0% found this document useful (0 votes)
883 views84 pages

Migration Planning Guide

Migration Planning Guide

Uploaded by

beerman81
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
883 views84 pages

Migration Planning Guide

Migration Planning Guide

Uploaded by

beerman81
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 84

EXPERION PKS

RELEASE 516

R511 Migration Planning Guide


EPDOC-XX70-en-516A
August 2020
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 2020 - Honeywell International Sàrl

-2-
Contents 3
Chapter 1 - About this guide 7
1.5 Related documents 8
1.6 Special terms 9
1.7 Before you begin 11
Chapter 2 - Experion migration concepts 12
2.7 Migration license requirements 14
2.8 About the migration tools 15
2.8.1 Overview of Upgrade Tool 15

2.8.2 Migration Readiness tool 15


2.8.3 ERDB Consistency Checker 15
2.8.4 BOOTP Checker 16

2.8.5 Install Sequencer 16


2.8.6 Controller Migration wizard 16

2.9 Dual primary state 16


2.9.1 History collection during dual primary state 16

2.10 About OPC Integrator, script engines, and SCADA channels 17


2.11 Migrating custom displays 17
2.11.1 Migrating Display Builder displays 17

2.11.2 Migrating HMIWeb displays 18


2.11.3 Updating the HMIWeb solutions pack 18
2.11.4 Migrating trends 18

2.12 Excel data exchange 19


Chapter 3 - System interoperability concepts 20
3.1 Interoperability 20
3.2 Server interoperability 21
3.3 eServer interoperability 22
3.4 Domain controller interoperability 22
3.5 BOOTP server interoperability 22
3.6 DSA and OPC interoperability 22
3.7 Controller interoperability 22
3.7.1 Controller CDA/exchange peer-to-peer connections 23

3.8 Configuration Studio interoperability 23


3.8.1 Using Configuration Studio during server migration (dual primary state) 24

-3-
3.8.2 Using Configuration Studio during multi-cluster migration 24
3.8.3 Saving and rebuilding checkpoints 24
3.8.4 Using the Search utility 24

3.8.5 Using Display Builder and HMIWeb Display Builder 24

3.9 Station interoperability 25


3.9.1 Displays 25
3.9.2 Network Detail displays 25

3.10 Enterprise Model Database (EMDB) interoperability 25


3.11 Inter and intra cluster interoperability 25
Chapter 4 - Planning migrations 27
4.1 Develop a migration plan 27
4.1.1 Considerations while migrating non-redundant Experion systems and control
components 28

4.1.2 Considerations for migrating network-API based customer applications 28


4.1.3 Migration Planning Checklist 28

4.2 Develop a migration strategy 30


4.2.1 System migration planning 30

4.2.2 Cluster migration planning 30


4.2.3 State of the process 31
4.2.4 Network topology considerations 31

4.3 Develop a migration timetable 31


4.3.1 Migration time estimates 32

4.4 Review software requirements 33


4.4.1 Migrating other Honeywell products and applications 34
4.4.2 Migrating non-Experion third-party applications 34

4.5 Review hardware requirements 35


4.6 Choose whether to use Experion Software Installation Server
(ESIS) 35
4.7 About Experion Migration Storage Node (EMSN) 36
4.7.1 Identify a location for the EMSN 37
4.7.2 Considerations for using EMSN hosted in a domain 37

4.8 Considerations for planning network topology changes 38


4.9 Review migration considerations 38
4.9.1 Considerations for migrating integrated Experion-TPS nodes 38
4.9.2 Considerations for migrating DSA-connected Experion/TPN systems 39

4.9.3 Considerations for migrating secured Experion nodes 39

-4-
4.9.4 Considerations for multi-cluster migrations 39
4.9.5 Considerations for partitioning hard drives using Experion PKS System
Initialization media 40
4.9.6 About pre-installed SQL scenario 42

4.10 Planning time synchronization during migration 42


4.10.1 NTP servers (time source for Series C control hardware) 42
4.10.2 Time check on system before you start migration 42

4.11 Identify security policy changes 43


4.11.1 Installing the domain controller package 43
4.11.2 Workstation package 44

4.12 Cancelling a migration 45


4.12.1 On-process migration of servers/clients 45
4.12.2 Off-process migration of servers/clients 46

4.12.3 On-process migration of controllers 46


4.12.4 Off-process migration of controllers 46

Chapter 5 - Starting migration 47


5.1 Selecting a migration path 47
5.1.1 On-process migration of servers/clients 47
5.1.2 On-process migration of controllers 47

5.2 Migration scenarios 48


5.2.1 Server/client migration scenarios 48

5.2.2 Controller migration scenarios 48


5.2.3 migration 50

Chapter 6 - Using tools to verify upgrade readiness 51


Chapter 7 - migration reference 52
7.1 Qualified migration paths 52
7.1.1 server/client migration paths 52
7.1.2 controller migration paths 53

7.2 system interoperability 53


7.2.1 Interoperability summary 54

7.3 Software requirements 58


7.3.1 Software media requirements 58
7.3.2 Microsoft and other Experion updates 59
7.3.3 Reapplying software patches on servers 59
7.3.4 Total Plant Network (TPN) software 60

7.3.5 Honeywell Experion PKS Localization Media 61

-5-
7.3.6 SCADA system communication protocols 61

7.4 Hardware requirements 61


7.5 Experion installation space requirements 62
7.6 Experion migration space requirements 64
7.7 Experion Migration Storage Node (EMSN) space requirements 65
7.8 Multi-cluster migration scenarios 66
7.8.1 systems 66

7.9 Experion High Security Policy changes 67


Chapter 8 - Migration Planning Checklist Collection 68
8.1 System questions 68
8.1.1 Checklist 1 - Experion and Windows Software 71
8.1.2 Checklist 2 - Other Honeywell software 72

8.1.3 Checklist 3 - Third Party software 73


8.1.4 Checklist 4 - System architecture guidelines 73
8.1.5 Checklist 5 - Cluster and node sequence questions 74

8.1.6 Checklist 6 - Server specification sheet 75


8.1.7 Checklist 7 - Station specification sheet 77
8.1.8 Checklist 8 - Domain Controller specification sheet 79

8.1.9 Checklist 9 - Controller 80

-6-
CHAPTER

1 ABOUT THIS GUIDE

The Experion Migration Planning Guide assists you in understanding and planning the migration of
your Experion system. Specifically, this guide provides information and guidance for migrating
Experion systems from .
Experion supports the migration of LCN nodes to Experion LCN nodes.
For exact migration paths supported to target point release, refer to the latest target point release
Software Change Notice (SCN). For example, refer to the latest target release SCN.

1.1 Revision history


Version Date Description
A August 2020 Initial release of the document.

1.2 Prerequisite skills


It is assumed that you are familiar with the operation of Experion system software and the plant
processes which Experion controls, Microsoft Windows operating systems, and network administration
tasks.

1.3 Intended audience


This guide is intended for people who are responsible for planning, administering, and operating the
Experion system and the process which it controls. These people may include Plant Managers,
Process Engineers, and System Administrators.

1.4 How to use this guide?


This guide is organized into the following sections.

Topic Description
Experion Defines Experion migration, server migration, controller migration, qualified
migration migration paths and the applications, and tools developed to automate various
concepts tasks for migration.
System Introduces the concept of interoperability within the Experion system. Specific rules
interoperability for release interoperability and the restrictions of interoperability between system
concepts functions are described.
Planning Contains important planning information and topics that require consideration by
migrations users while planning to conduct on-process or off-process migrations.
Starting migration Provides information about the starting point for conducting a migration and
presents typical migration scenarios.

-7-
Chapter 1 - About this guide

Topic Description
Using tools to Defines the Migration Readiness tool and Upgrade tool. In addition, the reports
verify upgrade generated using the Migration Readiness tool and Upgrade tool.
readiness
R501.x migration Provides release specific reference content for planning migration.
reference
Migration Contains all the checklists that may be required while performing migration.
Planning
Checklist
Collection

1.5 Related documents


