Base Template Library 2014.0.0.2.1 Users' Guide

Base Template Library
Users’ Guide
Version 2014.0.0.2.1
Brought to you by…

The Solutions Architects (North America) of
Released: 12/15/2014
Table of Contents
Introduction .................................................................................................................................................. 4
History ....................................................................................................................................................... 4
Audience ....................................................................................................................................................... 5
Architecture Fundamentals .......................................................................................................................... 5
Automatic I/O Binding .......................................................................................................................... 5
Preconfigured Model ............................................................................................................................ 5
Model Exposure .................................................................................................................................... 5
Self-Referencing Attribute Data ............................................................................................................ 6
Retentive Values Capability .................................................................................................................. 6
BTL Use – Core Guideline(s) .......................................................................................................................... 6
Getting Started.............................................................................................................................................. 7
Acquiring ................................................................................................................................................... 7
Installing .................................................................................................................................................... 7
New Solutions/Galaxies or Upgrading ...................................................................................................... 8
What NOT To Do ....................................................................................................................................... 9
BTL Versioning......................................................................................................................................... 10
BTL Version Examples: ........................................................................................................................ 10
Versioning of the Custom Script Function Library .............................................................................. 12
Version History .................................................................................................................................... 12
Why a Custom Script Function Library? .................................................................................................. 12
Special Upgrade Considerations ............................................................................................................. 13
Architectural Recommendations ................................................................................................................ 14
Template Derivation ............................................................................................................................... 14
Runtime Model Architectures................................................................................................................. 16
Deployment View Architectural Recommendations .......................................................................... 17
Model View Architectural Recommendations .................................................................................... 17
Device Integration Architectural Recommendations.......................................................................... 19
BTL Features Detail ..................................................................................................................................... 22
Automatic I/O Binding ............................................................................................................................ 22
I/O Binding Overview .......................................................................................................................... 22
I/O Binding Options............................................................................................................................. 23
BTL 2014.0.0.2.1 Users’ Guide 2

I/O Binding Examples .......................................................................................................................... 29
Using DI Object Alias Tables ................................................................................................................ 39
Namespace Model Exposure .................................................................................................................. 39
Application Objects ............................................................................................................................. 40
Area Objects ........................................................................................................................................ 41
Self Referencing Attribute Data .............................................................................................................. 42
Retentive Values ..................................................................................................................................... 45
Additional Components .......................................................................................................................... 46
$mDatabaseConnectionSetup ............................................................................................................ 46
Delivered Object Details ......................................................................................................................... 47
System Objects.................................................................................................................................... 47
Device Integration / Data Access Objects ........................................................................................... 50
Application Objects ............................................................................................................................. 51
Support ....................................................................................................................................................... 61
What’s New… .............................................................................................................................................. 61
2014.0.0.2.1 ............................................................................................................................................ 61

Introduction
The BTL (Base Template Library) is provided as a free utility for Application Server galaxy designers as a
way to increase customer knowledge of best practices and to decrease the time required to get a galaxy
functioning properly within production and/or design environments. It contains numerous
preconfigured Application Server objects that possess the most common functionality galaxy designers
build into their solutions.
History
In 2003, Wonderware introduced Application Server to the manufacturing and service oriented
industries. With this introduction, and through its subsequent releases, many system designers have
realized the numerous benefits Application Server has to offer, such as its ability to create templates of
functionality and reuse those templates to decrease the overall engineering effort; it’s ability to derive
templates from templates to add incremental functionality and to simplify system maintenance; it’s
ability to execute the system as a whole on a single node, or across multiple nodes through simple drag-
and-drop operations; and much, much more.
And while these many benefits provided system designers and users with many new and powerful
capabilities that enabled them to improve their processes and more easily maintain their supervisory
systems, its object oriented architecture was something that was entirely new to many in the market...IS
something that continues to be new to many in the market.
As with all new technologies and new technological architectures, a learning curve presented itself.
That is, there is some amount of time that must be invested in understanding these new technologies in
order to realize the possible benefits. With Application Server this came in the form of not only
understanding numerous new terms—like Areas, Platforms, Engines, Objects, derivation, and many
more—but also understanding the execution environment—where objects execute under engines and
engines are hosted by Platforms, but all these things can be organized under areas, depending on how
you looked at the system.
Obviously, training is a critical piece to minimizing this learning curve. However, the goal of training is to
educate the system designer so that they are aware of the components of the system and how they
work together. And while extremely important, training alone cannot provide the system designer with
the other critical element: experience. Where training provides users with the knowledge of what can
be done, experience enables them to understand when and where those things should and should not
be done.
In an effort to minimize the amount of time system designers needed to invest in gaining experience
with Application Server, and to ensure systems utilized the best possible architectures, the BTL (Base
Template Library) was created. The intent was to provide system designers with preconfigured
functionality that is commonly needed, and to deliver that functionality in the best possible way; using
the best practices that have been developed through the experience of experts. In other words, the BTL
was created as a stepping stone to greater experience. It enables system designers to design and deploy
systems more quickly and easily, and to make use of best practices that have been discovered through

the experience of others. It was not, however, created to enable people with no knowledge or
understanding of Application Server to be successful. Users of the BTL must have at least a basic
understanding of Application Server and its components.
This document details the features and functionality contained within the BTL, and is intended to guide
system designers in the use of its many components.
Audience
This document is intended for use by galaxy designers already familiar with the core concepts and terms
associated with the Application Server. As such, this document does not provide basic concept details
(such as the purpose for an Area, the definition of a WinPlatform , etc).
Architecture Fundamentals
The BTL delivers key functionality often times needed during the design and configuration of Application
Server solutions. It does this through the use of preconfigured object. The key to these capabilities are
the Master template objects found within the BTL galaxy, which deliver specific functionality, but do so
in a generic way that can be applied to virtually any environment. These master templates deliver
functional capabilities as follows:
Automatic I/O Binding

Many Application Server components deal with the acquisition of data that exists outside of
Application Server (typically in process controllers like PLCs). The process of acquiring these
data points has traditionally been manual; requiring the system designer to manually define
each point within the galaxy, and then define how to acquire the desired data from the
controller. The BTL provides system designers with the ability to automate this process. Each
BTL galaxy object contains configurable settings that enable this automated process to be
flexible enough to meet the demands of almost any system.
Preconfigured Model
A preconfigured collection of objects have been organized for you in order to demonstrate the
appropriate configuration and organization of configuration related objects. From this most
basic model, organizations and system designer can then extend the model to properly
represent their operating environments. Why provide this…what value is there? Most
inexperienced system designers (and even several experienced ones’) don’t know how to
organize these components and thus cannot realize the benefits of an intentional architecture.
Model Exposure
The components of every App Server galaxy are organized into a logical, hierarchical model, to
make it easier for users to locate the information they need. This model can provide significant
value in not only data analysis, but also in the logic and execution of the App Server objects

themselves. The BTL helps expose this “model” so that the individual objects of a galaxy can
more easily navigate and access related components in the galaxy.
Self-Referencing Attribute Data

Application Server objects typically contain numerous data points—called attributes—that are
modeled to represent actual equipment, assets, and processes. The BTL exposes these by
grouping similar attributes of an object together. This enables system designers to more
efficiently and effectively get to the data they need and to design systems that offer greater
value from both an information analysis and execution standpoint.
Retentive Values Capability

The BTL adds to the core functionality of App Server by enabling objects to store their attribute
data to disk before the system is shutdown. Then, when the system is restarted, these data
points can be read from file and assigned an initial value from the file. This can significantly
reduce initialization code and help to simplify the object design process. Application Server has
the ability to do much of this on its own (through the use of its checkpoint files); but the BTL
provides an example of how this capability can be extended for more specific control and
utilization.
Additional Components
The BTL also provides a handful of additional object templates to help with some of the more
common needs found within galaxies. These elements, like the Database Connection Setup
template, are detailed in the Additional Components section.
These capabilities are delivered through the implementation of preconfigured Application Server
objects—developed using best practices for consistent and efficient execution. The BTL also
demonstrates various best practices in regard to template derivation, model instantiation, and more.
BTL Use – Core Guideline(s)

In order for the BTL to be most effective and beneficial to all users, certain guidelines must be adhered
to when making use of the BTL. While there are a number of guidelines that are discussed throughout
this document, there is only one “rule of engagement”, or hard-fast rule that MUST be followed:
Master level templates of the Base Template Library are not to be modified by system designers
and/or users of Application Server. These templates are created and maintained by Wonderware
personnel (App Server ninjas). Master templates can be identified by their template name. Any
template that contains an “m” at the beginning of their name is a master level template. For
example, $mWinPlatform or $mUserDefined. Please do not modify these, or any other master
level templates.
Starting with the 2014 release of Application Server and the BTL, the master level templates are
provided “protected”; which means they are read only anyway, and the above bold type should be
unnecessary. However, just in case you thought it was only a suggestion, it is not. Please do not modify

the master level templates. If you need to change the core behavior of the BTL objects, documentation
exists which provides an example of how to do this without modifying the master templates.
Obviously, the intent behind the BTL is to provide built-in functionality that has been tested for both
execution and optimal performance. In order to make use of these preconfigured templates, simply
derive you own “User Level” template from the masters, and then add whatever additional functionality
you desire.
Getting Started
Acquiring
The BTL, along with this manual, can be downloaded from the WDN (Wonderware Developer Network)
website (wdn.wonderware.com), in the Demo Application Download section.
Installing
The BTL can easily be available for use within new or existing galaxies through two simple steps. The
steps for accomplishing this are:
First, a custom script function library is needed for the BTL to function properly. This library doesn’t do
anything fancy or super-secret. All it does is more quickly iterate through large lists of string values and
provide more efficient parsing needed by the BTL for its automatic I/O reference assignments and model
building tasks. So the first step is to import this library into your galaxy. This is accomplished by
selecting the Galaxy menu from within the IDE and selecting Import  Script Function Library. In the list
of files types to import, select the “aaSLIB” type/option. Next, navigate to the location where you
downloaded the BTL, and select the file: ww.nasc.btl.modeling.aaSLIB.
Second, you need to decide which ArchestrA Object Package you need to import. The BTL is made
available in numerous packages so that you only import the elements you need. The following table
identifies the import packages available, and describes their intended use:
File Name Description

Master Templates ONLY.aaPKG Core templates of the BTL. These are the
templates recommended for import into existing
BTL galaxies that are upgrading from previous
versions
Master & User Templates.aaPKG Core templates of the BTL and user templates
(from which system designers will create their own
templates). This is recommended for experienced
users of the BTL working with new galaxies or for
importing into existing galaxies where the BTL will
be implemented for the first time.

All Templates and Instances.aaPKG Includes everything in the previously defined
packages, plus specific object instances have been
created to demonstrate a recommended model
architecture for configuration components. This is
recommended for new galaxies and for individuals
with limited experience with the BTL.
DASABCIP Master Templates ONLY.aaPKG These master-only templates provide core BTL
functionality specifically in the ABCIP DI objects.
This package is recommended for individuals
upgrading existing BTL CIP objects. It makes use of
version 4 of the DASABCIP objects. If you are using
a newer version of the DASABCIP objects in an
existing galaxy, this is still the import to use to
upgrade galaxies that previously made use of the
BTL.
DASABCIP Master & User Templates.aaPKG This package contains everything from the
previous as well as user templates for the CIP DI
objects—from which a system designer can
configure their environment specific
communications architecture (with the BTL
functionality included). This is recommended for
individuals adding BTL DASABCIP functionality to a
new or existing galaxy.
BTLWriter Object Only This package contains a single object, which is
used for troubleshooting and debugging problems
you may encounter with your BTL derived object
configurations. In other words, when you want to
know what is going on, these objects help you
discover the source of the configuration mistake
made. THESE OBJECTS SHOULD NEVER BE USED IN
A PRODUCTION GALAXY AS THEY WRITE TO THE
HARD DRIVE CONTINUOUSLY. THEY ARE FOR
TROUBLESHOOTING / DEBUGGING ONLY!
ArchestrA Graphics ONLY.aaPKG The ArchestrA Graphics Only package simply
contains all the ArchestrA graphics that are utilized
by or within the BTL objects.
New Solutions/Galaxies or Upgrading

