Honeywell Experion LX User 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 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
Contents
Honeywell 2017 3

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
Contents
Honeywell 2017 4

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
Contents
Honeywell 2017 5

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
Contents
Honeywell 2017 6

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
Contents
Honeywell 2017 7

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
Contains networking, security, and systems integration information applicable
to Experion.
Control
Hardware
Planning Guide
Contains planning and design topics applicable to Process Controllers.
Overview Provides a comprehensive overview of Experion, including basic concepts and
terminology.
Software
Change Notice
(SCN)
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.
About this guide
Honeywell 2017 8

Enterprise models
The section provides an introduction to enterprise models. Enterprise models provide
structure to support:
nOrganizing your system.
nStructuring your view of alarms.
nDefining the scope of user views and control rights.
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:
nA hierarchical structure that makes it easier for users to navigate their way through your
system.
nA 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.
nThe 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.
Enterprise models
Honeywell 2017 9

A typical asset model
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
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 assignableasset. 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.
Enterprise models
Honeywell 2017 10

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
Asystem model represents the Experion-related aspects of your system, namely:
nExperion server(s).
nStations, channels, controllers, system interfaces and printers that are associated with
those servers.
nIf 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.
Enterprise models
Honeywell 2017 11

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.
Enterprise models
Honeywell 2017 12

nWhen you call up the generic display by referencing
assets\precipitation\train1\precipitator1, you will see data for VLV001.
nWhen you call up the generic display by referencing
assets\precipitation\train1\precipitator2, you will see data for VLV002.
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.
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:
nOnly 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 LocationPane 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.
nUse 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
nAn asset model cannot include more than the maximum number of assets, which is
documented in the Experion Specification.
nAssets (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.
Enterprise models
Honeywell 2017 13

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:
nWindows operating system security
nStation 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.
Enterprise models
Honeywell 2017 14

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:
nWhat type of Station security you want to use.
Do you want to use Station-based or operator-based security?
nWhat access operators require within Experion.
You may want to restrict operators from controlling certain parts of the system.
nIf you choose operator-based Station security, what type of operator accounts do you
want to use:
lTraditional operator accounts
lIntegrated accounts using either domain Windows accounts or local Windows
accounts
lWindows group accounts using either domain Windows groups or local Windows
groups
nWhether you want to use Signon Manager.
If Signon Manager is to be used, you need to choose operator-based security with
integrated accounts.
nHow you implement Windows security.
nWhat 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.
Enterprise models
Honeywell 2017 15

Each profile specifies:
nThe assets that can be accessed by the operator or station assigned to it.
nThe 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.
Enterprise models
Honeywell 2017 16

Naming rules for assets
Each asset has three names:
nAtag 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.
nAn 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.
nAfull 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:
nTag names must be unique.
nTag names and item names can contain up to 40 single-byte or 20 double-byte
alphanumeric characters, with at least one alpha character.
nTag names and item names are not case-sensitive: Cooling Tower1 and cooling tower1
represent the same asset.
nThe first character of a tag name and an item must not be any of the following
characters:
lAt sign (@)
lDollar sign ($)
lSpace
nTag names and item names cannot contain any of the following characters:
lAsterisk (*)
lBackslash (\)
lBraces {} (rule applies to item names only)
lBrackets []
Enterprise models
Honeywell 2017 17

lCaret (^)
lColon (:)
lComma (,)
lDouble quote (")
lEquals (=)
lForward slash (/)
lGreater than (>)
lLess than (<)
lParentheses ()
lPeriod (.)
lQuestion mark (?)
lSemi colon (;)
lSingle quote (')
lSpace (rule applies to tag names only)
lTabs
lVertical bar (|)
nThe last character of a tag name and an item must not be a space.
nAfull item name:
lMust not be longer than 200 characters
lMust 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.
Enterprise models
Honeywell 2017 18

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 level3 and level4 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 RawMaterials,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.
Enterprise models
Honeywell 2017 19

The asset model for a simple system
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
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.
Enterprise models
Honeywell 2017 20