The following documents and sources contain additional information related to installation, upgrade,
and migration of Experion system software and firmware. It is recommended to have these documents
readily available for reference.
l Software Change Notices (SCN): The Software Change Notice provides information about new
features, problems resolved, known issues, software component versions, and firmware revisions
for a release/point release. In addition, the document also contains important changes from
previous release, special considerations in installation or migration, and any last-minute
documentation updates. Although the SCN is provided in printed form, you must always download
the latest version of the SCN from the Honeywell Process Solutions website
(https://www.honeywellprocess.com/support). The following are the three types of SCNs.
o Experion General Release Software Change Notice
o Experion Support Software - Software Change Notice
o Experion Point Release Software Change Notice

l Site-specific migration guides ( to ): For migrations from R410.x onwards, you can generate a site-
specific migration guide using the Upgrade Tool. As per the site configuration, the Upgrade Tool
combines the migration guides available on the Experion PKS Upgrade Tool components media for
the nodes/modules in the Experion cluster. This document is automatically generated by the
Upgrade Tool.

l The latest point release Experion PKS Upgrade Tool components media(Upgrade_Tool_
Components_media.iso) is available as an ISO image on Honeywell Process Solutions website
(https://www.honeywellprocess.com/support). Extract this ISO image using ISO extraction software
to create a DVD or copy the extracted files to local system and install the latest Experion PKS
Upgrade Tool components media. For example, you can use Virtual Clone Drive software for
extracting the contents to a media.
l If you are migrating to any point releases, refer to the applicable point release SCN.
l Experion Upgrade Tool User's Guide : This guide describes the procedures to install and configure
the Upgrade Tool.
l Experion Upgrade Tool Component media Software Change Notice : This Software Change Notice
contains information about Experion PKS Upgrade Tool Components media.
l Getting Started with Experion Software Guide : This document details the prerequisites and specific
tasks required to set up the Experion system. You can also use the document as a reference when
you add new components to your system.
l Experion Software Installation User's Guide (SIUG): This document guides you through the standard
Experion software installation. The SIUG is available in the .
l Experion Supplementary Installation Tasks Guide (SITG): This document describes the additional
tasks to be performed once you have completed an initial installation or upgrade of Experion. This
document is available in the .
l Control Hardware and I/O Module Firmware Upgrade Guide

-8-
Chapter 1 - About this guide

l Integrated Experion-TPS Nodes (ES-T, ESVT, & ACE-T) User's Guide : This document describes
supplementary installation tasks that must be done before you use T-Nodes on an Experion system.
In addition, it describes configuration tasks necessary for T-Nodes. This document is available in the
.
l ELCN Overview and Implementation Guide: This document provides an overview of the items to
consider when installing the Experion LCN and procedures for migrating LCN nodes to Experion
LCN.
l OneWireless Guides: For more information on OneWireless integration with Experion, refer to the
Experion PKS OneWireless Migration User's Guide and Experion PKS OneWireless Integration
User’s Guide available in the HPS Support website.
l ELCN Overview and Implementation Guide: This document provides the information required for
migrating your system from Classic T-Nodes using LCNP4 cards or ETN Nodes to ELCN based T-
Nodes.

1.6 Special terms


The following terms defined here are unique to the subject presented in this guide. Unless specifically
noted, the term “Migration” pertains to both on-process migration and off-process migration.

Base release
The release version of Experion that is currently in use before the start of a migration.

Controller Migration wizard


A software application which migrates process controllers and associated control hardware
to the newer release firmware with minimal user action.

Dual Primary Server state


A state during on-process migration where each server of a redundant pair operates as a
primary server. Dual primary state allows the checkout and verification of the process using
the new release software.

Engineering Repository Database (ERDB)


The database or set of databases which support the control system development.

Enterprise Model
A hierarchical representation of the Experion system components, the plant's assets and the
alarm groups derived from the assets, and alarm groups defined in the EMDB.

Enterprise Model Database (EMDB)


A database that contains the source descriptions of the plant's assets and alarm groups used
in the Enterprise Model.

ERDB Consistency Checker


Engineering Repository Database Consistency Checker. A tool to validate the internal
consistency of the ERDB.

Experion Control Cluster (Cluster)


An operational unit of an Experion control system consisting of Experion server or redundant
server pair, associated clients (Flex Stations, Consoles, and Extended Stations), controllers,
and optional other nodes, such as ACE, EHG, PHD, terminal server, and eServer.

Installation Application

-9-
Chapter 1 - About this guide

A software application that installs the Experion system software with minimal user action.

Mismatched component
Any component that is installed with or is running at a release other than the target system
release.

Install Sequencer
A software wizard which migrates Experion system components to the newer release system
software.

Experion Migration Storage Node (EMSN)


A location used for storing data (databases, system configuration, operating system
preferences, and so on) when migrating an Experion platform.

Migration Readiness Tool (MRT)


An software wizard that performs checks on servers, controllers, and other system
components to verify if they are ready for migration.

Off-Process Migration
Migration of an Experion control system or migration of an Experion system component
while it is not controlling the process and there is no view of the process. NOTE: Integrated
Experion-TPS nodes can maintain view to the process through TPN while the Experion off-
process migration is in progress.

On-Process Migration (OPM)


Migration of an Experion control system or migration of an Experion system component
while maintaining view and control of the process. This is achieved by utilizing redundant
system components.

Redundant Chassis Pair (RCP)


A pair of modules, such as two FIMs, IOLIMs or other chassis I/O modules that support
redundancy, each installed in redundant chassis (Primary and Secondary).

Release interoperability
The ability of system components to interact in a stable manner when operating with different
releases.

Supervisory Control And Data Acquisition (SCADA)


SCADA is an Experion application for process control. It is designed to interface with serial
devices such as PLCs and Honeywell TPS.

Server A and Server B


The standardized names of the redundant servers. Server A operates as primary before the
start of on-process migration, and Server B operates as the backup.

System migration
The migration of Experion control system from one release to a newer release.

Target release
The release version of the system software or firmware after migration is completed.

- 10 -
Chapter 1 - About this guide

1.7 Before you begin


Experion contains substantial infrastructure that supports the migration from one release to another,
while still maintaining process control. However, on-process introduces complexity along with beneficial
flexibility.

1.7.1 HPS Migration Center of Excellence/Technical Assistance


Center
The HPS Migration Center of Excellence (COE) or your local Honeywell Technical Assistance Center
(TAC) is set up to handle your questions and requests when planning an Experion system migration.
Contact the HPS Migration Center of Excellence through e-mail [email protected]
or call the Honeywell Technical Assistance Center at 1-800-822-7673, and request assistance when
planning to perform on-process migration of Experion software. The COE helps in planning the activities
and provides expert guidance. Arrangements can also be made to have Honeywell personnel at your
site to assist you with migration.
The COE provides a site survey to be completed along of migration software tools that can be run on the
system to help evaluate the system readiness for migration. You must forward the completed site survey
along with the log files generated as a result of running the migration tools to the COE for evaluation by
the Honeywell engineers. Honeywell can then provide further guidance on the subsequent actions to
be taken in preparing the system for migration.

- 11 -
CHAPTER

2 EXPERION MIGRATION CONCEPTS

Experion system migration is defined as the upgrade of Experion system components, such as
SERVERS, CLIENTS, ESERVERS, ACE, SCE, and SIMIOLIM nodes to the new release system
software. The firmware for I/O control hardware and Experion controller is also upgraded as part of
system migration.
Migration can either be performed on-process, where Experion components are upgraded while
maintaining a view and control of process operations; or off-process, where Experion system
components are taken off-line before they are upgraded to the new software release. On-process
migration can be performed only on redundant Experion components, specifically redundant servers,
controllers, and redundant control modules.
System migration is performed in two major stages.
l Server/client migration (Software migration of Experion servers and clients).
l Controller migration (Firmware migration of Experion process controllers and I/O hardware
components).

2.1 Server/client migration


Server migration is the upgrade of Experion servers, client nodes, and their loaded software. Migration
can include upgrades of the computer's operating system or computer hardware - such as adding more
memory to a server, or even upgrading to a newer computer (platform hardware). Experion server and
client nodes are migrated first, before other Experion nodes, such as eServers, ACE nodes, and
controllers. The Experion Install Sequencer is used for upgrading the Experion servers and clients.
During on-process migration, the migrated servers and clients operate at the target release while the
controllers and other control hardware operate at the base release. This is because the server
migration must be completed before the associated controllers' migration. Interoperability is necessary
between the servers and controllers to maintain system operations.
In systems that contain multiple Experion clusters, interoperability is necessary because clusters may
be migrated individually. During on-process migration it is likely that some clusters operate at a newer
release, while other clusters continue to operate at the older release. Interoperability between these
clusters is maintained through DSA communications during migration.

2.2 Controller migration


Controller migration is the upgrade of firmware installed in Experion control hardware. Only control
hardware that is redundant can be migrated on-process. Non-redundant control hardware can only be
migrated off-process. The Controller Migration wizard application is used for performing controller
migration.
The following is a summary of the Experion control hardware that supports migration.

Experion Control Hardware Comment


Controllers: C200 Controller includes a

- 12 -
Chapter 2 - Experionmigration concepts

Experion Control Hardware Comment


C200/C200e1 (CPM), Redundancy Module (RM) and may
contain any of the following interface
C300 (CC-PCNT01/CC-PCNT02) modules: IOLIM, FIM, FTEB, CNI,
C300 with EHB personality configured LIOM.

Note: Other controllers (such as, TPN controllers) can be


upgraded independently of Experion migration. They are
upgraded using the existing procedures described in TPN
documentation and are not covered in this document.
EHPM can be migrated using Controller Migration Wizard.
Interface Modules: These modules support redundancy
and can be migrated on-process.
RM, IOLIM, FIM, FTEB, CNI, LIOM, Series C FIM4, FIM8 and
PGM.
I/O Modules: These modules support redundancy
and can be migrated on-process.
Series C IOMs
Series A IOMs, Series H IOMs (non-redundant) Non-redundant modules support only
off-process migration.

The Controller Migration wizard is used for migrating process controller firmware and control hardware
firmware. This wizard automates many of the tasks performed during controller migration and is used for
both on-process and off-process migration. It can be accessed from the Controller menu in Control
Builder.
The Controller Migration wizard allows you to select redundant pairs of components for on-process
migration. For example, when a Redundant Chassis Pair is selected for migration, all modules installed
in the primary and secondary chassis are migrated. When a single pair of FIMs installed in a redundant
chassis are selected for migration, both modules are migrated.
Non-redundant I/O components associated with the controllers are migrated off-process; after the
controller and/or after the I/O interface modules are migrated.

2.3 Extended on-process migration support


Prior to R400.1, the on-process migration was supported from an N-1 to N (for example, from R30x to
R31x) releases. With R400.1, OPM is supported from both N-1 and N-2 releases to N (for example, from
R30x to R400.1). This reduces the need for an intermediate update during migration from an N-2
release to N release. .

2.4 Direct migration to point releases


With earlier releases, you were required to migrate the system to the base release (Experion R410.1)
and then upgrade to the required point release Experion R410.2. For more details on server migration
paths, refer to the Supported server migration paths section in the SCN. For more details about
migration, refer to the site-specific migration guides.

ATTENTION
1. This feature is qualified only for R410.1, R430.1, or with point releases on them. For
example, R410.1, R410.2, R410.3, R430.1, R430.2, R430.3, and so on.
2. This feature is qualified if individual server patches or TPN server patches are installed
on the point releases.

- 13 -
Chapter 2 - Experionmigration concepts

3. This new feature does not impact the earlier rule of direct controllers/IOs migrations from
any point release or patch to any target release as mentioned in the site-specific
migration guide and scenario-specific migration guide . For qualified controller migration
paths, refer to the Supported Controller Migration Paths section in the SCN.

2.5 Direct migration support from Controlled Patch Control


Release or hotfix to point release
For , you can directly migrate from CPCR or hotfix to appropriate target point release without
uninstalling or upgrading the patch on the base release. You can directly migrate from R410.x (with or
without hotfixes), R430.x (with or without hotfixes) onwards to , and subsequent releases. For example,
you can migrate from . For more information, refer to the respective latest SCN.

2.6 Spare IO module migration


With R400.1, the spare parts connected to the local chassis and remote chassis for the C200/C200E
controllers can be migrated separately from the Controller Migration wizard.
A new option, off process migration of spare parts in CPM chassis is added to the Controller Migration
wizard. This enables migration of the I/O modules that are connected to a local or remote chassis and
are not configured in the Control Builder (CB). The option can be selected from the available migration
options dialog box in the Controller Migration wizard.
This option is enabled for the following types of configuration.
l Redundant C200/C200E controller with spare parts connected in remote chassis. In the remote
chassis, at least one IO module must be configured in the CB to detect the spare parts.
l Non-redundant C200/C200E controller with spare parts connected to local chassis.
l Non-redundant C200/C200E controller with spare parts connected to remote chassis.
l In the remote chassis, at least one IO module must be configured in the CB to detect the spare
parts.
l Non-redundant C200/C200E controller with spare parts connected to the local chassis and remote
chassis. In the remote chassis, at least one IO module must be connected.

1
Redundant C200/C200e Controllers, which comprise a Redundant Chassis Pair (RCP),
contain identical chassis modules.
l Migration license requirements
l About the migration tools
l Dual primary state
l About OPC Integrator, script engines, and SCADA channels
l Migrating custom displays
l Excel data exchange
2.7 Migration license requirements
Starting with Experion R301.3, the OPM license is combined with the Server Redundancy purchasable
option. When the redundancy option is purchased, both the redundancy and OPM license information
are enabled. Controller redundancy is a secondary requirement which must be satisfied; otherwise, the
OPM option for controller migration is not enabled on the Controller Migration wizard.
Before starting the migration, license key is required.

- 14 -
Chapter 2 - Experionmigration concepts

2.8 About the migration tools


Various software applications and utilities have been developed specifically to help streamline the
system migration process by:
l Detecting system conditions prior to a migration that may cause problems or faults after a migration
begins.
l Detecting inconsistencies in system databases and system components that may cause errors
during migration.
l Automating many of the tasks that are performed during a migration.

l Overview of Upgrade Tool


l Migration Readiness tool
l ERDB Consistency Checker
l BOOTP Checker
l Install Sequencer
l Controller Migration wizard

2.8.1 Overview of Upgrade Tool


The Upgrade Tool checks the upgrade readiness of the nodes and its subsystems in an Experion
system. The Upgrade Tool is installed as a part of the Engineering tools installation. If you have
redundant servers, Upgrade Tool is installed on Server B. In case of non-redundant server, Upgrade
Tool is installed on the only server. The Upgrade Tool does not depend on any specific Experion
topology. In case of a redundant Experion configuration, the Upgrade Tool is run only on the Server B.
In case of a non-redundant Experion server configuration, the Upgrade Tool is run on the single
Experion server node. The Upgrade Tool ensures that it does not overload the Experion server.
Before starting an Experion upgrade, you have to verify the upgrade readiness of the Experion system
and prepare it for the upgrade. The Upgrade Tool automates the manual process of preparing the
Experion system for the upgrade. After the upgrade is complete, you can run the Upgrade Tool to
perform a post-upgrade analysis.
Upgrade Tool makes the upgrade readiness process effortless, easy, and error-free. It reduces the
manual information gathering time and minimizes the possibility of errors.

2.8.2 Migration Readiness tool


The Migration Readiness Tool (MRT) is a software application that performs prerequisite checks on the
system and its components which are necessary to ensure that an Experion system is ready for
migration. The MRT is run to check the migration readiness of servers, controllers, I/O chassis and
remote chassis modules, and control network platforms prior to starting a migration. After the MRT is
run, a report is generated to indicate the readiness of the system and its components for migration. You
can download the latest version of the MRT data files from the Honeywell Process Solutions website at
http://www.honeywellprocess.com. MRT is only used for R31x.x and R400.x Experion releases.

ATTENTION
The MRT is not used for SCADA systems.

2.8.3 ERDB Consistency Checker


The ERDB Consistency Checker utility performs checks on the Engineering Repository Database for
inconsistencies that may cause problems during a migration or cause a migration to fail. This utility also

- 15 -
Chapter 2 - Experionmigration concepts

detects patches that have to be removed before starting the migration. Run this utility before you start a
server migration in order to detect and eliminate problems which might appear during or perhaps even
after the migration. In addition, run this utility before you begin on-process migration of the controllers.
You can download the latest version of this utility from the Honeywell Process Solutions website at
http://www.honeywellprocess.com.
Prior to R430.1, you need run ECC as batch file. Starting from R430.1, ECC is integrated in
Configuration Studio. ECC must be started from Configuration Studio.From R430.1 , ECC also provides
an option to repair the inconsistencies if one or more repair scripts are available and installed for a
failed check.For more information about the integration of ECC in Configuration Studio, see the
Upgrade Tool User's Guide .

2.8.4 BOOTP Checker


The BOOTP Checker utility is used for detecting the BOOTP server on the FTE and ControlNet (through
Ethernet) communications network in a process system. This tool also queries the local database to
verify whether the NTP servers are configured on the local server. Use this tool before a migration, to
check whether there are multiple BOOTP servers configured on the network. There must be only one
BOOTP server running on the control network. If multiple BOOTP servers are running, BOOTP Checker
verifies that they are providing the identical information. You must run the BOOTP checker after
migrating one server and before migrating any controllers. You can download the latest version of this
utility from the Honeywell Process Solutions website at http://www.honeywellprocess.com.

TIP
The BOOTP Checker is not used for SCADA systems.

2.8.5 Install Sequencer


The Install Sequencer is a software application that coordinates the migration of system software to the
target release for servers and clients. The Install Sequencer automates many of the migration tasks that
were performed manually in the previous releases. The application is run on a server/client to be
migrated and it safely handles system database and configuration information so that it can be reloaded
to the server after the new release system software is installed. It also allows for hardware and
operating system upgrades during the migration process.

2.8.6 Controller Migration wizard


The Controller Migration wizard migrates (upgrades) the firmware in Experion control hardware to a
newer release. Experion control hardware includes process controllers, I/O interface components, and
associated I/O modules. The Controller Migration wizard can be accessed from the Control Builder.

2.9 Dual primary state


At one point during server migration, redundant servers which are migrating achieve a dual primary
state, where Server B has been migrated and is operating with the new release, and Server A is
operating with the base release. This state allows each server to operate as a primary and provide a
view of the process. You can perform testing on station and consoles that have been migrated to the
new release, to verify the control and view of the process on the new release.
l History collection during dual primary state

2.9.1 History collection during dual primary state


During dual primary state, the servers are at different releases and are not synchronized. History is
collected by both servers to ensure that there is minimal loss of history data after migration. Also, the

- 16 -
Chapter 2 - Experionmigration concepts

dual primary state allows a user to check the operation of the migrated server on the target release
against the base release primary server before committing to complete the migration. Therefore, dual
primary state is an important condition of on-process migration, which is present for some duration of
time and can be used for verifying the operations of the migrated server.
However, the history collected by both servers may create an increased load on controllers which are
being polled twice as often for the operating data. This could cause an overload on the controllers if the
base load is already near the specification limit. There is also an increase in the network traffic while in
the dual primary state because of the controllers polling twice for the same history data.

2.10 About OPC Integrator, script engines, and SCADA


channels
Experion OPC Integrator normally runs on redundant servers. During on-process migration when
Server B is stopped and is being migrated, OPC Integrator operates on Server A. After Server B is
migrated and is operating with Server A in dual primary state, all groups as well as script engines and
SCADA channels are loaded to Server B, but are disabled. OPC Integrator on Server A continues to
operate. When Server A is stopped to be migrated, the OPC Integrator groups, script engines, and
SCADA channels on Server B must be enabled manually to continue the data transfer, as it does not
happen automatically.

2.11 Migrating custom displays

ATTENTION
Systems that use customized (user-defined) displays created in Display Builder (.dsp files)
and/or HMIWeb Display Builder (.htm files) must follow the important considerations explained in
this section. Not following these recommendations may result in the loss of customized display
files.

Generally, you must back up any file that contains user-defined information, (such as customized
displays) before starting migration. These files may not be migrated forward as part of the migration
process and may need to be reinstalled after migration.
Any custom display files must be manually saved before migration and then restored after migration
because these files may be stored in a user-defined location and may not be migrated forward. For
example, you must back up and save the following files before starting migration.
l Point detail displays such as DI, Numeric, flag, and fieldbus.
l Faceplates such as DI, Numeric, flag, and fieldbus.
l Custom Station setup and menu configurations (*.stn and *.stb files).
l *.css files
l *.htm files

l Migrating Display Builder displays


l Migrating HMIWeb displays
l Updating the HMIWeb solutions pack
l Migrating trends

2.11.1 Migrating Display Builder displays


Custom Displays built using Display Builder (.dsp files) can be available on an upgraded Experion
Station provided that:

- 17 -
Chapter 2 - Experionmigration concepts

l The displays are custom displays (system display interoperability is not supported).
l The references to server data in the custom displays are limited to point parameters and the data in
user tables.

In Display Builder when you save a display (.dsp file), you can specify the display release for the file.
This allows you to save the display in an old format which allows you to use the display file with an older
release of Station. After a display file is updated or saved for a newer release, it cannot be displayed on
a Station operating on an older release.

2.11.2 Migrating HMIWeb displays


You must use either HMIWeb Display Builder or the Bulk Display Migration tool to migrate all custom
HMIWeb displays (.htm files) to the current Experion release.
After you migrate a node to the target release you must use either HMIWeb Display Builder or the Bulk
Display Migration tool to migrate the display files before you can display the custom or user-defined
HMIWeb displays (.htm files) in Station. For example, when a display file (created in an older release) is
opened using a new release of HMIWeb Display Builder, the file is automatically converted to the new
display format by saving the file in the new format. If you want to update the HMIWeb displays in bulk,
you can use the Bulk Display Migration tool (bulkdisplaymigrator.exe).

Related tasks
Migrating HMIWeb Display Builder Faceplates
2.11.3 Updating the HMIWeb solutions pack
HMIWeb Solution Pack (HMIWeb SP) is a comprehensive advanced shapes library designed to allow
customers to implement custom Experion displays consistent with the Abnormal Situation Management
(ASM) Consortium’s display guidelines and the site-specific requirements.
The HMIWeb SP and HMIWeb SP-based graphics can be migrated according the HMIWeb SP
migration instructions. However, the migrated HMIWeb SP shapes are not the same as the HMIWeb SP
shapes. Any new functionality introduced with the HMIWeb SP is not present in the migrated displays.
Any new functionality available with HMIWeb SP can be obtained by replacing the previous shapes with
the HMIWeb SP shapes.
The HMIWeb SP migration instructions, installation guidelines, and the HMIWeb SP is part of Experion
software media kit. Honeywell personnel can download the standard HMIWeb Solution Pack available
at http://teams.honeywell.com/sites/TechOpsKX/GFO/EEx/hmi/Solution%20Libraries/Forms/Solution_
Library_view.aspx.
Starting from R440, HMIWeb Solution Pack installation is integrated with Experion installation. If the
feature is already installed your system, then software is upgraded to a new version as part of Experion
installation.

2.11.4 Migrating trends


Trend object plot numbers in custom displays may not work as expected after migrating the displays, if
you are migrating from a release prior to R300. Prior to R300, trend objects assigned plot IDs, starting
from the number 2. However, after R300 trend objects assign plot IDs from the number 1.
If your display scripts add a plot and then reference the plot using the return plot ID, or if you use the
GetPlotIDFromPlotNumber method on the trendData object, there is no issue with your custom displays.
However, if your scripts directly access a plot, using the plot ID number, you may experience the issue
of the script setting the range of the 2nd plot in the trend instead of the first plot.
Here is an example of a script that directly accesses a plot.
dim xlow, xhigh, ylow, yhigh
chart001.GetPlotVisibleRange 2, ylow, yhigh, xlow, xhigh
chart001.SetPlotVisibleRange 2, 0, 20, xlow, xhigh

- 18 -
Chapter 2 - Experionmigration concepts

This script sets the range of the 2nd plot in the trend (if it exists), rather than the first plot in the trend,
which was the intention of this script when used in systems prior to R300.

2.12 Excel data exchange


If Microsoft Excel is installed, the MS Excel data exchange can be restored to an Experion node either
during or after migration of the node.
Restoring the MS Excel data exchange during migration requires that you install MS Excel and set up
data exchange on the node after the installation or reinstallation of the operating system, and before the
upgrade/installation of the new release of Experion is started.
MS Excel can be installed after migration of the Experion node, but you may encounter errors during the
migration; (just click OK to continue and complete migration). See the section “Setting up Microsoft
Excel reports” in the Supplementary Installation Tasks Guide for the procedure to restore MS Excel data
exchange on an Experion node.

- 19 -
CHAPTER

3 SYSTEM INTEROPERABILITY CONCEPTS

l Interoperability
l Server interoperability
l eServer interoperability
l Domain controller interoperability
l BOOTP server interoperability
l DSA and OPC interoperability
l Controller interoperability
l Configuration Studio interoperability
l Station interoperability
l Enterprise Model Database (EMDB) interoperability
l Inter and intra cluster interoperability

Related concepts
Server interoperability
Controller interoperability
Domain controller interoperability
eServer interoperability
Enterprise Model Database (EMDB) interoperability
Controller CDA/exchange peer-to-peer connections

Related reference
Interoperability summary

3.1 Interoperability
Interoperability is defined as “the ability of system components that are loaded and operating at
different releases of software to be compatible and interact in a stable manner.” For example, a server
which is loaded and operating with Experion software is able to communicate with a process
controller that is operating with Experion R410.x firmware.

3.1.1 Release interoperability


When you perform on-process migration, redundant servers are migrated to the target release first.
Redundant controllers can be migrated later to the target release. There is a period of time when
servers are migrated and are operating with the target release software, and the controllers, which are
not migrated, are operating at the original release (not even the base release from which the servers
migrated). Interoperability is also among controllers and in general between any modules that are
operating on different releases.
Release interoperability may not be necessary when you migrate a system off-process; that is if all
system components are off-line or are migrated before restarting the process.

- 20 -
Chapter 3 - System interoperability concepts

Till R310 release, Experion was supporting only two-way interoperability. Starting from R400.x,
Experion supports three-way interoperability.

3.1.2 Interoperability rules


Release interoperability within Experion systems are governed by a set of rules and restrictions.
l Connection between servers and clients, such as stations, operating at different Experion releases
is not supported. Servers and clients must be operating with the same release to communicate and
operate together. On-process migration begins when you migrate Server B of a redundant server
pair to a new release. Next you must migrate a client to the new release and then connect it to
Server B so that you have a view of the process on Server B which is operating on the new release.
l Servers must be migrated to the new release before all other modules. Servers operating at a
newer release can interoperate with other modules running at an older release; with the exception
of stations. For interoperability, the stations have to be on the same release as the server.
l When the other modules excluding stations are upgraded, the upgraded modules can interoperate
with the server which must already be on the target release. The upgraded modules can also
independently interoperate with the rest of the modules which may be operating on the original
release or on the target release.
l Starting from R400, Experion supports three way interoperability feature. For example,
interoperability is supported if there are servers operating at , the associated ACE node is
operating at R400.3, and controllers operating at R410.x.

3.2 Server interoperability


3.2.1 Server interoperability with server
Interoperability between servers in different control clusters operating on different release software is
supported. This interoperability is supported through DSA and OPC communications. For example, a
DSA Server on Release R431.x, (such as an Experion Server or eServer on R431.1 or R431.2) can
communicate with other DSA Servers or clients operating on Release .

3.2.2 Server interoperability with client


Interoperability is not supported between servers and clients (Flex and Console Station) operating with
different release software. Clients and servers must be operating with the same release software to
support full interoperability. For example, an server cannot connect to and operate with a client
operating with R410 software.

3.2.3 Server interoperability with controller


Interoperability between servers and controllers operating with different release firmware is supported.
All release firmwares that are supported for controller migrations to the target release are also
supported for interoperability with the target release. For the exact releases/point releases/patches from
where a migration is supported to the target release/point release are available in the respective latest
General release SCN or the specific point release SCN .
Here the server release represents all the applications running in a server (such as Control Builder and
real time data cache) that interact with applications running in a controller, (such as CEEs).

Related reference
Interoperability summary

- 21 -
Chapter 3 - System interoperability concepts

Related topics
System interoperability concepts

3.3 eServer interoperability

Related reference
Interoperability summary

Related topics
System interoperability concepts

3.4 Domain controller interoperability


A domain controller (server) used in an Experion system operates as an independent node and is
migrated separately. The interoperability of a domain controller with the Experion server depends on
the operating system of the domain controller.

Related reference
Interoperability summary

Related topics
System interoperability concepts

3.5 BOOTP server interoperability


The BOOTP server must be running on the latest release server of the cluster. You must run the BOOTP
checker before migrating or rebooting any controllers.

3.6 DSA and OPC interoperability


DSA is used for communication between servers. The communication using DSA depends on the
interoperability of the servers on different releases.
OPC is used to access the controller data between clusters. The OPC Integrator running in a cluster can
access controller data in the other clusters through the OPC server in the Experion server. These OPC
connections also depend on the interoperability of the servers on different releases.

The OPC Integrator running in a station, console or Experion server can communicate with internal and
external OPC DA servers using OPC DA versions 1.0a, 2.00, and 2.05a.
OPC Integrator supports interoperability with all OPC servers.

3.7 Controller interoperability


The controllers, communication modules, and simulators can be upgraded in any order. This is
supported by the interoperability between different releases of the following Experion modules.
l C200
l C200E
l C300 (CC-PCNT01/CC-PCNT02)
l C300 with EHB personality configured
l FIM
l FIM4
l FIM8

- 22 -
Chapter 3 - System interoperability concepts

l IOLIM
l LIOM
l ACE
l SIM-C200
l SIM-C200E
l SIM-C300
l SIM-IOLIM
l PGM and C300 20 ms(Turbo Machinery)
l EHPM
l EIP
l EHB
l UOC

Controller CDA/exchange peer-to-peer connections

Related reference
Interoperability summary

Related topics
System interoperability concepts
3.7.1 Controller CDA/exchange peer-to-peer connections
Peer-to-peer controller CDA/exchange between a C200 controller and a later release of a C300
controller works only if the connection is defined (initiated) in the C300 controller.

Related reference
Interoperability summary

Related topics
System interoperability concepts

3.8 Configuration Studio interoperability


Interoperability between a client and server operating on different releases is supported. Using the
Configuration Studio on the client node, you can connect to a server when both server and client are
operating on different releases. However, in such a situation not all tasks are available. For example, an
client can connect to R410 server, but tasks that do not support interoperability are not available.

Starting the Configuration Studio to connect to a system provides only view of the nodes that are
operating with the same release. Choosing the task Configure Process Control Strategies connects to
an ERDB server which is at the same release as the client you are currently using. Refer to the
Enterprise Model Database (EMDB) interoperability section for illustrations on Control Builder
interoperability.
l Using Configuration Studio during server migration (dual primary state)
l Using Configuration Studio during multi-cluster migration
l Saving and rebuilding checkpoints
l Using the Search utility
l Using Display Builder and HMIWeb Display Builder

- 23 -
Chapter 3 - System interoperability concepts

3.8.1 Using Configuration Studio during server migration (dual


primary state)
You can open and use Configuration Studio (CS) during an on-process migration, although there are
some limitations on the tasks that are available to use. These limitations depend on the following:
l The node you are using (Server B or Server A).
l The release currently operating on the node.

The Connect dialog box that appears, when you start the Configuration Studio, displays all the detected
servers, regardless of their release and update levels.

When selecting a task from the list in Configuration Explorer using Server B (which has been migrated
to the target release) during dual primary state, you may receive some error and/or warning messages
indicating that the task is not permitted during OPM. Some tasks in the Configuration Explorer window
are unavailable. You can open and use the Control Builder, the Enterprise Model Builder, and other
engineering tools to verify that the system configuration was migrated successfully and to perform
compatibility tests. However, the databases in the system are read-only. You cannot make any
configuration changes or perform any engineering tasks to the ERDB or EMDB during the on-process
migration.
When using CS on Server A (which is operating with the base release) in dual primary state, warning
messages appear. For example, database is not writeable at this time. Although, you can open and use
Control Builder, Enterprise Model Builder and other engineering tools, messages such as ‘Function not
allowed when connected to secondary database' appear. The ‘read-only’ restriction applies also to the
system databases.
When various applications in CS are open, they indicate that the system is in an OPM status (OPM
appears in yellow on the status line below the application window).
When opening CS and the engineering applications from clients (Console Stations, Flex, and so on.),
the behavior is different. You must connect directly to a server that is on the same release as the client
(and do not connect to the system). A Console Station that is migrated and is now operating on the
target release is similar in behavior to Server B as previously described. Similarly, a Console Station
which is operating on the base release is similar in behavior to Server A as previously described.

3.8.2 Using Configuration Studio during multi-cluster migration


Connection to systems and server on different releases is supported. The Connect dialog box that
appears when you open Configuration Studio displays all the detected servers regardless of their
release and update levels. However, if the client (which is used for connecting to the server) and the
server are operating on different releases, not all tasks are available.

3.8.3 Saving and rebuilding checkpoints


The checkpoint rebuild and manual checkpoint save operations are performed for the various controller
nodes during server dual primary state in OPM.
The format of checkpoint files in a given release of Experion is unique, so that the checkpoint files of
one release are not compatible with other Experion releases. For example, R410.1 checkpoint files are
not compatible with Experion Release and vice versa.

3.8.4 Using the Search utility


Starting the Search utility in Configuration Studio (Determine where an object is used in the system
(Where Used)) searches only the ERDBs and/or EMDBs which are at the same release and update
level.

3.8.5 Using Display Builder and HMIWeb Display Builder


If a user modifies displays on the base release in Server A, the changes are lost once the server

- 24 -
Chapter 3 - System interoperability concepts

migration is complete. When the Server A is upgraded and synchronized with Server B, the modified
displays are overwritten with the original displays in Server B.

3.9 Station interoperability


l Displays
l Network Detail displays

3.9.1 Displays
The displays in cluster can access controller data at any release level in any cluster in the system. The
intercluster communication is through DSA.
During the dual primary state, some clients (Flex stations, console stations, and console extensions) are
on target release and connected to Server B, and some clients which are still on the base release are
connected to Server A.
After dual primary and before Server A migration all the clients must be migrated to the target release.

3.9.2 Network Detail displays


Network Detail displays and faceplates accessed in Station provide information gathered from
computers, switches, FTE devices, and Control Firewalls through the System Performance Server (SPS)
on the monitoring server. The monitoring server association is defined using the Configuration Studio
Network Tree - Assign Monitoring Server task.

3.10 Enterprise Model Database (EMDB) interoperability


Starting Configuration Studio to connect to the system provides view of the nodes which are at the same
release. Choosing the task ‘Configure Assets or Alarm Groups for this system’ starts the Enterprise
Model Builder (EMB) application and connects to the EMDB server which is at the same release and
update level as the client you are currently using.
Some functions are disabled during migration. For example, the EMDB (and ERDB) are locked to
prevent any changes until migration is completed. Additionally, features which are available in newer
releases are not available on nodes operating at earlier releases until they are migrated to the new
release.

Related reference
Interoperability summary

Related topics
System interoperability concepts

3.11 Inter and intra cluster interoperability

3.11.1 Configuration and validation interoperability


Intercluster peer-to-peer function enables communication between batch layers distributed in two or
more Experion clusters. This function allows a parent recipe in one cluster to control its child recipes in
another cluster. The clusters participating in intercluster peer-to-peer communication may be in the
same or different FTE communities.
Inter-cluster interoperability

- 25 -
Chapter 3 - System interoperability concepts

3.11.2 Runtime interoperability


Inter-cluster interoperability
The following table shows interoperability between Security Manager and Security Manager Proxies
with all other nodes that participate in Secure Communications. C300s, Console Stations, Flex Stations,
Console Extension Stations, and Servers not in the role of Security Manager or Security Manager Proxy.

- 26 -
CHAPTER

4 PLANNING MIGRATIONS

Preparation for system migration requires careful planning and must begin well in advance of the day
that you plan to start a migration. To execute a migration successfully requires the coordination of
many things along with the cooperation of various plant personnel. Develop a comprehensive
migration plan that addresses the considerations described in the following sections. Also a plan helps
to alert responsible plant personnel on what to expect before, during, and after the migration.
This section covers topics that describe preliminary planning, considerations, and tasks which are
essential for conducting a successful system migration while on-process.
l Develop a migration plan
l Develop a migration strategy
l Develop a migration timetable
l Review software requirements
l Review hardware requirements
l Choose whether to use Experion Software Installation Server (ESIS)
l About Experion Migration Storage Node (EMSN)
l Considerations for planning network topology changes
l Review migration considerations
l Planning time synchronization during migration
l Identify security policy changes
l Cancelling a migration

4.1 Develop a migration plan


It is essential that you develop a migration plan for your control system to minimize any problems which
may occur during a migration and ensure that the migration is successful. In developing a migration
plan, you must take into account the structure and size of the control system as well as the process
which the Experion system controls.
A system may contain one Experion cluster, or in a larger system, a number of Experion clusters. An
Experion cluster may consist of computers that host redundant servers, clients which may consist of
one or more Console Stations, Flex Stations associated with the servers, and controllers associated
with the cluster. Larger Experion clusters may consist of computers that host redundant servers; clients
(both Flex and Console Stations) associated with the servers, an ACE node, and a set of controller
components. Large plants may contain a number of control systems that have many Experion clusters
populated throughout the plant.
You may decide to migrate the Server/Client nodes of one cluster and then migrate all, none, or a
portion of the controller components of that cluster. The servers in all the Experion clusters of a control
system may be selected for migration now, and the controller migration could be scheduled for a later
time. Interoperability of system components is possible with some restrictions. For example, you could

- 27 -
Chapter 4 - Planning migrations

migrate and operate servers and clients on the new release software, and operate controllers and other
system nodes running at the base release until migration is scheduled for those components. In any
case, server migration (which includes clients) is always performed before the migration of ACE nodes
and controllers within a single cluster.
A well-planned migration plan must be developed beforehand to ensure success. A control system
must be partitioned in such a way that migration of Experion clusters is accomplished with minimal
upset to the process. You may want to create a system drawing showing the system structure to aid you
in migration planning.
Also, consider any hardware upgrades that may be necessary or desired. Servers may require a newer
hardware platform (computer system) in order to operate and run new release system software. See
Hardware requirements for more information.
Contact the HPS Migration Center of Excellence at [email protected] to let them
know that you are planning to perform a migration of your system. The HPS Migration Center of
Excellence, working with TAC, can offer invaluable information and guidance in planning and executing
a system migration.
l Considerations while migrating non-redundant Experion systems and control components
l Considerations for migrating network-API based customer applications
l Migration Planning Checklist

4.1.1 Considerations while migrating non-redundant Experion


systems and control components
Non-redundant Experion system and control components must be migrated off-process. If a migration is
planned during a scheduled plant maintenance shutdown, a migration plan must be developed to make
sure that people and resources are available for the migration.

4.1.2 Considerations for migrating network-API based customer


applications
Network-API based customer applications must be migrated off-process.
For more information, refer to the Application Development Guide .

4.1.3 Migration Planning Checklist


The Migration planning checklist provides a high-level list of tasks to be performed while planning a
system migration. Many of these tasks refer to sections in this document for further information or
procedures to complete the task. You can use a more comprehensive set of checklists available in the
Migration Planning Checklist Collection chapter.
Table 4.1 Migration Planning Checklist
Step Task Done?
1 Inform the HPS Migration Center of Excellence (COE) that you are preparing to migrate
your system. You can contact the COE at [email protected].
2 Review the latest SCN to find any information that pertains to the migration you are going
to perform. Review the general specifications and requirements for the new release in
Appendix A of the SCN. See the Experion SCN for this information.
3 Check the Honeywell Process Solutions website and refer to the spreadsheet available at
the following link http://www.honeywellprocess.com/library/support/software-
downloads/Experion/experion-update-matrix.zip for any information on updates for latest
Experion patches, software updates, and so on to review whether or not these items
apply to the system installation for migration.
5 Use a software application (such as Intergraph, Auto-Cad, or Visio) to plan your
implementation or system design. Create a drawing that shows the system architecture,
(clusters, servers, clients, and controllers) that could aid you to implement your migration.

- 28 -
Chapter 4 - Planning migrations

Step Task Done?


6 Identify the cluster and node migration sequence. SeeMulti-cluster migration scenarios.
This is a very important consideration and you must consider the process being viewed.
During migration, a station cannot view the process for a few hours while the connected
server is updated. Thus while the station is being updated, alternate security level or
asset assignments may need to be performed on the stations that are not being migrated
at that time.
7 Identify the backup imaging sequence for Experion nodes including the locations of
images. Experion Backup and Recovery application can be used for this operation. See
Experion Backup and Restore User’s Guide for information and procedures.
8 Make sure that a time topology for the system is in place that provides time
synchronization to all the nodes throughout migration. See Planning time synchronization
during migration.
9 Identify the location of the BOOTP server. Refer the section BOOTP service in the
Scenario specific migration guides.
10 Identify all other Honeywell Applications in the system and consider any interoperability
and migration requirements. Define a migration plan for these applications. SeeMigrating
other Honeywell products and applications.
11 Identify all third party applications in the system, and define a migration plan.
SeeMigrating non-Experion third-party applications.
12 Read through the appropriate Scenario specific migration guides to become familiar with
the migration process, and be aware of other tasks to perform in preparation for migration.
Take notes.
13 Review computer hardware requirements for the target release, and review against your
computer hardware proposed for use on the new release. See the section
‘Software/Hardware/Firmware Compatibility’ in the Experion SCN for more information.
14 Verify that DVD drives are available to the PCs identified for migration. This can include
local drives or remote drives that may be used to read the Experion media.
15 If planning to use an Experion Software Installation Server (ESIS) during migration,
identify a node in the system to be used as an ESIS. SeeChoose whether to use Experion
Software Installation Server (ESIS).
16 Review Supplementary Installation Tasks Guide for information and tasks that may be
necessary during migration (such as time synchronization and adding computer back into
a domain).
17 Identify the FTE drivers and switches and\or the switch configuration files that need to be
updated.
18 Review the latest Fault Tolerant Ethernet Overview and Implementation Guide for
possible improvements.
19 Use ERDB Consistency Checker on Process systems to identify the following:
l Validate the content of the Engineering Repository Database (ERDB).
l Identify and correct inconsistencies in the ERDBs before starting migration.
l Custom CCLs that have to be updated.
l Control strategies that have to be updated after the migration.
20 Identify any customized system displays that have to be re-created after migration.
21 Plan any conversions that are to be done after the migration, such as CNI replacement
with FTEB and C200 replacement with C300.
22 Estimate the time required to migrate the system components and develop a timetable for
the migration process (planning, system readiness or pre-migration tasks, migration of
servers/clients and controllers to the target release, post-migration tasks.) See Develop a
migration timetable.

- 29 -
Chapter 4 - Planning migrations

4.2 Develop a migration strategy


Identify the scope of migration.
l On what release of Experion software is your system currently operating (the base release)?
l What release of Experion software do you want to migrate to (the target release)?
l Which part(s) of the system are to be migrated at this time?
l What parts of the system are identified for subsequent migrations?
l Is a product change planned for the system nodes?
l How do the migrated system nodes interoperate with the nodes that remain on the base release?
l If Secure communications is enabled, identify the node performing the Security Manager role and
what is its migration requirement for Experion cluster(s) in the Security Area?

If your system comprises one Experion cluster or a number of clusters, all the server nodes in the
clusters are migrated to the target release now? Do server nodes share databases between clusters?
For example, the Enterprise Model Database (EMDB) may exist on a dedicated node which is shared
between servers in different clusters. How does this impacts migration? How does this impacts the
system operation and interoperability if one Experion cluster is migrated to the target release and
another cluster is left at the base release? When migrating from R410.xor later, the cluster order is not
restricted - the cluster with EMDB Server can be migrated first, last, or middle.
For larger systems that include multiple clusters, a migration strategy must contain two scenarios.
1. How is the system migrated?
2. How is each Experion cluster migrated?

l System migration planning


l Cluster migration planning
l State of the process
l Network topology considerations

4.2.1 System migration planning


Depending upon how your system topology is arranged, determine the order of migration for the nodes
and clusters that comprise your system.

4.2.2 Cluster migration planning


Within a single cluster, on-process migration of Experion nodes occur in the following order.
l Server B
l EAS (off-process migration can be performed before or after server migration)
l One Flex Station
l One Console Station
l Console Extension Stations (CES) connected to the migrated Console Station
l Perform compatibility and performance tests

l
ATTENTION

- 30 -
Chapter 4 - Planning migrations

Some stations and consoles can be migrated before or after Server A or Server B is
migrated.

l Remaining Flex Stations


l Remaining Console Stations
l Remaining Console Extension Stations (CES) connected to the Console Stations
l Server A
l Controllers
l ACE and SCE nodes (migrated off-process)
l E-APP
l eServer
l Collaboration Station

Other nodes which may be associated with a number of servers across multiple clusters, such as
eServer, are migrated off-process, independent of the system migration.
If your system contains Series C control hardware (C300 (CC-PCNT01/CC-PCNT02)/C300 with EHB
personality configured controllers, FIM4s, FIM8s, and PGM), you must upgrade the CF9 control firewall
to the latest firmware before you migrate the Series C control hardware.

4.2.3 State of the process


Determine what state is satisfactory for the process to start an on-process migration. The process must
be stable, and if possible, inactive. If the process is a batch operation, it is recommended that a batch
not be in progress during system migration. Verify that the process is appropriate for on-process
migration by using normal system displays to view and monitor the process.

4.2.4 Network topology considerations


If you are migrating a SCADA node from , the network topology changes depend on whether you want
to use the following process control components after migration or not.

NOTE
The process control components are.
l C200, C200e, C300 (CC-PCNT01/CC-PCNT02), and UOC with EHB personality
configured controllers.
l ACE, SCE, or EHG nodes
l Fieldbus Interface Module or FTE Bridge Module

If the SCADA node is configured with FTE topology, then FTE gets installed during migration. If the
SCADA node is configured with Ethernet topology, then the same configuration is retained after
migration.
For details on the network topology changes, refer to the corresponding SCADA migration guide. You
can refer Related documents for the list of migration guides.

4.3 Develop a migration timetable


Develop a timetable for conducting the migration. Consider the timing of the various migration tasks that

- 31 -
Chapter 4 - Planning migrations

need to be performed and the order of such tasks. Estimate the time required for completing each task.
For example, estimate the time for:
l Obtaining new hardware, if required.
l Completing pre-migration tasks.
l Performing server migration of one redundant node.
l Performing migration of associated client nodes.
l Completing compatibility and performance tests on migrated nodes.
l Completing the migration of the remaining client nodes.
l Performing server migration of second redundant node.
l Completing server post-migration tasks.
l Reinstallation of other Honeywell applications.
l Reinstallation of third-party applications.
l Migration of other Experion nodes, ACE, SCE, EHG, and so on.
l Performing controller migration.
l Completing controller post-migration tasks.

Migration time estimates

4.3.1 Migration time estimates


Use the following information as a guide for estimating the time to perform an on-process migration from
, or an off-process migration from . The estimates are based on a cluster with 5-10 stations, redundant
servers, 1 ACE node, 3 - 10 controllers, and a number of LCN connections. These times can vary
significantly based on user experience, database size, and the current condition of the system.

On-process migration to

Migration Task Estimated Time


Overall planning. 2–5 days
Fixing of all issues that may prevent migration, and getting an approval from COE 2–4 days
for migration
Preparation and backups. 2–5 days
Server B migration together with some stations or consoles. 3–4 days
Migrate remaining stations and consoles.
l Each Flex Station 3–4 hours
l Each Console Station 3–4 hours
Verification of proper Server functionality (Compatibility Testing). 1–2 days
Server A migration 1–2 days
Controller migration 1–2 hours per
controller
Perform off-process ACE node migration 3–5 hours
TPS functionality 1–2 days
Migration verification 1–2 days

- 32 -
Chapter 4 - Planning migrations

Off-process migration to

Migration Task Estimated Time


Overall planning. 1–2 days
Fixing of all issues that may prevent migration, and getting an approval from COE 2–4 days
for migration.
Preparation and backups. 1–3 days
Server A and B migration. 2–3 days
Migrate the stations and consoles:
l Each Flex Station 3–4 hours
l Each Console Station 3–4 hours
Controller migration 1–2 hours per
controller
ACE node, SCE 3–5 hours
TPS functionality 1–2 days
Migration verification 1–2 days

4.4 Review software requirements


Review and address the software requirements for the migration. Some considerations that must be
reviewed are:
l What is the base release (or current release) of the system components identified for migration?
l What is the target release for the system components?
l Will the system be taken to the latest target point release?
l Is the release at the correct service pack level or release level to perform the planned migration?
l Does the planned migration path for the system create any special requirements that must be met?
For example, if all the system components are not currently operating at the base release, then must
components at older releases be migrated to the base release before migration to the target
release?

ATTENTION
l Before starting the migration from base release to the target release, ensure all the
required optional features are installed using the installation media of the base release.
l The qualified on-process server migration paths for Experion Release are:
o Experion R410.x (with or without patches) to Experion
o Experion R430.x (with or without patches) to Experion
o Experion R431.x (with or without patches) to Experion
o Experion R432.x (with or without patches) to Experion
o Experion R500.x (with or without patches) to Experion
o Experion R501.x (with or without patches) to Experion
o For exact supported migration paths, refer to the latest target release SCN.
o For exact supported migration paths, refer to the latest target release SCN.

l Migrating other Honeywell products and applications


l Migrating non-Experion third-party applications

- 33 -
Chapter 4 - Planning migrations

Related topics
Software requirements
4.4.1 Migrating other Honeywell products and applications
Some of the Honeywell applications installed on Experion nodes may not be migrated as part of the
Experion system migration. During migration you may get a message that informs you of software
applications (both Honeywell and third-party applications) that cannot be migrated forward. Refer to the
associated product documentation and take appropriate actions to preserve these applications and
user settings so that they can be restored after migration.
l Alarm Pager - If you are using Alarm Pager option, you must reconfigure the alarm paging after
migration. This requires that you check to make sure that the modem (if one is used) is connected to
the system and configured properly. Refer to Experion Server and Client Configuration Guide .
l Control Component Libraries (CCLs) - The system standard CCLs supplied with Experion are
migrated forward to the new release. Special consideration is required for customer specific CCLs.
l Customized system components and display files must be manually saved because they are not
migrated and then restored in the target release. For example:
o Point detail displays such as DI, Numeric, flag, and fieldbus.
o Faceplates such as DI, Numeric, flag, and fieldbus.
o Custom Station menu configurations (*.stb files)
o *.css files

l Safety Manager - For Experion systems that have Safety Manager installed, refer to the Safety
Manager documentation for migration.

The following are some of the other Honeywell applications that may be installed on Experion nodes
and not migrated as part of Experion system migration.
l Field Device Manager (FDM)
l Asset Manager
l Da Vinci Server, Quality Server, MxProLine Server
l BMA
l Process History Database (PHD)
l Process Performance
l Profit Suite
l Simulation
l TPB
l User Alert
l Uniformance

For information about Applications Interoperability Matrix, refer to the


http://teams.honeywell.com/sites/AIT/HPSAITInteroperabilityMatrix/Shared%20Documents/HPS-
Applications%20Interoperability%20Matrix.aspx link.

4.4.2 Migrating non-Experion third-party applications


Most non-Experion applications are not migrated as part of Experion migration. If your control system
includes non-Experion (third party) applications, consider a strategy for saving the data and
configuration files for the application so that the data and user settings can be restored with the
application after Experion migration is completed. Take appropriate steps to save these files and
applications. During server migration you may get a message that informs you of software applications
that are not be migrated forward and deleted from the node.
Additional considerations must be made such as:

- 34 -
Chapter 4 - Planning migrations

l Are the third-party applications currently operating with the Experion system compatible with the
new release operating system requirements?
l Are the third-party applications interoperable with the new Experion platform software release?
l Are there upgrades available for the third-party software?
l Is compatibility testing performed off-line to ensure that the applications operates properly in a
stable manner?

ATTENTION
Experion operates with Windows Firewall enabled. You must verify that third-party applications
are set to operate in a firewall environment.

Here are some examples of third-party software applications.


l Virus protection services applications are not migrated forward as part of Experion migration.

4.5 Review hardware requirements


Migrating an existing Experion system to new system software may require that the hardware platform
(computer system) which supports software operation is also upgraded. Hardware platforms may be
configured as Experion Servers, Flex Stations, Consoles, ACE or SCE nodes, or other client nodes. A
new computer system may be needed to meet the performance requirements for Experion software
operation. Typical upgrades may include adding memory cards, installing additional disk drives and
upgrading to newer interface cards.
Any third-party hardware interfaces, if installed, need to be transferred to the new hardware platforms.
Verify if the interface hardware is compatible and can be installed in the new platform's card slots, and if
the interface hardware need to be replaced. Make sure that any replacement hardware is equivalent in
function of the hardware that it replaces. Estimate the time required to obtain any new hardware.

4.6 Choose whether to use Experion Software Installation


Server (ESIS)

Starting R310, Experion Software Installation Server (ESIS) can be set up only on a local hard drive, a
portable USB hard drive, or a removable USB drive. Setting up ESIS includes installing all the Experion
software on a shared folder (the shared folder is created on local hard drive or USB drive) which can be
accessed over a network to perform Experion installation and migration on one or more systems. ESIS
provides a single repository for all Experion software and can be used for installing and migrating
Experion software on multiple systems simultaneously. ESIS can be updated for any media updates or
new media releases. An ESIS repository consists of a copy of the following:
l Experion® PKS Installation media 1 ( DVD 1)
l Experion® PKS Installation media 2 ( DVD 2)
l Experion® PKS Updates media ()
l Microsoft® Visual Studio® 2012 Professional for CAB Developers media - 1 (DVD 1)
l Microsoft® Visual Studio® 2012 Professional for CAB Developers media - 2 (DVD 2)
l Experion® PKS System Initialization media
l Experion® PKS System Initialization Updates media
l Experion® Support and Maintenance (ESM) media (DVD R242.1)
l Microsoft® SQL Server® 2017 x64 media

- 35 -
Chapter 4 - Planning migrations

l HMIWeb Solution Pack Installation Media


l Experion® PKS
l Microsoft Windows 10 Enterprise 2016 LTSB (x64) HPS Reinstallation media
l Microsoft Windows Server 2016 Standard HPS Reinstallation media
l Embedded Microsoft Windows Server 2016 Datacenter HPS Reinstallation media
l Experion PKS with PMD Controller media
l Experion TPN Personalities APP CD
l Experion TPN Personalities GUS CD
l Microsoft Updates DVD (SUIT)

ATTENTION
l You can create an ESIS repository on a local hard disk that can be accessed using a
network share.
l For setting up an ESIS repository, the minimum space required on the ESIS server is 45
GB.
Depending upon your preferences for ESIS setup, the minimum size required for ESIS
setup varies.
l You must have .Net Framework 2.0 or higher version installed on your computer for
creating an ESIS repository.
l You can create the ESIS repository on the following operating systems.
o Windows Server 2016
o Windows 10
o Windows Server 2008 32-bit OS (Service pack 1 or above)
o Windows Server 2008 R2 OS (Service pack 1 or above)
o Windows 7 32-bit OS (Service pack 1 or above)
o Windows 7 64-bit OS (Service pack 1 or above)

l The ESIS and Experion Migration Storage Node (EMSN) can be hosted on the same
server. When hosted on the same node, while connecting to EMSN or ESIS, ensure to
use the same account (with same permission) during migration.

ATTENTION
1. DO NOT install/setup ESIS on Experion nodes.
2. Although ESIS allows migration of multiple Experion nodes, there are some limitations
that must be noted.
l In on-process migration scenarios, do not migrate more than two nodes
simultaneously. When the Plant processes are running, the control system must
have the necessary bandwidth for network communications to ensure process
control.
l In off-process migration scenarios, it is assumed that other control devices are on
the network (third party devices). Therefore, do not migrate more than four nodes
simultaneously.

4.7 About Experion Migration Storage Node (EMSN)


The Experion Migration Storage Node (EMSN) is a temporary storage area used for storing migration-

- 36 -
Chapter 4 - Planning migrations

related information, which is used after installing Experion.


l Identify a location for the EMSN
l Considerations for using EMSN hosted in a domain

4.7.1 Identify a location for the EMSN


The EMSN is a shared folder which is used for storing and retrieving the database and configuration
information contained on an Experion node identified for migration. The EMSN must be set up and
located on a node different from the node to be migrated, but within the same control network or
Experion cluster. EMSN is compatible with USB hard drive or removable USB drive.
The EMSN must have sufficient disk storage so that the information can be copied to the EMSN from the
server or client node to be migrated. You can identify a node and create a space for the EMSN before
you begin migration. You are prompted to create a shared folder for the EMSN during migration. A
minimum of 32 GB disk space is required for creating EMSN.

During phase I of migration, if you do not select Operating System Re-installation option, then Local
EMSN and the Remote host EMSN options are available. If local EMSN is not required to be stored
after migration, then you can select Select this to delete EMSN once Migration Complete (this helps to
manage the disk space) check box.

ATTENTION

4.7.2 Considerations for using EMSN hosted in a domain


When the computer on which EMSN is hosted and the Experion node to be migrated are members of a
domain, they can either be on the same or different network. You may not be able to resolve the
Universal Naming Convention (UNC) path to EMSN and the credential information when the following
are performed during migration.
l A hardware change
l An operating system installation (cannot be avoided for the migration paths where operating system
change is a must)

To avoid path resolution problems, perform one of the following based on the location of the EMSN and
the node to be migrated.
1. If the EMSN and the node to migrated are connected over the same network.
a. Use normal UNC.
b. For security (account and password), create a local account (and password) on the domain
system that matches the account being used for performing the migration on the node being
migrated.
l Add this account to the Share and File Permissions on EMSN.
l The account entered must be the Account Name and associated password. Or, you can
specify an account on the EMSN by entering EMSNHostName\Account.
l Enter the password.

2. If the computer is not local to the system, (computers must communicate across a router):
a. Define the Server UNC path in the following format: \\EMSN Host IP Address\<<EMSN
ShareName>> For example: \\192.168.0.1\EMSN
b. For Security (account and password), create a local account (and password) on the domain
system that matches the account being used for performing the migration on the node being
migrated.

- 37 -
Chapter 4 - Planning migrations

l Add this account to the Share and File Permissions on EMSN.


l Type the account name as <<EMSN Host IP Address>>\Account. For example:
192.168.0.1\MigAccount
l Type the password.

4.8 Considerations for planning network topology changes

ATTENTION
Any changes to the control or supervisory communications topology in the system must be made,
either before migration is started or after migration is completed.

Identify any changes to the system or network topology that are planned and which can be made before
the migration. For example, if you are planning a product change (changing a SCADA system type to
Process system) or conversion of single/dual Ethernet or ControlNet to FTE; a FTE supervisory network
must be installed in the system before migration starts. For more information and the tasks for installing
an FTE network in a system, see ‘Converting a single or dual Ethernet supervisory network to an FTE
network’ in the Fault Tolerant Ethernet Installation and Service Guide . Create a plan to complete the
changes.
Identify any changes to the system communications network that you want to make after migration. For
example, you may want to add CISCO switches, update the CISCO switch firmware, and then update
the CISCO switch configuration, and add a control firewall. Also, you may want to install C300/C300
with EHB personality configured controllers and Series C I/O modules, add Stations, add controllers,
and/or update the control firewall. You must also determine a plan for performing these changes that
affect the network topology.

4.9 Review migration considerations

ATTENTION
The following sections contain important information that you must consider before you begin a
migration. The information is arranged by system function or feature and describes conditions
where data may be lost through the migration process, if precautions are not taken or procedures
are not followed. Where possible, workarounds are provided to help safeguard and restore data.
Therefore, if your Experion system contains certain configurations of system components or uses
these features, you must read the related topics of interest to determine if the information is
relevant to your system or situation. If so, take precautions to back up your data files and follow
any required workarounds.

l Considerations for migrating integrated Experion-TPS nodes


l Considerations for migrating DSA-connected Experion/TPN systems
l Considerations for migrating secured Experion nodes
l Considerations for multi-cluster migrations
l Considerations for partitioning hard drives using Experion PKS System Initialization media
l About pre-installed SQL scenario
l About System Alarms Suppression

4.9.1 Considerations for migrating integrated Experion-TPS nodes


TPS components continue to be on-process during the migration of Experion system components, and

- 38 -
Chapter 4 - Planning migrations

ES-Ts continues to have view and control capabilities to the TPS system during the migration process.
When an ES-T node is selected for migration, it loses view and control capabilities. After the node is
migrated and is operational on the new release, view and control are restored. Considerations must be
made to maintain at least one operational node that can provide view of the TPN.
If you are implementing the Experion LCN, TPN software on TPS nodes must be upgraded.

4.9.2 Considerations for migrating DSA-connected Experion/TPN


systems
The ESVTs and ESTs in Experion clusters that are connected to TPN can be migrated without affecting
TPN operations. The version of TPN required for the integrated Experion-TPS nodes in has not
changed since R210 so there is no requirement to upgrade it, unless you are planning to install the
Experion ELCN. Experion ELCN requires the TPN/LCN software be updated on the LCN and on the
Experion TPS Nodes, prior to updating the Experion software.

ATTENTION
DSA interoperability between R3xx and is supported.

4.9.3 Considerations for migrating secured Experion nodes


The following considerations must be noted for secured Experion nodes before migrating from .
1. It is recommended to remove secure communication configuration changes during Experion
migration.

4.9.4 Considerations for multi-cluster migrations


The following important considerations must be read to determine if any apply to your system in a
migration scenario.
l The table “Multi-cluster migration scenarios and EMDB interoperability” describes migration
scenarios for two clusters. The same scenarios are valid for all clusters within a system.
l In all migration scenarios, DSA and OPC data interoperability is available throughout the migration
process. Server nodes connected through DSA must maintain communication with other DSA
servers and clients before, during, and after an on-process migration, (except for the node that is
currently being updated). OPC data exchange between servers and clients and third-party OPC is
also maintained during migration, except when the OPC node is being migrated.
l Interoperability is supported only between clusters (servers) operating on two different releases and
only between releases in which migration is supported. Interoperability between clusters (servers)
operating on more than two different releases is not supported.
l Do not make any engineering changes until all clusters within a system are migrated.
l Do not make any engineering changes until all systems are migrated.
l Do not download or upload EMDB data when either the EMDB hosting Experion server or the target
Experion server is in dual primary state.
l Minimize the amount of time that clusters are running on different releases. Although OPM of multi-
cluster systems allows for interoperability between clusters operating on different releases, you must
minimize the time that clusters on different releases in a system are allowed to co-exist.
l All nodes within the FTE communities used by any of the migrating clusters must be updated to the
latest version of Common Components before starting a migration.

- 39 -
Chapter 4 - Planning migrations

l All FTE system preferences and FTE driver configurations must be the same for all clusters in the
FTE community.
l The BOOTP server must be running on the latest release server of the cluster. You must run the
BOOTP checker before migrating or rebooting any controllers.

4.9.5 Considerations for partitioning hard drives using Experion PKS


System Initialization media
Experion PKS System Initialization media fails to partition hard drives before starting the operating
system installation if additional internal drives or RAID arrays are connected to the system.

ATTENTION
l Experion PKS System Initialization media is tested and qualified only on Honeywell
recommended hardware configuration and only supports those configuration. Honeywell
recommended hardware configurations do not include more than one hard drive on non-
RAID platforms.
l Previously used EXPPlus media (R3xx.x) was unintentionally supporting such non-
standard hard drive configuration. Therefore, any customer using such configuration and
migrating to may come across this issue.
l This issue is not applicable to external USB hard drives attached to the platforms.

Before starting the operating system installation, Experion PKS System Initialization media fails to
perform the requested partition of the hard drive on workstations with more than one internal hard drive
or servers with more than one RAID array. Hard drive partition on these servers/workstations fails with
the error message Failed to configure harddisk. Click Yes to retry or No to exit. Experion PKS System
Initialization media deletes and re-creates partitions in the additional hard drive or the RAID array.

ATTENTION
This is not applicable to USB hard drives attached to the platforms.

This issue occurs when customers are using Experion PKS System Initialization media to perform hard
drive partition prior to operating system installation on any Dell platform having non-standard
Honeywell configuration or any server or workstation. The non-standard Honeywell configuration can
be (but not limited to)
l workstation having more than one internal hard drive, and
l any server/workstation having more than one RAID array.

ATTENTION
Review the hardware platform configuration to ensure that the platform does not include more
than one internal hard drive on non-RAID platforms and more than one RAID array on RAID
platforms.
You must perform this hardware platform verification before booting the system with Experion
PKS System Initialization media to start operating system installation. If you have not performed,
the Experion PKS System Initialization process may delete and re-create partitions in the
additional hard drive or RAID array. This results in data loss in the additional hard drive or the
RAID array.

- 40 -
Chapter 4 - Planning migrations

To disable additional hard drives in BIOS before starting operating system


installation

1. Press F2 to enter BIOS Setup while the workstation is booting.


2. On the left pane, navigate to Drives, and press right arrow or Enter to expand Drives.

ATTENTION
Before disabling/enabling the SATA ports that have additional hard drives, you must
verify the Drive Details section on the right pane.

3. For Dell Precision Workstations R5500, T5500 and T3500:


a. Select Drives.
b. Clear the respective check boxes for each SATA port (For example, SATA-1 check box).
Hence, all SATA ports to which additional hard drives are connected are disabled.
c. Click Apply to save the changes.
d. Click Exit to close the BIOS setup window.
4. For Dell Precision Workstations T5400, T3400, and P490:
a. On the left pane, navigate to each SATA port option using the arrow keys.
b. Press Enter to modify the SATA port option.
c. Select Off to disable all SATA ports to which additional hard drives are connected.
d. Press Esc, and then select Accept to save the changes.
5. Restart the workstations/servers.

To enable the hard drives

1. Once the installation completes, perform step 1 through step 2 from the To disable additional hard
drives in BIOS before starting OS installation procedure.
2. For Dell Precision Workstations T5500 and T3500:
a. Select Drives.
b. Select the respective check boxes for each SATA port (For example, SATA-1 check box).
Hence, all SATA ports to which additional hard drives are connected are enabled.
c. Click Apply to save the changes.
d. Click Exit to close the BIOS setup window.
3. For Dell Precision Workstations T5400, T3400, and P490:
a. On the left pane, navigate to each SATA port option using the arrow keys.
b. Press Enter to modify the SATA port option.
c. Select On to enable all SATA ports to which additional hard drives are connected.
d. Press Esc, and then select Accept to save the changes.
4. For Servers:
a. Do not use Experion PKS System Initialization media for operating system installation if the
server has more than one set of RAID arrays configured.
b. Perform manual operating system installation, and then use Experion PKS System
Initialization media to perform system configuration.
For more information on this issue, contact Honeywell TAC.

- 41 -
Chapter 4 - Planning migrations

4.9.6 About pre-installed SQL scenario


In , the pre-installed SQL scenario is supported to install Experion on a system where Microsoft SQL
Server 2014 Standard Edition Service Pack1 (SP1) is already installed.
SQL installation prior to Experion installation is only required on all the server nodes. For migrating on
all the server nodes from , you must manually install SQL on the server node and then configure SQL
prior to Experion migration. For migrating the server nodes from , this scenario is applicable only for
operating system re-installation migration. This scenario is also applicable for eServer and EAS node.
For configuring SQL, refer to the Configuring pre-installed SQL Server 2012 procedure in the Software
Installation User's Guide.

4.10 Planning time synchronization during migration


Maintaining the correct time synchronization throughout migration is critical. If you have a time topology
for your system, you must consider whether the current time topology is comprehensive enough to
distribute time to all system nodes during a migration. Otherwise, you must establish a time topology
that provides reliable time distribution to all nodes in the system.
Keep in mind that during a migration, some nodes operate at the new release (such as servers and
clients that are migrated), while other nodes (such as controllers) continue to operate at the base
release. Experion nodes in a system that are not synchronized to the same time source may drift
through time and cause control and/or migration problems. For example - at one point during server
migration, a redundant server pair is operating in a dual primary state, (Server B has been migrated and
is operating at the new release and Server A is operating at the base release). Each server may be
distributing time to the controllers associated with these servers. If time is not synchronized between the
servers, the controllers may execute control strategies incorrectly due to the inconsistent time received
from the servers.
The system time source must derive its time from a reliable external time source.
For the Experion LCN, you must configure the main ESVTs to be Clock Source Master and Clock
Source Backup Master (Slave) in the LCN NCF. For information, refer to the ELCN Overview and
Implementation Guide , topic “Experion TPS Node Configuration Requirements for ELCN”.
l NTP servers (time source for Series C control hardware)
l Time check on system before you start migration

4.10.1 NTP servers (time source for Series C control hardware)


In Experion R301.3 and later releases, Network Time Protocol (NTP) is used for furnishing system time
to all Experion nodes. Series C control hardware (C300/C300 with EHB personality configured
controllers, FIM4, FIM8, PGMEHPM, and IEC61850M), uses time distributed from an NTP server, so if
your system contains any Series C control hardware, you must setup an NTP server. Preferably the NTP
server must be setup on a Windows 2008 or a Windows 2003 node which derives its time from a
reliable external time source.
After server migration the exisitng NTP configuration settings can be restored using NTPConfig utility.
For more information, refer to the Scenario-specific migration guide and Site-specific migration guide .
For information about upgrading firmware using the Series C Firmware Load Tool, refer to the latest
Control Hardware and I/O Modules Firmware Upgrade Guide .
For information about setting up the system time, refer to the following guides.
l Time Synchronization topic in Server and Client Planning Guide .
l Setting up Time Synchronization in the Supplementary Installation Tasks Guide .

4.10.2 Time check on system before you start migration


Server time and time zone settings must remain consistent during migration. Before starting migration

- 42 -
Chapter 4 - Planning migrations

on a redundant server pair, check to make sure the time and time zone settings are the same on both
Server A and Server B, as well as the client nodes (Console Stations, Flex Stations, ACE node, so on.).
Change if necessary. After migration, check the time zone settings on the server and client nodes to
ensure they are the same. Change if necessary. Do not change time zone settings during a migration.
Additionally, check the time zone setting on other servers in the system, (any servers that are connected
to the migrated servers by DSA), and make any changes so that all nodes are set to the same time.
Support for the latest Daylight Savings Time fixes are included with the Experion Software. However,
due to the recent global time zone adjustments, it may be necessary to reset the time zone settings
during some migration scenarios. You must verify the time zone and set the time (if necessary) after the
software upgrade but before the server synchronization for dual primary state, and reestablishing of
server redundancy and all other nodes.

4.11 Identify security policy changes


Experion systems that use the Experion High Security Policy in a domain or workgroup environment
require that you update the security policy files to the most recent version when migrating your system.
Note that you can update your security policy files manually without using the installation packages,
although it is not recommended.
The Experion High Security Policy consists of the following two installation packages:
l A domain controller package which is installed on the domain controller. For more information, refer
to the Installing the domain controller package procedure.
l A Workstation package which is automatically installed on all nodes as part of the Experion software
load. You might be prompted to save the checkpoint when preparing to start migration. It does not
require a separate installation.

Installing the domain controller package


Workstation package

4.11.1 Installing the domain controller package


A domain controller used in an Experion system operates as an independent node with either Microsoft
Windows Server 2003 (32-bit), Microsoft Windows Server 2008 Standardor,Microsoft Windows Server
2008 R2 Standard, or, Microsoft Windows Server 2012 operating system installed.
If you are using Microsoft Windows Server 2003 (32-bit) currently as the domain controller’s operating
system, and do not upgrade the operating system, you must install the Experion High Security Policy on
the domain controller before you start migration.
If you are using Microsoft Windows Server 2003 (32-bit) as the domain controller operating system and
choose to upgrade to Microsoft Windows Server 2008 Standard, or Microsoft Windows Server 2008 R2
Standard, or Microsoft Windows Server 2012, or Microsoft Windows Server 2016, upgrade the domain
controller after completing migration of all nodes in the domain. Refer Interoperability summary section
in migration reference for domain controller interoperability.
Use the Microsoft recommended procedures to perform the operating system upgrade (at:
http://support.microsoft.com/default.aspx?scid=kb;en-us;325379). After the operating system upgrade is
complete, install the Experion Security Policy again on the domain controller.

ATTENTION
When you remove R31x version of the domain controller package, it does not change any user
group settings or disassociate any user/group settings, and does not delete any of the security
objects, (such as accounts, groups, or group policy objects). In addition, any Experion R31x
nodes that are members of the domain continue to operate when the new domain controller
package is installed.

- 43 -
Chapter 4 - Planning migrations

To install the domain controller package

1. Insert Experion PKS Installation media 1.


2. Browse to the removable drive location.
3. Right-click and choose Open.
4. Browse to <Packages\DCSecurity>.
5. Right-click Honeywell security model - domain controller and click Install.
6. If security warning dialog box is displayed, click Run.
7. In the Welcome to the Honeywell Experion PKS Installation Setup Wizard, click Next.
8. If prompted, type the user name and the password of the domain administrator account, and then
click OK.
9. Read the License Agreement, click I accept the terms in the license agreement and click Next.
10. Select Install policies at Domain Level and click Next.
11. Click Install.
12. Click Finish.

To remove the domain controller package

1. Click Start > Windows System > Control Panel.


The Control Panel dialog box is displayed.
2. Select Programs and Features.
3. Select the Honeywell Security Model-Domain Controller program.
4. Click Uninstall.

ATTENTION
Honeywell-provided Group Policy Objects (GPOs) are over-written when the new
domain controller security package is installed. Therefore, any customizations made to
the GPOs must be recreated after the new domain security package is installed. Users
must create their own GPOs for settings they want to customize, rather than modifying
the Honeywell-provided GPOs.

You must return to the Run Link Domain Groups task in the migration method chapter that brought
you to this chapter and continue with the remaining tasks.
For more information on domain controller package, refer to latest Windows Domain and
Workgroup Implementation Guide. For planning information, refer to Windows Domain and
Workgroup Planning Guide. For operation system migration information, refer the appropriate
operating system-specific implementation guide Windows Domain Implementation Guide for
Windows Server 2016/Windows Domain Implementation Guide for Windows Server 2016.

4.11.2 Workstation package


The workstation package is installed on all nodes as part of Experion software installation during
migration. The package includes the Link Domain Groups which is executed manually after the
workstation is made a member of a domain on which the domain security package is installed. The
application links the global group members with the local groups for computers participating in a
domain. In other words, after migrating a system with domain security, you must run Link Domain
Groups on all Experion nodes in the domain. Note that if domain security is not used, and the user login
is based on workgroup security, then the application is not required on any of the Experion nodes.
If errors occur when running the Link Domain Groups command, make sure that:

- 44 -
Chapter 4 - Planning migrations

l The new domain controller package is installed


l The workstation is made a member of the domain
l Both the domain controller and the workstation are on-line on the network

For more information on Experion High Security Policy, refer to the Server and Client Configuration
Guide.

4.12 Cancelling a migration


You can cancel on-process migration and go back and restore the control system to operate with the
base release software, depending upon which stage of the migration your system is at.
l On-process migration of servers/clients
l Off-process migration of servers/clients
l On-process migration of controllers
l Off-process migration of controllers

4.12.1 On-process migration of servers/clients


You can start on-process migration of redundant server by clicking Start Migration on the On-process
Migration page in Station. A number of restrictions take effect at this point.
l You cannot make changes to the Engineering Repository or Enterprise Model Databases. ERDB
and EMDB replication remains disabled until Server A migration is complete.
l You cannot initiate a manual failover or database synchronization while the on-process migration is
active.

To cancel migration, click the Cancel Migration button on the On-Process Migration page. Then, restore
the server to the state it was before starting migration and start the migration again. After migration is
cancelled, you cannot re-enter migration from the point at which migration was cancelled.
You can cancel on-process migration (without a loss of control or view) up until the point where you
begin migration of Server A, (Section ‘Migrating Server A’ in the On-process migration (OPM) checklist).
After performing ‘Run Compatibility Tests’ in the OPM checklist, run the system for 2-3 days to allow the
control system to remain stable. You must be satisfied with the control system performance before you
continue migration of Server A.
While Server A is being migrated, Server B must remain at system running status and as the primary
server. If you change the status of Server B, you invalidate the on-process migration and the base
release of Experion must be restored or reinstalled on both Server A and Server B.
If you cancel on-process migration before you begin Server A migration, then you must restore Server B
with the saved disk image or reinstall the base release of Experion on Server B (and associated clients)
to return the system to a redundant server state.
If you restore Server A or Server B from a disk image and Server A and Server B are part of a domain,
you must remove the computer from the Windows domain and then:
1. Add again each to the workgroup.
2. Re-boot each.
3. Add again each to the domain.

If you cancel on-process migration while Server A is shutdown, then you must restore the saved disk
image containing the base release of Experion to Server A. You lose all runtime data during the period
that Server A is down. After Server A is restored and is running, you must restore the disk image or
reinstall the base release of Experion on Server B to return the system to a redundant server state.

- 45 -
Chapter 4 - Planning migrations

If you are planning to migrate Experion TPS nodes to Experion LCN nodes during Experion On-Process
Migration of your existing Experion system, you must implement the ELCN Bridge. Also, you must install
an additional, separate Experion Server to commission the ELCN Bridge and then monitor it during the
Experion On-Process Migration timeframe.

ATTENTION
The ELCN Bridge Commissioning Server is needed only when migrating from Experion or later.
There is no need for the ELCN Bridge Commissioning Server if you have already installed ELCN
Bridges and are doing an Experion on-process migration to a newer Experion release.

4.12.2 Off-process migration of servers/clients


There are no critical points when to cancel off-process migration, as the control system does not
operate. All migrated nodes can be restored to the base release, if necessary. If you need to restore any
server or client node to the base release, you can use a disk image, (saved prior to migration) to restore
the node to the base release. First you must cancel or exit any applications that are running; then load
the disk image to the node.

4.12.3 On-process migration of controllers


Generally, after the migration of redundant controllers and I/O control hardware is started, you must
allow the migration to complete.
When migrating redundant Series C control hardware, the Controller Migration Wizard gives you an
option either to continue with the migration of the redundant partner, or choose ‘Back to Idle.’ If Back to
Idle is selected, due to switchover, the controller running on the base firmware becomes the primary
controller. The controller on the new release firmware runs the base release firmware.
After migration is complete, you can restore redundant controllers to the base release firmware, but it
must be performed off-process.

4.12.4 Off-process migration of controllers


There are no critical points for off-process migration of controllers, except that after a migration is started
it must be allowed to complete. If controller migration is interrupted, the controller may have to be
returned to the factory for reprogramming.

- 46 -
CHAPTER

5 STARTING MIGRATION

Before starting migration, perform the following:


l Select a migration path.
l Select the server/client migration scenario.
l Select the controller migration scenario.

The following sections elaborate the criterion for these selections.


l Selecting a migration path
l Migration scenarios

5.1 Selecting a migration path


The starting point for Experion system migration is the selection of a migration path. A migration path
defines the system migration from the base release to the target release.
There are minimum requirements for a migration path. Systems must be operating with a software
release and update level that supports on-process migration.

ATTENTION
Read the section Planning for Migration . It contains pertinent information which is essential to
perform a successful migration.

l On-process migration of servers/clients


l On-process migration of controllers

5.1.1 On-process migration of servers/clients


On-process migration is supported using the procedures contained in the Scenario specific migration
guides.
*For exact migration paths supported to target point release, refer to the latest target point release
Software Change Notice (SCN). For example, refer to the latest target release SCN.

5.1.2 On-process migration of controllers


On-process migration is supported using the procedures contained in the scenario specific migration
guide and site-specific migration guide . For more information, refer to the latest Experion PKS General
Release Software Change Notice and Experion PKS Support Software Software Change Notice .

- 47 -
Chapter 5 - Starting migration

5.2 Migration scenarios


l Server/client migration scenarios
l Controller migration scenarios

5.2.1 Server/client migration scenarios


The following table shows the server/client migration and installation scenarios which are supported for
Experion Release . Experion PKS Installation media contains the Install Sequencer which executes the
migration. The table also shows the Windows operating systems that are supported for the different
Experion node types and the behavior of the Install Sequencer when it is run on the system. Some
migration scenarios may require a hardware upgrade. Reinstallation of the operating system is
mandatory for all the migration scenarios.

Table 5.1 Experion Server/Client migration scenarios and Install Sequencer behavior
Operating Experion Install Sequencer Behavior
System Release
Installed Installed
Microsoft None Performs a clean installation on Experion .
Windows
Server 2016
Microsoft None Performs a clean installation on Experion .
Windows 10
(64-bit)
Windows 41X.x and Detects the previous version of Experion on the computer. Starts the Install
Server 2008 43X.x Sequencer to perform migration to Experion with an operating system
R2 (64–bit) change.
Windows 7 41X.x and Detects the previous version of Experion on the computer. Starts the Install
Professional 43X.x Sequencer to perform migration to Experion with an operating system
(64–bit) change.
Windows Experion Detects the previous version of Experion on the computer. Starts the Install
Server 2008 R400.x Sequencer to perform migration to Experion with an operating system
(32 bit) change.
Windows 7 Experion Detects the previous version of Experion on the computer. Starts the Install
Professional R400.x Sequencer to perform migration to Experion with an operating system
(32 bit) change.
Microsoft Experion Detects the previous version of Experion on the computer. Starts the Install
Windows Sequencer to perform migration to Experion with a choice to the user for an
Server 2016 operating system re-install or to retain the Operating system.
Microsoft Experion Detects the previous version of Experion on the computer. Starts the Install
Windows 10 Sequencer to perform migration to Experion with a choice to the user for an
(64-bit) operating system re-install or to retain the Operating system.

TIP
Refer to the Software Installation User's Guide for clean installation.

5.2.2 Controller migration scenarios


The migration of controllers and control hardware can be performed in a number of ways, depending
upon the system topology and the compliment of the installed I/O. Typical scenarios are described in
the following table. Note that controller migration is performed, after server/client migration is
completed.

- 48 -
Chapter 5 - Starting migration

Table 5.2 Controller migration scenarios


Controller Migration scenario Use the Controller Migration wizard
and…
On-Process Migration scenarios
On-Process migration, Redundant C200 Controller Chassis — Select redundant C200 controller
which includes redundant controller modules, such as CPM, chassis (primary and secondary
RM, CNI, IOLIM, FTEB, and FIM. The controller may reside chassis) at one time for on-process
either on the Supervisory Network or on a I/O Network migration. All redundant components in
(currently not supported for the CPM and IOLIM modules). the controller chassis are migrated at
once.
Also, individual controller interface
components in an RCP that are
redundant can be selected for
migration, such as FIMs and IOLIMs.
On-Process migration, Redundant C300 Controllers Select redundant controller modules for
migration.
On-Process Migration, Redundant FIM4/FIM8/PGM Select redundant Fieldbus Interface
Modules (FIM4/FIM8/PGM) for
migration.
On-Process Migration, Redundant EHPM Select redundant EHPM for migration.
On-Process migration, Redundant IEC61850M Select redundant IEC61850M for
migration.
Off-process Migration scenarios
Off-process Migration, Redundant Chassis Perform migration of redundant
controller chassis off-process. All
redundant components in the controller
chassis are migrated at once.
Off-process Migration, Non-Redundant Chassis Select a non-redundant controller
chassis for off-process migration. All
components in the controller chassis
(except I/O) are migrated at once.
Off-process Migration, Redundant C300 Controllers Select redundant controller modules for
migration.
Off-process Migration, Non-redundant C300 Controllers Select individual controller modules for
migration.
Off-process Migration, Non-redundant controller modules, Select individual controller modules for
(CPM, CNI, IOLIM, FIM, FTEB and LIOM) off-process migration.
Off-process Migration, Redundant FIM4/FIM8/PGM Select redundant Fieldbus Interface
modulesand PGM for migration.
Off-process Migration, Non-redundant FIM4/FIM8/PGM Select individual Fieldbus Interface
modules and PGM for migration.
Off-process Migration, Associated I/O modules Select Individual I/O modules for off-
process migration.
Off-process Migration, ACE/ SCE-ACE and SIM-C200 Select individual ACE/SIM-ACE or SIM-
C200 control nodes for off-process
migration.
Off-process Migration, Redundant EHPM Select redundant EHPM for migration.
Off-process Migration, Non-redundant EHPM Select individual EHPM for migration.
Off-process Migration, Redundant IEC61850M Select redundant IEC61850M for
migration.
Off-process Migration, Non-redundant IEC61850M Select individual IEC61850M for
migration.

- 49 -
Chapter 5 - Starting migration

5.2.3 migration
Site-specific migration guides to ): For migrations from R410.x onwards, you can generate a site-
specific migration guide using the Upgrade Tool. As per the site configuration, the Upgrade Tool
combines the migration guides available on the Experion PKS Upgrade Tool components media for the
nodes/modules in the Experion cluster. This document is automatically generated by the Upgrade Tool.

- 50 -
CHAPTER

6 USING TOOLS TO VERIFY UPGRADE


READINESS

Upgrade Tool (UT) can be used for performing upgrade readiness checks.

ATTENTION
For migration where the base release is , the UT must be used for any readiness checks for
servers and controllers.

Upgrade Tool (UT)


The Upgrade Tool checks the upgrade readiness of the nodes and its subsystems in an Experion
system. The Upgrade Tool is installed as a part of the Engineering tools installation. If you have
redundant servers, Upgrade Tool is installed on Server B. In case of non-redundant server, Upgrade
Tool is installed on the only server. The Upgrade Tool does not depend on any specific Experion
topology. In case of a redundant Experion configuration, the Upgrade Tool is run only on the Server B.
In case of a non-redundant Experion server configuration, the Upgrade Tool is run on the single
Experion server node. The Upgrade Tool ensures that it does not overload the Experion server.
Before starting an Experion upgrade, you have to verify the upgrade readiness of the Experion system
and prepare it for the upgrade. The Upgrade Tool automates the manual process of preparing the
Experion system for the upgrade. After the upgrade is complete, you can run the Upgrade Tool to
perform a post-upgrade analysis.
Upgrade Tool makes the upgrade readiness process effortless, easy, and error-free. It reduces the
manual information gathering time and minimizes the possibility of errors.
For more details, refer to Experion Upgrade Tool Users Guide .

- 51 -
CHAPTER

7 MIGRATION REFERENCE

Starting from R431.2, direct migration to point releases are supported. For more information refer to
Experion migration concepts section.

l Qualified migration paths


l Software requirements
l Hardware requirements
l Experion installation space requirements
l Experion migration space requirements
l Experion Migration Storage Node (EMSN) space requirements
l Multi-cluster migration scenarios
l Experion High Security Policy changes

7.1 Qualified migration paths

7.1.1 server/client migration paths

Migration paths illustrate the path for an Experion system migration from the base release (or current
release) to the target release (new release). A migration path may also include intermediate steps. For
more information, contact the HPS Migration Center of Excellence. Note that migration paths apply to
servers and clients. Table 6 lists the migration paths that are supported in Experion for Experion
Servers, Console, and Flex Stations. Refer to the Software Change Notice (SCN) available on the
Honeywell Process Solutions website (Honeywell Process Solutions website) for the most up-to-date
migration paths.

ATTENTION
The following on-process and off-process migration paths are supported for physical to virtual
and virtual to virtual migrations:
l Experion R410.x (with or without patches ) to Experion
l Experion R430.x (with or without patches ) to Experion
l Experion R431.x (with or without patches ) to Experion
l Experion R432.x (with or without patches ) to Experion
l Experion R500.x (with or without patches ) to Experion
l Experion R501.x (with or without patches ) to Experion

- 52 -
Chapter 7 - migration reference

Table 7.1 Server/client migration paths supported


Migration Supported for Documentation
Path to On- Off- References
process process
Migration Migration
X X Site-specific migration guides (): For migrations from R410.x onwards,
you can generate a site-specific migration guide using the Upgrade
Tool. As per the site configuration, the Upgrade Tool combines the
migration guides available on the Experion PKS Upgrade Tool
components media for the nodes/modules in the Experion cluster. This
document is automatically generated by the Upgrade Tool.

Scenario-specific migration guides (): , you can generate a scenario-


specific migration guide using the Upgrade Tool. As per the scenario
configuration, the Upgrade Tool combines the migration guides
available on the Experion PKS Upgrade Tool components media for
the nodes/modules in the Experion cluster. This document is
automatically generated by the Upgrade Tool.

For exact migration paths supported to target point release, refer to the latest target point release
Software Change Notice (SCN). For example, refer to the latest target release SCN.

7.1.2 controller migration paths

The qualified migration paths for migrating controllers, interface modules, and I/O module firmware to
Experion are determined using the Migration Readiness Tool/Upgrade Tool. Only valid firmware
release versions are listed in the Select Target Release box of the Controller Migration dialog box.
Refer the target point release Software Change Notice (SCN) document supplied with your software for
the most up-to-date migration paths. In the following table, on-process migration applies only to
redundant controller and I/O module components.

Table 7.2 Controller nodes supported for migration


Experion Control Hardware On- Off-
process process
migration
(Only if
redundant)
Controllers: X X

C200 (CPM), C200E, C300 (PCNT01 / PCNT02), EHPM, IEC 61850M and UOC
including CPM and all associated components can be migrated using Controller
Migration Wizard.

Interface Modules: X X
RM, IOLIM, FIM, FIM4, FIM8, PGM, FTEB, CNI, LIOM
I/O Modules:
Series C IOMs X X
Series A IOMs, Series H IOMs X
(non-redundant)
Application Environments:
ACE, SCE, SIMLIOM X
EHG X

7.2 system interoperability


Experion allows greater interoperability between nodes operating on different releases. You can use

- 53 -
Chapter 7 - migration reference

applications for engineering work and configuration and then download the changes to nodes
operating on different releases. However, there are restrictions to the engineering work and operations
during the migration. There are lesser restrictions after the servers are migrated, and controllers are
operating on an older release.
Interoperability rules in Experion are such that you can continue the engineering work and operations in
a multi-release environment in the same way as was done in the past in a single release environment.
The general restrictions in interoperability are as follows:
l Before migration:
o There are no restrictions if all connected clusters are at the same release and update
level.

l During migration while servers are in Dual Primary state:


o Configuration changes are restricted to ensure system integrity.
o A server and its associated client must be at the same release and update level in order to
connect. Clients can only connect to a server operating on the same release as the client.
o No engineering changes must be made to a cluster until all nodes within that cluster are
migrated to the same release and update level.
o Alarms and point data are typically accessible through DSA between clusters of different
releases and update levels both during and after migration. Refer to EMDB Interoperability
table in Enterprise Model Database (EMDB) interoperability section to see the release
interoperability of servers for DSA.

l After migration:
o In some cases, configurations from previous releases must be updated to the latest
version before changes can be made. For example after migration, user-defined custom
display and shape files need to be updated to the current release so that they can be used
in Station.
o Only a subset of engineering tasks may be available. For example, two clusters operating
at different releases; some engineering tasks which are available when working within a
cluster operating with the same release, may not be available when working on the cluster
operating with the different release.

Interoperability summary

7.2.1 Interoperability summary

Server interoperability with controllers

This section summarizes the release interoperability support between server and the various controller
type nodes.
In the table, Server Release represents all applications running in a server (such as Control Builder and
real time data cache) that interact with applications running in a controller, (such as CEEs). The table
indicates that Server interoperates with controllers operating with firmware.
Control Builder allows you to load and upload controllers operating with R410.x or later firmware. You
can edit, load, and upload controllers operating with firmware with the exception being that new
features available in are not applicable in controllers running with the older release firmware.

eServer interoperability

- 54 -
Chapter 7 - migration reference

Domain controller interoperability

A domain controller (server) used in an Experion system operates as an independent node and is
migrated separately. This section summarizes the interoperability of a domain controller in an Experion
system.

In the following table, the letters listed in each box represent the Experion components that can be
installed with the respective Experion release on that Domain Controller Operating System version.

DC Operating System / Domain Functional Level


Experion Release
used for DC Windows Windows Windows Windows Windows
Windows Server
installation Server Server 2008 Server Server 2012 Server
2003/2003 R2
2008 R2 2012 R2 2016
Experion PKS R400.1,
A+C, B, D A+C, D A+C*, D A+C*
R400.2
Experion PKS R400.3
A+C, B, D A+C, D A+C, D A+C
and later
A, B, C, D, A, B, C, D,
Experion PKS R410.X A, B, C, D A, B, C, D, E
E E
A, B, C, D, A, B, C, D,
Experion PKS R430.X A, B, C, D A, B, C, D, E
E E
A, B, C, D, A, B, C, D,
Experion PKS R431.X A, B, C, D, E A, B, C, D, E
E E
A, B, C, D, A, B, C, D,
Experion PKS R50X.X A, B, C, E A, B, C, D, E A, B, C, D, E
E E
A, B, C, D, A, B, C, D,
Experion PKS R510.X A, B, C, E A, B, C, D, E A, B, C, D, E
E E

l * – Requires patch
l A – DC security (required on one writable DC, not allowed on RODC)
l A+C – R400 DC Security including TPS Domain Console Configuration (required on at least one
writable DC, not allowed on RODC)
l B – FTE
l C – TPS Domain Console Configuration (optional on all writable DCs, not allowed on RODC)
(included in DC Security in R400.x)
l D – System Management
l E – USB Enable/Disable (R410 and later only)

Following are the rules related to the Experion PKS components installed on a Domain Controller:
l If multiple versions of Experion PKS coexist in a domain, the version of the Experion
PKScomponents installed on the Domain Controller must be equal to or greater than the latest
version of Experion PKS running in the domain (including point releases).
l If TPS and Experion coexist in a domain, the version of the Experion PKS components installed on
the Domain Controller must be equal to or greater than the latest version of Experion PKS running
in the domain (including point releases).
l The domain functional level of the domain (which is less than or equal to the Domain Controller
Server Operating System version) is restricted to the combinations above that indicate support for A
or A+C. For example, R431.1 supports Windows Server 2008 as the Domain Controller (indicated
by “A” in the R431.1/WS2008 box), however it does not support that Domain Controller being
configured as Windows Server 2003 Domain functional level (there is no A in the R431.1/WS2003
box).

- 55 -
Chapter 7 - migration reference

Windows client compatibility issues

Microsoft also imposes some rules related to client operating systems joined to a domain of certain
functional levels, as indicated in the following table.

Windows Domain Function Level


Clients Server Server Server 2008 Server Server 2012 Server
2003 2008 R2 2012 R2 2016
Windows XP/Server 2003 Y*** Y Y Y N N
Windows Vista/Server
Y* Y Y Y Y Y
2008
Windows 7 Y** Y Y Y Y Y
Server 2008 R2 Y** Y* Y Y Y Y
Windows 8/Server 2012 Y** Y** Y* Y Y Y
Windows 8.1/Server 2012
Y** Y** Y** Y* Y Y
R2
Windows 10/Server 2016 N Y** Y** Y** Y** Y

l Y – Supported
l N – Deprecated (SMB 1.0)
l Y* – Supported but requires GPO update
l Y** – Supported but requires GPO Update and some features in client may not be supported
l Y*** – Supported but not recommended.

C200 and C300 controller interoperability

Release interoperability for C200 and C300 controllers with other controller type nodes is summarized
in the following tables.

Controller CDA/Exchanges peer to peer connections

The following table lists the restrictions when setting up peer-to-peer connections between controller
type nodes operating on different releases.
As the previous table indicates, controller CDA/Exchange peer-to-peer from a C200 controller on R210
to a C300 controller on R3xx works only when the connection is defined (initiated) in the C300
controller.
As the previous table indicates, controller CDA/Exchange peer-to-peer from a C200 controller on R210
to a C300 controller on R3xx works only when the connection is defined (initiated) in the C300
controller.

Checkpoint file interoperability

The format of checkpoint files in a given release of Experion is unique so that the checkpoint files of one
release are not compatible with other Experion releases. For example, R410.x Checkpoint files are not
compatible with Experion Release . Similarly, checkpoint files are not compatible with Experion
Release R410.x. Therefore, you must execute Checkpoint Rebuild during migration, so that the
checkpoint file format conforms to the new server release. For example, a redundant R410.x server pair
is being migrated to - after Server B is migrated to .

- 56 -
Chapter 7 - migration reference

Enterprise Model Database (EMDB) interoperability

While migrating the EMDB, some functions are disabled. For example, the EMDB (and ERDB) are
locked to prevent any changes until migration is completed. Additionally, features which are available in
newer releases are not available on nodes operating at earlier releases until they are migrated to the
new release. For example, an EMDB server and a client that are migrated to can take advantage of
the features available with the new release, (for example, the Network Tree). The client (operating with
) can load EMDB changes to a server operating at the older release R4xx, but the network tree is not
available to use on the R4xx server. After the server is migrated to , the network tree is visible and
available on the server. The following figure illustrates the interoperability of the EMDB in multi-cluster,
where one cluster is operating with R410.1 and a second cluster has been migrated to . The Network
Tree is not present in R410.1, although the system definitions, assets, and alarm groups in the EMDB
database can be downloaded and uploaded from the cluster, where the system EMDB is located.

TIP
Server Runtime includes the EMDB that is loaded to the server. The dotted line between Server
Runtime and CB represents the synchronization of changes done in EM assets and used by the
Control Builder.

The following table shows the interoperability of EMDB across Experion releases. The same
interoperability rules applies for DSA communication.

NOTE
The interoperability defined here is limited to defining the Experion system as part of the EMDB
server (eg: for DSA) and configuration load in EMDB for Assets Alarmgroups etc. onto all the
configured servers.
R311.2 Server Patch243 for PAR1-J43NXT patch is mandatory on R311 system to ensure
interoperability.
R310 Server Patch680 for PAR1-K7N7TZ patch is mandatory on R310 system to ensure
interoperability.
R301.3 Server Patch093 for PAR1-WKEFV9 patch is mandatory on R301 system to ensure
interoperability.
Refer to respective patch SCNs for more details.

The following figure shows two clusters, one operating with R4xx and the other that has been migrated
to . EMDB interoperability is fully supported between the clusters. Note that interoperability is supported
also when the EMDB is located in the R4xxcluster. In other words, the EMDB can be located in either
cluster and still support full interoperability.

CAB interoperability

CAB types existing within the ERDB on servers, which are then migrated to and left unchanged, can be
loaded to servers, which are then migrated to ACE nodes.

- 57 -
Chapter 7 - migration reference

ATTENTION
After a CAB type is opened and edited by the build-time, it can no longer be loaded to an R410.x
ACE node. A CAB type, that is built or edited on an system, can be loaded only to an ACE node
operating with .

Related concepts
Server interoperability
Controller interoperability
Domain controller interoperability
eServer interoperability
Enterprise Model Database (EMDB) interoperability
Controller CDA/exchange peer-to-peer connections

Related topics
System interoperability concepts

7.3 Software requirements


l Software media requirements
l Microsoft and other Experion updates
l Reapplying software patches on servers
l Total Plant Network (TPN) software
l Honeywell Experion PKS Localization Media
l SCADA system communication protocols

Related concepts
Review software requirements
7.3.1 Software media requirements
Whether you are migrating to or installing Experion , you require the following software media for
upgrading either Experion Server or Station.
Honeywell Experion media:
l Experion PKS System Initialization media
l Experion PKS System Initialization Updates media
l Experion PKS Installation media 1
l Experion PKS Installation media 2. The latest point release Experion Support Software is available
as an ISO image on Honeywell Process Solutions website
(https://www.honeywellprocess.com/support). Use the ISO image content to create a DVD/media for
installing the latest Experion point release. For extracting contents to a media, use ISO extraction
software. For example, you can use Virtual Clone Drive software for extracting the contents to a
media.
l Microsoft Visual Studio for CAB Developer media. (optional, required only if CAB is selected).
l Experion Support and Maintenance media
l Microsoft SQL Server 2014 SP2
l Experion PKS with PMD controller media (optional)

For operating system, the following media are required.

- 58 -
Chapter 7 - migration reference

l Windows Server 2016 HPS OS reinstallation media


l Windows 10 (64-bit)HPS OS reinstallation media

7.3.2 Microsoft and other Experion updates


There are two types of updates or patches as follows:
1. Patches or updates that must be installed immediately after upgrading and before using the server.
In case of redundant servers, the patches must be installed immediately after upgrading each
server. Most of such updates are from third parties like Microsoft.
2. Patches or updates that need not be installed immediately after upgrading and before using the
server. You can use the server after the upgrade without installing the patch. In case of redundant
servers, such patches can be installed even after both the servers are upgraded. Most of such
updates are from Honeywell.

7.3.3 Reapplying software patches on servers


You may have installed patches for specific server issues. Some of these patches may not be included
in .
Use the following list to determine if you need to reapply any of the updates that are not included in . If
you have applied a patch with a patch number equal or greater than the number listed in the following
table, you may need to obtain and reapply a newer version of the patch that is compatible with Experion
Server/Client release.

From Release Patch Number (need to reapply after migration)


R400.1
R400.2
R400 SP2 208, 209
R400.3
R410.1
R410.2
R410.3 P003

ATTENTION
The base releases (for example, R311.2, R311.2 Server Patch 1) are all included in the R400.1
General Release. However, if you have installed a patch with a patch number greater than the
patch numbers mentioned in the table that you may need to reapply a newer patch.

About the patch number


The patch number is embedded in the name of the patch file.

Experion.RRelease.Subsystem.PatchNumber.PARNumber.zip
Release= The release of the product
PatchNumber= The patch number

PARNumber=PAR number of the issue reported


For example: ExperionPKS.R310.2.Server.Patch016.PAR1-APQ57X.zip
Release = R310.2
PatchNumber = 016

PAR Number = 1-APQ57X

- 59 -
Chapter 7 - migration reference

Refer to the patch install log, for the history of patches applied on the node. The default location of this
log file is as follows:
l For Server/ESVT/Console Station: C:\Program Files\Honeywell\Experion
PKS\Server\Setup\Software Update log.txt.
l For Flex Station/EST: C:\Program Files\Honeywell\Experion
PKS\Client\Setup\Software Update log.txt.

Patch log files

Patch log files

You may also refer to the Patch log for the history of patches applied on the node. The default location
of this log file is:

For Server/ESVT/Console Station - C:\Program Files\Honeywell\Experion


PKS\Server\Setup\Software Update log.txt.

For Flex Station/EST - C:\Program Files\Honeywell\Experion


PKS\Client\Setup\Software Update log.txt.

7.3.4 Total Plant Network (TPN) software


The minimum release level of TPN software that is fully compatible with Experion released software is
shown in the following table.

Compatibility for… LCN Software Release


ES-T and ESVT integration with any Experion release. R652.1 or later
ACE-T integration with any Experion release. R652.1 or later

Experion Release Series Minimum TPN System Software


R201, R21x , R301.x TPN R641.2
TPN R535.1 or later R5xx releases in this series.
TPN R652.1 or later R6xx releases in this series.

For more information about TPN software compatibility, refer to the latest Experion General Release
Software Change Notice.

ATTENTION
TPN R683.2 or later and Experion R410.x is required for:
l New TPS Console/System alarm integration
l Fully functioning integration for HMI Web TPS Detail Displays
Ensure that you are using the Utilities and Load Module (ULM) media that corresponds
to the Experion release for the proper version of the Z12 and Z14 emulated.

The following are required for ELCN Bridge and/or Experion LCN:
l TPN R687.1 or later
l Utilities and Load Module media R301.18 or later
l Experion R510.x or later

In Experion R310 release, the following are the functionalites that require LCN R680.

- 60 -
Chapter 7 - migration reference

l Uncertain quality for TPS points — OPC applications, currently has access to the existing value
quality field for the PV parameter fetch. However, this is not currently filled in from the PV parameter
fetch quality based on the PVSTS LCN parameter. This functionality provides the ability to return the
UNCERTN quality of PV in TPN server. This functionality is optional for the users and if not selected,
there is no change in the existing functionality.
l Disabled alarm indication — TPN server functionality is unaffected irrespective of optional activation
of the disabled alarm indication. TPN server must be able to ignore the new bit in the event record if
the option is activated. This is applicable to TPN server of both TPS and Experion.
The ESVT can use the flag in the event record and TPN server to store the disabled events in
Experion journal when the new bit of information is set, irrespective of the NCF option selected. The
functionality is leveraged to ESVT to identify alarms as disabled in its propagation to the Experion
alarm system. ESVT is used to supply operational alarm information, yet it is designed to be an
event logger. The use of the disabled indication allows TPN server not to propagate disabled
alarms to operational clients. For example, an alarm summary on flex station. TPN server must be
able to use the new bit in the event record to identify disabled alarms.

With LCN R681, the selective cutout feature allows the alarms of a point to pass through the secondary
point in the cutout state. The NIM, flag, numeric, regulatory control, regulatory PV, digital input, analog
input, digital composite, and device control points can be configured with the new parameters to enable
selective cutout. Selective cutout operates in combination with the contact cutout feature. This feature is
supported from R311 onwards.
Note that the latest versions of the EST and ESVT load modules must be used, which are: EST 68.1 and
ESVT 68.0. The load module software is located on the Utilities and Load Module CD, which can be
ordered through the Honeywell Process Solutions (HPS) Online Support web site.

7.3.5 Honeywell Experion PKS Localization Media


If the Experion system to be migrated is a localized system, the following additional software is needed.
l Experion PKS EUI pack - For the language of the base system.

For Microsoft Windows Server 2008 StandardandMicrosoft Windows Server 2008 R2 Standard:
l Microsoft Windows Server 2008 StandardandMicrosoft Windows Server 2008 R2 Standard MUI
pack CD for required language.
l Microsoft Office 2007 MUI pack CD

For Microsoft Windows 7 (64-bit):


l Experion PKS EUI pack CD (this pack contains the Language Pack Installer (LPI) which is used for
installing the language pack)
l Microsoft Office 2007 MUI pack CD

7.3.6 SCADA system communication protocols


Experion SCADA Server communicates with a variety of SCADA devices using different protocols (such
as, Modbus, Allen-Bradley, so on). Most of these protocols are not under control of Honeywell, but the
majority of these protocols have not changed. Unless there is a protocol change, it can be assumed that
the new releases of Experion Server continue to be compatible with the existing SCADA devices.

7.4 Hardware requirements


For list of supported platforms, refer to the latest Experion PKS System Initialization media Software
Change Notice. For information about software/hardware/firmware compatibility refer to the latest
Experion Software Change Notice .
If you are migrating a system which is not a supported platform for , you must perform a platform
hardware change during the migration to .

- 61 -
Chapter 7 - migration reference

For Windows-based Experion LCN nodes, the hardware platform must be supported by Microsoft
Windows 10 or Windows Server 2016.

ATTENTION
You cannot change the operating system type during a migration. For example, you cannot
change the server operating system to a workstation operating system during migration.

7.5 Experion installation space requirements


Experion installation using Experion PKS System Initialization media
The Experion system must have minimum of 60 GB hard disk space in C drive for the Experion PKS
System Initialization media to install the following:
l Operating system
l Operating system updates
l Drivers

Using the following method, calculate the minimum free hard disk space required for the operating
system installation: 55 GB (operating system + base Experion) + GB RAM size x 1.5 (page file) + GB
RAM size x 1.5 (dump file).
If the calculated value is greater than 60 GB, then 60 GB is the minimum free hard disk space required.
For example, in a system with 4 GB RAM, the minimum free hard disk space required for the operating
system installation is 67GB (55 + 4*1.5 + 4*1.5). Hence, 67 GB is the minimum free hard disk space
required for operating system installation.
If the calculated value is lesser than 60 GB, then the calculated value is the minimum free hard disk
space required. Hence, 60 GB is the minimum free hard disk space required for operating system
installation.

ATTENTION
l If you are installing Experion in custom installation path, refer to Custom installation path
section, for the disk space required for each of the custom install paths.
l The minimum space required in C drive (60 GB) is independent of default or custom
installation paths.
l The Experion PKS System Initialization media displays a warning if the recommended
disk space is not available, and does not allow you to install on C: drive.

Experion installation without using Experion PKS System Initialization media


The hard disk space requirement to install Experion without using Experion PKS System Initialization
media is as follows.

- 62 -
Chapter 7 - migration reference

l Default path: If you are planning to install Experion in the default path, each node must meet
minimum space requirements in C drive as follows.

Node Minimum space


Server (ESV) 32 GB
Server TPN Connected (ESVT) 32 GB
eServer 32 GB
Application Server (EAS) 32 GB
Application Control Environment (ACE) 14.5 GB
Application Control Environment TPN Connected (ACE-T) 14.5 GB
Simulation environments 14.5 GB
Experion Hiway Gateway (EHG) 14.5 GB
App Node (E-APP) 14.5 GB
PC Universal Station(PCUS) 14.5 GB
Console Station (ES-C) 28.5 GB
Console Station TPN connected (ES-T) 28.5 GB
Console Extension Station (ES-CE) 28.5 GB
Flex Station (ES-F) 28.5 GB
Collaboration Station 28.5 GB
Optional Components 4 GB
l Custom install path: If you are planning to install Experion in the custom installation path, the path
you select for each component must meet the minimum space requirements.

Experion Experion Experion


Third party application Software Runtime Data SQL Logs
Node (Default drive: C drive) path path path
Server (ESV) 17.5 GB 8.5 GB 5 GB 1 GB
Server TPN Connected (ESVT) 15 GB 8.5 GB 5 GB 1 GB
eServer 13.5 GB 5 GB 5 GB 1 GB
Application Server (EAS) 15.5 GB 7 GB 5 GB 1 GB
Application Control 9.5 GB 2 GB 2 GB 1 GB
Environment (ACE)
Application Control 9.5 GB 1.5 GB 2 GB 1 GB
Environment TPN Connected
(ACE-T)
Simulation environments 8 GB 1.5 GB 2 GB 1 GB
Experion Hiway Gateway 7 GB 1 GB 2 GB 1 GB
(EHG)
App Node (E-APP) 8.5 1 GB 2 GB 1 GB
Console Station (ES-C) 17.5 GB 9 GB 2 GB NA
Console Station TPN 16 GB 8.5 GB 2 GB NA
connected (ES-T)
Console Extension Station (ES- 16 GB 8 2 GB NA
CE)
Flex Station (ES-F) 16.5 GB 8 GB 2 GB NA
Collaboration Station 16.5 GB 8 GB 2 GB NA
PC Universal Station (PCUS) 3.5 GB 0.5 2 GB NA

- 63 -
Chapter 7 - migration reference

7.6 Experion migration space requirements


7.6.1 Experion migration with operating system change
Migration with operating system change uses the same space numbers that have been calculated for
the Experion installation without using Experion PKS System Initialization media (refer to the table in the
above section) along with the data present in the system. For example, size of the SQL database in the
system.

ATTENTION
If you are planning for migration with operating system change, then approximately 12 GB of hard
disk space is required on C: drive for operating system installation.

7.6.2 Experion migration without operating system change


Migration without operating system change uses the same space numbers that have been calculated in
the below table with the data present in the system. For example, size of the SQL database in the
system.

ATTENTION
If you are planning to use the local node (undergoing migration) as EMSN repository, then EMSN
space is added to the space calculated for software path.

The hard disk space requirement for migration without operating system change is as follows.
Default Path: If you are planning for migration without operating system change in the default path,
each node must meet minimum space requirements along with the data present in the system.

Node name Minimum space


Server (ESV) 29.5 GB
Server TPN Connected (ESVT) 29.5 GB
eServer 29.5 GB
Application Server (EAS) 29.5 GB
Application Control Environment (ACE) 10 GB
Application Control Environment TPN Connected (ACE-T) 10 GB
Simulation Environments 10 GB
Experion Hiway Gateway (EHG) 10 GB
App Node (E-APP) 10 GB
PC Universal Station (PCUS) 10 GB
Console Station (ES-C) 19 GB
Console Station TPN Connected (ES-T) 19 GB
Flex Station (ES-F) 19 GB
Collaboration Station 19 GB
Console Extension Station (ES-CE) 19 GB

- 64 -
Chapter 7 - migration reference

Custom install path: If you are planning for migration without operating system change in the custom
installation path, the path you select for each component must meet the minimum space requirements
along with the data present in the system.

OS Software Runtime SQL Logs


Node name path path path path
Server (ESV) 15.5 9 GB 4 GB 1 GB
GB
Server TPN Connected (ESVT) 15.5 9 GB 4 GB 1 GB
GB
eServer 15.5 9 GB 4 GB 1 GB
GB
Application Server (EAS) 15.5 9 GB 4 GB 1 GB
GB
Application Control Environment (ACE) 3 GB 4 GB 2 GB 1 GB
Application Control Environment TPN Connected 3 GB 4 GB 2 GB 1 GB
(ACE-T)
Simulation Environments 3 GB 4 GB 2 GB 1 GB
Experion Hiway Gateway (EHG) 3 GB 4 GB 2 GB 1 GB
App Node (E-APP) 3 GB 4 GB 2 GB 1 GB
PC Universal Station (PCUS) 3 GB 4 GB 2 GB 1 GB
Console Station (ES-C) 10.5 6.5 GB 2 GB NA
GB
Console Station TPN Connected (ES-T) 10.5 6.5 GB 2 GB NA
GB
Flex Station (ES-F) 10.5 6.5 GB 2 GB NA
GB
Collaboration Station 10.5 6.5 GB 2 GB NA
GB
Console Extension Station (ES-CE) 10.5 6.5 GB 2 GB NA
GB

7.7 Experion Migration Storage Node (EMSN) space


requirements
You can use the following as a guidance to calculate the EMSN space requirements.
To determine Total space (T), right-click Drive C: and click Properties. The used space is displayed in
the dialog box that appears.
The Base size in is the estimate for the Experion software installed in the server/client node, minus
Experion data and database files stored on the node.
Options include optional Experion software files (CAB) and other third-party applications, although the
applications are not saved or migrated forward during migration.
If you plan to use the same EMSN as storage for other node migrations, you must consider the
additional disk space needed. Space on the EMSN that was used for prior system migrations can be
recovered. Identify a system (computer name) in the EMSN file structure that has completed migration
and delete all folders and data located under the system name to free up space on the EMSN for future
migrations.

- 65 -
Chapter 7 - migration reference

Table 7.3 Experion Migration Storage Node estimated space


Node Type Total space (T) Base size (B) Options (O) Estimated EMSN
(Eg, CAB) Space needed
T - (B +O) = EMSN
Release 3xx.x
Process Server 8 GB + Options 8.7
SCADA Server, eServer 8.7 GB + Options 8.7
Process Flex Station, Console 9.6 GB 3 GB 12.6
Extension Station
Collaboration Station 9.6 GB NA 9.6
SCADA Flex Station, Console 9.6 GB + Options 12.6
Extension Station
Console Station 11 GB 3 GB 14
ACE, SCE 5 GB 1 GB 6
Formula: Total Space - (Base size + Options) = Estimated EMSN space
Options include CAB software, Third Party software and applications installed on
the node, so on.

7.8 Multi-cluster migration scenarios


Migration of systems that contain multiple clusters requires additional planning and considerations with
regard to preserving and updating the Enterprise Model (EM) and the Enterprise Model Database
(EMDB).

7.8.1 systems

ATTENTION
Migration from R3xx to requires multiple hops. However, DSA interoperability between 3xx and
are supported for letting one cluster complete multiple hops to during a migration scenario.
R311.2 Server Patch243 for PAR1-J43NXT patch is mandatory on R311 system to ensure
interoperability.

R310 Server Patch680 for PAR1-K7N7TZ patch is mandatory on R310 system to ensure
interoperability.
R301.3 Server Patch093 for PAR1-WKEFV9 patch is mandatory on R301 system to ensure
interoperability.
Refer to respective patch SCNs for more details.

For systems, you can migrate the servers in any order. For example in the following figure, if both
Cluster X and Cluster Y are running systems, either cluster can be migrated first. The following figure
shows the case where the EMDB server is still running with in Cluster X while Cluster Y has been
migrated to . In the case of a system with a EAS or non-redundant Experion Server (EMDB Sever), there
is no restriction on what server is migrated first. If you are migrating from R410.x) to , you must ensure
both EMDB and non-EMDB servers are migrated to before using Upgrade Tool.

- 66 -
Chapter 7 - migration reference

The following table presents migration scenarios for multi-cluster systems and also gives an indication
of the interoperability restrictions for the EMDB. Interoperability for the EM has been enhanced in
systems. See Enterprise Model Database (EMDB) Interoperability for more details.

7.9 Experion High Security Policy changes


The following changes are made in the R400.x version of the Experion High Security policy:
l The global group, previously named Engineering Repository Administrators is changed to ER
Admins. This group is created by both a global group and a local group in the domain and
workstation security packages.
l The Engineering Repository Users group is changed to ER Users. This group is not created by the
domain controller security package.
l The Link Domain Groups, which is part of the workstation package, is modified to make the global
ER Admins group, and the Engineering Repository Administrators group (if it exists), members of
the local ER Admins group.
l Also, if a local ER Users group exists, the domain Operators, Engineers, and Supervisors groups
are made members of this group.
Domains using the Engineering Repository Administrators and Engineering Repository Users
groups can find that new groups are created (ER Admins and ER Users) after installing the R400.x
Experion High Security Policy.
l The following permissions are added to the IE settings in the group policies.
o Allow binary and script behaviors.
o Run ActiveX controls and Plugins.
o Script ActiveX controls marked safe for scripting
o Allow Active scripting for all sites except Restricted
o Run ActiveX from CD.

Verify that the Internet Explorer settings do not adversely affect any other applications that use
Internet Explorer.

- 67 -
CHAPTER

8 MIGRATION PLANNING CHECKLIST


COLLECTION

The following tables contain queries that pertain to an Experion system installation. You can fill in the
tables with information that is relevant to your system. It is important to have this information at hand
when performing a system migration.
l System questions

8.1 System questions


Item Checklist question Checklist# Required Required Done? See topic in
for for migration guide
OPM? OffPM?
Preliminary questions
Is the Redundancy Option available Y N Migration license
in the license? If it is, then OPM is requirements
automatically available.
Have the latest updates for the Y Y Refer the section
Migration Readiness Tool been Obtaining the
downloaded from the online support latest Migration
website? Readiness Tool
(MRT) data files in
the Scenario-
specific migration
guides.
Have the latest updates for the ERDB Y Y Refer to the
Consistency Checker been Upgrade Tool
downloaded from the online support User's Guide.
website?
Are the software media for Experion 1 Y Y Review software
R510.1 and OS available? requirements
Are the software media for other 2 Y Y Total Plant
Honeywell Applications available? Network (TPN)
software
Are the software media for 3 rd party 3 Y Y Migrating non-
applications available? Experion
thirdparty
applications
System Architecture and Cluster Identification, Considerations for Migration
Create (or get) the system 4
architecture plan. Use this checklist
as a guideline to determine what
must be minimum included in the
System Architecture diagram.
Has each cluster boundary been Develop a

- 68 -
Chapter 8 - Migration Planning Checklist Collection

Item Checklist question Checklist# Required Required Done? See topic in


for for migration guide
OPM? OffPM?
identified in the System Architecture migration plan
Diagram?
Have the cluster and node migration 5 Y Server
sequence been identified? Needs to interoperability
consider interoperability restrictions. Enterprise Model
This is a very important Database (EMDB)
consideration, and need to consider interoperability
the process being viewed. During Develop a
migration, station is not be able to migration plan
view the process for a few hours, so Develop a
alternate security level or asset migration strategy
assignments may need to be done on
the stations that are not being Multi-cluster
migrated at that time migration
scenarios
Installing the
Domain Controller
package
eServer
interoperability
Have the back up imaging (Ghosting) See Backup and
sequence and steps, including Restore Guide
locations of images been identified?
Has EBR been positioned as the
Honeywell recommended solution for
this operation?
Is time topology for the system in Y Planning time
place that provides time synchronization
synchronization to all nodes during migration
throughout migration?
Has the BOOTP server location been 6 Refer the section
identified? Use the appropriate BOOTP service in
Server Specification Sheet Check list- the scenario-
6 to record this information. specific migration
guides and site-
specific migration
guide.
Have all other Honeywell 2 Total Plant
Applications in the system been Network (TPN)
identified and an Interoperability and software
migration plan defined? Use Check
list - 2 to record this plan
Have all the TPS node information 6, Related
been identified and recorded? Use documents
Check list — 6 and 7 (Server, station) 7
Have all Third Party Applications in 3 Migrating non-
the system been identified and a Experion
migration plan defined? Use Check thirdparty
list ? 3 to record this plan applications
Have the Experion Migration Storage 6, Identify a location
Nodes been identified for every stage for the Experion
7,
of the migration? Record this Migration Storage
information on the appropriate 8 Node(EMSN)
Computer Node Specification Sheets
( Check lists 6,7,8)

- 69 -
Chapter 8 - Migration Planning Checklist Collection

Item Checklist question Checklist# Required Required Done? See topic in


for for migration guide
OPM? OffPM?
Is the network topology to be Refer the section
changed, modified (includes new Re-configuring
Switches, changes in Switches, Ethernet, FTE
Changes from Control Ethernet and networks and
Control Net to FTE). Note that some migration in the
of these are off process. This plan scenario-specific
needs to be recorded using FTE migration guides
design guidelines and site-specific
migration guide.
Have compatibility and performance
tests been specified to verify that new
release software is acceptable.
Has a detailed time schedule of the Develop a
migration been prepared? migration
timetable
Computer Node Specification Sheets
Has a Server Specification Sheet 6 Review hardware
been filled out for every server in the requirements
system (A and B separately, Refer the section
ACE,SCE, eServer, and EMDB server Local Windows
not hosted on an Experion server), groups and local
including any proposed hardware user accounts in
changes? the scenario -
specific migration
guides and site-
specific migration
guide.
Has a Station Specification Sheet 7 Sub heading CAB
been filled out for each Station (ES C, Review hardware
ES T, ES CE, ESTE, ESF), including requirements
any proposed hardware changes?
Refer the section
Local Windows
groups and local
user accounts in
the Scenario-
specific migration
guides.
Has a Domain Controller 8 Review hardware
Specification sheet been filled out for requirements
each Domain Controller in the system Refer the section
(Primary and Back up?), including Local Windows
any proposed hardware changes? groups and local
Do you have a cascade domain user accounts in
configuration? If so, ensure that the scenario-
appropriate domain functional specific migration
controller and forest functional guides and site-
controller are selected. specific migration
guide.
Installing the
Domain Controller
package
HMIWeb and .dsp information
Has a list of customized displays Using Display
been prepared, including location, Builder and

- 70 -
Chapter 8 - Migration Planning Checklist Collection

Item Checklist question Checklist# Required Required Done? See topic in


for for migration guide
OPM? OffPM?
and plan for migration? HMIWeb Display
Builder
Controller Information
Has a Controller Specification Sheet 10 Refer the section
been filled out for every Controller in Rebuilding
the System (C200, includes CPM, Checkpoint files in
FIMs, IOLIMs; C300 and FIM4, FIM8; the scenario-
ACE, SCE, SIMC200, and SIMIOLIM) specific migration
Use Check List 10. guideand site-
specific migration
guide.

Refer the table


Pre-migration
checks for
controller
migration in the
scenario-specific
migration guide
and site-specific
migration guide.

l Checklist 1 - Experion and Windows Software


l Checklist 2 - Other Honeywell software
l Checklist 3 - Third Party software
l Checklist 4 - System architecture guidelines
l Checklist 5 - Cluster and node sequence questions
l Checklist 6 - Server specification sheet
l Checklist 7 - Station specification sheet
l Checklist 8 - Domain Controller specification sheet
l Checklist 9 - Controller

8.1.1 Checklist 1 - Experion and Windows Software

Item Checklist question Done? Notes


Are the following Honeywell media available? See Review software
requirements
Experion Client/Server Initialization DVD
Experion Installation Software media
EUI Pack of for the desired language (if the Contact Honeywell TAC.
current system is localized).
Is one of the following Microsoft Windows Server 2016 media
available? (OS for Server nodes)
Honeywell Process Solutions (HPS) re-
installation operating system (OS) media
Microsoft Windows Server 2016 CD
Is one of the following Windows 7 media available? (OS for Client
nodes)

- 71 -
Chapter 8 - Migration Planning Checklist Collection

Item Checklist question Done? Notes


Microsoft Windows 7 CD
Windows Server 2008 MUI Pack CD for desired language (if the Contact your IT/IS
current system is localized) department for the MUI
CD
Windows 7 MUI Pack CD for desired language (if the current system is Contact your IT/IS
localized) department for the MUI
CD

8.1.2 Checklist 2 - Other Honeywell software

Item Checklist question Applicable? Done? Notes


Is the media for the following Honeywell applications See Migrating other
available? Record the migration plan on a per application Honeywell products and
basis. applications for additional
information.
1 DVM - Digital Video Manager
See the Digital Video Manager User
Guide for details to migrate DVM client
and host components.
2 FDM - Field Device Manager
See the FDM Software Upgrade
Installation Guide for details to migrate
the Field Device Manager application.
3 Control Component Libraries (CCLs)
See ‘Control Component Libraries’ in
section Migrating other Honeywell
products and applications
4 Process History Database (PHD)
5 User Alert
6 EST/ESVT - Experion Server TPN.
7 Alarm Pager
8 Asset Manager
9 Business Flex
10 Da Vinci Server, Quality Server,
MxProLine Server
11 OMS
12 Operator Effectiveness
13 OptiVISION
14 PMD
15 POMS
16 Process Performance
17 Profit Suite
18 Safety Manager
19 Simulation
20 TPB
21 Uniformance

- 72 -
Chapter 8 - Migration Planning Checklist Collection

8.1.3 Checklist 3 - Third Party software

Item Checklist question Applicable? Done? Notes


List the media and migration considerations for each Third Party application.
1 Application name: (Virus Protection…)
2 Vendor Contact information
3 Is the media available?
4 Is the license key recorded?
5 Is the application compatible with the new operating system
requirement? This must be answered on a per computer node
basis.
6 Is this application interoperable with the new Experion
Release?
7 Is compatibility testing off line required to ensure that the
application operates in a stable manner?

8.1.4 Checklist 4 - System architecture guidelines

Item Checklist question Done? Notes


Topology diagram, show every node and network in the diagram. The following list of information that
are needed, on a per node and per network basis. Following is a list of nodes and networks shown
below.
Node name or identifier in network
All IP addresses for the node
Process area/asset assignment
Type of node (see list below)
Current release level and SP
What is the node for the BOOTP Server?
What is the sequence number for
migrating this node?
Does the node host the EAS?
What is the node the NTP Time Server?
List of nodes and Networks:
l PCN Network Components:
Routers, Level 3,2 and 1 switches
l Domain Controller(s)
l Experion servers : ESV, ESVT, ACE,
eServer, EMDB server (if
separate),SCE, EHG
l Experion stations : ES-C, ES-T, ES-
CE, ES-TE, ES-F
l Experion controllers : C200, IOLIM,
FIM, C300/C300 with EHB
personality configured, FIM4, FIM8
and PGM.
l Fieldbus network
l DeviceNet network
l Profibus network
l Supervisory Control Net- Ethernet
l ControlNet

- 73 -
Chapter 8 - Migration Planning Checklist Collection

Item Checklist question Done? Notes


l SCADA devices, including
controllers, PLCs, Terminal servers,
Serial adapters
l Intellatrac

8.1.5 Checklist 5 - Cluster and node sequence questions

Item Checklist question Done? Notes


Have the control clusters been identified?
A control cluster consists of ESV/ESVT server, associated
controllers, LCN, and Stations.
Multiple cluster systems
Does the system consist of multiple clusters, in a single
FTE community?
Is there a shared EMDB between clusters?
Has the EMDB interoperability plan for the shared EMDB For more information, see
been defined? Enterprise Model Database
(EMDB) interoperability
Restrictions on Interoperability of different releases on
section.
shared EMDB.
Has the interoperability plan for clusters that remain on For more information, see
base release been identified? Interoperability section.
Single and cluster systems
Have alternate station connections (considering security
and asset assignments) been identified, so that view to
process using station being migrated is not lost?
Node Sequence for migration
Recommended sequence of migration:

l Server B (Includes the EMDB)


l One Flex Station
l One Console Station
l Console Extension Stations (CES) connected to the
migrated Console Station
l Perform Compatibility Tests
l Remaining Flex Stations
l Remaining Console Stations
l Remaining Console Extension Stations (CES)
connected to the Console Stations
l eServer (migrate off-process only)
l Server A
l ACE and SCE nodes (migrated off-process)
l Control Firewall (CF9)
l Controllers

l Profibus, Devicenet, serial interfaces.


l Profibus migration needs to be done using a Profibus
tools

l SCADA device communications

- 74 -
Chapter 8 - Migration Planning Checklist Collection

8.1.6 Checklist 6 - Server specification sheet

Item Property Pre- Post-


migration migration
Main items
Experion Server Type (ESV, ESV Redundant, ESVT, ESVT Redundant,
ACE, SCE, eServer)
System type (non-redundant server / redundant primary server / redundant
backup server)
Computer Name
Dell Server Type
Domain Name
Location
Cluster Identity
Process Plant being controlled
Dell system service tag
Company name
Workgroup name
Customer name
Node number to be migrated
Is this node be migrated on-process or off-process?
Hardware configuration
CPU
Memory
Disk Drive
Dell Power Edge RAID Controller (PERC) type
Number of network interface cards (NICs)
CD/DVD drive types
Power Supply type
Network configuration
Domain Name System (DNS)
Windows Internet Naming System (WINS)

FTE community name (if using FTE)


FTE Device Index number
NIC #1
MAC address
IP address
Subnet mask
NIC #2 (if installed)
MAC address
IP address
Subnet mask
NIC #3 (if installed)
MAC address
IP address
Subnet mask

- 75 -
Chapter 8 - Migration Planning Checklist Collection

Item Property Pre- Post-


migration migration
NIC #4 (if installed)
MAC address
IP address
Subnet mask
ControlNet (PCIC) card installed (yes / no)
ControlNet MAC address
Other cards installed
PCIC
Serial Adapters
Other?
Software and Licenses
Experion Software version and update Level
What is the System release at this time? See:
1) ProductVersion.txt in Program files\Honeywell\Experion PKS\Engineering
Tools.

2) C:\Program Files\Honeywell\Experion PKS\Server\setup\software update