Are you designing a solution from scratch? Are you thinking of implementing the BTL into an existing
Application Server solution? Are you wanting to upgrade an existing Application Server solution that
already makes use of the BTL?
For any of the above questions, the answer to doing it right is relatively simple:
1) Read (or re-read) this “Getting Started” section from the beginning, and through to the end
BEFORE doing anything. Understand all the things related to getting started—like what version

you should be using of the BTL, or the reminder to always import the custom script function
library). Read the entire Getting Started section, and then come back to do step 2.
2) Verify you have the correct version of the BTL for your version of Application Server. This is
described in the BTL Versioning section.
3) Import the custom script function library. It doesn’t matter if your galaxy had it before…if you
are upgrading, you need the latest script function library. If you are building a new solution
from scratch, you need the script function library.
4) Decide what type of installation you will be working with, and select the proper package. The
packages are described (and their intended us) in the table below the Getting Started title. For
example, if this is a new galaxy or a new implementation of the BTL objects into an existing
galaxy, then you will most likely want the “All Template & Instances” package, or the “Master
and User Templates” package. If this is an existing BTL based galaxy and you are simply wanting
to upgrade it to the latest, you will want the “Master Templates Only” package (and possibly the
“DASABCIP Master Templates ONLY” package if they were already in use in your galaxy).
That really is it. Well, except for the following section that explains what NOT to do…it’s important too.
What NOT To Do
The BTL does not provide a magical world where everything is configured for your environment out of
the box. What it does provide is the ability to more quickly, easily, efficiently, and SUCCESSFULLY design
Application Server solutions. So you will need to utilize the BTL appropriately in order to gain any
benefit or value from it. In order to do that, you should obviously read this manual…but there are a
handful of specific things you should NOT do:
1) You should not jump in and “play” around with the BTL without first reading through this
manual. It may seem ridiculous to say so (here in this manual)…but we literally created this
manual because people first tried playing around ended up with questions. So…now you can
came back to the documentation to understand it, rather than doing the inefficient trial-and-
error methodology. Reading through this manual will help provide you with information
necessary to be more successful.
2) As is stated in the BTL Use – Core Guideline(s) section, Master level templates are not to be
modified by galaxy system designers and/or users of App Server. See that section for details.
3) Never perform an “Upload Runtime Changes” within a BTL galaxy, as this will cause the BTL to
not function properly. Doing so will overwrite attributes of the BTL that are utilized to control
script execution order, automatic I/O assignment, modeling data, and much more. Executing an
“Update Runtime Changes” will break the BTL and result in an inconsistent execution
environment for your galaxy as well as dramatically increasing the resource needs of the system
(dramatically decreasing the efficiency). If you find yourself trying to recover from a scenario
where someone did perform an upload runtime changes, simply read the BTL Troubleshooting
Guide, which contains details about the default values for the various attributes and working to
return things to “normal”.

BTL Versioning
So how do you know what version of the BTL to use, or even to download? These sub-sections describe
this in greater detail.
The BTL version (posted online with downloads, and included in any documentation, package files, etc),
is comprised of 5 sets of numbers that are separated by a period. Those 5 number sets are:
 [Major Version of App Server]

 [Minor Version/Release of App Server]
 [Service Pack #]
 [Thousand’s Place of Master Templates’ “ConfigVersion”]
 [Hundred’s Place of Master Templates].
BTL Version Examples:
Example 1: 1.2.300.4.5
In this example, the first number set is 1; which indicates that this BTL version works with Application
Server version 1
The second number set is 2 (two). It indicates that this BTL version was tested against the “R2” release
of version 1, but not with any later releases (not R3, R4, etc.)
The third number set is a 300. This indicates that this version of the BTL was designed, developed,
and/or tested and is supported with the Service Pack 3 (for Application Server 1 R2)
While all the previous number sets helped us pick the right version for importing into an Application
Server galaxy, the last two numeric sets are used to help everyone know if the right templates were (and
still are) in use within an Application Server solution. In other words, how do you or anyone else know if
the right version really was imported into the galaxy? The answer is that we document that with the
fourth and fifth number sets. The fourth number set, which in this case is a 4, represents the thousands
place of all Master templates’ “ConfigVersion” (more on that shortly). The fifth number set, which in
this case is a 5, represents the hundreds place of all Master templates’ “ConfigVersion”. In other words,
if you were to look at the properties of ANY of the MASTER templates of the galaxy, and you click on the
“Attributes” tab, you would find the value of 4500 in the “ConfigVersion” attribute.
Let’s try a more recent example…
Example 2: 2014.0.0.2.0
This BTL Version should be downloaded and used in solutions making use of Application Server 2014
(not R2, but the initial release because the second number set is a 0), with no Service Packs (because the
third number set is a 0); and if you were to look at the “ConfigVersion” of any of the Master Templates
you imported from these BTL packages, they will have a “ConfigVersion” of 2000; as you can see in the
following example:

Last example/scenario: You are asked to help someone add some new capabilities to an existing
Application Server solution, and perhaps asked if you would be able to also help improve the
consistency and performance of the solution as well. After taking a look at the galaxy, you may decide
to use the BTL; but in order to know what version of the BTL to use, you need to know the version of
Application Server. So you look at their solution and discover they are running 2012 R2 with no Service
Pack. To get the proper version of the BTL, you only need to go to the WDN website and locate the BTL
download with a version of 2012.2.0. You don’t care about the last two digits because you are not
interested in what the Master Level templates will be in that galaxy. However, if the full BTL version is
2012.2.0.1.7, then you would know the Master level templates would have a value of…?

Hopefully you said “1700”.
Versioning of the Custom Script Function Library

How do you (or anyone else) know if the right version of the Script Function Library was imported into a
galaxy? How do you know someone hasn’t upgraded the version of Application Server, and whether or
not they updated the custom script function library? The answer is simple: just ask the script function
library. How? Create an OnScan script in any object, and in the body of the OnScan script, enter the
following:
LogMessage(ww.nasc.btl.modeling.aaObject.GetLibraryVersion());
This will write a message to the logger (when you deploy the object) that specifies the version; like this:
To know what full BTL version that was associated with, simply look on WDN for the BTL downloads, and
match it to the version ending it “1.9”. One and only one version will end in 1.9; and in this case, it’s
2014.0.0.1.9.
Version History
For a listing of the changes that have been made from version to version, the BTL also provides an object
template named, “$BTLVersionInfoDummyObject” (found within the _BTLVersionInfo template toolset).
To view the version change information, simply open this object template and click on the “?” icon in
the upper right-hand area of the object editor. This object (and its parent) should never be instantiated
or modified by system designers. It is provided simply as a means of documenting (within any BTL
solution) the change history of the BTL.
Why a Custom Script Function Library?

The 2012 release of the BTL was the first to make use of a custom script function library. As stated
earlier, this library doesn’t do anything fancy or super-secret. All it does is more quickly iterate through
large lists of strings and provide more efficient parsing needed by the BTL for its automatic I/O reference

assignments, and model building tasks. So why not do all that within Application Server scripts? Quite
frankly:
1) Because a complied DLL is faster at it than native Application Server scripting. Lots faster?
No…but if a galaxy is going to assign 2,000,000 I/O addresses, and each one takes a nanosecond,
then it will take more than 2 minutes to assign all the I/O addresses. By using a precompiled
library (the script function library), we were able to reduce the time by about 50% (or more).
That kind of efficiency gain was worth using the custom library for our customers with very large
galaxy solutions
2) The scripting within the BTL is simplified considerably when using a DLL/library to do some of
the heavy lifting. In other words, the same effective scripting is possible within Application
Server, but requires considerably more lines of code (no recursive calls or calling of quick
functions).
So…we found a way to make the BTL faster and simplify some of its scripting; but we also found that the
addition of the custom script function library made a few people uneasy. Why? Many system designers
are still not 100% familiar with (or comfortable with) the creation of their own DLL’s, libraries, or
trusting what other put in a library. In order to deal with these concerns, we include the original raw C#
code in all BTL downloads. This enables individuals that desire to do so, the ability to better understand
what functions are provided by the custom script function library.
Special Upgrade Considerations

One final note on upgrading galaxies to newer versions of the BTL…starting in Application Server 2014,
object designers could export objects a “protected”; which is what was done with the BTL objects to
help ensure changes were not made to the Master templates. Because these objects were exported as
protected, and earlier versions of the BTL objects were not (the functionality did not yet exist), you will
need to uncheck (deselect) one of the default import options when importing the BTL into your galaxy.
Specifically, deselect the option labeled, “Never overwrite an upprotected object with a protected

object”; as is shown in the following image:
This will ensure the latest BTL objects are imported successfully. As always (anytime you perform an
import of objects into a galaxy), please make sure you read the import log shown to verify the proper
objects were updated—which in the case of a BTL Upgrade, should be all the Master level templates.
Architectural Recommendations
Providing architectural recommendations can be a double-edged sword. On one side, it can significantly
help reduce the design time and help to ensure both galaxy designers and users have the best possible
experience. On the other side, it can add confusion to individuals with little experience. This section
provides recommendations for a variety of architectures that can be used in an Application Server
implementation, but does not represent every possible best practice and/or design strategy that can be
successful.
Template Derivation
One of App Server’s most powerful features is the ability to create templates of functionality. While a
single template can contain all the attributes, logic, and capabilities necessary to be all things to all
people, this type of design results in a complex objects that suffer from execution inefficiencies, are
difficult to maintain due to their complexity, and are prone to user configuration errors. To minimize
complexity and the potential for configuration error, and to produce objects that execute efficiently,
objects should be designed with concise functionality in mind. However, as with all things, there is a
balance that must be established between too little and too much functionality within a single object.
Objects that provide too little functionality result in a galaxy that contains so many objects that system
designers have difficulties locating objects; and produce galaxies with overly complex derivation and/or

instantiation models. The “balance” is something that each system designer must identify themselves;
the line between functionality and performance.
The best possible scenario for objects that fulfill more than one function is to incrementally add
functionality. This is accomplished through template derivation. Derivation is the function of creating a
new template object from an existing one; thus establishing a parent-child relationship between objects
(where children inherit the capabilities of their parent, while also introducing new capabilities within
themselves).
It is has been identified that certain architectures of derivation are more productive than others. In the
BTL, a minimum of three levels of derivation are always employed. The base object templates that are a
part of all Application Server galaxies are the first level. It is not possible to modify these templates.
The second level—used by the BTL—are the “Master” or “m” level templates. All templates at this level
start with the letter “m”. For example, “$mWinPlatform”, “$mAppEngine”, and “$mUserDefined” just
to name a few.
These Master templates provide all the BTL functionality and should NOT be modified by persons
making use of the BTL. If the templates provided by the BTL provide value and system designers wish to
use them in their galaxies, they should derive new templates from the masters. Templates derived from
the BTL Master Templates are identified in this document as User Level Templates. It is customary for
system designers to prefix these templates with a character sequence that identifies them as unique to
the organization using them. For example, the Wonderbrew Corporation might derive a new template
from $mUserDefined, and name it “$wbUserDefined” (where the “wb” references “Wonderbrew”). This
is the third level of derivation, and is the minimum level where system designers should begin
implementing their own customizations within templates (and for eventual instantiation of runtime
objects).
One measure that can be employed to ensure objects do not become overly complex is to count the
number of field attributes and user defined attributes. Field attributes, which are unique to the User
Defined objects, are powerful attributes that contain numerous attributes themselves (ie: How to access
external data, a description for the attributes, the engineering units, and much more). When possible, it
is recommended that the number of field attributes be limited to a maximum of between 40 and 60.
While objects support a higher number, this recommendation helps to ensure the total number of
attributes in an object remains low enough to ensure efficient object execution in runtime. User defined
attributes, while not as complex as field attributes, should also be limited to a reasonable number as
well; typically less than seventy-five to 100. Again, the objects can support many more attributes than
this, but these recommendations provide a good first-glance estimate to how “busy” and “complex” an
object may be.
The balance, therefore, is up to the system designer. All architectures should be tested for design-time
and runtime execution efficiency; benchmarking various designs and selecting the model that provides
the best balance and performance.

