Page 1
Experion LX
Station Planning Guide
EXDOC-X128-en-500A
April 2017
Release 500
Page 2
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
Page 3
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
Page 4
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
Page 5
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
Page 6
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
Page 7
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
Page 8
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
Page 9
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
Page 10
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
Page 11
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
Page 12
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
Page 13
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
Page 14
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
Page 15
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
Page 16
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
Page 17
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
Page 18
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
Page 19
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
Page 20
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
Page 21
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
Page 22
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
Page 23
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
Page 24
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
Page 25
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
Page 26
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
Page 27
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
Page 28
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
Page 29
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
Page 30
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
Page 31
Servers
n
The server starts
n
A report is generated
Server scripts can also include:
n
Periodic scripts, which run at specified intervals while the server is running
n
Library scripts, which perform specialized functions when called by other server scripts
Server scripts don't block point processing, and don't impact other server functions because
they run at a low priority.
Note that server scripting has been optimized for relatively short scripts (less than 30 lines),
and is not designed for implementing control strategies (which should be done in the
controller). If a task is computationally intensive, or requires extensive file handling, you
should write a custom application in Visual C/C++ or Visual Basic.
For more information about server scripts, see the Server Scripting Reference.
Naming rules for computers
Every Experion node (for example, Experion server, Console Station, and Flex Station
computers) must have a unique name and IP address. The unique name must comply with the
following rules:
n
The length of the node name must comply with the table below.
n
The name must begin with an alphabetic character, such as a to z, or A to Z.
n
The name must not contain spaces or other non-standard characters.
n
The names of redundant server pairs must consist of a common base name (which must
also follow the other naming restrictions), plus an A suffix for the primary server and a
B suffix for the backup server.
For example, if the base name of the redundant servers is HSSERV:
l
The name of the primary server is HSSERVA.
l
The name of the backup server name is HSSERVB.
n
The base name must not end with ‘A’or ‘B’. (The use of A and B as the last letter in a
name is reserved for naming redundant servers.)
n
To avoid potential confusion, the node name should not end with a ‘0’ or ‘1’, as these
numbers are used in hosts files to identify redundant links.
Honeywell 2017 31
Page 32
Servers
Maximum length of a node’s base name for single Ethernet or FTE networks
Node type FTE
15 characters
Flex Station, Console Station, Collaboration Station
Example host name: HSCSTN
14 characters
Redundant Experion server
Example host name: HSCSVRA
13 characters
BCC redundant Experion server
Example host name: HSCSVR1A
15 characters
Non-redundant Experion server
Example host name: HSCSVR
Maximum length of a node’s base name for Dual Ethernet networks
Node type Dual Ethernet
14 characters
Flex Station, Console Station, Collaboration Station
Example host name: HSCSTN1
13 characters
Redundant Experion server
Example host name: HSCSVRA0
12 characters
BCC redundant Experion server
Example host name: HSCSVR1A0
1
2
3
4
5
14 characters
6
Non-redundant Experion server
Example host name: HSCSVR0
1
The next character is reserved for A/B redundant server suffix.
2
The next two characters are reserved for the server location number and the A/B redundant server
suffix.
3
The next character is reserved for 0/1 redundant link suffix.
4
The next two characters are reserved for A/B redundant server suffix and the 0/1 redundant link
suffix.
5
The next three characters are reserved for the server location number, A/B redundant server
suffix, and the 0/1 redundant link suffix.
6
The next character is reserved for 0/1 redundant link suffix.
Honeywell 2017 32
Page 33
Servers
Servers and the Enterprise Model Database
The Experion Enterprise Model Database (EMDB) comprises the engineering definitions of
your system components, assets, and alarm groups.
EMDBs are created as part of an Experion installation procedure, which requires that you
identify the node(s) on which you want to install the EMDB. You therefore need to consider
the following questions before installing Experion:
n
On which server (or redundant server pair) should the EMDB reside?
n
Do you require more than one EMDB per system?
Attention:
n
If you choose to install the EMDB on a redundant server pair, you must
install the EMDB on both server A and server B.
n
Although it is possible to have multiple EMDBs, it is recommended that
you only have one EMDB in an Experion system.
ESM Server
The ESM server maintains the node configuration details that are used by the Installation
Builder and Diagnostic Studio.
You can have only one ESM Server in a system, and the ESM Server must be located on a
server-grade computer. During the installation of Experion nodes, you can choose to install
the ESM Server on an Experion node, or you can install an ESM Server on a non-Experion
node from the ESM application media.
Honeywell 2017 33
Page 34
Networks
Networks
This section provides high-level information on networking issues.
Network planning issues for an Experion process control network are also described in the
following documents:
n
Overviewdescribes the basic concepts and terminology as well as the capabilities of an
Experion process control network.
n
Fault Tolerant Ethernet Overview and Implementation Guide includes information
about configuring a system that conforms to Honeywell's High Security Network
architecture. It contains information about network equipment specifications,
configuration, IP addressing, and network topologies.
Network planning considerations
In planning your Experion network, your considerations should include the following issues.
Issue Comments
Select the most appropriate structure.
Domains or workgroups
For more information, see the Network and Security Planning Guide.
Select the most appropriate network topology.
Network topologies
For more information, see the Network and Security Planning Guide.
Determine your network security requirements.
Network security
For more information, see the Network and Security Planning Guide.
Determine your Experion security requirements and decide what type
Experion security
features
Network redundancy Decide whether you need redundant networks.
Process Controllers Determine the networking requirements of your Process Controllers.
Controllers other than
Process Controllers
of security you need to implement.
For more information, see the Network and Security Planning Guide.
If you have controllers other than Process Controllers, determine how
you are going to connect them to the network.
Honeywell 2017 34
Page 35
Networks
Network redundancy
Fault Tolerant Ethernet (FTE)
Honeywell's Fault Tolerant Ethernet (FTE) provides redundancy and a highly available
networking scheme using commercial network interface cards (NIC) and standard Ethernet
hardware (switches).
For more information about FTE, see the Fault Tolerant Ethernet Overview and
Implementation Guide.
Process controllers
Experion supports supervisory level communications over Honeywell's Fault Tolerant
Ethernet (FTE) network.
There are two different types of supervisory communication:
n At level 3 there is the supervisory communication between the server and client.
n At level 2 there is the downstream supervisory connection to the controllers on the
Experion Process Network (EPN).
For more information about the networking security, see the “Network security” chapter of
the Network and Security Planning Guide.
Honeywell 2017 35
Page 36
Time synchronization
Time synchronization
The following topics are important for understanding and planning the time synchronization
requirements of your Experion LX system.
Experion time requirements
Reliable and coordinated time is an important element in an Experion system. It is used in
many aspects of the system including:
n
n
n
Supported time protocols
When deploying a topology, the time protocols supported should be considered.
control functions
redundancy options
intersystem communications of supervisory systems
PTP
client
1
CDA
server
SNTP
server
NTP
server
PTP server
Device
CDA
client
SNTP
client
NTP
client
C300 X X X
PGM X X X
Wireless Device
Manager
X X
2
PMD X X
3
RTU
Moxa switch (IEC
61850 compliant)
1
PTP IEEE-1588 version 1 and PTP IEEE-1588 version 2 are supported for Safety Manager devices.
For all other devices, only PTP IEEE-1588 version 2 is supported.
2
Limited to servicing Field Device Network(FDN) only
X
X X X X
XExperion time
4
requirements above
3
Also supports DNP3 for time synchronization
4
Limited to IEC 61850 networks only
Honeywell 2017 36
Page 37
IED
W /PTP
Secondary NTP Server / NTP
Client
Bay Level
Process Level
Level 0
Level 1
Level 2 Station Level
Level 3
Ethernet with PTP -1588 v2
Ethernet with NTP
GPS
WDM
W /NTP
L2 Domain Controller
EPKS Server & clients
L3 Forest Root
Domain Controller
Stratum 1
Stratum 2
Level 2.5
L2 .5 Router
NTP Master clock
850 M
W /SNTP
C300 /
FIM /PGM
W /SNTP
Stratum 2
850 M
W /PTP
C300
W /PTP
IEC 61850 Switch
L3 Router
Stratum 3
IEDS
W / NTP
L2 FTE switch
Primary NTP
Server
Stratum 2
Stratum 2
Primary NTP Master
Clock
Primary PTP Master
Clock
Backup NTP Master Clock /Backup PTP
Master Clock
Backup PTP Master
Clock
PTP -IEEE 1588 version 2
Grand Master Clock
Stratum 4
C200
W /CDA
Ethernet with CDA
SM
W /NTP
SM
W /PTP
RTU
W /SNTP
IO
W /PTP
IO
W /NTP
Time synchronization
PTP
client
1
CDA
server
SNTP
server
NTP
server
Device
CDA
client
SNTP
client
NTP
client
Windows client X X
Windows server
Windows domain
controller
2
X X
X X
3
X
Typical time distribution topology that is supported by Experion connected devices.
PTP server
1
PTP IEEE-1588 version 1 and PTP IEEE-1588 version 2 are supported for Safety Manager devices.
Honeywell 2017 37
For all other devices, only PTP IEEE-1588 version 2 is supported.
2
Including ESXi hosts
3
With Experion LX Server install
Page 38
Time synchronization
Time synchronization in workgroups and Windows domains
By default, workgroups synchronize once a week and Windows domains synchronize during
logon or authentication, or once every 8 hours or so if not logged in. Within a Windows
domain, computers auto-configure themselves for time distribution.
For more information, see http://technet.microsoft.com/en-us/library/cc749145(WS.10).aspx.
The default time synchronization mechanisms for workgroups and Windows domains do not
meet control system specifications, which require localized, high-quality time
synchronization.
Level 1 network
The C300 Controller, FIM8, PGM, IEC 61850 Interface Module, and Safety Manager
require high-quality time served from a Network Time Protocol (NTP) or Simple Network
Time Protocol (SNTP) Server.
The quality of time determines how tightly events from different devices can be correlated,
especially with regard to digital Sequence of Events (DI SOE). For DI SOE, therefore, it is
recommended that you use a high quality external time source such as an IEEE-1588
(Precision Time Protocol)-based time server.
The most stringent requirement for time synchronization at level 1 is from controllers that
need high-resolution, digital sequence of events. An example of this requirement is in the
electric utilities where thousands of digital input points are monitored. Each state change is
time stamped to a minimum resolution of 1 ms. These state changes are logged. After certain
faults, such as a generator going offline, the log is frozen for later analysis to see which
condition led to the fault. Examples are turbine imbalance, drop in frequency of the grid,
circuit breaker trips, and so on. Critical physical and electrical events follow each other over a
short period of time and the log is used to identify which event happened first and caused the
rest. Typically the cause is used to back-charge the responsible party.
Level 2 network
At level 2, time is a gating factor used in many supervisory functions such as:
n
redundancy
n
event processing
n
system monitoring
Time stamping is also used in diagnostic messages. For example, Safety Manager notifies
Experion of all abnormal changes in system behavior by means of time-stamped diagnostic
messages.
Honeywell 2017 38
Page 39
Time synchronization
Summary
Both levels provide important and critical functions to an overall system that is being used to
control a plant's processes. System events can be generated from either the hardware side
(level 1) or from the supervisory side (level 2). Therefore, time synchronization between the
two network levels also needs to be coordinated, ideally, using the same source. This
mitigates against messages and events being mishandled, regardless of where they are sourced
from.
About time protocols
Simple Network Time Protocol (SNTP) is a proper subset of Network Time Protocol (NTP),
which uses the same packet format. As a subset, SNTP gets time from an NTP server, but
does not run complex filtering and control algorithms to extract the best time from multiple
sources and precisely set the local clock increment rate. SNTP only measures round-trip-delay
and sets the local clock when it drifts beyond internal limits.
Time protocols and Microsoft Windows
All supported Microsoft Windows operating systems use NTP. Each domain controller in a
Windows Server 2003 or 2008 domain, by default, is an NTP server. The Active Directory
provides a hierarchical time infrastructure. Each system added into the Active
Directory/domain synchronizes time with a time source in the domains hierarchy.
About setting up time synchronization in your Experion LX control system
Because the default Windows NTP implementation is not set up for the tolerances needed for
control systems, Honeywell recommends that you use the NTPConfig tool to configure time
synchronization on your Windows nodes. The NTPConfig tool corrects the tolerance
deficiencies and converts the Active Directory default settings to be compatible with control
system requirements. To overcome the tolerances, parameters are updated to maintain more
stringent time synchronization.
If your control system is integrated with a Windows domain, it is recommended that you use
the domain controller as the time source for all the clients within the domain (this is the
default setting). As domain controllers are typically not on a network that is accessible to the
control system itself, the controllers within the process control should be configured to get
their time from an Experion server that has been set up as an NTP server acting as a
secondary NTP server, which gets its time from the domain controller.
Time protocols and time servers for Experion LX controllers
The C300 uses SNTP or PTP to attain the time, but includes its own proprietary ability to
adjust the clock increment rate to that of the time source so that fewer actual adjustments
(bumps) are necessary (similar to the functionality of NTP).
When plant-wide correlation of C300 DI-SOE is required, PTP must be provided.
Honeywell 2017 39
Page 40
Time synchronization
As a client, Safety Manager supports the NTP protocol but also supports the PTP time
protocol, which is used for synchronization over its own SafeNet network.
Precision time protocol (PTP)
The IEEE-1588 Precision Time Protocol provides high-precision time with low overhead.
Unlike NTP, it is only a Local Area Network protocol, requiring a local time server, known
as an IEEE-1588 Grandmaster. PTP supports multiple Grandmasters for availability.
Typically, Grandmasters get their reference time from GPS, but can also get time from other
GPS devices using one of the standard coaxial cable protocol connections. Multiple units
from the same manufacturer may even share a GPS antenna. PTP is a UDP Multicast
protocol, so it adds some network traffic.
Time source hierarchy
The Series 8 controllers and interfaces have a time source hierarchy. When the better time
source becomes unavailable, they degrade to a less-accurate source. From highest to lowest
precision:
n
PTP (if enabled)
n
SNTP
n
CDA Server Protocol
Time source configuration
SNTP is used when the IP addresses of one or two NTP servers are configured in Control
Builder System Preferences. SNTP Server 1 is tried first. If unavailable, SNTP Server 2 is
tried. PTP is used when individual devices are configured in Control Builder to use it. Once
enabled, PTP is self-configuring.
PTP Grandmaster configuration notes
PTP defines synchronization profiles for various applications. We use the default profile. The
basic settings are synchronization every two seconds, and using multicast for round-trip-time
determination.
Planning your time hierarchy
Implementing a time strategy that is appropriate for a process control system involves using a
time hierarchy where the root of the hierarchy is the most reliable time source.
Windows domains, by default, implement a hierarchy of time distribution across the domain.
The domain controller that is the PDC Emulator is the node that synchronizes with a reliable
external source.
Honeywell 2017 40
Page 41
Time synchronization
Ideally, all the control systems nodes are linked together in a hierarchy of time critical usage.
In most cases, it may be better to set up one or two secondary network time protocol (NTP)
servers that service all the control systems NTP clients on the local network. This provides
mitigation against requirements on the network being available to keep the time consistent and
attain accurate time.
Your organization may already have a time hierarchy in place that can be used as a source
from which you can then branch off for the control system. Regardless of the source of time,
all topologies should include local NTP servers that serve time in the control system.
Workgroup topology with no external source
In the following diagram, redundant Experion servers are set up as redundant NTP servers.
All time clients, such as Flex Stations, Console Stations, and C300 controllers, receive time
from the primary Experion server. If this server fails over, time is served by the backup
Experion server.
This topology uses the internal CMOS clock of the authoritative server as the time source.
This time source is not as accurate and will create deviations in time seen throughout the
hierarchy. Systems with strict requirements on sequence of events should not implement this
topology.
Workgroup topology with external source
In the following diagram, the primary Experion server receives time from an external source.
The redundant Experion servers are set up as NTP servers which serve time to all time clients,
such as Flex Stations, Console Stations, and Safety Manager. If the primary Experion server
fails over, time is served by the backup Experion server. An external source serves time to the
C300 controller.
Honeywell 2017 41
Page 42
Time synchronization
This topology creates a dependency on the network infrastructure between the control system
and the external source. The reliability of this network should be taken into consideration
when planning this time hierarchy.
If the network between the external sources is reliable or local, then direct access to the
external (or local) device is recommended. This means that you only need one secondary
server. This is highly recommended for SOE configurations.
Domain topology
In the following diagram, the domain controller receives time from an external source. The
domain controller serves time to the redundant Experion servers, Flex Stations, and Console
Stations. An external source serves time to the C300 controller.
You should verify that the Active Directory/domain you link to uses a reliable external time
source. If an external source is not used, the internal CMOS of the domain controller (or PDC
Emulator) is used as the time source. This time source is not as accurate and will create
deviations in time seen throughout the hierarchy. Systems with strict requirements on
sequence of events should not implement this topology.
Honeywell 2017 42
Page 43
Time synchronization
Planning considerations for time synchronization
n
Controllers and CEEs obtain the start and end of Daylight Saving Time (DST) from
Experion servers. For controllers and CEEs to automatically change to DST, the
Experion server's clock must be selected to automatically adjust clock for daylight
savings changes. DST changeover in the Experion server's clock triggers the
controllers and CEEs to change to DST, regardless of whether it’s done automatically
by the operating system or enabled manually by the user within the DST period.
n
For controllers, CEEs, and Experion servers in the same time zone, whenever DST
starts or ends, the controllers and CEEs clocks are adjusted either forward or backward
by 1 hour.
n
The start and end of DST is always identified from the Experion server. In the case
where controllers, CEEs, and Experion servers are not in the same time zone;
controllers and CEEs will shift by one hour (irrespective of any time zone the controller
or CEE is in and also irrespective of if DST is applicable for controller or CEE time
zone) at the start and end of DST (applicable as per server time zone).
n
For controllers and CEEs that are in different time zones to the Experion servers,
Honeywell recommends not to use Automatically Apply DST option and to manually
Honeywell 2017 43
Page 44
Time synchronization
change the 'Daylight Savings Time' on these controllers and CEEs.
For controllers and CEEs that are in the same time zone as the Experion servers, you
can use the Automatically Apply DST option. Therefore, the 'Automatically Apply
DST' option can be applied to specific controllers and CEEs within an Experion
cluster.
Honeywell 2017 44
Page 45
Stations
Stations
This section describes how to determine your Station requirements. (Station is Experion's user
interface.)
Issue Comments
User types Identify the user types and assess their respective needs.
Read-only
access by casual
users
Flex Stations
Console Stations
Mobile Stations
Simultaneous
view of several
displays
Specialized
hardware
Security
requirements
Display update
rates
Determine whether an eServer, which provides read-only access to displays
and reports, would satisfy the needs of users such as managers and production
controllers.
Flex Station is the standard type of Station. It typically runs on a standard
computer, and is suitable for most users and most tasks.
If you have Process Controllers and don't want to suffer loss of view if the
server fails, you need Console Stations.
If users want access to data as they move around the plant, then you should
consider Mobile Station.
Determine whether users (especially operators) need to simultaneously see
several displays.
Determine whether any users (especially operators) need specialized
hardware, such as multi-monitor consoles, and membrane keyboards.
Based on user types, work practices and site layout, determine the most
appropriate security setups for Stations and Windows.
See the Network and Security Planning Guide.
Determine the rate at which you want displays to be updated.
Displays Determine your display requirements.
Identifying user types and assessing their needs
Before you can determine your Station requirements, you must first identify each user type,
and then assess their respective needs.
Typical user types include: operators, maintenance engineers, managers and production
controllers.
Honeywell 2017 45
Page 46
Stations
Operators generally need dedicated Stations, whereas maintenance engineers may only need
access to a Station for a few minutes, two or three times a day. Other users, such as managers
and production controllers, may only need read-only access to trend-related displays and
reports.
Connection options for Flex Stations
There are two ways of connecting a Flex Station to the server:
n
Static. A permanent, dedicated connection. This is the recommended connection type
for Flex Stations used by operators.
n
Rotary. An 'as required' connection. This is the recommended connection type for
users who do not need full-time access to the server, or who need remote access
(typically through a modem).
Rotary connections are advantageous from a licensing viewpoint because the license
specifies the maximum number of simultaneous Station connections.
About Console Stations
Console Stations provide direct access to process data as well as alarms and messages from
CDA sources such as Process Controllers. This direct access provides a continuous view of
your process, even if the Experion server is unavailable (for example, during a server
failover). Consequently, there is no loss of view of critical data and alarms when the server
fails, and so an operator can still control and monitor the process.
During server outages, any specific chart visualization access directly to the Engineering
Repository Database (ERDB) view is not available unless at least one of the servers is
available. Other views, such as Detail Displays, remain available at all times.
A Console Station is also connected to an Experion server. After you configure the
connection to the Experion server, the server database files are replicated to the Console
Station. This means that configuration of items such as process points is only done once.
Although a Console Station provides direct access to data, alarms and messages, some
functions, such as reporting, history and events collection, are still provided by the Experion
server. Therefore, if the Experion server is unavailable these functions are not available on the
Console Station. For details, see the “Functions available on the Console Station” and “What
happens when the Experion server is unavailable” topics in the “Configuring Console
Stations” section of the Station Configuration Guide.
Attention:
Honeywell 2017 46
Page 47
Stations
Console Stations do not report any CNET or CNI-related notifications. This is
because the Network Diagnostic Manager (NDM) that is responsible for reporting
CNET or CNI-related notifications is not enabled on Console Stations. NDM runs
only on primary servers or non-redundant servers. For more information about
NDM, see the “NDM Overview’” topic in the “Alarm and Event Processing”
section of the Control Hardware Notifications Theory Guide.
Licensing
For more information about Station licensing, contact your Honeywell representative.
Mobility
There are several solutions for mobility and remote access to Experion data.
A remote device can be:
n
A handheld or similar mobile device on a wireless network.
n
A computer on a remote network.
n
A computer that is not on your Experion process network (for example, a computer that
is connected to your business network).
n
A computer that is not running the Microsoft Windows operating system.
Considerations for selecting a mobility access solution:
n
If you need access from a small screen on a mobile or handheld device, use eServer
Mobile Access.
n
If you need full Station capabilities on a larger screen, use Mobile Station.
n
If you need eServer Premium Access functionality from a client that does not meet all
of the requirements of eServer Premium Access, use Mobile Access for eServer
Premium.
n
If you need simple, lightweight access to Station displays, use eServer Standard
Access.
The following table identifies the requirements and characteristics for each mobile access
solution.
Solution
Node
requirements
Characteristics Zero client
eServer
Standard
Access
Honeywell 2017 47
eServer
Business and field users. Typical desktop screen
size. Read only access.
Yes
Page 48
Stations
Solution
Node
requirements
eServer
Premium
eServer
Access
eServer
Mobile
eServer
Access
Remote
Mobile
Station
Engineering and
Station Server
(RESS)
Mobile
Access
for
eServer
Premium
eServer and a
Remote
Engineering and
Station Server
(RESS)
Station update rates
Characteristics Zero client
No.
Business and field users. Typical desktop screen
size. Read only access. Live updates and trends.
Requires a
small
installation.
Field users mainly. Designed for small screens,
such as handheld devices.
Yes
Field users mainly. Full Station capabilities for field
users. Typical desktop screen size. Read and write
access. Can also be used for remote access to
Yes
Configuration Studio.
Business and field users. Typical desktop screen
size. Read only access. Live updates and trends.
Yes
In an Experion system there are a number of different update rates that you can configure, all
of which are taken into account when determining the 'actual update rate' that is visible to an
operator. For example, you can configure the rate at which:
n
The Experion server subscribes to data from devices
n
Station receives updates from the Experion server
n
Individual custom displays are updated.
n
The values of individual parameters on a custom display are updated
When planning your system it is recommended that you specify the longest practical update
rate to reduce the load on the server. This is a particularly important consideration if a Station
uses a remote or low-bandwidth connection.
For more detailed information about the various types of update rates and how they are used
to determine the 'actual update rate', see the topic 'Understanding update rates' in the
'Customizing Stations' section of the Station Configuration Guide.
Honeywell 2017 48
Page 49
Stations
Specialized Station hardware
In general, Station runs on a standard computer, with a PC keyboard, monitor, and mouse.
However, Station supports most Windows-compliant peripherals such as trackballs and
touchscreens, as well as two specialized keyboards:
n
Operator Entry Panel (OEP). This is a membrane-style keyboard with dedicated
function keys. It is suited for use by operators in harsh environments.
n
Integrated Keyboard (IKB). This consists of a standard keyboard combined with
dedicated function keys and built-in trackball. It is suited for use by operators who need
a large number of function keys in addition to a standard keyboard.
n
Operator Touch Panel. This is a touchscreen device that shows the status of your
system, process information, and also provides an interface for updating the values
associated with a point parameter.
Attention:
The IKB and the OEP keyboard are not compatible with Experion Electronic
Signatures. You cannot use either of these keyboards with Experion Electronic
Signatures.
Determining your Station requirements (an example)
The following example shows how to determine your Station requirements.
Your configuration and Station requirements are as follows:
n
The site has a control room, staffed with two operators. It is essential that both
operators can always see the Alarm Summary and some critical trend displays.
n
Maintenance engineers need access to Stations on the production line, and have
suggested five suitable locations.
n
The two production controllers need one Station in their office. After hours, one of
them is always on call—consequently, they both need Station at home.
The following Stations meet the requirements:
n
Two Console Stations in the control room. Each Station is fitted with four monitors,
and uses Multi-window Station and SafeView to ensure that the critical displays are
always visible.
n
Five rotary Stations on the production line.
Honeywell 2017 49
Page 50
Stations
n
One static Station in the production controllers’ office.
n
Two modem-connected rotary Stations at the homes of the production controllers.
Because of the anticipated usage levels of the rotary Stations, you decide you only need a
license for six Stations: three static (includes the two Console Stations) and three rotary.
Honeywell 2017 50
Page 51
Printers
Printers
This chapter describes how to determine your printer requirements.
IssueComments
Alarm printers are typically located near Stations used by operators—for
example, in the control room.
Alarm printing
Alarm printing requires a 132-column dot matrix printer that has been qualified
for use with Experion.
Reports can be printed on any suitable printer.
Reports
Display
captures
Typically, each report is directed to the most convenient printer on the network.
For example, an alarm report might be printed on the printer in engineering
office.
If you need to capture display contents, such as trends, you should consider a
color printer.
Honeywell 2017 51
Page 52
Controllers
Controllers
Experion supports a wide range of controllers in addition to Process Controllers. This chapter
describes issues you need to consider in order to integrate these controllers with your
Experion system. (The Control Hardware Planning Guide contains planning information for
Process Controllers.)
IssueComments
Experion-specific
documentation
Monitoring and control strategies
Connection options Determine how you are going to connect the controllers to the server.
Scanning strategies
Read the interface reference for each type of controller you want to
integrate with Experion.
Configure the controllers so that they do not impose excessive
communications or processing loads on the server.
Determine the server's data update requirements, and then design a scanning
strategy that minimizes the communications load.
Interface references
There is a separate interface reference for each type of SCADA controller supported by
Experion. These references include integration details, such as connection and configuration
options, that may affect your design and planning decisions.
If Quick Builder is used to configure a controller, the interface reference is also included in
Quick Builder's help.
Monitoring and control strategies
Attention:
Do not include the server in any control loops because potential delays, caused by
communications traffic or heavy server loads, may seriously affect your plant's
operation.
You should configure controllers so that they do not impose excessive communications or
processing loads on the server. It is important to remember that the server's primary tasks are
to:
n
Monitor system activity
n
Start/stop processes
Honeywell 2017 52
Page 53
Controllers
LAN
Station
Server
Controllers
n
Generate reports
n
Provide data to other systems
Connection options
The way in which you connect a controller to the server depends on several factors, including
your plant's layout and the controller's communication port(s). (Note, however, that your
choice may depend on restrictions specified in the interface references.)
Network connections
If a controller has a network port, you can connect it directly to the network.
Controllers connected directly to the network
Redundant connections
If you have network redundancy, you may be able to connect some controllers using
redundant connections. To check whether your controllers support redundant connections,
see the manufacturers’ documentation and the Experion interface reference for that controller
or communication protocol.
Direct serial connections
If you have a small system, you can connect controllers to the server's serial ports.
Note that you can add more serial ports to the server with a serial adapter. An advantage of
serial adapters is that they provide a choice of interfaces, such as RS-422 and RS-485, which
are suitable for medium-distance links.
For a list of qualified serial adapters, contact your local Honeywell representative.
Honeywell 2017 53
Page 54
Controllers
Indirect serial (terminal server) connections
You can connect controllers to the network through a terminal server. (A terminal server
allows you to connect several controllers to the network even though they only have serial or
parallel ports.) Most terminal servers also provide a range of serial connection options, such as
RS-232, RS-422 and RS-485.
Tip:
Be aware of the difference between the similar sounding terms 'Terminal Servers'
and 'Terminal Services'. They are quite different terms referring to different
technologies and are not interchangeable.
A Terminal Server is a hardware device for connecting one or more serial
communication controllers (terminals) with an Ethernet network.
Windows Terminal Services (now known as Remote Desktop Services) refers to
software which provides remote desktop connection of Windows-based
computers over a network.
Terminal servers are particularly useful if you have a:
n
Plant-wide LAN, and you want to connect controllers to the LAN—as shown in the
following figure.
n
Geographically-dispersed controllers on a WAN.
Honeywell 2017 54
Page 55
Controllers
Typical system with terminal servers
Terminal servers and server redundancy
If you have redundant servers, you must use terminal servers to connect controllers that only
have serial ports. (Unlike the controllers, terminal servers can automatically switch
communications to whichever server is running as primary.)
Honeywell 2017 55
Page 56
Controllers
A terminal server in a redundant server system
Modems
You can use modems to connect controllers located at remote sites, such as reservoirs.
If you only require infrequent scanning—as in the case of a reservoir—you could use a dialup modem. If you require more frequent scanning, you could use a modem in conjunction
with a leased line.
Note that you can also use modems to connect remote Flex Stations—for example to give
engineers after-hours access from home.
Specialized links
If modem connections are not suitable, you can also use radio, satellite or other specialized
links. In such cases, discuss your requirements with your local Honeywell representative.
Honeywell 2017 56
Page 57
Points
Points
This section describes how to determine your point requirements.
Tip:
If you want to use a user-defined data format, you must define the format on the
server. See the section titled "About user-defined data formats" in the Station
Configuration Guide for more information.
Issue Comments
Point names Develop a consistent naming strategy for your points.
If you have controllers other than Process Controllers, you need to understand
Point types
the purpose and capabilities of Experion’s inbuilt point types (called standard
points).
System
interfaces
Algorithms Determine whether you need to use any algorithms.
Scripts
History
collection
Groups Determine which points need to be grouped and displayed together.
Trends Determine which point parameters need to be displayed in a graphical manner.
Scanning
strategy
Number of
points
Multipleservers
Experion includes a number of high-level interfaces—called system
interfaces—that allow it to exchange data with other applications or subsystems
without the need for separately defining points.
Determine whether you can use server scripts to perform specialized tasks on
points.
Determine your history collection requirements.
Develop an appropriate scanning strategy. (Scanning is the process by which
the server reads from/writes to memory locations in controllers other than
Process Controllers.)
Estimate the number of points you require—the number determines your
licensing requirements.
If you have multiple servers, review information on point data in a DSA
system.
Point naming conventions
All points within your system have a tag name (also called a point ID or point name) and
Honeywell 2017 57
Page 58
Points
anitem name. Tag names must be unique, whereas item names can be duplicated as long as
the resulting full item name is unique.
When a point is created, it is given a unique tag name, for example, POINT01 or POINT02.
This identifier is used in Experion whenever it is necessary to refer to a point in the server (for
example, on a custom display or in a report).
Point names must follow certain naming rules:
n
An item name cannot match the item name of any other point belonging to the same
parent asset.
n
Tag names must be unique within the cluster server.
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: POINT01 and Point01 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 or strings:
l
Ampersand (&)
l
Asterisk (*)
l
Backslash (\)
l
Braces {} (rule applies to item names only)
l
Brackets []
l
Caret (^)
l
Colon (:)
l
Comma (,)
l
Double quote (")
l
Equals (=)
Honeywell 2017 58
Page 59
Points
l
Forward slash (/)
l
Greater than (>)
l
Less than (<)
l
Number sign (#)
l
Parentheses ()
l
Percent (%)
l
Period (.)
l
Question mark (?)
l
Semi colon (;)
l
Single quote (')
l
Space (rule applies to tag names only)
l
String “-Out”
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
It is also important for both engineers and operators that points are named in a consistent and
‘user-friendly’ manner. You might, for example, consider:
n
Basing the names on existing documentation, such as schematics and wiring diagrams,
so that users can easily switch between documents and displays.
n
Using the same prefix for related points, so that users can easily find related points.
n
Starting each part of a name with a capital, to improve readability. For example:
Boiler1Temp.
Honeywell 2017 59
Page 60
Points
Examples
n
Using a device name prefix. All points associated with Boiler3:
Boiler3Temp
Boiler3InValve
Boiler3OutValve
n
Using recipes. A recipe is used to control a unit called B5. (A unit is typically
something like a chemical cracker.) The recipe includes the following ingredients (each
ingredient contains a value that is downloaded to the unit): WATER, ACID, and
START.
You need to create the following points for unit B5:
B5WATER
B5ACID
B5START
Point IDs and Distributed System Architecture (DSA)
With DSA, you can have more than one point with the same point ID (or tag name) provided
that the name is unique to a given server and that the points do not belong to the same asset.
If points with duplicate IDs (tag names) are created, then they can be distinguished by
prepending the tag name with the server alias. If, for instance, there are two points with the
duplicate tag name FIC123 on servers NorthPlantSrv and SouthPlantSrv, then the
prepended tag names of each point would be NorthPlantSrv:FIC123 and
SouthPlantSrv:FIC123. The prepended tag name can be used wherever normal tag names
are used (for example, in a HMIWeb display).
Two important restrictions for points with duplicate tag names are:
n
They must not belong to the same asset.
n
Their prepended tag name (for example, NorthPlantSrv:FIC123) must not exceed 40
characters.
Standard point types
Experion provides the following types of standard (SCADA) point that are used to exchange
data with controllers other than Experion Process Controllers.
Standardpointtype Use
Analog Continuous values, such as temperature or pressure.
Status Digital values (on and off).
Honeywell 2017 60
Page 61
Points
Standardpointtype Use
Accumulator Totalizer values.
Container
A user-defined point type that allows you to treat a group of related points
as if they were one point.
Standard points have a composite data structure that can represent several field values as
parameters. For example, you only need one analog point for a control loop that maintains the
temperature of an oven, because the point's data structure includes the following parameters
(data items):
n
Process variable (PV) to record the current oven temperature
n
Output variable (OP) to change the temperature of the oven
n
Set point (SP) to specify the correct oven temperature
n
Mode (MD) to change the loop from manual to automatic control
User-defined parameters
You can increase the functionality of a standard point by defining your own parameters to
store custom data. For example, you may want to store a value generated by a script, or
record the serial number of the device associated with the point. You can also add userdefined scanned parameters to analog and status points so that for example you can retrieve a
collection of related Modbus/TCP Input/Holding Registers or Input Status/Coils
corresponding to a single Modbus/TCP device and Function code. See the topic titled "Userdefined point parameters" in the Station Configuration Guide for more information.
For more information about standard points, see the topic titled "Understanding and
configuring points" in the Station Configuration Guide and 'Building and configuring points'
in the Quick Builder User’s Guide.
Data quality
For point parameters values acquired by the server’s OPC scan task, the OPC Quality of the
value is also stored. When no OPC Quality is available, Experion sets the quality according to
the following rules.
1.
If the value is not a number (NaN), the quality is set to UNCERTAIN.
2.
If there is a communications error, the quality is set to BAD with a substatus of Comm
Failure.
3.
If neither of the above is true, the quality is set to GOOD.
Honeywell 2017 61
Page 62
Points
Container points
A container point ties together a set of related points so that they can be managed as if they
were one point. Container points not only speed up configuration tasks, they also make it
easier for operators to manage your system.
A container point is, in effect, a user-defined point type that matches your data requirements
for a particular type of device or process. For example, if you have fifty identical
compressors, you could create a new type of container point called 'compressor', and then
create one compressor point for each compressor.
For each type of container point, you must:
n
Define its structure in Quick Builder
n
Create a point detail display in Station (A point detail display shows run-time values
and configuration settings for a particular type of point, and is functionally equivalent to
the point detail displays supplied with Experion.)
You may also want to create a matching faceplate. (A faceplate is a specialized popup
that shows a subset of the details shown on the point detail display—typically the
point's run-time values and control settings. A faceplate appears when an operator
clicks an object that is linked to a point.)
Typical point detail display
For more information about container points, see 'About container points' in Quick Builder.
System interfaces
Experion includes a number of high-level interfaces—called system interfaces—that allow it
to exchange data with other applications or subsystems without the need for separately
defining points.
Honeywell 2017 62
Page 63
Points
The database structure of system interface—called flexible points—is determined by the
application/subsystem, rather than by Experion.
The documentation for each system interface contains Experion-specific information, such as
integration issues and connection options, that may affect your design and planning decisions.
For more information about the OPC Interface, see the “Configuring OPC” section of the
Station Configuration Guide.
Algorithms
An algorithm extends a point's functionality by performing additional processing, or initiating
an action. Experion provides two types of algorithms:
n
PV. Gathers/manipulates data, the result of which is usually stored in the point's PV.
n
Action. Initiates an action—such as requesting a report—when the point's PV changes
value.
Note that you should use algorithms with discretion, because attaching them to
numerous points may adversely affect the server's performance.
For a description of each algorithm, see 'Algorithms' in Quick Builder.
History collection
Experion can be configured to store the values of point parameters at predetermined intervals
to create a history of process values. This process is known as history collection.
Experion provides two different ways of collecting and storing historical data for point
parameters:
n
Periodic history
n
Exception history
The historical data collected by Experion can be used for:
n
Third-party applications via the Experion OPC HDA Server and ODBC driver.
Tip:
When connecting a third-party historian (such as PI) to Experion, it is
strongly recommended that you use the OPC HDA server rather than the
OPC DA server, because the HDA server will prevent duplicate load on the
control network. Also, all point parameters collected into the third–party
historian should be assigned to Experion history.
Honeywell 2017 63
Page 64
Points
n
Operational purposes, like trend monitoring (in the case of periodic history).
n
Collection and analysis by enterprise historians, like PHD servers.
Because the data from both periodic history and exception history is readily accessible to
specialized historians, the transmission of Experion history data places no additional load on
your control network.
Periodic history
Periodic history collects and stores numerical data at predefined regular intervals. Periodic
history data is generally used for operational purposes such as trend monitoring but is also
collected for historical analysis.
Experion has a comprehensive range of collection rates for periodic history. These collection
rates provide a high degree of flexibility in moderating the load on your control network.
n
Fast history stores snapshots of a point parameter at short regular intervals. You can
choose from 8 different collection rates. By default, the fastest collection rate is 5
seconds but this can be changed to 1 second if necessary.
n
Standard history stores snapshots at slightly longer intervals, ranging from 1 minute to
30 minutes. The fastest standard history collection rate of 1 minute can be changed to
30 seconds if necessary. In addition to storing snapshots, standard history also
calculates and stores average values, based on the standard history snapshot rates. The
default averages are: 6-minutes, 1-hour, 8-hours, and 24-hours.
n
Extended history stores 1, 8, and 24-hour snapshots.
If you need to further customize the periodic history collection intervals, please contact your
Honeywell technical representative.
Note that history collection is synchronized to the system time. For example, the 6-second
collection occurs at 6, 12, 18 (and so on) seconds after the minute boundary on the system.
Exception history
While periodic history is used for numerical data and primarily for operational purposes,
exception history is currently only available for string data collected for analysis by enterprise
historians such as PHD servers.
Like periodic history, exception history scans point parameter values at predefined intervals
and offers a comprehensive range of scanning intervals: with exception history you can
choose from up to 16 different scanning rates. Unlike periodic history, however, exception
history is based on sampling rather than regular collection: it only stores the scanned values
when they are different to the last stored value. This not only helps to minimize the database
size but also the load on the control network.
The default collection rates for exception history are:
Honeywell 2017 64
Page 65
Points
n
5, 10, 15, 30, and 60 seconds
n
5, 10, 15, 30, and 60 minutes
n
2, 4, 6, 8, 12, and 24 hours
If you need to customize the exception history collection intervals, please contact your
Honeywell technical representative
Offset groups
If you are collecting standard periodic history or exception history for TPS point parameters
you can control the impact of history collection on the LCN by assigning point parameters to
a history offset group. An offset group is used to specify a predefined delay, which enables
the data collection to be staggered. This helps to reduce the impact of history collection
processes on the performance of the underlying control system. You can choose from 16
default offset groups.
Note that offsets are not reflected in the time stamps for stored data. For example, if there is a
15-second offset and the data is collected at 8:00:15, the data is still time-stamped as if it had
been collected at the beginning of the interval, that is, at 8:00:00.
Storage requirements for history samples
Experion stores history values in physical files. The storage requirements for history
collection are detailed below. However, note that it may not be possible to configure the
maximum number of history parameters available. For more information about the maximum
number of point parameters for which you can collect history, contact your Honeywell
representative.
Periodic history
There are five history files for standard history - one for the snapshots and four for the
averages. There is a single history file for fast history, and there are three history files for
extended history.
Use the following formula to determine your total storage requirements (in bytes) for periodic
(that is, standard, fast, and extended) history:
(((N1+N2+N3+N4+N5+5)*(PS*7+8))+((N6+1)*(PF*7+8))+((N7+N8+N9+3)*
(PE*7+8)))*2
Where:
Variable Description
N1–N5
Honeywell 2017 65
The number of samples retained by each of the standard history files (N1 = 1-minute
snapshots, N2 = 6-minute averages, and so on).
Page 66
Points
Variable Description
N6 The number of samples retained by the fast history file.
N7–N9
PE The number of point parameters with extended history.
PF The number of point parameters with fast history.
PS The number of point parameters with standard history.
The number of samples retained by each of the extended history files (N7 = 1-hour
snapshots, N8 = 8-hour snapshots, and N9 = 24-hour snapshots).
Exception history
Exception history is stored in a set of two data files. Exception history requires at least 1.6 GB
of free disk space: this allows for two data files of 500 MB each, as well as extra space when
performing archiving operations.
Archiving history samples
You can configure each history file to hold up to 100,000 samples for each parameter. In the
case of fast history, the history file fills up very quickly. For example, if you set the fast
history interval to 1 second, then 100,000 samples represents just over one day.
Note that there is a limit to the size of each history file and that the number of samples stored
decreases as the number of parameters increases. Furthermore, the more samples you add, the
greater the impact on the server's system memory and CPU. For optimum performance,
especially in a redundant server system, it is recommended that you configure an individual
history file to be no greater than 500 MB in size (this is the default setting).
If you need to keep more than the maximum number of samples that each history file can
accommodate, you must configure the History Archive Manager to archive the history files at
appropriate intervals. Typically, history files are archived to another disk on the server, a file
server or to recordable media such as DVDs or CDs. While it is possible to estimate when the
files for periodic (that is, fast, standard, and extended) history files will be 'full', as there is a
constant collection and storage rate, it is not possible to do this with exception history files as
samples are only stored when their value or quality varies from the last stored value or quality.
Attention:
If trend displays on Station need to access historical information that has been
archived, the archives should be located on the server otherwise there will be
performance issues. See 'Configuring a trend' in the chapter on 'Group and trend
displays' in the Station Configuration Guide.
Honeywell 2017 66
Page 67
Points
Groups
You can make it easier for operators to interpret system activity by grouping related points.
Each group can contain up to eight points, and each point in the group has its own faceplate
that shows the values of the major parameters.
Typical group
Trends
Trends display historical process values in a graphical manner. In many instances, trends
provide operators with the best means of understanding system activity.
Depending on your database size, you can define up to 1,000 trends.
In order to make a trend meaningful, you need to select the appropriate type of history
collection for each point parameter. For example, you need fast history for rapidly changing
parameters, but extended history for slowly changing ones.
Honeywell 2017 67
Page 68
Points
Typical trend
Standard trends and limit trends display historical data for up to 32 points as line graphs. In
addition to the line graph, you can choose to display numeric history for the points in the
trend as well as events associated with the points in your trend.
You can configure your trend so that the data is displayed as:
n
A bar graph for up to three points
n
An X-Y plot for two analog points, with one point's values plotted against the other.
Scanning strategy
Scanning is the process by which the server reads from/writes to memory locations in
controllers other than Process Controllers.
Each item of controller data to which the server needs read/write access is defined in the
server as a point parameter. For example, the temperature of a boiler would typically be
represented in the server as the PV (process variable) of an analog point.
An efficient scanning strategy provides the required level of monitoring and control, while
keeping system load to a minimum.
IssueComments
Basic principles Ensure that your strategy conforms to the basic principles.
Scanning techniques Use scanning techniques that are appropriate to your needs.
Honeywell 2017 68
Page 69
Points
IssueComments
Scan optimization
Optimize your scanning strategy, so that you minimize the load on
the server.
Basic principles of scanning
Keep these two basic scanning principles in mind when designing your scanning strategy:
1.
Limit control to starting/stopping processes
The Experion server is not designed to be included in control loops—potential
communication delays and heavy server loads may result in unreliable system activity.
(The Experion server is designed primarily to collect data, and to present it in a
meaningful way to users.)
2.
Limit data extraction to useful information
You should only extract data from controllers that is useful to operators, or is required
for a specific purpose (trending, auditing, and so on).
Scanning techniques
Experion supports the following scanning techniques. (Scanning is the process by which the
server requests point parameter values from controllers.) You can use several scanning
techniques on the same controller, providing they are supported by that controller.
Scanningtechnique Comments
The server only scans a point parameter when requested by an operator, a
report, or an application.
Demand
For more information about demand scanning, see the topic titled "Demand
scanning" in the "Points" section of Station Configuration Guide.
The server performs 'Once-off' dynamic scanning, accelerated dynamic
scanning, or periodic dynamic scanning when an operator calls up a display
Dynamic
Exception
or requests it for a controller.
For more information about dynamic scanning, see the topic titled "About
dynamic scanning" in the "Points" section of Station Configuration Guide.
The server polls the controller for any change-of-state data. Exception
scanning is thus triggered by events, not time.
Exception scanning is:
Not supported by all controllers
n
More difficult to implement than periodic scanning because it
n
usually requires additional logic in the controller, additional
configuration in Experion, or both
Honeywell 2017 69
Page 70
Points
Scanningtechnique Comments
The server scans a point parameter at the specified interval. For example,
if a parameter's scan period is 15 seconds, the server scans the associated
controller every 15 seconds for the parameter's value.
You can choose from a range of standard scan periods, ranging from
seconds to minutes, and you can assign a different scan period to each
parameter.
Periodic
Periodic scanning:
Is supported by most controllers
n
Is simple to implement
n
Places a predictable, but potentially heavy, load on the server
n
The server scans a point parameter at scheduled periods. Electronic Flow
Measurement (EFM) only.
Scheduled
For more information about Electronic Flow Measurement, see the
"Configuring Electronic Flow Measurement (EFM)" section of Station
Configuration Guide.
Unsolicited messaging
Some controllers support unsolicited messaging, where the controller, rather than the server,
initiates a communications session. Unsolicited messaging can substantially reduce
communications traffic, especially if the values do not change frequently.
Check the manufacturer's documentation to determine whether a controller supports
unsolicited messaging.
Scan optimization
To optimize scanning:
n
Use unsolicited messaging if the controller supports this feature, and values change
infrequently.
n
Use periodic scanning if values change frequently.
n
Choose a scanning period appropriate to the values being scanned. For example, you
do not need to scan a temperature every 5 seconds if it changes only slightly over an
hour.
n
Minimize the number of scan packets as follows:
Honeywell 2017 70
Page 71
Points
l
Specify the minimum number of scan periods for a given controller because the
server requires a separate scan for each scan period. For example, you might only
need two scan periods for a particular controller: a short one for a few critical
values, and a long one for all other values.
l
For each scan period you use, specify the longest period that is acceptable to your
needs.
l
Arrange parameter value addresses so that they occupy contiguous addresses in the
controller's memory, as shown in the following figure. If parameters occupy
contiguous addresses, the server can access many parameters in a single scan—the
exact number is controller-specific.
Estimating the number of points required
Based on your analysis of your system and the role that you want Experion to perform,
estimate the number of points you need to define. Use this figure, with an appropriate safety
margin, to determine your licensing requirements.
Remember that the composite nature of Experion points means that you do not need one point
per I/O value.
Honeywell 2017 71
Page 72
System Status Network tree
System Status Network tree
This section describes Network Tree planning considerations.
Topic Goto
About the System Status Network tree About the System Status Network tree below
About System Event server and System
Performance Server
Identifying a network topology Identifying a network topology on page74
About System Event Server and System Performance
Server on the next page
About the System Status Network tree
This section describes the Network tree planning considerations so that you are able to view
computers and network equipment and their events from the System Status display. You use
specific tasks in Configuration Studio to define network equipment. After you download
these definitions, the Network tree in the System Status display is built and visible to
operators with the appropriate scope of responsibility assignment.
In order to view event and performance data for the items appearing in the Network tree, you
deploy the Experion System Event Server and System Performance Server.
Honeywell 2017 72
Page 73
System Status Network tree
About System Event Server and System Performance Server
The System Event Server (SES) is an Experion system component that issues Windows
events as OPC alarms or events to a subscribing OPC client such as the System Status
Display. The System Status display shows Windows system events through the use of the
SES. The SES is integrated with the Experion Alarm and Event subsystem. The integration
means, for example, that an operator can acknowledge a system alarm from the System Status
display in the same manner that a process alarm is acknowledged on the Alarm Summary
display.
The System Performance Server (SPS) is an OPC Data Access server that retrieves
performance and configuration information and allows it to be integrated into operator
displays and process applications in a manner consistent with process data access. This kind
of information is vital for system monitoring and problem analysis. While third-party tools
provide some trending and analysis of computer and network performance information, the
SPS provides capabilities that integrate this information into the process control environment.
Honeywell 2017 73
Page 74
System Status Network tree
Note that the scope of SPS is per cluster. By default, all computers added to the network tree
in Configuration Studio are automatically assigned to the server that is hosting the Enterprise
Model Database (EMDB). These computers need to be reassigned in the multiple cluster
server EMDB.
When multiple clusters (or even domains, workgroups or organizational units) are covered in
a single EMDB, it is necessary to assign computers to the appropriate SPS. In all cases, this is
the local Experion server providing that cluster.
For more information, see the System Management Configuration Guide.
Identifying a network topology
Several topologies are shown in this section to illustrate System Status Network tree planning
considerations. The topologies include:
n
Workgroup
n
Domain with no Organizational Units (OUs)
n
Domain with OUs
n
Multiple domains
Attention:
If you are planning to support a Network tree in a Windows domain environment,
the following sections imply that you have Active Directory and Dynamic DNS
already configured. The topologies are narrowly focused on planning
considerations for the System Status display Network tree. For information
regarding network and security best practices for Experion systems, refer to the
Network and Security Planning Guide.
Workgroup topology
In the following figure, a workgroup topology is shown to illustrate planning considerations
to support event notifications to the System Status display and its Network tree.
Honeywell 2017 74
Page 75
System Status Network tree
In this example:
n
Redundant Servers support several Stations in the same workgroup topology.
n
All nodes belong to the same IP multicast group using the same IP multicast address,
which forms them into an FTE Community.
n
System Performance Server (SPS) should be installed on all Experion servers.
n
The System Event Server is installed on only one of the redundant server pairs.
n
The System Event Server scope of 'domain' (its default setting) is appropriate for this
workgroup topology.
n
When there are multiple Experion servers in an FTE Community, the Distributed
System Architecture (DSA) option should be enabled so that the servers can share SES
event data.
n
Each server in the FTE Community subscribes to the server hosting the SES.
Domain with no Organizational Units (OUs)
In the following figure, a simple domain with no Organizational Units (OUs) topology is
shown to illustrate planning considerations to support event notifications to the System Status
display and its Network tree.
Honeywell 2017 75
Page 76
System Status Network tree
In this example:
n
Redundant servers support several Stations in the same domain topology.
n
All nodes belong to the same IP multicast group using the same IP multicast address,
which forms them into an FTE Community.
n
System Performance Server (SPS) should be installed on all Experion servers.
n
The System Event Server is installed on only one of the redundant server pairs.
n
The System Event Server scope of 'domain' (its default setting) is appropriate for this
topology.
n
When there are multiple Experion servers in an FTE Community, the Distributed
System Architecture (DSA) option should be enabled so that the servers can share SES
event data.
n
Each server in the FTE Community subscribes to the server hosting the SES.
Honeywell 2017 76
Page 77
System Status Network tree
Domain with Organizational Units (OUs)
In the following figure, a domain topology using Organizational Units (OUs) is shown to
illustrate planning considerations to support event notifications to the System Status display
and its Network tree.
In this example:
n
Redundant servers support several Stations in OUs in the same domain topology.
n
All nodes belong to the same IP multicast group using the same IP multicast address,
which forms them into an FTE Community.
n
System Performance Server (SPS) should be installed on all Experion servers.
n
The System Event Server is installed on only one of the redundant server pairs.
n
The System Event Server scope of 'domain' (its default setting) is appropriate for this
topology.
n
When there are multiple Experion servers in an FTE Community, the Distributed
Honeywell 2017 77
Page 78
System Status Network tree
System Architecture (DSA) option should be enabled so that the servers can share SES
event data.
n
Each server in the FTE Community subscribes to the server hosting the SES.
Multiple domains or multiple workgroups
In the following figure, a topology using multiple domains is shown to illustrate planning
considerations to support event notifications to the System Status display and its Network
tree. A topology of multiple workgroups within the same multicast group should follow these
same planning considerations.
In this example:
n
Redundant servers support several Stations in each workgroup or domain topology.
n
All nodes belong to the same IP Multicast group using the same IP Multicast address,
Honeywell 2017 78
Page 79
System Status Network tree
which forms them into an FTE Community.
n
System Performance Server (SPS) should be installed on all Experion servers.
n
The System Event Server is installed on one of the redundant server pairs in each
workgroup or domain.
n
The System Event Server scope of 'domain' (its default setting) is appropriate for these
topologies.
n
When there are multiple Experion servers in an FTE Community, the Distributed
System Architecture (DSA) option should be enabled so that the servers can share SES
event data.
n
Each server in the FTE Community subscribes to the server hosting the SES in each
workgroup or domain.
n
If Server1 and Server2 are DSA connected, duplicate FTE event notifications occur.
To eliminate these duplicate FTE event notifications, remove the FTE event filter file
(FTEFilter.xml) from all but one SES pair.
The FTE event filter file is located at C:\HWIAC\Filters\FTEFilter.xml<data
folder>\Honeywell\ProductConfig\Filters\FTEFilter.xml.
Where <data folder> is the location where Experion data is stored. For default
installations, <data folder> is C:\ProgramData. The C:\ProgramData folder
is a system folder, which means that it is only visible if you select the Show hidden
files, folders, and drives option button in the Folder Options dialog box. To change
this setting in Windows Explorer, click Organize > Folder and search options, and
then click the View tab.
SES event notification behavior
Events are gathered by the System Event Provider (SEP), part of system management
runtime. The events are synchronized on all nodes within the FTE Community and domain.
The SES is used to convert these events to an OPC event usable by the Experion server.
If the SES fails, an event is generated by the Experion server indicating that it has lost the
connection to the SES. System Events are not viewable until the SES is restarted, or the
Experion server fails over to the redundant server. When SES is restarted, it reads all events
from the SEP and makes them available to the server. No event loss occurs. If the SEP fails,
the SES reports loss of connection with its data source (SEP), and no system events are
available. When the SEP is restarted, it synchronizes with another node which has the full set
of events. In addition, new events that occurred during the time that SEP was unavailable are
read and added to the event list. No event loss occurs.
Network tree planning summary
Honeywell recommends that one of the above topologies be chosen when implementing
Experion. Utilizing these topologies will allow for simplified configuration and cater to future
Honeywell 2017 79
Page 80
System Status Network tree
system expansion. System expansion is simplified by simply configuring new nodes to use
the same IP Multicast address and the same SES already implemented. The planning
considerations are summarized in the following sections.
Attention:
It is strongly recommended that you implement a topology featuring one SES per
cluster server.
For information on implementing this topology, see Technote 234 available from
the Honeywell HPS Online Support website.
Recommendations
For typical domain and workgroup environments, establishing all nodes to use the same
multicast address and SES scope provides you with the most ease of use and flexibility for
future growth.
Location of SES
Only one System Event Server (SES) must be installed per FTE Community, per domain. If
the Experion servers are redundant, the SES is installed on both servers. The nodes access the
SES in their domain as defined from the FTE Community Settings task in Configuration
Studio.
Scope of SES
The SES scope default setting of 'domain' provides synchronization of system events across
the domain as restricted by the multicast community.
Enabling event notification for SES
Events are enabled for capturing through the use of the event filter configuration tool. Event
filter files are installed on the nodes where the events defined (in the filter file) are logged. For
example, the TPN Server event filter file is installed on the node with the TPN Server. FTE
filter files are installed with the SES. By default, all FTE events are collected based on the
view of the SES node.
DSA
The Distributed System Architecture (DSA) option should be enabled so that multiple servers
in an FTE community can share SES event data. Only one server (pair) in the DSA can have
the SES component installed and active. The remaining servers need to subscribe to the server
(pair) hosting SES to access all system events.
Honeywell 2017 80
Page 81
System Status Network tree
When you first define a server and download this server definition to other servers in the
system, the default subscription for the server is disabled and it does not participate in the
DSA. After you define a server, you must enable the DSA connection with other servers so
that SES event data can be shared.
You need to consider these DSA connections when determining the number of DSA
connections to license.
Location of SPS
SPS should be installed on all Experion servers.
Notifications from switches and routers
Any switches or routers from which notifications are to be received are configured to send
those notifications to the server nodes on which the SNMP Monitor has been installed.
Auxiliary Status display
SES and SPS auxiliary displays are installed automatically on all Experion nodes as part of
the system management software. The Auxiliary Status display should be installed on any
other clients needing view of SES or SPS auxiliary status. Other managed component
auxiliary displays need to be installed (for example, Redirection Manager) if used within the
system.
Honeywell 2017 81
Page 82
Alarms and events
Alarms and events
This section describes how to determine your alarm and event requirements.
Issue Comments
Designing
alarm
systems
Consider and plan your alarm strategy.
Dynamic
Alarm
Suppression
Alarm and
alert
shelving
Alarm
prioritization
System
alarm help
Alarm
annunciation
Alarm
groups
Decide whether you want to enable Dynamic Alarm Suppression to deal with high
alarm situations like unit trips by temporarily but automatically removing certain
'flow-on' alarms from normal alarm views.
Decide whether you want to enable alarm shelving. Enabling alarm shelving
allows operators to temporarily remove alarms from normal alarm views. For
example, if some equipment is out of action for maintenance, operators can
temporarily remove alarms associated with this equipment from their current alarm
view.
Alerts can also be shelved in the same way.
Formulate a set of rules and guidelines for prioritizing alarms.
System alarm help is supplied with each release of Experion and can be tailored
for a customer's site. For more information about how to do this, see "Configuring
system alarm priorities and help" in the Station Configuration Guide.
Consider your alarm annunciation needs, such as buzzers and horns.
Decide whether you want to create alarm groups. Alarm groups provide an
alternative way of viewing alarms, which is not related to your asset model. For
example, you could create an alarm group to monitor alarms on all electrical
motors in your plant, regardless of their locations within the asset model.
Decide whether you want to create system alarm groups. Unless stated otherwise,
the configuration and usage of system alarm groups is the same as alarm groups.
System
alarm
groups
Alarm
Tracker
Alerts
Honeywell 2017 82
However, system alarm groups can only include system points and other system
alarm groups. They can be used to create a hierarchy of dashboards for the System
Status display. For more information, see “Creating a dashboard hierarchy for the
System Status display” in the HMIWeb Display Building Guide.
Decide whether you want to create alarm trackers. An alarm tracker provides an
asset-based, graphical view of alarms over time that helps operators identify and
respond to abnormal situations like alarm floods. Alarm Tracker is an Experion
license option.
Consider using alerts for notifications whose urgency and priority are not high
Page 83
Alarms and events
Issue Comments
Messages
enough to be alarms.
When defining an alarm for certain types of standard point (status, analog and
accumulator), you can assign an appropriate message that helps operators
understand the significance of the alarm. (The Alarm Summary display only shows
basic details—such as the pointID, date/time and priority—which may not be
sufficient for operators.)
Events
Consider your event storage and archiving needs. (Events include changes in
alarms, changes in point status and operator actions.)
Planning and designing your alarm system
It is generally agreed that the purpose of an alarm system is to announce to operators that
something is abnormal and that action is (or may be) required in response to that situation.
In an ideal world, operators would only see alarms for process events and states that require
specific operator action within a relatively short time. However, even in the most welldesigned alarm system, operators may find that the primary alarm summary display includes
alarms that are of no immediate operational relevance.
Other problems that can occur in alarm systems are:
n
Excessive standing alarms: When alarms are continually on the primary alarm summary
display, operators often learn to ignore these alarms. This makes it less likely that
operators will see alarms that really do require action.
n
Alarm floods: When alarms are raised so quickly that operators do not have enough
time to react to them, important alarms that require a prompt response become
obscured. In situations like this, the alarm system can hinder rather than support
effective operations.
A well-planned and thoughtfully designed alarm system that encompasses a range of
strategies and solutions can, however, minimize the number and type of alarms that prevent
operators from focusing on and dealing with the most urgent or important alarms at any given
time.
The following topics describe:
n
Honeywell product solutions that support effective alarm strategies
n
Factors that contribute to excessive alarms
n
Strategies for dealing with such factors
Honeywell 2017 83
Page 84
Alarms and events
Honeywell products that support effective alarm strategies
Consider the following Honeywell products when planning your alarm system and strategies
for dealing with abnormal situations.
Alarm Configuration Manager
Alarm Configuration Manager (ACM) is a product that is separate but complementary to
Experion. The key feature of ACM is its capacity for “holding” designed alarm settings as the
master alarm database, and through audit and enforcement, providing a “safety net” to ensure
that changes are temporary and that the engineered alarm configuration can always be
restored.
With ACM, settings like alarm trip points, priorities, and the disable status can be driven by
planned equipment operating modes. ACM also provides tools that support work processes
for alarm rationalization and maintenance.
Experion Dynamic Alarm Suppression
Experion Dynamic Alarm Suppression (DAS) is ideal for reducing excessive alarms arising
from unplanned compound events like equipment trips. It provides additional capability and
convenience above and beyond the current mechanisms of controller logic. Although DAS
can be applied to suppress alarms from planned equipment outages, ACM provides a more
complete solution for planned outages.
Experion alarm or alert shelving
Experion alarm or alert shelving allows operators to temporarily remove alarms or alerts from
the main display when they are nuisance or extraneous alarms or alerts that are not filtered out
by other mechanisms.
Other Experion functionality
Within Experion there is a range of other functionality that enables operators to deal with
excessive or extraneous alarms. For example, operators can temporarily disable alarms. There
is also an Experion alarm configuration option that, when enabled, allows operators at a
specified security level to temporarily suppress the audible annunciation of non-urgent alarms.
To help deal with alarm bursts and floods, operators can also use the Alarm Tracker pane on
the Experion Alarm Summary. Alarm Tracker is an Experion license option that provides a
graphical, time- and asset-based view of alarms. By making it easier for operators to identify
“clusters” of alarms on assets within an operator’s scope of responsibility, an alarm tracker
helps operators to respond more quickly to excessive process alarms.
While such functionality provides a good basis for dealing with situations that can lead to
excessive alarms, ACM, DAS and alarm shelving provide extra capability that can
significantly reduce the number of excessive alarms that have no operational relevance.
Honeywell 2017 84
Page 85
Alarms and events
Together all of these tools provide engineers and operators with a good set of complementary
functions for reducing excessive alarms in the case of both standing alarms and alarm floods.
You can use some or all of these tools based on site needs.
For more detailed information about the functionality described above, see the Station
Configuration Guide.
Factors that contribute to excessive alarms
The main causes of excessive alarms (and alarms that have no immediate operational
relevance) include:
n
n
n
Alarm design, for example, when the alarm system is not properly rationalized to
reduce alarm floods and excessive standing alarms.
Maintenance issues, for example, when the control system is being modified or when
sensors are taken out of service for repair and the alarms related to those sensors are
taken out of service at the same time. If no preemptive action is taken in relation to
those alarms, standing (and possibly spurious) alarms can appear during repair and
testing.
Changes in equipment mode, for example, when there is a change in the product being
manufactured and different operating parameters are required.
n
Compound events, for example, when there is a superseding event, like a compressor
trip, or when there are multiple related alarms.
n
Other causes. This category covers a range of other causes that need to be addressed in
a different manner to the causes listed above.
The likely impact of these factors is summarized in the following table.
Cause Most likely consequence
Standing alarms Alarm floods
Alarm design X X
Maintenance X
Equipment mode X
Compound event X
Other causes X X
Dealing with excessive alarms
Recommended strategies for dealing with excessive alarms are described below.
Honeywell 2017 85
Page 86
Alarms and events
Reducing unnecessary alarms through good design and alarm rationalization
Good alarm design through effective alarm rationalization is considered a best practice
strategy for dealing with excessive alarms resulting either from alarm floods or high numbers
of standing alarms.
Effective alarm rationalization removes alarms that do not meet the criterion of a necessary
alarm. It does this by ensuring that:
n
n
n
Only those events or states that require specific operator action within a short time (for
example, 15–30 minutes) are configured as alarms.
If no operator action is required, then that event or state should either:
l
Not be annunciated to the operator, or
l
Be configured as an alert or notification rather than an alarm.
The attributes of the remaining true alarms (for example, the trip point, priority, deadband, alarm on/off delay and range extension) are set to provide the best compromise
between enabling quick operator action and avoiding nuisance alarms.
One approach to alarm rationalization is to use controller logic to reduce standing alarms and
flooding. For example, you might use controller logic to:
n
Combine multiple similar alarms into a single robust alarm (for example, by using logic
to combine alarms from temperatures on the side of a tank), or
n
Cover changing equipment modes, or
n
Suppress consequential alarms.
On the other hand, you might consider using Alarm Configuration Manager (ACM) and
Dynamic Alarm Suppression (DAS) as more effective alternatives to customized controller
logic.
Despite best efforts to rationalize alarms, alarm systems can still suffer from alarms that are of
no immediate operational relevance. This might happen, for example, when the documented
operator action may not apply due to some circumstance not accounted for in the alarm design
process. Rationalization can therefore not entirely prevent excessive standing alarms or alarm
floods. Nevertheless it is a key component of (and indeed the very foundation of) a welldesigned and effective alarm system.
Dealing with alarms related to maintenance and repair
Often, operators put the point into the Disable or Journal-only state when this occurs, or
manipulate some other alarm attribute, such as alarm priority. However, putting an alarm into
“maintenance” means that this alarm will no longer protect the process.
The site alarm strategy should therefore identify a work process to:
Honeywell 2017 86
Page 87
Alarms and events
n
n
ACM provides a formal way to enforce such a work process.
Another option is to use Experion alarm shelving to:
n
n
n
Dealing with alarms related to changes in equipment mode
Even if an alarm system is well rationalized, excessive alarms may arise because a given piece
of equipment may operate differently in different situations. This happens sometimes in
continuous processes, and very often in batch processes. To deal with this, alarm
rationalization must put the alarm trip points at their most conservative settings, possibly
resulting in large numbers of standing alarms in situations where those alarm settings are too
aggressive.
Ensure that the loss of the alarm during this period will not cause excessive process
risk, and
Deploy alternative precautions if deemed necessary.
Shelve the alarm
Set the shelving reason to “Maintenance”
Define the scope of responsibility to ensure that appropriate supervision takes place.
A good solution is to have a controlled way to change alarm settings by equipment mode.
This can be done by what is sometimes called static alarm suppression or mode-based
alarming. Options here include:
n
Controller logic, where, for example, sequences can be used to manipulate alarm
attributes to change trip points, priorities, the journal-only state and the disable/journalonly status appropriately as batch phases progress.
n
ACM operating modes which provide a good, well-documented means for configuring
and changing alarm settings (alarm enable state, the disable/journal-only status, trip
points, and priorities) for each operating mode on an asset or piece of equipment. This
allows the alarm settings to be better tailored to the specific operating situations,
resulting in far fewer standing alarms.
Note that while DAS can be useful for suppressing alarms on a device that is out of
service, it cannot adjust alarm properties like trip points.
Caution:
Any solution that affects safety-related or otherwise critical alarms should be
carefully considered as well as carefully designed and implemented.
Honeywell 2017 87
Page 88
Alarms and events
Dealing with compound events: consequential alarms or other multiple alarm
situations
Alarms are generally configured to notify operators that action is required in an otherwise
normal or quiescent process. However, equipment failure or process upsets can lead to many
more alarms than the operator can react to, while only a few of those alarms (for example,
“compressor trip”) indicate what the operator’s main focus should be.
Controller logic can be configured to deal with such situations, but this involves extra
engineering costs, and has long-term maintenance risks.
DAS is specifically designed to handle this problem in a clear, documented way. It is similar
to “contact cutout” in TPS in that it operates independently of other alarm suppression
mechanisms, such as disable and journal-only, which may be manipulated by ACM or by
sequences. But it is superior to contact cutout in its flexibility; and it is superior to both contact
cutout and controller logic in operator presentation, logging, and documentation. In most
cases, DAS can replace the controller logic which may have been configured to meet this
need. However, it is recommended that DAS strategies remain simple and straightforward. In
more complex cases, controller logic may be used together with DAS to provide the optimal
solution. For instance, controller side suppression logic may be useful where sequence of
events is deemed important and there is a delay between the reading of the value and alarm
generation, as sometimes happens with some server-generated SCADA alarms.
Dealing with alarms resulting from other factors
No matter how much engineering goes into the alarm system, there will always be the
potential for alarms that, for a short period of time, are not relevant to an operator, and that the
operator would therefore like to hide from the primary alarm summary. Such alarms could be
due to a range of factors such as those outlined above, and might relate to alarm situations that
have not been completely addressed by the alarm design process. Or they could arise in
situations where the operator has taken appropriate action, and the process is recovering, but
alarms are not expected to return to normal for some time.
Experion alarm shelving is designed to handle these cases directly, by allowing the operator
to shelve alarms (that is, temporarily place selected alarms on the “alarm shelf” off the main
display), but allowing these alarms to be quickly and easily called up for reference and
crosschecking.
Dynamic Alarm Suppression
Dynamic Alarm Suppression (DAS) is an Experion license option that provides an automated
way of temporarily removing alarms from the default (unfiltered) view of the Alarm
Summary. Alarms are removed in accordance with a set of rules that you configure.
By temporarily removing specific alarms from the Alarm Summary when pre-configured
conditions are met, DAS helps operators to focus on the issue at hand or on other more
critical conditions in the plant.
Honeywell 2017 88
Page 89
Alarms and events
DAS is primarily intended to help operators deal with high-alarm situations like trips where
multiple alarms related to the same event are triggered in quick succession. It can therefore be
a useful strategy for dealing with “downstream” alarms resulting from equipment trips (or
even unit shutdowns or startups). For example, if a pump shuts down or a compressor trips,
you might want to use DAS to automatically suppress any consequential low-flow (or lowpressure) alarms.
Although suppressed alarms are hidden from the default (unfiltered) view of the Alarm
Summary, the number of alarms currently suppressed is shown in the summary statistics at the
bottom of the Alarm Summary, and operators can use the (suppressed alarms) view to see
which alarms are currently suppressed.
DAS can be used for alarms on any of the following point types: CDA, SCADA, DSA, point
server, or third-party OPC.
Attention:
DAS should only be used to suppress alarms that are of no direct operational
relevance to operators and that do not require an operator response at the time.
Before implementing DAS it is very important that you read the alarm design and
application guidelines in the Server and Client Planning Guide as well as the
configuration guidelines and scenarios in the Server and Client Configuration
Guide.
Planning and application guidelines for Dynamic Alarm Suppression
Dynamic Alarm Suppression (DAS) is an advanced form of alarm management that should
be designed, implemented and tested by appropriate individuals such as the engineers who are
responsible for the equipment in question.
Before designing, implementing or modifying an alarm system, it is recommended that
engineers familiarize themselves with industry standards such as the EEMUA’s Publication
191 Alarm Systems: A Guide to Design, Management and Procurement, the ASM
Consortium's guideline Effective Alarm Management Practices, and the ISA-18.2 standard
Management of Alarm Systems for the Process Industries.
When planning your system, bear in mind the following:
n
As a general principle, keep your DAS strategy simple and conservative to ensure that
important alarms requiring operator attention are not inadvertently suppressed.
n
A well-designed and well-managed alarm system is an important precondition for alarm
suppression. It is therefore strongly recommended that, before implementing DAS,
sites:
Honeywell 2017 89
Page 90
Alarms and events
n
n
l
Rationalize alarms and reduce duplication as much as possible.
l
Implement management of change (MOC) for the alarm system. This is particularly
important to ensure that a site’s alarm suppression strategy is taken into account
when, for example, equipment is changed or out for maintenance, or when systems
are running in a mode other than the original design.
In the absence of formalized MOC, it is important to have comprehensive and accurate
documentation in place to ensure that subsequent changes in equipment and control
strategy do not result in unforeseen (and potentially hazardous) consequences.
Consider using DAS in conjunction with mode-based alarming using a tool like Alarm
Configuration Manager (ACM). While mode-based alarming is not fast enough to deal
with suppression, it can be effective for managing alarms under controlled scenarios
like when bringing a unit back into service. (Note, however, that care needs to be taken
when bringing a unit back into service as removing suppression too early could lead to
alarm floods.)
For example, you could use ACM to define an out-of-service or shutdown mode that
sets journal-only and other alarm attributes to ensure that any noise on the triggering
signals during maintenance or repair does not translate to alarms. You could also use
ACM to suspend enforcement on related tags, thereby allowing temporary changes
such as the disabling of alarms.
n
DAS is best suited for dealing with trips in small units or in fairly distinct equipment. If
you want to use DAS for dealing with large scale unit or plant trips, create low-level
(that is smaller and thus more easily managed) alarm suppression groups that can
operate independently on individual units within the larger unit or plant.
n
Although DAS could be used to manage alarm annunciation during planned
shutdowns or startups, changes to known plant states are better addressed with ACM.
n
If your site currently uses controller logic, contact cutout, or other mechanisms to
achieve suppression or shelving functionality, you might want to consider the
advantages of using Experion DAS or Experion alarm shelving. Before making any
significant change to your current alarm system, it is of course always important to
consider the impact of such a change on operators.
Alarm and alert shelving
Alarm shelving is a form of manual suppression that enables operators to remove individual
alarms from the main alarm summary display for a limited time.
Shelving is typically used by operators to hide “nuisance” alarms that are distracting them
from other more important alarms. Although multiple alarms can be shelved at the same time,
you can only shelve one alarm at a time.
Alarm shelving is most suitable for the following situations and scenarios:
Honeywell 2017 90
Page 91
Alarms and events
n
n
n
Operators can shelve alerts as well as alarms. The following information about alarm shelving
also applies to alerts.
How alarm and alert shelving works
n
Dealing with stale or standing alarms such as those arising from instrument malfunction
or faulty equipment awaiting repair.
Background or nuisance alarms such as those arising from unusual weather conditions.
Dealing with alarms that require action that may take time. For example, an operator
may need to change a temperature set point for a process that takes two hours to effect
the change. In a case like this, operators can shelve the alarm for two hours, knowing
that if the alarm is re-annunciated after that time, there is still a problem that needs to be
addressed.
When an alarm is shelved, Experion automatically:
l
Acknowledges the alarm
l
Silences the alarm
n
While alarms are shelved they can be viewed by using the (shelved alarms) view on
the Alarm Summary or by choosing one of the filters on the Alarm Icon column that
show shelved or hidden alarms.
n
Depending on how shelving has been configured at a given site, shelved alarms
generally do not reappear in the Alarm Summary until their shelving period expires or
they are manually unshelved.
n
If an alarm returns to normal while it is shelved, it remains shelved until its shelving
period elapses or it is unshelved by the operator. When such an alarm is unshelved it
automatically disappears from the alarm summary.
n
If an alarm recurs while it is shelved, the alarm remains shelved and also remains
acknowledged and silenced.
For more information about alarm shelving, see the “Configuring alarm shelving” topic in the
“Configuring alarms, alerts, and messages” section of the Station Configuration Guide.
What happens when a shelved alarm is suppressed?
If an alarm is either shelved or suppressed, it is hidden from the default view of the Alarm
Summary. Note thatshelved alarm messages are still shown on the Message Summary.
Information about the shelved state of an alarm is maintained independently of information
about the suppression state of an alarm. However, where an alarm is both shelved and
suppressed, information about the suppression state of an alarm is considered to be more
important (or of greater interest) than information about its shelving state. For example, in the
Honeywell 2017 91
Page 92
Alarms and events
display of alarm counts and alarm state icons on a custom display, information about an
alarm’s suppression state takes precedence over information about its suppression state. See
the following scenario for more about the precedence of suppression over shelving.
The following scenario illustrates what happens when an alarm on POINTA01 has been
defined as a “target alarm” in the suppression group SG01, and that alarm is currently shelved
when suppression group SG01 is activated.
n The alarm remains shelved until the shelving period expires (or until the alarm is manu-
n On the Alarm Summary, the alarm:
ally unshelved).
l Is included in both the (suppressed alarms) and (shelved alarms) view. If the
alarm is unshelved while the suppression group is still active, it is removed from the
(shelved alarms) view but stays in the (suppressed alarms) view until the sup-
pression group is deactivated.
l Shows the Suppressed icon (rather than the Shelved icon) in the alarm icon
column.
l Is included in the Suppressed count (but not the Shelved count) in the alarm stat-
istics at the bottom of the Alarm Summary.
n On custom graphics:
l If there is only one alarm condition currently existing on a point, and that condition
is both shelved and suppressed:
l The point alarm state shows the Suppressed icon.
l The alarm is included in the Suppressed alarms count (but not the Shelved alarms
count) on the point.
l
If there are two alarm conditions currently existing on a point, one shelved and one
suppressed, the point
alarm state shows the Shelved icon.
n On the location pane of the Alarm Summary, the Tool Tip for the asset alarm count:
l Does not show the Suppressed count or the Suppressed icon even if the only
nonzero alarm count is the Suppressed alarms count
l Shows the Shelved count and the Shelved icon if a shelved alarm is the most import-
ant alarm on that asset.
Alarm prioritization
It is essential that alarms are correctly prioritized so that operators are able to respond to
alarms in a systematic manner. You therefore need to formulate a set of guidelines so that
Honeywell 2017 92
Page 93
Alarms and events
commissioning engineers assign the correct priority to each alarm condition. You also need to
take into account 'cascading alarm' scenarios—for example, if a pump failure results in a
pressure drop, the pump failure alarm requires a higher priority than the pressure alarm.
Experion prioritizes alarms at two levels:
n
n
Note that if critical alarm support is enabled, urgent priority alarms with a sub priority of 15
will be shown as critical priority alarms on the Alarm Summary and other displays. For
information about how to enable critical alarms, see “Customizing alarm colors” in the Station
Configuration Guide.
All alarms, except Journal, appear in the Alarm Summary and are therefore responded to by
operators. All alarms, including Journal, are written to the event journal.
System alarms are assigned a Honeywell default priority and sub-priority. These can be
adjusted at the server cluster level as required. For more information, see “Configuring system
alarm priorities” in the Station Configuration Guide.
Priority. The priorities are: Urgent, High, Low and Journal (the default)
Sub-priority. These range from 15 (highest) to 0 (lowest)
Views
You can improve alarm management by creating appropriate views for operators. (A view
shows a particular subset of alarms, and presents the details in a particular way.) The
following figure, for example, shows an Alarm Summary that only lists urgent alarms. Note
that when a filter has been applied to the Alarm Summary, the (Filter applied) indication
appears to the left of the Clear All Filters button. For more information see the topic
“Creating a view of a summary display” in the Station Configuration Guide.
It is also possible to restrict the system alarms that are displayed, by selecting the minimum
system alarm priority to be visible to the operator, console, Console Station, or Flex Station.
Honeywell 2017 93
Page 94
Alarms and events
A typical Alarm Summary display
Alarm annunciation
Although alarms appear in Station, you need to consider your alarm annunciation needs.
Experion provides the following types of alarm annunciation:
n
Station-based buzzer or speaker
n
External horn or siren
Station-based buzzer or speaker
Audible alarm notification is appropriate for Stations used by operators; however, it may not
be appropriate for Stations used by production controllers and managers.
You can specify the system-wide characteristics of alarm notification, such as the duration of
the sound, and the frequency at which the sound repeats if an alarm is not acknowledged.
You can also disable audible alarming on particular Stations, as appropriate.
Honeywell 2017 94
Page 95
Alarms and events
External horn or siren
If there is a possibility that users may not hear a Station buzzer/speaker, you should consider
installing one or more horns or sirens.
You can configure up to fivealarm notification points—one each for Critical, Urgent, High,
Low or Any alarm priority—to control horns or sirens. For example, you could use the
Urgent point to control a horn, and use the Any point to control a buzzer.
Alarm groups
Alarm groups provide you with an alternative way of viewing alarms, which is not related to
your asset model. For example, you could create an alarm group to monitor alarms on all
electrical motors in your plant, regardless of their locations within the asset model. Unless
stated otherwise, the configuration and usage of system alarm groups is the same as alarm
groups. However, system alarm groups can only include system points and other system
alarm groups.
Alarm groups provide the following major benefits:
n
They provide additional filtering capabilities in the Alarm Summary or System Status
display for system alarm groups.
n
They provide aggregate alarming—that is, at each level of an alarm group, you can
see the number of alarms that exist at that level.
n
They allow you to include aggregate alarming parameters in custom displays, so that
operators can quickly see how many alarms there are in each section of the plant.
n
System Alarm Groups can be used to create a hierarchy of dashboards for the System
Status display. For more information, see “Creating a dashboard hierarchy for the
System Status display” in the HMIWeb Display Building Guide.
For more information about alarm groups, see the “Alarm Groups and Aggregate Alarming”
section of the Station Configuration Guide.
Alarm trackers
Alarm trackers provide a graphical, time-based view of alarms on assets within an operator’s
scope of responsibility. An alarm tracker is displayed in a pane on the Experion Alarm
Summary and provides a convenient way of viewing “clusters” of alarms on individual assets.
By grouping alarms in this way, an alarm tracker helps operators to respond more quickly to
alarms in abnormal situations like alarm floods.
Alarm Tracker is an Experion license option.
Best practice recommendations
If you want to implement alarm trackers at your site, it is strongly recommended that:
Honeywell 2017 95
Page 96
Alarms and events
n
n
For information about configuring alarm trackers and assigning an alarm tracker to operators,
Stations, Consoles, or Console Stations, see “Configuring alarm trackers” in the Station
Configuration Guide.
An example of an Alarm Tracker pane in the Alarm Summary
Operators use the Alarm Summary with the Alarm Tracker pane as their primary
display for an extended period to ensure that they are well experienced in using alarm
tracker features in a normal situation before they use it during a major process upset.
You rationalize the alarm system at your site to ensure that alarm-related displays
(especially the Alarm Summary and the Alarm Tracker pane) do not contain more
alarms than necessary. For information about alarm design and alarm rationalization,
see “Designing alarm systems” in the Station Planning Guide.
Alerts
Alerts are notifications whose urgency and priority are not high enough to be alarms.
There are several types of alerts:
Honeywell 2017 96
Page 97
Alarms and events
n
n
n
Alerts are incorporated into Experion from a third-party user alert application using a URT
connection. For more information, see the “Configuring alerts” section of the Station
Configuration Guide.
Interactive Instruction alerts, which can be generated by C300 controllers and ACE to
indicate to operators that there are tasks that they must complete so that a sequential
control module can continue executing. These types of alerts are configured when the
sequential control module is configured. For more information on sequential control
modules and alerts, see the Sequential Control User's Guide.
User-generated alerts, which can be used, for example, as a reminder to an operator to
schedule maintenance for a piece of equipment.
System-generated alerts, which are notifications of an abnormal condition in the system
that could cause problems if the condition is not fixed.
For example, the gas pressure in Pipe A has been rising steadily over the last couple of
days, most probably due to a build-up of waste particles on the inner lining. This is
leading to a degradation in process performance. An alert is raised to indicate that pipe
cleaning must take place in the next week.
Messages
Messages can be generated to provide additional information to an operator, for example
when a point goes into alarm, a message can provide an explanatory note or a procedure.
There are four types of messages:
n
Informational
n
Confirmable (available if you have Process Controllers)
n
Single signature (available if you have Process Controllers)
n
Double signature (available if you have Process Controllers)
Informational messages are defined in:
n
Configuration Studio if you have standard points.
n
Control Builder if you have process points.
Confirmable messages are configured in Control Builder.
Single signature and double signature messages are configured in Control Builder.
For status, analog, and accumulator points you can specify a predefined message to be
displayed in the Message Summary when the point goes into alarm.
Each Station displays the message text defined on its local server. If you have a DSA system,
the message indexes and text should be the same on all servers to ensure that appropriate
messages are displayed for remote points.
Honeywell 2017 97
Page 98
Alarms and events
Events
An event is a significant change in the status of an element of the system such as a point or
piece of hardware. Examples of events are the occurrence of an alarm, an alarm returning to
normal, an operator signing on, and a batch process starting.
Event details, which include the source of the event, the condition and a timestamp, can be
viewed on displays and included in reports.
Events are initially collected in a system database, and are periodically copied to a Microsoft
SQL Server online event database for queries and reporting. The events are kept in database
for a specified period, after which they are deleted.
Event storage and archiving
If you want to retain events for more than a few weeks, you need to use Event Archiving to
configure:
n
n
How long events are kept online
How often events are archived
Event Archiving allows you set up automatic archiving, or to configure an alarm which alerts
the operator to archive events at appropriate intervals. Event Archiving enables you to archive
events to a network file server or to tape. Archiving to tape uses the Windows Backup
program. Events archived to a network file server can be copied to other media such as CD,
or included in a system backup.
For more information about Event Archiving, see the “Configuring Event Archiving” section
of the Station Configuration Guide.
Honeywell 2017 98
Page 99
Displays
Displays
This section describes how to determine your display requirements.
Issue Comments
Experion includes a comprehensive set of system displays, which display
System displays
Tabbed displays
Custom displays
information in a standardized manner.
Some system displays, such as groups and trends, require configuration.
Decide whether you want to enable tabbed displays in Station. With
tabbed displays operators can have multiple displays open. Tabbed displays in Station work in a similar way to tabbed displays in Microsoft Internet Explorer.
Decide whether you want to create your own (custom) displays. Well
designed custom displays make it much easier for operators to interpret
system activity and to run your plant in an efficient manner.
Custom faceplates
Web pages and other
documents
Update rates You need to select an appropriate update rate for each Station.
If you have custom points, consider creating your own (custom) faceplates
to present point data in a manner that is easy for operators to understand.
Station can display Web pages and ActiveX documents, such as Microsoft
Word and Microsoft Excel documents. You can also embed Web pages
and ActiveX documents in custom displays.
System displays
The system displays that you can call up in Configuration Studio are used to configure items
such as reports, group displays, trends, alarm trackers, Station settings, Console Stations, and
so on.
The procedures for configuring these items are documented in the Station Configuration
Guide.
Tabbed displays
Tabbed displays are an optional server wide setting.
With tabbed displays, operators can call up displays in individual tabs within a Station
window. Whenever they call up a display, operators can choose to open it in an existing tab
or in a new tab.
An example of Station with tabbed displays enabled.
Honeywell 2017 99
Page 100
Displays
After opening displays in individual tabs, operators can quickly move between displays by
clicking on the tab of the display they want to view. This is particularly useful when operators
are dealing with alarm floods or other urgent alarm situations.
The tab of a point detail display and any custom display that is associated with an alarm
group, shows an alarm icon representing the “most important” alarm on that display. This
means that operators can keep track of alarms even on displays that are not currently on view.
Custom displays
You can make it much easier for operators to interpret and control system activity if you
create suitable custom displays.
Custom displays are created using HMIWeb Display Builder, a specialized drawing tool,
which is supplied with several clip art libraries that cover a range of industries. For example,
the clip art libraries include representations of pumps, valves, and so on.
With custom displays, you can insert your own graphics (for example, photographs and
layout diagrams) using any of the following formats.
n GIF (.gif)
n Wimdows Bitmap (.bmp)
n JPEG (.jpg)
n Metafile (.wmf)
n Portable Network Graphic (.png)
The following figure shows a typical custom display created using HMIWeb Display Builder.
Honeywell 2017 100
Loading...