log.txt.
Verify that both servers have been upgraded consistently.
Experion License Key
Windows OS Version and SP level
Windows License keys
Server client access license mode (per server / per client)
Number of client licenses
List all ESV Options enabled on license
System-related questions
Does this Server host the EMDB?
For which cluster does this server host the EMDB?
Does this server host the BOOTP Service?
Does this server host the NT Time service?
Security and permissions
Document custom local user groups and custom local user accounts, folder
ACLs and so on
Local Group name
Local Group policy
Local Group members/accounts and passwords
Other local user accounts
Experion local user accounts
Backups and disk sizes
Disk size estimate for EMSN calculation
See Experion Migration Storage Node (EMSN) space requirements
Location and identity of the Ghost Image
Location and identity of the EBR image (if used)
Other questions
Has the Migration Readiness Tool (MRT) MRT been run on this node?

- 76 -
Chapter 8 - Migration Planning Checklist Collection

Item Property Pre- Post-


migration migration
Does MRT report any errors or warnings?
Has the Migration Readiness checklist found in the Tools SCN been
executed?
Has this node/system been migrated to migrate from a previous update
(R201) or software update or service pack (R210) using OPM?
TPN Node information
Need to add from the screen capture, and make a table for recording data

8.1.7 Checklist 7 - Station specification sheet