Runtime Model Architectures
Within App Server, object instances are the components that gather inputs and outputs, historize data
to a common data repository, execute logic (scripts), and perform various other functions. These
objects are organized in two different views: Deployment and Model.
The Deployment View identifies the node (or computer) where each object is executing. This “view”
enables system designers to distribute the work of the objects across one or more machines quickly and
easily; to fully utilize the computing resources available within a facility.
The Model View identifies the logical organization of a process; oftentimes implemented in a hierarchy
that enables users to most easily locate information. The Model View has nothing to do with WHERE
the objects are executing, but instead, provide users with the ability to look for information from a
logical standpoint. The following image provides example of both views
In the example image, the galaxy is currently deployed to two different nodes (GR_Platform and
INFO_Platform). Each of these nodes has multiple “objects” executing, providing all the capabilities of
the system as a whole. The model view, however, identifies the components of the system from a
logical standpoint; organized into a hierarchy. This hierarchy separates the system elements from the
process elements (in the “SystemObjects” area and the “WonderbrewCorp” area). Within each of these
areas, additional areas further differentiate the function of the objects they contain. This enables, for
example, users to most easily locate information relating to the roaster; as they are able to drill down
through The Galaxy, to the Wonderbrew Corporation, and finally to the Roasting area. To locate the
same information in the Deployment View, the user would have to know the node (or computer) where
the object is current executing. Both views provide significant value, depending on the role of the

person looking at the information. Numerous best practices can be applied to both object deployment
and system modeling.
Deployment View Architectural Recommendations

As was stated earlier, the deployment view focuses on WHERE objects are running. The top most
“node” or element of the deployment view contains platforms (or computers) where the objects are
running. Within each platform, engines are used to segment objects into execution groups. View
Engines represent the execution environment for InTouch visualization applications. Application
Engines represent the execution environment for all other galaxy objects.
All the objects contained within a single Application Engine execute on a scheduled period; specifically
defined as the Scan Time of the Application Engine. The architectures of the computing resources
available today often times provide nodes with considerable horsepower. That is, these resources often
times contain multiple processors (or cores), large memory reserves (RAM), as well as storage capacity
(hard disk space). App Server can take advantage of these resources most effectively when
implemented properly.
The most effective architecture that makes use of these resources is one that uses multiple Application
Engines under each Windows Platform object. Each Application Engine represents a process on the
computer (aaEngine.exe); and the objects owned by that engine execute under this process. Therefore,
by creating multiple Application Engines, the multiple processors (or cores) of a system are most
effectively utilized. The memory allocated to each process is also protected; ensuring that if problems
encountered, they can be isolated to a limited number of objects.
In the example image provided earlier, all Device Integration objects are executing under a single
Application Engine. Further performance increases may be realized by segmenting the execution of the
Device Integration objects into yet another Application Engine. The optimal configuration can be
attained through further testing. Initially, deploying all objects into a single engine can provide a
mechanism for benchmarking the performance of all objects when run together. The architecture can
then be modified to split the object execution between two engines. Again, the performance of each
engine should be monitored. Once observed, additional engines can be created and the objects split
further between them; again measuring the performance (CPU utilization, RAM usage, etc). At some
point, the benefit of splitting these objects between more and more engines will degrade, and this
information can be used to identify the optimal execution configuration (or number of engines across
which the objects should be “split”).
Additional factors can influence how many platforms and engines are used—like I/O or Engine
redundancy configurations—however, it is recommended that system designers utilize multiple engines
within each platform, and test their configurations to identify where they can achieve the greatest
performance.
Model View Architectural Recommendations

Application Server makes use of Area objects to separate application objects into logical groupings.
These Area objects not only make the grouping of like components together easier, but also act as alarm

concentrators (enabling alarm and event information to be filtered most effectively). While no two
processes will be modeled the same, some modeling architectures can provide greater value than
others.
The BTL is delivered pre-configured with a number of area and object instances organized into a logical
model. As it is not possible to pre-configure the BTL to satisfy every possible manufacturing
environment or service delivery model, the BTL’s pre-configured instances only focus on the
components that are common to all systems. The following image provides an example of these Areas
and their object instances.
The SystemObjects area, and its contained areas, are provided to enable the separation of computer
and configuration elements and their execution from the process-related objects. Platforms, Engines,
View Applications ,etc, are able to be organized within this preconfigured model in a way that not only
enables them to be most easily located, but also in a way that enables alarming conditions that may be
encountered with these elements to be better filtered for display to interested parties. For example, IT
(Information Technology) specialists may not be responsible for the supervisory system, but they are
often times responsible for the computing equipment used in supervisory systems. Under the BTL
model, they are able to focus their attention on alarms pertaining to the platforms and engines, thus
exposing only the information that is relevant to their areas of expertise.
System designers making use of the BTL only need to add a new Area for their organization under the
existing model (specifically under the “theGalaxy” area) to continue making use of this model. The
following image provides an example of how this might be implemented for a company called
Wonderbrew with multiple manufacturing sites.

In this case, the system designer created an area for the company, and placed it under the “theGalaxy”
area (named “WonderbrewCorp”). They then created an area specific to the manufacturing site for
which the galaxy was related (“NewYorkPlant”). Then, under this area, they added all the additional
areas related to their manufacturing process (Roasting, Mashing, Brewing, etc).
While an almost limitless number of models can be created and implemented, the above example has
proven valuable to many App Server and System Platform users. Before starting a new App Server
project, it is strongly recommended that both the deployment (execution) model and the logical models
be considered before doing any development work.
Device Integration Architectural Recommendations

DI (Device Integration) Objects are specialized types of objects that retrieve data from outside App
Server (typically through a DA or IO Server application which communicates with specific controllers).
These objects can be configured in various ways to allow all galaxy communications to flow through
them, or some limited subset of the communications. However, certain architectures have proven more
beneficial than others.
Instantiation Architectures
All too often, system designers try to accomplish too much in too few objects; and this is especially true
when it comes to DI Objects. While it is possible to funnel all galaxy communications related to a
specific controller through a single device integration object, there are a number of drawbacks to this
type of architecture. First there is the issue of what is called the “advise list”; which contains a listing of
all the points the DI object needs to collect from a controller (or from a piece of software that provides

the controller data). When using a single DI object, the process of building this list can be time
consuming and resource intensive; thus distributing the advise list across multiple objects provides
improved efficiency. Secondly, there is the issue of system maintenance. If changes are made that
require the DI object to be redeployed, all data provided by the DI object will be temporarily unavailable
while the object is redeployed, and for some period afterward while it rebuilds the advise list. In other
words, a modification needed for a change in a single area of the plant could result in all
communications going down while the DI object is redeployed.
Another disadvantage of utilizing only a single DI object per controller relates to how galaxy data is
gathered by the objects within the galaxy. Each externally referencing attribute in the galaxy must be
told what DI object provides the desired information, the name of the appropriate scan group, and the
name of the data point to retrieve from the controller. By using only a single DI object, which will
execute on a single machine (or platform), all galaxy communications are dependent on that node being
available and it’s engine function efficiently.
A more efficient and reliable architecture can be attained through the use of numerous DI objects,
spread across multiple nodes, each focusing on the gathering of controller data specific to a given
process or area. This results in smaller advise lists, enabling the DI object to execute more efficiently.
Another benefit of this architecture is that system maintenance activities that require redeployment do
not kill communications for every point in the galaxy while a single DI Object is being redeployed. In this
case, only the data points related to the DI object being redeployed will be unavailable; and the time
required for those points to again become available is lower due to the limited number of data points
flowing through it. Finally, by spreading the DI objects across several nodes, more reliable
communication architectures can be realized. DI Objects can take advantage of not only the automatic
redundancy capabilities built-in to the Galaxy (through the redundant DI object), but also the inherent
availability advantages of distributing the load across more than one node.
One common and practical design recommendation is simply to place one DI object per area. Systems
that make use of the Model View to create hierarchical structures will realize significant benefits from
placing only a single DI Object per area, and having all the objects within that area reference that DI
object. Obviously, this is only valid if the galaxy is modeled correctly. For example, if a galaxy only has a
single area, and all galaxy objects are placed in this area, then there is no benefit to having a single DI
object. However, in a galaxy that has a solid, well thought-out model architecture, this will not only
simplify communications, it will also provide better communications stability throughout the galaxy. In
this architecture, changes to a DI object that require redeployment will only affect the object within that
area; enabling the other “areas” to continue functioning uninterrupted.
The following image provides an example of this architecture implemented within the Wonderbrew
Corporation. In this example, the entire plant is run from a single controller (or at least, a single
controller acting as a data concentrator for all the controllers in the plant). Even though there is only
one controller that is being accessed, each area has its own dedicated DI object that focuses on the data
relevant to its specific functional role (like roasting, bottling, etc).

Scan-Group Configuration
Each DI Object can contain one or more scan groups. The scan groups enable system designers to
segment the communications of a single DI object further, into groups for optimal performance. Each
scan group can define when the information should be gathered (ie: all the time, only when someone is
looking at the data, etc).
While each DI Object can contain multiple Scan Groups, it is important to define these groups properly.
Multiple scan groups should be used when they are needed. This may be to separate important data
that must be updated more frequently than less important data. For example, if gathering the
production count from a controller in a low-speed process, it may make sense to only request the
information once every minute. However, pressure readings from that same process may be more
critical, and thus may need evaluated more frequently. In this situation, two scan groups may provide
the optimal communication performance. Additionally, DI Objects do have a maximum number of data
points that can be gathered within a single scan group. While this number is fairly high (32,767),
performance of the DI Object does decrease as the number of items within a scan group grows.

Anything over 5,000 typically decreases performance noticeably. This not only supports breaking the
items into multiple scan groups, but also supports the previous recommendation of utilizing multiple DI
objects.
BTL Features Detail
Automatic I/O Binding

One of the most popular features of the BTL is its ability to automatically assign I/O references to object
attributes. Utilized properly, it can save system designers hours or even days of data entry time,
eliminate typographical errors, and even help provide a system that can dynamically adjust to changing
communication architectures while minimizing the engineering effort required to make it happen. Most
simply put, the I/O binding feature is used to automatically associate object attributes with controller
(ie: PLC) registers, or other galaxy object attributes. The following sections detail how the automatic
binding works, and the options available within this feature.
I/O Binding Overview

When an object attribute is designed to gather data from another object, it is “extended” with input
and/or output reference. These references tell the attribute where to look for the data it is supposed to
represent. Each reference is actually made up of multiple parts; specifically two parts if the reference is
looking to another application server object attribute, or three parts if it is looking to a PLC register
(through a Device Integration object). All references contains these parts, which are:
Object Name
The object name tells the attribute what object in the galaxy will be providing the data. This applies to
all references (internal or external).
Scan Group
The scan group is unique to those references that are going to external registers (like PLC registers), and
is a part of all communication objects. These communication objects are called Device Integration
objects, and they all contain one or more of these scan groups. The system designer creates the Scan
Groups (sometimes called topics, or Block Read or Block Write groups). Scan groups are used to break
communications up into logical groups (for control over how quickly the data in that group is
requested/written, or to simply segment the data into easy to understand segments).
Item Name
Finally, the Item Name represents the specific piece of data this attribute should be gathering. If an
object attribute is simply pointing to another object attribute in the galaxy, then this is the name of the
attribute in the destination object. However, if the attribute is referencing a PLC register, it is the name
of the register specific to the external device.
The BTL provides a way of automatically (in runtime) determining these three pieces; the Object Name,
the Scan Group, and the Item name that should be used by every input/output extended attribute. How
does it do this?

