Escolar Documentos
Profissional Documentos
Cultura Documentos
T R A I N I N G
Training Manual
Revision A
April 2009
Part Number 11-GM-10012
Table of Contents
Table of Contents
Module 1
Introduction .................................................................................1-1
Section 1 Course Introduction......................................................................... 1-3
Section 2 Wonderware System Platform ...................................................... 1-17
Lab 1 Creating a Galaxy......................................................................... 1-39
Section 3 The ArchestrA IDE ........................................................................ 1-45
Section 4 Automation Objects....................................................................... 1-67
Section 5 System Requirements, Licensing and Support............................. 1-79
Section 6 Application Planning ..................................................................... 1-89
Lab 2 Identifying the Mixer ..................................................................... 1-95
Module 2
Module 3
Module 4
Module 5
Module 6
Security ........................................................................................6-1
Section 1 Security Overview ........................................................................... 6-3
Lab 17 Security ...................................................................................... 6-13
Module 8
Module 9
Wonderware Training
Module 1
Introduction
Section 1 Course Introduction
Section 2 Wonderware System Platform
Lab 1 Creating a Galaxy
1-3
1-17
1-39
1-45
1-67
1-79
1-89
1-95
1-2
Module 1 Introduction
Module Objective
z
Introduce the Wonderware System Platform and its architecture, environment, and
requirements for installation and licensing.
Wonderware Training
Agenda
Module 1 Introduction
Section 1 Course Introduction
This section describes System Platform - Part 1 / Wonderware Application Server 3.1 and
Device Integration Products, the objective of the course, intended audience, prerequisites,
and the course agenda. It also includes a description of Wonderware Products.
Section 2 Wonderware System Platform
This section provides an overview of the Wonderware System Platform and how critical the
architecture of ArchestrA is to plant automation. An overview of the differences between
Object-oriented and traditional Tag based HMI and SCADA products is provided, as well as
how these differences apply to Wonderware System Platform applications. This section will
also provide a description of what a Galaxy is, how it relates to the Galaxy Database and the
Galaxy Repository and how a Galaxy is created.
Lab 1 Creating a Galaxy
Section 3 The ArchestrA IDE
This section provides an overview of the ArchestrA IDE, the Template Toolbox and Application
Views and the object Check-in/Check-out process.
Section 4 Automation Objects
This section provides an explanation of the various types of objects utilized in the ArchestrA
IDE and an overview of when and how they are used. Additionally, it describes how to create
and configure instances of objects and the hosting and containment relationships of objects.
Section 5 System Requirements, Licensing and Support
This section provides a detailed explanation of the system requirements necessary for
Wonderware System Platform, discusses Licensing details and covers Support services.
Section 6 Application Planning
This section provides an explanation of the need for adequately modeling your plant in order
to achieve an application implementation that will be optimal for efficiency.
Lab 2 Identifying the Mixer
1-3
1-4
Module 1 Introduction
This section provides an explanation of the importance of having a model of the plant facility.
Additionally, it explains the concept of how to utilize ArchestrA Application Server to model a
specific facility.
Lab 3 Creating the Plant Model
Section 2 The Deployment Model
This section provides an explanation of the Deployment Model and demonstrates the structure
of the Deployment Model.
Lab 4 Creating the Deployment Model
Section 3 The Runtime Environment
This section provides an explanation of the Runtime environment and explains the use of the
Object Viewer in monitoring the Runtime environment.
Lab 5 Using Object Viewer
Section 4 Connecting to the Field
This section provides an understanding of the Device Integration Objects, I/O Server and DA
Server. It also provides an overview of DI Objects.
Lab 6 Connecting to the Field
Wonderware Training
Module 6 Security
Section 1 Security Overview
This section provides an understanding of Security as it relates to Application Server.
Lab 17 Security
1-5
1-6
Module 1 Introduction
Section 1 Wonderware I/O Servers
This section will describe the configuration of a Wonderware I/O Server (Modbus).
Section 2 Wonderware Data Access Servers
This section provides familiarization with Wonderware Data Access Server and its use with
Application Server.
Section 3 Device Integration Objects
This section provides familiarization with DI Objects and their use with Wonderware
Application Server.
Wonderware Training
Automotive
Discrete Manufacturing
Electrical Power
Facilities Management
Process Manufacturing
1-7
1-8
Module 1 Introduction
These solutions leverage a powerful, layered software architecture that enables a variety of
features and capabilities, such as visualization, optimization and control of plant floor data
collection, and data storage and analysis.
Dev
Engelopm
inee ent
r
InteSyst em
grato
r
Inf r
Ope ast ru
.F
rat ct ur
.P acilit
ion e
ies
owe
s
M
Tra
an
n rG
IT
Pla
Bui n &
ld
P
Eng rocess
inee
r
.T
ag
sm en
.W ransp issio erat io emen
t
n&
.E at er ort at n
ion
t c.
&W
ast
ewa
t er
Con
Opetr ol R
rato oom
r
P
Suproducti
ervis on
or
Ope Line
rato
r
Ope
rat e
Mo
bile
Use
r
Q
Eng uality
inee
r
P
Eng rocess
inee
r
Ma
Opeintena
rato nce
r
Ma
i
Evo nt ain
lve &
IT
Ma
Sup intena
ervis nce
or
e
Machin
Ma
n
O uf a
per ct u
.D
at io ring
.F iscre
t
ns
o
eM
.M od
a
.O ining & Beve nuf ac
t
r
i
&
l&
urin
a
.S
Gas M et a ge
g
p
ls
P ec
.E harm ialt y C
ace hem
t c.
ut ic
al ical &
Line
Sys
t
Con em &
nec Dev
t ivi ice
ty
t
en
tm
par
/ De
Plan
t
/ Sit
es
Ent er pr ise
Wonderware Training
Product Quality Management and SPC Delivering products with high quality defined
as meeting specifications at the lowest possible cost is a top priority for manufacturers
and industrial operations, and Wonderware software applications meet these quality
needs. InTouch HMI offers real-time data monitoring and alarming; Wonderware Historian
stores voluminous process data for quality analysis; Wonderware QI Analyst software
provides enterprise-wide SPC; Wonderware ActiveFactory software trends data;
Operations & Performance software provides spec management, genealogy, BOM
enforcement, OEE and Downtime monitoring; the Wonderware System Platform monitors
data levels, and application templates can help deliver nearly any quality capability;
InBatch software collects information on batch quality and recipe settings; and the list
goes on.
Mobile Solutions Wonderware mobile solutions feature the industry's leading Mobile
Workforce & Decision Support System. Wonderware IntelaTrac enables the delivery of
Best Practices to field workers improving Asset Management for the leading refiners,
chemical manufacturers, and power generators globally.
For more information on Wonderware software solutions and products, visit the Wonderware Web
site at http://www.wonderware.com.
1-9
1-10
Module 1 Introduction
ArchestrA technology
ArchestrA technology, or architecture, helps reduce application engineering effort and deployment,
increase efficiency, provide optimization and standardization, and enable integration of distributed
automation systems and applications from virtually any vendor. Geographically dispersed
applications (from a few hundred to one million I/O, and from a single node to hundreds of
stations) can be rapidly and securely implemented.
The ArchestrA architecture leverages advanced software technologies to fill the gap between ERP
systems and control systems. This architecture provides the following:
z
Framework which supports common services and a core set of system objects
Object Development Toolkit which enables third parties to create new domain objects
customized for specific needs
Version management
Internationalization
Configuration and Deployment Related Components that are required for centralized
deployment of the runtime components. These components are installed just like any
other Windows application and include the following:
Runtime Components that are centrally deployed and administered. These components
include the following:
Wonderware Training
Wonderware Historian
The Wonderware Historian component of the System Platform is a high-performance, real-time
database for historical information. It combines the power and flexibility of a relational database
with the speed and compression of a true process historian, integrating the office with the factory
floor or any industrial operation. The Wonderware Historian is designed to collect a wide variety of
plant data, at full resolution and very high data rates.
Wonderware ActiveFactory
The Wonderware ActiveFactory software provides data-trend analysis, sophisticated numericaldata analysis using Microsoft Excel, comprehensive data reporting using Microsoft Word, and the
capability to publish real-time and historical plant information to the Web or company intranet site
using Wonderware Information Server. Plant knowledge workers using ActiveFactory information
can quickly troubleshoot problems, study potential process inefficiencies, and eliminate the timeconsuming process of locating the data.
1-11
1-12
Module 1 Introduction
Wonderware Information Server
The Wonderware Information Server offers an easy solution for aggregating and presenting plant
production and performance data over the Web or company intranet. Using Wonderware
Information Server, large amounts of process data can be aggregated into highly informative
production reports tailored to the information needs of plant personnel. Content from the
Wonderware Information Server can be incorporated into other Web portals, helping to make
existing corporate IT portals more informative and valuable.
Wonderware QI Analyst
Wonderware QI Analyst Statistical Process Control (SPC) software is an important part of any
quality management program. Performing both online and historical SPC, QI Analyst supports
real-time process monitoring and alarms, as well as historical reports to view process health over
any period of time. Real-time SPC, analysis, and reporting are equally easy. By storing process
data in the QI Analyst database and linking to external data sources, users can leverage
enterprise-wide SPC to reduce variation, reduce costs of manufacturing, and increase productivity.
Wonderware Training
Wonderware SCADAlarm
SCADAlarm alarm and event-notification software provides a telecommunications link to industrial
automation software systems. It seamlessly integrates with the comprehensive Wonderware
product family and has built-in browsers to enable fast configuration of information from
Wonderware System Platform and InTouch HMI software.
Wonderware Toolkits
Wonderware Toolkits provide powerful extensibility to InTouch HMI and System Platform
applications by enabling developers to extend the capabilities of Wonderware products to meet
specific system integration needs. The Toolkits promote adherence to industry standards, provide
additional customization and intellectual property protection, and enhance the ability to interface
Wonderware products with other software and hardware.
Wonderware offers the following Toolkits:
Toolkit
DAServer Toolkit
ArchestrA Object Toolkit
Historian Toolkit
Alarm Toolkit
Wizard Toolkit
Script Toolkit
GRAccess Toolkit
MXAccess Toolkit
1-13
1-14
Module 1 Introduction
Wonderware Enterprise Integration Application
Wonderware offers powerful capabilities to complete the manufacturing supply chain by linking the
manufacturing system to business applications like ERP, PLM, SCM, and LIMS systems.
Wonderware Enterprise Integration Application provides a scalable and configurable solution
designed to accommodate even the most complex requirements for tightly aligning business and
manufacturing systems.
Wonderware IntelaTrac
Wonderware IntelaTrac is a suite of configurable software and ruggedized mobile hardware
products that provides workflow management, procedural and general task management
capabilities typically focused around plant operations, maintenance management, and production
tracking and compliance applications to mobile field workers.
Object Development Toolkit: allows 3rd parties to create new domain objects
customized for specific needs
The ArchestrA infrastructure, or Framework, supports core services that are required by most of
the different types of supervisory control and manufacturing information systems mentioned
above. These core services include the following:
z
ArchestrA IDE
Version management
Internationalization
Wonderware Training
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.
1-15
1-16
Module 1 Introduction
Wonderware Training
Introduce the concept of ArchestrA and how it relates to the manufacturing environment
Explain the difference between Object Oriented development process and Tag Based
development process
Explain what a Galaxy is and how it relates to the Galaxy Database and the Galaxy
Repository
This section provides an overview of the Wonderware System Platform and how critical the
architecture of ArchestrA is to plant automation. An overview of the differences between Objectoriented and traditional Tag based HMI and SCADA products is provided, as well as how these
differences apply to Wonderware System Platform applications. This section will also provide a
description of what a Galaxy is, how it relates to the Galaxy Database and the Galaxy Repository
and how a Galaxy is created.
System Platform
The Wonderware System Platform provides a single platform for all the SCADA, Supervisory HMI,
and Production and Performance Management needs of industrial automation and information
personnel. It provides a common and strategic industrial application services platform on top of
virtually any existing system, and is built upon the industry-standards based, ArchestrA real-time
SOA technology.
The Wonderware System Platform is designed to make it easier for manufacturers to adjust to the
ever-changing needs of customers and the overall market. Its diverse functionality extends
Wonderware customers software investments and encourages flexibility in application
development.
It supports consistent and reliable operations across industrial operations and manufacturing
facilities as well as promotes sustainable production and operational performance improvements.
The Wonderware System Platform contains an integral core set of capabilities and services to
support sustainable production and operations performance improvement via a comprehensive
set of six capability areas:
z
1-17
1-18
Module 1 Introduction
Industrial Domain Services
The Wonderware System Platform offers industrial domain services that are not provided by
commercial operating systems or generic IT products. It provides a powerful infrastructure that
enables Wonderware customers to leverage lower-cost commercial PC hardware and operating
systems in industrial applications.
Application functions are quickly customized. Whether you have no knowledge of computer
programming or consider yourself an expert software engineer, the System Platform can empower
you to conveniently interact with process systems from any remote location. The result is a
reduction of personnel costs and improved response times because the software continuously
monitors and deploys messages, 24/7.
Industrial Domain Services provide:
z
Audit logging and extended security protection for developers and system-maintenance
personnel
Pager, mobile phone, PA system and e-mail alerts for unattended operational monitoring
A single global Namespace to access data elements anywhere, without tag limitations
Plant information and supervisory functions to script special behavior and responses
Easy importing and migration of legacy systems and external system configurations
Connectors and communication servers for control devices, applications and systems
including:
Wonderware Training
A production history archive for a single production line, an entire facility or the
complete enterprise
Data compression, which reduces disk storage and makes more data available online
Manual data
1-19
1-20
Module 1 Introduction
Information-Delivery and Visualization Services
Delivering the right information, to the right user, at the right time, and in the form in which they
expect it is a key service provided by the Wonderware System Platform. Wonderware customers
can concurrently visualize manufacturing and business information, and dynamically implement
changes to reach their business objectives.
Quickly access real-time and historical information using the open and easy-to-use HMI solution
that seamlessly integrates with legacy and new plant systems. Proactively enhance your plants
profitability by taking action on information in real time, obtaining real-time and historical data from
beyond the boundaries of the secured process network. Create queries and run reports, even if
you have no SQL database knowledge. The Wonderware System Platform can even help you
achieve regulatory compliance with simple and accurate automated reports.
Capabilities
z
Multiple client interfaces [i.e., Thick, Terminal Services Edition (TSE) or Web Client]
Open SQL access, enabling simplified data queries with powerful retrieval modes
Wonderware Training
Advanced ArchestrA technology, which facilitates the assembly of applications that are
component-based and generated from standard templates
SharePoint services
Microsoft Office
1-21
1-22
Module 1 Introduction
System Management and Extensibility Services
Furthermore, the Wonderware System Platform facilitates the easy management, expansion and
modification of applications or the host computing architecture. These services provide a range of
architectural choices, both during the initial system design phase and throughout the lifetime of an
installed system.
Leverage the flexible and scalable ArchestrA software architecture for small and large systems
systems that can be easily expanded to meet future requirements. Improve system
troubleshooting. Leverage Wonderwares technological evolution and increased protection for
operating systems and databases. Decrease lifecycle costs for plant IT solutions. Change and
expand your system as a whole without disruption.
System Management and Extensibility Services provide:
z
The ability to re-architect systems at any time to support different system topologies (i.e.,
Single Node, Client/Server, Peer-to-Peer or Web-centric
In essence, the Wonderware System Platform facilitates consistent and reliable operations across
manufacturing and industrial operations to protect brand integrity. It empowers Wonderware
customers to extend their systems in virtually any direction to meet their current and future needs.
ArchestrA
ArchestrA is a comprehensive plant automation and information architecture designed from the
outset to extend the life of legacy systems by leveraging the latest software technologies.
Offerings built upon this architecture empower decision-makers to achieve their business goals,
without abandoning prior investments in automation systems, production processes or intellectual
property.
ArchestrA's complete approach to industrial architecture significantly reduces a plant's total cost of
ownership through easy installation, operation, modification, maintenance and replication of
automation applications.
In the ArchestrA environment, software applications can be rapidly assembled rather than
programmed. New applications also can be created simply through the reassembly of existing
applications.
The ArchestrA vision is to provide a unified and robust architecture that is the basis for
collaborative production systems in support of industrial enterprises. Its open-development
platform and tools uniquely enable Invensys and third parties such as OEMs, machine builders
and system integrators to build domain knowledge and add significant value to the solutions they
provide. End-users and suppliers will benefit from ArchestrA's unified platform, which enables the
instant integration of application information.
ArchestrA is the comprehensive industrial automation and information architecture that
orchestrates a new way to run or expand older plants more efficiently, and an optimal way to build
new plants.
Wonderware Training
1-23
1-24
Module 1 Introduction
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.
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
Wonderware Training
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.
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.
1-25
1-26
Module 1 Introduction
ArchestrA Architecture
ArchestrA, developed by Invensys, is a software infrastructure designed to unify combinations of
Invensys, third-party, and customer internal applications, both current and emerging, into a
synchronized, plant-level application model, and to foster their ongoing adaptation and
improvement. It comprises a unique combination of new toolsets and new applications
infrastructure services, allowing the rapid generation of new applications, products, and services.
Because it enables easy upgrades via integration of existing systems with these new technologies,
it offers manufacturers the promise of extending the lifecycle of an entire 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
1-27
1-28
Module 1 Introduction
Automation Information Pyramid
ArchestrA supports all layers of industry standard models. It is the basis for Supervisory,
Production and Plant Intelligence solutions. In addition, it extends functionality across the
enterprise enabling true manufacturing collaboration. The Automation Information Pyramid
illustrates these points. It displays the complete effectiveness of ArchestrA across all levels of the
manufacturing environment:
1. Plant Floor Connectivity
2. Supervisory
3. Production
4. Plant Intelligence
5. Manufacturing Collaboration
The following page illustrates these segments as they relate to the Automation Information
Pyramid.
Wonderware Training
Manufacturing
Collaboration
Plant
Intelligence
Production
Supervisory
Plant Floor
Connectivity
1-29
1-30
Module 1 Introduction
Scalability
Wonderware Application Server provides a scalable and integrated architecture to meet the needs
of small, simple applications all the way up to highly challenging manufacturing information
management systems.
Wonderware Application Server resolves the problems associated with scaling automation
applications because there are no limitations on system size and performance issues are easily
addressed through the introduction of new nodes. New workstations and any data points defined
are automatically integrated into the initial application through the plant model. The common
distributed peer-to-peer Namespace means that all information is shared between the nodes
without the user having to perform any additional engineering or configuration.
Object Oriented
Hierarchical
Done Last
Developed in Objects
Strictly Enforced
Progagated from Templates
Physical Devices as Objects
Tag Based
Flat
Done Early
Developed in Tags
Not Strictly Enforced
Changed in Tools like Excel
Data Types and communication
Bits as Tags
From the inception of PC-based HMI and Supervisory products, the development of data access,
scripting, alarming and data analysis has been based on the concept of tags. While simple and
very portable from one project to another, a tag-based environment has the downfall of a flat
Namespace, with no inherent ability to link elements together into more intelligent structures, with
built in relationships and interdependencies. Global changes to a tag database are typically done
externally to the development environment, in tools like Microsoft Excel or as a text file and then
re-imported into the application. Reuse in a tag-based system is commonly instituted through
dynamic or client-server referencing, that allows a common graphic to be created. Then a script is
executed to switch the tags being viewed in run-time. Furthermore, because of the flat structure of
the application, changes need to be sought out and analyzed as to the affect on the rest of the
application.
Wonderware Training
Alarm Monitoring
Animation Scripts
Security Scripts
Supervisory Scripts
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.
1-31
1-32
Module 1 Introduction
Types of objects
In object-oriented SCADA, objects contain the aspects or parameters associated with the device
they represent. For example, a valve object can contain all the events, alarms, security,
communications and scripting associated with a device. Objects don't just represent plant
equipment. They can also model common calculations, database access methods, Key
Performance Indicators (KPIs), condition monitoring events, ERP data transfer operations and
many more things that you want the plant information system to do. Because these operations are
modular, it is easy to add them to any and all parts of the application. For example, let's say that
there is a standard way your organization calculates and initiates a maintenance work order for a
pump. By encapsulating this function as an object, it is possible to use it with any pump in the
application.
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.
Wonderware Training
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
1-33
1-34
Module 1 Introduction
Object oriented Development Process- graphics are created last
Wonderware Application Server and the ArchestrA IDE have brought a new era to SCADA
Software development through the ability to create a complete plant device model. The developer
is abstracted from the complexities of the computing environment and allowed to concentrate on
"modeling" how the production facility is laid out and the different manufacturing cells and
processes that comprise plant-wide supervisory control. Once the plant model is captured, it is
easy to implement supervisory control functions. A small investment in creating Templates yields
big results in engineering productivity. The ten easy steps to creating a supervisory application
using the Application Server are:
1. A site survey is conducted to understand the layout of the manufacturing operation or process.
Piping and Instrument Diagrams (P&ID) can also be referenced to understand the specific
equipment in use.
2. A list is developed of similar pieces of equipment, like common types of motors, valves,
transmitters, control loops, drives, etc. Distinct areas of operation are also identified.
3. Templates are configured for each common device or component in the facility. For example,
there may be 100 transmitters of a particular type that can be modeled as a single device
template. This process sets up the standards for the supervisory application and for any
applications that are created in the future. These templates will be used to develop objects
which represent a specific device, such as a level transmitter LIC101. In addition, templates
contain all of the logic, input/outputs, scripting, history configuration, security and alarms and
events for the device.
4. Device templates can be contained within each other to build-up a more complicated device,
for example, a mixer may contain a level transmitter, pump, inlet / drain valves and agitator.
5. Device templates have attributes which represent real I/O available in the PLC or control
system. These attributes are then linked to the I/O through Device Integration Objects.
6. The application can then be assembled by using a simple drag and drop capability inside if the
ArchestrA IDE. As templates are dropped into their individual plant areas, an object instance is
created that is linked back to the template. This is the "Object-Oriented" nature of the
Application Server, which provides incredible power when it comes time to modify anything in
the system. The software does all the work as the user is simply configuring templates that
represent the equipment in the plant.
7. Objects are then assigned to security groups. This can be done on an individual basis or by
area of the plant. These security groups have common permissions. Roles are created to map
rights onto each security group. Users can be given one or more roles. This offers a great
amount of flexibility in changing user permissions and in managing the security model.
8. The model created in the ArchestrA IDE can now be deployed to the computers that will host
the application. Notice that absolutely no consideration needs to be given to how the
supervisory stations are going to be laid-out or which computer needs to have a specific part
of the system running on it. The Application Server is a fully distributed system, which can
reside on a single computer or on hundreds of computers. Standard system objects, such as
Platforms and Engines, represent specific computers that are used to host objects when they
are deployed.
9. Graphics are then configured using InTouch, the world's most popular HMI software
package. This can also be done using the Smart-Symbol functionality contained in InTouch
9.0 SP 2 which allows a graphic element to be created and linked to a template in the
ArchestrA IDE. That way the display graphics are also object-oriented and tightly coupled to
the plant model.
Wonderware Training
1-35
1-36
Module 1 Introduction
What is a Galaxy?
Its important to understand what a Galaxy is before one is created. A Galaxy is the entire
application, the complete ArchestrA system consisting of a single logical name space and a
collection of WinPlatforms, AppEngines and objects. One or more networked 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 ArchestrA IDE session requires connection to a specified Galaxy. In other words, the
ArchestrA IDE cannot be started in a Galaxy-neutral state. When you attempt to start the
ArchestrA IDE, the Connect to Galaxy dialog box is displayed.
Galaxy Repository/Galaxy connect selections: This consists of the GR Node Name and
Galaxy Name boxes.
Action buttons: Connect, New Galaxy, Delete Galaxy, About and Cancel.
Licensing information
If the Galaxy Name box is empty, you have not yet created a Galaxy on the computer shown in the
GR Node Name box. Before you can start the ArchestrA IDE, you must either browse for a Galaxy
on another node or create a new Galaxy.
Wonderware Training
1-37
1-38
Module 1 Introduction
Wonderware Training
Objectives
Upon completion of this lab you will be able to:
z
Create a Galaxy
1-39
1-40
Module 1 Introduction
Summary Lab Instructions
Following is a summary of the general steps you will complete for this lab. For detailed
instructions, please refer to the Detailed Lab Instructions on subsequent pages.
Wonderware Training
Create a Galaxy
1. Start the ArchestrA IDE by selecting Start / All Programs / Wonderware / ArchestrA IDE.
This will display the Connect To Galaxy dialog box.
The GR node name field will reflect the name of the local computer.
The Galaxy name drop-down list is initially empty since there are no Galaxies created in this
node.
2. Click the New Galaxy button to create a new Galaxy.
1-41
1-42
Module 1 Introduction
4. Enter TrainingGalaxy in the Galaxy name field.
5. Verify Base_Application_Server.cab is selected in the Galaxy Type field.
6. Click the Create button to continue.
The Create Galaxy dialog box will display indicating the Galaxy creation progress.
When the galaxy creation process is complete the Close button will enable.
7. Click Close.
Wonderware Training
This closes the Connect To Galaxy dialog box and displays the ArchestrA IDE.
1-43
1-44
Module 1 Introduction
Wonderware Training
This section provides an overview of the ArchestrA IDE, the Template Toolbox and Application
Views and the object Check-in/Check-out process.
1-45
1-46
Module 1 Introduction
Key Functions of the ArchestrA IDE
The Main Window is the user interface in which you can create your application and deploy it to
your enterprise. This main window provides the key platform where a wealth of functionality
capability can be accessed and configured. Some of these key functions include the following.
z
Galaxy Configuration
Destroy a Galaxy
Security Configuration
Object Configuration
Edit objects
Deploy/undeploy objects
IDE Configuration
As the main aspects of the ArchestrA IDE Main View (for example, Menu options, Toolbars,
Template Toolbar and Application Views, etc.) are identified and discussed, they are elaborated on
in greater detail as to how these Key Functions can be used
Wonderware Training
The Main Window of the ArchestrA IDE is composed of the following components:
z
Title bar
Menu bar
Toolbar
Template Toolbox
Application Views
Operations View
Status bar
When you first log in to the ArchestrA IDE, the Main Window displays the Template Toolbox and
Application Views docked on the left, the Toolbar docked at the top, and the Object Editor Client
Area on the right. Upon subsequent logins by the same user, the Main Window displays the
positions for these controls as they were at the end of the last log in session.
The Title Bar displays the name of the utility. The other elements of the Main Window are
described below.
1-47
1-48
Module 1 Introduction
Menu Bar
The ArchestrA IDE Menu Bar is a dynamic element that includes the following menus:
Galaxy, Edit, View, Object, Window, and Help. Depending on what object or Main Window
element is in focus, what condition it is in, or whether certain functions are logically permitted,
some menu commands may be deactivated. The following is a description of menu commands.
Galaxy menu Providing Galaxy or user-level global commands, the Galaxy menu includes the
following:
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.
Export For exporting Automation Objects, All Automation Objects, Script Function
Libraries, and a Galaxy Dump.
Wonderware Training
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 ArchestrA IDE, this command
opens the ArchestrA 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.
1-49
1-50
Module 1 Introduction
View menu similar to a standard Microsoft View menu, this menu provides commands for
controlling the Main Window display. On your initial ArchestrA IDE login, all four Main Window
components listed below are visible (checked) and the client language is set to the one chosen
during installation. Subsequent logins by the same user implement the previously saved ArchestrA
IDE settings. This menu includes the following commands:
Model For bringing focus to the Model view of the Main Window.
Deployment For bringing focus to the Deployment view of the Main Window.
Derivation For bringing focus to the Derivation view of the Main Window.
Template Toolbox For bringing focus to the Template Toolbox of the Main Window.
Graphic Toolbox For bringing focus to the Graphic Toolbox of the Main Window.
Operations For displaying the progress and results of a set of Galaxy database
operations that can be done at the same time as other application-building operations.
Synchronize Views For specifying that a selected object stay selected as you move
through the views.
Reset Layout For resetting everything back to its original default locations.
Status Bar For toggling on/off the Status Bar of the Main Window.
Wonderware Training
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 1-54 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.
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.
1-51
1-52
Module 1 Introduction
z
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 ArchestrA IDE Help menu includes the
following commands:
Help Topics Standard Help command, used for opening the ArchestrA IDEs HTML
Help documentation system.
About ArchestrA IDE Opens the About ArchestrA IDE dialog box which provides
software version and copyright information.
Operations Pane
The Operations pane displays the progress and results of a set of Galaxy database operations
that can be done at the same time as other application-building operations. Currently, validating
the configuration of objects is the only operation that uses this pane.
Important! Validation can be done on both templates and instances, but only on those that are
checked in.
Wonderware Training
Right-click on an object (multi-select is allowed) and click Validate on the shortcut menu.
1-53
1-54
Module 1 Introduction
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 ArchestrA IDE. See section on
Operations Pane for more information.
Only one validation operation can be run at a time. But you can multi-select more than one object
for each validation operation. The set of objects are validated serially.
Note: Validation operations cannot be canceled.
Continue using the ArchestrA IDE to perform other operations, if necessary, while validation is
ongoing, including work on objects in the validation set. If an object is not available for validation
when the command is initiated on it, validation is not be performed. Also, if validation is in process
on an object, other operations initiated by you on the object fail. Failure to perform validation on an
object is indicated in the Command Results column of the Operations pane.
To validate all objects in the Galaxy, validate the Galaxy object.
Wonderware Training
Toolbar
The ArchestrA IDE Toolbar consists of icons for quick access to frequently used commands. It is
shown below, and each icon, from left to right, is described afterwards. The description titles
associated with each below are based on the tool tip that appears when you hover over each
Toolbar icon.
Change Galaxy For selecting a Galaxy repository that is different from the one to
which you are currently connected, this command opens the Select Galaxy dialog box.
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 checked 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.
1-55
1-56
Module 1 Introduction
Deploy For deploying the object or objects currently in focus to the nodes their
configurations denote, this command opens the Deploy Object dialog box.
Undeploy For undeploying the object or objects currently in focus from the nodes that
currently host them, this command opens the Undeploy Object dialog box.
Delete For deleting the object in focus.
Customize Toolsets For maintaining the toolset categories displayed in the Template
Toolbox, this command opens the Customize Toolsets dialog box.
User Information For configuring global user preferences for the ArchestrA IDE.
Using this command opens the Configure User Information dialog box.
Galaxy Status For accessing the status of the current Galaxy.
Model View For displaying the Model view in the Main Window.
Deployment View For displaying the Deployment view in the Main Window.
Derivation View For displaying the Derivation view in the Main Window.
Template Toolbox For displaying the Template Toolbox in the Main Window.
Graphic Toolbox For displaying the Graphic Toolbox in the Main Window.
Operations View For displaying the Operations View in the Main Window.
IDE Help Standard Help command, used for opening the IDEs HTML Help
documentation system.
The availability of the previously described icons is dynamic depending on which part of the
ArchestrA 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.
1-57
1-58
Module 1 Introduction
Application Views
The Application Views pane displays the galaxy configuration based on how an object is related to
other objects:
z
Model View - This defines the Object relationship to the automation scheme layout. The
Objects are organized into Areas to represent the physical plant layout.
Deployment View - This view defines the Object instance relationship to the PC that the
Object code is running on.
Derivation View - This view displays what the derivation path is from Base Template to
Instance. All templates and instances are displayed in this view.
The Model view is the default display when the ArchestrA IDE is first started. Subsequent
ArchestrA IDE sessions retain the users last setting.
Model View
The Model view presents objects in terms of their physical or containment relationships, and
allows you to organize them through a folder structure. This view most accurately represents an
application perspective of the processes that users are emulating: for instance, specific process
areas, tanks, valves, pumps and their relationships based on containment.
An example of a Model view is as follows:
Galaxy Name
This view is used to display the assignment of Object Instances to their area. All Object instances
belong to one and only one area.
Areas can be hierarchical. This means that an area can contain an area and the parent area
collects the statistics for all its Objects and its sub-areas.
The above diagram represents the tree view that is displayed within the model view. This
represents the area based relationships of each of the objects. The diagram is read left to right and
top to bottom, so an Area can host Application objects, DeviceIntegrationObjects,.and Objects that
contain Objects
If the instance does not have a defined host then the instance will be displayed under the
"Unassigned Area" root of the tree.
The top of the tree is the GalaxyObject, This is displayed using the name that was given to the
Galaxy when it was created.
To assign one object to another, drag-and-drop it. To unassign an object currently assigned to
another object, drag-and-drop it to the Unassigned Area folder.
Wonderware Training
This diagram represents the tree view that is displayed within the deployment view. This
represents the topology view based on which PC and Engines the objects run on. The diagram is
read left to right and top to bottom, so a Platform can host an AppEngine. Also, an AppEngine can
host an Area.
If the instance does not have a defined host then the instance will be displayed under the
"Unassigned Host" root of the tree.
To assign an object to another, drag-and-drop it onto the host object. An inappropriate assignment
match is not allowed. Conversely, to unassign an object, drag-and-drop it to the Unassigned
folder.
1-59
1-60
Module 1 Introduction
Derivation View
The Derivation view presents objects and templates in terms of their genealogy relationships. The
derivation view is the only tree view that shows both templates and instances. The purpose of this
view is to display to the user from which templates and derived templates an instance inherits its
properties.
An example of a Derivation view is as follows:
This view contains all templates and instances. The tree is displayed in alphabetical order at each
level within the tree.
The base templates created within the ApplicationObject Toolkit is on the left, as all other
templates and instances are derived from these an extra level will be added to the tree.
The items with $ prefixes are templates or templates which were derived from other templates.
Base templates are shown in the second level of the tree structure, and derived templates and
object instances are appropriately indented based on their relationship with parent objects.
Templates with no associated instances are grouped together under Unused Templates. Under
each branch of the tree, child objects are listed in alphabetical order. Default objects are displayed
in bold.
Unlike the Model and Deployment views, you cannot drag-and-drop objects from one branch to
another in the Derivation view. The parent-child relationship between a template and a
downstream object cannot be changed dynamically. You can perform other commands on objects
in this view.
Wonderware Training
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:
1-61
1-62
Module 1 Introduction
Three Types of Status Indicators
There are three kinds of indicators that accompany object icons:
z
Description
Undeployed (see AnalogDevice_001 and DDESuiteLinkClient_001 in example above)
(no indicator)
Description
Configuration warning
Configuration error
(no indicator)
Configuration good
Description
AppEngine undeployed, its redundant pair deployed.
AppEngine deployed, its redundant pair not deployed pending configuration updates.
AppEngine deployed, its redundant pair not deployed pending required software update.
Description
Applies to InTouchViewApp deployment when files are being transferred.
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.
1-63
1-64
Module 1 Introduction
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.
To check an object in to the Galaxy database
a. Select it and, on the Object menu, click Check In
Wonderware Training
b. Enter a comment (optional) and click OK to finish checking in the object. Click Cancel to
terminate the check in process.
The Galaxy indicates whether any of the objects you are attempting to check in are check-out to
other people. If an object you are attempting to check in already is checked in, check in is ignored.
The Check In dialog box enables you to provide comments about configuration changes made
while the object was checked out. It is comprised of the following options:
z
Comment: Use this box to enter your comments about configuration changes made to the
object.
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.
1-65
1-66
Module 1 Introduction
Object Viewer
Note: The Object Viewer is explained in more detail when the Runtime Environment is discussed
in Module 2, Section 3, The Runtime Environment,, page 2-25
The Object Viewer monitors the status of the objects and their attributes and can be used to
modify an attribute value for testing purposes.
To add an object to the Object Viewer Watch list, you can manually type the object and attribute
names into the Attribute Reference box in the menu bar and select Go. When prompted to enter
the Attribute Type, press the OK key.
You can save a list of items being monitored. Once you have a list of attributes in the Watch
Window, you can select all or some of them and save them to an XML file. Right-click on the
Watch window to save the selection or load an existing one. You can also add a second Watch
window that shows as a separate tab in the bottom of the Viewer.
Refer to the Platform and Engine documentation for information about attributes that may indicate
system health. These attributes provide alarm and statistics on how much load a platform or
engine may have when executing application objects or communicating with I/O servers and other
platforms.
You see information about total instances, total templates, deployed instances with changes,
undeployed instances with changes, objects that have an error or warning state, objects that are
checked out, and object you have checked out.
c. Click OK.
Wonderware Training
This section provides an explanation of the various types of objects utilized in the ArchestrA IDE
and an overview of when and how they are used. Additionally, it describes how to create and
configure instances of objects and the hosting and containment relationships of objects.
Objects
Automation Objects
An automation object allows the encapsulation of all configuration elements of each piece of your
system, such as I/O definitions, logic (scripting), history configuration, alarm/event configuration,
security/access control and graphics. This self-contained approach dramatically reduces the
engineering time associated with the initial creation and maintenance of objects. By keeping all
object configuration tightly related and contained within the object itself, there is no need to use
multiple editors to make sure that the alarming, I/O definitions, scripting, history, and security are
consistent for an object.
There are Template objects, and Instance objects:
z
Template objects: these are high-level definitions of the objects: equipment, devices,
constructs or simply system parts of the Galaxy
Instance objects: these are the runtime objects and represent the specific items in the
environment, like processes, valves, holding tanks, and so on
Domain objects:
z
Device Integration objects: represent the communication with the external devices
System objects: represent the parts of a Galaxy and not the domain they are monitoring
and/or controlling
An object reference cannot exceed 32 characters (including the $ character used in template
names) and must contain at least one non-numeric character.
1-67
1-68
Module 1 Introduction
You should avoid assigning objects and attributes the same names because this may result in an
attribute reference can refer to two different things. For example, if you have two objects, A1 and
B2, where A1 is the container of B2, and object A1 has an attribute named B2, the reference string
A1.B2 could either refer to the B2 attribute within A1, or the B2 object contained in A1.
Object Categories
Within the Template Toolbox there are three main categories of objects. These are:
z
Application objects
AnalogDevice
Boolean
DiscreteDevice
Double
FieldReference
Float
Integer
Sequencer
SQLData
String
Switch
UserDefined
DDESuiteLinkClient
InTouchProxy
OPCClient
RedundantDIObject
System objects
AppEngine
Area
InTouchViewApp
ViewEngine
WinPlatform
Wonderware Training
Application Objects are used to create devices in your Galaxy. These devices represent real
objects in your environment.
AnalogDevice Object
This object can act as either an Analog Input (with optional Output) or as an AnalogRegulator that
provides an external representation of a PID controller that exists elsewhere (typically a PLC or
DCS).
The AnalogDevice can be configured to have a personality of one of the two basic types:
z
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.
1-69
1-70
Module 1 Introduction
z
Initial Control Mode When in Cascade, the SP can only be written by other objects.
When in Manual, a user can write the SP. When None, anything can write to it.
Control Tracking optional capability to read a Boolean control track flag from an external
device or object. When tracking is on, the SP is pure read-only and cannot be changed.
Boolean Object
The Boolean object is derived from the FieldReference object and is used for evaluations that
result in either of the truth values of true of false, often coded 1 and 0 respectively.
DiscreteDevice Object
A Discrete Device is a general purpose Object that is used to represent a large class of physical
equipment common in manufacturing such as pumps, valves, motors, and conveyors. These
devices have two or more physical states (for example Open, Closed, Moving), and are optionally
controlled using a combination of discrete outputs. Their actual state is monitored via a
combination of discrete inputs.
The meaning of the states depends on the kind of Discrete Device. In the case of a pump, the
states might be configured as Off and On, while for a valve they might be configured as Open,
Closed, or Moving. Note that a control valve has a continuous position represented by 0 to
100% and is not typically represented with a Discrete Device, since its state is represented by a
continuous signal rather than discrete signal.
When a Discrete Device is commanded to a new state, it sets an appropriate combination of
discrete outputs for that state. When its monitored discrete inputs change, the Discrete Device
determines the new actual state of the equipment and sets the PV (process variable)
appropriately.
Through the use of the Discrete Device the operator is guaranteed that a value displayed on the
screen is a good and reliable value. This object will automatically display the state as Bad if the
quality of any of the inputs is bad or the inputs are in an invalid combination determined at
configuration time by the application developer.
Some of the features of the Discrete Device object are as follows:
z
Input and Output states of the DiscreteDevice object are totally independent of each other
and can be configured as required by the 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).
Double Object
The Double object is derived from the FieldReference object.
FieldReference Object
The FieldReference object is the generic object for accessing data from an external device. This
object can act as both the field input and a field output.
Wonderware Training
WriteOnly Output
Note: There is an Online Seminar available for the ArchestrA Sequencer Object. To register,
visit www.wonderware.com/training or call 1-866-WW-TRAIN (1-866-998-7246) or email
Wonderware Training at training@wonderware.com.
SQLData
The SQLData Object is an ArchestrA application object that can be used to store data to, and
retrieve data from a SQL Server database. The SQLData Object provides the means to map data
in a SQL database to attributes in a Galaxy.
String Object
The String object is derived from the FieldReference object.
Switch Object
The Switch object is the object for accessing data from a simple discrete (0/1) device. This object
can act as both a discrete input and a discrete output.
The Switch Object can be configured into three basic access modes:
z
WriteOnly Output
The PV value can be historized, logged as an event, and alarmed when abnormal.
UserDefined Object
The UserDefined object is an empty object that you can use to create customized objects. You can
use the UserDefined object in the following ways:
z
As a "container" for other objects. An object relationship in which one object is comprised
of other objects is called containment. Containment allows you to group various objects
together to make complex objects. For detailed information on object containment, see the
ArchestrA IDE documentation.
1-71
1-72
Module 1 Introduction
To use the UserDefined object as a container object, you simply create an instance of the object,
and add ApplicationObjects to it while in the Model View. The only indication of this containment
structure is in the tree structure in the Template Toolbox or Model View. The UserDefined object
editor does not provide any indication of this containment relationship. To edit the configuration of
any contained objects, you must open the individual editors of those objects.
Note: A UserDefined object can only contain ApplicationObjects.
z
As a base object to extend through user-defined attributes (UDAs), scripting, and attribute
extensions. For detailed information how to customize an object using these features, see
the common editor documentation.
For example, you might create a UserDefined object called "Tank" and use it to contain
ApplicationObjects that represent aspects of the tank, such as pumps, valves, and levels. You
could create two DiscreteDevice object instances called "Inlet" and "Outlet" and configure them as
valves, and create an AnalogDevice object instance called "Level" and configure an alarm to be
triggered when it overflows. The containment hierarchy would be as follows:
--Tank
--V101 (Inlet)
--V102 (Outlet)
--LT103 (Level)
The Tank object derived from the UserDefined object can be customized to raise an alarm when
both the Inlet and Outlet valves are open. For example, you could add a Boolean UDA called
"StateAlarm," extend it with an alarm extension, and add the following script:
if me.inlet == "Open" and me.outlet == "Open" then
me.statealarm = true;
else
me.statealarm = false;
endif;
You would now have a UserDefined object that forms the complex Tank object, which uses
containment and has been extended to raise a specific process alarm.
Wonderware Training
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.
This object is very simple; it only allows the value of three attributes to be historized:
z
InTouchViewApp Object
The InTouchViewApp object represents an InTouch for System Platform application. The
InTouchVewApp object manages the check-in, check-out, and deployment of an InTouch
application.
When you create an InTouchViewApp for a new InTouch application, WindowMaker is started by
the ArchestrA IDE. You then create the application the same way you would if WindowMaker had
been started from the InTouch Application Manager.
ViewEngine Object
The ViewEngine object is used to host InTouchViewApp objects. The ViewEngine object supports
common engine features such as deployment, undeployment, startup and shutdown. One
ViewEngine object can handle several InTouchViewApp objects.
WinPlatform Object
The WinPlatform platform object is a key base object. The key functionality of this object includes:
z
Calculating various statistics related to the node 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.
1-73
1-74
Module 1 Introduction
z
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
Wonderware Training
Creating a Template
Right-click on the appropriate type of object, and select New / Derived Template. For example,
use the $UserDefined object to create a $Mixer template as a container for the mixers various
components (agitator, inlet valves, pumps, and so on).
Instances
Instances are the run-time objects created from templates in Wonderware Application Server.
Instances are the specific things in your environment like processes, valves, conveyer belts,
holding tanks, and sensors. Instances can get information from sensors on the real-world device
or from application logic in Wonderware Application Server. Instances exist during run time.
In your environment, you may have a few instances or several thousand. Many of these instances
may be similar or identical, such as valves or holding tanks. Creating a new valve object from
scratch when you have several thousand identical valves is time-consuming. That's where
templates come in.
1-75
1-76
Module 1 Introduction
There are two ways to create an instance of a template. This is indicated as follows:
Wonderware Training
It can now be renamed using the naming convention as designated by your instructor.
1-77
1-78
Module 1 Introduction
Wonderware Training
This section provides a detailed explanation of the system requirements necessary for
Wonderware System Platform, discusses Licensing details and covers Support services.
2 gigahertz (GHz) or faster dual core processor, or a 3 GHz or faster single core
processor. A dual core processor is strongly recommended for optimal performance
Minimum of 2 gigabytes (GB) RAM. For Galaxies with more than 500 objects, 4 GB
RAM is recommended in the GR node
Super VGA (1024 x 768) or higher resolution video adapter and monitor.
Keyboard
Super VGA (1024 x 768) or higher resolution video adapter and monitor
Keyboard
The hardware requirements for using the Alarm Client and Trend Client at run time are the same
as for the InTouch HMI version 10.1 run time.
The Windows Vista operating system imposes hardware requirements that may exceed the
minimum requirements for Application Server version 3.1. If you intend to install Application Server
3.1 on a computer running Windows Vista, see the following Microsoft web site for hardware
requirements:
www.microsoft.com/windows/products/windowsvista/editions/systemrequirements.mspx
1-79
1-80
Module 1 Introduction
Software Requirements
This section describes the operating system, database, and other software requirements to install
Application Server version 3.1.
z
Operating Systems
Operating Systems
z
Windows Server 2003 Standard Edition SP2 is the recommended operating system
for computers running server components.
The following table lists the supported operating systems that can be installed on computers
running as Application Server development, application, and GR nodes. Development and
application nodes are considered to be clients of the server GR node.
Operating Systems
Notes:
1. The Windows 2000 Professional, Windows 2000 Server, and Windows 2000 Advanced Server
operating systems are not supported for Application Server version 3.1. An error occurs if you
attempt to install or upgrade Application Server version 3.1 on a computer running any edition
of the Windows 2000 operating system.
2. The computer designated as the Galaxy Repository node can run on Windows XP Pro only as
a single-node configuration of Application Server. Windows Server 2003 is the recommended
operating system for the GR node.
3. You can run Application Server only on computers running a 32-bit operating system. You
cannot run Application Server on a computer running a 64-bit operating system.
4. The Bootstrap, IDE, and Galaxy Repository are supported by the following language versions
of Microsoft operating systems: English, Japanese, Chinese, German, and French. The
Galaxy Repository is also supported by the English, Japanese, Chinese, German, and French
versions of Microsoft SQL Server 2005.
Wonderware Training
SQL Server 2005 SP2 must be installed on the computer designated as the ArchestrA
Galaxy Repository node prior to installing Application Server.
You also cannot install and use Application Server on a computer that has both Microsoft
SQL Server 2000 and Microsoft SQL Server 2005 installed.
The Galaxy Repository locks the SQL Server maximum memory usage to 65% of the
computer's physical memory.
TCP/IP must be enabled on the computer hosting a SQL Server 2005 database. The TCP/
IP protocol setting can be verified from the SQL Server 2005 Network Configuration under
SQL Server Configuration Manager.
The Microsoft SQL Server 2005 login for BUILTIN\Administrators group must be present
and enabled.
Microsoft .NET Framework 3.5 must be installed on every computer that hosts an
Application Server version 3.1 component. The Application Server installation program
halts if .NET Framework 3.5 is not installed on the target computer. A dialog box appears
requesting that you install .NET Framework 3.5. If you click Install Prerequisites, the
installation program automatically installs .NET Framework 3.5.
Microsoft Visual Studio 2005 is required only by the MXAccess and GRAccess toolkits
distributed with Application Server.
InTouch 10.1
ActiveFactory 9.2
QI Analyst 8.1
1-81
1-82
Module 1 Introduction
Vista Restrictions
z
Application Server version 3.1 can run under Windows Vista SP1, Windows Vista
Enterprise SP1, Windows Vista Business SP1, or Windows Vista Ultimate SP1. The
Windows Vista Home Basic and Home Premium editions are not supported. The Windows
Vista Business Edition is recommended for use with Application Server.
You must log on as a Windows Vista administrator to run Application Server version 3.1.
You cannot run Application Server as a Windows Vista standard user or power user.
The Windows Vista User Account Control (UAC) must be disabled when running
Application Server. Refer to Microsoft Windows Vista documentation for instructions to
disable UAC.
When you disable Windows Vista UAC, you must restart the computer before attempting
to install the ArchestrA IDE or Wonderware Application Server. A Galaxy connection error
occurs if you attempt to install the ArchestrA IDE or Wonderware Application Server and
you did not restart the computer after you disabled the UAC.
Windows Vista does not support a traditional Application Server single-node configuration
that includes Wonderware Historian (formerly IndustrialSQL Server).
If the computer that hosts the Galaxy Repository runs on Windows Vista, SP2 must be
applied to SQL Server 2005 installed on the same computer.
A computer running on Vista cannot be configured to be an alarm provider and also have
InTouch WindowViewer on the same computer configured to generate alarms. Only one of
the two will function properly as an alarm provider.
Windows Vista does not support NetDDE. ArchestrA Symbols that use the client layer
when accessing InTouch tags, and appear as a third-party client trying to access
WindowViewer as a data server. As a result, ArchestrA symbols cannot communicate with
InTouch tags. Windows Server 2003 and Windows XP Pro still support NetDDE.
Windows Vista security prevents started Windows services from interacting with desktop
objects. When Application Server 3.1 is installed on a computer running Vista, scripts do
not run correctly if they include the InTouch ActivateApp() and SendKeys() functions.
Windows Vista prevents these functions from interacting with desktop objects to start
Windows programs or send keystrokes to these programs.
The Domain profile is assigned automatically to a connection if a domain controller for the
domain to which the computer is a member is found on the connection.
The Public profile is designed to keep the computer from being visible to other computers
on the network. Network discovery is turned off for the Public profile.
Wonderware Training
The Private profile is used for a more trusted environment. Network discovery is turned on
for a Private profile. Firewall exceptions and rules can be created on any or all of these
profiles.
This is important because the OS Configuration utility and the Vista Firewall utility apply their
firewall exceptions to the Domain and Private profiles only.
As previously noted, you can specify which profile you want assigned to a connection as long as
that connection is not a Domain connection. This is done through the "Network and Sharing
Center". Click on the Network icon in the right side of the task bar and then click on one of the
networks that is shown. You can change a connection from a Public profile to a Private profile. The
firewall calls these settings "Profiles" but the network calls them "Location types."
On computers using dual NICs, the first NIC is normally connected to the domain and is assigned
the Domain profile automatically. The second NIC is typically assigned the Public profile.
The first issue is that your entire computer (all connections) is restricted to the most restrictive of
the profiles assigned to any connection. So if the second connection was assigned a profile of
Public, none of the firewall exceptions set by the OS Configuration or Vista Firewall utilities will be
allowed. The exceptions were set for Domain and Private only, not Public. You must set the
second connection to the Private profile for any of the firewall exceptions to work.
The second issue is that it appears that a restart of your computer, or even a restart of a computer
to which you are connected, can change your connection back to the Public profile. Once again
the firewall exceptions will not be effective. You'll have to change the connection back to the
Private profile after each restart or a restart of the connected computer.
To avoid these NIC issues and prevent the "Identifying" process from taking place on a connection
and changing the assigned profile, certain items must be present in the definition of the
connection. Follow the rules below:
1. If you have only one NIC, no action is required. The profiles and firewall rules are automatic.
2. If you have two NICs follow the actions below:
z
If the second NIC is not physically connected to anything (that means no wire in it), no
action is required. The profiles and firewall rules are automatic.
If the second NIC is connected, it MUST be configured. Follow the rules for configuring a
normal redundancy setup. Vista will identify this NIC and assign it a Private profile. If the
NIC is not configured, Vista will assign a profile of Public to this NIC and cause all of the
Wonderware product firewall exceptions to be deactivated on all NICs. For the NIC to be
configured properly, give it an IP address, sub net mask and gateway address. The
gateway address can be the same as the IP address. Usually these addresses will be the
internal, non-routable addresses like 192.168.0.x or the 10.x.x.x range.
If you have more than two NICs, make sure all connected NICs are configured with an IP
address and default gateway address and have been assigned a profile of private.
1-83
1-84
Module 1 Introduction
ActiveFactory Count
Note: Note: An Application Server Platform for a dedicated Galaxy Repository node is not
included.
The Wonderware System Platform license is available in different sizes, each one offered as a
unique combination of the following:
z
Wonderware Training
Wonderware Clients
In addition to the Wonderware System Platform, one or more of the following Wonderware
Clients are usually required:
z
InTouch for System Platform (also available as Terminal Services Edition if needed)
ActiveFactory
The InTouch for System Platform license includes an Application Server Platform and is
available in different flavors, as follows:
z
Information Server Standard Client; which lacks InTouch Write Back, InBatch and QI
Analyst integration.
The ActiveFactory license supports Terminal Services Server applications (except with a Per
Device license).
Historian Server Standard Edition limited to 24 hour data retrieval and sized by Tagcount
1-85
1-86
Module 1 Introduction
An Unlimited version of the Wonderware Development Studio license includes all the above
products, plus:
z
Information Server
ActiveFactory
InControl
The Wonderware Development Studio license is available in different sizes, each one offering a
unique combination of:
z
InTouch Tag-count
Wonderware Training
Installation
For instructions on installing Wonderware Performance Software, see the installation document
located in the root folder of the installation CD.
Additionally, refer to the Wonderware Software Installation series of online seminars where a
session corresponding to Wonderware Performance Softwqare 3.5 may be available.
Wonderware eLearning training options are located at http://www.wonderware.com/training
Product support
Wonderware provides responsive, award-winning teams of specialists committed to delivering
world-class customer support, training, and consulting services. For information on the various
customer support programs, contact your local distributor or access the Wonderware Technical
Support site online at http://www.wonderware.com/support/mmi/
You will find a variety of information on the Technical Support site including the Wonderware
Developer Network (WDN) Library, Documentation, FAQs, Tech Alerts, Tech Articles, Tech Notes,
and Tech Support Forums. When you first enter the site, you will have limited access. To gain
access to the different areas and services, you must first register.
Also on the Technical Support site is the Technical Support Policies, Terms & Conditions guide
which provides information on how to contact Technical Support, information on the support
policies and procedures, and much more.
1-87
1-88
Module 1 Introduction
Wonderware Training
Explain a project workflow and area devices and why they are needed
This section provides an explanation of the need for adequately modeling your plant in order to
achieve an application implementation that will be optimal for efficiency.
Introduction
In order to successfully implement a project for the Wonderware System Platform environment,
you should start with careful planning to come up with a working model of your plant or plant area.
A six-step project workflow is provided that describes how to complete different tasks in a logical
and consistent order, so that you minimize the engineering effort.
The project information that you define will become your guide when actually creating your
industrial application using the ArchestrA IDE. The better your project plan, the less time it will take
to create the application, and with fewer mistakes and rework.
Plan Templates
1-89
1-90
Module 1 Introduction
Before you start this process, you should determine how you want to document the results of your
project planning. One good way is to use a spreadsheet application such as Microsoft Excel to
document the list of devices, the functionality of each device, process areas to which the devices
belong, and so on.
Wonderware Training
)9
37
77
),&
)9
'5,9(
/,&
)7
&7
/7
37
)7
)9
)9
'5,9(
&7
1-91
1-92
Module 1 Introduction
Identifying Functional Requirements
For each unique device, you will need to define the functional requirements, which includes:
z
Inputs and outputs. How many inputs are required for the device? How many outputs are
required?
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
Wonderware Training
2EMHFW
2EMHFW
$WWULEXWHV
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.
Planning Templates
A template is an element that contains common configuration parameters for objects that are used
multiple times within a project. Templates are instantiated to represent specific objects within the
application.
For example, you might need multiple instances of a valve within your application, so you would
create a valve template that has all of the required properties. This allows you to define once and
reuse multiple times. If you change the template, the changes can be propagated to the instances.
You can use simple drag-and-drop within the ArchestrA IDE to create instances from templates.
Additional information on how to actually develop objects using templates is covered in Module 3,
Planning for Object Templates on page 3-5.
1-93
1-94
Module 1 Introduction
The next two steps, defining the security model, and defining the deployment model, are done
once the initial Plant Model is in place. These are steps are detailed in subsequent modules in this
training course. Please refer to additional information which is available in the Wonderware A2
Deployment Guide.
Define Security Model: Each attribute of an AutomationObject is given a security classification.
This provides the ability to define who can write to attributes of an object.
Define Deployment Model: The Deployment Model view shows which objects instances reside
on which computers. In the ArchestrA environment, the physical location of object instances is not
required to approximate the real-world environment it models. The Deployment view does not
need to reflect your physical plant environment.
Wonderware Training
Factory Layout
Your instructor will assign you a student number that you will use to create the unique identifiers
for each heat exchanger and mixer assigned to you.
This lab will help familiarize you with the plant processes on which the remaining labs are based.
Objectives
Upon completion of this lab you will be able to:
z
Use the naming convention and device structure defined for this class in subsequent labs
1-95
1-96
Module 1 Introduction
Summary Lab Instructions
Following is a summary of the general steps you will complete for this lab. For detailed
instructions, please refer to the Detailed Lab Instructions on subsequent pages.
This lab contains several intricate parts that are not easily summarized.
Please refer to the Detailed Lab Instructions on the next page.
Wonderware Training
Inlet 1: Inlet 1, which is used in conjunction with Pump 1 adds the first material into the
tank
Inlet 2: Inlet 2, which is used in conjunction with Pump 2, adds the second material into
the tank
2 pumps:
z
Pump 1: Pump 1, which is used in conjunction with Inlet 1 adds the first material into the
tank
Pump 2: Pump 2, which is used in conjunction with Inlet 2, adds the second material into
the tank
1 motor:
z
2 meters
z
1-97
1-98
Module 1 Introduction
Specifically, the devices of the mixer system are automatically operated by the simulation to
perform the steps indicated previously through the following sequence:
Throughout the execution of each batch, the LIT and TT devices will continuously indicate the
current level and temperature of the tank respectively. The temperature is in direct proportion with
the level of the tank: the higher the level, the higher the temperature, and vice versa; and it
fluctuates from 35% to 90%, within the actual range.
Note: The simulation uses randomization to ensure the LIT and TT meter values differ from batch
to batch.
Wonderware Training
1-99
1-100
Module 1 Introduction
Wonderware Training
1-101
1-102
Module 1 Introduction
Wonderware Training
Module 2
Application Infrastructure
Section 1 The Plant Model
Lab 3 Creating the Plant Model
Section 2 The Deployment Model
Lab 4 Creating the Deployment Model
Section 3 The Runtime Environment
2-3
2-5
2-13
2-15
2-25
2-29
2-39
2-49
2-2
Explain the concept and describe the need of developing a Plant Model before
configuring the Wonderware Application Server
Wonderware Training
Examine the concept of how to utilize ArchestrA Application Server to model a specific
facility
This section provides an explanation of the importance of having a model of the plant facility.
Additionally, it explains the concept of how to utilize ArchestrA Application Server to model a
specific facility.
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.
2-3
2-4
WinPlatform AutomationObjects
AppEngine AutomationObjects
Device IntegrationObjects
WinPlatforms, AppEngines and Device Integration objects do not report their alarms and events to
Area AutomationObjects even though they belong to Areas. This allows alarm clients to receive
alarm notifications without any dependencies on Area AutomationObjects. For example, a
deployed and running WinPlatform can report alarms even though its Area is not deployed and
running.
Using the Area model will become a filtering mechanism for alarms when we cover the Module on
Alarms and History.
Wonderware Training
Objectives
Upon completion of this lab you will be able to:
z
Create instances
Use the $Area object to create a plant model for the Galaxy
2-5
2-6
Discharge
Intake
Production
Line1
Line2
ControlSystem
d. Arrange the new $tArea instances to model the factory layout defined in Lab 2.
Wonderware Training
2-7
2-8
Wonderware Training
2-9
2-10
ControlSystem
Intake
Line1
Line2
Production
The ControlSystem Area will be used in this example to accommodate future system objects
created throughout the rest of this class.
Wonderware Training
2-11
2-12
Wonderware Training
This section provides an explanation of the Deployment Model and demonstrates the structure of
the Deployment Model.
deploys to
Object Viewer,
Run-time environment
Galaxy database
Templates
Instance Objects
Scripts configuration
Scripts execution
Alarms configuration
History configuration
History Logs
[Wonderware Historian]
2-13
2-14
Testing
When you are ready to deploy, make sure the following conditions are met:
z
The objects being deployed are not in an error state in the Galaxy database
The object's host is already deployed. A cascade deploy operation, which deploys a
hierarchy of objects, deploys all objects in the correct order. This deploys an object's host
before the object is deployed.
Redeploying Objects
Redeploying is similar to deployment. While you are testing, you frequently redeploy your
application to see changes you make. The redeploying process undeploys the object and then
deploys it back.
You may have an object whose deployment state is Pending Update. That means the object
changed since it last deployment. When you deploy those changes, the new object is marked as
the last deployed version in the Galaxy.
Undeploying Objects
You may need to undeploy one of more objects. Undeploying removes one or more objects from
the run-time environment.
Before you start, you need to select the object or objects you want to undeploy in the ArchestrA
IDE.
Before you delete or restore a Galaxy, undeploy all objects in the Galaxy.
Note: Undeploying can fail if the target object has objects assigned to it. Make sure you select
Cascade Undeploy in the Undeploy dialog box.
Wonderware Training
Objectives
Upon completion of this lab you will be able to:
z
Use the $WinPlatform, $AppEngine and $Area objects to create a deployment model for
the Galaxy
2-15
2-16
Wonderware Training
2-17
2-18
Note: Notice the color of the bottom right icon changes to yellow.
This indicates the
object is the first Platform, and is therefore the GR Platform. By default, the first Instance of a
platform will be the GR platform and will use its Node name.
5. Name the new instance GRPlatform.
6. In the Model view, assign the GRPlatform instance to the ControlSystem area.
Wonderware Training
10. Using the Template Toolbox and the Model view, create a new instance of the $tAppEngine
template.
2-19
2-20
12. In the Model view, assign the AppEngine instance to the ControlSystem area.
Wonderware Training
2-21
2-22
The Deploy dialog box displays. By default the system will perform a Cascade Deploy with a
Deploy Object Count of 8 instances, and it will set all instances On Scan as soon as the objects
are deployed.
Wonderware Training
2-23
2-24
Wonderware Training
Illustrate the differences in the Development environment and the Runtime environment
Explain the use of the Object Viewer in monitoring the Runtime environment
This section provides an explanation of the Runtime environment and explains the use of the
Object Viewer in monitoring the Runtime environment.
Runtime Environment
The previous workflow task defined the deployment model that specifies where objects are
deployed. In other words, the deployment model defines which nodes will host the various
AutomationObjects.
The objects deployed on particular platforms and engines define the objects' load on the
platform. The load is based on the number of I/O points, the number of user-defined attributes
(UDAs), and so on. The more complex the object, the higher the load required to run it.
After deployment, the Runtime environment facilitates the activity generated by the objects. In
Application Server the Object Viewer is used to monitor the Runtime environment. The Object
Viewer is used to check communications between nodes and determine if the system is running
optimally. For example, a node may be executing more objects than it can easily handle, and it will
be necessary to deploy one or more objects to another computer.
To view the activity in the Runtime database the Object Viewer is used. It displays the current
value of all of the objects and object attributes in the database. In order to create the Runtime
database, Application Server requires information about all of the variables being created. As
object and object attribute values change (for example created, value change, configuration
change), the changes are reflected in Runtime and monitored via the Object Viewer.
Object Viewer
The Object Viewer monitors the status of the objects and their attributes and can be used to
modify an attribute value for testing purposes.
To add an object to the Object Viewer Watch list, right-click the attribute from the Attribute Name
panel and select Add to Watch.
You can save a list of items being monitored. Once you have a list of attributes in the Watch
Window, you can select all or some of them and save them to an XML file by right-clicking on the
Watch window and selecting Save. A previously saved Watch window can also be loaded to
monitor previously saved attributes. You can also add a second Watch window that shows as a
separate tab in the bottom of the Viewer.
2-25
2-26
Attributes section
Individual attributes of the object.
Checked in
Objects whose configuration are successfully uploaded have a new version number and a change
log entry for the upload operation. The run-time objects version number also has a new version
number. That version number matches the version in the configuration database.
Wonderware Training
2-27
2-28
Wonderware Training
Objectives
Upon completion of this lab you will be able to:
z
2-29
2-30
Using ObjectViewer
a. Open Object Viewer from within the ArchestrA IDE.
b. Rename the default watch window to Platform Info and add the following attribute references:
Instance
Attribute Name
GRPlatform
CPULoad
GRPlatform
DiskSpaceFree[1]
GRPlatform
RAMAvailableAvg
c. Create a new watch window called Engine Info and add the following attribute references:
Instance
Attribute Name
AppEngine
Scheduler.ScanPeriod
AppEngine
ScanState
AppEngine
ScanStateCmd
d. Save the watch list to your training folder (C:\Wonderware Training) with the name My
Watch Windows.
Wonderware Training
Using ObjectViewer
1. In Model view, open Object Viewer by right-clicking the GRPlatform instance and selecting
View in Object Viewer.
2-31
2-32
Attributes section.
Individual attributes of the object.
2. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to
rename the default Watch List 1 tab.
Wonderware Training
4. Click OK.
5. The tab is now labeled Platform Info.
2-33
2-34
Wonderware Training
DiskSpaceFree
When prompted, enter 1 as the array index which represents drive C
RAMAvailableAvg
8. Right-click in the Watch List (bottom section of Object Viewer) and select Add Watch
Window to add a new tab to the watch list.
2-35
2-36
Wonderware Training
Scheduler.ScanPeriod
ScanState
ScanStateCmd
13. Right-click in the Watch List (bottom section of Object Viewer) and select Save As to save
the watch list to disk.
2-37
2-38
15. Click Save to save the watch list to the selected location.
Wonderware Training
Become familiar with Device Integration Objects, I/O Server and Data Access Server
Overview of DI Objects
This section provides an understanding of the Device Integration Objects, I/O Server and DA
Server. It also provides an overview of DI Objects.
Introduction
The server application provides the data and accepts requests from any other application
interested in its data. Requesting applications are called clients. Some applications such as
InTouch and Microsoft Excel can simultaneously be both a client and a server.
2-39
2-40
Value Time Quality (VTQ) places a time stamp and quality indicator on all data values
delivered to VTQ-aware clients.
The network transport protocol is TCP/IP using Microsofts standard Winsock interface.
To use the SuiteLink Communication Protocol, the following conditions must be satisfied.
z
You must use computer names (Node Names) of no more than 15 characters.
For more information on installing and configuring Microsoft TCP/IP, see your
Microsoft Windows operating system's documentation.
Wonderware SuiteLink must be running as a service. If for some reason SuiteLink has
been stopped, you will need to start it again. (SuiteLink is automatically installed as a
Common Component when you install InTouch. It is configured to startup
automatically as a Windows Service).
Wonderware Training
2-41
2-42
DDESuiteLinkClient
The DDESuiteLinkClient object is a key member of the core set of AutomationObjects within the
ArchestrA system infrastructure. The DDESuiteLinkClient object is a DeviceIntegration object that
allows access to a running I/O Server. A DDE or SuiteLink I/O Server can provide data points to
Galaxy application objects through the DDESuiteLinkClient object.
Note: The DDESuiteLinkClient object is compatible with all Wonderware I/O Servers and
components.
There is a one-to-one relationship between an instance of the DDESuiteLinkClient object and a
running I/O Server. If you want to reference data points in more than one I/O Server, you must
configure and deploy more than one DDESuiteLinkClient object. For example, you would need to
configure one DDESuiteLinkClient object to communicate to an TCP I/O Server and another one
to talk to the GEHCS I/O Server.
When you configure the DDESuiteLinkClient object, you can specify one or more I/O Server topics
to which access is required. At run time, all items that the Galaxy application requires for a
Wonderware Training
OR
<objectname>.<topicname>.<attributename>
The <objectname> is the name that you choose to give to the DDESuiteLinkClient object.
Each I/O topic for a DDESuiteLinkClient object is also known as a "scan group." Run-time object
attributes allow you to monitor errors related to the data quality for item values in a scan group.
InTouchProxy
The InTouchProxy Object is a gateway between Galaxy application objects and data that is
available through an InTouch application. The InTouchProxy object allows you to browse a
selected InTouch application tagname dictionary, add selected tags as attributes in the Galaxy
application, then read these attributes from the InTouch application at run time.
Note: Before using the tagname browser to browse for tags, make sure that InTouch
WindowMaker is not running on the InTouch node. WindowViewer, however, can be running. Also,
be sure that you have given share permission of Read to the InTouch folder that contains the
Tagname.X file.
The InTouchProxy object is a key member of the core set of AutomationObjects within the
ArchestrA system infrastructure. The InTouchProxy object is a DeviceIntegration object that
represents a running InTouch node. The InTouch node effectively serves as the data provider
(supporting the SuiteLink communication protocol) by providing data points to Galaxy application
objects through the InTouchProxy object.
Note: This object is compatible with InTouch v7.11 and later applications.
There is a one-to-one relationship between an instance of the InTouchProxy object and a running
InTouch node. An InTouch "node" is a unique combination of the computer name and InTouch
application. If you want to reference data points in more than one InTouch node, you must
configure and deploy more than one InTouchProxy object. For example, you would need to
configure one InTouchProxy object to get data from an InTouch application running on Computer1
and another one to get data from an InTouch application running on Computer2.
When you configure the InTouchProxy object, you might want to specify one or more existing
InTouch tagnames (items) to use as object attributes. At run time, if these attributes are added in
the client (for example, the Object Viewer watch window), they are updated with the latest values
from the InTouch items. InTouch sends a new data value for an item to the InTouchProxy object
2-43
2-44
The <objectname> is the name that you choose to give to the InTouchProxy object.
The group of specified InTouch items for an InTouchProxy object is also known as the "scan
group." Only one scan group exists in the InTouchProxy object. Run-time object attributes within
the scan group allow you to monitor errors related to the data quality for InTouch item values in a
scan group.
OPCClient
The OPCClient object is a key member of the core set of AutomationObjects within the ArchestrA
system infrastructure. The OPCClient object is a DeviceIntegration (DI) object that allows access
to a running OPC Data Access (DA) Server. A third-party OPC DA Server can provide data points
to Galaxy application objects through the OPCClient object.
Note: The OPCClient object is compatible with all OPC Servers that are compliant with OPC Data
Access v2.05 or later standards.
There is a one-to-one relationship between an instance of the OPCClient object and a running
OPC DA Server. If you want to reference data points in more than one OPC DA Server, you must
configure and deploy more than one OPCClient object. For example, you would need to configure
one OPCClient object to communicate to an TCP OPC Server and another one to talk to the CIP
OPC Server.
An OPCClient object supports the following operations on I/O points for the OPC DA Server:
z
Subscriptions, which are implemented via scan groups. Read transactions, which are
implemented via block reads.
Note: If you are using this object to communicate with an OPC DA Server, you must properly
configure the OPC DA Server before deploying this object.
RedundantDIObject
The RedundantDIObject provides you with the ability to configure a single object with connections
to two different data sources (proxy objects or DIDevice objects). In the event of a failure of the
active data source, this object automatically switches to the standby data source.
This capability allows clients to configure redundant connections to a field device.
The RedundantDIObject is a DeviceIntegration object that makes redundant connections to a field
device possible. If one of the source objects is unable to provide connection to the field device, the
RedundantDIObject automatically switches to the other source object for continued data
acquisition.
The way the RedundantDIObject determines that a data source is in Bad state by monitoring the
ConnectionStatus attribute common to all DIObjects, the ProtocolFailureReasonCode attribute
that reflects a failure in communication by a DAS DIObject with a field device, and the ScanState
attribute common to all ApplicationObjects. When those attributes are, respectively, Disconnected,
Wonderware Training
Subscriptions, which are implemented via scan groups. Read transactions, which are
implemented via block reads (when available in the source DIObject). Write transactions,
which are implemented via block writes (when available in the source DIObject).
Note: Most ApplicationObjects in the ArchestrA environment write only the last data received in a
scan cycle. DeviceIntegrationObjects, including the RedundantDIObject, operate differently. They
queue all data received in a scan cycle and write them all in the order received.
The two source DIObjects do not have to be the same type. But they must support the same type
of DAGroups and must have the same item address space.
Note: The RedundantDIObject checks the state of its source DIObjects on every scan cycle.
Note: During configuration, one DIObject is set as the Primary DI source and the other is set as
Backup DI source. These are just the starting points. During runtime, the terms Active and
Standby apply, the configured Primary object initially being the Active object (if able to provide
connection to the field device) and the configured Backup object initially being the Standby. If the
connection to the Active object fails, then the Standby becomes the Active one and the other
becomes the Standby. This switching between Active and Standby objects can be repeated
multiple times depending on the configured switch attributes.
For complete redundancy coverage, the RedundantDIObject must be configured to have the
DAGroups that are common to both source DIObjects. When the connection fails to the Active
DIObject, all items are unsubscribed from the Active DIObject and new subscriptions are made to
the Standby DIObject. If either DIObject has unique DAGroups, it is important that the
RedundantDIObject should not be configured to use those uncommon DAGroups.
RedundantDIObjects belong to a family of objects called DINetwork objects.
Scan Mode
The scanning mode for the scan group, either ActiveOnDemand, Active, or ActiveAll. For the
ActiveOnDemand mode, attributes that are not actively being referenced by any client or object
are not scanned. For the Active mode, an attribute is always in the active scanning state. When
the last reference to the attribute is unregistered (unadvised), the attribute is deleted. For ActiveAll,
an attribute is always in the active scanning state, but when the last reference to the attribute is
unregistered (unadvised), the attribute is not deleted.
To enable Advanced Communication Management, you must:
z
2-45
2-46
Set the scan mode for each scan group that belongs to your device integration objects
within the Galaxy.
I/O Server
Different I/O data sources have different requirements. Two main groups are identified:
z
Legacy I/O Server applications (SuiteLink, DDE, and OPC Servers) do not require a
platform on the node on which they run. They can reside on either a standalone or
workstation node.
However, the DI Objects used to communicate with those data sources such as the
DDESuiteLinkClient object, OPCClient object, and InTouchProxy objects must be
deployed to an AppEngine on a Platform. Although it is not required that these DI Objects
be installed on the same node as the data server(s) they communicate with, it is highly
recommended in order to optimize communication throughput.
For Device Integration objects like CIP and TCP DINetwork objects, both the DAServer
and the corresponding DI Objects must reside on the same computer hosting an
AppEngine.
I/O Servers can run on Workstations, provided the requirements for visualization processing, data
processing, and I/O read-writes can be easily handled by the computer. Run the I/O Server and
the corresponding DI Object on the same node where most or all of the object instances (that
obtain data from that DI Object) are deployed.
This implementation expedites the data transfer between the two components (the I/O Server and
the object instance), since they both reside on the same node. This implementation also minimizes
network traffic and increases reliability.
However, it is good practice to evaluate the overhead necessary to run each
Support for hot configuration, device additions and device- and server-specific parameter
modifications
A wide range of DA
Wonderware Training
The DAServer is like a driver: it can receive data from different controllers simultaneously. For
example, a DAServer might use OPC to access data remotely in one machine, and use InTouch to
communicate with another machine. When a DAServer transfers data, it also transfers a
timestamp and quality codes.
The DAServer is flexible enough to be used in a variety of topologies, but some topologies are
more efficient than others.
For example, the DAServer can connect to the OPC Server directly across the network, or
FactorySuite Gateway can be placed on the same machine as the OPC DAServer and SuiteLink
can be used to link the server to devices. Of the two topologies, using FactorySuite Gateway is
more efficient than connecting the DAServer directly to the OPC Server.
OPC DAServer technology also has drawbacks; for instance, data may be lost briefly without the
user realizing the loss has occurred.
2-47
2-48
Wonderware Training
Objectives
Upon completion of this lab you will be able to:
z
2-49
2-50
d. On the Topic tab, add a topic called tagname and import the InControl Items List.csv file
from the C:\Wonderware Training folder.
e. In Model view, assign the InControl instance to the ControlSystem area.
In Deployment view, assign the InControl instance to the AppEngine object and deploy the
object.
i.
ConnectionStatus
Reconnect
ServerNode
ServerName
CommunicationProtocol
Wonderware Training
2-51
2-52
Wonderware Training
Server node: <ask your instructor>. The following figure uses TRAININGPC as an
example.
2-53
2-54
Wonderware Training
14. Click the Save and Close button and check in the object.
2-55
2-56
Wonderware Training
21. The Deploy dialog box is displayed. By default the system will set the instance On Scan as
soon as the object is deployed.
2-57
2-58
23. Click the Close button to return to the ArchestrA IDE. The different views now display the
instance in its deployed state.
Wonderware Training
25. The Object Viewer application opens to display the attributes of the selected object in the
right panel.
26. If you closed Object Viewer, open your watch list by right-clicking the Watch List (bottom
section of Object Viewer) and select Open to open the My Watch Windows file.
27. Right-click in the Watch List and select Add Watch Window to add a new tab to the watch
list.
28. Right-click in the Watch List and select Rename Tab to rename the default Watch List 1 tab.
29. The Rename Tab dialog box is displayed. Name the new tab InControl.
2-59
2-60
ConnectionStatus
CommunicationProtocol
Reconnect
ServerName
ServerNode
Wonderware Training
Module 3
Application Objects
Section 1 Templates and Instances
3-3
3-9
3-11
3-25
3-27
3-35
3-37
3-41
3-45
3-61
3-67
3-2
Wonderware Training
Introduces you to the concept of templates and explain how to derive a template.
This section introduces you to the concept of templates and explain how to derive a template.
Templates
One of the major benefits of Application Server is that it allows you to re-use existing engineering.
Working with templates is the best way to illustrate such capability.
A template is an entity that represents the common functional requirements of a field device
(valves, pumps), a group of field devices (skids, stations), or a user function (algorithms). These
requirements reflect information such as number of Inputs and Outputs, alarm conditions, history
needs, and security. One object template performs the equivalent functions of multiple InTouch
tags and scripts.
A template is created either from a base template or from another derived template. Base
templates are the objects provided with the Application Server. Base templates cannot be
modified.
Note: You should avoid creating instances directly from base templates, since you will not be able
to take advantage of advanced configuration and maintenance capabilities.
Templates are high-level definitions of the devices in your environment. Templates are like a
cookie cutter from which you can make many identical cookies.
You define a template for an object, like a valve, one time and then use that template when you
need to define another instance of that item. Template names have a dollar sign ($) as the first
character of their name.
A template can specify application logic, alarms, security, and historical data for an object.
A template can also define an area of your environment. You can extend and customize a
template by adding User Defined Attributes (UDAs), scripts, or extensions to meet the specific
needs of your environment. Objects inherit attributes from their parents.
Wonderware Application Server comes with predefined templates, called base templates. You
cannot change these templates. All templates you create are derived from base templates.
You can also nest templates, or contain them. Contained templates consist of nested object
templates that represent complex devices consisting of smaller, simpler devices, including valves.
A reactor is a good candidate for containment.
Templates only exist in the development environment.
3-3
3-4
Instances
Instances are the run-time objects created from templates in Wonderware Application Server.
Instances are the specific things in your environment like processes, valves, conveyer belts,
holding tanks, and sensors. Instances can get information from sensors on the real-world device
or from application logic in Wonderware Application Server. Instances exist during run time.
In your environment, you may have a few instances or several thousand. Many of these instances
may be similar or identical, such as valves or holding tanks. Creating a new valve object from
scratch when you have several thousand identical valves is time-consuming. That's where
templates come in.
Propagation
If you need to change something about all diaphragm valves, you can change the template for the
diaphragm valve and all diaphragm valves in your application inherit the changes, assuming the
attributes are locked in the parent template. This makes it easy to maintain and update your
application.
Wonderware Training
Wonderware Application Server is shipped with a number of pre-defined templates to help you
create your application quickly and easily. Review these templates and determine if any of their
functionality match the requirements of the devices on your list. If not, you can create (derive) new
templates from the supplied UserDefined templates.
For your project planning, document which existing template can be used for which objects, and
what templates you will need to create yourself.
A child template that you derive from a parent template can be highly customized. You can
implement user-defined attributes (UDAs), scripting, and alarm and history extensions.
3-5
3-6
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
3-7
3-8
Wonderware Training
This section introduces you to the $UserDefined object and its functionality.
$UserDefined Object
The UserDefined object provides the basic functionality you need to develop an ArchestrA
supervisory application. The UserDefined object provides this functionality as Field Attributes,
scripts, User Defined Attributes (UDAs), and attribute extensions.
You can configure Field Attributes as an Analog or Discrete type with one of the following access
modes:
z
Input. The Field Attribute only accepts input. The Field Attribute is updated based on the
value that is read from the configured input address.
InputOutput. The Field Attribute accepts input and sends output. The output destination
can optionally differ from the input source address. The InputOutput mode supports the
User writeable and Object writeable attribute categories.
Output. The Field Attribute only sends output. The Field Attribute writes to the specified
output destination. The Output mode supports the following categories:
Calculated
Calculated retentive
User writeable
Object writeable
Note: We recommend you do not extend the Field Attribute value with an Input, InputOutput, or
Output extension. If the value is extended, unstable behavior with the Field Attribute value will
occur.
The Analog Field Attribute supports the following data types:
z
Integer
Float
Double
The Analog Field Attribute provides the enabling and configuration for the following functionality:
z
History
Statistics
3-9
3-10
State Labels
History
State Alarm
Statistics
The UserDefined object is an object that you can use to create customized objects. You can use
the UserDefined object as a template, or as a container.
As a template
Use the UserDefined object as a template containing Field Attributes associated to multiple
variables in a system. In this case, the object provides a simple and manageable structure as
all the variables are contained in the same object.
For example, you might create a UserDefined object called Tank and configure Field
Attributes that represent variables associated to the tank system:
z
LT100 - Analog Field Attribute - Input from a level transmitter configured with options
such as: Scaling, Limit alarms and Statistics (Min/Max/Avg).
TT100 - Analog Field Attribute - Input from a temperature transmitter configured with
options such as Rate of Change alarm and Statistics (Min/Max/Avg).
SW100a - Discrete Field Attribute - Input from a limit switch configured with options
such as State Labels and State alarm.
SW100b - Discrete Field Attribute - Input from a limit switch configured with options
such as State Labels and State alarm.
References between attributes in the object can be accomplished by using relative reference,
for example:
The Tank can be customized to raise an alarm when both XV100a and XV100b valves are
open. For example, you can add a Boolean UDA called ValueOpenAlarm, extend it with an
Alarm Extension, and then add the following OnExecute script:
IF me.XV100a == "Open" AND me.XV100b == "Open" THEN
me.ValueOpenAlarm = true;
ELSE
me.ValueOpenAlarm = false;
ENDIF;
As a container
Use the UserDefined object as a container for other objects. An object relationship in which
one object is comprised of other objects is called containment. Containment allows you to
group various objects together to make complex objects.
Wonderware Training
Objectives
Upon completion of this lab you will be able to:
z
Configure and use object templates to create instances that will inherit configurations
Use the Galaxy Browser to build references to instance attributes within the Galaxy
3-11
3-12
Input
Data type:
Float
Engineering units:
Deg F
checked
4095.0
EU value - Maximum:
250.0
-5.0
255.0
Instance
Attribute Name
T1
InControl
tagname.HE1XX_TC1
T2
InControl
tagname.HE1XX_TC2
T3
InControl
tagname.HE1XX_TC3
T4
InControl
tagname.HE2XX_TC3
g. Using the watch list created in Lab 5, add a new watch window named HeatEx with the
following attributes from the HeatEx_001 instance:
z
T1
T2
T3
T4
Wonderware Training
3-13
3-14
Wonderware Training
T1
Access mode:
Input
Data type:
Float
Engineering units:
Deg F
checked
4095.0
EU value: Maximum:
250.0
-5.0
255.0
3-15
3-16
10. The Check In dialog box appears. Enter Initial configuration and setup in the Comment
field.
Wonderware Training
3-17
3-18
Wonderware Training
23. Repeat steps 17 through 22 to configure the Input source for attributes T2, T3 and T4 using
the tagname.HE1XX_TC2, tagname.HE1XX_TC3 and tagname.HE1XX_TC4 attributes.
24. Click the Save and Close button
25. The Check In dialog box appears. Enter Initial configuration and setup in the Comment
field.
3-19
3-20
Wonderware Training
3-21
3-22
Wonderware Training
32. Right-click in the Watch List (bottom section of Object Viewer) and select Add Watch
Window to add a new tab to the watch list.
33. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to
rename the default Watch List 1 tab.
The Rename Tab dialog box is displayed.
34. Enter HeatEx for the Tab Name field and click OK.
3-23
3-24
T1
T2
T3
T4
You will observe the attribute values changing in real time. The Quality attribute should reflect
Good data.
36. Right-click in the Watch List (bottom section of Object Viewer) and select Save to save the
watch list.
Wonderware Training
This section presents the concept of attribute locking and provides an illustrations on how locking
attributes can propagate to previously derived instances.
Locking an attribute in a Template indicates that its value is to be logically shared with all derived
objects (Templates or instances). In other words, when the value changes in the template, that
change is propagated to all the derived children of the object. When an attribute is locked in the
Template, the value can be changed in that Template but not in any of the derived children.
Based on this concept, an attribute can have one of three logical lock types:
z
Unlocked: Both Templates and instances can have these. Attribute is read-write. The
object has its own copy of the attribute value and is not shared by derived objects.
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 readonly. 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
3-25
3-26
Unlocking an Attribute
To unlock a Template attribute, do the following:
a. Select the desired Template in the ArchestrA IDE and start its editor.
b. Select the locking mechanism for the locked attribute in the 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.
c. Save and close the object editor.
The previously locked attribute in any instances created from this template are now unlocked. The
previously locked attribute in any templates derived from this template are still Locked (in me). The
previously locked attribute in any instances of derived templates remain in Locked in Parent.
Wonderware Training
Objectives
Upon completion of this lab you will be able to:
z
Lock attributes in templates to control the changes that can be made on derived objects
Propagate changes from templates to derived object by modifying the value of locked
attributes
3-27
3-28
Scaling section:
locked
Wonderware Training
3-29
3-30
Scaling section:
locked
Note: You may need to expand the Enable I/O scaling section. Click the
section.
Wonderware Training
3-31
3-32
The Deploy dialog box appears. Notice by default Deploy Changes is selected, indicating only
the objects with changes will be deployed.
Wonderware Training
3-33
3-34
Wonderware Training
Introduces you to the concept of the $AnalogDevice object and its functionality.
This section introduces you to the concept of the $AnalogDevice object and its functionality.
$AnalogDevice Object
The AnalogDevice object is an ApplicationObject that can be configured as either a basic analog
device, or an analog regulator device. When configured as a basic analog device, the
AnalogDevice object follows the traditional model of a basic analog input/output object with
alarming and history. When configured as an analog regulator device, the AnalogDevice object
provides an external model of a PID controller that exists in a field device, in addition to providing
the traditional analog alarming and history capabilities.
z
The process value (PV) is read from the field (except when the AnalogDevice object is
configured to be in Manual mode).
You can configure the AnalogDevice object to enable or disable analog output. If you
enable output, you can configure the output destination address to be the same (default)
or different from the input source address. Commands to change the PV will result in an
output to field. For data integrity, the value of PV represents the value read from the
external controller (except when the AnalogDevice object is in Manual mode), not the
requested PV that is output to the external controller.
The input and outputs can be optionally scaled between raw counts and engineering unit
values using either linear or square-root conversions.
The AnalogDevice object supports alarming for PV conditions, such as when the PV:
z
In addition, you can configure the AnalogDevice object to allow or disallow the overriding of the PV
value. If you enable the PV override, then you can use the PV.Mode attribute to place the
AnalogDevice object into either Auto or Manual mode. When the AnalogDevice object is in Auto
mode, the PV is updated from the field and matches the value and quality of the PVAuto attribute.
When the AnalogDevice object is in Manual mode, the PVAuto attribute continues to be updated
from the field, but the PV value does not. Instead, the PV can be set by a user write or a script, and
the quality is always set to UNCERTAIN.
Finally, you can configure the AnalogDevice object to historize key variables, including PV and
PV.Mode.
3-35
3-36
The process value (PV) is read from the field (except when the AnalogDevice object is
configured to be in Manual mode), but is never written.
The SP value is both read from the field and written to the field. You can configure the SP
output destination address to be the same (default) or different from the input source
address. Commands to change SP result in an output to field. For data integrity, the value
of SP always represents the value read from the external controller, not the requested SP
that is output to the external controller.
The PV and SP can be optionally scaled between raw counts and engineering unit values
using either linear or square-root conversions.
The AnalogDevice object supports alarming for PV conditions, including when the PV:
z
In addition, you can configure the AnalogDevice object to allow or disallow the overriding of the PV
value. If you enable the PV override, then you can use the PV.Mode attribute to place the
AnalogDevice object into either Auto or Manual mode. When the AnalogDevice object is in Auto
mode, the PV is updated from the field and matches the value and quality of the PVAuto attribute.
When the AnalogDevice object is in Manual mode, the PVAuto attribute continues to be updated
from the field, but the PV value does not. Instead, the PV can be set by a user write or a script, and
the quality is always set to UNCERTAIN.
Other controller-oriented features that can be configured for an AnalogDevice object of type
analog regulator include:
z
Controller mode (CtrlMode attribute). You can use the controller mode to govern what
types of writes are allowed to the SP value within the system. Controller mode options are
Manual, Cascade, and None. When the object is in Manual mode, only end users are
allowed to command a change in the value of SP. In Cascade mode, only scripts or other
supervisory objects are allowed to command a change to SP. Finally, if None is specified
for the controller mode, any type of write is allowed for the SP.
Control tracking. A Boolean control track flag can be read from an external device or
object. When tracking is on, the external controller "owns" the value of the SP; the SP is
purely read-only and cannot be commanded to be changed and output to the field.
Wonderware Training
Objectives
Upon completion of this lab you will be able to:
z
3-37
3-38
Analog (locked)
Unchecked (locked)
Enable PV override:
Unchecked (locked)
checked (locked)
0.0 (locked)
4095.0 (locked)
Conversion mode:
Linear (locked)
unchecked (locked)
Wonderware Training
2. Name the new template $Meter and move it to the Training template toolset.
3-39
3-40
Analog (locked)
Unchecked (locked)
Enable PV override:
Unchecked (locked)
checked (locked)
0.0 (locked)
4095.0 (locked)
Conversion mode:
Linear (locked)
unchecked (locked)
5. Click the Save and Close button and check in the object.
Wonderware Training
Introduces you to the concept of the $DiscreteDevice object and its functionality.
This section introduces you to the concept of the $DiscreteDevice object and its functionality.
$DiscreteDevice Object
The DiscreteDevice object is a general purpose ApplicationObject that represents a large class of
physical equipment common in manufacturing, such as pumps, valves, motors, and conveyors.
These devices have two or more discrete physical states (for example, Open, Closed, and
Moving). The actual state of a device is monitored using a combination of discrete inputs, and a
device can be optionally controlled using a combination of discrete outputs.
The state names are configurable and are mapped to both input and output Boolean combinations
in truth-table form. The meaning of the states depends on the type of discrete device. For a pump,
the states might be configured as "Off" and "On," while for a valve they might be configured as
"Open," "Closed," and "Moving." Note that a control valve has a continuous position represented
by an analog signal of 0 to 100% and is not properly represented with a discrete device. Control
valves are best represented with the AnalogDevice object.
When a DiscreteDevice object is commanded to a new state, it sets the configured combination of
discrete outputs for that state. When one or more of its monitored discrete inputs change, the
DiscreteDevice object determines the new actual state of the equipment and sets the process
value (PV) appropriately.
Input and output states are totally independent of each other and can be configured as required by
your application; however, the input and output states can be linked by alarms. This allows the
object to detect a command timeout and uncommanded change alarms when devices
unexpectedly change, or fail to change when commanded to do so.
Historization of key attributes including the current state (PV) and commanded state (Cmd) can
also be configured.
Finally, the DiscreteDevice object supports a rich set of statistics reporting that you can enable
during configuration.
Passive
The passive state represents the state of the discrete device when it is idle, stopped, or
closed (the typical non-running position). For example, the passive state for a motor might
be "Off."
First Active
The first active state (Active1) represents the state of the discrete device when it is
considered to be running. For example, the active state for a motor might be "Forward."
You can use outputs to control the first active state.
3-41
3-42
(Optional) Some discrete devices have more than one active state. For example, a motor
might have a second active state of "Backward." You can use outputs to control the
second active state (Active2).
Transition
(Optional) The discrete device is in a transition state any time it is changing from one valid
state to another. For example, if you have a valve with a passive state of "Off" and an
active state of "On," the transition state might be "Moving."
Fault
The fault state occurs when the feedback that is coming from the field is incorrect or
impossible based on how the discrete device works. For example, a fault would occur if
the Hi and Lo limit is being reached at the same time for a single device. Examples of fault
state names are "Error," "Bad," or "Broken."
Valve_Close
Mapped State
Transition
Closed
Opened
Bad
where:
1=TRUE
0=FALSE
By default, when the monitored discrete inputs change, the DiscreteDevice object determines the
new actual state of the equipment and updates the value of the process value (PV) appropriately.
You can configure the DiscreteDevice object to allow or disallow overriding of the PV value. If you
enable the PV override, then the object can be placed in Auto, Manual, or Simulate modes using
the PVMode attribute.
z
When the object is in Auto mode, the PV updates from the field and matches the value
and quality of PVAuto.
When the object is in Manual mode, PVAuto continues to update from the field but the PV
does not. Instead, the PV can be set by a user or script and the quality is always marked
as UNCERTAIN.
Wonderware Training
When the object is in Simulate mode, the PV value is set equal to the Cmd value, rather
than read from the field.
A configurable control mode. The control mode (Manual or Cascade) determines what
types of writes are allowed to the Cmd value within the system. Manual indicates that only
users (operators) are allowed to request a change to Cmd, whereas Cascade indicates
that only scripts or other supervisory objects are allowed to request a change to Cmd.
Control tracking. A Boolean control track flag can be read from an external device or
object. When tracking is on, the external controller "owns" the value of the Cmd; the Cmd
is purely read-only and is set to the value of PV.
Alarm Capabilities
The DiscreteDevice object provides sophisticated alarming capabilities, including:
z
Command timeout alarm, which indicates that the PV state did not change to match the
Cmd state within a configurable timeout period.
Uncommanded change alarm, which indicates that the PV state changed from the
expected Cmd state to some other state and the quality of PV is GOOD or UNCERTAIN
(not BAD).
Individual alarms for each of Active1, Active2, and Fault state conditions.
Duration alarms for each of Active1 and Active2 states, indicating the discrete device has
been in the state for too long of a time period.
Statistical Features
The DiscreteDevice object offers advanced built-in state tracking calculations that can be used for
equipment monitoring and time-in-use tracking, including:
z
The most recent time durations of the Active1, Active2 and Passive states.
The total accumulated time durations of the Active1, Active2 and Passive states, with
optional alarming on the Active1 and Active2 total durations.
The number of transitions into the Active1, Active2 and Passive states.
3-43
3-44
Wonderware Training
Objectives
Upon completion of this lab you will be able to:
z
3-45
3-46
Checked (locked)
Enable outputs:
Checked (locked)
Unchecked (locked)
Checked (locked)
State names:
(locked)
Passive state:
Closed
Open
Transition state:
Traveling
Fault state:
Fault
2 (locked)
Input Name:
(locked)
CLS
OLS
Input to PV Map:
(locked)
0 0: Traveling
0 1: Open
1 0: Closed
1 1: Fault
PV override:
(locked)
1 (locked)
Output Name:
(locked)
CmdOpen
Closed:
Unchecked (locked)
Open:
Checked (locked)
Manual (locked)
Control tracking:
(locked)
Wonderware Training
Derived a new template from the $DiscreteDevice object, name it $Pump, and assign it to the
Training template toolset.
Checked (locked)
Enable outputs:
Checked (locked)
i.
Unchecked (locked)
Unchecked (locked)
State names:
(locked)
Passive state:
Stopped
Running
Fault state:
Fault
1 (locked)
Input Name:
(locked)
FlowSwitch
Input to PV Map:
(locked)
0: Stopped
1: Running
PV override:
j.
(locked)
1 (locked)
Output Name:
(locked)
CmdStart
Stopped:
Unchecked (locked)
Running:
Checked (locked)
Manual (locked)
Control tracking:
(locked)
3-47
3-48
Checked (locked)
Enable outputs:
Checked (locked)
Unchecked (locked)
Unchecked (locked)
State names:
(locked)
Passive state:
Stopped
Running
Fault state:
Fault
1 (locked)
Input Name:
(locked)
AuxContact
Input to PV Map:
(locked)
0:
Stopped
1:
Running
PV override:
(locked)
1 (locked)
Output Name:
(locked)
CmdStart
Stopped:
Unchecked (locked)
Running:
Checked (locked)
Manual (locked)
Control tracking:
(locked)
Wonderware Training
Checked (locked)
Enable outputs:
Checked (locked)
3-49
3-50
Unchecked (locked)
Checked (locked)
State names:
(locked)
Passive state:
Closed
Open
Transition state:
Traveling
Fault state:
Fault
Wonderware Training
2 (locked)
Input Name:
(locked)
CLS
OLS
Input to PV Map:
(locked)
0 0:
Traveling
0 1:
Open
1 0:
Closed
1 1:
Fault
PV override:
(locked)
3-51
3-52
1 (locked)
Output Name:
(locked)
CmdOpen
Closed:
Unchecked (locked)
Open:
Checked (locked)
Manual (locked)
Control tracking:
(locked)
9. Click the Save and Close button and check in the object.
Wonderware Training
Checked (locked)
3-53
3-54
Unchecked (locked)
Unchecked (locked)
State names:
(locked)
Passive state:
Stopped
Running
Fault state:
Fault
Wonderware Training
1 (locked)
Input Name:
(locked)
FlowSwitch
Input to PV Map:
(locked)
0:
Stopped
1:
Running
PV override:
(locked)
3-55
3-56
1 (locked)
Output Name:
(locked)
CmdStart
Stopped:
Unchecked (locked)
Running:
Checked (locked)
Manual (locked)
Control tracking:
(locked)
17. Click the Save and Close button and check in the object.
Wonderware Training
Checked (locked)
3-57
3-58
Unchecked (locked)
Unchecked (locked)
State names:
(locked)
Passive state:
Stopped
Running
Fault state:
Fault
Wonderware Training
1 (locked)
Input Name:
(locked)
AuxContact
Input to PV Map:
(locked)
0:
Stopped
1:
Running
PV override:
(locked)
3-59
3-60
1 (locked)
Output Name:
(locked)
CmdStart
Stopped:
Unchecked (locked)
Running:
Checked (locked)
Manual (locked)
Control tracking:
(locked)
25. Click the Save and Close button and check in the $Motor template.
Wonderware Training
Section 6 Containment
Section 6 Containment
Section Objectives
This section illustrates the concept of containment and how it works with Application Objects and
Templates.
This section illustrates the concept of containment and how it works with Application Objects and
Templates.
Tagnames
Contained Name
Hierarchical Name
Name
Description
Tagname
Contained Name
The name of the object within the context of its container object. For
example, the object whose Tagname is Valve1 may also be referred to
as Tank1.Outlet, if Tank1 contains it and it has the contained name
"Outlet".
Hierarchical Name
3-61
3-62
ApplicationObject Containment
ApplicationObjects can be contained by other ApplicationObjects. This provides context for the
contained object and a naming hierarchy that provides a powerful tool for referencing objects.
Note: Base templates cannot be contained by another template, either as the container or as the
template being contained. You can only use containment with derived templates.
Wonderware Training
Section 6 Containment
An example of a containment hierarchy is a tank that contains the following objects:
z
Inlet Valve
Agitator
Outlet Valve
Level
3-63
3-64
Agitator = Agitator01
Level = Level01
Wonderware Training
Section 6 Containment
Within the context of each hierarchy, the contained names are unique, in that the names only refer
to this tank system and the contained objects.
So if the tank is named Tank01, the contained names are:
z
Tank01.Inlet
Tank01.Agitator
Tank01.Outlet
Tank01.Level
Me.Outlet: Allows a script running within the parent object to generically reference its child
outlet instance.
3-65
3-66
Containment of instances is limited to Areas containing other Areas and AppObjects containing
other AppObjects.
Renaming can be done on an instance's tagname and contained name. A template only has a
template name.
Wonderware Training
Objectives
Upon completion of this lab you will be able to:
z
3-67
3-68
f.
Engineering units:
Liters (locked)
EU value Minimum:
0.0 (locked)
EU value Maximum:
100.0 (locked)
-5.0 (locked)
105.0 (locked)
Derived a new template from the $Meter object, name it $TT, and assign it to the $Mixer
template. Configure the object as follows:
Engineering units:
Celsius (locked)
EU value Minimum:
0.0 (locked)
EU value Maximum:
250.0 (locked)
-5.0 (locked)
255.0 (locked)
Wonderware Training
3-69
h. Configure the input and output references for the contained objects as follows
where XX is your student number.
For Agitator_001
AuxContact.InputSource:
InControl.
tagname.T1XX_AG_AuxContact
CmdStart.OutputDestination:
InControl
tagname.T1XX_AG_CmdStart
CLS.InputSource:
InControl
tagname.T1XX_IV1_CLS
OLS.InputSource:
InControl
tagname.T1XX_IV1_OLS
CmdOpen.OutputDestination:
InControl
tagname.T1XX_IV1_CmdOpen
CLS.InputSource:
InControl
tagname.T1XX_IV2_CLS
OLS.InputSource:
InControl
tagname.T1XX_IV2_OLS
CmdOpen.OutputDestination:
InControl
tagname.T1XX_IV2_CmdOpen
For Inlet1_001
For Inlet2_001
For LIT_001
PV.Input.InputSource:
InControl
tagname.T1XX_LT_PV
CLS.InputSource:
InControl
tagname.T1XX_OV_CLS
OLS.InputSource:
InControl
tagname.T1XX_OV_OLS
CmdOpen.OutputDestination:
InControl
tagname.T1XX_OV_CmdOpen
FlowSwitch.InputSource:
InControl
tagname.T1XX_TP1_FlowSwitch
CmdStart.OutputDestination:
InControl
tagname.T1XX_TP1_CmdStart
FlowSwitch.InputSource:
InControl
tagname.T1XX_TP2_FlowSwitch
CmdStart.OutputDestination:
InControl
tagname.T1XX_TP2_CmdStart
InControl
tagname.T1XX_TT_PV
For Outlet_001
For Pump1_001
For Pump2_001
For TT_001
PV.Input.InputSource:
i.
3-70
Open Object Viewer from within the ArchestrA IDE and, using the watch list created
previously, add a new watch window called Mixer and add the following attribute references:
Object
Attribute
Agitator_001
Cmd
PV
Inlet1_001
Cmd
PV
Inlet2_001
Cmd
PV
LIT_001
PV
Outlet_001
Cmd
PV
Pump1_001
Cmd
PV
Pump2_001
Cmd
PV
TT_001
PV
Wonderware Training
7. Right-click the $Valve object in the Training template toolset and select New / Derived
Template to create a derived template of the $Valve object.
3-71
3-72
Pump1
Pump2
The Training template toolbox should now look like the following:
13. Derive the following template from the $Motor object, containing it within the $Mixer object:
z
Agitator
Wonderware Training
LIT
The Training template toolbox should now look like the following:
3-73
3-74
Liters (locked)
EU value Minimum:
0.0 (locked)
EU value Maximum:
100.0 (locked)
-5.0 (locked)
105.0 (locked)
17. Click the Save and Close button and check in the object.
Wonderware Training
TT
3-75
3-76
Celsius (locked)
EU value Minimum:
0.0 (locked)
EU value Maximum:
250.0 (locked)
-5.0 (locked)
255.0 (locked)
21. Click the Save and Close button and check in the object.
Wonderware Training
3-77
3-78
Wonderware Training
3-79
3-80
33. Click the Save and Close button and check in the object.
Wonderware Training
Instance
Attribute
Input 2: CLS
InControl
tagname.T1XX_IV1_CLS
Input 1: OLS
InControl
tagname.T1XX_IV1_OLS
3-81
3-82
Instance
Attribute
Output 1: CmdOpen
InControl
tagname.T1XX_IV1_CmdOpen
37. Click the Save and Close button and check in the object.
Wonderware Training
Instance
Attribute
Input 2 : CLS
InControl
tagname.T1XX_IV2_CLS
Input 1: OLS
InControl
tagname.T1XX_IV2_OLS
3-83
3-84
Instance
Attribute
Output 1: CmdOpen
InControl
tagname.T1XX_IV2_CmdOpen
41. Click the Save and Close button and check in the object.
Wonderware Training
Attribute
InControl
tagname.T1XX_LT_PV
44. Click the Save and Close button and check in the object.
3-85
3-86
Instance
Input 2: CLS
InControl
tagname.T1XX_OV_CLS
Input 1: OLS
InControl
tagname.T1XX_OV_OLS
Wonderware Training
Attribute
Instance
Attribute
Output 1: CmdOpen
InControl
tagname.T1XX_OV_CmdOpen
48. Click the Save and Close button and check in the object.
3-87
3-88
Instance
Attribute
Input 1: FlowSwitch
InControl
tagname.T1XX_TP1_FlowSwitch
Wonderware Training
Instance
Attribute
Output 1: CmdStart
InControl
tagname.T1XX_TP1_CmdStart
52. Click the Save and Close button and check in the object.
3-89
3-90
Instance
Attribute
Input 1: FlowSwitch
InControl
tagname.T1XX_TP2_FlowSwitch
Wonderware Training
Instance
Attribute
Output 1: CmdStart
InControl
tagname.T1XX_TP2_CmdStart
56. Click the Save and Close button and check in the object.
3-91
3-92
Attribute
InControl
tagname.T1XX_TT_PV
59. Click the Save and Close button and check in the object.
Wonderware Training
3-93
3-94
Attribute List
Agitator_001
Cmd
PV
Inlet1_001
Cmd
PV
Inlet2_001
Cmd
PV
LIT_001
PV
Outlet_001
Cmd
PV
Pump1_001
Cmd
PV
Pump2_001
Cmd
PV
TT_001
PV
Wonderware Training
67. Right-click in the Watch List (bottom section of Object Viewer) and select Save to save the
watch list.
3-95
3-96
Wonderware Training
Module 4
4-3
Section 2 Extensions
4-7
4-11
4-21
4-45
4-53
4-2
Be able to work with extending the objects and configuring them for additional
functionality.
Wonderware Training
Section 1 UDAs
Section 1 UDAs
Section Objective
This section introduces and explains UDAs and how they are configured and used.
This section introduces and explains UDAs and how they are configured and used.
Set whether the new attribute is an array and how many elements comprise it
Set alarms and historization for the new attribute (done on the Extensions page)
Define security and references to other objects (done on the Extensions page)
Note: After you add an attribute to an instance, it appears in the Attribute Browser list for use with
the scripting and attribute extension functions.
Put to the extreme, scripts and UDAs can be used to create a completely new type of
ApplicationObject starting from an empty container object that has no behavior / logic itself.
You can add UDAs to a template or an instance. When you add a UDA to a template, the UDA, its
data type, and category are automatically locked in the child instances.
If UDA parameters such as initial values and security classifications are locked in the template,
they cannot be changed in child instances. If these parameters are unlocked in the template, the
initial value and security are editable and lockable in derived templates. When unlocked in either
the base or derived template, the value is editable in instances.
After you add an attribute to an instance, it appears in the Attribute Browser list for use with the
scripting and attribute extension functions.
4-3
4-4
Inherited UDAs
Name List
UDAs list: Lists all UDAs currently associated with the object. Click the Add button to add
a new UDA.
Inherited UDAs list: Lists all UDAs associated with the object's parent. The object
automatically includes these UDAs. They can only be edited by modifying the parent
template.
Data type list: Shows the data type options for configuring the selected UDA.
Select from the data types Boolean, Integer, Float, Double, String, Time, ElapsedTime or
InternationalizedString.
Allowed categories are Calculated, Calculated retentive, Object writable and User writeable.
You can lock writable attributes. If you select Calculated for an attribute, only scripts running on the
same object can write to the attribute.
You can create an array for each data type except InternationalizedString. Select This is an
array and specify the array's length in the Number of elements box.
The Value parameter specifies the initial setting for the attribute when the object is deployed. Enter
value data for each data type. In the case of a non-arrayed Boolean, select the True/False check
box to use a True value. Clear the check box to use a False value. For an arrayed Boolean, select
the desired element and provide a default value by typing either true or false.
Wonderware Training
Section 1 UDAs
When using UDAs in scripting, note the following:
z
When using Calculated and Calculated Retentive UDAs as counters, they must be
manually initialized. For instance, if you use me.UDA=me.UDA+1 as a counter in a script,
you must also initialize the UDA with something like me.UDA=1 or me.UDA=<some
attribute value>.
Calculated UDAs can be initialized in OnScan and Execute scripts (that is, scripts with
those types of Execution Type triggers), but not Startup scripts.
Calculated Retentive UDAs must be initialized in Startup scripts, and can be initialized in
OnScan and Execute scripts. The main purpose of a Calculated Retentive UDA is to
retain the attribute's current value after a computer reboot, redundancy-related failover, or
similar occurrence in which valid checkpoint data is present. Therefore, your Startup script
should contain a statement testing the Boolean value of the attribute,
StartingFromCheckpoint, on the object's AppEngine. If the value is TRUE, you should not
initialize the UDA; if the value is FALSE, you should initialize the UDA.
4-5
4-6
Wonderware Training
Section 2 Extensions
4-7
Section 2 Extensions
Section Objective
This section describes the Output Functionality for Application Objects in the Extensions
environment.
This section provides describes the Output Functionality for Application Objects in the Extensions
environment.
Extensions
The Extensions page is comprised of seven main functional areas, described next.
InputOutput
Extension Group
Input
Extension Group
Output
Extension Group
Alarm
Extension Group
History
Extension Group
Boolean Label
Extension Group
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
4-8
Alarm Extension Group: Use to create an alarm condition when a Boolean attribute's
value is set to TRUE.
History Extension Group: Use to historize the value of an attribute that does not already
have history capabilities.
Boolean Label Extension: Specify custom text strings for the False state and the True
state. These custom text strings appear in the Active alarm state list in the Alarm
extension area for you to select. If you are using the InTouch HMI, you can see these
custom text strings in InTouch.
Wonderware Training
Section 2 Extensions
System, Batch or Software. Type a Priority level for the alarm (default is 500). Also, choose
between Use Object Description for Alarm Message or typing in another alarm message in
the Message box. An X is placed in the Alarm column of the selected attribute.
7. For History Extension, enter values for the remaining parameters: Force Storage Period,
Engineering Units, Value Deadband, Trend High and Trend Low, if available (depends on
the data type of the selected attribute). An X is placed in the History column of the selected
attribute.
8. For Boolean Extensions,
9. Lock the value if desired. The lock symbol is available only when you are extending a
template. Otherwise, it indicates the lock condition of the value in the parent object.
10. Set the security classification for the attribute if available. See "Security Icons" in "Working
with Object Editors" for more information.
11. Save and close the object editor to include the new attribute extensions in the configured
object.
Output Functionality
The following information applies to the functionality of InputOutput and Output extensions as well
as the output function of the Field Reference, Switch and Analog Device objects.
If a single set request is made to a destination attribute during a single scan cycle, that value is
sent to the destination. During a single scan cycle, though, more than one set request to the same
destination is possible. In that case, folding occurs and the last value is sent to the destination.
The following occurs during a single scan cycle: Only the last value requested during a scan cycle
will be sent to its destination when the object executes. Its status is marked as Pending as it waits
for write confirmation from the destination object. All other set requests during that scan cycle are
marked as successfully completed.
If one or more new sets are requested during the next scan cycle, then the second scan cycle's
value is determined in the same way as described above. It is then sent to the destination when
the object executes again and the value sent to the destination during the previous scan cycle is
marked with successful completion status even if write confirmation had not been received.
In other words, within a single scan cycle, data is folded and only the last set requested is sent to
the destination. For instance, an {11,24,35,35,22,36,40} sequence of set requests will result in a
value of 40 being sent to the destination object. All other values result in successful completion
status.
The exception to the above-described functionality is for Boolean data types used in User sets
(sets from InTouch or FactorySuite Gateway). This functionality accounts for an unknown user
input rate (for instance, repeated button pushes) with a consistent object scan rate for outputs, and
therefore creates reproducible results. In this case, a combination of folding as described above
plus maintenance of a queue of one element deep in order to better meet the expectation of users.
To begin with, the first value set after the object is deployed (the default True or False) is always
written to its destination.
Subsequently, the following occurs during a single scan cycle: A two-tiered caching scheme of a
Value to be Sent and a Next Value to be Sent is implemented. The Value to be Sent is based on
data change as compared to the last value sent to the destination object. The Next Value to be
Sent is based on data change as compared to the Value to be Sent value. When the first data
change occurs, the new value is cached in the Value to be Sent queue. Folding occurs if the same
value is requested again. If another value change occurs, this second value is cached in the Next
Value to be Sent queue. Again, folding occurs if the same value is requested again.
4-9
4-10
1,0,0,1,1
none
1,0,0,1,1
1,1,0,0
1,1,0,0
none
Value to be Sent
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
Objectives
Upon completion of this lab you will be able to:
z
4-11
4-12
Instance
Attribute
Speed.InputSource
InControl
tagname.T1XX_AG_Speed
SpeedSP.InputSource
InControl
tagname.T1XX_AG_SpeedSP
Using the watch list created in Lab 5, add a new watch window named Extensions with the
following attributes from the Agitator_001 instance:
z
PV
Cmd
Speed
SpeedSP
g. Set the SpeedSP attribute to any valid float value to test it.
h. Save the watch list.
Wonderware Training
Float
Category:
Object writeable
4-13
4-14
6. Click the
follows:
button to add another UDA named SpeedSP to the object and configure it as
Data type:
Float
Category:
User writeable
Wonderware Training
checked
Source:
---.---
4-15
4-16
checked
Source:
---.---
unchecked (locked)
12. Click the Save and Close button and check in the object.
Wonderware Training
Attribute
InControl
tagname.T1XX_AG_Speed
4-17
4-18
Attribute
InControl
tagname.T1XX_AG_SpeedSP
19. Click the Save and Close button and check in the object.
Wonderware Training
Cmd
PV
Speed
SpeedSP
25. Double-click the SpeedSP attribute to open the Modify Numeric Value window.
26. Set the SpeedSP attribute to any valid float value. In this example, 50 is used.
When the Agitator_001 is running the Speed attribute will indicate the actual speed of the motor
around the SpeedSP (speed setpoint).
27. Save the watch list.
4-19
4-20
Wonderware Training
4-21
4-22
Wonderware Training
Scripts list: Shows all scripts currently associated with the object. The columns indicate
which kind of trigger the script uses: Startup, On Scan, Execute, Off Scan and Shutdown.
Click the Add button to add a new script.
Inherited scripts name list: Shows all scripts associated with the object's parent. The
columns indicate which kind of trigger the script uses: Startup, On Scan, Execute, Off
Scan and Shutdown.
Configure Execution Order: Sets the execution order of multiple scripts (inherited and
local) associated with this object.
Aliases area: Lets you create and modify aliases that apply to the script you are working
on. Aliases are logically descriptive names for typically long ArchestrA reference strings
that you can use in the script to make the script more readable.
Declarations area: Provides a place to add variable declaration statements, such as DIM
MyArray[1] as FLOAT;. These declared variables live from the startup to the shutdown of
the object and can be used to hold values that persist from one execution of the script to
the next. They apply only to the script in which they are declared.
Basics area: Provides a location in which you set the expression, triggering conditions,
and other settings that run the script in the run-time environment. This area includes:
Script State: Select to send the state of the script to a Wonderware Historian Server
historian, the ArchestrA historian.
4-23
4-24
Startup
Called when the object is loaded into memory (deployment, platform or engine start). This script
method is intended to be used to instantiate COM objects and .NET objects. Depending on load
and other factors, it may be possible that sets to object attributes from this script method may fail.
Attributes that reside off-object are not available to this script method. Therefore it is not
recommended to use this script method for any scripting beyond its intended use.
OnScan
Called the first time an AppEngine calls this object to execute after the object scan state is
changed to OnScan. This script method is intended to be used to initiate local object attribute
values, or to provide more flexibility in the creation of .NET or COM objects. Attributes that are offengine are not available to this script method. It is not recommended to use this script method for
any scripting beyond its intended use.
Execute
Called every time the AppEngine performs a scan and the object is OnScan.
The execute script method is the workhorse of the scripting methods. This is the place that runtime
scripting should be done to ensure that all attributes and values are available to the script. This
script method in analogous to the InTouch scripts with the following conditional trigger types:
z
On True: Executes if the expression validates from a false on one scan to a true on the
next scan.
On False: Executes if the expression validates from a true on one scan to a false on the
next scan.
While True: Executes scan to scan as long as the expression validates as true at the
beginning of the scan.,
While False: Executes scan to scan as long as the expression validates as false at the
beginning of the scan. ,
Data Change: Executes when there is a change in data from one scan to the next.
Data changes between each scan are not evaluated, only the value at the beginning of
each script is used for evaluation purposes, in other words if a boolean attribute were to
change from True to False to True again during 1 scan cycle, this change would not be
evaluated as a data change as the value is True at the beginning of each scan cycle.
Time-based script considerations (a trigger period of 0 means that the script execute
every scan).
Wonderware Training
4-25
4-26
Attribute References
Relevant References
References that go up the hierarchy to parent objects are called relative references.
Relative references, such as Me, are valid reference strings. A valid reference string must always
contain at least a relative reference or one substring.
The following are valid relative references that refer to the current object:
z
Me
MyContainer
MyPlatform
MyEngine
MyArea
Relative references are especially useful in templates because absolute references typically do
not apply or make sense.
When you use relative references, like MyContainer, you can refer to contained objects within that
container. For example, a reference to MyContainer.InletValve.PV is equivalent to
Tank1.InletValve.PV in the following hierarchy:
Tank1
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
4-27
4-28
If you use Calculated and Calculated retentive UDAs, they must be manually initialized.
For example, if you use me.UDA=me.UDA+1 as a counter in a script, you must also
initialize the UDA with something like me.UDA=1 or me.UDA=<some attribute value>.
Calculated UDAs can be initialized in scripts with Execution type triggers of On Scan
and Execute, but not initialized in Startup scripts.
Calculated retentive UDAs can be initialized nearly anywhere, however the advantage of
initializing on Startup is the StartingFromCheckpoint attribute can be evaluated. For
example, a Calculated retentive UDA retains the attributes current value after a
computer restart, redundancy-related failover, or similar situation in which valid checkpoint
data is present. Your Startup script should contain a statement testing the Boolean value
of the StartingFromCheckpoint attribute on the objects AppEngine. If the value is TRUE,
do not initialize the UDA. If the value is FALSE, initialize the UDA.
Language Definition
All QuickScript .NET keywords and variable name identifiers are not case sensitive. However, the
case is preserved throughout editor sessions.
Both single line and multi-line comments are supported. Single line comments start at a in a
source code line that has no matching ending in the line. Multi-line comments start with a { and
end with a } and can span multiple lines as the name suggests.
Examples:
Dim A; This is a single line comment
Dim B; {This is an example of a multiline comment}
Spaces and indentation can be used as desired to improve readability, except that at least one
space must appear between adjacent identifiers, and spaces and line breaks cannot appear within
identifiers and numbers. Individual statements are distinguished by a semicolon that marks the
end of a statement.
Description
Complement
Negation
NOT
Logical NOT
Wonderware Training
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)
(, )
- (negation), NOT, ~
**
* , /, MOD
+, -
SHL, SHR
==, <>
&
10
11
12
13
AND
14 (lowest)
OR
4-29
4-30
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
statement will refer to the value associated with the local variable PV rather than the attribute
PV.
Note: The naming convention for QuickScript.NET variables is more restrictive than in
QuickScript. In QuickScript additional special characters are allowed:
QuickScript_special_character :- _!@-?#$%\&
In contrast to QuickScript arrays with up to three dimensions are supported. Only the upper bound
of each dimension can be specified and is fixed after the declaration; i.e., a statement analogous
to VBs ReDim statement is not supported. The lower index of each array dimension is always 1.
Wonderware Training
Default
Value
Boolean, Discrete
False
Integer
Signed
2147483648 to 2147483647
Float, Real
NaN
Double
NaN
String, Message
(empty
string)
Time
Comment
ElapsedTime
Object
Nothing
Indirect Datatype
The Indirect keyword supports dynamically binding a variable to an arbitrary reference string for
get/set usage.
The syntax for this keyword, including the use of the method, BindTo(s), is
show in the example below:
dim x as indirect;
...
x.BindTo(s); ' where s is any expression that returns a string
x = 1234;
if WriteStatus(x) == MxStatusOk then
' ... do something
endif;
WHILE Loop
4-31
4-32
Data Type
Mapping
Boolean, Discrete
Integer
Float, Real
Double
String, Message
Time
Object
Wonderware Training
(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.)
It is possible to exit the loop from within the body of the loop via the EXIT FOR statement.
The FOR loop is executed as follows:
1. analog_var is set equal to start_expression.
2. The system tests to see if analog_var is greater than end_expression. If so, the loop exits. (If
change_expression is negative, the system tests to see if analog_var is less than
end_expression.)
3. The statements in the body of the loop are executed. Here the loop can potentially be exited
via the EXIT FOR statement.
4. analog_var is incremented by 1 - or by change_expression if it is specified.
5. Steps 2 through 4 are repeated.
Note: FOR-NEXT loops may be nested. The number of levels of nesting possible depends on the
memory and resource availability.
4-33
4-34
As in the case of the FOR TO loop it is again possible to exit the execution of the loop via the
statement EXIT FOR; from within the loop.
Note: Collections are frequently leveraged by VB and VBA / JScript. 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
Dim
Dim
Dim
Dim
fso As IFileSystem;
folder As IFolder;
fileCollection As IFileCollection;
file As IFile;
fileName as String;
Wonderware Training
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.
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.
4-35
4-36
Overflow Error
A script experiences an overflow condition. Overflow conditions not only apply to analog data
types (integer float) but also other data types (for example, string length overflow).
Division by Zero
The division by zero error is raised only for integer operations. In the case of float values the
scripting is able to deal with + and - and also NaN (Not a Number).
Wonderware Training
4-37
4-38
If the quality of Valve101.PV and Valve102.PV is acceptable then the if and else branches are
executed purely based on the value of those two attributes.
However, if at least one of the PV values has an unacceptable quality (bad or initializing) then
automatically the else branch is executed. I.e., if statements should be written in a way that the
else branch always constitutes the fail safe mode.
Adhering to this standard allows script writers to take quality into account without ever explicitly
evaluating the quality of referenced attributes.
Wonderware Training
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 it is easier if all the
listed cases are treated equally; i.e., the quality is ignored in all cases.
Time Propagation
Time propagation preserves the timestamp of process data obtained from source field devices like
a PLC or DAServer. The timestamp can be shown from visualization client applications like
InTouch. Also, timestamps are associated with the value and quality of data saved to the
Wonderware Historian.
Execution Mode
Execute mode scripts can be configured to execute in one of two execution modes, synchronous
or asynchronous. All other script types are always synchronous and cannot be configured
otherwise.
Synchronous Execution
The synchronous mode is the default choice and represents serial script execution by the
ApplicationEngine in the course of calling the Execute method of all ApplicationObjects that are
on-scan in the ApplicationEngine. For satisfactory determinism, this mode requires that all scripts
execute deterministically and quickly enough to prevent an ApplicationEngine over-scan condition.
Asynchronous Execution
The asynchronous mode is used for the class of scripts that perform operations that 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.
Only script code written for the Execute type of an object can be declared asynchronous.
If an asynchronous script is currently executing, then the condition for next execution is not
evaluated and it is not executed again. Condition evaluation is always done in main thread of
engine. Therefore, only one copy of a given asynchronous script in an object can be executing at
one time.
4-39
4-40
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).
Asynchronous scripts also have the following diagnostic attribute within the engine:
Script Timeout
The execution time of both synchronous as well as asynchronous mode scripts is monitored
against a timeout period. All synchronous scripts on an AppEngine share the same timeout period
which is exposed as a configurable attribute of the AppEngine.
In the case of asynchronous scripts a timeout period that is shared for all asynchronous scripts
does not make sense since the needed execution time can vary by orders of magnitude between
different asynchronous scripts. In order to account for this, the timeout period can be separately
configured for each asynchronous script. It is exposed as an attribute of the script.
Wonderware Training
Calling public instance methods (with and without parameters) of .NET types.
Calling public static methods (with and without parameters) of .NET types.
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:
4-41
4-42
Script Examples
The following script examples may be used for reference.
Note: Many additional script examples may be located in the ArchestrA IDE Help files under
Enhancing an 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;
Wonderware Training
4-43
4-44
Wonderware Training
Objectives
Upon completion of this lab you will be able to:
Use the QuickScript.NET scripting engine to extend your objects with extra functionality
z
4-45
4-46
Me.ConnectionStatus <> 2
Trigger type:
WhileTrue
Trigger period:
00:00:05.0000000
Script body:
Me.Reconnect = True;
Me.ConnectionStatus <> 2
Trigger type:
OnTrue
Script body:
Me.DisconnectCnt = Me.DisconnectCnt + 1;
Wonderware Training
4-47
4-48
(locked)
Declarations section:
(locked)
Scripts section:
Execution type:
Execute (locked)
Basics section:
(locked)
Expression:
Me.ConnectionStatus <> 2
Trigger type:
WhileTrue
Trigger period:
00:00:05.0000000
Me.Reconnect = True;
The purpose of this script is to monitor the ConnectionStatus attribute of the object every 5
seconds. As long as the connection status is equal to something other than 'Connected' (A value
of 2 signifies Connected), the script will tell the object to attempt a reconnect.
Wonderware Training
Integer
Category:
Calculated
The DisconnectCnt attribute is a counter that will keep track of how many times the object
disconnects. This attribute value will be updated via a script, defined next.
6. Select the Scripts tab.
4-49
4-50
7. Click the
button to add a new script to the object. Name the script DisconnectMonitor
and configure it as follows:
Aliases section:
(locked)
Declarations section:
(locked)
Scripts section:
Execution type:
Execute (locked)
Basics section:
(locked)
Expression:
Me.ConnectionStatus <> 2
Trigger type:
OnTrue
Me.DisconnectCnt = Me.DisconnectCnt + 1;
This script monitors the connection status of the object. Every time it changes from a 'Connected'
status to a non-connected status ('Disconnected' or 'Mixed'), it increments the count
(DisconnectCnt attribute).
Wonderware Training
This script will initialize (set to zero) the DisconnectCnt attribute when the object goes on scan.
11. Click the Save and Close button and check in the object.
12. Deploy the InControl instance, accepting the defaults in the Deploy dialog box.
Note: Your instructor will demonstrate how the completed lab steps have changed the
behavior of the deployed object.
4-51
4-52
Wonderware Training
Objectives
Upon completion of this lab you will be able to:
z
Use the QuickScript.NET scripting engine to automatically configure on runtime the input
and output references of instances
4-53
4-54
Modify the Mixer instance, create and deploy a new Mixer instance
d. Undeploy the Mixer_001 instance and change its name to Mixer_1XX.
e. Create a new instance of the $Mixer template named Mixer_2XX and assign it to the Line2
area.
f.
g. Using the watch list created in Lab 5, verify configuration of Mixer 1and its contained Objects
using the Mixer tab in Object Viewer.
h. Rename the Mixer tab in Object Viewer, naming it Mixer 1.
i.
Add a new watch window named Mixer 2 with the following attributes to verify configuration of
Mixer 2 and its contained Objects.
Object List
Attribute List
Agitator_002
Cmd
PV
Inlet1_002
Cmd
PV
Inlet2_002
Cmd
PV
LIT_002
PV
Outlet_002
Cmd
PV
Pump1_002
Cmd
PV
Pump2_002
Cmd
PV
TT_002
PV
Wonderware Training
(locked)
Declarations section:
(locked)
Scripts section:
Execution type:
Script body section:
OnScan (locked)
Lab 14 - Configuring Automatic Reference.txt script
located in the Wonderware Training folder.
4-55
4-56
3. Click the Save and Close button and check in the object.
5. Click OK to confirm the Undeploy, retaining the default selections in the Undeploy dialog
box.
Wonderware Training
10. Right-click the $Mixer template and choose New / Instance to create a new instance of the
$Mixer template.
11. Rename the new instance Mixer_2XX, where XX is your student number.
12. Click Yes when the warning displays.
4-57
4-58
The new instance of the Mixer_2XX displays a warning icon on all contained objects. Your
instructor will address this after the lab.
Note: Warnings can be cleared by setting the default references from ---.--- to ---, or by using the
Upload Runtime Changes in the context menu after deployment to pull runtime I/O assignments
to the configuration interface.
Important! If there is a warning icon on the Mixer_2XX instance itself, notify your instructor.
Warning
icons
are OK!
15. Deploy the Mixer_1XX instance, accepting the default deployment settings.
Wonderware Training
4-59
4-60
Attribute List
Agitator_002
Cmd
PV
Inlet1_002
Cmd
PV
Inlet2_002
Cmd
PV
LIT_002
PV
Outlet_002
Cmd
PV
Pump1_002
Cmd
PV
Pump2_002
Cmd
PV
TT_002
PV
Wonderware Training
Module 5
5-3
5-15
5-33
5-39
5-2
Wonderware Training
Section 1 Alarms
Section 1 Alarms
Section Objectives
z
This section provides familiarization of the concept of alarms and events and how ArchestrA
handles them.
What is an Alarm/Event
The alarm and event capabilities in the system provide for users to automate the detection,
notification, historization and viewing of either application (process) alarms and events or system/
software alarms events. Alarms and events are things that occur in the runtime system. Events
and alarms are different and the system distinguishes between the two. An event is simply an
occurrence of a condition at a certain point in time. The system can detect events, store them
historically and report them to various clients. Alarms, on the other hand, represent the
occurrence of a condition that is considered abnormal (generally bad) in nature and requiring
immediate attention from a user. Alarms are a special type of event that indicate something
abnormal has happened. The system handles the real-time reporting of alarms in a special
manner and provides special clients for their viewing.
Examples of alarms include:
z
A process 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.
5-3
5-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 Alarms
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
5-5
5-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
Wonderware Training
Section 1 Alarms
Alarm Queries
Alarm queries are used within alarm clients to retrieve real-time alarm information and event
reports from the Galaxy.
The fully-qualified syntax of an alarm query to retrieve a single alarm within an object as reported
by a specific WinPlatform object is:
\\nodename\Galaxy!area!object.attribute
If the WinPlatform object that serves as an alarm provider is located in the local computer, the
following syntax of the alarm query is allowed:
\Galaxy!area!object.attribute
The following table lists different variants of the alarm query and their return data:
Alarm Query
Results
\\nodename\Galaxy!area
\\nodename\Galaxy!area!area
\\nodename\Galaxy!winplatform
\\nodename\Galaxy!engine
\\nodename\Galaxy!dio
All alarms and events from the device integration object itself.
Use of Wildcard
The asterisk (*) is a wildcard character that may be used to substitute any character or characters
in the object.attribute part of the alarm query.
The following table lists different examples on the use of the wildcard character on alarm queries
and their return data:
Alarm Query
Results
\\nodename\Galaxy!area!object.*
\\nodename\Galaxy!area!*.attribute
All alarms and events from all the objects in the area for
the specific attribute.
\\nodename\Galaxy!area!objectprefix*
By using multiple queries it is possible to retrieve alarms from different nodes (WinPlatform
objects) at the same time, for example:
\\NodeNameA\Galaxy!Area1 \\NodeNameB\Galaxy!Area2
5-7
5-8
General Attributes
Alarm Attributes
You can set individual alarms within an object for each type of alarm. For example, you can set
alarms for each of the limits of a level alarm. The calculated AlarmMode attribute value of an
individual alarm uses the same inputs an object alarm. The parent AlarmMode attribute is from the
object itself. As with object alarms, the individual alarm mode is set to the most restrictive input
state. For example, if the objects AlarmMode state is disabled and the individual alarms
AlarmInhibit is FALSE, the individual alarm is disabled.
Each individual alarm is autonomous from other individual alarms in an object. The AlarmMode of
an individual alarm is not propagated to other alarms. Unlike inhibit for the entire object, inhibit of
an individual alarm does not affect the alarms of any contained objects. You can selectively
enable, silence, or disable an individual alarm and not set other alarms to the same value within
the object hierarchy.
Attribute
Description
AlarmInhibit
If TRUE, all alarms for the object are disabled. Typically written to by a script, user or
input extension. If an area, all alarms for objects in area are disabled. If a container, all
alarms for objects in container are disabled.
AlarmMode
Indicates current alarm mode of object. The mode is based on the object's commanded
mode; if an area and container are enabled. Otherwise, the most disabled state of the
container or parent area applies. Disabled mode is considered the most disabled, then
Silenced and then Enabled.
AlarmModeCmd
InAlarm
Indicates whether any of the object's alarms are in the Active state. Can be true only
when the object is on scan and alarms are enabled.
Alarm Attributes
Attribute
Description
<Attribute>.Acked
<Attribute>.AckMsg
<Attribute>.AlarmMode
The current alarm mode setting. Valid values are: Enable, Disable,
Silence.
<Attribute>.AlarmModeCmd
The command to set the alarm mode. Valid values are: Enable, Disable,
Silence.
<Attribute>.Category
The category of the alarm. The label of each alarm category is fixed.
Wonderware Training
Section 1 Alarms
Attribute
Description
<Attribute>.DescAttrName
<Attribute>.InAlarm
The alarm state. This is exactly the same as the attribute in the host
primitive that represents the alarm condition, except when the alarm
state is disabled, in which case, InAlarm is set to Off, regardless of the
actual condition state.
The quality is set during execute to the quality of the attribute, except
when the alarm is disabled, in which case the quality is always GOOD.
<Attribute>.Inhibit
<Attribute>.Priority
The value for the urgency of the alarm. Valid values are 1 through 999,
with 1 being the most urgent.
<Attribute>.TimeAlarmAcked
The timestamp indicating the last time this alarm was acknowledged.
The date format reflects the current locale setting for the operating
system.
<Attribute>.TimeAlarmOff
The timestamp indicating the last time this alarm (as represented by the
InAlarm attribute) went off. The date format reflects the current locale
setting for the operating system.
<Attribute>.TimeAlarmOn
The timestamp indicating the last time this alarm (as represented by the
InAlarm attribute) went on. The date format reflects the current locale
setting for the operating system.
5-9
5-10
Alarm Extensions
An alarm extension can be added to a template or instance Boolean attribute in the Extensions tab
of the objects editor. If added to a template attribute, the alarm extension is automatically locked in
derived objects. Attribute arrays cannot be extended.
On the Extensions page of the Object Editor, select an attribute from the Extendable Attributes
List. The four extension groups dynamically change to allowed extension rules for the selected
attribute type.Select the Alarms check box. For Alarm Extension, select a Category from the list.
Wonderware Training
Section 1 Alarms
For Boolean Label Extension, specify text strings for the False state and the True state, if needed.
These text strings appear in the Active Alarm State list for you to select.
Lock the values, if needed. The lock symbol is available only when you are extending a template.
Otherwise, it indicates the lock condition of the value in the parent object.
5-11
5-12
Specify the alarm query that will be a part of the logging instance
Set performance tuning parameter The auto reconnect rate is not the same as the
performance tuning parameter. It depends on the time out for a connection attempt
associated with SQL ServerServer.
When minimized, the Alarm DB Logger Manager appears as an icon in the system tray. When
you right-click the icon, a popup menu appears displaying the following commands:
Wonderware Training
Section 1 Alarms
Start Begins the alarm logging process.
Stop Ends the alarm logging process.
Settings Opens the Alarm DB Logger Manager - Configuration dialog box.
Hide Window Minimizes the Alarm DB Logger Manager dialog box to an icon in the system
tray.
Show Window Opens and maximizes the Alarm DB Logger Manager dialog box.
Close Exits the Alarm DB Logger Manager Utility.
b. The Smart Cache Status indicates the percentage fill of the in-memory buffer with alarm
records.
c. Click Settings to configure the Alarm DB Logger. The Alarm DB Logger Manager Configuration dialog box appears.
For more information on configuring the Alarm DB Logger, see Alarm DB Logger
Configuration.
d. Click Start to begin the alarm logging process.
e. Click Stop to end the alarm logging process.
5-13
5-14
Wonderware Training
Objectives
Upon completion of this lab you will be able to:
z
5-15
5-16
Extend the Malfunction attribute with an Alarm extension and lock it. Configure its category
as Process and leave the default values on the rest of the attributes.
j.
Using the watch list created in Lab 5, add a new watch window called Alarms and add the
following attribute references:
z
LIT_001.PV
LIT_001.InAlarm
LIT_001.Hi.InAlarm
LIT_001.Hi.Limit
LIT_001.Hi.TimeAlarmOn
LIT_001.Hi.TimeAlarmOff
Agitator_001.InAlarm
Agitator_001.Malfunction
Agitator_001.Malfunction.InAlarm
Agitator_001.Malfunction.TimeAlarmOn
Agitator_001.Malfunction.TimeAlarmOff
Line1.AlarmOnCnt
Wonderware Training
l.
User Name:
sa
Password:
Configure the Alarm DB Logger Manager to query all priorities from the following alarm
query:
\Galaxy!ControlSystem
\Galaxy!Discharge
\Galaxy!Intake
\Galaxy!Production
m. Leave the defaults advanced settings and start Alarm DB Logger Manager.
5-17
5-18
3. Click the Save and Close button and check in the object.
Wonderware Training
checked (locked)
Level alarms:
(locked)
Hi:
checked (locked)
Hi Limit:
80.0 (unlocked)
Hi Priority:
500 (locked)
Hi Alarm Message:
6. Click the Save and Close button and check in the object.
5-19
5-20
Boolean
Category:
Object writeable
Wonderware Training
checked
--checked (locked)
Category:
Process
Priority:
500
Alarm message:
me.ShortDesc
True
12. Click the Save and Close button and check in the object.
5-21
5-22
16. Click the Save and Close button and check in the object.
Wonderware Training
5-23
5-24
Note: If Object Viewer was open during undeployment, you will see the following error
message. Click the OK button to close and then re-open Object Viewer from the ArchestrA
IDE.
Hi.InAlarm
Hi.Limit
Hi.TimeAlarmOff
Hi.TimeAlarmOn
InAlarm
PV
InAlarm
Malfunction
Malfunction.InAlarm
Malfunction.TimeAlarmOff
Malfunction.TimeAlarmOn
AlarmOnCnt
Wonderware Training
27. Configure the Alarm DB Logger Manager Configuration dialog box as follows:
Server Name:
localhost
Database:
WWALMDB
User Info:
User Name:
sa
Password:
Logging Mode:
Detailed
5-25
5-26
30. In the Alarm DB Logger Manager Configuration dialog box click the Next button to
continue.
31. Configure the Alarm DB Logger Manager Query Selection dialog box as follows:
From Priority:
To Priority:
999
Alarm Query:
\Galaxy!ControlSystem
\Galaxy!Discharge
\Galaxy!Intake
\Galaxy!Production
Wonderware Training
5-27
5-28
Wonderware Training
Database Engine
Server name:
localhost
Authentication:
Windows Authentication
5-29
5-30
Wonderware Training
5-31
5-32
Wonderware Training
Section 2 Historization
Section 2 Historization
Section Objectives
z
This section provides familiarization with the background concept of historization and the details of
historizable configuration.
Historization Background
The history system supports historization of process data in distributed history architecture.
One or more Historian products can be installed on the same network as the Application Server
Galaxy. The Galaxy can be configured to store history data into one or more of those Historians.
Since the Engines use push technology to historize, the Historian box does not have any
ArchestrA software requirements.
Each Engine in the Galaxy is configured with the location of the Historian storage node to which its
history data is to be sent. This configuration is stored in an attribute within the Engine.
Wonderware Historian requires a Historian tag to be configured in its database for each attribute to
be historized by an AutomationObject. Thus, there is a one-to-one relationship between a
historized object and a tag in Wonderware Historian.
When an AutomationObject starts up it registers its configuration data with Historian using a
Historian supplied interface. If the Historian tag already exists, it means this object has been
previously registered. If the Historian tag does not exist, it is created automatically. In either case,
the object receives back a unique identifier (handle) for that tag. This is a push-style configuration
model, meaning the configuration data for each historized property of an object is dynamically, and
automatically, pushed to Historian. The user does not need to run Historian configure and import
tags from Application Server (as done with InTouch today).
For storage, the story is similar. When an object decides to store a new VTQ to Historian, it
pushes that storage update message, with the new VTQ, to Historian using a Historian supplied
interface. The Historian must exist on a different node from the AutomationObject. The history
primitive uses the previously-returned unique identifier for the Historian tag that corresponds to the
historized property to identify the tag being stored.
History Configuration
Historizable Data Types for Attributes
For attribute data to be stored in the historian, a host AppEngine must be configured to send
history data to a Wonderware Historian node. For each object, you can configure attributes of the
following data types to be saved to the Wonderware Historian.
z
Float (numerical)
Double (numerical)
Integer (numerical)
Boolean (non-numerical)
5-33
5-34
Enum type attributes are saved as Wonderware Historian integer ordinal values.
IEEE NaN values for float and double data types are converted to null values prior to being
sent to the historian. NaN values are associated with a Bad OPC data quality.
All numerical attributes sent to the Wonderware Historian are in the engineering units
specified for the attribute. The Wonderware Historian does not scale numerical values.
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 2 Historization
Reconfiguration of Historian at Object Undeploy Time
When an AutomationObject is undeployed that has been historized, object does not cause any
dynamic reconfiguration of the Historian product. In other words, the Historian tag and all its
history is left in the Historian historian. This means the history data can still be examined in the
future even if the AutomationObject is no longer deployed.
NaN Handling
For Float and Double attributes, a potential value is the IEEE NaN encoding for the float or double
representation. NaN values can be generated for attributes that are to be historized. These NaNs
will be accompanied by a Bad OPC Data Quality. In any case, NaN is a valid value that can be
generated for floats and doubles. Unfortunately, Historian clients do not handle NaN properly.
Therefore, ArchestrA will convert the NaN value to a Null value representation just prior to sending
to Historian.
5-35
5-36
The Galaxy Platform and its Engines which are generating history startup prior to Historian
node startup in a recovery situation.
History data must be preserved in these cases by having it stored locally until the link to
Historian has recovered or Historian has started. This is called store/forward. This
capability is limited by the hard disk capacity of the system where data is stored before
forwarding. The maximum data storage size to be consumed by store/forward must be
configurable in the Platform. Also, whether store/forward is enabled/disabled can be
configured.
Historian extension
You can assign historical extensions to extended attributes that you select from the Extensions tab
of your objects.
After you select the History extension check box to save the data to history associated with the
attribute extension you selected, an X appears in the H column of the Extendable Attributes list to
indicate its data is saved to the historian.
The following are the common historical attributes that you can configure for your system and
application objects.
Force Storage Period: Interval in milliseconds in which an attribute value is saved to the
Historian, regardless of whether the value exceeds its value deadband setting or not. An attribute
value is saved to the Historian at every Force Storage interval. The default value of zero (0)
disables the Force Storage period.
Value Deadband: Threshold value in engineering units, which is the absolute difference between
the current and most recent saved historical values. The current value must exceed the absolute
deadband to be saved as historical data.
The Value Deadband filters out small, momentary value changes from being saved to the
Historian. A new value that is within the range of the deadband is not saved to the Historian. The
Wonderware Training
Section 2 Historization
default value of 0.0 disables the Value Deadband and any change to a value is saved as historical
data.
Interpolation Type: List of methods used by the Historian to interpolate analog historical data.
The interpolation type determines which analog value is selected during a Historian data retrieval
cycle. Interpolation types include System Default, Stairstep, or Linear. The default interpolation
type is System Default.
Stairstep: No interpolation occurs. The last known value is returned with the given cycle time. If no
valid value can be found, a NULL is returned to the Historian.
Linear: The Historian calculates a new value at the given cycle time by interpolating between the
last known value prior to the cycle time and the first value after the cycle time.
System Default: The Wonderware Historian system-wide interpolation setting. The system-wide
setting must be either stairstep or linear interpolated.
Rollover Value: Positive integer value that represents a tags reset limit when the Historian
operates in counter retrieval mode. In counter retrieval mode the Historian uses a tag's rollover
value to calculate and return the delta change between consecutive retrieval cycles. The default
value is 0.0.
The Rollover value applies only to numeric attributes. The Rollover value is disabled if the
historical attribute data type is Boolean or a string.
Trend Hi: Initial maximum trend value in engineering units for clients. The default is 100.
Trend Lo: Initial minimum trend value in engineering units for clients. The default is 0.0.
Sample Count: Integer that indicates the number of samples the Historian should store in the
active image for an attribute value. Acceptable range of values is from 0 to 9999. The Historian
enforces a sample count of 65 for the active image.
If the current sample count for the active image is 65, and you set the sample count to a value less
than or equal to 65, the new sample count setting is not saved to the Historian database, and the
active image count remains at 65.
If the current sample count for the active image is greater than 65, and you set the sample count to
a value less than or equal to 65, the new sample count is saved to the Historian database and 65
is used by the active image.
Regardless of the current sample count for the active image, if you set the sample count to a value
greater than 65, the new sample count is saved to the Historian database and used by the active
image.
Enable Swinging Door: A flag that indicates whether the swinging door rate deadband is enabled
or disabled. The default is disabled.
Enable Swinging Door is disabled if the historical attribute data type is Boolean or a string.
Rate Deadband: Percentage rate of change deadband based on the change in the slope of
incoming data values to the Historian. For example, specifying a swinging door rate deadband of
10 percent means that data is saved to the Historian if the percentage change in slope of
consecutive data values exceeds 10 percent.
The default is 0.0, which indicates a swinging door rate deadband is not applied. Any percentage
greater than 0.0 can be assigned to the rate deadband.
5-37
5-38
Wonderware Training
Objectives
Upon completion of this lab you will be able to:
z
Configure attributes within objects for historization including the History Extension
5-39
5-40
j.
Use ActiveFactory Trend to connect to the local Wonderware Historian using Integrated
security.
Agitator_001.Speed
Inlet1.PV
LIT_001.PV
Wonderware Training
C:\S&F
3. Click the Save and Close button and check in the object.
5-41
5-42
checked
Historian:
6. Click the Save and Close button and check in the object.
Wonderware Training
9. Click the Save and Close button and check in the object.
checked (locked)
0 (locked)
Sample Count:
0 (locked)
12. Click the Save and Close button and check in the object.
5-43
5-44
RPM
17. Click the Save and Close button and check in the object.
Wonderware Training
LOCALHOST
Authentication information:
Use Integrated security:
checked
21. After the server has being added to the Server list click the Close button.
5-45
5-46
Wonderware Training
Agitator_001.Speed
Inlet1_001.PV
LIT_001.PV
ActiveFactory Trend displays a graphical representation of the history data recorded for the
selected tags. Notice in this example the first half of the graph is blank. The blank section reflects
the time period before deployment, when no data was available.
5-47
5-48
Wonderware Training
Module 6
Security
Section 1 Security Overview
Lab 17 Security
6-3
6-13
6-2
Module 6 Security
Module Objective
Configure, deploy, and test security with Application Server.
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.
Each attribute of an AutomationObject is given a security classification. This provides the ability to
define who can write to attributes of an object.
6-3
6-4
Module 6 Security
For example, a certain attribute of the DiscreteDevice may be set by the operator to change its
status while a different attribute may be set by a technician. These attributes are meant for
different people, Operator (operate) and Technician (tuning). Configuring access to all users for all
AutomationObjects on individual bases would be a time-consuming and repetitive effort. Thus,
configured Roles and Security Groups can be applied to Users to enable easier configuration of
the Security Model.
Security Groups are simply the grouping of objects that you want to behave in the same way with
respect to security. Every AutomationObject belongs to exactly one Security Group. By default all
new objects belong to the Default Security Group, which cannot be removed. Roles generalize
Users function, such as Intake Operator or Dispatcher. Roles are granted permissions onto a
number of Security Groups. If, for instance, a Role is granted Tuning access to a Security Group,
then that role has write permissions to all object attributes with a security classification of Tuning
(but none other). Roles are also granted utility functions-based permissions, such as Deploy or
Can Edit.
For example, a Role of Software Engineer is created. This Role has full permissions to modify the
objects in the ArchestrA IDE, and has permissions to deploy as well. To undeploy an object,
though, the system requires that the object is offscan. Control of offscan/onscan is controlled by
Operation permissions -- not granted to the Software Engineer, so he cannot undeploy any objects
in Onscan mode. Only an operator (with Operation permissions) can do so.
Permissions are required to perform most ArchestrA activities. Usually only one permission is
required to perform a given activity, but occasionally, two or more permissions may be required for
operation-critical actions.
The final aspect of the Security Model is the User. This describes the access to the system
allowed by a User. The User can be granted as many Roles as needed to perform their job.
ArchestrAs security system is configured in the Configure Security dialog box by:
1. Enabling Security
2. Defining your Security Model
3. Mapping Users to the Security Model
4. Mapping AutomationObjects to the Security Model
If the Security is not enabled then Authentication mode is disabled.
Wonderware Training
Authentication Mode
6-5
6-6
Module 6 Security
On the Authentication Mode page, choose the mode of Galaxy security:
z
None: The default setting for new Galaxies, this mode is considered Open Security. It
leaves all functions open to all users. No authentication is provided for any operations in
the ArchestrA configuration or runtime environment. No login dialog boxes are displayed
for operating Application Server utilities or runtime processes.
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 ArchestrA IDE closes.
When you switch to None from another Authentication Mode and click OK, the
ArchestrA IDE is shut down.
When Galaxy authentication is selected, each user must provide a user name and
password in a login dialog box. The security system authenticates the user's credentials
against Galaxy user data. Access to all operations in the ArchestrA IDE and anywhere in
the ArchestrA environment are granted based on the logged in user's associated roles
and permissions. The ArchestrA IDE customizes the user interface to the user's previous
preferences (for instance, which Application Views are shown). The logged in user's
name is shown in the status bar of the ArchestrA IDE.
When OS User Based authentication is selected, each user must provide a domain, user
name and password in a login dialog box. The security system ensures that the OS user is
authorized to use the ArchestrA IDE.
When OS Group Based authentication is selected, each user must provide a domain, user
name and password in a login dialog box. The security system first ensures that the user
is authorized to use the ArchestrA IDE. Then the system authorizes the user's credentials
against operating system groups mapped to security roles in the Galaxy.
Note: In both OS-based authentication modes, a user is not presented with a log in dialog box
if that user has authorization to use that ArchestrA utility.
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.
6-7
6-8
Module 6 Security
If you use OS Group Based Authentication Mode, you should first familiarize yourself indepth with
the functions of the Windows operating system, particularly its user permissions, groups and
security features. ArchestrA OS Group Based security leverages those Windows features.
Take note of the following behaviors that are unique to OS Group Based Authentication Mode:
z
A newly-added user working on a computer that has no access to the Galaxy node cannot
write to an attribute on a remote node if that user has never logged on to the remote node.
This is true even if the user has been given sufficient runtime operational permissions to
do writes. To enable remote writing capabilities, log on to the remote node at least once.
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 ArchestrA IDE, SMC, and InTouch for System Platform require their users to be
authenticated so that the appropriate permissions can be confirmed. An authenticated user is
granted the sum of all Permissions within their assumed Roles.
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.
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.
6-9
6-10
Module 6 Security
Minimal Operating System Permissions Required for Starting OS User
The OS user account must not be required to have any special privileges to enable it to utilize the
client utilities. Specifically it must not require the user to be an Administrator on the host machine.
The user will be able to change their own OS password from within the ArchestrA utility.
Logon Dialog
If security is enabled within the Galaxy, a client utility Logon dialog will be displayed. Application
Server provides a standard login dialog.
The login appears:
z
The user explicitly chooses a Log On option from within the user interface. It is not
necessary to explicitly Log Off before logging on using a different User Profile. The
previous user will be implicitly logged off.
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 (for example halting a failing
process). This does not require the user to have any privileges.
Operate Operators write to these attributes during normal day-to-day operations. These
include Attributes such as Setpoint, Output and Control Mode for a PID Object, Command
for a Discrete Device Object, etc. This requires the user to be assigned to the Security
Group of this AutomationObject, to allow the write.
Secured Write Operators write to these attributes for normal interaction with a highly
secured object forces re-authentication. This requires the user to be assigned to the
Security Group of this AutomationObject, to allow the write. The AutomationObject will
reject the write requested via the return status and the user must re-enter the login details.
Verified Write Operators write to these attributes for normal interaction with a very
highly secured object. This is similar to Secured Write, however it also requires a second
user authentication. The second user must also be assigned to the Security Group of this
AutomationObject, to allow the write.
Tune Writing to these attributes is considered a tuning activity. Examples are attributes
that adjust alarm setpoints, PID sensitivity, etc. This requires the user to be assigned to
the Security Group of this AutomationObject, to allow the write.
Read-Only The attributes are never written to at runtime, regardless of the user's
permissions.
There are two other situations where an Attribute's Security Classifications are specified:
z
When an Engineer overrides the Attribute Security Classification within a Template editor.
6-11
6-12
Module 6 Security
Wonderware Training
Lab 17 Security
Lab 17 Security
Introduction
As you work with the security settings within the ArchestrA IDE you set up various Roles and
Users and configure them with different sets of permissions. You then observe the different
behaviors in the Object Viewer as you logon as various users.
In this lab you configure the security settings for your galaxy and test those settings with a sample
automation object that has been partially pre-configured for you.
The security configuration used in this lab is based on the following premises:
Operators: these users can acknowledge alarms and operate devices by modifying Operate
attributes in the objects (for example, open a valve or start a motor); but they are not allowed
to change alarm set points or other Tune attributes. Users in this role do not have access to
the configuration data.
Supervisors: these users are only allowed to perform tuning configurations by modifying
Tune attributes in the objects (for example, changing an alarm set point). Users in this role do
not have access to the configuration data.
Engineers: these users have access to the configuration of the Galaxy through the ArchestrA
IDE and configuration of the objects in runtime by modifying Configure attributes in the objects
(for example, changing a deadband or an input source). Notice that users in this role do not
have Operate permissions, which will prevent them from setting objects off scan before writing
to a Configure attribute. It is assumed that the Operators own the runtime, so they have to
set the objects off scan (put the devices off line) before an engineer can change the
configuration on runtime.
Note: Importing objects will be discussed in detail, including the options in the Import Objects
dialog box, in a subsequent module.
Objectives
Upon completion of this lab you will be able to:
z
Configure the security classifications for individual attributes within automation objects
6-13
6-14
Module 6 Security
Summary Lab Instructions
Following is a summary of the general steps you will complete for this lab. For detailed
instructions, please refer to the Detailed Lab Instructions on subsequent pages.
Free Access
Att2_Operate:
Operate
Att3_SecuredWrite:
Secured Write
Att4_VerifiedWrite:
Verified Write
Att5_Tune:
Tune
Att6_Configure:
Configure
Att7_ReadOnly:
Read Only
g. Add a security group named TestGroup and assign the SecurityTest_001 instance to it.
h. Configure the Default role with the following permissions:
On the General permissions section:
IDE Permissions:
unchecked
SMC Permissions:
unchecked
checked
i.
Default:
checked
TestGroup:
unchecked
Add a new role named Operators with an access level of 500 and with the following
permissions:
No General permissions
Wonderware Training
Lab 17 Security
No Operational permissions for the Default security group
Configure the Operational permissions section for the TestGroup security group as follows:
j.
checked
unchecked
checked
unchecked
Add a new role named Supervisors with an access level of 1000 and with the following
permissions:
No General permissions.
No Operational permissions for the Default security group.
Configure the Operational permissions section for the TestGroup security group as follows:
Can acknowledge Alarms:
unchecked
unchecked
unchecked
checked
k. Add a new role named Engineers with an access level of 2000 and with the following
permissions:
Configure the General permissions as follows:
IDE Permissions: checked (this will check every box within the node)
Framework Configuration:
unchecked
SMC Permissions: checked (this will check every box within the node)
Configure the Operational permissions for the TestGroup security group as follows:
l.
unchecked
checked
unchecked
unchecked
m. Add a new user named HOper with a full name of Homer Operator and make it part of the
Operators role. Assign ww as the password.
n. Add a new user named JSup with a full name of Joe Supervisor and make it part of the
Operators and Supervisors role. Assign ww as the password.
o. Add a new user named WEng with a full name of William Engineer and make it part of the
Engineers role. Assign ww as the password.
6-15
6-16
Module 6 Security
Test General Permissions
p. Verify that the WEng user cannot modify the security configuration through the ArchestrA IDE.
Using the watch list created in Lab 5, add a new watch window called Security and add the
following attribute references:
Object Name
Attribute Name
SecurityTest_001
Att1_FreeAccess
SecurityTest_001
Att2_Operate
SecurityTest_001
Att3_SecuredWrite
SecurityTest_001
Att4_VerifiedWrite
SecurityTest_001
Att5_Tune
SecurityTest_001
Att6_Configure
SecurityTest_001
Att7_ReadOnly
SecurityTest_001
ScanState
SecurityTest_001
ScanStateCmd
Test the different security classifications and the security permissions by modifying the value
of the attributes under the different user accounts created before.
Wonderware Training
Lab 17 Security
Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions,
please refer to the Summary Lab Instructions on the previous page(s).
2. In the Import Automation Object(s) dialog box, navigate to C:\Wonderware Training and
select the $SecurityTest.aaPKG file.
6-17
6-18
Module 6 Security
Note: Importing objects will be discussed in detail, including the options in this dialog box,
later in this course.
4. In the Import Preferences dialog box, leave the default options and click OK to continue.
Wonderware Training
Lab 17 Security
The imported object now appears in the Application toolset:
10. Select the Free Access security classification from the popup menu.
6-19
6-20
Module 6 Security
11. Repeat step 6 to configure the security classifications for the following attributes:
Att2_Operate:
Operate
Att3_SecuredWrite:
Secured Write
Att4_VerifiedWrite:
Verified Write
Att5_Tune:
Tune
Att6_Configure:
Configure
Att7_ReadOnly:
Read Only
12. Click the Save and Close button and check in the object.
Wonderware Training
Lab 17 Security
6-21
6-22
Module 6 Security
Configure Security for the Galaxy
17. From the Galaxy menu, select Configure / Security to enable and configure security for the
galaxy.
18. Select Galaxy for the Authentication Mode.
Wonderware Training
Lab 17 Security
19. Select the Security Groups tab.
6-23
6-24
Module 6 Security
Wonderware Training
Lab 17 Security
21. Select the Default security group and locate the SecurityTest_001 instance in the objects list
(right pane).
22. Drag-and-drop the SecurityTest_001 instance to the TestGroup in the security group list (left
pane).
6-25
6-26
Module 6 Security
23. Select the TestGroup security group to confirm SecurityTest_001 appears as an object in the
TestGroup security group.
Important! Make sure that you are moving the objects instance (SecurityTest_001) and
NOT the objects template ($SecurityTest).
Wonderware Training
Lab 17 Security
24. Select the Roles tab.
25. From the Roles available list, select the Default role and configure the permissions as
follows:
In the General permissions section:
IDE Permissions:
SMC Permissions:
checked
TestGroup:
unchecked
Note: The Can Write to GObject Attribute using ObjectViewer permission will allow everyone
(the Default role applies to every user) to modify attribute values using Object Viewer.
6-27
6-28
Module 6 Security
checked
unchecked
checked
unchecked
Wonderware Training
Lab 17 Security
unchecked
unchecked
unchecked
checked
6-29
6-30
Module 6 Security
unchecked
checked (this will check every box within the node)
35. Configure the Operational permissions for the Engineers security group as follows:
Can Acknowledge Alarms:
unchecked
checked
unchecked
unchecked
Wonderware Training
Lab 17 Security
36. Select the Administrator role and configure the Operational permissions for the TestGroup
security group as follows:
TestGroup: checked (this will check every box within the group)
6-31
6-32
Module 6 Security
39. Double-click on the Full name field and enter Homer Operator.
40. Check the checkbox in front of Operators to assign it to the Operators role.
Wonderware Training
Lab 17 Security
41. With HOper selected, click on the Change Password button, enter the following information
in the Change Password dialog box, and then click the OK button to continue.
Old Password:
[blank]
New Password:
ww
ww
43. Double-click on the Full name field and enter Joe Supervisor.
44. Assign the user to the Operators and Supervisors roles.
6-33
6-34
Module 6 Security
Note: Notice that the user JSup will inherit permissions from both the Operators and
Supervisors roles, allowing JSup to modify attributes with Operate and Tune security
classifications.
45. With JSup selected, click on the Change Password button, enter the following information in
the Change Password dialog box, and then click the OK button to continue.
Old Password:
[blank]
New Password:
ww
ww
47. Double-click on the Full name field and enter Will Engineer.
48. Assign the user to the Engineers role.
Wonderware Training
Lab 17 Security
6-35
6-36
Module 6 Security
49. With WEng selected, click on the Change Password button, enter the following information in
the Change Password dialog box, and then click the OK button to continue.
Old Password:
[blank]
New Password:
ww
ww
50. In the Configure Security dialog box, click OK to accept the security configuration.
51. In the Change User dialog box, enter the following information.
User name:
WEng
Password:
ww
Wonderware Training
Lab 17 Security
55. From the Galaxy menu, select Change User to log in as the Administrator.
6-37
6-38
Module 6 Security
Test Operational permissions
Note: Notice that the SecurityTest_001 object needs to be re-deployed. This is because when
the object was assigned to a different security group, the object's SecurityGroup attribute was
changed, modifying the configuration of the object.
58. Deploy the SecurityTest_001 object.
59. Open Object Viewer by right-clicking the SecurityTest_001 instance and selecting View in
Object Viewer. If you closed Object Viewer before, you can use File / Load Watch List to
open the file you saved earlier.
60. Right-click in the Watch List (bottom section of Object Viewer) and select Add Watch
Window to add a new tab to the watch list.
61. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to
rename the watch list to Security.
62. Add the following SecurityTest_001 attributes to the watch list:
z
Att1_FreeAccess
Att2_Operate
Att3_SecuredWrite
Att4_VerifiedWrite
Att5_Tune
Att6_Configure
Att7_ReadOnly
ScanState
ScanStateCmd
Wonderware Training
Lab 17 Security
66. Enter the users credentials in the Change User dialog box.
Database Engine
Server name:
localhost
Authentication:
Windows Authentication
6-39
6-40
Module 6 Security
71. In the Object Explorer (left pane) navigate to localhost / Databases / WWALMDB / Views to
get a list of all the databases Views in the Object Explorer Details (right pane).
Wonderware Training
Lab 17 Security
72. In the Views list (right pane), right-click on the v_EventHistory view and select Open View to
display the current list of alarms logged in the database.
6-41
6-42
Module 6 Security
Wonderware Training
Module 7
Galaxy Maintenance
Section 1 Exporting and Importing Objects
7-3
7-13
7-21
7-35
7-2
Configuring Instances Through a .csv File Using Galaxy Dump and Load
Wonderware Training
This section discusses some fundamental functions dealing with Galaxy Maintenance.
Specifically, it illustrates how to Export for future use and how to Import a galaxy created
previously.
7-3
7-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.
Wonderware Training
7-5
7-6
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.
Wonderware Training
7-7
7-8
Wonderware Training
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.
7-9
7-10
Wonderware Training
7-11
7-12
When the import process is complete, you can start using the objects you imported.
Wonderware Training
This section discusses some fundamental functions dealing with Galaxy Maintenance.
Specifically, it illustrates how to Export a galaxy for future use and how to Import a galaxy
created previously.
Galaxy Dump
Object instances and their configuration data can be exported to a comma-delimited format Galaxy
dump file (.csv extension).
The Galaxy Dump function only dumps instances. Templates cannot be dumped. The .csv file
contains the configuration for the checked in versions of the selected objects as well as the
checked-out objects of the user who initiates the Galaxy dump. The file contains only those
attributes that are unlocked and configuration time-writeable, one column per attribute. Attributes
that are locked, calculated or runtime writeable only are not saved to the file. Attributes that are not
text based (for example, type QualifiedStruct) are not dumped. Object Help files are not dumped.
To export objects to a Galaxy dump file:
a. Select an object in the Application Views pane. You can export more than one instance with
this function by first multi-selecting objects (Shift+Click). Also, you can dump all instances
derived from a template by selecting just the template.
7-13
7-14
Wonderware Training
7-15
7-16
Wonderware Training
7-17
7-18
Wonderware Training
Replace entire instance if an instance of an object with the same name already
exists and you want to replace it entirely with the object in the import file.
Only update changed attributes if an instance with the same name already exists
and you want to replace only the attributes of the object where the values are
different.
Skip if an instance with the same name already exists and you want to keep the
version already in the Galaxy.
Stop Galaxy Load if an instance with the same name already exists and you want to
cancel the Galaxy Load.
c. Choose the preferred conflict resolution and click OK. A progress box is displayed during the
Galaxy load process. Click Cancel to terminate the Galaxy load process.
A Galaxy Load dialog box appears indicating that the Load was successful.
All objects that were changed or created during the Galaxy Load process are checked out to
the logged in user.
Note: A comment line in a .csv file created in Microsoft Excel may create an unintended
default-value object. To avoid this scenario, open the .csv file in Notepad to ensure the
comment line does not contain quote marks.
7-19
7-20
Wonderware Training
This section provides an understanding of role of the System Management Console and how it can
be configured.
Runs with minimal ArchestrA and operating system requirements, equivalent to "Safe
mode"
Allows viewing of the layout of the Galaxy Repository, Platforms, and Engines
7-21
7-22
The Platform Manager appears under the ArchestrA System Management Console (SMC) root
node.
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 will depend upon the software installed:
z
Other snap-ins (for example IndustrialSQL Server) will be available when other
Wonderware software is installed
Each snap-in has its own toolbar, menu options, detail panel, and so on. The contents of these
items will change as you select different items in the console tree.
Security
For all ArchestrA administrative utilities, including Platform Manager, security is configured
through the ArchestrA IDE. By default, there is no security enabled for Platform Manager or any of
the other snap-ins.
7-23
7-24
Wonderware Training
Restore
When you restore a database from backup, any information saved to the database since the
backup was performed is overwritten with the restored information. All changes to the database
since the backup are lost. Also, any transactions in progress when the backup was performed are
rolled back.
7-25
7-26
DAServer Manager
The DAServer Manager allows local or remote configuration of the DA Server and its device
groups and items, and can monitor and perform diagnostics on DAServer communication with
PLCs and other devices.
Like the LogViewer and Platform Manager, the DAServer Manager is a Microsoft Management
Console (MMC) snap-in. Many high-level functions and user-interface elements of the DAServer
Manager are universal to all DAServers; to understand the DAServer Manager, it is critical to read
the documentation for both the MMC and the DAServer Manager.
To read the documentation about the MMC and DAServer Manager, click the Help topics on the
SMC Help menu. Both the MMC Help and the DAServer Manager Help are displayed.
Log Viewer
The ArchestrA Logger is a utility that records information regarding the activity occurring on the
computer. For example, it records start-up data, error conditions, and DAServer information.
The Log Viewer can:
z
When running an ArchestrA application, the Logger runs as a system service. The Log Viewer is a
Microsoft Management Console (MMC) snap-in that provides a user interface for viewing
messages reported to the Logger. The MMC is a host or container utility for the Log Viewer with its
own generic functions.
Note: If a problem occurs while running an ArchestrA application, always check logged
messages by using the Log Viewer prior to calling Technical Support.
Wonderware Training
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 dependent on the current state of the object and your
security permissions. If you do not have permission to perform a particular command, then that
command is grayed out.
7-27
7-28
Description
Monitor
Use this dialog box to locate and open a log file of saved messages.
Connect
New
Refresh
Export List
You can export the currently shown log messages to a log file. Log files
have an .aaLGX extension. The default file name is LogExport with the
current date in the format (mmddyyyy) appended as a suffix. You can
edit the name of a log file but not its extension.
Help
Wonderware Training
Command
Description
Filter
Find
Go To
Bookmarks
Mark
Choose Columns
Customize
The Logger and Log Viewer are automatically installed when an ArchestrA component is installed.
z
Logger - This is the background process that stores messages and events in the system.
This process occurs without any prompting from or interaction necessary from the user.
The logging process can be customized with the LogFlag Editor Snap-In utility. The
Logger is installed as a system service, and can be configured to be an Auto Service or
Manual Service. As an Auto Service utility, the Logger is started when the PC is booted
up. As a Manual Service utility, the Logger requires a manual start through the System
Services utility in Windows Control Panel. In either case, the logging process is always
started when an ArchestrA component begins functioning.
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.
7-29
7-30
6
LogFlag Editor
LogFlag Viewer
5
3
4
Wonderware Training
2
1
To go to a bookmarked message
a. On the View menu, click Go To.
b. In the Go To dialog box, enter the name of the messages bookmark by typing it in the box or
selecting from the list.
c. Click Go To. The Go To dialog box remains open.
d. Use the Previous and Next buttons to go to the nearest bookmarked message above and
below, respectively.
e. When you are done searching, click Close.
Note: You cannot go to bookmarked messages that are currently hidden by a filter. If you cannot
find the desired message, disable filtering and try again.
7-31
7-32
To add a new bookmark, select the message you want to bookmark in the message window
and click Add. This function is comparable to a fast bookmark. Rename it by pressing F2.
Platform Manager
Platform Manager is a common component of an Application Server application and it is available
from any PC node in the application that has a deployed platform; therefore, you do not need to
install it onto each node. This ensures that all nodes used within a galaxy have access to Platform
Manager.
When you use Platform Manager, you can access the platforms and engines deployed to the local
PC node and to any other PC node in the Galaxy. Platform Manager does not require the
GalaxyRepository to be installed on the PC node.
After highlighting a Galaxy or an Engine, you can use the Action menu to start or stop the object,
or set it OnScan/OffScan. If the galaxy has security implemented, you must log on as a user
configured with the proper SMC permissions to start SMC, Start/Stop engines and platforms, or
write from the Object Viewer.
Wonderware Training
The following commands are available from the Platform Manager Action menu when you select
an Engine in either the console tree or the details pane.
These commands are also available by right-clicking an item in either the console tree or the
details pane. The available commands are dependant on the current state of the object and your
security permissions. If you do not have permission to perform a particular command, then that
command is grayed out.
7-33
7-34
Wonderware Training
This section discusses the role of changing the network account and how to use the Change
Network Account and how to configure it.
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.
7-35
7-36
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 ArchestrA IDE may not
function properly. Rebooting the Galaxy node causes this update to occur immediately.
When you use the Change Network Account utility to create or use an account that is different
from the one originally set up during installation, the old account is maintained (not deleted).
WARNING! After you change any data shown in the Change Network Account dialog box,
ensure that all other computers that have installed ArchestrA-enabled software use the same type
of user account with the same user name and password.
7-37
7-38
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.
You chose to use a network domain user account, but the password
you typed does not match the account's password. Click OK, correct
the password, confirm the password, and click OK.
Wonderware Training
Action Required
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.
You must order the network cards properly. In the Network Connections dialog box, click
Advanced Settings on the Advanced menu. In the Advanced Settings dialog box (see image
below), use the up and down arrows to define the correct order of Connections and click OK. The
first connection in the list must be the supervisory network card. If a computer contains more than
two network cards (for instance, a supervisory connection, a PLC connection, and an RMC
connection for ArchestrA redundancy), the supervisory net must be listed first and the others can
be listed in any other position.
7-39
7-40
Wonderware Training
Module 8
8-3
8-9
8-13
8-2
DAServers and DI Objects and how they relate to the connectivity of your application to
external data.
FactorySuite Gateway and how it can enhance the connectivity of your application.
Wonderware Training
This section will describe the configuration of a Wonderware I/O Server (Modbus).
Introduction
Wonderware I/O Servers are Microsoft Windows application programs that enable other DDEaware Windows applications (such as InTouch or Excel) access to data in the real world (such as
PLCs or RTUs).
Wonderware servers are primarily intended for use with Wonderware's InTouch program;
however, they can be used by any Microsoft Windows program capable of acting as a DDE client.
In this section, we will examine the start-up, configuration and use of a Wonderware I/O Server.
Because Wonderware's I/O servers are Windows applications, they will all have the same basic
appearance and capabilities. Keep in mind that depending on server requirements, additional
hardware (network, and so on) may be necessary and the configuration screens may require
additional information.
The following information references the Modbus I/O Server as a point-to-point server using the
RS-232 serial port to PLCs provided at the Wonderware facility training environment. Your
instructor may have you configure the following screens differently.
Note: All I/O Server setup which follows is specific to the Wonderware facility training
environment. Your instructor will provide the proper configuration information. It accesses one
Koyo DirectLogic O5 PLC via its programming port.
8-3
8-4
Com Port: Select the communication port that is connected to the PLC equipment.
Reply Timeout: Enter the amount of time (in seconds) that all PLCs connected via this serial
communications port will be given to reply to commands from the I/O Server.
Note: This timeout is sustained only when the PLC fails to respond. When the PLC is
responding normally, there is no penalty. The default value of 3 seconds should be sufficient
for most configurations.
Protocol area: Select the protocol configured for the equipment attached to this
communication port. RTU is recommended.
Baud Rate area: Select the baud rate (serial bit rate) setting that matches the equipment
connected to this communication port.
Data Bits area: Select the option for the number of data bits that corresponds to the
configuration of the equipment on this communication port.
If ASCII is selected for the protocol, use 7. If RTU is selected, use 8.
Stop Bits area: Select the appropriate number of stop bits for the communication port. If the
baud rate is greater than 300, the stop bits should be set to 1.
Parity area: Select the setting that corresponds to the configuration of the equipment on this
communication port.
Note: All devices on a single communication port must be configured with the same Protocol,
Parity, Stop Bits, Data Bits and Baud Rate.
Wonderware Training
Note: Click Save to save the current settings entered for the selected communication port.
The Communication Port Settings dialog box remains displayed and another communication
port can be configured.
8-5
8-6
Note: Once topics have been defined, their names will be listed in the Topics pane of this
dialog box.
b. Click New to add a new topic definition.
The MODBUS Topic Definition dialog box appears:
c. Topic Name: Enter a unique name (up to 32-characters long) for the PLC in the field.
Note: When communicating with InTouch, this exact name is used as the topic name in the
Access Name definition.
d. ComPort: Select the communications port to be associated with this topic.
Wonderware Training
Slave Device Type: Drop-down list contains slave device types other than the default.
g. String Variable Style: The PLC will use this style to store ASCII strings in its registers.
h. Register Type: Select BINARY or BCD, based on hardware used.
i.
Block I/O Sizes: Coil Read: Enter the maximum number of consecutive coils to be read at
one time. In this example, the valid coil read values can be between 8 and 2000 and must be
an even multiple of 8.
j.
Coil Write: Enter the maximum number of consecutive coils that can be written to at one time.
In this example, the valid coil write values can be between 8 and 800 and must be an even
multiple of 8.
k. Register Read: Enter the maximum number of consecutive registers to be read at one time.
In this example, the valid register read values can be between 1 and 125.
l.
Register Write: Enter the maximum number of consecutive registers that can be written to at
one time. In this example, the valid register write values can be between 1 and 100.
m. Update Interval: Enter the frequency (in milliseconds) that the I/O Server will read (poll) the
items/points associated with this topic. Different items/points can be polled at different rates by
defining multiple topic names for the same PLC and setting different update rates for each
topic.
n. Click OK to accept the entries and close the dialog box.
The Topic Definition dialog box will open with the new topic listed:
o. Click the Done button to close this dialog box and return to the server's program window.
p. Click Modify to change an existing topic definition.
q. Click Delete to delete an existing topic definition.
Note: The previous information is provided for example only. Configuration steps for this
class are provided in the following lab.
8-7
8-8
Wonderware Training
Become familiar with Wonderware Data Access Server and its use with Wonderware
Application Server.
This section provides familiarization with Wonderware Data Access Server and its use with
Application Server.
Introduction
Wonderware Data Access (DA) Server is designed to provide simultaneous connectivity between
client applications based on Wonderware SuiteLink, OPC and DDE protocols that run on the
Microsoft Windows operating system and the data devices supported by the specific protocol
being translated.
The Wonderware DAServers also come with an exclusive new user interface called the DAServer
Manager, which is installed as a Microsoft Management Console snap-in. Its end-user benefits
include simple remote server activation, configuration and operation, and extensive protocol
diagnostic troubleshooting.
Several standard features are available with each DAServer, including:
z
Support for hot configuration, device additions and device- and server-specific parameter
modifications
A wide range of DAServers support connectivity to numerous protocols and products. A few of the
current DAServers Wonderware includes support for are:
z
Component Architecture
A DAServer is comprised of three physical parts:
z
Plug-in Component(s): responsible for communicating with clients, used by all DAServers.
Plug-ins provide protocol translation functionality for device integration clients.
Typical Plug-ins use DDE, SuiteLink or OPC protocol, and serve as interfaces between
their clients and the DAS Engine. A protocol can be disabled when customizing the
installation for your DAServer.
8-9
8-10
Device Protocol Layer: Server specific, responsible for communicating with hardware and
specific to the DAServer. The Device Protocol Layer provides translation between the
hardware- specific protocol such as ModBus and CIP and the DAS Engine interface:
Each physical part of a DAServer is comprised of a set of .EXE and/or .DLL modules. ArchestrA
provides the Plug-in and DAS Engine modules.
You must create the Device Protocol Layer (server specific) modules with the DAServer Toolkit,
and all three sets of modules are required for a fully functioning DAServer.
DAServer Characteristics
Configuration
The DAServer Manager is capable of displaying specific configuration pages for all servers. This
utility allows browsing and editing of servers on different nodes.
Recall that DAServers are hot-configurable. In other words, they are configurable while the server
is running or even acquiring data. Certain restrictions imposed by the underlying network/protocol/
hardware might apply.
For instance, if you uncheck System Items on the global parameters configuration dialog of the
DAServer Manager and select Apply, and then re-check System Items and Apply, System Items
data is valid only to newly connected clients.
The configuration data format for DAServers is XML. Any XML-enabled program (for example, IE
and XML Notepad) can read this format.
Runtime
The DAS Engine is loaded by the DAServer as an in-process COM object.
It is not statically linked. In other words, a new DAS Engine (feature enhancement or bug fix)
would not require re-linking to the other components nor re-QA of those other components. It is
deployed to the system and attaches to all existing server components.
Wonderware Training
Diagnostics
The DAServer Manager diagnostic tool displays generic diagnostic objects common to all servers
as well as server-specific/server developer defined diagnostic data.
Hot Configuration
One of the big advantages provided by the DAServer is the ability to make your DAServer
configurable while the server is running - hot configuration.
The extent to which a specific DAServer is hot configurable varies from server to server. You can
choose from a variety of hot configuration responses, from not being hot configurable at all to
being configurable of each individual parameter while the server is running.
The DAServer handles most of the hot configuration work. In general, a user will run the DAServer
Manager and configure each hierarchy. Any changes she makes that add/delete/update a
hierarchy are sent immediately to the running DAServer.
Server-specific code may elect to react to the change. Some parameters cannot be changed while
the DAServer is running due to protocol-specific issues, and these can be ignored by the serverspecific code.
Here is a complete list of notifications to the server about changes in the configuration:
z
8-11
8-12
FS Gateway is also useful for legacy servers, controllers, and operating systems. Gateway can
translate older DDE to the newer SuiteLink protocol, enabling legacy products to connect to newer
systems.
Wonderware Training
Become more familiar with DI Objects and their use with Wonderware Application
Server.
This section provides familiarization with DI Objects and their use with Wonderware Application
Server.
Introduction
Device Integration (DI) Objects represent the application's network and devices, and mirror the
actual device hierarchy. In Application Server, Device Integration (DI) Objects are a subset of
Automation Objects available in the Template Toolset of the ArchestrA IDE. As a subset of these
Automation Objects, Device Integration Objects consist of two parts:
z
DI Network Object, which represents the communications port and are thus associated
with DA Servers.
DI Device Object, which represents the physical devices that make up a network.
Examples of DI Device Objects are network bridge devices or PLCs. When the objects are
deployed, they represent the network hierarchy. Each level of this hierarchy can be
monitored for its individual status.
Device Integration objects are used to represent communications channels and field controllers.
As such, they are most often arranged in a hierarchy that models the physical hierarchy of the
network and devices on that network.
Device Integration objects are designed to make it very easy to integrate DAServers into the
ArchestrA environment.
Therefore, deploying a DI Network actually deploys the DAServer and its associated components
within the ArchestrA IDE/Galaxy. This facilitates the DAServer installation process for end-users.
Several DI Objects are delivered and installed by default with your Application Server software.
There are also several DI objects available that are for specific DA Servers. These are available
on the Wonderware Device Integration DVD.
DI Object Advantages
Device Integration Objects (DI Objects) represent communication with external devices. DI
Objects may be DINetwork Objects (for example, the Redundant DI Object) or DI Device Objects.
DI Objects (and their associated AppEngine) can reside on any I/O, DA, or Automation Object
Server node in the Galaxy. DI Objects allow connectivity to data sources such as DDE servers,
SuiteLink servers, OPC servers, and existing InTouch applications.
The advantages of using DI Objects are as follows:
z
DI objects allow you to configure, deploy, and monitor DAServers from one centralized
location.
DI Objects can be used to represent all devices and PLCs in a network, enabling
representation of an entire plant, including a hierarchical view of network connectivity.
DI objects are so closely tied to the DAServer that when an object is deployed across the
network, it remotely installs the DAServer (This means that you can install the DAServer
without going to the actual machine, and that the DAServer connects immediately.).
8-13
8-14
DI objects are very closely tied to the DAServer they are assigned to, so that when an
object is deployed, it brings with it all code, including registry, scripting, attributes, and
parent.
Note that in a large project, this process may take some time. However, tremendous savings are
achieved when comparing centralized deployment with individual tasks should the Servers be
separately installed and configured on each node.
Scan On Demand
Advanced Communication Management minimizes network traffic and CPU usage of a DIObject
or DAServer. While the client application is running, scanning for an attribute value is suspended
when the owning object no longer appears in the running application. For example, Advanced
Communication Management suspends scanning for an object's attribute value when the operator
minimizes the application window containing the object. When the operator shows the window
containing the object again, Advanced Communication Management resumes scanning and the
object's attribute value is updated in the application.
Scanning can be configured using the following options:
Active
z
Items are deleted and added to the scan group as requested (referenced) by the clients.
Items that exist when a scan mode change occurs are not deleted unless the previous
mode was ActiveAll and the items are no longer referenced.
The Active scan mode polls all points that are referenced, whether active or inactive.
In Active scan mode an attribute is always in the active state. When the last reference to
the attribute is unregistered/unadvised, the attribute is deleted.
ActiveAll
z
Scanning is continuous and dynamic attributes are never removed when unsubscribed.
Items are activated by client requests, but continue to exist even after the client are not
interested in them anymore.
The scan group polls the field device for all points irrespective of whether they are
currently active, inactive, or even subscribed to by items.
ActiveOnDemand
z
When the scan mode is configured as ActiveOnDemand, attributes that are not actively
being referenced by any client or object are made Inactive and are not scanned.
New Items are deleted and added to the scan group as requested (referenced) by clients.
Wonderware Training
Items that exist when a scan mode change occurs are not deleted unless the previous
mode was ActiveAll and the items are no longer referenced.
ActiveOnDemand scan mode polls the field device for currently active items only. Inactive
items are not scanned.
8-15
8-16
Wonderware Training
Module 9
Multi-Node Applications
Section 1 Application Redundancy
Lab 18 Configuring Application Redundancy
Section 2 DI Redundancy
Lab 19 Configuring the Redundant DI Object
Section 3 Multi Node Application
Lab 20 Convert to Network Environment
9-3
9-15
9-29
9-33
9-45
9-49
9-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 covers the concept of redundancy, how it can be configured and key points
to more effectively implement this feature.
This section provides an understanding of the concept of redundancy, how it can be configured
and key points to more effectively implement this feature. It also provides an understanding of the
concept and functionality of Redundant DI Objects
Redundant Configuration
Redundancy is important in processes that rely on continuous availability of information. There are
two basic types or topologies of redundant configuration:
z
Redundant DI Objects
9-3
9-4
Wonderware Training
The Application Engine that is enabled is considered the Primary engine of the redundant pair;
when you enable this engine, an additional (Backup) engine is automatically created.
Since an engine is required to run under a platform, the platform objects that sponsor the Primary
and Backup application engines need to be configured to use the dedicated NIC. This NIC
provides a high speed inter-connection link or Redundant Message Channel between the
platforms. The Message Channel is vital to keep both engines synchronized with alarms, history,
and checkpoint items from the engine that is in the Active Role. Each engine also uses this
Message Channel to provide its health, along with status information, to the other.
The sequence of deployment (cascade, Primary first, or Backup First) of the redundant pair of
Application engines determines which of these in the pair will take the Active Role. The first engine
deployed takes the Active role while the other one takes the Standby role. The engines maintain
their current roles until a failure occurs. (A failure might consist of computer hardware lost or failed,
or a network card failure.) If a failure occurs, the engine with the Standby role assumes the Active
role and the engine that was in the Active role is given the role of Standby - Not Ready. When the
cause of the failure has been remedied, this engine assumes the Standby - Ready role.
9-5
9-6
During Configuration
Primary object: The object intended as the main or central provider of the functionality in the
run-time. For AppEngines, it is the object you enable for redundancy. For data acquisition, it is
the DIObject you intend to use first as your data source in the run-time.
Backup object: The object that provides the functionality of the Primary object when it fails.
For AppEngines, it is the object created by the ArchestrA infrastructure when the Primary
object has been enabled for redundancy. For data acquisition, it is the DIObject you do not
intend to use first as your data source in the run-time.
During Run-Time
Active object: The object that is currently executing desired functions. For AppEngines, it is
the object that is hosting and executing ApplicationObjects. For data acquisition, it is the object
that is providing field device data through the RedundantDIObject.
Standby object: The passive object; that is, it is waiting for a failure in the Active object's
condition or for a force-failover. For AppEngines, it is the object that monitors the status of the
Active AppEngine. For data acquisition, it is the object that is not providing field device data
through the RedundantDIObject.
The Primary/Backup and Active/Standby objects form a redundancy pair. For AppEngine pairs,
only the Primary and its hierarchy of assigned ApplicationObjects must be created, configured and
deployed. The Backup is handled completely by the ArchestrA infrastructure (for instance, it is
deployed separately from the Primary). For data acquisition, the Primary/Backup DIObjects (the
data sources) must be separately created, configured and deployed. Also, you must create,
configure and deploy a RedundantDIObject to control failovers between the two data source
objects.
In the AppEngine redundancy environment, the Active and Standby objects monitor each other's
status and switch when failure conditions occur. In the data acquisition environment, the
RedundantDIObject monitors the status of the two DIObject data sources, and handles the
switching from Active to Standby objects.
The relationship between the configuration time (Primary/Backup) and run-time (Active/Standby)
object pairs is not static. In the run-time, either the Primary or Backup object can be the Active
object at any particular time. Whenever one becomes the Active object, the other automatically
becomes the Standby.
Configuration values for Primary and Backup also can be changed after deployment of the objects.
Note: In the case of AppEngine redundancy, ArchestrA supports a one-to-one topology in which
the computers hosting the Primary and Backup object sets must be connected by crossover cable
and have fixed IP addresses.
Key Points
a. Before placing an engine with redundancy enabled under a platform in the Deployment view,
configure the platform Redundant Message Channel; otherwise the engine will show an error.
Wonderware Training
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
9-7
9-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
9-9
9-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.
Wonderware Training
Standby - Missed Heartbeats: The state of an AppEngine when 1) a heartbeat ping has
not been received from its Active partner within a configured timeout period, 2) the Active
AppEngine fails or hangs up, or 3) the Active AppEngine is shutdown on purpose. When in
this state, the Standby object attempts to determine whether or not the Active object has
failed. If a manual failover is initiated (by using the ForceFailoverCmd attribute), it will be
processed only if the heartbeats were missed over the primary network and not missed
over the RMC.
Standby - Not Ready: The state of an AppEngine when one of several conditions occurs:
1) its has lost communications with its partner object or it maintains communications with
its partner but has missed checkpoint updates or alarm state changes from the Active
AppEngine, 2) new objects are deployed to the Active AppEngine and necessary files
have not been installed on the Standby AppEngine yet, or 3) the Standby AppEngine has
lost communications over the RMC before it could complete synchronizing data. Typically,
the AppEngines partner is in one of the following states: Active-Standby not Available,
Active, or Standby- Missed Heartbeats.
Standby - Ready: The state of an AppEngine when is has completed synchronizing code
modules and checkpoint data with the Active AppEngine. In this state, the AppEngine
monitors for Active AppEngine failure by verifying heartbeat pings received from the
Active engine, checks that all files required for execution are in sync with the Active
engine, and receives the following from the Active AppEngine: checkpoint change data,
subscription-related notifications, alarm state changes, and history blocks.
Standby - Sync'ng with Active: The state of an AppEngine when it is synchronizing code
modules with the Active object. If code modules exist on the Standby computer that do not
exist on the Active node, they are uninstalled, and likewise, any code modules that exist
on the Active node but not on the Standby node are installed. Once all code modules are
synchronized, the AppEngine transitions to Standby-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
9-11
9-12
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.
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
See the following table for a matrix of allowed operations based on specific conditions.
Deploy Both Primary
and Backup Objects
Cascade Deploy
Allowed
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
No
Yes
No
Yes
Condition
9-13
9-14
Condition
Cascade Deploy
Allowed
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.
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.
Wonderware Training
Objectives
Upon completion of this lab you will be able to:
z
9-15
9-16
to ArchestrA
to RMC
b. Use the network connections Advanced Settings to make sure that the ArchestrA
connection is access before the RMC connection.
c. Assign an IP address to the RMC in a different subnet than the ArchestrA connection.
Important! The IP address for the RMC connection on both computers must be different but in
the same subnet.
d. On the Advanced setting for TCP/IP, configure the RMC connection to not Register this
connections addresses in DNS.
Configure the GRPlatform objects Redundancy message channel IP address with its own
RMC IP address.
g. Create a new instance of the $tWinPlatform template named Platform_001 and assign it to
the ControlSystem area.
h. Configure the Platform_001 object with the name of the second computer and its own RMC
IP address for the Redundancy message channel IP address.
i.
Configure the AppEngine object for Redundancy and assign its backup to the Platform_001
object.
Wonderware Training
k. Using the watch list created in Lab 5, add a new watch window called Redundancy and add
the following attribute references:
Instance
Attribute
AppEngine
Host
AppEngine
Redundancy.Identity
AppEngine
Redundancy.Status
AppEngine
Redundancy.PartnerPlatform
AppEngine
Redundancy.PartnerStatus
AppEngine
Redundancy.FailoverOcurred
AppEngine
Redundancy.ForceFailoverCmd
l.
m. Force a failover in the system and monitor the data using Object Viewer and the different
watch windows created during the class.
9-17
9-18
to ArchestrA
to RMC
This is an optional step that enables you to easily identify each connection in this class
environment.
Wonderware Training
4. In the Advanced Settings dialog box, Adapters and Bindings tab, make sure that the
ArchestrA connection is listed before the RMC connection and then click the OK button to
close the dialog box.
and
9-19
9-20
6. In the RMC Properties dialog box, General tab, select the Internet Protocol (TCP/IP) item
and click the Properties button.
7. At the Internet Protocol (TCP/IP) Properties dialog box select the Use the following IP
address option and assign an IP address in a different subnet than the ArchestrA connection.
Wonderware Training
Important! The IP address for the RMC connection must be different on each computer but in
the same subnet, and on a different subnet than the ArchestrA node.
Note: In this example the first computer will have an IP address of 192.168.1.1 and the
second computer will have an IP address of 192.168.1.2. Both will be have a subnet mask of
255.255.255.0.
9-21
9-22
12. Click the OK button to close the Internet Protocol (TCP/IP) Properties dialog box.
13. Click the Close button to close the RMC Properties dialog box.
Wonderware Training
17. Click the Save and Close button and check in the object.
18. Create a new instance of the $tWinPlatform template named Platform_001.
9-23
9-24
Wonderware Training
26. Click the Save and Close button and check in the object.
27. In Deployment view, assign the automatically created AppEngine (Backup) object to the
Platform_001 instance.
9-25
9-26
Host
Redundancy.Identity
Redundancy.Status
Redundancy.PartnerPlatform
Redundancy.PartnerStatus
Redundancy.FailoverOccurred
Redundancy.ForceFailoverCmd
Wonderware Training
You can use the Mixer1 watch window to verify that the objects are running properly.
36. Failover the system doing any of the following on the second computer:
z
You can use the Mixer1 watch window to verify that the objects are running properly.
9-27
9-28
Wonderware Training
Section 2 DI Redundancy
Section 2 DI Redundancy
Section Objective
z
This section covers the concept of redundancy, how it can be configured and key points
to more effectively implement this feature.
This section provides an understanding of the concept of redundancy, how it can be configured
and key points to more effectively implement this feature. It also provides an understanding of the
concept and functionality of Redundant DI Objects
Redundant DI Objects
Application Engines can host Redundant Device Integration Objects (DI Objects). The
RedundantDIObject monitors and controls the redundant DIObject data sources. Unlike redundant
AppEngines, individual DIObject data sources do not have redundancy-related states. For all
intents and purposes, they function as standalone objects.
Only one DIObject data source provides field device data through the RedundantDIObject at a
time. Both data sources must have commonly configured DAGroups which are reflected in and
channeled through the RedundantDIObject, which monitors the two DIObject data sources and
determines which one is Active at any given time. Both data sources must also have the same
item address space.
The Redundant DI Object is a DINetwork Object used to enable continuity of I/O information from
field devices. The Redundant DI Object provides the ability to configure a single object with
connections to two different data sources. If the primary data source fails, the Redundant DI
Object automatically switches to the backup data source for its information. There is a one-to-two
relationship between an instance of the Redundant DI Object and the running instances of the
source DI objects; that is, for each Redundant DI Object, a pair of source DI Objects is deployed.
9-29
9-30
6XSHUYLVRU\1HWZRUN
',B
$(
3ODWIRUP
$SSOLFDWLRQ6HUYHU
',B
'$6HUYHUB
'$6HUYHUB
$%7&3
'+
&RQWURO1HWZRUN
3/&
Configuration RedundantDIObjects
Configure redundancy in data acquisition objects in the ArchestrA IDE through their editors. Data
acquisition redundancy objects (two DIObjects and the RedundantDIObject) do not have
redundancy-related deployment statuses.
In data acquisition redundancy, you must configure all three components: a Primary DIObject data
source, a Backup one, and a Redundant DIObject.
Because data acquisition redundant components are essentially standalone objects, all valid
operations that apply to any other ApplicationObjects apply to the three objects. All ArchestrA IDE
commands, Galaxy Dump and Load functions, and import and export operations are valid on the
two DIObject data sources and the RedundantDIObject.
The main focus of RedundantDIObject configuration is:
z
Setting the Primary DI Source and Backup DI Source on the General tab of the objects
editor.
Setting up the common scan groups, and block read and block write groups on the
respective tabs of the objects editor.
Note: You must configure at least one scan group before you can deploy the RedundantDIObject.
Also, only scan, block read, and block write groups shared by the Primary and Backup DIObjects
should be configured in the RedundantDIObject.
Wonderware Training
Section 2 DI Redundancy
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.
9-31
9-32
Wonderware Training
Objectives
Upon completion of this lab you will be able to:
z
9-33
9-34
Configure DI Redundancy
a. Create two new instances of the $tAppEngine template, name them AppEngineDI1 and
AppEngineDI2 and assign them to the ControlSystem area.
b. Host AppEngineDI1 on the GRPlatform platform and AppEngineDI2 on Platform_001
platform.
c. Rename the InControl instance as DIO1 and host it on the AppEngineDI1 engine.
d. Create a copy of the DIO1 object by repeating Lab 6 but naming the object DIO2. Assign the
new object to the ControlSystem area and host it on the AppEngineDI2 engine.
e. Derived a new template from the $RedundantDIObject object, name it $tRedundantDIObject,
and assign it to the Training template toolset.
f.
DIO1
Backup DI source:
DIO2
h. In the Scan Group tab, copy the common scan groups and attributes from the primary or
backup DI sources.
i.
k. Using the watch list created in Lab 5, add a new watch window called RDIO and add the
following attribute references:
Instance
Attribute
InControl
DISourcePrimary
InControl
DISourceBackup
InControl
DISourceActive
InControl
DISourceStandby
InControl
StatusPrimaryDISource
InControl
StatusBackupDISource
InControl
ConnectionStatus
InControl
SwitchReason
InControl
ForceFailoverCmd
l.
Wonderware Training
9-35
9-36
Configure DI Redundancy
1. Create two new instances of the $tAppEngine template.
2. Name the new instances AppEngineDI1 and AppEngineDI2 and assign them to the
ControlSystem area.
Wonderware Training
7. Use Lab 6, Connecting to the Field to create another device integration object, but name it
DIO2 instead of InControl. Assign it to the ControlSystem area.
Note: You can export your object, rename the original, and then import the object to create a
copy of the object with all of the original objects configuration attributes.
9-37
9-38
10. Create an instance of the $tRedundantDIObject template named InControl and assign it to
the ControlSystem area.
Wonderware Training
Note: The template name InControl is used here to match the existing attribute references that
were configured in the objects and scripts in previous labs.
DIO1
Backup DI source:
DIO2
9-39
9-40
14. In the Copy Common Scan Groups dialog box, click the OK button to accept tagname as
the scan group for the new InControl object.
Wonderware Training
16. Click the Save and Close button and check in the object.
9-41
9-42
Wonderware Training
DISourcePrimary
DISourceBackup
DISourceActive
DISourceStandby
StatusPrimaryDISource
StatusBackupDISource
ConnectionStatus
SwitchReason
ForceFailoverCmd
SwitchCnt
27. Failover the system doing any of the following on the second computer:
z
9-43
9-44
You can use the Mixer 1 watch window to verify that the objects are running properly.
Wonderware Training
9-45
9-46
Wonderware Training
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.
9-47
9-48
Wonderware Training
Objectives
Upon completion of this lab you will be able to:
z
9-49
9-50
Create a platform instance named ABPlatform where AB is your initials and assign it to the
ControlSystem area.
j.
Create an engine instance named AppEngineDI and assign it to the ControlSystem area.
Wonderware Training
Create an area instance named ABLine and host it on your ABAppEngine object, where AB
is your initials.
u. Create an instance of your mixer template and name it properly with the valid 3-digit mixer ID
at the end (ABMixer_1XX) as identified in Lab 2. Host it on your ABLine area, where AB is
your initials.
v.
w. Use Object Viewer to verify that all objects are running properly and are getting data from the
field.
Note: Feel free to experiment and play around with the multi-node system to reinforce the
knowledge acquired during this class.
9-51
9-52
Wonderware Training
Appendix A
A-2
Wonderware Training
A-3
A-4
Wonderware Training
A-5
A-6
Wonderware Training
A-7
A-8
Wonderware Training
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).
A-9
A-10
Wonderware Training
Appendix B
B-2
Wonderware Training
B-3
The Plant Model Planning Diagrams are displayed on the following pages.
B-4
Wonderware Training
B-5
B-6
Wonderware Training
B-7
B-8
Wonderware Training