Item Property Pre- Post-


migration migration
Main items
Experion Station Type (ESC, EST, ESCE, ESTE, ESF)
Computer Name
Dell Server Type
Domain Name
Location
Cluster Identity
Process Plant being controlled
Dell system service tag
Company name
Workgroup name
Customer name
Node number to be migrated
Is this node be migrated on - process or off - process?
Hardware configuration
CPU
Memory
Disk Drive
Dell Power Edge RAID Controller (PERC) type
Number of network interface cards (NICs)
CD/DVD drive types
Power Supply type
Is the Station in an Icon Console?
If yes, number of video displays
What is the keyboard type?
Standard (Qwerty) yes/no
Integrated keyboard (IKB) (yes / no)
Operator entry panel (OEP) and standard (yes / no)
Is a TouchScreen present?
If yes, type of TouchScreen (USB or Serial)
If Serial, COM port used (COM1 or COM2)
Network configuration
Domain Name System (DNS)

- 77 -
Chapter 8 - Migration Planning Checklist Collection

Item Property Pre- Post-


migration migration
Windows Internet Naming System (WINS)
FTE community name (if using FTE)
FTE Device Index number
NIC #1
MAC address
IP address
Subnet mask
NIC #2 (if installed)
MAC address
IP address
Subnet mask
NIC #3 (if installed)
MAC address
IP address
Subnet mask
NIC #4 (if installed)
MAC address
IP address
Subnet mask
ControlNet (PCIC) card installed (yes / no)
ControlNet MAC address
Other cards installed
PCIC
Serial Adapters
Software and Licenses
Windows OS Version and SP level
Windows License keys
Is CAB Developer license loaded on this Station?
Security and permissions
Document custom local user groups and custom local user accounts, folder
ACLs and so on
Local Group name
Local Group policy
Local Group members/accounts and passwords
Other local user accounts
Experion local user accounts
Backups and disk sizes
Disk size estimate for EMSN calculation See Experion_Migration_Storage_
NodeEMSN_space_requirements_R400.1.html#id-Ref153798537__id-
Ref139694446.
Location and identity of the Ghost Image
Location and identity of the EBR image (if used)
TPS Node information
Need to add from the screen capture, and make a table for recording data