I/O Binding Options
The BTL automates the process of assigning the references to attributes that acquire their data from
other App Sever objects or external data sources. This occurs in runtime, rather than configuration
time, enabling object attributes to bind to the appropriate data point based on the configuration options
defined within the objects themselves, and the instantiated model being used. These configurable
options identify how to assign both the name of the object providing the desired data, as well as the
structure for the attribute data (the register name to use). The BTL even provides a mechanism for
assigning the object and attribute name based on a custom configuration; which is defined within a pre-
existing script within the BTL. In such cases, the system designer simply needs to define how the
assignment should be made. This automatic I/O reference capability can be used with not only other
galaxy object attributes, but also for I/O associated with controllers. While it is most commonly used
with controllers that support hierarchical based data models, it can also be used with older style
controllers that do not.
This automatic IO reference assignment capability is delivered through a handful of scripts that evaluate
numerous configuration options. In the end, the reference created for each IO attribute is based on the
following:
[Object Name].[Scan Group Name].Atrribute([Item Prefix][Register

Name])
The following subsections provide additional details regarding the automatic IO binding configuration
options :
Object Name: The object name represents the name of the object providing the desired data, and is a
required component. It is most commonly the name of a specific DI Object, but can alternatively be any
other object within the galaxy. The configuration options that impact how the Object Name component
is assigned include: DIO.BindLevel, DIO.Name, and DIO.Name.MeConstant. For more details, see the
section on DIO.BindLevel
Item Separator: The item separator simply tells App Server the character that should be used to
separate the final register name from the other elements found in the reference. By default, the value
of the item separator is a period (“.”); but it can be changed to whatever is needed. The only
configuration option that applies to the Item Separator is the UDA named: DIO.ItemSeparator.
Scan Group: The Scan Group element is specific to those cases where the external data is being acquired
through a DI Object (which is the most common situation). As a DI Object can contain multiple Scan
Groups, it is important to define which Scan Group should be used. This assignment is made by
modifying the DIO.ScanGroupIndex UDA of the object. For more information, see the section on the
Bind Level configuration attribute.
Attribute: The Attribute keyword enables App Server to more accurately parse the register name. This
is necessary due to the variety of register name structures required by the controller manufacturers in
the market. For example, an older Allen-Bradley controller—such as a PLC 5—might require an address

to be listed at B3:0/3. The colon and forward slash characters could be misinterpreted by the
Application Server text/string parser, except that the “Attribute” keyword enables it to hand the request
to the controller “as-is”.
Item Prefix: Some controllers require a character or characters to be added to the beginning of the
register name in order to return the proper data. This configurable UDA enables the system designer to
specify one if it is needed.
Register Name: The Register Name element identifies the specific data that is wanted from the
controller (or the attribute name if looking to another App Server object). There are numerous ways the
reference can be built, and these options are controlled by the configuration of the
“DIO.ItemNameOption” attribute. For more information, see the DIO.ItemNameOption section of this
document.
Of the six (6) options that are utilized in the construction of the external reference, three warrant
further review. The following sections detail these user configurable options.
DIO.BindLevel Attribute
The DIO.BindLevel attribute is used to tell an object where to go to get the name of the DI object being
used to provide communication(s). More specifically, the DIO.BindLevel attribute is an integer; and that
integer represents 8 choices for discovering the name of the object providing communications. These
options and their details are listed in the following table:
Value Description Details

1 Disable this Setting the DIO.BindLevel to a value of 1 disables this object’s automatic
Function I/O assignment. In other words, if you do not want the BTL to bind the
object’s I/O extended attributes, set the DIO.BindLevel to 1.
2 MyPlatform Setting the DIO.BindLevel to “2” forces the object to ask the platform
under which it is running for the name of the DI object that should be
used.
The Platform contains an attribute called “DIO.Name”. It is populated by

either a BTL extended DI Object (which occurs automatically if the DI
object is configured with a DIO.BindLevel of 2) or if someone simply
enters the desired DI object name directly to this attribute of the
platform.
3 MyEngine Setting the DIO.BindLevel to “3” forces the object to ask the application
engine under which it is running for the name of the DI object that
should be used.
The application engine contains an attribute called “DIO.Name”. It is

populated by either a BTL extended DI Object (which occurs
automatically if the DI object is configured with a DIO.BindLevel of 3) or if
someone simply enters the desired DI object name directly to this
attribute of the engine.

4 MyArea Setting the DIO.BindLevel to “4” forces the object to ask the Area under
which it is running for the name of the DI object that should be used.
The Area contains an attribute called “DIO.Name”. It is populated by

either a BTL extended DI Object (which occurs automatically if the DI
object is configured with a DIO.BindLevel of 4) or if someone simply
enters the desired DI object name directly to this attribute of the Area.
5 MyContainer Setting the DIO.BindLevel to “5” forces the object to ask the application
object under which it is running for the name of the DI object that should
be used.
The containing object must be a BTL extended application object for this
option to be valid. The containing object has an attribute called
“DIO.Name”, which is populated based on its DIO.BindLevel. In other
words, this object will use the same DIO.Name as the object that
owns/contains it.
6 Me Setting the DIO.BindLevel to “6” forces the object to populate its
DIO.Name based on the value of another attribute on this object named
“DIO.Name.MeConstant”.
The “DIO.Name.MeConstant” is not automatically populated by the BTL,

and it is the responsibility of the system designer to ensure this value
gets populated (in design time, or programmatically—through a script—
that the system designer creates).
7 Use Setting the DIO.BindLevel to “7” forces the object to simpy use its own
DIO.Name DIO.Name. There are multiple ways to populate an objects own
Initial Value DIO.Name. As an example…the system designer could enter a value
(manually) during configuration time into this attribute, or create a script
to populate the DIO.Name.InputSource to the “name” of the DI object.
This option differs from the previous (6) ONLY in that this option looks to
the initial value of the “DIO.Name” rather than the
“DIO.Name.MeConstant”.
8 Link to App Setting the DIO.BindLevel to “8” is the only option that allows this object
Object to “bind” to something other than a DI object. This option was created
to enable binding to other objects for testing/simulation type of
scenarios. In otherwords, if a system designer wants to test
functionality, they can configure their objects to use a DIO.BindLevel of
8, and bind to special objects designed to simulate the desired process.
Any values entered for the Bind Level that are not listed above are invalid; and the behavior of the
object will be unpredictable.
Because each object has only a single “DIO.BindLevel”, this means that all attributes of any give object
can only connect and receive their automatic I/O assignments from a single object (DI or application).

Architectures that desire to have multiple attributes that communicate with various DI object within a
single application object need to follow a design methodology that separates these into multiple objects
that are contained by a single object. More information on this type of configuration can be provided by
your local Wonderware Technical Sales Consultant.
If the configured value of an object’s DIO.BindLevel results in the DIO.Name NOT being populated, the
BTL scripts that automatically assign I/O references will run continuously. This can have significant
performance and resource implications and should be avoided. To determine if this is happening, it is
recommended that the system designer monitor the value of the _BTL.IORefSet.ExecutionCnt. If this
value contentiously increases, a configuration error exists and should be resolved by the system
designer.
The DIO.BindLevel can only be set at configuration time. Changes to the BindLevel in runtime do not
cause the I/O references to be rebuilt/redefined. As such, if an architectural change needs to be
implemented—related to WHERE the objects retrieve the name of the object providing
communications—requires the objects to be undeployed and redeployed to take effect.
DIO.ScanGroupIndex (DIO.BlockReadIndex/DIO.BlockWriteIndex)
The DIO.ScanGroupIndex (or BlockRead/BlockWrite index of the ReadWrite object(s)) identifies which
ScanGroup (or topic) the object should use. This setting/attribute value is used when the DIO.BindLevel
is configured to interact with DI (Device Integration) objects. If, for example, the DIO.BindLevel is
configured with a value of 8, that object is not looking at IO, but at another application object and thus
the DIO.ScanGroupIndex is invalid. This setting is used to determine which scan group to use on DI
objects. The default, 1, indicates that the object should use the first scan group in the DI objects scan
group list. A value of 2 would indicate that the object should bind to the second scan group. If the value
of the DIO.ScanGroupIndex results in an invalid reference, then the scripts related to the automatic I/O
reference assignments will run continuously. For example, if the DIO.ScanGroupIndex is configured with
a value of 2, but the DI object only contains a single ScanGroup, then the reference is invalid.
DIO.ItemNameOption
The DIO.ItemNameOption identifies how to structure the name of the item. There are 14 distinct item
name options. The number of options available are so high because of the diversity of controllers (like
PLC’s) and how they require items to be requested. All of the item name options of the BTL are based
on variations of the object and its location within the area hierarchy.
In order to select the appropriate Item Name option, the system designer must understand the various
names objects in the galaxy can have. The following image provides an example of a galaxy with just a
handful of objects, and then defines the various names that the objects can have; specifically the malt
auger found under Roaster022.

Term Value
Tagname MaltAuger_002
Instance Name MaltAuger_002
Contained Name MaltAuger
Hierarchical Name Roaster022.MaltAuger
Area Roasting
Area Contained Name RoastingCN
Area Hierarchical Name TheGalaxy.RoastingCN
The options available for the Item Name Option and the details of each option are listed in the following
table:

1 Scripted Like a DIO.BindLevel of 1, this disables the
automatic assignment of I/O references at
the item name level.
2 AttributeName The Item Name for each attribute will match
the name of the attribute itself.
3 Tagname.AttributeName The Item Name for each attribute will be a
combination of the attribute’s owning
object’s tagname, as well as the actual
attribute name (separated by a period).
4 HierarchicalName.AttributeName The Item Name for each attribute will be a
object’s hierarchical name, as well as the
actual attribute name (separated by a
period).
5 ContainedName.AttributeName The Item Name for each attribute will be a
object’s contained name, as well as the
actual attribute name (separated by a
period).
6 Area.Tagname.AttrName The Item Name for each attribute will be a
object’s Area name, the owning object’s
tagname, as well as the actual attribute
name (each separated by a period)

7 Area.HierarchicalName.AttrName The Item Name for each attribute will be a
hierarchical name, as well as the actual
attribute name (each separated by a period)
8 Area.ContainedName.AttrName The Item Name for each attribute will be a
contained name, as well as the actual
9 AreaContainedName.Tagname.AttrName The Item Name for each attribute will be a
object’s Area contained name, the owning
object’s tag name, as well as the actual
10 AreaContainedName.HierName.AttrName The Item Name for each attribute will be a
actual attribute name (each separated by a
period)
11 AreaContainedName.ContainName.AttrName The Item Name for each attribute will be a
period)
12 AreaHierName.Tagname.AttrName The Item Name for each attribute will be a
object’s Area hierarchical name, the owning
object’s tag name, as well as the actual
13 AreaHierName.HierName.AttrName The Item Name for each attribute will be a
period)
14 AreaHierName.ContainName.AttrName The Item Name for each attribute will be a
period)

Any values entered for the Item Name Option that are not listed above are invalid; and the behavior of
the object will be unpredictable.
I/O Binding Examples

As this topic can easily become confusing for new users of the BTL, the following tables present
numerous configuration setting examples, and the resulting reference that will be constructed. All
examples are based on the following galaxy/object configurations
Model View Deployment View
Object Name Attribute Details

MaltAuger_002 Watts I/O attribute that monitors the electrical power consumed by the
motor.
Roaster022 Watts I/O attribute that contains the electrical power consumed by the
roaster’s malt auger. Basically, it points to the same controller
data as the MaltAuger_002.Watt attribute (and is in place only as
an alternative referencing example)
Roaster022 Power.Watts Internal (memory) attribute that contains the calculated value
(from a script within the object) of the Watts consumed by the
roaster’s malt auger (and is in place only as an alternative
referencing example)
Roaster022 DIO.Name Value = “RoastingControl”, and is assigned through the
DIO.BindLevel reference of this object.
Roasting DIO.Name Value = “RoastingControl”, and can either by assigned through
manual entry or automatically updated by a properly configured
DI object.
AppEngine DIO.Name Value = “RoastingControl”, and can either by assigned through
DI object.
GR_Platform DIO.Name Value = “RoastingControl”, and can either by assigned through
DI object.
Adjusting the DIO.BindLevel

In the following examples, the changes made will pertain to the DIO.BindLevel and its related
components to demonstrate the object (and when applicable, scan group) reference built. Both the
configuration attributes that are changed, as well as the related elements of the references that result,
will be highlighted in the resulting reference.

DIO DIO DIO DIO DIO DIO
Bind Item Item Scan Scan Item
Level Name Separator Group Group Prefix
Option Index
1 4 . 1 NONE NONE
[Default] [Default] [Default] [Default] [Default]
Resulting Reference: ---
Additional Details: No attribute reference is assigned when the DIO.BindLevel
is set to option 1

Option Index
2 4 . 1 NONE NONE
Resulting Reference: RoastingControl.Tagname.Attribute(Roaster022.MaltAuger.Watts)
Additional Details: The “RoastingControl” component of the reference came from the
value found within GR_Platform.DIO.Name. The “Tagname”
component of the reference was automatically discovered by the
auto IO assignment logic based on the configuration of the
MaltAuger_002.DIO.ScanGroupIndex (which was set to 1)

