FactoryTalk View Site Edition Version 11 (CPR9 SR11) Design Considerations

Reference Guide
Design Considerations - FactoryTalk® View Site Edition
Copyright ©2019 Rockwell Automation, Inc.

Table of contents
1 Introduction ...................................................................................................................................... 3
2 Infrastructure and Topology Design ................................................................................................... 4
3 Computer Hardware and Operating Systems ..................................................................................... 8
4 System Sizing Recommendations ..................................................................................................... 13
5 FactoryTalk Services Platform Topology .......................................................................................... 14
6 FactoryTalk View SE Station and Network Station ............................................................................ 15
7 FactoryTalk View SE Redundancy ..................................................................................................... 16
8 Hardware Redundancy ..................................................................................................................... 20
9 Client Considerations in a FactoryTalk View SE Application ............................................................. 20
10 FactoryTalk ViewPoint Web-based HMI clients ................................................................................ 24
11 Controller (PLC) Considerations ....................................................................................................... 26
12 PlantPAX Architectures ................................................................................................................... 30
13 FactoryTalkView SE Installation ....................................................................................................... 31
14 FactoryTalk Activation .................................................................................................................... 35
15 Communications (Live Data) ............................................................................................................ 36
16 Runtime Modifications with FactoryTalk View SE ............................................................................. 41
17 Alarm and Events .............................................................................................................................. 41
18 Datalogging ..................................................................................................................................... 46
19 Global Objects.................................................................................................................................. 47
20 Security ........................................................................................................................................... 48
21 Trending .......................................................................................................................................... 50
22 Language Switching ........................................................................................................................ 50
23 Graphic Displays ............................................................................................................................... 51
24 HMI Server Startup Type .................................................................................................................. 60
25 Multi-User System Remote HMI Client Awareness ............................................................................ 61
26 Multi-Monitor Support ...................................................................................................................... 61
27 Applying FactoryTalk View SE in a 21 CFR Part 11 environment ......................................................... 62
28 Maintenance and Troubleshooting ................................................................................................... 62
29 FactoryTalk View SE Tools............................................................................................................... 65
30 Other Tools and Utilities .................................................................................................................. 66
31 RSView32 to FactoryTalk View SE Conversions ............................................................................... 67
32 Reference Information Links ........................................................................................................... 68
Design Considerations - FactoryTalk View Site Edition – January 2019 Page 2 of 70

1 Introduction
This document is intended as a supplement to the standard documentation that is
provided with FactoryTalk® View Site Edition.
It is designed to make system developers aware of the fundamental best-practice
guidelines for designing and implementing a FactoryTalk® View Site Edition system. If
you are new to building FactoryTalk® View SE distributed systems, this is a guide to help
you make decisions. This document will discuss some topics in detail; or this document
may refer you to another article or website where the topic is discussed in more detail
(and is more routinely updated).
This document (and any future updates) can be found in the Rockwell Automation
Knowledgebase:
AID 32549 - FactoryTalk View SE Distributed System Design Considerations
Frequently throughout this document, the user will be directed to more information in
the form of Answer IDs, or AIDs. These are technical papers created by Rockwell
Automation and posted on the Rockwell Automation Knowledgebase, accessible here:
http://www.rockwellautomation.com/knowledgebase
Note: The Knowledgebase requires a login and some AIDs are restricted to those with a
Tech Support contract, though only public AIDs are referenced within this document
when possible.