- 78 -
Chapter 8 - Migration Planning Checklist Collection

8.1.8 Checklist 8 - Domain Controller specification sheet

Item Property Pre- Post-


migration migration
Main items
Computer Name
Dell Server Type
Domain Name
Location
Cluster Identity
Process Plant being controlled
Dell system service tag
Company name
Workgroup name
Customer name
Node number to be migrated
Is this node be migrated on process or off process?
Hardware configuration
CPU
Memory
Disk Drive
Dell Power Edge RAID Controller (PERC) type
Number of network interface cards (NICs)
CD/DVD drive types
Power Supply type
Network configuration
Domain Name System (DNS)
Windows Internet Naming System (WINS)
FTE community name (if using FTE)
FTE Device Index number
NIC #1
MAC address
IP address
Subnet mask
NIC #2 (if installed)
MAC address
IP address
Subnet mask
NIC #3 (if installed)
MAC address
IP address
Subnet mask
NIC #4 (if installed)
MAC address
IP address
Subnet mask

- 79 -
Chapter 8 - Migration Planning Checklist Collection

Item Property Pre- Post-


migration migration
Software and Licenses
Windows OS Version and SP level
Windows License keys
Backups and disk sizes
Disk size estimate for EMSN calculation
See Experion Migration Storage Node (EMSN) space requirements
Location and identity of the Ghost Image
Location and identity of the EBR image (if used)
Other questions and Active directory settings
Document Active directory Settings
Document custom local user groups and custom local user accounts,
folder ACLs and so on
Local Group name
Local Group policy
Local Group members/accounts and passwords
Other local user accounts
Experion local user accounts
Document custom global user groups
Custom Global Group name
Custom Global Group policy
Custom Global Group members/accounts and passwords