Option Index
3 4 . 1 NONE NONE
value found within AppEngine.DIO.Name. The “Tagname”
MaltAuger_002.DIO.ScanGroupIndex (which was set to 1).

Option Index
4 4 . 1 NONE NONE
[Default] [Default] [Default] [Default] [Default] [Default]

Option Index
value found within Roasting.DIO.Name. The “Tagname”

Option Index
5 4 . 1 NONE NONE
value found within Roaster022.DIO.Name. The “Tagname”

Option Index
6 4 . 1 NONE NONE
Additional Details: In this case, an additional attribute of the MaltAuger_002 was
configured. It was the “DIO.Name.MeConstant” UDA, and it was
configured manually with a value of “RoastingControl”.
Thus, the “RoastingControl” component of the reference came

from the value found within
MaltAuger_002.DIO.Name.MeConstant. The “Tagname”

Option Index
7 4 . 1 RoastingControl NONE
[Default] [Default] [Default]
Additional Details: In this case, one additional attribute of the MaltAuger_002 was
configured. It was the “DIO.Name” UDA, and it was configured
manually with a value of “RoastingControl”.
Thus, the “RoastingControl” component of the reference came

from the value found within MaltAuger_002.DIO.Name. The
“Tagname” component of the reference was automatically
discovered by the auto IO assignment logic based on the
configuration of the MaltAuger_002.DIO.ScanGroupIndex (which
was set to 1).

Option Index
8 2 . 1 NONE NONE
Resulting Reference: MyContainer.Attribute(Watts)
Additional Details: In this case, one additional attribute of the MaltAuger_002
was configured. It was the “DIO.Name” UDA, and it was
configured manually with a value of “MyContainer”.
Thus, the “MyContainer” component of the reference

came from the value found within
MaltAuger_002.DIO.Name. Of special interest in this
example, is that the Scan Group value was not used.
When the DIO.BindLevel is set to 8, all ScanGroup settings
are ignored.

Option Index
8 2 . 1 NONE NONE
Resulting Reference: MyContainer.Power.Attribute(Watts)

Option Index
Additional Details: In this case, the DIO.Name attribute was modified to
contain both the “MyContainer” references, as well as the
“Power” sub element.
Thus, all I/O attributes will begin with the name of the
container, and “Power”, followed by the actual element
name. When the DIO.BindLevel is set to 8, all ScanGroup
settings are ignored.
Adjusting the DIO.ItemNameOption

In the following examples, the changes made will pertain to the DIO.ItemNameOption and its related
components to demonstrate the variation possible within the item name. Both the configuration
attributes that are changed, as well as the related elements of the references that result, will be
highlighted in the resulting reference.

Option Index
4 1 . 1 NONE NONE
[Default] [Default] [Default] [Default]
Resulting Reference: ---
Additional Details: No attribute reference is assigned when the
DIO.ItemNameOption is set to option 1

Option Index
4 2 . 1 NONE NONE
Resulting Reference: RoastingControl.Tagname.Attribute(Watts)
Additional Details: In this case, the “Watts” component of the reference is the
result of the “DIO.ItemNameOption” being set to 2; which
only retrieves the attribute name for building the
reference.

Option Index
4 3 . 1 NONE NONE
Resulting Reference: RoastingControl.Tagname.Attribute(MaltAuger_002.Watts)
Additional Details: In this case, the “MaltAuger_002.Watts” component of the
reference is the result of the “DIO.ItemNameOption” being
set to 3; which retrieves the object’s tagname and attribute
name for building the reference.

Option Index
4 4 . 1 NONE NONE
[Default] [Default] [Default] [Default] [Default] [Default]
Additional Details: In this case, the “Roaster022.MaltAuger.Watts” component of the
reference is the result of the “DIO.ItemNameOption” being set to
4; which retrieves the object’s hierarchical name and attribute

Option Index
4 5 . 1 NONE NONE
Resulting Reference: RoastingControl.Tagname.Attribute(MaltAuger.Watts)
Additional Details: In this case, the “MaltAuger.Watts” component of the
reference is the result of the “DIO.ItemNameOption” being
set to 5; which retrieves the object’s contained name and
attribute name for building the reference.

Option Index
4 6 . 1 NONE NONE
Resulting Reference: RoastingControl.Tagname.Attribute(Roasting.MaltAuger_002.Watts)
Additional Details: In this case, the “Roasting.MaltAuger_002.Watts” component of the
reference is the result of the “DIO.ItemNameOption” being set to 6;
which retrieves the object’s area, contained name, and attribute

Level Name Separator Group Index Group Prefix
Option
4 7 . 1 NONE NONE
Resulting Reference: RoastingControl.Tagname.Attribute(Roasting.Roaster022.MaltAuger.Watts)
Additional Details: In this case, the “Roasting.Roaster022.MaltAuger.Watts” component of the
reference is the result of the “DIO.ItemNameOption” being set to 7; which
retrieves the object’s area, hierarchical name, and attribute name for
building the reference.

Option Index
4 8 . 1 NONE NONE
Resulting Reference: RoastingControl.Tagname.Attribute(Roasting.MaltAuger.Watts)
Additional Details: In this case, the “Roasting. MaltAuger.Watts” component of the
which retrieves the object’s area, contained name, and attribute

Option
4 9 . 1 NONE NONE
Resulting Reference: RoastingControl.Tagname.Attribute(RoastingCN.MaltAuger_002.Watts)

Option
Additional Details: In this case, the “RoastingCN.MaltAuger_002.Watts” component of the
which retrieves the object’s area contained name, tag name, and

Optio
n
4 10 . 1 NONE NONE
[Default [Default] [Default] [Default] [Default]
]
Resulting RoastingControl.Tagname.Attribute(theGalaxy.RoastingCN.Roaster022.MaltAuge
Reference: r.
Watts)
Additional In this case, the “theGalaxy.RoastingCN.Roaster022.MaltAuger.Watts”
Details: component of the reference is the result of the “DIO.ItemNameOption” being set
to 10; which retrieves the object’s area contained name, hierarchical name, and

Option Index
4 11 . 1 NONE NONE
Resulting Reference: RoastingControl.Tagname.Attribute(RoastingCN.MaltAuger.Watts)
Additional Details: In this case, the “RoastingCN.MaltAuger.Watts” component of the
reference is the result of the “DIO.ItemNameOption” being set to
11; which retrieves the object’s area contained name, contained
name, and attribute name for building the reference.

Optio
n
4 12 . 1 NONE NONE
[Default [Default] [Default] [Default] [Default]
]
Resulting RoastingControl.Tagname.Attribute(theGalaxy.RoastingCN.MaltAuger_002.Watts
Reference: )
Additional In this case, the “theGalaxy.RoastingCN.MaltAuger_002.Watts” component of
Details: the reference is the result of the “DIO.ItemNameOption” being set to 12; which
retrieves the object’s area hierarchical name, tag name, and attribute name for
building the reference.

Optio
n
4 13 . 1 NONE NONE
Resulting RoastingControl.Tagname.Attribute(theGalaxy.RoastingCN.Roaster022.MaltAuge
Reference: r.
Watts)
Additional In this case, the “theGalaxy.RoastingCN.Roaster022.MaltAuger.
Details: Watts” component of the reference is the result of the “DIO.ItemNameOption”
being set to 13; which retrieves the object’s area hierarchical name, hierarchical
name, and attribute name for building the reference.

Option
4 14 . 1 NONE NONE
Resulting Reference: RoastingControl.Tagname.Attribute(theGalaxy.RoastingCN.MaltAuger.Watts)
Additional Details: In this case, the “theGalaxy.RoastingCN.MaltAuger.Watts” component of the
reference is the result of the “DIO.ItemNameOption” being set to 14; which
retrieves the object’s area hierarchical name, contained name, and attribute

Adjusting the Options
In addition to the many object and item naming configuration options, other options enable system
designers to control how the I/O reference is assigned. The following example(s) detail some of these
options:

Option Index
4 4 ! 1 NONE NONE
Resulting Reference: RoastingControl.Tagname.Attribute(Roaster022.MaltAuger!Watts)
Additional Details: The DIO.ItemNameSeparator enables the system designer to define
the character that separates the components of the Item name by a
custom character (or characters). This is occasionally needed by
certain process/machine controllers.

Option
4 4 . 1 NONE XXX
Resulting Reference: RoastingControl.Tagname.Attribute(XXXRoaster022.MaltAuger.Watts)
Additional Details: The DIO.ItemPrefix configuration UDA enables system designers to
prefix the register name with a character (or characters); as needed by
some controllers.
Many more configuration combination could be shown—nearly limited combinations; however the
above examples should provide system designers with the information necessary to utilize the available
options to meet their IO binding needs.
The most important thing to do when deciding on an architecture to utilize for automatic I/O binding is
to TEST YOUR ARCHITECTURE BEFORE GOING INTO PRODUCTION! Once you have created an
architecture that consistently follows a methodology, then system designers can follow those design
methodologies repeatedly to maintain a consistent system that operates effectively, and efficiently.
Custom Bindings
In the event that the configuration options presented earlier in this section cannot provide the needed
reference structures to successfully communicate with the desired controllers, the BTL provides one
remaining option to help. After the auto binding scripts finish executing, a customizable script executes.
This customizable script allows system designers to add their own logic for building custom references.
This script, named _BindAttrs, contains additional documentation (within the body of the script) to help
system designers complete this task.

Using DI Object Alias Tables
A final option is available that is often helpful to system designers attempting to communicate with
machine controllers that do not support the use of custom named or hierarchical data structures. All
the above mentioned options apply; however, if these options do not enable the system designer to
create the address structures needed by the controller, they can make use of DI Object Alias Tables.
These “tables” enable the system designer to provide a translation between the attribute reference and
the actual naming structure utilized by the controller.
For example, an attribute named “Temperature.PV”, found in an object named “Reactor001” might get
an automatically assigned reference of,
“ReactorController.FastData.Attribute(Reactor001.Temperature.PV)”. However, the controller might
require the reference to actually be “F8:47”. In such cases, the system designer can continue using the
automatic I/O reference building capability of the BTL, in combination with the alias table feature of DI
objects.
While alias table references can be manually entered, one reference at a time, it is also possible to
import the references from a script. The BTL helps to simplify this process by enabling the system
designer to export a list of all the I/O attributes associated with any given object. To export the list, the
system designer simply needs to instantiate and deploy the object, and then set the
Model.CreateAliasTableCmd attribute of the object. When set, the BTL will create a file (named the
same as the object) in the directory specified in the object’s Model.AliasTableDir attribute. Setting the
command bit writes a file to the specified directory, and the file contains all CSV file with all the I/O
items within the object. The System Designer can then modify this table using their preferred CSV
editor, or import it “as-is” into the appropriate DI Object and modify the controller references directly
within the DI Object alias table.
There are two things that a system designer must be aware of when working with this feature of the
BTL. First, DI Objects only support the importing of up to 5,000 aliases per Scan Group. However, since
the BTL creates individual files for each object, and objects should not contain that many attributes, it
should not be an issue. Secondly, this feature of the BTL exports a single entry for every
internal/external attribute reference. And while this meets the needs of nearly all users, there are cases
where the input and output references differ for a single attribute. In this situation, it is necessary to
either use the _bindAttrs script to manually define the different addresses for the attribute’s inputs and
outputs, or use the BlockReadWrite object(s) provided by the BTL.
Namespace Model Exposure

Another useful feature of the BTL is its delivery of namespace model information. All objects within a
galaxy have access to some model information through keyword use in references, scripts, etc. These
include the keywords of MyPlatform, MyEngine, MyArea, MyContainer, and Me. All these references
are relative in that the value exposed relate to the object or script using them. This enables system
designers to save time and engineering effort by reducing the total number of unique I/O references and
scripts they have to create, as they can be defined at a higher level in the development hierarchy (ie: in a
higher level template)

As an example, in the preceding example image, a script written in the MaltAuger_002 object that
makes use of the MyArea relative reference would return a value of “Roasting”. A MyArea reference on
another object in the galaxy, contained in a different area, would return its area’s name.
While these relative references provide excellent abstraction capabilities, additional model information
can be useful when creating logic and scripting, to allow objects to interact with one another. The BTL
delivers this through a number of UDA arrays: MyAreas, MyContainedObjects, and MyContainers. A
slight variation on these can be found in the $mArea template; MyAppObjects, MyAreas,
MyContainedAppObjects, and MyDIObjects. Each application and area object of the BTL contains these
UDA arrays.
To understand their use, the following sections provide more detailed information regarding each of
these UDA’s as well as examples (where applicable) of the values populated into these fields (relating to
the previous example image):
Application Objects
MyAreas
The MyAreas attribute array contains a listing of all the Area objects that contain the object. In the case
of the previous example image, the PowerMonitor_002.MyAreas array would contain two elements, the
first would have a value of “theGalaxy”, and the second would contain a value of
“theGalaxy.RoastingCN”.