2 Infrastructure and Topology Design
Notes:
1. For architectures making use of a domain, it is recommended to use more than one domain controller such that a host failure will not interrupt domain services.
2. For architecture making use of Remote Desktop Services, it is recommended to use more than one RDS server to prevent a single point of failure for thin clients.
3. For smaller applications, this can be co-located with the VantagePoint Server host or the AssetCentre Server host.
4. Depending upon MSSQL licensing, this instance of Express could be removed and all SQL data logged to the existing MSSQL Standard instance.
5. For use with VantagePoint. Refer to the Mobility section in 61808 - FAQ: FactoryTalk VantagePoint Frequently Asked Questions
(https://rockwellautomation.custhelp.com/app/answers/detail/a_id/61808
6. As with Remote Desktop Services using multiple servers to eliminate a single point of failure, the ThinManager servers are configured for redundancy.
7. ThinManager server is frequently co-located with Remote Desktop Services server. The components have been split onto different hosts in this example, but can be consolidated
if the number of hosts becomes a concern.
8. Thin Clients can be either ThinManager Ready or ThinManager Capable. ThinManager Ready means the clients have the ThinManager BIOS extension image embedded, allowing for
easy configuration out of the box. ThinManager Capable devices do not have anything related to ThinManager embedded, but can still be connected to the ThinManager server via
a PXE boot.
9. Internet Browsers can be used to connect to FactoryTalk VantagePoint, FactoryTalk ViewPoint, and FactoryTalk AssetCentre servers.
Networking Considerations
A distributed HMI solution requires a reliable network to support communications
between the servers and the clients. Ethernet communications rely on a network that
does not have noise, interrupted connectivity, excessive collisions, or broadcast
storms. The options are endless when designing your network topology, but best
practices are always recommended.
Learn more about Industrial Network Architectures here:
https://www.rockwellautomation.com/en_NA/capabilities/industrial-
networks/overview.page
Ethernet Design Considerations Reference Manual (Publication number ENET-RM002C)

Firewalls are used to separate networks.
They can block traffic based on user, TCP/UDP port number and/or by
source/destination. Firewalls do not provide protection against viruses or intrusions.
It is a best practice to use Remote Desktop Services to "get through" a Firewall.
However, if neccessary ports can be manually opened to allow FactoryTalk network
related traffic to pass. The TCP ports used by Rockwell Automation products can be
found here:
Aid 29402 - TCP ports used by Rockwell products.
Wireless Networking
FactoryTalk applications require network speeds of >= 100Mbps.
Occasionally wireless or 3rd party networks (T1, DSL, etc.) are implemented in a control
environment. For instance, to communicate with remote sites. Wireless networks are
prone to signal interference, leading to breaks in communications, therefore it
recommended to avoid using wireless with FactoryTalk View SE thick clients or with
direct data server to controller connections.
• Ensure that all thick FactoryTalk® View SE clients are on the same network
segment as the server(s).
• Remote HMI clients are possible through the use of Remote Desktop Services (thin
clients) or FactoryTalk Viewpoint web clients.
• Controllers at remote locations should be configured to use a data concentrator,
which needs to be located on the same network segment as the data server(s).
Time Synchronization
It is strongly recommended to synchronize time clocks on distributed system
components (controllers), computers, and redundant servers.
The Windows Time service (W32tm.exe) uses the Network Time Protocol (NTP) to
synchronize computer clocks on the network. Time synchronization is critical for the
proper operation of many Windows services and to ensure the security of Kerberos
authentication within an Active Directory environment. In a FactoryTalk View SE
distributed system, time synchronization ensures accurate time stamps on alarms and
diagnostic logs.
In workgroup environments, configure Windows Time to synchronize all the SE
computer clocks to an authoritative time server (e.g. the FactoryTalk Directory).
• In either environment, the authoritative time server should then be synched to:

o a reliable time server on the Internet
o a locally-connected hardware time source such as an atomic clock
• Check the Event Viewer System log of each computer to verify that the time is
being updated properly.
Time synchronization source in a domain is provided by the domain controller that
authenticated the client. The domain controller's time is set based on a weighting score
and run through a specific search order of domain controllers.
1. Cumulative weighting calculation (additive)
8 - Domain controller in same site
4 - Domain controller marked as a reliable time source
2 - Domain controller located in the parent domain
1 - Domain controller that is a PDC emulator
2. Specific search order of all domain controllers meeting the following criteria and
assigning them a score
Parent domain controller in-site, reliable or not
Local domain controller in-site, reliable only
Local PDC emulator in-site (skipped if machine is a PDC emulator)
Parent domain controller out-of-site, reliable or not
Local domain controller out-of-site, reliable only
Local PDC emulator out-of-site (skipped if machine is a PDC emulator)
The Windows domain controller will use the highest scoring time source to pull time
information from with ultimately the PDC Emulator in the root of the forest being the
most authoritative source and being the only source that should be synchronized with
an external source.
How Windows Time Service Works

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-
started/windows-time-service/how-the-windows-time-service-works
Windows Time Service Tools and Settings

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-
started/windows-time-service/windows-time-service-tools-and-settings

How to configure an authoritative time server in Windows Server
http://support.microsoft.com/kb/816042
Other Network Considerations

For many networks, reliability includes redundant Ethernet media, including switches,
cabling, and Ethernet cards.
For more information about network resiliency go to this link:
Network Security within a Converged Plantwide Ethernet Architecture
NIC Card Teaming

It is important to note that two Ethernet cards connected to the same subnet in the
same PC are only supported when they are teamed. When two NICs are teamed, they
appear as a single NIC to Windows. If the primary NIC fails, the secondary NIC will
automatically be used. The switchover is handled at the driver level and is transparent
to Windows. FactoryTalk relies on Windows to provide Ethernet availability.
Multi-Homed PCs
Multi-homed servers (i.e.: servers with 2 or more NIC’s connected to 2 different
networks) connected to the Process Control Network (PCN) and Enterprise Network
(EN) are not recommended for the following reasons:
1. They are difficult to troubleshoot.
2. They can negatively impact network security by providing multiple paths between
the networks. For example, malware introduced on the Enterprise Network (EN) is
very likely to migrate unimpeded to the Process Control Network (PCN).
3. They can create unexpected and undesirable effects with the browser service.
(see Microsoft article Symptoms of multi-homed browsers)
A preferred solution is to use a DMZ between the PCN and the EN to isolate them, and
place the SE computers only on the PCN.
Auto-Detect NIC cards (Auto-negotiation)

Auto-negotiation lets devices select the optimal way to communicate without requiring
you to configure the devices. However, if you connect a manually-configured device to
an auto-negotiation device, a high rate of data transmission errors can occur. All 100
Mbps devices are required to support auto-negotiation, but most existing 10 Mbps

devices do not. Select a switch that supports both speeds to enable you to connect to
existing devices that use the slower rate.
3 Computer Hardware and Operating Systems

As a general rule, there will be improved performance in any application with a faster
CPU and additional RAM over the published minimum or even recommended amounts.
In addition, there should always be sufficient disk space to provide virtual memory that
is at least twice the size of the physical RAM.
Supported Operating Systems

Operating System requirements are located in the FactoryTalk View SE Installation
Guide. The installation guide documentation can be found with the product install
media or through the following Rockwell Automation Literature Library link: Publication
number VIEWSE-IN003I.
The Product Compatibility and Download Center (PCDC) can help you find product-
related downloads including firmware, release notes, associated software, drivers,
tools and utilities. The following link will provide access to the Product Compatibility
and Download Center (PCDC).
Microsoft Security and other updates

Microsoft releases a range of security, operating system and other software updates.
Rockwell Automation qualifies certain MS updates for software that impacts Rockwell
Automation software products. It is recommended that you implement a controlled
system suitable for your application and environment, and follow the guidance for the
distribution of all updates.
It is strongly recommended that Microsoft updates are not applied or installed until the
MS update has been Fully Qualified by Rockwell Automation and the results of our
testing have been reviewed and published. A rating of “fully qualified” indicates that
Rockwell Automation has tested the MS update with the primary functional areas of the
relevant software product and no issues were detected. When completed, test results
that show the areas tested will be posted for your review. Following the release of
Microsoft updates to the operating system, office products, Internet Explorer and SQL
Server, Rockwell Automation confirms that functionality within the products continue
as expected and qualify each update for installation. Updates that are characterized as
"critical" are given priority during the testing phase.

Before applying any qualified updates to your system, they should either be tested in a
non-production system or installed during a scheduled maintenance period. This will
ensure that there are no unexpected results or side effects.
Link to Rockwell Automation Qualification of Microsoft Updates.
Server vs. Workstation Operating System

Server Operating Systems are recommended for computers hosting application
servers (HMI servers, data servers, or Tag Alarm and Event Servers). Operating system
requirements depend on whether the server will support more or fewer than 10 client
connections.
A client can be any of the following:
• FactoryTalk View SE Client
• FactoryTalk View Studio
• FactoryTalk View SE Administration Console
• FactoryTalk Transaction Manager connector
• FactoryTalk View SE Server
For application servers that support:
• More than 10 client connections, the recommended operating systems with the
appropriate number of CAL (client access licenses) installed.
o Windows Server 2016 Standard
o Windows Server 2016 Datacenter
o Windows Server 2012 R2 Standard
o Windows Server 2012 R2 Datacenter
o Windows Server 2012 Standard
o Windows Server 2012 Datacenter
o Windows Server 2008 R2 Standard with Service Pack 1
o Windows Server 2008 R2 Enterprise with Service Pack 1
• 10 or fewer client connections, the minimum requirement is
o Windows 10 Enterprise
o Windows 10 Professional
o Windows 7 Ultimate with Service Pack 1
o Windows 7 Enterprise with Service Pack 1

o Windows 7 Professional with Service Pack 1
FactoryTalk View SE software is tested and supported on Windows operating systems
installed from original Microsoft media only. Using unsupported operating systems is
not recommended.
Workgroups vs. Domain

All FactoryTalk® system components must reside in either a Windows workgroup or a
Windows domain. A number of Windows networking elements are required, including
Internet Information Services (IIS).
Workgroup: Decentralized Administration

• Workgroup Advantages:
o No Domain Controller (Windows Server OS) to purchase.
o One less computer in network to maintain.
o Recommended only for small FactoryTalk View SE applications where user
accounts don’t change often.
• Workgroup Rules:
o All computers participating in an application must be members of the same
Windows workgroup.
o All users participating in the workgroup must be members of the Administrators
group.
o Create the same set of user accounts and passwords on every computer in a
FactoryTalk View SE application.
Domain: Centralized Administration

• Domain Advantages:
o One place to manage Users, Groups and Security.
o If the FactoryTalk Directory is part of a domain, then windows-linked users can
be added in for use within FactoryTalk.
o Automate IP addresses with Dynamic Host Configuration Protocol (DHCP), and
Name Resolution and with Domain Name Service (DNS) and Windows Internet
Name Service (WINS).
• Domain Rules:

o For applications consisting of more than 10 computers, a domain controller is
recommended.
o Rockwell Automation Software components (including FactoryTalk® Services
Platform components) should not be installed on domain controllers. See
Domain Best Practices
o Trusts must be established between different Domains if FactoryTalk® View SE
will be required to communicate between them.
o Do not install FactoryTalk software on a computer configured as a domain
controller. Microsoft recommends against third party software installed on a
domain controller.
For more information on designing and deploying Active Directory Domain Services and
DNS, please consult the Active Directory Domain Services documentation:
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-
domain-services
Domain Controller Redundancy

For applications consisting of or expanding to more than 10 FactoryTalk® computers, it
is recommended to use a Windows Domain and have at least two Domain Controllers
configured for redundancy and high availability on the same network segment as the
FactoryTalk System. When used in a domain environment, FactoryTalk View SE
requires that a Domain Controller always be available or performance degradation will
eventually occur.
FactoryTalk Services in a distributed environment depend on 3 critical functions to
operate: Name Resolution, Time Synchronization and Authentication. If any of these
three functions are unavailable or performing poorly then the entire distributed system
will be adversely impacted. A Windows domain may be utilized to provide these
functions in a centralized and secure manner but should be implemented in a fashion to
guarantee performance and resiliency.
Authentication:
Authentication in a Windows domain environment is centralized and performed by a
domain controller. This authentication utilizes kerberos. A kerberos ticket has a default
maximum lifetime of 600 minutes in a Windows domain environment. Tickets are only
needed when authenticating new connections with servers. Ongoing connections are
not impacted by expiring tickets. In a trusted domain environment, the kerberos ticket
for access to a resource in a different domain is generated at the local domain
controller (which communicates with the remote domain controller) and then passed to

the remote domain controller that is hosting the resource the user wants access to. As
part of its security, it is required that all clocks within the system be synchronized within
5 minutes or kerberos authentications will begin to fail.
Windows domains may also be utilized to provide additional centralized services
beyond these core services which also may adversely impact application performance
if domain controller(s) are not available or performing poorly. If a domain becomes
unable to provide its services, FactoryTalk components will begin to fail over time (e.g.,
wire frames, slow screen updates, slow screen navigation, complete system failure)
depending on the configuration of timeouts for these domain functions.
A Windows workgroup environment may be used in lieu of a Windows domain with the
following considerations:
1. If a locally scoped DNS server is not available, it is recommended to implement
static IP addressing along with hosts files across all machines in the distributed
environment for name resolution.
2. To synchronize the clocks of all machines in the distributed environment, it is
recommended that an external NTP server is made accessible to at least one
machine, then that machine is configured to sync to this external NTP server and
have its own NTP server enabled, and lastly, all other machines are configured to
use the local NTP server to synchronize their time from. By default in a non-domain
environment, individual machines may attempt to synchronize with
time.windows.com which may not be accessible or desired.
3. When configuring FactoryTalk Security without a domain, it is recommended to
utilize FactoryTalk users instead of Windows-linked user accounts. For more
information, refer to the FactoryTalk View SE Installation Guide. When using
windows-linked users in a non-domain environment, authentication is performed
by every single resource in the system and the local accounts must be identical
across all systems. Windows also uses NTLM authentication instead of kerberos
for authenticating Windows users in this environment which is slower and less
secure.
For distributed systems, a domain is recommended to centralize administration and
provide additional security that a Windows workgroup cannot provide.
Internet Information Server (IIS)

Internet Information Server (IIS) is required for HMI Servers, as well as FactoryTalk View
Studio that needs to remotely connect to a Network FactoryTalk View SE system. A
manual pre-installation of IIS is not required. The installation and configuration of IIS is
automatically provided when installing FactoryTalk View Site Edition from the product
installation media.

Factorytalk View SE HMI Tag Database uses Microsoft SQL Server Express 2014 SP2
As of FactoryTalk View Site Edition version 10, the Microsoft SQL Server 2008 R2
Express edition was replaced with Microsoft SQL Server Express 2014 SP2.
All references to SQL Server are referring to the 32-bit application version, which is
installed with FactoryTalk View SE Station, Studio and Server.
4 System Sizing Recommendations

When you design and set up a FactoryTalk system, we recommend using the following
guidelines. If you find that your system needs to expand beyond these guidelines, contact your
Rockwell Automation sales or distributor representative to discuss your application design.
Component Recommended guidelines
FactoryTalk Alarms and Events
FactoryTalk Alarms and Events servers per application 10 non-redundant servers or 10 redundant server pairs
FactoryTalk tag-based alarms per server 20,0001
Logix device-based alarms per server 10,0002
Total alarms per application 100,0003
FactoryTalk Linx
FactoryTalk Linx data servers per application 10 non-redundant servers or 10 redundant server pairs
Total device tags per application 1,000,0004
Tags per FactoryTalk Linx data server 100,0004
FactoryTalk View SE
FactoryTalk View Studio instances 5 simultaneous connections to the same application
HMI servers 10 non-redundant servers or 10 redundant server pairs
HMI tags per HMI Server 40,0005
Total data logged tags per HMI server (1 second scan 5,000
rate)
FactoryTalk View SE client sessions simultaneously 1204

connected to the application
FactoryTalk ViewPoint SE servers per application 4
FactoryTalk ViewPoint SE concurrent clients per 50

ViewPoint server

Reference information for the superscript numbers noted in the table above:
1. The number of alarm backing tags influences the maximum number of available alarms because they increase the resource
requirements of the alarm server. When using backing tags for status and control, a good rule of thumb is to multiply the total
number of backing tags by the total number of alarms, and ensure the result is less than 20,000. PlantPAx® users should refer to
the PlantPAx Reference Manual PROCES-RM001 for alarm server sizing guidance for a PlantPAx application.
2. This number is the sum of both instruction alarms and Logix tag-based alarms across all the controller shortcuts in each
FactoryTalk Linx server.
3. The total number of alarms per application includes all FactoryTalk Alarms and Events tag-based and device-based alarms in the
application.
4. Refer to Rockwell Automation Answer ID 1070902 for detailed information to determine system scalability for the total device tags
per application.
5. The maximum number of HMI tags that can be created on a single HMI server is 175,000. Extensive use of HMI tags has a significant
performance impact on an HMI server, so Rockwell Automation recommends minimizing their use, and instead using direct-
reference tags as much as possible.
For information about FactoryTalk View SE requirements that might affect the design
of a redundant system, see FactoryTalk View Site Edition Installation Guide. For
information about requirements that apply to redundant data servers such as
FactoryTalk Linx and RSLinx Classic, see the product documentation.
5 FactoryTalk Services Platform Topology

FactoryTalk allows for data sharing (called FactoryTalk Live Data) throughout a
distributed system, and allows for redundancy and fault tolerance while tracking
changes in the system. The heart of the FactoryTalk system is the FactoryTalk
Directory.
Answer ID 58803 - FactoryTalk Services Platform Best Practices
FactoryTalk Directory Definition

In every FactoryTalk system, one computer must be designated as the FactoryTalk
Directory (FTD). The FTD centralizes access to security and application resources for
all FactoryTalk products and components participating in an automated control
system. The FTD can be loosely compared to a Microsoft Windows Domain Controller,
in that both connect a group of resources. There are currently two types of FactoryTalk
Directories:
• A Local FactoryTalk Directory (Local FTD) is typically used in a single (standalone)
computer system. The Local FTD may or may not be connected to a Local Area
Network (LAN).
• A Network FactoryTalk Directory (Network FTD) is designed primarily for use with
a multiple (distributed) computer system and it is normally connected to a LAN.
Any other computers in the FactoryTalk system are clients to the designated
Network FTD
FactoryTalk enabled products can only communicate with a single FTD and
subsequently, only with the other products associated with that same FTD. A computer
can only be a member of one FTD at a time. The FTD is not aware of the existence of any
other FTD’s and cannot share information with another unrelated FTD system.
FactoryTalk Application Definition

A FactoryTalk Application is a logical grouping of resources within an FTD, making it a
subset of the FTD itself. The purpose of a FactoryTalk Application is to logically group
servers (data and HMI) within the FactoryTalk Directory. A FactoryTalk View Application
can consist of one or more FactoryTalk View SE HMI servers, one or more data servers
and one or more Alarm and Event servers.
FactoryTalk Directory Redundancy

There is no redundancy configuration for a FactoryTalk Directory server. The
FactoryTalk Directory information is cached on each computer that is participating in a
distributed application. If the FactoryTalk Directory server computer is disconnected
from the network or fails, each client and server in the application can continue to
access the graphics (from HMI Servers) and tags (from Live Data Servers) in the
application as long as the computer had previously accessed the FactoryTalk Directory
server.
The FactoryTalk Directory availability is required when doing any editing of the
application. It is recommended to place the FactoryTalk Directory on a PC with high
availability. Though placement on the Primary HMI Server is supported since that is a
highly available server, it is strongly recommended that the FactoryTalk Directory be
located apart from any redundant HMI server computers and placed on a separate
machine.
For more detailed information, see:
AID 66352 - FactoryTalk View SE Behavior when FactoryTalk Directory is Unavailable
6 FactoryTalk View SE Station and Network Station

FactoryTalk View SE Station Application
A Station Application locates the HMI server, Data server, Alarm and Events server, and
HMI client on a single computer in a standalone application.

FactoryTalk View SE Network Station Application
A SE Network Station expands the capability of single HMI stations for security and data
access. When you only require a standalone application, but still have the need to:
• Access network-scoped products like FactoryTalk® Historian ME and SE and
FactoryTalk® Batch.
• participate in network-scoped FactoryTalk® Security
• Access an off-box FactoryTalk Linx Data Server that can be configured for
redundancy.
Note: Up to 20 SE Network Station applications can be configured in one FactoryTalk
Directory.
Some other key points to keep in mind:
• Similar to a distributed application, a Network SE Station application can contain
one or more areas that divide the application into manageable parts or organize it
in a way that makes sense for the process it is controlling.
• Only one HMI Server can be added to a Network SE Station application.
• Only a local on-box client may connect to the Network SE Station application,
similar to a SE Local Station application.
• In a SE Network Station application, you can use multiple FactoryTalk Linx and OPC
data servers (including RSLinx Classic), running on different computers. You can
also set up a redundant pair of host computers for each data server in the
application.
• One or more FactoryTalk Tag Alarm and Event Servers can be used to provide alarm
monitoring and control for tags in devices that do not have built-in alarm detection.
7 FactoryTalk View SE Redundancy

Redundancy can be configured for:
• HMI Server
• Live Data Server
• Alarms and Events
• OPC Servers
Redundancy requirements are unique to each application. The ideal redundant solution
involves having at least two instances of everything – hardware, software, networks,
and so on. In practice, this is seldom feasible or even necessary. FactoryTalk View SE
redundancy allows creation of duplicate server information that can be used if a server
fails. The desired outcome is to maximize system availability. Software redundancy is
not the equivalent of ControlLogix processor style hot backup.
FactoryTalk View SE Redundancy is typically used for:
• Complete computer hardware failure.
• Complete software failure on one HMI/Live Data Server computer.
• Power failure on one HMI/Live Data Server computer.
Decide and plan redundancy requirements:
• Which components in the HMI system require redundancy?
• What software components on PC’s require backup systems?
• The network layout of the components within the system.
• CPU processing load that is expected for each computer.
Redundancy Configuration
The typical configuration when using two computers in an HMI system, is to have one
designated as the “Primary” with the responsibility of the Primary HMI Server, Primary
Live Data Server and Primary Alarm and Events Server. The second computer is
designated as “Secondary” with the responsibility of the Secondary HMI Server,
Secondary Live Data Server and Secondary Alarm and Events Server.

Additional Information:
FactoryTalk View SE User's Guide (Publication VIEWSE-UM006)
Alarms and Events System Configuration Guide (Publication FTAE-RM001)
Runtime Editing a Redundant Application

When editing HMI server graphic displays in FactoryTalk View Studio software, the HMI
server properties window has a “Replicate Active to Standby” button to manually
replicate edited displays from the Active HMI server to the Secondary HMI server. The
Tag-Based Alarm and Events server changes made on the primary server are
automatically replicated to the secondary server. Runtime modifications do not appear
on the HMI clients until the user navigates away from the modified graphic display and
then back again to reload it. Or the HMI client is shut down and restarted.
NOTE: Edits to displays will always replicate from the Active to the Standby server,
even if the Active server is the secondary.
In a FactoryTalk View SE Network application that is configured for redundancy, it is
very important to confirm that both servers are available and communicating with each
other before doing any project application editing
Exception: If there is a network disruption that separates communication between a
healthy Primary and a healthy Second server, then each will assume they are the Active
server. When the network reconnects and both servers can again communicate they
will determine who the Active is and who is the Standby server depending on the
configuration choice that was applied for switchover.
For additional information, see Rockwell Automation Knowledgebase Answer ID:
AID 566240 - FactoryTalk (CPR9) Redundancy Partner Server Coordination Overview
Redundant Server Switchover Choices

When service is restored at the primary server, either the system will switch back to the
primary server automatically, or the secondary server will remain active. This depends
on the switchover option configured in the Redundancy tab of the server’s Properties
dialog box.
• Continuing to use the secondary server
If you select the option to “Continue using the secondary server even when the
primary server becomes available again”, the secondary server will remain the
Active server, even if the primary server is ready. Use this option if you want to be
able to manually choose when to switch back to the primary server.

Clients will remain connected to the healthy Active server, until you perform the
manual switchover, or until the currently Active secondary server fails. If you
choose not to switch back automatically to the primary server, the primary server
will go on standby when service is restored, until the Active secondary server fails.
If that happens, the failover and switch-back cycle begins again.
• Automatic switch back to the primary server
If you select the option to “Switch over to the primary server when it becomes
available”, the system will switch back automatically, from an Active secondary to
a restored primary server. Connected clients will switch back to the Active primary
server, as soon as it is ready.
Choosing to switch to the primary server means the primary server is always
preferred. You cannot manually change the Active and Standby servers, if you
select this option.
In systems where the HMI server and Data server are hosted on the same machine,
selecting this option may lead to a state where the HMI server is active on the primary
machine, but the Data server is active on the secondary machine. Technically there is
nothing wrong with this scenario, but it would be best practice to provide an indication
on the client to show a viewer that the primary machine is not currently the active server
for both of the server types. You may want to consider requiring a manual switchover
so that maintenance personnel can evaluate the reason for a failover and be sure that
both servers on the primary computer hardware are healthy before switching over
again.
How to monitor which server is active and which server is standby?

In FactoryTalk View Studio, you can open the Server Status dialog window to view the
operational status of HMI servers. The Server Status dialog window can be of assistance
for analyzing behavior and troubleshooting problems.

Displaying Server Status on an HMI display screen
Operators or maintenance personnel may want the ability to quickly view the health of
the servers in the HMI system on a View SE Client HMI display. The status can be shown
on a display using two available functions called “PrimaryServerStatus()” and
“SecondaryServerStatus()”. The FactoryTalk View Site Edition installation media
provides demonstration applications with an example of how this functionality can be
set up and implemented. The display can reviewed for the configuration concept or the
entire display can be taken and used in your own applications.
8 Hardware Redundancy
Hardware Redundancy is handled at or below the operating system level of the PC.
Failover occurs when a hardware component fails, such as a motherboard, hard disk,
Ethernet card, or input device. This type of redundancy is not directly related to the
FactoryTalk application software. Typically these types of solutions require special
drivers or perhaps even virtual environments in which application software would run.
When implementing anything other than standard Windows hardware with a standard
Windows installation, it is important to test and qualify your FactoryTalk enabled
system before placing it into a production environment. Detailed information on this
topic is outside the scope of this document.
9 Client Considerations in a FactoryTalk View SE Application

There are three different client categories for FactoryTalk® View applications:
• Thick Clients: The native FactoryTalk® View SE client, which requires an
installation on each client computer.
• Thin Clients: A FactoryTalk View SE Client instance initiated by remotely
accessing the SE Client installation through the network. Since all data processing
is performed in the server environment, a thin client is typically a computing
terminal with minimal resources (processor, hard drive, memory, etc.).
• ViewPoint Clients: As an add-on to the FactoryTalk View SE system, FactryTalk
ViewPoint SE provides users with the capability to connect to the running HMI
application through the use of a web browser. This extends the accessibility of
information in the control system to a browser running on a computer or mobile
device.
The support of ViewPoint clients has changed from previous releases. Version 11 of
FactoryTalk® View SE and FactoryTalk ViewPoint SE support a total of 120 Thick/Thin

clients and 200 ViewPoint clients. For example, a system application could be
comprised of:
• 120 Thick clients, 50 View Point Clients per server with up to 4 servers for total of
200 ViewPoint clients.
• 60 Thick Clients, 60 Remote Desktop Services clients, 200 ViewPoint clients.
These client limits should be considered maximums. It should be noted that application
design will factor greatly into the number of concurrent clients that can be supported.
The use of HMI tags, datalogging, and the number of tags per second that are being
requested are all factors that will influence the resource usage and loading of the
application servers. As resource usage increases, additional application servers
(FactoryTalk® View SE HMI servers, FactoryTalk Linx data servers, ViewPoint servers,
etc) will be required.
For additional information, see Rockwell Automation Knowledgebase Answer ID:
AID 732555 - FactoryTalk View SE Product Characterization
Remote Desktop Services / Thin Client Support

Thin client support for FactoryTalk View SE is accomplished by using Windows Remote
Desktop Services. Thin clients are typically accessing the application remotely,
sometimes from outside of the control network firewall. Often in heavily industrial
environments, the operator station on the plant floor is a thin client while the servers
and full operator stations stay safely inside the control room. Thin clients traditionally
are cheaper to replace and take minimal time to set up.
Windows Remote Desktop Services (formerly known as Terminal Services) allows a
Remote Desktop Services (thin) client to access a Remote Desktop Session Host or
application remotely. If the thin client is remote from the system, it will have access to
the system as if it were physically situated on the same network as the Remote Desktop
Session Host.
An illustration of a typical FactoryTalk View SE system architecture for Remote Desktop
Services follows:

The FactoryTalk View SE Client is installed on the Remote Desktop Session Host.
Therefore, when a thin client connects, the user will have access to the full FactoryTalk
View SE client. All processing for the client is done on the Remote Desktop Session
Host. See the Windows Remote Desktop Services topic for more details.
FactoryTalk View SE fully supports Remote Desktop Services in Windows.
For more details, refer to the following Rockwell Automation Knowledgebase Answer
ID’s:
AID 567658 - Using FactoryTalk View SE with Remote Desktop Services
Remote Desktop Services is a standard Role built-into the Windows Server family of
operating systems. This technology allows remote access to applications and data over
the network. It can be used as an administrative tool to connect to a remote machine
and perform maintenance tasks, or as a thin client solution to allow remote clients to
execute applications or even access the entire desktop of the host server.
A thin client solution runs applications and performs data processing and storage
functions on a remote computer, thus minimizing the amount of information traveling
across your network. While multiple sessions run on a single server, each user can only
see their individual session. Only the user interface is shown on the client, user input
from client is redirected over the network to the remote desktop session. The Windows

desktop is transmitted to clients for display using terminal emulation software.
Similarly, the software sends command functions such as keyboard inputs and mouse
clicks across the network between the client and the server.
Connectivity is available via many software packages running on many different thin
and ultra-thin or zero client types including but not limited to:
• Microsoft Remote Desktop Connection software on current Windows PC’s and
Tablets
• Microsoft Remote Desktop Connection Client software for Mac’s and legacy
Microsoft OS’s
• Remote Desktop client software on iOS, Android, and Linux devices
• Standard web browser on a PC or mobile device
• Thin-client and Zero client hardware devices with built-in Remote Desktop clients.
Remote Desktop Services Licensing

Remote Desktop Services has its own method for licensing clients that log on to
Remote Desktop Services servers, separate from the licensing for the Windows Server
2008 R2 family of operating systems. Remote Desktop Connections must receive a
valid license issued by a Remote Desktop Licensing Server before they are allowed to
log on to a Remote Desktop Session Host or Connection Broker.
One Remote Desktop Licensing Server can serve multiple Remote Desktop Services
servers concurrently therefore you can either leverage an existing Remote Desktop
Licensing Server or create your own.
If you are creating your own Remote Desktop Licensing Server, please note the
following:
• For small deployments, you can install Remote Desktop Licensing on the same
computer as Remote Desktop Session Host. For larger deployments, it is
recommended that the Remote Desktop Licensing role service be installed on a
separate computer from the Remote Desktop Session Host role service.
• For redundancy and reliability purposes, it is recommended that the Remote
Desktop License Server be installed on a computer that is separate from any
FactoryTalk View SE server, although it is not a requirement.

Using Rockwell Automation ThinManager with Remote Desktop Services
ThinManager offers centralized management solutions for the modern factory & office
by simplifying management of applications and visual sources. Remote Desktop
Services and ThinManager both require licensing.
ThinManager allows unprecedented control and security in a sustainable and scalable
platform regardless of the size of your industrial environment or number of facilities.
ThinManager's thin client architecture allows for deployment of less expensive
hardware while giving users the applications and tools familiar to them in a format that
reduces management and hardware costs while increasing security.
By acting as a centralized management solution, ThinManager will seamlessly integrate
with your current PLC’s and HMI while providing a number of features, tools, and
methods of access, which make it simple to monitor and adjust user sessions from
anywhere.
ThinManager display clients can be generated by a session running on a display server
(e.g. a Remote Desktop Server, a shadowed thin client, a video feed from an IP camera,
or VMWare® virtual machines, as well as others). Administrators can allow multiple user
sessions to operate at the same time and each can be viewed and/or controlled directly
from ThinManager or from any authorized thin client terminal on the network.
ThinManager renders display clients through a number of different types of thin client
hardware available from multiple manufacturers and offers the ability to expand the
number of sessions, which can be simultaneously viewed from any designated
workstation.
Links to additional ThinManager information:

http://www.thinmanager.com/
AID 1076143 - ThinManager Architecture Review FAQ
AID 580089 - How to install and license Remote Desktop Services and ThinManager
AID 562240 - How To View and Control a FactoryTalk View SE Client on Mobile Devices
10 FactoryTalk ViewPoint Web-based HMI clients

FactoryTalk ViewPoint is an add-on to FactoryTalk View that provides a fully animated,
read and write view of existing network or local applications from a web browser.
A web application consists of graphic displays selected from a FactoryTalk View
application, converted for viewing in a web browser, and then published to a
FactoryTalk ViewPoint Server (web server). There is no need to install any Rockwell

Automation Software products on the browser computer, all that is needed to connect
to the published FactoryTalk ViewPoint web application is the name (or IP address) of
the computer hosting the FactoryTalk ViewPoint Server that stores the application.
With FactoryTalk ViewPoint, critical information of plant floor operations can now be
easily accessed and monitored from virtually any location and virtually any device.
FactoryTalk ViewPoint leverages HTML5 technology which opens up connectivity
across common types of mobile devices and modern browsers. Whether you’re using
Internet Explorer on an operator workstation, Google Chrome or Safari on a hand-held
device, a web browser is all that is needed to gain access to the web-enabled
application.
AID 731619 - Designing for Mobility: Top 10 Design Tips for a Mobile HMI with FactoryTalk
ViewPoint
A FactoryTalk ViewPoint web application consists of graphic displays selected from an
existing FactoryTalk View application, converted for viewing in a web browser, and then
published to a FactoryTalk ViewPoint Server (web server).
• For Site Edition applications, the FactoryTalk ViewPoint Server runs on a desktop
or server computer.
• For Machine Edition applications, a PanelView™ Plus, PanelView™ Plus 6 or
PanelView™ Plus 7 operator terminal functions as the server.
Some benefits of FactoryTalk® ViewPoint include:
• Automatic display scaling
• Multiple display browsing made easy
• Simple access for remote clients
Some features supported by FactoryTalk View SE are not supported in ViewPoint
architecture. Refer to the following Rockwell Automation Knowledgebase content:
AID 57596 - FactoryTalk ViewPoint: FactoryTalk View Object and Feature Support
FactoryTalk View SE Version Compatible FactoryTalk ViewPoint SE Version
FactoryTalk View SE 5.0 FactoryTalk ViewPoint SE 1.0
FactoryTalk View SE 6.0 FactoryTalk ViewPoint SE 1.2 and 2.0
FactoryTalk View SE 7.0 FactoryTalk ViewPoint SE 2.60 and 2.61

References:
AID 62112 - FactoryTalk ViewPoint Compatibility Matrix
AID 57990 - FactoryTalk ViewPoint Tips and Best Practices TOC
11 Controller (PLC) Considerations

Controller specification is just as important in smaller architecture as it is in larger
architectures when a controller must communicate with an HMI. The load of the
controller will dictate whether or not the requests from the HMI for data will be fulfilled.
A complete discussion of controller strategy is well beyond the scope of this document.
Some topics will be mentioned because of controller data importance to the HMI
displays and overall performance. Some HMI applications can experience performance
issues because it cannot efficiently receive data requested from the controller. This is
typically because the controller is unable to handle all of the communication requests
that it is receiving. Note: Communication to the HMI are handled at the lowest priority
for a ControlLogix processor.
In summary, when choosing the type and quantity of controllers that will communicate
with the HMI, it's important to clarify both what data is needed from the controller, and
how often it will be needed. There are controller options that directly affect HMI
communications as well.
• Memory
o How much memory is available vs. how much memory is used?
o Tag management (Using arrays & UDTs)
• Tasks
o Continuous
 Scan time

 Time slice
o Periodic
• Number of connections the controller will have to handle
• Public/Private Data
• Redundancy
For more information see Rockwell Automation Literature Library Publication:

Logix5000 Controllers Design Considerations Reference Manual
Publication 1756-RM094
For more details, also see Rockwell Automation Knowledgebase Answer ID:
AID 25915 - System Overhead Time Slice to Increase Bandwidth for Communications
Controller Memory
Be sure to size the controller appropriately for HMI communications. When there are
multiple Data servers talking to a single ControlLogix Controller, separate memory is
consumed by each Data server instance.
If a controller must send its data to an HMI or to a database, there must be enough
memory in the controller to handle both application code (which has priority) as well as
communications. Remember that the communications task in the controller has the
lowest priority.
In order for displays with data collection to function properly, they must be able to
gather data from controllers in an efficient and reliable manner.
Keep in mind that both RSLinx Classic and FactoryTalk Linx use up memory in a
ControlLogix Controller when they are requesting data.
• FactoryTalk Linx is the data server for Rockwell Automation control hardware.
• FactoryTalk Linx Gateway is for third-party OPC DA and UA software access.
Periodic vs. Continuous Tasks

It is recommended to use periodic tasks wherever possible in order to manage
communications time. As a general rule, it is recommended to keep 30% of each scan
time available for communications. Communications is one of the lowest priority tasks
that a controller executes, so a busy controller may be too busy to ever communicate

with a Data server. A controller may become "too busy" when using both Periodic and
Continuous tasks; however, time is much easier to manage when tasks are Periodic.
Continuous Tasks
• Communications use CPU time only after other tasks execute.
o Overhead time slice adjustments may provide more time for communications,
but execution may not be efficient.
Periodic Tasks
• After execution, task suspends and waits for trigger. While task is suspended,
communications are serviced.
o Beware of task overlap! Task overlap occurs when the controller cannot
execute all tasks in the configured interval. If task overlap occurs, the
overlapping task simply does not execute and waits for the next trigger. While
this state may appear to provide more idle time to service communications, it
comes at the expense of lost execution of periodic tasks.
Arrayed vs. Scattered Tags

It is recommended to use DINT single-dimension arrayed tags versus scattered tags
whenever possible. DINT tag types in the controller eliminate data conversion code for
communication which results in faster execution and reduced memory space.
Additionally math performed on DINT values is quicker to execute than on REAL values.
Arrayed tags are optimized for communications and use less controller memory than
scattered tags. Using arrays allows for more data throughput and takes far less
controller resources during communications polling. Communications is optimized for
single dimension arrays. Using scattered tags instead of arrayed tags will result in
communications requiring more processor time, which could lead to slower scan times
and/or communications delays.
Controller Time Synchronization

CIP Sync can be used to synchronize time among controllers (and other CIP Sync-
enabled devices). When there are multiple controllers in a system that provide data to
an HMI, particular Alarm & Event data, it is strongly recommended that time is
synchronized among controllers.

CIP Sync™ (CIP Network + IEEE-1588 Standard) is a time synchronization method. It can
provide synchronizing of all devices over Ethernet with a UCT time value with up to 100
nanoseconds accuracy. AID 55019 - CIP Sync (IEEE 1588)
Controller Connections
• FactoryTalk Linx
o Each instance of FactoryTalk Linx can use up to 5 connections to a Logix
Controller.
o These 5 connections break down to 4 read connections and 1 write connection.
All 5 connections are not always used. They are used as needed and are
automatically controlled by FactoryTalk Linx.
• RSLinx Classic
o By default each instance of RSLinx Classic can use 5 connections to a Logix
Controller.
o Can be increased manually to 20
• Other features that use connections
o Controller-to-Controller messaging
o Local I/O
o Motion Servo Modules
o Produced / Consumed Tags
AID 56682 - Counting CIP Connections for Produced and Consumed tags in ControlLogix
Controller Redundancy
When ControlLogix Redundancy is being used, it is important to configure more
communications time in the controller. Communications time is used by the processors
to synchronize. Since the synchronization occurs during the Communications Time it is
necessary to allow more time so that the HMI system is also able to obtain the requested
data.
ControlLogix Redundancy – Ethernet/IP: When ControlLogix Redundancy is being used
with FactoryTalk Linx data servers, IP address swapping must be used.

Automatic IP Address Switching
When the IP addresses are swapped there may be a communications disconnection
that can last for 30 seconds to 1 minute.
ControlLogix Ethernet modules share their IP addresses with their partner modules in
the redundant chassis. This allows the Live Data Server to use the same IP address to
communicate with a primary module regardless of which CLX chassis is the primary.
While the IP address is automatically switched, it may take FactoryTalk Linx up to 1
minute to recognize the switch.
To better understand the cause of the communications bump, see:
AID 31520 - Understanding HMI Switch Overtimes when using Ethernet/IP Swapping and
ControlLogix Redundancy
ControlLogix Redundancy - ControlNet vs. Ethernet:

If bumpless communication between Live Data Servers and CLX controllers is required,
use a separate ControlNet network that is dedicated to communication with those
devices.
Using ControlNet (over Ethernet/IP) will improve recovery times of the data server when
the CLX switches over, assuming the HMI/Data Server remains healthy. ControlNet will
not affect the switchover times of the primary and secondary servers. The following
estimates have been found during testing:
• Data server recovery when the CLX primary switches to a CLX secondary with
Ethernet, ~ 30 seconds.
• Data server recovery when the CLX primary switches to a CLX secondary with
ControlNet. Usually less than 1 sec.
• FT View Platform (HMI/Data Server and Clients) recovery when Active Server
switches to a Standby Server with Ethernet or ControlNet, this could take 30
seconds
For more information, see the Rockwell Automation Literature Library:
ControlLogix Enhanced Redundancy System User Manual:
Publication number 1756-UM535
12 PlantPAX Architectures
The recommended PlantPAx specifications help reduce variability by defining a set of
system architectures and associated products and documenting best practices.

PlantPAx specifications are geared towards process systems and are sized so system
performance is not affected by normal variations in hardware and software
configurations.
All PlantPAx class architectures achieve targeted system performance by following
defined specifications.
For information on PlantPAx systems, see Rockwell Automation Literature Library:
• PlantPAx Distributed Control System Reference Manual
o Publication number PROCES-RM001
• PlantPAx Distributed Control System Selection Guide
o Publication number PROCES-SG001
13 FactoryTalkView SE Installation
Unattended installation
FactoryTalk View Site Edition supports the unattended mode to install the software.
You can typically use this mode during large-scale roll outs when it might be too slow
and costly to have administrators or technicians interactively install the software on
individual computers.
Client installation portal

During FactoryTalk View Site Edition installation, you can choose to install the client
install portal feature. Through this option, the FactoryTalk View SE Client software can
be installed over the network through a link provided to remote operator systems.
FactoryTalk Historian Connectivity tools

This installation option allows FT View SE Clients to access and display information
from the FactoryTalk Historian SE system configured in the FactoryTalk Directory.
Uninstall FactoryTalk View tool

You can use this tool to uninstall FactoryTalk View components that are already
installed on your computer. It does not uninstall components like RSLinx Classic and
FactoryTalk Activation Manager, that might be used with other products.
Note: Establish the system’s computer names prior to installing FactoryTalk Service
Platform and FactoryTalk View SE. Changing computer names after the installation of
the software is not recommended.
The installation media provides options to install the complete suite of software
components or some individual components. For each selection on the installation
menu, the following table shows the mandatory, recommended and optional software
components to install.
1. Site Edition Client is not mandatory if you plan to install FactoryTalk ViewPoint SE.
2. For more information, see the Rockwell Automation Literature Library document:
FactoryTalk View Site Edition Installation Guide
On page 37: About FactoryTalk Historian Connectivity.
Default File Locations for FactoryTalk View SE

x86 Core program files:

• C:\Program Files\Rockwell Software\RSView Enterprise
x86 Help files and additional documentation:
• C:\Program Files\Common Files\Rockwell\Help
x64 Core program files:
• C:\Program Files (x86)\Rockwell Software\RSView Enterprise
x64 Help files and additional documentation:
• C:\Program Files (x86)\Common Files\Rockwell\Help
Default File Locations for FactoryTalk View SE Distributed Applications

The locations of the product files for the following operating systems:
Windows 7 x86 and x64
Windows 8 and 8.1 x86 and x64
Windows 10 x86 and x64
Windows Server 2008 and 2008 R2 Standard X86 and X64
Windows Server 2012 Standard X86 and X64
Windows Server 2016 Standard X86 and X64:
• Network FactoryTalk Directory File:
o C:\ProgramData\Rockwell\RNAServer\Global\*.RnaD
• HMI Application Files:
o C:\Users\Public\Documents\RSView Enterprise\SE\
• Help Files and additional documentation:
o C:\Program Files\Common Files\Rockwell\Help
All HMI components that are part of the same HMI system need to be located on the
same Local Area Network (LAN) with the FactoryTalk Directory, FactoryTalk View SE
HMI server(s), FactoryTalk Data server(s), FactoryTalk Alarms and Events server(s),
FactoryTalk View SE client(s) and FactoryTalk Activation Manager.
Where should the FactoryTalk Directory be installed?

If possible, the FactoryTalk Directory should be installed on an independent computer.
It is not recommended to co-locate the FactoryTalk Directory with either member of a
redundant HMI pair. However, if necessary, place the FactoryTalk® Directory on the
primary HMI server (as opposed to the secondary.)
Where should the FactoryTalk Activation server be installed?
Common practice is to co-locate the FactoryTalk Activation server with the
FactoryTalk® Directory.
It is not recommended to co-locate the FactoryTalk Activation server with either
member of a redundant HMI pair.
Where should the FactoryTalk View SE HMI server(s) be installed?

A maximum of one FactoryTalk View SE HMI server can be installed on a single computer
for a production environment.
The maximum number of FactoryTalk View SE HMI servers that can be installed on a
single computer during development is five.
For more information, see the FactoryTalk View Site Edition Installation Guide.
Where should the Data server(s) be installed?

A maximum of two data servers is recommended per single computer for a production
environment.
Data server to controller communications should not be over wireless connections. If
a wireless connection is necessary, a data concentrator should be configured on the
same wired Local Area Network (LAN) as the data server. The concentrator will then
communicate to the controller in question over the wireless connection, while the data
server receives data from the concentrator over the wired LAN.
Where should the FactoryTalk View SE client(s) be installed?

Where ever operator terminals are required.
For more information, see the Rockwell Automation Literature Library document:
FactoryTalk View Site Edition Installation Guide.
Where should I locate my FactoryTalk ViewPoint server?

It is recommended to install the FactoryTalk ViewPoint server on a high availability
server separate from those used to host the HMI, Data, and/or Alarms and Events
servers when used with a redundant FactoryTalk View SE system.
If you are using FactoryTalk ViewPoint with a Network Station application, it must be
located on the same computer hosting the HMI server.

Defining Areas in a HMI Application
FactoryTalk View SE provides flexibility in how to structure a distributed HMI, however
there are best practices that should be followed.
• Do not duplicate references to a Data Server (RSLinx Classic, FactoryTalk Linx, 3rd
party OPC Server) in your FactoryTalk View SE application.
Tags from a single data server may be referenced from any HMI project in any Area
of the application.
• Use Areas and Sub-Areas to contain a single HMI or Data Server. This will prevent
the failure of one data server from affecting any others that are in the same area.
This will also prevent potential performance problems.
• Install the FactoryTalk Services Platform (FTSP) on a computer that is hosting a 3rd
party Data Server. This will enable faster detection of any Data Server
communication problems and will also allow for a fast switchover in a redundant
configuration.
For further details and explanations, refer to Rockwell Automation Knowledgebase
Answer ID
AID 29663 - Guidelines for Structuring Areas in a FactoryTalk View SE Application.
14 FactoryTalk Activation
The FactoryTalk Activation Manager is an application used to acquire and manage
Rockwell Automation Software Activations.
FactoryTalk Activation Manager provides a choice of configuration options:
• node-locked (includes local and mobile)
• concurrent (includes floating and borrowed)
In systems using HMI clients that may not be dedicated, it might be desirable to use a
single, centralized FactoryTalk Activation server to serve client licenses.
Centralized or Independent Activation Servers

For users interested in consolidating their activations for centralized management,
Rockwell Automation recommends hosting this centralized activation server on the
FactoryTalk Directory host, or another independent server separate from the
application servers.
For users who are concerned with disruptive network conditions and/or risk mitigation,
most activations can be hosted local to each application component. For activations

that cannot be split (for example, FactoryTalk View Site Edition bundle licenses,
capacity counts), decentralized activation servers hosted on the same network
segment as the application server are recommended.
For more information regarding FactoryTalk Activation, refer to:
Chapter 5 of the FactoryTalk View SE Installation Guide - Publication VIEWSE-IN003I
AID 67103 - FactoryTalk Activation: Reference Index of common Technotes
AID 612825 - Managing Remote FactoryTalk Activation Manager Servers
What happens if FactoryTalk View is not activated?

If the FactoryTalk View components you have installed cannot be activated, for
example, because the activation server is unavailable or because borrowed activations
have expired, the software will continue to run for up to seven days.
The seven-day grace period allows time to correct the problem with acquiring
activations without disrupting critical applications. If the activation is restored within
seven days, normal operations will resume.
If the activation is not restored, the grace period will expire. After the grace period
expires, if you restart FactoryTalk View SE and activation remains unavailable, the
software will run for two hours in demo mode.
With a FactoryTalk View SE network distributed application, running in demo mode, you
can:
• Create or load up to five HMI servers locally in FactoryTalk View Studio.
• Create or load up to five graphic displays per HMI server.
• Run a local station FactoryTalk View application for up to two hours. In demo mode,
remote clients cannot connect to a FactoryTalk View server.
15 Communications (Live Data)

FactoryTalk Linx is the preferred method of data communication for FactoryTalk View
SE unless one of the following features is needed:
• OPC/DDE Server to non-FactoryTalk applications
• Complex communication routing. Protocol changing (ex. Ethernet to DH+), then
RSLinx Classic is required.
• Offline browsing of older PLC/SLC hardware and RSLogix files, then RSLinx Classic
is required.
AID 507425 - Data Server Decision Guide
FactoryTalk Live Data Protocols: TCP/IP and DCOM

To add an OPC data server: In FactoryTalk View Studio, in the Explorer window, right-
click the application root, or right-click the area name, select Add New Server > OPC DA
Server or OPC UA Server
The FactoryTalk System Policy allows the Live Data protocol to be selected. This policy
setting will affect communications between client and server services and between the
FactoryTalk directory and servers on the network. If the FactoryTalk Live Data service
detects that some components on the network are not compatible with the selected
policy setting, it will override the policy and use whichever setting is most likely to
ensure uninterrupted communications. For example, for third-party servers and RSLinx
Classic, FactoryTalk Live Data will not attempt a TCP/IP connection and will always use
DCOM.
AID 49329 - Locating settings for the communications protocol (TCP/IP or DCOM)
OPC UA and OPC DA Connectors for FactoryTalk Live Data

• Clients can communicate through data servers, which provide access to
information in devices that comply with the OPC UA 1.02 or 1.03 specifications.
• Clients can communicate through data servers, which provide access to
information in devices that comply with the OPC DA 2.05a, UA 1.02 or 1.03
specifications.
This enables FactoryTalk software to interface with third-party systems and data is
universally accessible across a FactoryTalk system.
NOTE: OPC UA servers do not support the FactoryTalk View redundancy capabilities in
this release.
For more information regarding FactoryTalk Linx, refer to:
FactoryTalk Linx Getting Results Guide - Publication LNXENT-GR001

FactoryTalk Linx Gateway
FactoryTalk Linx Gateway is an OPC server that enables OPC clients to connect to
FactoryTalk applications. By connecting via FactoryTalk Gateway, 3rd party clients are
able to access live tag data from within a FactoryTalk system and perform read and
write operations.
Some facts about FactoryTalk Linx Gateway:
• It is OPC DA and OPC UA compatible.
• FactoryTalk Linx Gateway Station is for use on stand-alone, local applications.
• FactoryTalk Linx Gateway Distributed is for FactoryTalk network applications.
• Only one FactoryTalk Linx Gateway can be installed per computer.
• FactoryTalk Linx Gateway can only point to a single FactoryTalk application at a
time.
• FactoryTalk Linx Gateway can communicate to as many unique tags as licensed.
• Multiple FactoryTalk Linx Gateways can point to a single FactoryTalk application.
• 20 remote OPC clients have been formally tested and validated against FactoryTalk
Linx Gateway.
• Can optionally exclude from OPC Discovery Service and control access for selected
portions.
• Comprehensive diagnostic information provided with predefined diagnostic tags
using embedded FactoryTalk Diagnostic log viewer.
FactoryTalk Linx Gateway Data Bridge

• Application is delivered and licensed with FactoryTalk Linx Gateway.
o Operates on single PC or distributed.
o Can share a local activation with FactoryTalk Linx Gateway.
• FactoryTalk Linx Data Bridge delivers data from one FactoryTalk Live Data source
to another.
o Logix Controller via FactoryTalk® Linx.
o OPC UA Servers via FactoryTalk® Linx OPC UA Connector.
• User configured tag pairs.
o Subscription to data source based on user selected rate.
o Source data delivered to the Data Bridge is forwarded to destination

o Optional quality and timestamp values delivered to both source and destination
• Configuration import / export to back up the settings or streamline the setup
process
• Manual configuration via user interface or import/export of configuration to
manipulate with desktop software
• Shares the FactoryTalk Linx Gateway’s activation levels (5K, 32K, 70K, unlimited)
• Enables Logix5000 controllers to indirectly interface with OPC UA Servers
Calculating Tags on Scan

To calculate the maximum number of tags that could possibly be on-scan from a Live
Data Server (ex. RSLinx Classic) add all of the following:
Note: If a tag is used in multiple places it only counts once.
• Tags on graphics being displayed (or having been displayed if displays are
configured to cache and always update)
• Alarm and Alarm Acknowledge tags
• Tags in Derived tag equations (only derived files running)
• Tags in Event files (only event files running)
• Tags in Data Logs Models (only models that are running)
• Handshake tags
• Tags that Macros or VBA are using for read and write operations
Note: Also take into consideration other applications like FactoryTalk Historian SE that
may be using the same Live Data Server
HMI Tags versus Direct Reference Tags

Each graphic display can contain up to 3,000 references to expressions or tags (HMI and
Direct). This limit includes duplicate tags and tags contained in embedded variables.
Embedded variables can be used to display data in a graphic display that will updates
dynamically at run time. It is recommended that no more than 200 objects be used on a
single graphic display that are using embedded variables that are dynamically updating
data.
For more details, also see Rockwell Automation Knowledgebase Answer ID’s:
AID 1086271 - FactoryTalk View SE recommendation for the maximum number of
objects using embedded variables.

AID 584999 - Explanation of graphic display tag connection limit in FactoryTalk View SE
Tag Database (HMI Tags)

• Very useful when creating similar controls. Parameter files can reference
directory folder structure or tags for quick duplication of controls.
• Easy to do Tag Replacement (search and replace)
• HMI tags must be used (that is, Direct Referenced tags cannot be used) for any of
the following components in the application:
o Security.
o Data manipulation (Scaling, offset values, setting minimum or maximum limits
on values).
For optimum performance, do not place all the HMI tags in the root folder. It is also
recommended that the number of tags in a folder be limited to less than 1000. HMI tags
contained in nested folders do not contribute to the number of tags in the root of the
folder.
AID 29266 - Slow object animation performance when opening HMI displays.
Direct Referenced Tags

• No need to build or create a tag database since tags are directly referenced from
the controller
• Provides access to complex data types in the Logix5000 environment. Reference
the tag values directly, and eliminate the need to create an HMI tag for each
member element.
• Parameter files can be used with Direct Referenced Tags
• Tag Replacement can be used with Direct Referenced Tags
• Security cannot be configured; however, a workaround is to use the function
UserHasSecurityCode() with visibility on Input fields.
AID 46484 - How to apply security on tags when using direct referenced tags.
Note: The Tag Browser button appears beside data entry fields. Type information into
the filter field or click the browse button to open a list containing valid entries for the
field. Using the Tag browser button will prevent syntax errors that could require
debugging later in the application development.

16 Runtime Modifications with FactoryTalk View SE
Runtime editing of an HMI application (both redundant & non-redundant) is fully
supported, but some tag information is loaded into RAM when the FactoryTalk View SE
services start. Therefore, in order for the change(s) to take effect, some tag database
modifications may require:
• Server restart/reboot.
• Client session restart.
• Client screen refresh.
At development time, you should evaluate what runtime modifications may be needed
and have a procedure in place to allow for them once a project has been commissioned.
AID 39853 - FactoryTalk View SE Runtime Editing Considerations.
Redundant HMI Server Runtime Modification

• Automatically copies HMI project files from the primary server to the secondary
server after you set up redundancy.
• Supports the replication between active and standby servers, even when the
currently active server is the secondary server. When the replication completes,
no need to restart the server.
• Automatically saves project online edits to both active and standby servers if both
are available on the network and healthy. If one of the servers is unavailable when
edits are being done, it might be necessary to manually initiate the replication
process when the server is available again.
• Provides the redundancy functions PrimaryServerStatus() and
SecondaryServerStatus() to retrieve the server status in a redundant server pair.
• Provides the Switchover command to switch the active server in a redundant
server pair.
AID 39853 - FactoryTalk View SE Runtime Editing Considerations.
17 Alarm and Events

If you are upgrading to version 11.00, legacy HMI alarm definitions in your older existing
application are stored in the HMI tag database. Use the FactoryTalk View Alarm

Migration tool to migrate them to FactoryTalk Alarms and Events. For an example of
instructions, see the video at the Rockwell Automation YouTube page.
Note: FactoryTalk View version 10 is the last release to support the legacy HMI tag
alarms. For FactoryTalk View version 11.00 and later legacy HMI tag alarms are no longer
supported.
AID 45583 - Tool: Converting RSViewSE HMI Alarms to FactoryTalk View SE A&E Tag-
Based Alarms.
Several FactoryTalk Alarm Objects that are available for use on a display:
Alarm and Event Banner - Use to subscribe to alarms from one or more areas in the
FactoryTalk system and then monitor and interact with the most urgent and recent
alarms.
• Display various attributes of alarms.
• Indicate the state of alarms using icons, colors, and sound.
• Used by operators to acknowledge or silence the alarms that are displayed.
Alarm and Event Summary - Use to subscribe to, monitor, and interact with alarms and
events from one or more areas in the FactoryTalk system.
• Displays various alarm attributes.
• Indicates alarm states using icons and colors.
• Allows an operator to acknowledge, reset, suppress or disable the alarms that are
displayed.
Alarm and Event Log Viewer - View alarm and event information previously logged in a
database configured to store historical data. Programmatically query the database for
specific records.
Alarm Status Explorer - Displays the FactoryTalk Directory area model and the alarm
sources contained within that area model. Operators use the Alarm Status Explorer to
view and change the status of alarms in the FactoryTalk Alarms and Events system.
• Enable or disable alarms.
• Suppress or unsuppress alarms.
• Enter comments when enabling, disabling, suppressing, or unsuppressing alarms.
1. Alarm and Events - Tag-Based
• Offers the equivalent of HMI tag Alarm monitoring, but with an expanded feature
set.
• Works with any controllers available on any data server (OPC or FactoryTalk
Linx)

2. Alarms and Events - ALMA and ALMD instructions
• Works with Logix controllers (V16 to V19 and v24 or later).
• Alarm detection performed in FactoryTalk Linx.
• No HMI tag definition needed.
• All alarm configuration done in the controller using RSLogix 5000.
3. Logix Tag-based Alarms
• Logix tag-based alarms are supported only on Compact GuardLogix 5380,
CompactLogix 5380, CompactLogix 5480, ControlLogix 5580, and GuardLogix
5580 controllers, with firmware v31 or later.
• Logix tag-based alarms associate alarm conditions with tags for Logix 5000
controllers. Logix tag-based alarms monitor tag values to determine the alarm
condition, but they are not part of the logic program and do not increase the
scan time for a project.
FactoryTalk Alarms FactoryTalk Alarms Logix Tag-Based

and Events and Events Alarms
Tag-Based ALMA and ALMD
Instructions
Configured in HMI Application Yes
Alarm tags are polled by HMI Yes
Configured in Controller Yes Yes
Alarm status is pushed to HMI Yes Yes
Enhanced Alarm Summary Object Yes Yes Yes
Alarm History in MS SQL database Yes Yes Yes
Alarm History Viewer Object Yes Yes Yes
Alarm Banner Object Yes Yes Yes
Support for Redundancy Yes Yes Yes
Runtime Language Switching Yes Yes Yes
Alarm buffering during loss of connection to the controller

To receive device-based alarms, the alarm server (FactoryTalk Linx) establishes a
subscription to the alarms in the Logix controller. The controller maintains a connection
to each subscriber and monitors the status of that connection.
As alarm state changes occur, the controller caches information such as timestamps,
alarm state and associated tag values, and transmits the information to all of the
subscribers.

If any subscriber fails to confirm the receipt of the alarm information, or if the
connection to a subscriber is not good, the controller stores the undelivered alarm
information in a 100 KB buffer. Each subscriber has its own buffer and communication
problems with one subscriber do not interfere with alarm delivery to other subscribers.
When the buffer is full, newer alarm information is discarded and a FactoryTalk
Diagnostics message is logged. The buffer is created when the subscriber establishes
its initial connection, and is maintained for a length of time after a subscriber loses its
connection. The length of time is specified in the Buffer Timeout setting on each
FactoryTalk Linx device shortcut.
For more information regarding FactoryTalk Alarm and Events, refer to:
FactoryTalk View Site Edition User's Guide:
Publication VIEWSE-UM006
FactoryTalk Alarm and Events System Configuration Guide:
Publication FTAE-RM001
FactoryTalk Alarm and Events Redundancy

Microsoft SQL server is configured for use with Alarms and Events. If a connection to
the historical database is not available, the server will cache alarm events until the
connection becomes available again, at which point the cached events are sent to the
database.
When implementing Alarm and Event redundancy, it is acceptable to place the alarm
history database on either the primary or secondary HMI/Data servers since events will
be cached should that server become unavailable; however it is recommended to place
the SQL Server on a machine separate from the redundant HMI/Data Server pair, as
shown below.
Note: Microsoft SQL must be installed if the use of FTAE Alarm History is desired.
Microsoft SQL Express is provided with the FactoryTalk View SE installation media and
is a free installation. However, if there is already an existing MS SQL server within the
architecture, it can be used. The SQL Server that is installed with FactoryTalk
AssetCentre could also be used.
Duplicated/Conflicting Historical Entries

In rare circumstances when using FactoryTalk Alarms and Events redundancy, it is
possible for the historical database to receive duplicate and/or conflicting alarm
messages. This state could occur if the active Alarms and Events server (i.e. Server A)
loses connectivity to the network (including controllers and historical database) and
locally caches faulted alarm states while Server B records and logs accurate alarm
values. When connectivity to the network is restored, it is possible for Server A to
receive and log good quality events from the data server before connecting and
synchronizing with the alarm server.
Synchronization of time is important in any distributed system; however, time
differences will be more apparent and confusing to the operator in the case of alarming
since mis-matched times will appear together in the same display. If the FactoryTalk
Alarms and Events system includes tag-based alarm servers, the timestamps for those
alarms come from the computer that is hosting the server. For FactoryTalk Alarms and
Events device-based alarms, the timestamp is received from the ControlLogix
processor where the alarm was generated.To ensure that alarms are ordered properly
by time, you must synchronize the computer’s clock with the controllers’ clocks.
For more information refer to the FactoryTalk View Site Edition User's Guide, "Setting
up FactoryTalk System Availability "
Refer to the FactoryTalk Alarm & Event Configuration Guide:
WIN-911 SCADA alarm notification software

FactoryTalk Alarms and Events has been qualified for use with Win-911 software. They
are a Rockwell Automation Encompass Partner.
WIN-911’s SCADA alarm notification software creates a reliable remote message
delivery system. If an industrial process malfunctions, the SCADA system will detect the
problem and WIN-911’s alarm notification software will send out notifications by text
message or email to the people who need to know. An error in a SCADA system can lead
to large scale problems, WIN-911 sends alerts directly to specific personnel so the
message will be received, logged and managed. This allows your operators and plant
managers to focus on other tasks while WIN-911’s software monitors the emergency
response.
There are multiple types of connections offered by WIN-911 to integrate with different
SCADA systems. The WIN-911 Direct Connect is recommended solution for SCADA
products such as FactoryTalk View SE and FactoryTalk View ME. Your SCADA systems
determines the issue and WIN-911’s intelligence decision matrix pushes out the remote
alarm notification. The users can acknowledge and manage the alarm in the SCADA
database through voice, text or email.
Win-911 Website: http://www.win911.com

AID 558027 - Where can I download Win911 for FactoryTalk View SE/ME or PanelView
Plus
AID 565196 - Win911 subscribing to an alarm using Alarm and Events in FactoryTalk View
SE
18 Datalogging
Data logging is a FactoryTalk View SE component that collects and stores tag values.
When using a Datalog Model, a user can define which tags to collect for a specific
configuration and where to store the collected values.
When planning data collection, design the system so only essential data is collected.
Limiting data collection is important because collection activities require substantial
processing power and generate significant traffic on the communication channel or
network.
Keep data collection requirements in mind when designing the layout of the
programmable controller data tables and the tag database. Ideally, tag addresses
should reference contiguous blocks of programmable controller data tables to reduce
network traffic and optimize system response.
In a redundant SE system it is suggested to log to a third computer as opposed to locally,
in doing this there is only one location to manage the data and there is no need to merge
multiple files or databases together after a failover or switchover.
Datalogging to Secondary Path

FactoryTalk View SE allows for a secondary or backup path to be specified if the primary
path for file sets or the ODBC database becomes unavailable. This could happen
because of network failures or because of lack of disk space on the computer where
the data is being logged.
If the primary data log location becomes unavailable, FactoryTalk View SE begins to
store the data in a buffer. The buffer can hold up to 64 Kb of data. If the primary location
is still unavailable when the buffer fills, or when the maximum amount of time to buffer
data has elapsed, FactoryTalk View SE switches to the secondary path.
FactoryTalk View SE checks periodically to determine whether the primary file path has
become available again. If it has become available, FactoryTalk View SE switches back
automatically.
If both paths are unavailable, FactoryTalk View SE buffers the data. If the buffer fills and
both paths are still unavailable, FactoryTalk View SE empties the buffer (the data in the

buffer is lost) and begins storing new data in the buffer. FactoryTalk View SE continues
checking both paths until one becomes available.
Multiple datalog models

At run time, up to 20 models can run simultaneously on each FactoryTalk View SE
Server. Use multiple data log models to:
• Store related information in separate file sets
• Log groups of tags at different rates
• Log groups of tags based on events
Datalog Storage Formats

Logged data is stored in either an internal file set, providing faster performance for
historical trends, or in an ODBC compliant database. If a file set is used, tag values are
stored in proprietary format files. Trend objects can read the data to plot in a graphic
display.
If values are stored to an ODBC compliant database, it is highly recommended that this
be a separate database server. This data can then be viewed using products such as
FactoryTalk Historian Classic, FactoryTalk Historian Site Edition, or third party ODBC
compliant tools such as Microsoft Excel or Seagate Crystal Reports.
If the ODBC database becomes inaccessible, FactoryTalk View SE logs the data to
backup files in proprietary format. The location of backup files is configurable.
The datalog internal file set can be opened, viewed, and saved to CSV file format using
the File Viewer utility.
Each data storage file format will have its own database limitation.
AID 33773 - Datalogging file limitations in FactoryTalk View SE
FactoryTalk View Site Edition User's Guide, refer to "Setting up data logging"
19 Global Objects
A Global Object Library can be used to improve efficiency and provide better
organization of large projects.

A Global Object is an object that is created once and can then be referenced multiple
times on multiple displays in an application. When changes are made to the original
(base) object, the copies (reference objects) are changed as well.
A Global Object display (.ggx file) contains the base objects. It is possible to define
multiple base objects within a single Global Object display. A base object can also be
made up from other base objects.
Define only a few base global objects per Global Object display.
Because a base object can contain other base objects, the entire Global Object display
must be loaded into memory every time one of its objects is referenced at runtime. By
limiting the number of base objects to 10 or 20 per Global Object display, performance
is improved at runtime by:
• Speeding up the loading of Global Object display into memory.
• Speeding up a search process for the base object referenced within the Graphic
display.
Example: A Global Object display containing 200 base objects which are referenced on
several graphic displays can take approximately 10 to 20 seconds to load when selected.
What's happening?: Each time a Graphics display referencing a base object is called,
the entire Global Object display with 200 base objects will be loaded in memory and
searched for the required components. The search can have severe performance
impact on the HMI client, particularly on lower-end servers with a lot of client
connections.
Solution: Divide the Global Object display into 10 smaller Global Object displays each
containing about 20 base objects.
Effects of the Solution: During run-time, smaller Global Object displays will load much
faster, the search for the corresponding base objects will be much faster, and overall
client performance will improve by order of magnitude when displaying that particular
screen.
FactoryTalk View Site Edition User's Guide, refer to "Creating Graphics Displays".
20 Security
Security threats to a Process Control System generally fall into 4 categories: external,
internal, intentional and accidental.

Detailed security recommendations against external threats are beyond the scope of
this document. However, there are some basic measures that should be taken to
protect against the most common threat – the day-to-day users of the HMI system.
Recommendations in this area include:
• Password protect the computer’s BIOS. To prevent booting from anything other
than the local hard drive, configure the computer to boot only from the hard drive,
and then configure a BIOS password so that mischievous users cannot change the
boot device.
• Password protect the local Administrator account. This often overlooked task is
critical.
• Configure the Windows environment so that it is “strictly business” for the
operators. Restrict access to required applications only using Group Policy (in a
domain) or Local Policy (on an individual machine or workgroup). The provided
FactoryTalk View “DeskLock” tool can also be used for this purpose.
FactoryTalk Security
FactoryTalk Security authenticates user identities and authorizes user requests to
access a FactoryTalk-enabled system. These security services are fully integrated into
the FactoryTalk Directory and are included as part of the FactoryTalk Services Platform.
FactoryTalk Security includes user authentication that determines who can open,
create, modify, and delete application components, and on which computers the
actions are allowed. Use FactoryTalk Security to add user and group security accounts
as well as Windows-linked accounts, and set up security for common operator actions.
FactoryTalk Security can be configured to:
• Prevent writes to specified tags from the FactoryTalk View SE Client.
• Prevent access to specified displays from the FactoryTalk View SE Client.
• Prevent access to specified commands from the FactoryTalk View SE Client.
• Prevent changes to the application from FactoryTalk View SE Studio or the
FactoryTalk View SE Administration Console.
To open the FactoryTalk View SE User Accounts editor or the Secured Commands
editor, the user requires access to the Common/Create Children action, in addition to
the Common actions, Configure Security, List Children, Read, and Write, on the area or
application.
AID 30980 - FactoryTalk Security - Tips and Best Practices

21 Trending
When planning trends, consider how they will be used. For example, will the trend be
used to:
• Analyze process information.
• Monitor production efficiency.
• Review archived process variables to ensure compliance with government
regulations.
• View short-term historical data to help operators make quick decisions.
Based on such considerations, it can be determined:
• Which tags need to be plotted on the same trend.
• Which tags need to be plotted from a data log model or FactoryTalk Historian.
• Which tags need to be plotted against time, or against another tag.
Trends can display real-time or historical data, from data log models or FactoryTalk
Historian SE. Trend Templates may be used to create pre-configured trend objects for
use in graphic displays. Trend Snapshots may be used as overlays with real-time trends.
FactoryTalk View Site Edition User's Guide, refer to "Setting up Trends".
For additional details, see Rockwell Automation Knowledgebase Answer ID:
AID 1087720 - Trend Object Comparison (TrendX, TrendPro)
22 Language Switching
Language switching allows operators to view user-defined text strings in an
application, in up to 40 different languages. At run time, in a distributed application,
multiple FactoryTalk View SE clients can switch between any of the languages the
application supports.
Generally, it is best practice to develop all the screens in one language first, then import
the translations at the very end. Once translated, all screen text edits and additions
must be updated in both languages.
FactoryTalk View Site Edition User's Guide, refer to "Language switching".


Runtime language switching is also supported for alarming when using FactoryTalk
Alarms and Events.
FactoryTalk Alarm and Events System Configuration Guide, refer to “language”.
Using Localized Language Versions of FactoryTalk View SE

Localized language versions of FactoryTalk View SE are not required for the viewing or
translation of displays and alarm text. Do not install a local language version of
FactoryTalk View SE (for example, German, French or Japanese) on an English
Operating System or errors may occur. For best results, use the same localized
language version of FactoryTalk View SE on the same language of operating system
install.
23 Graphic Displays
Develop Hierarchies for Efficiency and Clarity
Develop a hierarchy of displays with each display giving more granular detail of an
object, area or function. This prevents displays from being cluttered by attempting to
display a large amount of information at one time. This also reduces the demands on
the Live Data Server from having to poll and display a large amount of unnecessary data.
Create Templates
Create templates to ensure consistency of appearance. Use global objects and
parameter passing for efficient re-use of screen content.
Naming of Application Components

FactoryTalk® View SE supports long file names. File names also include the path and
can be up to 200 characters long. For example a graphic display that has the file name
“System Overview” has 15 characters in it. However, it is actually 118 characters because
it also includes the directory path as shown in the example below:
“C:\Documents and Settings\All Users\Documents\RSView SE Enterprise\SE\HMI
Projects\My Application\Gfx\System Overview.gfx”

Avoid using graphic display names that conflict with commands or macros
As with graphic display names, you can also choose your macro names. Avoid using the
same names for displays and macros. The underlying system will clearly understand
your intentions calling macros to run. The same consideration should be used to avoid
naming macros or graphic displays the same as native system commands. For example
“Display” is a system command. Do not name a graphic display “Display”. For a list of
FactoryTalk View SE system commands, refer to
FactoryTalk View Site Edition User's Guide - Publication VIEWSE-UM006
Search and Replace for Tags on a Graphic Display

FactoryTalk View Studio provides a tool to Find and/or Replace Tag names. Search for
every occurrence of a specific tag or text string throughout the graphic and global
object files of a FactoryTalk View SE application. You may replace text or tag names
with different text and undo your changes. The location (the scope) of the search can
be one or more displays and HMI servers that belong to the same application.
Note: Find and Replace does not include VBA code. This capability is included separate
in the VBA Editor.
Cross Reference Search

This FactoryTalk View Studio tool gives the ability to find tags and text strings in the
following HMI project components: Tag Database, Displays, Global Objects,
Parameters, Macros and Datalogs. Use the Cross Reference form to specify the tag or
text string to be searched for, the location, and components to be searched and then
display the location and components in a spreadsheet form. Same as Find and Replace
feature, it operates across multiple HMI servers and presents results in an interactive
spreadsheet format. Once listed in the spreadsheet, just double-click the component
to open it in the appropriate editor.
Graphic Display Navigation Buttons

You can use the navigation button object to create buttons to navigate between
previously viewed graphic displays. FactoryTalk View SE can maintain a navigation
history of displays that have been opened by the user. The navigation buttons let you
browse back and forth to previously opened displays.
You can create up to three types of navigation buttons. Each navigation button
performs a single function at runtime, with the option to display the previous screen,
the next screen, or the navigation history.

Navigation history is optional and is configured for each FactoryTalk View SE Client. To
track displays you can specify what displays to track by using the Properties tab in the
Display Settings for each chosen display. This provides flexibility for tracking only the
displays necessary.
For additional details, click on Help in the FactoryTalk View SE Client wizard
FactoryTalk View Site Edition User's Guide - Publication VIEWSE-UM006
Caching Graphic Displays

In the Display Properties you have the option to set it for being cached in memory after
being displayed or not.
If you select “No” for this setting, the display will not be loaded into the display cache
memory when it is displayed for the first time. Most displays in the application will be
configured as displays that are not cached. This will have a positive impact on
performance, as memory usage is kept to a minimum on the number of displays stored
in memory.
If you select “Yes” for this setting, the display will be loaded into the display cache
memory when it is displayed for the first time. This means when the graphic display is
called again to re-open the data will be displayed quickly. The improved performance
will depend on how many tags are part of the graphic display. To remove displays from
the display cache memory at runtime you will need to use the “FlushCache” command.
A sub-option to choosing “Yes” is “Always Updating”. Select this check box keep the data
updating even when the display is not visible to the user. For example, choose this
option to continuously update trend data on a display even if it is not visible. This option
will also make displays re-open even faster. Always updating a cached display can cause
added communications overhead because the data will be retrieved for tags whose
values might not otherwise be necessary. If you use the Always Updating option with
the “Cache After Displaying” option (Display <display name> /ZA), the startup command
is executed when the display is loaded into the cache. The shutdown command is
executed only when the cache is emptied (using the “FlushCache” command).
Note: Each display in the display cache uses memory. Once Windows consumes all
physical memory, it is forced to swap to disk. This can have an undesired impact on the
system, resulting in all SE Client activities occurring slower than expected. To conserve
system resources, limit the total number of displays in the cache to 40. This includes
displays loaded using options configured through the display settings using the Display
<display name> /Z or /ZA command.

Caching Global Object Displays
If a Graphics display contains 10 or more reference objects and is being accessed
frequently, consider setting its “Cache After Displaying” property to “Yes”.
Note: Caching the Graphics display may improve performance, but be aware that any
runtime edits on the base object will not be reflected in the Graphic display until the
FlushCache command is issued or an SE client session is closed and re-started. The
maximum recommended number of simultaneously opened "cached“ displays is 40.
Cached displays consume memory. Always updating a cached display can add to
communications overhead, as data is retrieved for tags whose values might not be
needed.
Rockwell Automation Knowledgebase Answer ID:
AID 482415 - FactoryTalk View Site Edition: Cache After Displaying
Overlay vs. Replace

When creating graphic screens, select “Replace” as often as possible as it will cause the
currently displayed screen to close while opening the newly requested screen. If
“Overlay” is selected, it must be managed more closely. It is possible for multiple
screens to be open one on top of the other using up memory and CPU resources
unnecessarily. The number of displays that are displayed or minimized simultaneously
should be limited to 40.
Use Wallpaper
When importing a large graphic object (*.jpg, *.bmp) to use as a background, converting
the object to wallpaper will allow smoother mouse control over the object and provide
a better environment for developing the graphic. It also saves memory for faster display
of screen.
Faceplates
Consider using faceplates. Faceplates are standard screens that can be used (and re-
used) within an application. Faceplates can correspond to a Logix5000 instruction, a
tag structure within Logix5000 AOI, or any group of tags that is repeated throughout an
application. Process faceplates can be included in any application by right-clicking on
the HMI server in FactoryTalk View Studio and selecting “Add Process Faceplates…”. A
faceplate is a graphic screen like any other and counts toward the licensed display
count of an application.

In addition you can obtain PlantPAx Process Objects Library. They are a collection of
sophisticated AOIs and coordinating faceplates that provide functionally typical for
process customers.
Rockwell Automation Knowledgebase Answer ID:
AID 62682 - Rockwell Automation Library of Process Objects (Process Library) for the
PlantPAx System
Other Faceplates can also be found through the Sample Code Library. Download of
these faceplates is free and does not require a support contract. However, take note
that users may submit code as well and some code may be unverified. Be sure to test
any downloaded code thoroughly before placing it into production. Searching for
keyword "Faceplate" will uncover faceplates created for Rockwell Automation devices.
http://samplecode.rockwellautomation.com
Graphic Display Update Rates

This setting can be found in each graphic display’s settings. Keep update rates only as
fast as necessary for the processes like Tag Read/Write, Datalogging, Derived Tags or
Events. These update rates are important and can have a direct influence on the
performance of the HMI server and clients. The update rate is also influenced by the
rate at which the tag in the target device changes.
Graphic Display Limitations

Each graphic display can contain up to 3,000 references to expressions or tags (HMI and
Direct). This limit includes the tags contained in embedded variables.
AID 584999 - Explanation of graphic display tag connection limit in FactoryTalk View SE.
Using Object Embedded Variables

Embedded variables can be used to provide information in a graphic display that
updates dynamically at run time.
Embedded variables can contain the following elements:
• Tags
• Tag placeholders
• Literal numbers or strings
• The time and date

Using the caption text for text objects, button objects or local message objects, tag
based embedded variables can be used to dynamically display new tag values whenever
it is read from the data source..
Embedded variables that use tags in tooltip text will show the value that is captured
when the mouse hovers over the object, but it does not update dynamically while the
display is running.
Embedded Variable Recommendation:

It is best practice to use the Numeric and String objects to display data dynamically
using tag data sources.
When several hundred data values need to be displayed dynamically on a graphic
display, the Numeric and String objects are better designed to request data from many
of these objects efficiently using tag groups.
Using Embedded Variables with a Text object or with the states of Multistate Indicator
objects is acceptable practice when there are only a few of these objects on a graphic
display.
When large quantities of Text objects or Multistate Indicator objects are used with
dynamically updating embedded variables, they retrieve the data values one object at a
time. Unlike Numeric and String objects which are designed to form graphic display tag
groups for efficiency when updating.
Product testing has indicated that exceeding the use of more than 200 objects
configured with dynamically updating embedded variables will affect how quickly the
data will update when a graphic display is initially opened.
The amount of delay for the data to update can vary depending on how many objects are
using embedded variables and the way they are implemented on the graphic objects. In
extreme cases, the delay could be 10 seconds or more.
It is recommended that no more than 200 objects that are using embedded variables
that are dynamically updating data be used on a single graphic display.
Answer ID 1086271 - FactoryTalk View SE recommendation for the maximum number of
objects using embedded variables.
Using ActiveX Controls on a Graphic Display

A FactoryTalk View SE graphic display can be a container for an ActiveX control. An
ActiveX object is a software component that is either supplied with FactoryTalk View
SE or used from an independent source such as Microsoft Office, Visual Basic, and
many other third-party applications.

An ActiveX object gives access to its features through the object’s properties, events,
and methods. By embedding an ActiveX object in a FactoryTalk View SE graphic display
and then assigning properties or specifying handlers for the object’s events, the object
can interact with FactoryTalk View. Information can be passed between an ActiveX
object and FactoryTalk View SE using FactoryTalk View SE Tags. If a FactoryTalk View
SE tag is attached to an ActiveX object’s Value property, the object’s behavior changes
as the tag’s value changes.
Be aware that ActiveX versions may vary based on the operating system and in turn may
not work properly.
AID 775669 - Registering ActiveX control using FactoryTalk View Studio
For additional details, see the FactoryTalk View Site Edition User's Guide
Using VBA with FactoryTalk View SE Graphic Displays

Visual Basic for Applications (VBA) can be used to customize and extend the capabilities
of FactoryTalk View SE. FactoryTalk View SE graphic displays include the ability to
incorporate VBA scripts. Use the VBA integrated development environment (IDE) to
create, test, and debug VBA procedures that run in response to events triggered from
within FactoryTalk View SE graphic displays.
• VB third-party access to the FactoryTalk View SE Display Client object model,
which includes the Tag and Graphic object models, is not supported. Access to the
FactoryTalk View SE object model is available only within the FactoryTalk View SE
client’s VBA.
• Limited support is available through Rockwell Automation Technical Support for
customers needing assistance debugging their VBA scripts. A maximum of 20 lines
of code per problem can be considered.
• Use of custom VBA code should be limited. Only use when a native feature of the
product does not meet the necessary requirements.
• VBA is single threaded.
• VBA is not compiled code.
• VBA is not recommended for continuous calculations. For continuous
calculations, the use of an OCX or EXE is recommended only if derived tags are not
suitable.

Top 6 Best Practices when using VBA
1. Don't use VBA if you don't have to.
Instead of this in VBA… Do this in FactoryTalk View SE…
Read in a lot of tag data to Perform calculations via Derived Tags

perform calculations
VBA Forms or modal VBA Use displays instead of VBA forms since they do not block object
popups events or have the chance of getting caught “behind” the
operator’s HMI screens.
MsgBox (“Hey operator, Log your messages to the FactoryTalk Diagnostics log, or use a
something happened!”) FactoryTalk View SE display with the message in a string tag if you
want it to be obvious.
Use VBA to check for high/low FactoryTalk View SE Numeric Input objects contain numeric entry
limits when operator enters a high and low limit settings, as well as an option to set tooltip text
set point. for the operator.
Use VBA to read in tags to set Embedded variables allow you to dynamically insert tags into the
text displays for the operator, captions on graphical objects, tooltip text, local messages and
popup window titles, or display title bars.
tooltips.
2. The use of error handling is required.

• Option Explicit is not an option.
o Make it a habit to use this at the beginning of ALL your VBA code.
o Use this to catch typos or mismatch problems before they become an error.
• Always use an Error Handler!
o Test for Error after each object call, and take appropriate action.
o Preferred: On Error Goto ErrHandler
o Errors are categorized and logged to the FactoryTalk Diagnostics log.
o Always use the IsError() function with numeric and string objects
• Write your errors to the FactoryTalk Diagnostics Log!
o With meaningful error messages that capture the screen name, routine
name, and other useful information.
o Use VBA Err.Num and Err.Desc objects to catch system errors.

3. Avoid using VBA Forms or Message Boxes msgbox()
• They can prevent other VBA calls or events.
• Modal popups can get caught “behind” the HMI screens which can produce
confused and frustrated operators.
4. Limit database interfaces within VBA code.
• Do not attempt to replace the functionality of FactoryTalk Transaction Manager.
• If your database is located on a networked PC, be prepared to deal with potential
disconnections or network issues. These can cause hang-ups or delays in your
VBA code.
• As databases grow over time, size or improper indexing can cause significant
delays or hang-ups.
• Be ready to handle database table or record locks, especially in multi-user
environments.
5. Test before deployment in a realistic runtime environment with real controllers
and running control code. What works in the development environment may work
differently in the runtime environment:
• Slower tag loading.
• Slower client execution.
• Unforeseen operator actions.
• Client CPU usage and memory allocation.
6. Reuse and comment your code.
• Use version control, especially if you are giving your screens/code to someone
else.
AID 30399 - Recommendations For Writing Visual Basic for Applications
AID 51771 - Sample VBA: Learn Error Handling Techniques
AID 51769 - Sample VBA: Trend pen manipulation at runtime
AID 724611 - Sample VBA: Position a popup or faceplate in SE relative to the clicked
mouse position
AID 51768 - Sample VBA: How to query the A&E History database and display results in
FactoryTalk View SE

AID 23528 - Accessing VBA code hosted in one display from a different display
AID 22007 - How to trigger a command on an SE client from an HMI server
AID 54424 - Sample VBA: Using a Wrapper Module to Log Standard Error Messages
Import and Exporting of Graphic Display XML Files

FactoryTalk View SE stores graphic displays in a proprietary format using a .gfx
extension (e.g., DisplayName.gfx). However, the Graphics Import Export Wizard in
FactoryTalk View SE Studio allows for both graphic displays to be exported to an XML
file, and graphic displays to be imported from an XML file. The XML files can be edited
to modify objects that already exist or to add new objects.
A display cannot be imported or exported that is currently open in the same instance of
FactoryTalk View SE Studio. Having the display open in a second or remote instance of
Studio will not cause it to fail. However if an older version of a display is open and it is
saved after the import has been done, the imported changes will be overwritten.
Since XML files are text files, you can perform search and replace operations on
STRINGS that are contained within graphic displays before you import them back into
the application.
AID 29942 - FactoryTalk View Graphic Strings Search and Replace using Graphics XML
Exported Files
24 HMI Server Startup Type

The HMI Server Startup involves starting and running multiple components (services).
There are two options for starting the HMI Server: “On Demand” and “Load and run
startup components when operating system initializes”. This setting can be accessed
in FactoryTalk View Studio or the FactoryTalk Administration Console by right mouse
clicking on the HMI Server icon and selecting properties.
In general ‘On Demand’ is selected during development so that all the services do not
startup every time the HMI Server is started. This setting is useful for development
stations or machines hosting many different HMI applications that may not all need to
be running at once.
Once the system is deployed – or if a redundant HMI Server system is desired, then it
should be set to “Load and run startup components when operating system initializes”.

25 Multi-User System Remote HMI Client Awareness
Alarming, Datalogging and Derived Tags are all HMI Server components (services).
When an application is administered or run by multiple users, behavior which is
appropriate in a single-user, single computer environment might not function as
expected in an application with multiple remote HMI clients.
For example, a graphic display is running on several remote client computers and it uses
a macro that stops a derived tags file. When that display is closed on one client, the
shutdown macro will stop the derived tags file on the HMI Server, which means it will be
shut down for all the running HMI clients. This behavior would be true for the other
server side components like Datalogging.
26 Multi-Monitor Support
Multi-monitor deployment – FactoryTalk View SE version 10 (CPR9 SR10) and later
Supports the automatic and dynamic management of HMI application displays. This
provides operators more screens to view more information about process operations
from a single workstation.
• The monitor configuration is defined per client and can be unique per operator
station.
• An HMI Client configuration can support individual configuration of up to six
monitors.
• Applications can span multiple monitors. You can easily drag the displays between
monitors.
• HMI displays can be displayed on the specific pre-configured monitors or
dynamically based on the relative location of originating request.
• The ‘/M’ parameter provides the ability for the display command to specify which
specific monitor the display should be opened on.
Multi-Monitor Support in versions prior to 10.0 (CPR9 SR10)

Multiple monitors can be implemented in one of two ways:
1. Launch two separate FactoryTalk View SE clients for each monitor. XY display
coordinates can be set for each client so that they always open on a specific

monitor. Or an operator can manually move a client once it is open onto the desired
display.
2. Run a single FactoryTalk View SE client where the HMI developer has configured
the XY coordinates all of the displays to open on one or other specific monitor.
Application popups can be given XY coordinates or can use VBA to appear wherever the
mouse click occurred. However, system popups (not HMI application popup) will always
show up on the "first" monitor..
AID 724611 - Sample VBA: Position a popup or faceplate in SE relative to the clicked
mouse position
AID 34321 - Using RSView SE Distributed with multiple monitors
27 Applying FactoryTalk View SE in a 21 CFR Part 11 environment

It is often asked if FactoryTalk View SE complies with the electronic records and
signatures portion of 21 CFR Part 11 (Title 21 – Code of Federal Regulations – Part 11).
FactoryTalk View SE has been designed to meet the needs of customers needing to
comply with regulations such as 21 CFR Part 11. However, the software product in itself
cannot be compliant, but when the software is applied properly it can make a system
compliant.
AID 23120 - Applying RSView SE in a 21 CFR Part 11 environment.
28 Maintenance and Troubleshooting

There is no replacement for a conversation with Technical Support when you believe
there may be a real issue. Getting familiar with Maintenance and Troubleshooting
techniques may help you understand the system better. This will assist you to diagnose
and solve issues quickly and to communicate to Technical Support the issues being
experienced.
Using FactoryTalk Diagnostics

FactoryTalk Diagnostics is the central location for warnings and errors generated by the
system. FactoryTalk Diagnostics and Audit allows you to collect, store, and examine
messages from multiple FactoryTalk-enabled products in a single, central location. Use
these messages to your advantage!

FactoryTalk Diagnostics include:
• Command and macro usage
• Operator comments and other actions (such as tag writes)
• System messages and errors
• Communication network messages
• Tag read and write activity etc.
The information can be:
• Viewed in the FactoryTalk Diagnostics Viewer List (shown above)
• Viewed in a Graphic display using the FactoryTalk Diagnostics Viewer Object
• Archived for future analysis
• Exported to ODBC format
Choose where to log messages by type and specify which categories of messages
should be routed to the logging destination.
AID 41060 – How to move the FactoryTalk Diagnostics Log to Another Location
AID 41498 - Tips for viewing the FactoryTalk Diagnostics logs of several computers
simultaneously
AID 54424 - Sample VBA: Using a Wrapper Module to Log Standard Error Messages
Patching FactoryTalk Products and Applications

Periodically, product patches are released to fix product anomalies. In general, once a
system is deployed and working successfully, it is not recommended to install a patch
roll-up simply because it exists. Patches should be used to address problems that are
being experienced and affecting the application.
Patches are included in a single patch roll-up execution file so that all patches can be
applied at once. Even though all patches are included in the roll-up, only patches that
are actually required for an installed product will be applied. The roll-up uses specific
check files to confirm which product is installed. The roll-up will only install patch files
provided these files already exist on the target computer, unless a new binary file is
being introduced as part of a patch. The patch roll-up includes patches for the following
products:
• FactoryTalk View
• FactoryTalk ViewPoint

• FactoryTalk AssetCentre
• FactoryTalk Batch
• FactoryTalk Transaction Manager
• FactoryTalk Metrics and Report Expert
• FactoryTalk Alarms and Events
• FactoryTalk Services Platform
• FactoryTalk Linx
• FactoryTalk Linx Gateway
• RSLinx Classic
Master list of all available Patch Table of Contents (TOC)

AID 897919 - Master list of all available Patch TOCs
Verifying Installed Patches

To make sure patches were installed successfully, a utility called the Patch Validator
utility can be used to compare the files installed on a computer to a list of patch files
currently available. The Patch File Validator utility will run automatically after a roll-up
has been applied.
AID 30393 - Patch File Validator Utility
The roll-up version is also written to the computer registry location:
HKEY_LOCAL_MACHINE\SOFTWARE\Rockwell Software\Patch Roll-ups
Applying Patches to Redundant HMI Server Application

You may be able to minimize downtime when applying software patch roll-ups to
running systems with redundant HMI servers by following this suggested step-by-step
procedure.
AID 64357 - FTViewSE CPR9: Minimal downtime installation of a patch rollup to
redundant HMI servers

29 FactoryTalk View SE Tools
FactoryTalk View Application Documenter
A stand-alone utility that provides very detailed information on SE or ME projects. The
user is able to select the components and elements they need to view. The complete
project information or only selections can be printed to provide a quick comprehensive
hard copy reference manual. This tool is automatically installed with the product.
FactoryTalk View SE Application Manager

A utility that simplifies the backup and restore operations. You can use it to back up,
restore, rename and delete FactoryTalk View SE applications, including the FactoryTalk
Directory.
DeskLock
A utility that locks users in the FactoryTalk View SE Client program and prevents them
from having access to the Windows desktop and using Windows system keys.
FactoryTalk View SE Cache File Management

A utility that can be used to manage temporary internet files. This tool may be used on
systems with Internet Explorer 10 and later.
FactoryTalk View SE Custom Web Site Setup

A utility that allows for a more secure web site to be configured that IIS will use instead
of its default web site, to transfer information between HMI servers and clients in a
FactoryTalk View SE network application.
For information about when and how to enable it, refer to the Rockwell Automation
Knowledgebase Answer ID:
AID 39618 - FactoryTalk Internals: FactoryTalk View Site Edition IIS Handbook
AID 506034 - FactoryTalk View Site Edition: FactoryTalk View SE Secure / Custom Web
Site Setup tool
Graphic Strings Search and Replace

A utility to perform search and replace operations on strings that are contained within
graphic displays.

HMI Server Backup and Restore
A utility that allows for a backup to be created of a running HMI server project. Only
backup the HMI Server files and not the entire application.
Legacy Tag Database Conversion

A utility to convert your legacy HMI server projects (version 6.0 and older) so the Tag
database will function with Microsoft SQL.
Tag Import and Export Wizard

A utility for importing or exporting the FactoryTalk View SE Server’s HMI tag database.
Exports it to a CSV file format, so that multiple modifications can be made to the file
and imported back with any changes.
FactoryTalk Live Data Test Client

The Live Data Test Client allows you to troubleshoot FactoryTalk OPC communications,
Direct Reference and HMI Tags.
30 Other Tools and Utilities

Windows Event Logs with FactoryTalk Diagnostics
FactoryTalk Diagnostics was added to the Windows Event Viewer so all computer log
files are accumulated in the same place.
AID 31073 - Tool for collecting Event log files (Windows O/S up to and including Windows
Server 2003, Windows XP)
AID 453900 - Batch file script to collect Windows event logs for Windows Server 2008 /
Windows 7 (32 or 64 bit) and later operating systems
Windows Performance Monitor

Create historical logs and alerts for resource conditions such as running out of process
memory.
AID 31196 - Monitoring FactoryTalk View SE memory and CPU usage using Performance
Monitor
31 RSView32 to FactoryTalk View SE Conversions
Converting an application from RSView32 to FactoryTalk View SE is a built-in option
that can be selected when creating a new HMI server.
Keep in mind, that the following HMI components will not convert from RSView32 to
FactoryTalk View SE:
• Native View32 trends
• Tag monitors
• Command lines embedded in graphics
• Alarm Summaries
• External applications that depend on RSView32 to be an OPC or DDE Live Data
Server
Certain ActiveX controls may not function as they did in RSView32. These will need to
be evaluated on a case by case basis.
To migrate an RSView32 project to a FactoryTalk View SE distributed application, do
not use the “Attach” option. Instead, create a new HMI server by importing the project.
To do this, select ‘Import a project” in the Select Operation window of the Add HMI
Server Wizard. Then in the Import Project window, select RSView32 as the project type
and specify the path to the RSView32 project file.
AID 27708 - RSView32 to FactoryTalk View SE Conversion Guides
AID 49241 - RSView32 to FactoryTalk View Supervisory Edition Migration
Considerations
VBA – RSView32 to FactoryTalk View SE

FactoryTalk View SE Version 11 and later - New VBA interface for HMI tag database.
Additional details for migrating RSView 32 VBA, see Rockwell Automation
Knowledgebase Answer ID:
AID 51770 - Sample VBA: Exercise in migrating a View32 application with VBA to ViewSE

32 Reference Information Links
FactoryTalk View Tips and Best Practices Table of Contents
AID 37110 - FactoryTalk View Tips and Best Practices TOC
Compatibility
AID 35330 - Rockwell Software Products and Antivirus Software
Tricks and Tweaks

AID 22007 - How to trigger a command on an SE client from an HMI server
AID 29298 - How to play an SE client wave file triggered off of an alarmed tag
AID 31307 - How to AppStart the Windows "User Account" Manager from FTViewSE
AID 33075 - How to print a text file using VBA and Notepad
AID 494565 - In FactoryTalk View SE client how to Enable/disable Auto Logout
AID 41060 – How to move the FactoryTalk Diagnostics Log to Another Location
AID 41498 - Tips for viewing the FactoryTalk Diagnostics logs of several computers
simultaneously
AID 36594 - How to disable Alt-F4 and Ctl-F4 in an FactoryTalk View SE client
Data Communications
FactoryTalk Linx Getting Results Guide (Publication LNXENT-GR00)
AID 58963 - RSLinx Classic, RSLinx Enterprise, FactoryTalk Linx Driver Compatibility
Matrix
AID 52353 - OPC and DCOM Information, Tutorials and Troubleshooting
AID 65406 - Using FactoryTalk Applications with Third Party Devices
AID 29402 - TCP/UDP Ports used by Rockwell Automation products
AID 26464 - RSLinx Internals: OPC/DCOM timeouts when a remote client is
disconnected
AID 68789 - RSLinx Enterprise LogixDP Data Provider Information
AID 507425 - Data Server Decision Guide
AID 609894 - Optimize ControlLogix Performance for FactoryTalk Client Applications
AID 780671 - FactoryTalk Diagnostics Counter Monitor
ControlLogix
ControlLogix Selection Guide (Publication 1756-SG00)
RSLogix5000 Controllers Design Considerations (Publication 1756-RM094)
ControlLogix Redundancy System User Manual (Publication 1756-UM523)
ControlLogix Enhanced Redundancy System User Manual (Publication 1756-UM535)
AID 47065 - ControlLogix Controller Common Specifications
AID 40314 - How Many ControlLogix Processors Are Supported in a Single Chassis
AID 45926 - Logix 5000 Tag Import Utility for RSView32, FactoryTalk View Studio and
FactoryTalk Transaction Manager


FactoryTalk View Site Edition Version 11 (CPR9 SR11) Design Considerations

Uploaded by

Copyright:

Available Formats

FactoryTalk View Site Edition Version 11 (CPR9 SR11) Design Considerations

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FactoryTalk View Site Edition Version 11 (CPR9 SR11) Design Considerations

Uploaded by

Copyright:

Available Formats

Reference Guide

Design Considerations - FactoryTalk® View Site Edition

Copyright ©2019 Rockwell Automation, Inc.

Design Considerations - FactoryTalk View Site Edition – January 2019 Page 2 of 70

Design Considerations - FactoryTalk View Site Edition – January 2019 Page 3 of 70

Design Considerations - FactoryTalk View Site Edition – January 2019 Page 4 of 70

Design Considerations - FactoryTalk View Site Edition – January 2019 Page 5 of 70

How Windows Time Service Works

Windows Time Service Tools and Settings

Design Considerations - FactoryTalk View Site Edition – January 2019 Page 6 of 70

Other Network Considerations

NIC Card Teaming

Auto-Detect NIC cards (Auto-negotiation)

Design Considerations - FactoryTalk View Site Edition – January 2019 Page 7 of 70

3 Computer Hardware and Operating Systems

Supported Operating Systems

Microsoft Security and other updates

Design Considerations - FactoryTalk View Site Edition – January 2019 Page 8 of 70

Server vs. Workstation Operating System

Design Considerations - FactoryTalk View Site Edition – January 2019 Page 9 of 70

Workgroups vs. Domain

Workgroup: Decentralized Administration

Domain: Centralized Administration

Design Considerations - FactoryTalk View Site Edition – January 2019 Page 10 of 70

Domain Controller Redundancy

Design Considerations - FactoryTalk View Site Edition – January 2019 Page 11 of 70

Internet Information Server (IIS)

Design Considerations - FactoryTalk View Site Edition – January 2019 Page 12 of 70

4 System Sizing Recommendations

Component Recommended guidelines

FactoryTalk Alarms and Events

FactoryTalk tag-based alarms per server 20,0001

Logix device-based alarms per server 10,0002

Total alarms per application 100,0003

Total device tags per application 1,000,0004

Tags per FactoryTalk Linx data server 100,0004

FactoryTalk View Studio instances 5 simultaneous connections to the same application

HMI servers 10 non-redundant servers or 10 redundant server pairs

HMI tags per HMI Server 40,0005

FactoryTalk View SE client sessions simultaneously 1204

FactoryTalk ViewPoint SE servers per application 4

FactoryTalk ViewPoint SE concurrent clients per 50

Design Considerations - FactoryTalk View Site Edition – January 2019 Page 13 of 70

5 FactoryTalk Services Platform Topology

FactoryTalk Directory Definition

FactoryTalk Application Definition

FactoryTalk Directory Redundancy

6 FactoryTalk View SE Station and Network Station

Design Considerations - FactoryTalk View Site Edition – January 2019 Page 15 of 70

7 FactoryTalk View SE Redundancy

Design Considerations - FactoryTalk View Site Edition – January 2019 Page 17 of 70

Runtime Editing a Redundant Application

Redundant Server Switchover Choices

Design Considerations - FactoryTalk View Site Edition – January 2019 Page 18 of 70

How to monitor which server is active and which server is standby?

Design Considerations - FactoryTalk View Site Edition – January 2019 Page 19 of 70

9 Client Considerations in a FactoryTalk View SE Application

Design Considerations - FactoryTalk View Site Edition – January 2019 Page 20 of 70