8.1.9 Checklist 9 - Controller

Item Checklist question Done? Notes/Property


Value
Summary questions
Type of Controller: CPM (C200), FIM, IOLIM, C300/C300 with EHB
personality configured, FIM4, FIM8, C I/O, ACE, SCE, SIM IOLIM, and
PGM.
Redundant or Non-redundant
Node number to be migrated
Is this node be migrated on process or off process?
To which Experion cluster/server does this controller connect to?
Server name
IP address
What is Supervisory Control Network type for this controlle (FTE,
ControlNet, Ethernet)?
If upgrading the Supervisory Control Net to FTE, note that it must be done
off process.
Cabinet location and identifier (if C200 or Series C)
Base IP address (BOOTP Service)
FTE device index
Computer name (if ACE or SCE)
IP address — FTE Yellow
IP address — FTE Green

- 80 -
Chapter 8 - Migration Planning Checklist Collection

Item Checklist question Done? Notes/Property


Value
Are there HART devices connected to the controller?
Does the controller connect to FieldBus?
Does the controller connect to DeviceNet?
Does the controller connect to ProfiBus?
Initial ERDB checks (common for all Controllers connected to the same Warning that
server) ERDB must be
free of errors,
in server and
controllers
Run the ERDB Checker (on Server B, if redundant servers). Are any
errors reported?
(Question only applies if answer to previous question is yes)
Was an ERDB restore performed (Using DBADMIN “Restore Database”)
or a ghost restore performed without reloading all of the controllers, since
the controller firmware was upgraded?
Checkpoints and backups
Does the system use any CCL blocks?
If yes, then create a backup of the CCL, and record the path name to the Copy this over
backup. after migration
Has a manual checkpoint save been done for this controller, prior to start
of migration? Record date and time stamp of the checkpoint file
C200 questions
Use NTools to check C200 controller firmware revisions. Are any C200
controllers running R101 or releases earlier than R201 update 23 or
R210 update 10?
Has the Controller been scanned for unsupported modules?
Replace or correct firmware version. This is an off process step
The Controller Migration wizard supports only Honeywell qualified
module types and firmware versions
What are the CNI module numbers in controller and I/O chassis?
Honeywell recommends that all controllers and I/O chassis contain CNI
module numbers CCN013 or CCR013.
A RCP must only contain CNI module numbers CCN013/CCR013 or
CCN014/CCR014 for on-process migration.
ControlNet communication paths with FIMs or HART I/O modules must
only contain CNI module numbers CCN013 or CCR013. However, legacy
CCN012 or CCR012 CNI modules can reside in non-redundant controller
or I/O chassis that do not contain FIMs or HART I/O modules.
Fieldbus questions
Does the ERDB checker report any Fieldbus issues?
Was Bulk Edit or Bulk build ever used on the system?
Has ERDB checker version 02-024 (or later) been executed on your
ERDB?
Control strategy questions
Identify and rectify dangling Control Connections.
Refer to Dangling Control Connections in the Migration Readiness tool.
Review and must ensure that all peer references in the C200/C300 CEE
are working as expected before starting the on-process migration.