MyContainedObjects
This attribute array contains the names of all the Application Objects contained directly under the object
providing the value. For example, in the previous image, the MyContainedObjects array found within
the Roaster022 object would contain 4 elements. In order, they would contain the values:
Roaster022.MaltAuger, Roaster022.Agitator, Roaster022.InletValve, and Roaster022.OutletValve. This
array enables system designers to programmatically access information from children objects in
runtime; for either supervisory functionality or display within a user interface application.
MyContainers
This attribute array works in the opposite direction of the previous example; by providing a listing of
what object or objects own (or are parents to) this object. Taking the previous example image, the
PowerMonitor_002.MyContainers array would contain the following values (in the order shown):
Roaster022, Roaster022.MaltAuger, and Roaster022.MaltAuger.PowerMonitor. This array enables
system designers to programmatically access information from parent objects in runtime; for either
supervisory functionality or display within a user interface application.
Area Objects
Because Area objects provide functionality distinctly different from application objects, the Area object
contains a different list of attributes for helping system designers programmatically navigate the
namespace model. These attributes are:
MyAppObjects
This attribute array contains the name of every object executing under this area, and includes any
objects contained within the area’s application objects. Said another way, all application objects
executing directly under the area, or contained within application objects executing within this area, will
be included in this array. For example, in the previous example image, the “Roasting” area’s
MyAppObjects array will contain 12 elements; one for each of the objects that are found in that area.
This array will not, however, contain values for any Device Integration objects or other areas contained
under the area providing the value.
MyAreas
The MyAreas attribute array contains a listing of all the Area objects that contain this area. In the case
of the previous example image, the “Roasting” area would contain 2 elements; the first would have a
value of “theGalaxy”, and the second would contain a value of “theGalaxy.RoastingCN”.
MyContainedAppObjects
While this attribute is similar to the “MyAppObjects” attribute, it does have one distinct and important
difference. This attribute array will only contain elements for objects directly under the area. Looking
again to the previous example image, the Roasting area’s MyContainedAppObjects attribute would only
have two elements: Roaster011 and Roaster022. All other application objects are not directly under the
Roasting area, but instead are under other application objects.

MyDIObjects
This attribute array contains a listing of all the device integration objects that can be found executing
directly under this area. In the previous example image, the Roasting.MyDIObjects attribute array
would contain only a single element, with a value of “RoastingControl”. One architectural configuration
that system designers should be aware of is that an additional “My” attribute exists named, “MyDIOs”.
This attribute is utilized by the BTL logic to populate the MyDIObjects array, and should not be utilized
by system designers for any reason. This attribute exists because device integration objects are
different from all other types of objects in the following way: device integration objects can exist on
different engines than the Area the device integration is contained by. This is important as information
is only shared intra-engine by the BTL. So again, the “MyDIOs” attribute found within the $mArea object
should NOT be referenced (read or written to) by system designers.
The values contained within these UDA arrays are automatically populated when objects are deployed.
However, the system designer can also manually trigger a refresh of all these values by setting the
Model.CreateCmd Boolean UDA to true. The attribute will automatically reset itself back to false, and
cause all namespace model attributes to re-populate with the latest data it is aware of. If, however,
objects have been deployed in less time (seconds) than the hosting engine’s
“Model.DeployWaitTimeSeconds”, then those elements will not immediately be available to the model
attributes. They will become available after the Engine’s deploy wait time expires. Due to the
complexity of the script, populating these attributes is a resource intensive operation, and may require
significant CPU utilization as well as several seconds to complete.
Self Referencing Attribute Data

Similar to the namespace model exposure feature of the BTL, another set of UDA arrays within all BTL
provided object templates enables system designers to more easily access model and design structure
information. However, unlike the namespace model, these UDAs focus on grouping similar typed
attributes or individual objects together. Specifically, these UDA arrays are:
MyAnalogAlarmedAtrributes, MyAnalogAlarmedAttributesMap, MyAnalogFieldAttributes,
MyDiscreteAlarmedAtrributes, MyDiscreteFieldAttributes, and MyHistorizedAttributes. These attributes
provide system designers with the ability to look inside an object more effectively, by associating like-
typed components.
Each application object template of the BTL contains these UDA arrays, and the values contained within
them are specific only to that object instance in runtime. The following sections provide details for each
attribute array (and examples where applicable).
MyAnalogAlarmedAttributes
This attribute is populated with a list of all analog field attributes for which alarm definition have been
created. Because any one analog field attribute can have multiple types of alarms (4 value based
alarms, 2 deviation alarms, and 2 rate-of-change alarms), an additional field can be used to better
understand what specific alarms have been configured for this attribute (see the next sub-section for
additional information).

MyAnalogAlarmedAttributesMap
The map identifies which specific alarms have been enabled for a given analog field attribute through
the use of an 8 bit integer. Each bit within the integer represents one of the 8 types of analog alarms
that could be enabled for a given analog field attribute. The following table details these
Bit Decimal Value (by itself) Alarm

1 (LSB) 1 Value – HiHi
2 2 Value – Hi
3 4 Value – Lo
4 8 Value – LoLo
5 16 Deviation – Minor
6 32 Deviation – Major
7 64 Rate of Change - Increasing
8 (MSB) 128 Rate of Change - Decreasing
Additionally, the Map is an Array that matches with the MyAnalogAlarmedAttributes attribute. For
example, if the first element of the MyAnalogAlarmedAttributes array contains a value of
“Temperature.PV”, and the first element of the MyAnalogAlarmedAttributesMap contains a value of 9,
then the specific alarms enabled for the “Temperature.PV” are the LoLo and HiHi value based alarms
(because decimal 9 equates to the binary equivalent of 00001001; which indicates bits 1 and 4 are
active).
The BTL also contains ArchestrA graphic elements that make use of this, enabling a visualization
application to present configurable alarm displays for users to interact with (to modify setpoints and/or
enable/disable alarms).
MyAnalogFieldAttributes
The MyAnalogFieldReferences array contains a list of all analog attributes for which data is gathered
from an external source (external to the attribute…or in other words, it is not simply a calculated value).
This attribute array enables a system designer to programmatically walk through a list of the analog
element of an object; from which they may present the user with a simple graphic that enables them to
select one of these attributes and interact with the selected one as desired.
MyDiscreteAlarmedAttributes
Much like the MyAnalogAlarmedAttributes, the MyDiscreteAlarmedAttributes contains an array listing
all the Discrete Field Attributes for which alarms have been defined. However, unlike Analog Field
Attributes, discrete attributes can only have one type of alarm; therefore, no discrete alarm map is
needed. The BTL contains ArchestrA graphic elements that make use of this, enabling a visualization
application to present configurable alarm displays for users to interact with (to modify setpoints and/or
enable/disable alarms).
MyDiscreteFieldAttributes
The MyDiscreteFieldReferences array contains a list of all discrete attributes for which data is gathered
from an external source (external to the attribute…or in other words, it is not simply a calculated value).

This attribute array enables a system designer to programmatically walk through a list of the discrete
element of an object; from which they may present the user with a simple graphic that enables them to
select one of these attributes and interact with the selected one as desired.
MyHistorizedAttributes
This attribute array contains a listing of all the analog and/or discrete field references which have been
configured for historization. Because multiple elements of an attribute may be stored (such as the value
and the value deadband), each element of an attribute that has been configured for storage within the
Historian will be available within this attribute array.
An example of access these can be: If the MaltAuger_002 object contains two analog field attributes and
three discrete field attributes, and the value of each of these attributes is configured to be historized,
the system designer could access the MyHistorizedAttributes UDA array to populate a trend control in a
runtime ArchestrA graphic. While it is possible to acquire the list of historized data points from the
object through scripting (which is exactly what the BTL does), it is a somewhat time consuming and
resource intensive operation. The BTL eliminates the need for system designers to figure out how to do
this, or to implement it in each graphic or script that needs access to this information. By populating
these UDA arrays, system designers do not have to implement the logic themselves or waste the time or
computational resources building this list each time a user wants to see a trend.
The following image and table provides another example of the values each of these attributes would
contain for an object configured with the following attributes (with the historized attributes marked
with a “*”)
MyAnalogFieldAttributes MyDiscreteFieldAttributes MyHistorizedAttributes

GasCFM AbortCmd AbortCmd

Malt.PV EStopCmd EStopCmd
Malt.SP ResetCmd ResetCmd
NewState RestartCmd RestartCmd
NewStatus StartCmd StartCmd
Temperature.PV StopCmd StopCmd
Temperature.SP GasCFM
Malt.PV
Malt.SP
Temperature.PV
Temperature.SP
The values contained within these UDA arrays are automatically populated when objects are deployed.
However, the system designer can also manually trigger a refresh of all these values by setting the
Model.CreateCmd Boolean UDA to true. The attribute will automatically reset itself back to false, and
cause all self referencing attributes to re-populate with the latest data. Due to the complexity of the
script, populating these attributes is a resource intensive operation, and may require significant CPU
utilization as well as several seconds to complete.
Retentive Values
One very popular feature of Wonderware’s InTouch HMI is the ability to retain the value of a defined
data point through an application restart. For example, if a data point called LastSystemUser were
defined within InTouch, and it was configured with an initial value of “Unknown”, this value would not
necessarily be accurate after the application had been run for several days. By enabling retentive
values, InTouch is able to store the last known good value when InTouch is shutdown. This way, when
the application is restarted, it can use the last known good value for display rather than the defined
initial value.
Because Application Server differs so significantly from an execution standpoint over that of traditional
HMI, retentive capabilities were not implemented as a part of the core product. However, this doesn’t
mean that this feature cannot be implemented. The BTL also provides “retentive” capabilities through
the configuration of three object attributes: State.LoadCmd, State.SaveCmd, and State.SaveDir.
This functionality is implemented within the BTL by saving all non-I/O attribute values to disk on the
node where the objects are executing—when the object is going off scan (stopping executing). Three
configuration UDAs are responsible in utilizing this functionality; which is disabled default.
The first UDA, State.SaveDir, defines where the attribute data should be stored. The second attribute
that must be configured is the setting of the State.SaveCmd. If this Boolean attribute is set (True) when
the object is going off scan, then the values of all attributes will be written to disk (if the Sate.SaveDir
contains a valid directory path specified). The third and final attribute that must be configured is the
State.LoadCmd attribute. If this bit is set (True), then the object will load the attribute values from file
when it is deployed (if the Sate.SaveDir contains a valid directory path specified, and a file exists from
the previous undeploy operation).

Most often, when system designers want to take advantage of this functionality, the object(s) are
configured with the SaveCmd and LoadCmd set (True) as the default value. When the object goes on
scan, if value data is available in the State.SaveCmd directory, then the BTL will load these value into the
non-I/O attributes. When the object goes off scan, the non-I/O attribute values are saved automatically.
One critical element to keep in mind regarding this feature relates to Platform changes. If you undeploy
an application object from one platform, and deploy it on another, any save state data that may have
been written to disk will not go with the object. The system designer either has to plan for this in their
object design, or move the file manually (from the directory specified on the source node to the
destination node). Finally, it is (again) the responsibility of the system designer to enter a VALID and
already existing directory for the data to persisted to file (within the State.SaveDir UDA).
One topic that often comes up when considering this feature of the BTL relates to failover and reboot
scenarios. To be sure there is no confusion, the BTL related logic/scripting associated with objects will
not and do not run when rebooting a node executing objects, or in application engine redundancy
failover scenarios. In both cases, the values of all attributes are automatically populated from the last
checkpoint file created by the engine on which the object(s) were executing.
Additional Components
In addition to the already listed capabilities of the BTL, a handful of objects templates are delivered with
the BTL to address other common functionality desired within galaxies. This section details these
objects and the functionality they provide.
$mDatabaseConnectionSetup
Often times, system designers create components within the galaxy and/or the visualization application
which must interact with databases. In the spirit of true object oriented architectures, the BTL helps to
simplify the storage and accessibility of the database authentication information through the
$mDatabaseConnectionSetup template. This template adds several attributes which allow systems
designers to store the connection and authorization specific data in a single place. These attributes are
detailed in the table below:
Name Description
Name The name of the database within the
RDBMS (Relational Database
Management System)
Password The authenticating password that should
be used when accessing the database
when using RDBMS security
Server The name of the node/server providing
the RDBMS Services
User The authenticating user name that
should be used when accessing the
database using RDBMS security
SQLConnectionString A read-only register that contains the
connection string necessary to connect

