Honeywell Experion LX Client Manual
Experion LX
Station Planning Guide
EXDOC-X128-en-500A
April 2017
Release 500
Disclaimer
This document contains Honeywell proprietary information. Information contained herein is
to be used solely for the purpose submitted, and no part of this document or its contents shall
be reproduced, published, or disclosed to a third party without the express permission of
Honeywell International Sàrl.
While this information is presented in good faith and believed to be accurate, Honeywell
disclaims the implied warranties of merchantability and fitness for a purpose and makes no
express warranties except as may be stated in its written agreement with and for its customer.
In no event is Honeywell liable to anyone for any direct, special, or consequential damages.
The information and specifications in this document are subject to change without notice.
Copyright 2017 - Honeywell International Sàrl
Contents
Contents
Contents 3
About this guide 8
Enterprise models 9
About enterprise models 9
About asset models 9
About assignable assets and scope of responsibility 10
About system models 11
About generic displays 12
Guidelines for designing enterprise models 13
Guidelines for designing asset models 13
Guidelines for defining scope of responsibility 14
Naming rules for assets 17
Guidelines for determining the optimal topology for your plant 18
Example enterprise models and topologies 19
An asset model for a simple system 19
Implementing an enterprise model 20
Servers 22
Server redundancy 22
Distributed System Architecture 25
Inter-release support 25
DSA and firewalls 26
About point data in a DSA system 26
eServer 27
PHD 28
Remote Engineering and Station Server 29
Server scripts 30
Naming rules for computers 31
Servers and the Enterprise Model Database 33
ESM Server 33
Networks 34
Network redundancy 35
Honeywell 2017 3
Contents
Fault Tolerant Ethernet (FTE) 35
Process controllers 35
Time synchronization 36
Experion time requirements 36
About time protocols 39
Planning your time hierarchy 40
Planning considerations for time synchronization 43
Stations 45
Identifying user types and assessing their needs 45
Connection options for Flex Stations 46
About Console Stations 46
Mobility 47
Station update rates 48
Specialized Station hardware 49
Determining your Station requirements (an example) 49
Printers 51
Controllers 52
Interface references 52
Monitoring and control strategies 52
Connection options 53
Network connections 53
Direct serial connections 53
Indirect serial (terminal server) connections 54
Modems 56
Specialized links 56
Points 57
Point naming conventions 57
Point IDs and Distributed System Architecture (DSA) 60
Standard point types 60
Container points 62
System interfaces 62
Algorithms 63
History collection 63
Periodic history 64
Honeywell 2017 4
Contents
Exception history 64
Offset groups 65
Storage requirements for history samples 65
Archiving history samples 66
Groups 67
Trends 67
Scanning strategy 68
Basic principles of scanning 69
Scanning techniques 69
Scan optimization 70
Estimating the number of points required 71
System Status Network tree 72
About the System Status Network tree 72
About System Event Server and System Performance Server 73
Identifying a network topology 74
Workgroup topology 74
Domain with no Organizational Units (OUs) 75
Domain with Organizational Units (OUs) 77
Multiple domains or multiple workgroups 78
SES event notification behavior 79
Network tree planning summary 79
Alarms and events 82
Planning and designing your alarm system 83
Honeywell products that support effective alarm strategies 84
Factors that contribute to excessive alarms 85
Dealing with excessive alarms 85
Dynamic Alarm Suppression 88
Planning and application guidelines for Dynamic Alarm Suppression 89
Alarm and alert shelving 90
What happens when a shelved alarm is suppressed? 91
Alarm prioritization 92
Alarm annunciation 94
Station-based buzzer or speaker 94
External horn or siren 95
Honeywell 2017 5
Contents
Alarm groups 95
Alarm trackers 95
Alerts 96
Messages 97
Events 98
Displays 99
System displays 99
Tabbed displays 99
Custom displays 100
Custom display features and considerations 101
Custom faceplates 101
Display scripts 102
Display design 103
Display security 103
Acronyms 103
Web pages and other documents 104
Displays with linked documents 104
Reports 105
Standard report types 105
Integrated Microsoft Excel reports 107
Free Format reports 107
Output options 108
Specialized features 109
Recipes 109
Point requirements in recipes 109
Point control schedules 110
Honeywell Digital Video Manager 110
Exchanging data with other applications 112
Microsoft Excel Data Exchange 112
ODBC Data Exchange 113
OPC 113
Experion OPC Client Interface 113
Experion OPC Advanced Client 113
Experion OPC Display Data Client 115
Honeywell 2017 6
Contents
Experion OPC Server 115
Experion OPC Historical Data Access Server 116
Experion OPC Alarm and Event Server 116
Experion OPC Integrator 117
Creating custom applications 121
Installation and commissioning tasks 122
Installation and configuration tasks 122
Configuration tools 124
Configuration Studio 124
Enterprise Model Builder 124
Alarm Suppression display 124
Quick Builder 125
Control Builder 125
System displays 125
HMIWeb Display Builder 125
Experion server utilities 126
Station 127
Special-purpose utilities 127
Notices 128
Honeywell 2017 7
About this guide
About this guide
This guide contains high-level planning and design topics for Experion servers and clients, as
well as for controllers other than Process Controllers.
Revision history
Revision Date Description
A April 2017 Initial release of document.
Related documents
The following documents complement this guide. You should read them before you start
detailed planning and design tasks.
Document Description
Network and
Security
Planning Guide
Control
Hardware
Planning Guide
Overview
Software
Change Notice
(SCN)
Contains networking, security, and systems integration information applicable
to Experion.
Contains planning and design topics applicable to Process Controllers.
Provides a comprehensive overview of Experion, including basic concepts and
terminology.
Contains last-minute information that was not able to be included in the
standard documents. It may include important details that could affect your
planning or design decisions.
Honeywell 2017 8
Enterprise models
Enterprise models
The section provides an introduction to enterprise models. Enterprise models provide
structure to support:
This section also includes guidelines for designing enterprise models, as well as examples that
illustrate 'best practice' design principles.
About enterprise models
An enterprise model provides a means of organizing your system around key entities in your
enterprise, such as plant equipment.
An enterprise model provides:
n
Organizing your system.
n
Structuring your view of alarms.
n
Defining the scope of user views and control rights.
n
A hierarchical structure that makes it easier for users to navigate their way through your
system.
n
A simple and intuitive means of implementing scope of responsibility—that is,
systematically managing the access rights of operators (or Stations) to various parts of
your system.
n
The mechanism to enable and disable alarming for selected equipment.
An enterprise model is a framework that includes a set of specialized models, such as the asset
and system models, each of which represents one aspect of your system.
About asset models
An asset model forms the core of an enterprise model: it is a hierarchical representation of
your assets, similar to the one shown in the figure below.
An asset represents a particular physical item, such as a piece of plant equipment, a
production line or a building.
Honeywell 2017 9
Raw Materials *
Ball Mill
Rod Mill
Digestion *
Train 1
Digestor
Flash Vessel 1
Flash Vessel 2
Train 2
Precipitation *
Thickeners *
Thickener 1
Thickener 2
Train 1
Precipitator 1
Agitator
Cyclone
Train 2
Precipitator 2
Enterprise models
A typical asset model
About assignable assets and scope of responsibility
An asset model is not just a logical representation of your physical assets and how they relate
to each other. It also provides a framework for defining scope of responsibility (SOR)—that
is, assigning specific assets to specific operators (or Stations).
An asset that you can assign to an operator (or Station) is called an assignableasset. By
default, all top level assets in your asset model are assignable assets. If appropriate, you can
also define assets at other levels as assignable assets.
When you give an operator (or Station) access to an assignable asset, you also give access to
its child assets (except those which have been defined as assignable assets).
If an asset is changed from non-assignable to assignable, any scope of responsibility that was
previously inherited is cleared. As a result, control of this asset is temporarily lost until the
asset is included in the operator's or Station's scope of responsibility.
Honeywell 2017 10
Enterprise models
By assigning assets to operators, you not only restrict what assets they can control, you also
restrict what they see. For example, if an operator calls up the Alarm Summary it will only
display alarms related to assets that have been assigned to that operator. The associated asset
on system components can also be used to control which system alarms are displayed to
operators, based on their SOR.
Attention:
Scope of responsibility does not apply to point data on custom displays. If you
want to limit the visibility and use of point data on custom displays, you should
assign an appropriate security level to the point or the display during configuration
of the custom display.
About system models
A system model represents the Experion-related aspects of your system, namely:
n
Experion server(s).
n
Stations, channels, controllers, system interfaces and printers that are associated with
those servers.
n
If appropriate, servers that are connected to, but not part of, your Experion system (for
example, servers on your business network).
After you have configured your system and all its components, you can see a graphical
representation of your system model in the System Status display.
You can also create a dashboard hierarchy for the System Status display to provide graphical
information about the status of your system and network components in a way that allows
relationships and criticality to be represented. For more information, see “About dashboard
displays” in the HMIWeb Display Building Guide.
Honeywell 2017 11
Enterprise models
A typical system model, as shown in the System Status display
About generic displays
If you have many identical assets, such as a series of holding tanks, you can use one generic
display to show information about each tank. (Generic displays work in a similar manner to
point detail displays—that is, when you call up a generic display, you need to specify the
asset whose details you want to view.) For information on generic displays, see the HMIWeb
Display Building Guide.
Note that, in order to make use of generic displays, you must develop a systematic naming
convention.
For example, you might have the following asset model:
\assets\precipitation\train1\precipitator1
\assets\precipitation\train1\precipitator2
Each precipitator might have 2 points (whose tag names are VLV001 and
VLV002 respectively). For a generic display, you would use the same item
name for the points (for example, Valve):
\assets\precipitation\train1\precipitator1\Valve
\assets\precipitation\train1\precipitator2\Valve
You can then create a generic display that references Valve.
Honeywell 2017 12
Enterprise models
Guidelines for designing enterprise models
The following topics contain guidelines for designing enterprise models.
Guidelines for designing asset models
This topic provides guidelines for designing an asset model.
Ensure that your asset model reflects reality
Ensure that your asset model reflects the logical and physical design or structure of your plant.
For example, if your site consists of two distinct plants (say, Plant North and Plant South),
each with their own control room, then you would define Plant North and Plant South as
your top-level assets.
When you call up the generic display by referencing
n
assets\precipitation\train1\precipitator1, you will see data for VLV001.
When you call up the generic display by referencing
n
assets\precipitation\train1\precipitator2, you will see data for VLV002.
Keep your asset model as simple as possible
Keep your asset model as simple as possible, and with as few levels as possible. In particular:
n
Only define an item as an asset if you want to be able to use it for filtering or
navigational purposes.
For example, define as assets any items that you want to include in LocationPane of
the Alarm Summary, so that users can easily navigate (or filter) alarms. Similarly,
define as assets any items that will help users navigate (or filter) report data.
n
Use as few levels as possible—avoid using more than five.
Although you can have up to 10 levels, the deeper and more complicated your model,
the more cumbersome and therefore less useful, your model will be—in terms of both
operation and maintenance.
Bear in mind the following constraints
n
An asset model cannot include more than the maximum number of assets, which is
documented in the Experion Specification.
n
Assets (like points) constitute 'tags' in an Experion system, and therefore count towards
the total number of tags (or points) on a server. Note, however, that assets do not count
towards the server's licensed point count.
Honeywell 2017 13
Enterprise models
Details of a server's point counts are available on the Server License Details display (see the
topic titled "Checking your Experion license" in the "Configuration overview" section of the
Station Configuration Guide).
Develop a systematic and user-friendly naming convention for your assets
You need to develop a systematic and user-friendly naming convention, which complies with
the naming rules for assets. A well-designed naming convention makes it much easier for
operators to navigate their way through your system, and to respond to alarms.
A systematic naming convention is also essential if you want to make use of generic
displays—for example, use the same display for every holding tank in your plant.
Define appropriate assets as assignable assets
An assignable asset is one that can be assigned to an operator or Station for the purposes of
scope of responsibility.
As a general rule, we recommend that you restrict assignable assets to the two top levels of
your asset model. (By default, assets at the top level are assignable.)
If you make a lower level asset assignable, you should, for the sake of simplicity, also make
all its ancestors assignable. Otherwise, it may be harder to understand the behavior of the
assignment displays.
An asset model must not include more than the maximum number of assignable assets, which
is documented in the Experion Specification.
You should only change an asset from assignable to non-assignable (or from non-assignable
to assignable) before you engineer your data points. If you make such a change after you
have engineered your data points, you will need to reconfigure your scope of responsibility
displays.
Guidelines for defining scope of responsibility
It is essential that you define scope of responsibility (SOR) so that operators can access those
parts of the system for which they are responsible.
Experion system security comprises oth:
n Windows operating system security
n Station security: Station-based or operator-based
System security enables you to control who has access to the system and to control what users
can do within the system when access is granted.
Honeywell 2017 14
Enterprise models
Attention
Logging on to Windows does not necessarily grant permission for access to an
Experion application, such as Station. You therefore need to configure user access
to Experion separately to configuring Windows user accounts.
When configuring security for your site you need to consider:
n What type of Station security you want to use.
Do you want to use Station-based or operator-based security?
n What access operators require within Experion.
You may want to restrict operators from controlling certain parts of the system.
n If you choose operator-based Station security, what type of operator accounts do you
want to use:
l Traditional operator accounts
l Integrated accounts using either domain Windows accounts or local Windows
accounts
l Windows group accounts using either domain Windows groups or local Windows
groups
n Whether you want to use Signon Manager.
If Signon Manager is to be used, you need to choose operator-based security with
integrated accounts.
n How you implement Windows security.
n What type of Windows accounts you require.
Profiles
You define Scope of Responsibility (SOR) by creating profiles. Profiles provide a convenient
means of managing access to the system.
If you have chosen to use Operator-based security then a profile can be assigned to each
operator account. This assignment is configured by a user with sufficient security level (see
“Adding an operator account”).
If you have chosen to use Station-based security then a profile can be assigned to each station
by a user with Mngr access or, optionally, by the operator currently using the station.
Honeywell 2017 15
Enterprise models
Each profile specifies:
n The assets that can be accessed by the operator or station assigned to it.
n The times during which those assets can be accessed.
For more information about configuring scope of responsibility, see the topic "Configuring
system security" in the Station Configuration Guide.
Honeywell 2017 16
Enterprise models
Naming rules for assets
Each asset has three names:
n
A tag name (also called a point ID or point name). A unique name, which is used by
the system to identify the asset. The tag name must be unique across the DSA system.
n
An item name. A descriptive (user friendly) name for the asset. Unlike the point name,
the item name only has to be unique with respect to its siblings (other items that share
the same parent item).
For example, you can give many assets the item name of 'Mainvalve' provided each
asset has a different parent.
n
A full item name (also called an enterprise model name). A unique name, which
consists of the tag name and the names of all its ancestors within the asset model.
A full item name has the same structure as the full path name of a file on a network.
The following example is the full item name of an asset named ‘Agitator’:
/Assets/Precipitation/Train1/Precipitator1/Agitator
Asset names must follow certain naming rules:
n
Tag names must be unique.
n
Tag names and item names can contain up to 40 single-byte or 20 double-byte
alphanumeric characters, with at least one alpha character.
n
Tag names and item names are not case-sensitive: Cooling Tower1 and cooling tower1
represent the same asset.
n
The first character of a tag name and an item must not be any of the following
characters:
l
At sign (@)
l
Dollar sign ($)
l
Space
n
Tag names and item names cannot contain any of the following characters:
l
Asterisk (*)
l
Backslash (\)
l
Braces {} (rule applies to item names only)
l
Brackets []
Honeywell 2017 17
Enterprise models
l
Caret (^)
l
Colon (:)
l
Comma (,)
l
Double quote (")
l
Equals (=)
l
Forward slash (/)
l
Greater than (>)
l
Less than (<)
l
Parentheses ()
l
Period (.)
l
Question mark (?)
l
Semi colon (;)
l
Single quote (')
l
Space (rule applies to tag names only)
l
Tabs
l
Vertical bar (|)
n
The last character of a tag name and an item must not be a space.
n
A full item name:
l
Must not be longer than 200 characters
l
Must be unique
Guidelines for determining the optimal topology for your plant
This section provides guidelines for determining the optimal topology for your plant.
Keep your topology as simple as possible
As a general rule, we strongly recommend that you keep your topology as simple as
possible—the more complicated your topology, the harder it will be to efficiently engineer,
maintain and operate your plant.
Honeywell 2017 18
Enterprise models
Obviously, the simplest topology is a single-system topology that contains every server (and
clusters of servers) in your plant.
Determine you security and business needs
When choosing your topology, you also have to take into account your security and business
needs. For example, if your system also includes level3 and level4 applications, or a firewall,
the optimal topology will be significantly different from a system that does not include such
items.
For more information, see the Network and Security Planning Guide.
Example enterprise models and topologies
The following topics contain example models and topologies that illustrate 'best practice'
design principles.
An asset model for a simple system
Scenario
Your plant includes milling, digestion and precipitation processes.
You want an asset model that accurately represents the three processes, identifies the main
plant items, and allows you to assign operators to specific processes.
In the case of the precipitation process, which requires more operator skill, you want to be
able to separately assign the thickener equipment to specific operators.
Solution
You design the asset model shown in the following figure.
An asterisk next to an asset indicates that it is assignable. Because RawMaterials, Digestion
and Precipitation are top level assets, they are assignable by default. Because, you want to
be able to assign the thickeners to specific operators, you also make Thickeners assignable.
With this design, you can assign either or both Precipitation and Thickeners to operators, as
appropriate. For example, if you only assign Precipitation to an operator, that operator will
have access to all assets below it, except for the Thickeners branch.
Honeywell 2017 19
Raw Materials *
Ball Mill
Rod Mill
Digestion *
Train 1
Digestor
Flash Vessel 1
Flash Vessel 2
Train 2
Precipitation *
Thickeners *
Thickener 1
Thickener 2
Train 1
Precipitator 1
Agitator
Cyclone
Train 2
Precipitator 2
Enterprise models
The asset model for a simple system
Implementing an enterprise model
The following table summarizes the major steps involved in implementing an enterprise
model.
Task Done
Familiarize yourself with the concepts, guidelines and examples included in this section.
In the case of networking and security, you also need to read the Network and Security
Planning Guide.
Define your system name using Enterprise Model Builder.
See the Enterprise Model Builder User's Guide.
Honeywell 2017 20
Enterprise models
Task Done
Define your servers using Enterprise Model Builder.
See the Enterprise Model Builder User's Guide.
Define your asset model using Enterprise Model Builder.
See the Enterprise Model Builder User's Guide.
Define your points, Stations, channels, controllers and printers using the appropriate tool
(Quick Builder or Control Builder).
When building each point, ensure that you specify the parent asset.
See the Quick Builder Guide or Control Building Guide.
Build your network model.
See the “The Network tree” section of the Station Configuration Guide.
If you use Station-based security, assign assets to Stations.
See the “Configuring system security” section of the Station Configuration Guide.
If you use operator-based security, define profiles, and then assign profiles to operators.
See the “Configuring profiles for scope of responsibility” topic in the “Configuring system
security” section of the Station Configuration Guide.
Assign assets to reports.
See the “Reports” section of the Station Configuration Guide.
If appropriate, define alarm groups and system alarm groups using Enterprise Model
Builder.
See the Enterprise Model Builder User's Guide.
If appropriate, create generic displays.
See the “About generic displays” topic in the “About display types” section of the
HMIWeb Display Building Guide.
Honeywell 2017 21
Servers
Servers
This section describes how to determine your server requirements.
Issue Comments
Redundancy Decide whether you need server redundancy.
Distributed
system
eServer
PHD
Server scripts Decide whether you can use server scripts to perform specialized tasks.
Server names Define the server name(s).
Decide whether you need a distributed system.
Decide whether you want an eServer, which gives casual users read-only access
to displays and reports.
Decide whether you want an integrated PHD server, and whether you want PHD
to store long-term history.
Server redundancy
You can improve system availability with server redundancy.
In a redundant server system, Experion is installed on both servers, which are identically
configured and connected through an Ethernet network.
Experion uses software arbitration to determine which server acts as primary. With software
arbitration, each server polls the other through the LAN to determine whether the other server
has failed.
Attention:
Not all Experion components use the arbitration approach. The Enterprise Model
Database (EMDB) and Engineering Repository Database (ERDB) are located on
the preferred backup (missing or bad snippet) server. If the preferred backup
Experion server is not available, the system is considered in a degraded state and
no changes are allowed to be made to either database.
Honeywell 2017 22
Servers
Typical redundant server system
About Backup Control Center (BCC)
Backup Control Center (BCC) is a licensed option of Experion that supports business
continuity. BCC allows more than one pair of redundant servers to be configured, with each
pair of servers associated with a server location. Each server location is identified by a
number and this number is used when specifying server host names to identify which server
location the server is associated with. For more information and examples, see “Naming rules
for computers.” Server location names can also incorporate a more descriptive name for clear
identification.
The location that includes the server currently acting as the primary server is considered the
active server location. The other server location is considered the backup server location.
In the figure below, if Server1B is acting as the primary server, Server Location 1 will be the
active server location and Server Location 0 will be the backup server location. Additionally,
Server1A, Server0A, and Server0B would be considered secondary (backup) servers.
Honeywell 2017 23
Servers
Typical BCC system
Planning constraints for BCC
BCC requires a minimum bandwidth of 10 Mbps between server locations that is dedicated to
the server redundancy function. For information about capacity and topology constraints, see
the Experion HMI Specification.
Special considerations for BCC
In a system with BCC, there is only one primary server. When an OPC client needs to
connect to the system, it must connect to the OPC server running on the primary server.
Connecting to the OPC server on the backup server will result only in errors being returned.
For OPC clients that are unable to resolve the connection to the primary server themselves,
Redirection Manager (RDM) may be used to automatically maintain the connection to the
primary server in a non-BCC redundant system. RDM does not provide resolution of the
primary server for a BCC system. If the OPC client is only required to connect within a server
location, then RDM may still be used. If an OPC client is required to connect across server
locations, please contact the Honeywell Technical Assistance Center (TAC) for advice with
this configuration.
If the communications architecture requires different terminal servers in each server location,
then the port properties configured on the Experion channel should be configured with a host
name. The hosts file on each server can then be configured so that the host name is resolved
to the IP address of the terminal server in the local server location.
Note that a direct TCP connected controller can also have similar IP resolution where the host
name is matched to the name given to the controller in Experion. This may be useful if the
Honeywell 2017 24
Site B
Site A
Site C
WAN
Master Control Center
Servers
network requires different IP addresses for communication to RTUs or controllers from
different server locations. For more information, see the description of the controller’s Name
property in the respective interface reference guide.
Distributed System Architecture
Distributed System Architecture (DSA) is an option that enables multiple Experion server
systems to share data, alarms, alerts, messages, events, and history without the need for
duplicate configuration on any server.
DSA is appropriate for:
n
Large-scale plant-wide systems in which the servers are connected through a highspeed LAN
n
Geographically-distributed systems in which the servers are connected through a WAN
(DSA has been designed to minimize network traffic, and supports WANs with speeds
as low as 64 Kbps.)
Typical geographically distributed system
For more information about DSA, see 'Configuring Distributed System Architecture' in the
Station Configuration Guide.
Inter-release support
DSA interoperability works between the current release and previous releases of Experion.
For example, you can have a DSA system in which some servers are running the current
release while others are running the previous (or an even earlier) release of Experion.
Please consult the Experion LX Software Change Notice for specific details about which
releases are supported.
Honeywell 2017 25
Servers
DSA and firewalls
If there is a firewall in your DSA system other than the default Windows Firewall, you will
need to ensure that the necessary ports are opened in the firewall to enable DSA
communications between the DSA client and server nodes.
For information on DSA communication through a firewall and Windows security
enhancements, see the Network and Security Planning Guide.
About point data in a DSA system
DSA provides global access to point parameter data on all servers in the system. Each server
provides automatic dynamic caching of remote data for all of its clients, so that clients access
their local server for all data. In general, clients do not access remote servers directly.
However, some process data is accessed directly; for example, chart visualization via a
Process Detail display.
DSA data access works as follows:
1.
When one of its clients requests data for a point that is not already in the local server's
database, the local server asks the servers in the system for the data owner of the point.
2.
When the data owner is determined, the local server subscribes to the remote server
from which it obtained the data and automatically creates a cache reference (known as
a 'local cache point') in the local database.
3.
While the subscription is in effect the data owner uses 'report by exception', only
sending data to the caching server when there is a change. When the data is no longer
referenced by any of its client Stations or applications, the subscribing server cancels
the subscription to the data owner. This subscription mechanism ensures maximum
efficiency both on the servers and over the network.
How DSA affects your total point count
The cached points created by DSA do not count against the licensed point count for a given
server. They do, however, count towards the total maximum number of points per server.
Note that you can reduce the number of DSA points on a server by disabling DSA
subscription to the system model and system alarms on a remote server. This setting is useful
if you are approaching the maximum number of points on a server in a DSA system. For
more information, see 'Configuring servers to subscribe to data and alarms' in the
'Configuring Distributed System Architecture' topic in the Station Configuration Guide.
You can check the current number of DSA points (and other types of unlicensed points) on
the Server License Details display. See 'Checking your Experion license' in the
'Configuration overview' topic in the Station Configuration Guide.
Honeywell 2017 26
Servers
DSA-specific rules and restrictions
The following rules apply where you have DSA-connected servers:
n
Every point that will be accessed from more than one server must be assigned to an
asset.
n
When creating a new point, it can have the same tag name (point ID) as a point on
another server, but it cannot have the same tag name as a point on the same server, or
the same tag name as any existing asset or alarm group within your Enterprise Model.
When creating a new asset or alarm group, it cannot have the same tag name as any
existing asset or alarm group within the same system connected via DSA, or the same
tag name as any existing points on any of the servers connected via DSA.
So, for example, you can have the tag name FIC123 on ServerNorth as well as on
ServerSouth because Experion will identify the first as
ExperionServerNorth:FIC123 and the other as ExperionServerSouth:FIC123,
thus making each tag name unique within the system. You cannot, however, have an
asset or alarm group called FIC123 because assets and alarm groups are downloaded
to every server in the system, and downloading an asset with the tag name FIC123
would conflict with the existing FIC123 points on ServerNorth and ServerSouth.
n
System tables (such as the message, acronym, and reason tables) that reference an item
by number must be identical on every server.
eServer
An eServer is a special Experion server that gives casual users read-only access to displays
and reports using a browser such as Microsoft Internet Explorer.
An eServer also simplifies administration because it consolidates the management, security
and licensing of casual user accounts.
An eServer provides two levels of access:
n
Premium.
Provides access to displays that are updated in the normal manner.
n
Standard.
Provides 'snapshots' of displays that are not updated. (To check for changes to data, the
user must request a new snapshot by using the browser's refresh function.)
An eServer license allows an unlimited number of standard access connections. Premium
access connections are purchased separately.
The eServer software must be loaded on a separate computer, not on one of the Experion
servers in your process control network.
Honeywell 2017 27
Servers
From a networking point of view, an eServer is a separate server in a DSA system, and
requires a DSA license for each server that it subscribes to.
For more information about eServers, see 'Configuring eServer' in the Station Configuration
Guide.
For information about the security aspects of eServer, see the Network and Security Planning
Guide.
PHD
Process Historian Database (PHD) collects, stores, and replays continuous and other historical
plant data. While PHD resides on a separate node from Experion servers, they can interact,
enabling PHD to store long-term history data. PHD provides a more compact storage
mechanism.
Honeywell 2017 28
Servers
Short-term history collection
When PHD is used, Experion should be configured to store around ten to thirty days of
history—depending on your business requirements. History beyond this time window can be
stored using PHD.
Long-term history collection
When long-term history collection is migrated to PHD, your analytical applications must draw
their data from PHD rather than Experion. Ensure that all key applications can effectively use
PHD history data sources prior to discarding the history in Experion.
Remote Engineering and Station Server
A Remote Engineering and Station Server is a computer that supports remote or mobile
access to Station and to the Experion configuration tool, Configuration Studio.
You can set up a Remote Engineering and Station Server to enable remote access to either
eServer Premium displays (Mobile Access for eServer Premium) or to full Station
functionality (Mobile Access for Station).
Honeywell 2017 29
Servers
Planning considerations
In planning for the number of Remote Engineering and Station Server nodes that you might
need for your site, you should bear in mind the following:
n
A Remote Engineering and Station Server can be configured to support either Mobile
Access for eServer Premium or Mobile Access for Station (but not both). That is, you
need to set up separate Remote Engineering and Station Servers for each type of
access.
A Remote Engineering and Station Server that provides Mobile Access for Station can,
however, also be used to provide remote access to Configuration Studio.
n
The maximum number of concurrent remote access sessions that a Remote Engineering
and Station Server supports is 5.
Attention:
n
Within this maximum number of 5 concurrent sessions you can have a
maximum of 5 concurrent connections to Station or 4 concurrent
connections to Configuration Studio (or a mix of both types of connections
provided that you do not exceed the individual limits for each type of
connection). Note, however, that you cannot run both Station and
Configuration Studio within the one session.
n
Although you can run 4 concurrent connections to Configuration Studio,
only one of those connections can run the Quick Builder component of
Configuration Studio at any one time.
n
Because access to Station is provided within Configuration Studio as one of
the configuration tools, a remote device connecting to Configuration Studio
does not need a separate connection to Station.
For information on installing and configuring a Remote Engineering and Station Server, see
'Installing Remote Engineering and Station Server' in the Supplementary Installation Tasks
Guide and 'Configuring Remote Engineering and Station Server' in the Station Configuration
Guide
Server scripts
You can add extra functionality to your system with server scripts. A server script runs when
its associated event occurs—for example, when:
n
A point changes state
n
An operator acknowledges an alarm
Honeywell 2017 30
Loading...