- 81 -
Chapter 8 - Migration Planning Checklist Collection

Item Checklist question Done? Notes/Property


Value
Peer references that do not work usually indicate a configuration
mismatch between the ERDB and the controller. Such a mismatch can
result when the peer definition block is reconfigured and reloaded, but
the block with the peer reference is not subsequently reloaded. This
condition must be fixed before starting on-process migration, otherwise,
the controller migration fails to complete
Record the BASEPERIOD setting for the CEEFB.
If the BASEPERIOD setting is DEFAULT, then do not start on process WARNING
migration. Call Honeywell TAC
Have ACE loops been evaluated to see the effect of off process
migration?

- 82 -
Notices
Trademarks
Experion®, PlantScape®, SafeBrowse®, TotalPlant®, and TDC 3000® are registered trademarks of
Honeywell International, Inc.
ControlEdge™ is a trademark of Honeywell International, Inc.
OneWireless™ is a trademark of Honeywell International, Inc.
Matrikon® and MatrikonOPC™ are trademarks of Matrikon International. Matrikon International is a
business unit of Honeywell International, Inc.
Movilizer® is a registered trademark of Movilizer GmbH. Movilizer GmbH is a business unit of
Honeywell International, Inc.

Other trademarks
Microsoft and SQL Server are either registered trademarks or trademarks of Microsoft Corporation in the
United States and/or other countries.
Trademarks that appear in this document are used only to the benefit of the trademark owner, with no
intention of trademark infringement.