to a SQL database given the above
attribute values.
SQLUseWindowsAuthentication This Boolean attribute, when set, tells
the logic that builds the
SQLConnectionString to ignore the
“User” and “Password” attributes, and
simply authenticate using the executing
user (The ArchestrA Network Account).
Within the default BTL galaxy, this template has been further derived and even instantiated for
authentication to the most commonly needed databases within an App Server environment; the
Historian, Alarming database, and Production database.
Delivered Object Details

The final topic of this section details the objects delivered with the BTL, and the attributes they contain.
* Anywhere the phrase “NONE” is used, it indicates the literal text, “NONE”. Empty string references
will be listed as blank cells. Cells containing “N/A” indicate a value is not applicable, needed, or relevant.
** Many of the BTL objects contain a “Debug” attribute. When set, it causes additional information to
be written to the logger in a custom log flag. To view these messages, enable the debug attribute in
runtime, and then open the SMC Logger and enable the viewing of those Global Log Flag (as is
demonstrated in the following image).
System Objects
$mWinPlatform
Attribute Details:
Attribute Default Value Valid Values Use

DIO.Name NONE N/A Used with Automatic I/O Binding. This value is
populated either manually by the system developers
or automatically by DI Objects configured with a
DIO.BindLevel of 2.

$mAppEngine
Attribute Details:
BTL.Debug False True|False Used to log general BTL activity to
the SMC logger. Intended for use in
troubleshooting only and is NOT
recommended for use in a
production galaxy.
BTL.Deploy.LastTime 10/31/2011 N/A Used in conjunction with the model
12:00:00.000 building scripts. Assists in the
AM delayed model building of objects
post deployment. NOT intended for
user writing.
BTL.Deploy.Seconds 0 N/A Attribute which indicates the
amount of time (in seconds) since
the last object was deployed under
this engine. This value is
automatically reset to zero
whenever a new object is deployed,
or when this value exceeds the
Model.DeployWaitTimeSeconds
attribute value.
DIO.Name NONE N/A Used with Automatic I/O Binding.
This value is populated either
manually by the system developers
or automatically by DI Objects
configured with a DIO.BindLevel of 3.
Model.DeployWaitTimeSeconds 60 Any value Identifies the amount of time the
greater than engine (and all its contained objects)
0 should wait since the last object was
deployed before building the model
information. 60 seconds, the
default, is a good starting point, but
it is recommended that the system
designer test and tweak this number
to execute most efficiently within
the deployed architecture. For
application engines containing large
numbers of objects, this number
should probably be increased. For
small numbers, decreased.

Model.ObjectCntChanged True N/A This bit is used to trigger the
namespace model building and self
referencing attribute data scripts.
The value of the
Model.ObjectCntChanged bit is
updated to reflect changes every
scan of the engine.
Scripting Details:
Script Name User Editable Description
_BTL.DeployTimer No Used in modeling building and the delay that occurs
post-deployment.
_BTL.ResetDeployCount No Resets deploy time counter related to the model
building scripts executing and populating area and
object model data.
$mViewEngine
No enhancements of UDA exist within this template. It exists for consistency in the derivation best
practices detailed in this document
$mArea
Attribute Details:
BTL.Debug False True|False Used to log general BTL activity to
the SMC logger. Intended for use
in troubleshooting only and is NOT
recommended for use in a
production galaxy.
BTL.FirstScan True N/A Used by BTL scripting for first-time
logic execution. Should not be
modified by system designers
and/or users.
BTL.MyDIOs [Empty String] N/A Internal variable used to manage
lists of device integration objects
contained by this area object. This
attribute is not to be modified by
system designers.
BTL.ObjectType Area N/A Internal variable used to identify
the type of object (dynamically by
objects above and below it in a
hierarchy)
DIO.Name NONE N/A Used with Automatic I/O Binding.
This value is populated either
manually by the system developers
or automatically by DI Objects.

Model.CreateCmd False N/A This bit is used to trigger the
Model.ObjectCntChanged False N/A This bit is used to trigger the
MyAppObjects N/A N/A Array containing the names of all
application objects executing
within the area.
MyAreas N/A N/A Array containing a list of all areas
under which this area object is
executing.
MyContainedAppObjects N/A N/A Array containing the names of the
application objects that are
executing directly under this area.
MyDIObjects N/A N/A Array containing the names of all
Device Integration objects
executing under this area.
Scripting Details:
_BTL.DetectDeploy No Associated with the identification of newly deployed
objects and model creation.
_BTL.ModelParentWatch No Triggers building of model data when its parent
(Application Engine) triggers a model build.
_BTL.ModelUpdate No Associated with the building of the model data
_BTL.ReceiveDIOs No Associated with the tracking of the device integration
objects associated with this area.
_BTL.RemoveDIOs No Associated with the maintaining the MyDIObjects UDA
array within this area.
Device Integration / Data Access Objects

The following Device Integration objects contain the same User Defined attributes and scripting/logic as
a part of the BTL: $mDDESuiteLinkClient, $mInControlSLDDE, $mInTouchProxy, $mOPCClient,
$mInControlOPC, $mRedundantDIObject, $mCIPCNBPortCLX, $mCIPCNBPortCPLX, $mCIPCNBPortFLX,
$mCIPCNBPortPLC5, $mCIPCNBPortSLC500, $mCIPDHRIOPortKA5MicroLogix,
$mCIPDHRIOPortKA5SLC500, $mCIPDHRIOPortPLC5, $mCIPDHRIOPortSLC500, $mCIPLogix5000,
$mCIPLogixCPLX, $mCIPLogixFLX, $mCIPMicroLogix, and $mCIPSLC500.
Attribute Details:
BTL.Debug False True|False Used to log general BTL activity to the
SMC logger. Intended for use in
recommended for use in a production
galaxy.

modified by system designers and/or
users.
DIO.AppObjectName NONE N/A Kept for legacy support, but no longer
supported within the BTL
DIO.AreaConfirm [Empty String] N/A Utilized in the maintenance of the DI
object’s owning area’s list of device
integration objects. Not intended for
manual use by system designers.
DIO.BindLevel 4 1–4 When set to a value between 2 and 4,
this establishes where the DI object
will write its name. For example,
when set to 2, it will write its name to
its executing platform’s DIO.Name
attribute.
DIO.BindLevelEnum N/A See details Identifies the valid values for the
from BindLevel attribute.
earlier
section
DIO.Name NONE N/A Value is automatically assigned
through scripting
Scripting Details:
_BTL.AreaConfirm No Coordinates the maintenance of this object’s owning
area’s DI Objects list.
_BTL.BindName No Populates appropriate BindLevel specified object’s
DIO.Name attribute
_BTL.DIOBindLevelDCS No Enables runtime changes of the DIO.BindLevel to
immediately be implemented (rather than requiring a
redeploy operation)
Application Objects
The following application object templates share the below listed attributes and scripting/logic as a part
of the BTL implementation: $mAnalogDevice, $mDiscreteDevice, and $mUserDefined. Application
Object Templates that deviate from the below listed capabilities (such as the $mSequencer,
$mUserDefinedBlockReadWrite, etc) are detailed later in this section.

Attribute Details:
Attribute Default Valid Use
Value Values
Alarm.IsAnyAlarmDisabled False True|False This internally assigned bit provides
an indication that one (or more)
alarmed attributes have been
disabled/inhibited. This bit is NOT
updated in real time, but periodically
through the execution of the
_IsAlmInhibited script. For more
information, see the script details
later in this section.
galaxy.
users.
BTL.ObjectType [Object N/A Internal variable used to identify the
Based] type of object (dynamically by objects
above and below it in a hierarchy)
DIO.BindAttrs False N/A Bit used to trigger the user
configurable logic (script) to assign I/O
references. This bit can be set by the
system designer/user; but is also
automatically set by other scripts
within the object when applicable.
DIO.BindLevel 4 1–8 Defines the object (and where
applicable, scan group) name that
should be used in the construction of
all automatically built I/O references.
See details from earlier section
DIO.BindLevelEnum N/A See details Identifies the valid values for the
from BindLevel attribute.
earlier
section
DIO.BindRefCmd True N/A Bit used to trigger the automatic I/O
Binding logic of the object.
DIO.DeBindRefCmd False N/A Bit used to trigger the unassignment
of attribute references. When set, all
I/O attributes have their I/O reference
set to “---“

Value Values
DIO.IORefStep 0 1-5 Internal attribute identifying the
current phase/step in the process of
automatically assigning I/O. The
following details the step phases:
1 = Setting / Configuring the
DIO.Name
DIO.ScanGroup (BlockRead/Write
group)
DIO.RefHeader
4 = Setting actual I/O references of all
IO extended attributes.
5 = Finished setting all references
DIO.IsIO False N/A Identifies if the items being assigned
I/O addresses will be connecting to a
DI object or an application object. If
the former, the addresses will not
contain a scan group; the latter they
will.
DIO.ItemNameOption 4 1 – 14 Defines the item name reference that
should be used in the construction of
all automatically built I/O references.
See details from earlier section for
more details.
DIO.ItemNameOptionEnum N/A See details Identifies the valid values for the
from ItemNameOption attribute.
earlier
section
DIO.ItemNamePrefix NONE (ANY) Configuration attribute used in the
automatic building of references for
I/O attributes. See the section on
Automatic I/O binding for details on
valid values for this attribute.
DIO.ItemSeparator . (ANY) Configuration attribute used in the
DIO.Name NONE (ANY) Configuration attribute used in the

Value Values
DIO.Name.MeConstant NONE (ANY) Configuration attribute used in the
binding options for details on valid
values for this attribute.
DIO.RefHeader N/A Internal (read-only) attribute used in
the building of attribute I/O
references.
DIO.ScanGroup NONE (ANY) Configuration attribute used in the
DIO.ScanGroupIndex 1 (ANY) Configuration attribute used in the
Model.AliasTableDir C:\WAS (ANY) Configuration attributed used to
Object define where exported alias table
Alias data should be saved to disk. System
Tables designer is responsible for entering a
valid directory.
Model.CreateAliasTableCmd False N/A Configuration attribute used in the
automatic build of references for I/O
attributes. See the section on Using
DI Object Alias Tables for more
information.
Model.CreateCmd False N/A Bit used to trigger the assignment of
the model related attributes within
the object. For more information, see
Namespace Model and Self
Referencing Attributes sections of this
document.
MyAnalogAlarmedAttributes N/A N/A Array attribute populated by BTL
scripting which identifies all the
analog attributes of the object which
have been configured for alarming.
MyAnalogAlarmedAttributesMap N/A N/A Array attribute populated by BTL
scripting which further identifies the
specific type(s) of alarms configured
for an analog attribute. For more
information, see the section on

Value Values
MyAnalogFieldAttributes N/A N/A Array containing a list of all analog
field attributes contained within the
object. This field is populated by the
model building scripts of the BTL. For
more information, see Namespace
Model and Self Referencing Attributes
sections of this document.
under which the object is executing.
This field is populated by the model
building scripts of the BTL. For more
information, see Namespace Model
and Self Referencing Attributes
MyContainedObjects N/A N/A Array containing a list of all objects
executing directly under this object.
MyContainers N/A N/A Array containing a list of all objects
MyDiscreteAlarmedAttributes N/A N/A Array attribute populated by BTL
discrete attributes of the object which
MyDiscreteFieldAttributes N/A N/A Array containing a list of all discrete
field attributes contained within the
MyHistorizedAttributes N/A N/A Array containing a list of all attributes
which are being historized within the