Third-party licenses
This product may contain or be derived from materials, including software, of third parties. The third
party materials may be subject to licenses, notices, restrictions and obligations imposed by the licensor.
The licenses, notices, restrictions and obligations, if any, may be found in the materials accompanying
the product, in the documents or files accompanying such third party materials, in a file named third_
party_licenses on the media containing the product, or at
http://www.honeywell.com/ps/thirdpartylicenses.

Documentation feedback
You can find the most up-to-date documents on the Honeywell Process Solutions support website at:
http://www.honeywellprocess.com/support

If you have comments about Honeywell Process Solutions documentation, send your feedback to:
[email protected]
Use this email address to provide feedback, or to report errors and omissions in the documentation. For
immediate help with a technical problem, contact your local Honeywell Process Solutions Customer
Contact Center (CCC) or Honeywell Technical Assistance Center (TAC).

How to report a security vulnerability


For the purpose of submission, a security vulnerability is defined as a software defect or weakness that
can be exploited to reduce the operational or security capabilities of the software.
Honeywell investigates all reports of security vulnerabilities affecting Honeywell products and services.
To report a potential security vulnerability against any Honeywell product, please follow the instructions
at:
https://www.honeywell.com/product-security

Support

- 83 -
For support, contact your local Honeywell Process Solutions Customer Contact Center (CCC). To find
your local CCC visit the website, https://www.honeywellprocess.com/en-US/contact-us/customer-
support-contacts/Pages/default.aspx.

Training classes
Honeywell holds technical training classes that are taught by process control systems experts. For more
information about these classes, contact your Honeywell representative, or see
http://www.automationcollege.com.

- 84 -

You might also like