Value Values
State.Delimiter , [Any Single Identifies the column delimiter
String utilized when creating the “Save
Character] State” data file.
State.LoadCmd False N/A Configuration attributed related to
the automatic loading of last known
good values from disk for all non-I/O
object attributes. See section on
Retentive Values for more
information.
State.SaveCmd False N/A Configuration attributed related to
the saving of last known good values
to disk for all non-I/O object
attributes. See section on Retentive
Values for more information.
State.SaveDir C:\IAS N/A Configuration attributed defining
Object where retentive attribute data should
State be saved to disk. The directory
specified MUST exist…the BTL will not
create the directory for you! See
section on Retentive Values for more
information.
Scripting Details:
_BindAttrs Yes Provides system designers with the ability to create a
(Execution custom automatic I/O reference assignments to attributes.
Script) This script is automatically executed after the normal
binding scripts execute, and can also be manually triggered
_BTL.AliasTableCreator No Associated with the creation of alias tables for I/O
extended attributes within the object. Responsible for
writing the alias table values to file when the create alias
table command is set (true).
_BTL.DIOItemOptionDCS No Like the previous script, this identifies changes in the
binding. However, this script identifies changes to how the
item name is constructed and rebinds I/O extended
attributes in response.
_BTL.DIOName No Checks the validity of the named DI Object (assigned either
manually or through DI Object setting)
_BTL.IORefSet No Automatic I/O assignment script

_BTL.IsAlmInhibited Yes Sets the Alarm.IsAnyAlarmDisabled UDA to true if any
alarmed attribute is currently disabled/inhibited. This
script runs at a user defined period, which defaults to once
every 5 minutes. This period, which can be modified by the
system designer, should be set to the minimum frequency
at which system users need this information. However,
due to the complexity of the script, care should be taken to
NOT execute this script unnecessarily (as it is resource
intensive)
_BTL.ModelParentWatch No Associated with the building of the model data (triggering
from a parent object)
_BTL.SaveState No Logic that sales attribute data to disk for loading on object
startup.
While the above scripts and attributes apply to the listed application objects, a few remaining
application objects have been extended by the BTL as well, to add specific functionality. These objects
are defined below in the remaining subsections.
$mSequencer
Attribute Details:
Value Values
galaxy.
users.
Model.CreateCmd False N/A Bit used to trigger the assignment of
the model related attributes within
the object. For more information, see
Namespace Model and Self
Referencing Attributes sections of this
document.
MyAnalogAlarmedAttributes N/A N/A Array attribute populated by BTL
analog attributes of the object which

Value Values
MyAnalogAlarmedAttributesMap N/A N/A Array attribute populated by BTL
scripting which further identifies the
specific type(s) of alarms configured
for an analog attribute. For more
information, see the section on
MyContainedObjects N/A N/A Array containing a list of all objects
executing directly under this object.
MyContainers N/A N/A Array containing a list of all objects
MyDiscreteAlarmedAttributes N/A N/A Array attribute populated by BTL
discrete attributes of the object which
MyHistorizedAttributes N/A N/A Array containing a list of all attributes
which are being historized within the
Scripting Details:

$mSQLData
No enhancements of UDAs or scripts exist within this template. It exists for consistency in the derivation
best practices detailed in this document
$mUserDefinedBlockReadWrite
The $mUserDefinedBlockReadWrite object is identical to the $mUserDefined object except that it was
designed to utilize different I/O registers for read and write extensions. In other words, the system
designer would utilize this object when the input address must differ than that of the output address for
a given data point. Because all functionality is the same, only the differing attributes will be
documented here:
Attribute Details:
Value Values
DIO.BlockRead NONE N/A Similar to the DIO.ScanGroup of the
other Application Objects, this
contains the name of the Block Read
Group within the associated DI/DA
object. This field is automatically
populated by the scripting/logic with
Bind Levels 1 – 6; but can be written
to with option 7.
DIO.BlockReadIndex 1 (ANY) Identifies the index of the block read
group to use. Used with Bind Levels 1
– 6.
DIO.BlockReadRefHeader N/A Internal (read-only) attribute used in
references related to block reads
DIO.BlockWrite NONE N/A Similar to the DIO.ScanGroup of the
other Application Objects, this
contains the name of the Block Write
Group within the associated DI/DA
object. This field is automatically
populated by the scripting/logic with
Bind Levels 1 – 6; but can be written
to with option 7.
DIO.BlockWriteIndex 1 (ANY) Identifies the index of the block read
group to use. Used with Bind Levels 1
– 6.
DIO.BlockWriteRefHeader N/A Internal (read-only) attribute used in
references related to block writes

Scripting Details:
_BindAttrs Yes Provides system designers with the ability to create a
(Execution custom automatic I/O reference assignments to attributes.
Script) This script is automatically executed after the normal
binding scripts execute, and can also be manually triggered
_BTL.AliasTableCreator No Associated with the creation of alias tables for I/O
extended attributes within the object. Responsible for
writing the alias table values to file when the create alias
table command is set (true).
_BTL.DIOBindLevelDCS No Identifies that changes have occurred in the object’s bind
level, and resets I/O reference binding dynamically.
_BTL.DIOItemOptionDCS No Like the previous script, this identifies changes in the
binding. However, this script identifies changes to how the
item name is constructed and rebinds I/O extended
attributes in response.
_BTL.DIOName No Checks the validity of the named DI Object (assigned either
manually or through DI Object setting)
_BTL.IORefSet No Automatic I/O assignment script
_BTL.IsAlmInhibited Yes Sets the Alarm.IsAnyAlarmDisabled UDA to true if any
alarmed attribute is currently disabled/inhibited. This
script runs at a user defined period, which defaults to once
every 5 minutes. This period, which can be modified by the
system designer, should be set to the minimum frequency
at which system users need this information. However,
due to the complexity of the script, care should be taken to
NOT execute this script unnecessarily (as it is resource
intensive)
_BTL.SaveState No Logic that sales attribute data to disk for loading on object
startup.
$mBTLWriter
The BTL Writer object is provided as a mechanism for troubleshooting model and I/O assignment
configuration problems. It is NOT intended for use in a production system…period. Why? Because its
sole purpose is to write configuration and runtime attribute data to a file, every time one of the BTL
scripts run. Why? So that tech support personnel can identify possible configuration problems more
quickly. Simply stated, the BTL Writer creates a file with the same information available in the Object
Viewer, but more quickly, and sequentially keeping track of values over time. There is only a single
configurable attribute, and that defines the directory where the file is written. Wonderware Technical
Support engineers have access to the information necessary to utilize this text file, and will recommend
its use when appropriate.

While other objects are optionally provided with the BTL, the above mentioned objects constitute the
most commonly used object templates.
Support
For assistance with problems experienced utilizing the BTL, please contact Wonderware’s award winning
technical support group. For clarity, technical support should be contacted when system designers
experience problems with the BTL that are exhibited differently than documented. For design and use
recommendations, please contact your regional distributor’s systems consultants for assistance.
What’s New…
From time to time, the BTL gets a proverbial face-lift; to improve performance, implement new best
practices, and add new features. This section identifies the changes that were implemented in the latest
release. It does not, however, maintain a listing of all changes that have been made across the BTL’s
lifetime. That can be found within the BTL Version Info Dummy Object. Just view the help file
associated with this object for a complete history.
2014.0.0.2.1
This release of the BTL is the fourth for the 2014 App Server components. The following represents the
list of changes reported by the BTL Version Info Object Help:
Version: 2014.0.0.2.1
Release Date: 2014.12.15
Changes:
 All documentation was updated for this releases features and capabilities
 The custom script function library was updated to exclude BTL attributes as well as attributes
ending in "._RefAttrId".
 Removed "BTL.Version" attribute from all BTL objects, and updated documentation to identify
the proper way to get version info from any BTL provided object template—simply look at the
“ConfigVersion” attribute of any BTL Master object. Also included instructions for identifying
the version of the custom script function library in use.
 Improved automatic I/O assignment logic (multiple scripts) to improve execution performance,
troubleshooting and status information, support for more containment models of differing
application object types (ie: containing a UserDefinedBlockReadWrite within a UserDefined
derived parent), and clarify error and warning messages.
 Changed the category of numerous BTL provided UDA's to make them CalculatedRetentive
instead of Calculated (for persistence in loading from checkpoint scenarios like reboots or
redundant engine failovers).
 Modified $mAppEngine and $mArea templates, removing a script that would reset the
DIO.Name to "NONE" if the associated DI object was no longer valid (ie: undeployed), to
better support recent functional additions to the BTL (specifically, DIO.BindLevels 7 and 8).
 Removed unused declarations from multiple scripts (in declarations section of various scripts
and objects)
 Modified the name of the template toolset that contains the BTLWriter object (previous toolset
was misspelled). Template is now held under BTL Troubleshooting toolset.
 All BTL related scripts that ran under an execution type of “Data Change” were evaluated for
consistency. Some were updated to utilize a local variable while others make use of an object

UDA called BTL.FirstScan (if needed by other scripts of that object). Improvements were also
made too all such scripts to handle objects starting from checkpoint (to ensure proper loading
of values). This change better supports failover scenarios.

Base Template Library 2014.0.0.2.1 Users&#39; Guide

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Base Template Library 2014.0.0.2.1 Users&#39; Guide

Загружено:

Авторское право:

Доступные форматы

Base Template Library

Brought to you by…

BTL 2014.0.0.2.1 Users’ Guide 2

BTL 2014.0.0.2.1 Users’ Guide 3

BTL 2014.0.0.2.1 Users’ Guide 4

Automatic I/O Binding

BTL 2014.0.0.2.1 Users’ Guide 5

Self-Referencing Attribute Data

Retentive Values Capability

BTL Use – Core Guideline(s)

BTL 2014.0.0.2.1 Users’ Guide 6

File Name Description

BTL 2014.0.0.2.1 Users’ Guide 7

New Solutions/Galaxies or Upgrading

BTL 2014.0.0.2.1 Users’ Guide 8

BTL 2014.0.0.2.1 Users’ Guide 9

 [Major Version of App Server]

BTL Version Examples:

Let’s try a more recent example…

BTL 2014.0.0.2.1 Users’ Guide 10

BTL 2014.0.0.2.1 Users’ Guide 11

Versioning of the Custom Script Function Library

Why a Custom Script Function Library?

BTL 2014.0.0.2.1 Users’ Guide 12

Special Upgrade Considerations

BTL 2014.0.0.2.1 Users’ Guide 13

BTL 2014.0.0.2.1 Users’ Guide 14

BTL 2014.0.0.2.1 Users’ Guide 15

BTL 2014.0.0.2.1 Users’ Guide 16

Deployment View Architectural Recommendations

Model View Architectural Recommendations

BTL 2014.0.0.2.1 Users’ Guide 17

BTL 2014.0.0.2.1 Users’ Guide 18

Device Integration Architectural Recommendations

BTL 2014.0.0.2.1 Users’ Guide 19

BTL 2014.0.0.2.1 Users’ Guide 20

BTL 2014.0.0.2.1 Users’ Guide 21

BTL Features Detail

Automatic I/O Binding

I/O Binding Overview

BTL 2014.0.0.2.1 Users’ Guide 22

[Object Name].[Scan Group Name].Atrribute([Item Prefix][Register

BTL 2014.0.0.2.1 Users’ Guide 23

Value Description Details

The Platform contains an attribute called “DIO.Name”. It is populated by

The application engine contains an attribute called “DIO.Name”. It is

BTL 2014.0.0.2.1 Users’ Guide 24

The Area contains an attribute called “DIO.Name”. It is populated by

The “DIO.Name.MeConstant” is not automatically populated by the BTL,

BTL 2014.0.0.2.1 Users’ Guide 25

BTL 2014.0.0.2.1 Users’ Guide 26

Value Description Details

BTL 2014.0.0.2.1 Users’ Guide 27

BTL 2014.0.0.2.1 Users’ Guide 28

I/O Binding Examples

Model View Deployment View

Object Name Attribute Details

Adjusting the DIO.BindLevel

BTL 2014.0.0.2.1 Users’ Guide 29

DIO DIO DIO DIO DIO DIO

DIO DIO DIO DIO DIO DIO

DIO DIO DIO DIO DIO DIO

BTL 2014.0.0.2.1 Users’ Guide 30

DIO DIO DIO DIO DIO DIO

Base Template Library 2014.0.0.2.1 Users' Guide

Base Template Library 2014.0.0.2.1 Users' Guide