UOC UserGuide

EXPERION PKS
RELEASE 516
UOC User Guide

EPDOC-X512-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 12
1.1 Revision history 12
1.2 Related documents 12
1.3 Terms and definitions 15
Chapter 2 - Overview of UOC features 19
2.1 Native Experion Integration 19
2.2 ControlEdge 900 Form Factor 19
2.3 FTE Uplink Connectivity 20
2.4 Ethernet I/O Connectivity 20
2.5 ControlEdge 900 21
2.6 Field Device Manager 22
2.7 EtherNet/IP Connectivity to I/O, Devices, and Controllers 22
2.8 CEE Control Processing 22
2.9 Control Builder Strategy Configuration 22
2.10 I/O Points and I/O Reference Blocks 23
2.11 Simulation 23
2.12 Control Redundancy 23
2.13 Peer-To-Peer Communication 24
2.14 Alarms and Events 25
2.15 Time Synchronization 25
2.16 Security 25
2.17 Licensing 25
2.18 vUOC 26
Chapter 3 - Networking 29
3.1 Uplink FTE Network 29
3.2 Downlink I/O Network Topology 30
3.2.1 HSR Ring Topology with 900 I/O 31
3.2.2 Redundant Star (PRP) Topology with 900 I/O 34
3.2.3 DLR Ring Topology with EtherNet/IP and 900 I/O devices 35
3.2.4 Non-Redundant Star to 900 I/O and EIP Devices 38
3.2.5 EtherNet/IP in Experion 40
-3-
Chapter 4 - Installation 43
4.1 Hardware Considerations 43
4.2 Firmware Considerations 43
4.2.1 Converting PLC CPM to UOC CPM 44
4.2.2 Upgrading UOC CPM to New Firmware Version 48
4.2.3 Upgrading UOC EPM to new Firmware Version 48
4.2.4 Upgrading UOC UIOM to new Firmware Version 50

4.2.5 Firmware and Software Upgrade Considerations for vUOC 51
4.2.6 Additional Maintenance Activities in Firmware Manager 51
Chapter 5 - Configuration 52
5.1 Configuration Studio 52
5.2 Define and add assets in your enterprise model 52
5.3 Control Building 52
5.4 Specifying a Time Server 52
5.5 FTE Device Index 52
5.6 Creating UOC Platform block 53
5.6.1 Method 1: Using the File Menu 53
5.6.2 Method 2: Using the Project Assignment Panel 53
5.7 UOC Platform Block 54

5.8 Secondary UOC Platform Block 69
5.9 CEE Function Block 70
5.10 Configure UOC for Retention Startup 80
5.10.1 Introduction 80
5.10.2 Configure RETENTIONTRIG block 80
5.10.3 Loading Retention Trigger Block 97
5.11 Configure ControlNet for UOC 103

5.12 Configure ProfiNet for UOC 104
5.13 Configuring DLR for UOC 104
5.14 Convert a non-redundant UOC to a redundant controller 106
5.14.1 Prerequisites: 106
5.14.2 To convert a non-redundant UOC to a redundant controller 106
5.15 Convert a redundant UOC to a non-redundant controller 107

5.15.1 Prerequisites 107
5.15.2 To convert a redundant UOC to a non-redundant controller 107
-4-
5.16 Licensing Model 107
5.16.1 I/O Analog/Digital point(s) license 107
5.16.2 Composite Device Point(s) License 108

5.16.3 License Matrix 108
Chapter 6 - Load Configuration 110

6.1 About load operations 110
6.1.1 Loaded versus project database versions 110
6.1.2 Load initiation and load dialog box 110
6.1.3 Load action with Compare Parameters function 111
6.1.4 Load options for server history and server displays configuration 111
6.2 Initial load order guidelines 112

6.2.1 Component deletion considerations 112
6.3 Load components from Project 113

6.3.1 Loading UOC 113
6.3.2 Loading CEE 115

6.3.3 Loading I/OMs and CMs 117
6.4 Load With Contents command 117

6.5 Reloading components from project 117
6.6 Upload to the Monitoring database 118
Chapter 7 - ControlEdge 900 I/O Device Connectivity 119
7.1 CE900 IO in UOC 119
7.1.1 Model numbers 120
7.1.2 ControlEdge 900 IO Version Compatibility Matrix 120
7.2 UOC Configuration 121

7.3 Controller Rack 123
7.3.1 Rules 123
7.3.2 Creating Controller Rack 123
7.3.3 Method 1: Using the CE900_I/O library 123
7.3.4 Controller Rack Configuration 125
7.3.5 I/OM Status Summary 125
7.4 I/O Rack (EPM) 126

7.4.1 Rules 126
7.4.2 Creating I/O Rack 127
7.4.3 Hardware Information 127
7.4.4 Soft Failures and Alarms 127
7.5 I/O Module 128
-5-
7.5.1 Rules 128
7.5.2 I/O Module Creation 128
7.6 Channel 130

7.6.1 Rules and Behaviors 130
7.6.2 Channel Type Configuration 130
7.6.3 Channel Configuration and Status 133
7.6.4 Soft Failures and Alarms 135
7.7 I/O Module Configuration 139

7.7.1 Maintenance 139
7.7.2 Module Configuration/Monitoring Tabs 140
7.7.3 Common CE900 Module Configuration/Monitoring Tabs 141
7.7.4 CE900 UIO DI Channel NAMUR Configuration/Monitoring Tabs 145
7.7.5 CE900 UAI Module Configuration/Monitoring Tabs 146
7.7.6 CE900 DI32-24VDC Module Configuration/Monitoring Tabs 149

7.7.7 CE900 DO32-24VDC Module Configuration/Monitoring Tabs 151
7.7.8 CE900 DI16-VAC Module Configuration/Monitoring Tabs 153

7.7.9 CE900 DO08-VAC Module Configuration/Monitoring Tabs 155
7.7.10 CE900 DI16-DRYCT Module Configuration/Monitoring Tabs 156
7.7.11 CE900 DO08-RELAY Module Configuration/Monitoring Tabs 158
7.7.12 CE900 AO04 Module Configuration/Monitoring Tabs 160

7.7.13 CE900 AI16-100MS Module Configuration/Monitoring Tabs 162
7.7.14 CE900 AO08 Module Configuration/Monitoring Tabs 164
7.7.15 CE900 DI16-VACDC Module Configuration/Monitoring Tabs 166

7.7.16 UIO Namur Support 168
Chapter 8 - EtherNet/IP Device Connectivity 170

8.1 EtherNet/IP Device Configuration in UOC 170
8.1.1 Slot 0 Diagnostic Information 171
8.1.2 Slot 0 Configuration 172
8.1.3 Configuring the EtherNet/IP GenAdapter Block 173
8.1.4 Configuring the IP address of an EtherNet/IP device 179
8.1.5 Configuring I/O module blocks 179
8.1.6 Assigning EtherNet/IP devices to the CEE 181

8.1.7 Configuring I/O Ref blocks in CMs to access data from EtherNet/IP devices 181
8.2 Configuration Parameters for arrayed custom parameters 182

8.3 Configuration Parameters for scalar (non-arrayed) custom
parameters 186
8.4 Scaling support for Generic Device 187
-6-
8.4.1 Scaling Configuration Tab 187
8.4.2 Configuration 188
8.4.3 To view and modify the scaling parameters in EtherNet/IP generic device
instances 188
8.5 UOC and ControlLogix integration 189

Chapter 9 - UOC Node Redundancy Operation 191
9.1 Redundancy configuration restrictions 191
9.1.1 FTE Device Index 191
9.2 Partner controller compatibility 191

9.2.1 Redundancy compatibility result - RDNCMPT 192
9.3 UOC 1-slot I/O rack 194

9.4 Redundancy synchronization 194
9.4.1 Synchronization states - RDNSYNCSTATE 194
9.4.2 Enable Synchronization - ENBLSYNCCMD 195
9.4.3 Disable Synchronization - DSBLSYNCCMD 195
9.4.4 Auto-Synchronization State - RDNAUTOSYNC 195

9.4.5 Inhibit Sync Reason - RDNINHIBITSYNC 196
9.4.6 Initial Sync Progress - RDNSYNCPROG 198
9.4.7 Maximum Initial Synchronization Time - RDNISTIMEMAX 198

9.4.8 Last Synchronization Time - SYNCTIMEBEG 198
9.4.9 Last Lost of Sync Time - SYNCTIMEEND 198
9.4.10 Redundancy Traffic Rate 198

9.4.11 Conditions that result in loss of sync 199
9.4.12 Conditions that do not result in loss of sync 199
9.5 Switchover and secondary readiness 199

9.5.1 Become Primary command - BECMPRICMD 200
9.5.2 Initiate Switchover - SWITCHCMD 200
9.5.3 Max Switchover Time - RDNSOTIMEMAX 200
9.5.4 Conditions that result in switchover 200
9.5.5 Conditions that do not result in a switchover 201
9.5.6 Network switchover considerations 202
9.6 Redundancy history 202

Chapter 10 - Operation 203
10.1 UOC States And Transitions 203
10.2 UOC Front Panel Indications 206
10.2.1 Ethernet Port LEDs 206
10.2.2 Behaviors of Status and Redundancy Role LEDs 206
-7-
10.2.3 Status LED 207
10.2.4 Redundancy Role LED 211
10.3 UOC Startup 212

10.3.1 Actions During Boot 212
10.3.2 Restart After Power Loss 214
10.3.3 vUOC States and Startup Behaviors 214
10.4 Using Station displays 214

10.4.1 Identifying UOC 215
10.4.2 UOC Controller Point Detail Display (Redundant) 215
10.4.3 UOC Controller Point Detail displays (Non- Redundant) 219
10.4.4 vUOC Controller Point Detail displays 223
10.4.5 UOC-CPM (Local I/O) Racks 226
10.4.6 UOC-EPM Racks 227
10.4.7 UIO Racks 228
Chapter 11 - Troubleshooting 230

11.1 What to do when faults occur 230
11.2 Initial checks 230
11.3 Checking Control Builder error code reference 230
11.3.1 Checking faceplate LEDs 230
11.3.2 Using Firmware Manager to capture diagnostic data 231

11.3.3 Viewing release information log 231
11.3.4 Checking server point build log 231
11.3.5 Checking server point build error log 232
11.3.6 Checking error log 232
11.4 Fixing common problems 232

11.4.1 Loss of power 232
11.4.2 Power-On Self Test (POST) does not complete 232
11.4.3 Module does not complete startup 233
11.4.4 One or both FTE LEDs are OFF 234

11.4.5 FTE receive fault diagnostic 234
11.4.6 Controller does not synchronize with backup 236
11.4.7 Fatal ECC error 236
11.4.8 Isolated (lonely) Node 237
11.4.9 Duplicate Device Index detection 238
11.5 UOC Controller soft failures 239

11.6 Additional status and fault messages 245
11.6.1 Redundancy-related notifications 245
-8-
11.6.2 OPM-related notifications - RDNOPMSTATUS parameter 245
11.7 Online diagnostics 245

11.8 Fault classifications 246
11.8.1 Hard/Severe Failures 248
11.8.2 UOC Redundancy Communication Issues if CPM is not securely connected
to the rack 249
11.8.3 Soft Failures 249
11.8.4 Installation-Startup Failures 250
11.8.5 Hardware Watchdog Timer Expired 250
11.8.6 Communications Failure 250
11.9 Communications and system time faults during startup 250

11.9.1 Non-redundant UOC Controller 251
11.9.2 Redundant Primary UOC Controller 252
11.9.3 Secondary UOC Controller 254
11.10 Gathering information for reporting problems to

Honeywell 257
11.11 Guidelines for requesting support 257
Chapter 12 - Control Execution Environment 258
12.1 Functional Highlights 259
Chapter 13 - vUOC 260
13.1 Introduction 260
13.1.1 vUOC controllers with Private Path and Downlink I/O adapters 260
13.1.2 Flat Network Downlink I/O Topology 261
13.1.3 VLAN Tagged Network Downlink I/O Topology 262
13.1.4 Network Downlink I/O Topology 263
13.2 Guidelines for integration of virtual controllers 264

13.3 Creating Network Connections 265
13.3.1 Creating a Standard vSwitch 266
13.4 Defining Port Groups 272

13.4.1 Adding a Port Group to a Standard vSwitch 272
13.5 Physical network support for VLAN topologies 276

13.5.1 First level Switch configurations 276
13.5.2 Downstream Switch configurations 278
13.5.3 I/O Device Port configurations 280
13.5.4 Control Edge 900 IO and Switch Configurations 281
13.6 Download 282
-9-
13.7 vUOC Deployment 282
13.7.1 Reconfigure Network Assignments 289
13.8 vUOC Provisioning (first-time start up only) 290

13.9 vUOC Configuration and Usage 293
13.10 vUOC and Virtualization Host Maintenance 293
13.11 vUOC and Virtualization Host Availability 296
13.11.1 Turning on Fault Tolerance protection for vUOC 296
13.11.2 Disabling Fault Tolerance protection for vUOC 298
Chapter 14 - Performance and Capacity Considerations 300

14.1 Key Specifications 300
14.2 Managing Processing Load 302
14.2.1 Relevant Parameters 302
14.2.2 Overall Load Limits 303
14.2.3 Cycle Overruns 304
14.2.4 CPU Free 304
14.2.5 Redundancy Throughput 305
Chapter 15 - Security Guidelines for UOC 306

15.1 General 306
15.2 Organizational Security 306
15.3 Physical Security 306
15.4 Communication Hardening 307
15.5 Securing Connection to Uplink Network 307
15.6 Securing Connection to Downlink Network 307
15.7 Maintenance, Configuration and Operation 308
15.8 Third Party Configuration Files 308
15.9 Third Party Firmware Files 308
15.10 Private Redundancy Network Path 308
15.11 Patch Management 309
15.12 Backup/Recovery Capability 309
Chapter 16 - Configuring a Secure Connection for Experion Integration 310
16.1 Secure Communications 310
16.1.1 Secure Communication System Planning 312
16.1.2 Configure and Setup Steps 312
16.1.3 Advanced Technical Information 313
- 10 -
16.1.4 Certificate Management 313
16.1.5 Secure Communications using IPSec 313
16.1.6 Secure Commuincations Using TLS 314
16.1.7 Secure Boot 314
16.2 Obtaining and Installing the software 314

16.3 Overview of an IPSec deployment 315
16.4 Set Enrollment Information 316
16.5 Creating the Certificate Authority 316
16.6 Creating a certificate for Engineering Station and Console 320
16.6.1 Creating a certificate 321
16.6.2 Importing certificate and private key on target machine 322
16.7 Configure ControlEdge UOC for use with IPSec 329

16.7.1 Installing Certificate Manager Configuration Console 329
16.7.2 Setup certificates and IPSec policy in UOC 338
16.8 Configuring IPSec to secure traffic to the UOC 347

16.8.1 Configure and Activate Security Policies 347
16.8.2 Enable IPSec policy on PCs 347

16.8.3 Disable IPSec policy on Engineering Station/Console 351
16.8.4 Enable IPSec policy rules in the UOC 351
16.8.5 Disable IPSec policy rules in the UOC 353
16.9 Backup and Restore of CA 355

16.9.1 Backup 355
16.9.2 Restore 361
16.10 Renewal and revocation of certificates 365

16.10.1 CA Root certificate 365
16.10.2 Renewing the CA Root certificate 366
16.10.3 PC certificates 367
16.10.4 Revocation 367
16.10.5 UOC certificates 370
16.10.6 Revocation 370
16.11 Troubleshooting 370

16.11.1 How to reset UOC for IPSec configuration? 370
16.11.2 How to reset IPSec configuration on Windows? 371
16.11.3 Diagnosing IPSec with Network Analysis Software 371
16.11.4 If CMCC upload a large number of policies, the read data from the
transport connection can not be received 371
- 11 -
CHAPTER
1 ABOUT THIS GUIDE
1.1 Revision history
Revision Date Description

A August 2020 Initial release of the document.
1.2 Related documents

The following list identifies publications that may contain information relevant to the information
in this document. You can find these documents on https://www.honeywellprocess.com/en-
US/support/pages/all-documentation.aspx.
- 12 -
Chapter 1 - About this guide
Document Description
Firmware This document describes the tool used for loading
Manager User firmware to hardware modules of the UOC system and for
Guide_EPDOC- uploading diagnostics information from them.
X470.pdf
Hardware This document describes hardware components and

Planning and related installation practices for the ControlEdge 900
Installation family of controller hardware.
Guide_HWDOC-
X430-en-H.pdf
Virtualization This guide provides high-level guidance on how to

Planning and implement a virtualized Experion environment.
Implementation
Guide_EPDOC-
X147-en-A.pdf
EtherNet_IP_ This document provides an overview of the use of

Users_Guide_ EtherNet/IP™ communications with level 1 Experion
EPDOC-X399- control systems and offers practical guidance to perform a
en-511A.pdf successful integration of EtherNet/IP with Experion.
Fault_Tolerant_ This guide contains basic installation instructions and

Ethernet_ configuration requirements for an FTE network and its
Overview_and_ components. Detailed network planning and requirements
Implementation_ information is not included as this type of information is
Guide_EPDOC- site-specific.
XX37-en-511.pdf
Fault_Tolerant_ This document provides instructions for installing and

Ethernet_ servicing the Fault Tolerant Ethernet Mux driver.
Installation_and_
Service_Guide_
EPDOC-XX36-
en-511A.pdf
Network_and_ This document contains networking and security-related

Security_ information applicable to Experion. It provides information
Planning_Guide_ about the recommendations to assist you in planning,
EPDOC-XX75- setting up, and maintaining a secure environment for your
en-511B.pdf system.
Switch_ This guide describes the user interface of the Switch

Configuration_ Configuration Tool and provides an overview for
Tool_Users_ configuring switches using the tool. It describes the tasks
Guide_EPDOC- to create new switch configuration, open an existing switch
X246-en- configuration, generate text files from the switch
- 13 -
Document Description
511A.pdf configuration, and load the new switch configurations to
the switches. It also briefly describes creating and saving
projects using the tool.
Control Builder This guide provides detailed information on the

Components functionality of Control Builder and the function block
Theory_EPDOC- libraries it is used to configure. It does not cover
XX16-en- ControlEdge hardware modules such as the Control
511A.pdf Processor Module (CPM) or Input / Output Modules
(I/OMs).
Control Building The procedures in this guide are intended to give you the
User’s Guide_ ability to perform basic tasks within the Control Builder
EPDOC_XX19_ application such as configuring hardware devices,
en-511A.pdf continuous control strategies, and sequential control
strategies. Only representative forms are shown to
illustrate a procedure/concept.
Control Builder This guide provides information about parameters

Parameter associated with configuration forms of function blocks in
Reference Control Builder.
Guides_EPDOC-
XX18-en-
511A.pdf
Control_Builder_ This document provides a brief technical reference of

Components_ function blocks configured through Control Builder.
Reference_
EPDOC-XX15-
en-511.pdf
Engineering Data The Engineering Data Builder (EDB) add-in is a

Builder (EDB) productivity enhancement tool integrated with the Control
User’s Guide- Builder.
EPDOC-X417-
EDB add-in deploys customized, reusable, and extensible
en-511A.pdf
spreadsheets, allowing project engineers to save time in
updating configuration.
Virtualization This guide gets you started with the Honeywell Premium
with the Platform for Experion Virtualization Solutions.
Premium
Platform
EPDOC-X455-
en-B.pdf
- 14 -
1.3 Terms and definitions
Term Definition
AI Analog Input
AO Analog Output
CA Certificate Authority
CBR Class Based Recipe
CDA Control Data Access

It is the Experion system communication infrastructure and data
access interface schema that provides application integration
with Experion system objects.
CEE Control Execution Environment
CIP Common Industrial Protocol

An industrial communication protocol now maintained as a
standard by the Open Device Venders Association (ODVA).
Cleartext Data that is stored or transmitted unencrypted
CM Control Module
CMCC Certificate Manager Configuration Console
Consolidate A single connection used to group multiple I/O modules, instead

Connections of one connection per I/O module.
Also referred to as Assembly connections, Rack connections,
Gateway connections.
ControlEdge A family of controller hardware which can be assembled to create PLC or UOC
900 systems.
CPM Control Processor Module (also commonly referred to as

controller)
DI Digital Input
DLR DLR is a link layer protocol for establishing a form of ring

redundancy on an Ethernet network.
DO Digital Output
Downlink Shorthand term use to refer to one of two possible types of I/O
and device network that a UOC controller connects to.
EDB Engineering Data Builder
EDS Electronic Data Sheets
- 15 -
Term Definition
Files which define the communication properties of devices
capable of connecting to EtherNet/IP networks.
EtherNet/IP EtherNet/IP™
EPM Expansion Processor Module

Ethernet communications module connecting distributed racks
of ControlEdge 900 I/O modules to the CPM.
ETAP EtherNet/IP™ Tap

A type of switch that allows a device incapable of supporting the
DLR redundancy protocol to form a non-redundant connection
into a DLR ring.
Expansion I/O rack with EPM installed

I/O rack
FDM Field Device Manager
FTE Fault Tolerant Ethernet

GTAC Global Technical Assistance Center
HART Highway Addressable Remote Transducer
HMI Human Machine Interface
HPS Honeywell Process Solutions
HSR HSR (High Availability Seamless Redundancy) is a link layer

protocol for establishing a form of ring redundancy on an
Ethernet network. HSR is referred to as “Ring-HSR” in the UOC
platform block configuration form.
HW Hardware
IIS Internet Information Services
IKE Internet Key Exchange
I/O Input/Output
IP Internet Protocol
IPSec Internet Protocol Security
LEAP Lean Engineering of Automation Projects
Local I/O I/O rack with Control Processor Module installed (non-
rack redundant)
NIC Network Interface Controller
NTP Network Time Protocol
- 16 -
Term Definition
NVS Non-Volatile Storage
ODVA Open Device Venders Association

OTP One Time Password
OWD Open Wire Detected
PC Personal computer
PCCC Programmable Controller Communications and Commands
PCDI Peer Control Data Interface
PLC Programmable Logic Controller
Peer Server Data sourcing service provided by the Experion Process Server
Responder node which allows controllers like the UOC to access any data
presented by the Server’s data points via peer communication
over the supervisory network.
PRP Parallel Redundancy Protocol is a link layer protocol for

establishing a form of dual-path redundancy on an Ethernet
network. PRP is also referred to as “Star-PRP”.
PSM Power Status Module
PSU Power Supply Unit
PTP Precision Time Protocol PTP

IEEE-1588
It is a standardized internet networking protocol used for
synchronizing computer clock times in a distributed network of
computers. PTP provides higher precision than NTP. The UOC
supports time synchronization by either NTP or PTP on its uplink,
FTE network.
P&ID A diagram representing the Process and Instrumentation Design

Diagram of a plant or plant unit.
PWA Printed Wiring Assembly
RCM Recipe Control Module
Redundancy A network switch that allows another device to connect into a

Box ring topology even if the device itself cannot natively handle the
ring redundancy protocol.
Redundant ControlEdge 900 rack capable of hosting a redundant pair of

Controller CPMs.
Rack
Redundancy Module used with a CPM within a 1 I/O Slot Rack to implement
- 17 -
Term Definition
Module Dual Rack Redundancy.
(RM)
SCM Sequence Control Module

SD Card Secure Digital Card
SW Software
TCP Transport Control Protocol

TLS Transport Layer Security
UI/O Universal Input/Output Module
UCM Unit Control Module

It is a container that represents a piece of or logical grouping of
physical equipment. A Recipe may be configured to acquire a
UCM before its procedure can be executed. A UCM can also be
used as an auxiliary resource.
UOC Unit Operations Controller

This is a term used to refer to the CPM when used as a controller
in the Experion PKS Distributed Control System.
Uplink Shorthand term used to refer to the supervisory Ethernet

network that the UOC controller connects to within an Experion
system.
UPS Uninterruptable Power Supply
Users Human Actors
User Goals What users are hoping to achieve at a high level and why. Independent of
system implementation. Should be able to be linked to stakeholder business
goals and SRS use cases.
User Scenarios Specific examples that elaborate on user goals in a context. Told in the form of
stories. Independent of system implementation.
vUOC Virtual Unit Operations Controller
- 18 -
CHAPTER
2 OVERVIEW OF UOC FEATURES
The Unit Operations Controller (UOC) is a high value, low cost, rack-based process controller that
can be applied to any process control application in any industry. Its form factor, cost profile and
licensing model make it especially well-suited to industries that prefer to limit the scope of a single
controller to a single process unit, and to industries that require powerful batch enablers.
The UOC is paired with a virtualized controller called the virtual Unit Operations Controller
(vUOC).The vUOC provides a set of functions parallel to those of the UOC except that they are
deployed within a server hosted virtual machine.
Summary descriptions of UOC and vUOC features are presented within this section. Additional
details may be found elsewhere within this document and within the overall Experion document
set.
2.1 Native Experion Integration

UOC integrates natively into the Experion DCS in a fashion parallel to that of existing controllers
such as the C300 and C200E. It uses the same CEE (Control Execution Environment) control
solver as those controllers. Experion Fault Tolerant Ethernet provides redundant, level 2
communications to the UOC. Engineering Station, Direct Station and Flex Station nodes all
provide view of UOC parameter and alarm data via Experion native Control Data Access (CDA)
protocol. Communication, monitoring, displays, trending, historizing, advanced applications, batch
applications, configuration and field device management all work with the UOC controller in a
fashion equivalent to that of existing CEE controllers.
2.2 ControlEdge 900 Form Factor

UOC control algorithms and I/O communications processing run in a family of rack-resident
modules called ControlEdge 900. ControlEdge can be used to deploy high density control and I/O
installations meeting all environment and agency certification requirements with no restriction as
to cabinet type.
In addition to the UOC, components of the ControlEdge HW family can be used to deploy the
ControlEdge PLC, without the need to deal with a completely different component family.
The main components of UOC HW are listed here.
- 19 -
Chapter 2 - Overview of UOC features
Component Description
CPM Control Processor Module
Referred to as UOC-CPM.
Host processor of control and communications supporting
redundant and non-redundant configurations. Provides two
uplink Ethernet ports for connectivity to FTE. Provides two
downlink Ethernet ports for connectivity to an I/O and device
network.
EPM Expansion Processor Module

Ethernet communications module connecting distributed racks
of ControlEdge 900 I/O modules to the CPM.
UI/OM Universal Input / Output Module

16 channel I/O module with universal channels which can be
configured as AO, DI or DO. Channels configured as AO support
HART protocol.
I/O Racks Five possible non-redundant racks which hold an EPM or a non-
redundant CPM together with 1, 4, 8 or 12 I/O Modules. Three of
the racks accommodate non-redundant power supplies. The 8
and 12 slot racks are available with redundant power supplies
and a power status module.
Redundant Redundant controller racking supporting two power supplies and

CPM Rack two CPM slots.
Power AC or DC power supply modules and power status module.

System
Detailed information on the installation, planning and general characteristics of ControlEdge 900
HW components can be found in ControlEdge 900 Platform Hardware Planning and Installation
Guide_HWDOC-X430.pdf.
2.3 FTE Uplink Connectivity

UOC connects to a redundant FTE supervisory network via its uplink Ethernet ports (port #1& port
#2). UOC hosts a full featured firewall allowing it to securely connect directly to level 2, FTE-
qualified, third party switches. UOC deployments do not require connectivity to FTE through a
separate firewall.
Beginning with Experion R510.2, the vUOC connects to a redundant FTE supervisory network via
its uplink Ethernet ports (virtual switches). A software-based firewall is included allowing a secured
connection directly to Level 2, FTE- qualified, third party switches.
2.4 Ethernet I/O Connectivity

UOC connects to an I/O and device network via its two downlink Ethernet ports (port #3 & 4).
- 20 -
Multiple application-dependent typologies are supported with two configurable options:

l When only ControlEdge 900 I/O racks are connected, a native ring redundancy based on the
High Availability Seamless Redundancy (HSR) protocol may be used, a star redundancy based
the Parallel Redundancy Protocol (PRP) may be used or a non-redundant star may be used.
l When ControlEdge 900 I/O racks are used together with 3rd party EtherNet/IP devices, a ring
redundancy based on Device Level Ring (DLR) may be used or a non-redundant star may be
used.
2.5 ControlEdge 900

ControlEdge PLC supports various input/output modules. The following I/O modules are included:
Module Type Model Number

UI/O module 900U01-0100
UAI module 900A01-0102
DI 24VDC module 900G32-0001
DO 24VDC module 900H32-0102
DI High Voltage AC 900G03-0102
DO High Voltage AC 900H03-0102
AI16-100MS (High Level Analog Input, 16 Channels) 900A16-0103
AO04-500MS (Analog Output, 4 Channels) 900B01-0101
AO08-500MS (Analog Output, 8 Channels) 900B08-0202
DI16-DRYCT (DI - 16ch Dry Contact Type) 900G01-0102
DI16-VACDC (DI - 120/240 VAC, 125 VDC (16ch-Iso)) 900G04-0001
DO08-RELAY (Digital Output Relays, 8 Channels) 900H01-0102
Additional I/O modules will be made available in future releases of the Experion PKS.
NOTE : For Module AI16-100MS, the Model Number should be 900A16-0103 and the
firmware version should be 1.39 for the 100 ms scan rate support.
For below IO modules, there can be Model number mismatch between the IO module hardware
and the IO module reports.
- 21 -
Model Module Number report by the IO

Module Description
Number Module
Analog Output, 0 to 20mA, (4 900B01- 900B01-0101
channel) 0301
Digital Input, Contact type, (16 900G01- 900G01-0102

channel) 0202
Digital Output, Relays (8 900H01- 900H01-0102

channel) 0202
2.6 Field Device Manager

UOC supports integration with Experion Field Device Manager (FDM) for management of smart
field instruments. The FDM can view and manipulate the digital HART variables of field
instruments through the analog channels of UOC’s UI/OM.
The ability of UOC itself to access digital HART variables via a Field Device Server hosted on the
Engineering Station will be introduced in a future release.
2.7 EtherNet/IP Connectivity to I/O, Devices, and

Controllers
UOC supports control through third party I/O and devices connected by the EtherNet/IP protocol
on its Ethernet downlink.
A set of EtherNet/IP devices come preinstalled and ready for instantiation within Experion Control
Builder. This includes Rockwell Allen Bradley’s ArmorPoint I/O, ArmorBlock I/O, PowerFlex Drive
and E3 Relay.
Support for other EtherNet/IP I/O and EtherNet/IP device types can be integrated by projects
personnel without dependence on a new Experion release through the use of Experion Control
Builder’s Parameter Definition Editor (PDE).
Also supported are User Defined Type (UDT) blocks which enable UOC to communicate over its
downlink via EtherNet/IP with Rockwell Allen Bradley’s ControlLogix.
2.8 CEE Control Processing

UOC hosts the well-proven Control Execution Engine (CEE) strategy solver used in existing
Experion controllers. CMs (Control Modules) are fully supported for continuous control strategies.
SCMs (Sequential Control Modules), UCMs (Unit Control Modules), RCMs (Recipe Control Modules)
and CBRs (Class Based Recipes) are fully supported for batch control strategies.
2.9 Control Builder Strategy Configuration

Like all CEE controllers, UOC’s control strategies are configured using Experion Control Builder.
Control Builder offers a rich set of tools for the creation of strategies to control continuous,
discrete and batch processes. Strategies may be created as individual instances or as replicable
templates. Bulk creation of UOC control strategies is supported through Experion’s Engineering
Data Builder (EDB) add-on to Control Builder. EDB allows application engineers to create large
configurations using an efficient, spreadsheet-driven workflow.
- 22 -
2.10 I/O Points and I/O Reference Blocks

UOC supports binding of I/O to control through a mechanism that allows the configuration of one
to be independent of the other. UOC I/O points may be introduced into the system independent of
UOC control strategies. UOC control strategies may be configured and tested independent of their
corresponding I/O.
This independence is achieved through two kinds of function blocks supported by Control Builder
and by CEE.
l I/O Points
o I/O Points are Experion tagged blocks representing the device connected to the UOC
through an input or output channel of an I/O module.
o They are typically tagged with the same name (up to 40 characters) that labels the
device in a P&ID diagram.
o They serve as a connection target that binds a control strategy to an I/O channel.
o They allow the binding to be made by name, without constraining the strategy to work
with the particular channel of a particular I/O Module.
o They allow the configuration of the I/O Module to be separated from the configuration
of the control strategy.
o They can be created before or after the corresponding control strategy.
o In addition to I/O channels, they can be used to represent key parameter data which
do not correspond to actual I/O channels.
l I/O Reference Blocks
o I/O Reference Blocks are basic blocks instantiated in Control Modules to make an I/O
signal available for connection to algorithm blocks.
o They are bound to I/O Points though named references independent of particular
channels in particular I/O Modules.
o They support a simulation mode that allows for strategy checkout to be done in the
absence of I/O Modules.
o They complement I/O Points by serving as the reference end of the connection to the
I/O Point.
o In addition to referencing I/O channels, they can be used to reference key parameter
data which do not correspond to actual I/O channels.
UOC’s I/O Points and I/O Reference Blocks provide key enablers of the Lean Execution of
Automation Projects (LEAP) methodology supported by Experion.
2.11 Simulation
UOC may be used for both control and strategy-check-out simulation without the need to deploy a
special purpose simulation application. Simulation behaviors of strategies are controlled through
the SIMMODE parameter of I/O Reference blocks within the Control Module under test.
2.12 Control Redundancy

UOC optionally supports redundant control operation. Single Rack Redundancy is provided
through a single rack scheme where the partner CPMs are placed in the same rack along with
power supplies. The power supplies in a single rack scheme do not provide REDUNDANT power:
The left power supply provides power to the CPM mounted in the left slot. Likewise, the right power
- 23 -
supply provides power to the CPM mounted in the right slot.

Switchover from the active primary to the backup controller may be commanded manually. If a
fault occurs, the failed primary is detected automatically by virtue of comprehensive diagnostics,
leading to automatic switchover. Switchover occurs within 500 milliseconds in order to ensure a
seamless transition, preserving all configuration data and live data, and with no disturbance to
outputs.
Dual Rack Redundancy is provided through 2 separate 1 I/O slot racks each with a power supply
and a Redundancy Module . Refer to the ControlEdge 900 Platform Hardware Planning and
Installation Guide_HWDOC-X430.pdf for additional information.
2.13 Peer-To-Peer Communication

UOC supports multiple forms of peer-to-peer communication across its uplink FTE connection.
l Control Data Access (CDA)
UOC uses Experion native CDA protocol for communication with peer partners as well as level 2
server and station nodes. Parameter reads are supported under a cyclic publication paradigm.
Parameter writes are supported under an acyclic store paradigm.
Within CMs and SCMs, the configuration of peer references is transparent to the application
engineer. They are specified by configuring fully qualified parameter names such as
“TT101.DATAACQ.PV” in expressions, inputs pins or selected output pins, without concern as to
whether the parameter is in the same UOC or in a different controller.
UOC’s CDA peer connections may also be used to reference data from SCADA points by virtue of
Experion Peer Server Responder capability.
The Experion node types with which UOC supports CDA peer-to-peer communication are listed in
the following table. This set will be expanded in future releases.
Responding Node
UOC vUOC C200E C200
Initiating Node
C300
UOC ü ü ü ü ü
vUOC ü ü ü ü ü
C300 ü ü ü ü ü
ACE ü ü ü ü ü
C200E ü ü ü ü ü
C200 Note1 Note1 ü ü ü
NOTE 1: The C200 controller can respond to CDA peer communications from a UOC or vUOC
but cannot initiate them.
l Exchange Blocks
- 24 -
UOC supports a library of blocks which enable communication with third party PLCs and devices
via protocols which were originated by Rockwell Allen Bradley and now support transport over
Ethernet. Blocks within the EXCHANGE library allow initiation of and response to read and write
requests for flags, numeric and string arrays. EXCHANGE blocks support two protocols: the
Common Industrial ProtocolTM (CIP) and Programmable Controller Communication Commands
(PCCC).
l PCDI Blocks
UOC supports a library of blocks called Peer Control Data Interface (PCDI) which enable
communication with third party PLCs and devices via the Modbus TCP/IP protocol. Blocks within
the PCDI library allow initiation of read and write requests through a device proxy block to flag,
numeric and string arrays in a Modbus-capable peer controller.
2.14 Alarms and Events

UOC supports a comprehensive set of alarm and event reporting capabilities that integrate
seamlessly with Experion enablers for the display and historization of alarms and events.
Supported notification types include high, low and rate of change process alarms, state change
process alarms, state change system events, diagnostic events and batch events.
2.15 Time Synchronization

UOC maintains an internal clock which is synchronized with external wall clock time.
Synchronization can be maintained over the uplink network using either the Network Time
Protocol (NTP) or the Precision Time Protocol (PTP). All alarms and events reported by UOC are
issued with synchronized time stamps.
2.16 Security
UOC has built in enablers to provide for the secure and robust operation of its control and I/O
configurations. This includes an uplink firewall that limits message types to those appropriate to
the mission of the FTE network. It includes a downlink firewall that limits message types to those
appropriate to the missions of 900 I/O and EtherNet/IP communication. UOC also supports
mechanisms of signed firmware and secure boot which insure only Honeywell authorized
firmware to be executed within the device.
2.17 Licensing
UOC systems are delivered under a licensing model which allows HW and SW components to be
deployed in the manner that most naturally fits the process control problem to be solved. Indirect
cost penalties for good design practices are avoided. The bulk of the cost associated with deploying
a UOC system is proportional to the count of Analog and Digital I/O points put into service. There is
little additional cost if a good design dictates the deployment of small, per unit controllers. Similarly,
there is little additional cost if the design dictates the deployment of small, modularized control
strategies.
For more information on Licensing refer to Licensing Model section.
- 25 -
2.18 vUOC
As noted above, the virtual UOC provides a set of functions nearly equivalent to those provided by
the ControlEdge 900 based UOC. It is well suited to supervisory batch applications, lab applications
and control strategy checkout before strategies are deployed to a ControlEdge UOC
Differences between the two are driven by the nature of their hosting platforms and, to a certain
extent, by particular strengths that their respective deployments provide. Key differences are
highlighted by the following table.
- 26 -
Attribute UOC vUOC Comment

Host l Runs on the l Runs as a
Platform purpose- virtual
built, machine on
industry general
hardened, purpose PC
ControlEdge servers
CPM
Base Period l 50 ms l 50 ms or A second vUOC variant

500 ms supports a slower base
cycle in addition to the
50 ms base cycle
parallel to the UOC.
The slower variant
allows the vUOC to be
applied as a very large
batch supervisor
managing UOCs or
C200Es serving as
equipment controllers.
User l 32 MB l 32 MB in The 500 ms variant of

Memory the 50 ms the vUOC supports a
Capacity variant user memory database
4 X that of the UOC as
l 128 MB in an additional enabler
the 500 ms of large supervisory
variant batch configurations.
Control l Transparent l Not The vUOC has no

Redundancy redundancy currently native redundancy
support supported enablers, but as an
based on alternative, it can
proprietary optionally be deployed
enablers in virtual platforms
that provide high
availability solutions.
Support In l Runs on l Can run One of the key

VEP purpose- within HPS’ deployments of the
built HW and Virtual vUOC is as a simulator
cannot run Engineering within VEP to support
within HPS’ Platform early application
Virtual development.
Engineering
Platform
- 27 -
Users familiar with the Experion portfolio of controllers and simulators may be tempted to interpret
the vUOC in terms of things they are already familiar with. There are indeed similarities that can be
noted. But there are also significant differences which prevent vUOC from being equated with
previous offerings. This point is highlighted by the following table.
SIM- SIM-
Attribute UOC vUOC C300 ACE
C300 ACE
Hosting on Server No Yes No Yes Yes Yes
Direct I/O Connectivity Yes Yes Yes No No No
Deployment as Controller Yes Yes Yes No Yes No
Deployment as Simulator Yes Yes No Yes No Yes
Simultaneous Control and Yes Yes No No No No

Simulation
- 28 -
CHAPTER
3 NETWORKING
3.1 Uplink FTE Network

UOC and vUOC are deployed within Experion systems by connecting their uplink Ethernet ports to
a Level 2 FTE network. Of the two parallel tree networks that comprise an Level 2 FTE installation,
the ETH1 port connects to the A or Yellow tree while ETH2 connects to the B or Green tree.
FTE connectivity is summarized in the following diagram which shows a non-redundant UOC rack
and a virtual machine server for a vUOC in the context of the following Experion nodes.
l Experion Process Server
l Experion Direct Station (ES-C)
l Experion Flex Station (ES-F)
l ACE
l Terminal Server
l Domain Controller
Figure 3.1 UOC Network Connectivity (Uplink FTE Network)
- 29 -
Chapter 3 - Networking
UOC utilizes an existing FTE network, native to Experion PKS. It has a dual connection to Level 2
Yellow and Green FTE switches. No third party firewalls are required.
The number of levels of FTE switches above the UOC may be one, as shown in the diagram above,
two or three.
vUOC’s deployment within an FTE network follows Experion guidance for virtual machines. For
further information, see the vUOC section in this document.
Like existing CEE controllers, UOC requires the presence of a Process Server to function within an
Experion system.
When connecting to FTE, the UOC CPM gets its IP address from the Experion BOOTP service
running on the Engineering Station node. Its IP address is constructed by combining the CPM’s
FTE Device Index with the subnet base address configured through Control Builder and known to
the BOOTP server. Rotary switches of the UOC CPM are located on the module and are used to set
the FTE Device Index. They must be set before the module is inserted into its slot.
ATTENTION
Ensure that the Device Index is set before you place a module in a rack.
Note that, in the special circumstance that a PLC CPM received from the factory is being converted
to a UOC CPM, considerations on IP addressing are different initially. For further information on
converting a PLC CPM to a UOC, see the Converting PLC CPM to UOC CPM section.
Care must be taken in the assignment of FTE device indices to a UOC’s rotary switches. In a
redundant controller rack, the left hand UOC must be assigned an odd numbered device index
while the right hand UOC must be assigned an odd + 1 device index. The odd + 1 position is
reserved and must not be used for other than redundant partner. Non-redundant UOCs must
always be assigned odd numbered device indices. For more information on how to set the FTE
device index see the FTE Device Index section.
The L2 FTE switches to which UOC connects are managed switches which must be configured
using the FTE Switch Configuration Tool. Any ports to which UOCs connect must be configured as
“Other Auto” using this tool. For further information on the FTE Switch Configuration Tool, see the
Switch Configuration Tool Users Guide_EPDOC-X246-EN-511A.pdf.
Except for specific considerations noted within this document, all FTE installation and
maintenance practices for the UOC and vUOC must be done in a fashion consistent with Experion
and FTE guidelines. For further information, see Fault Tolerant Ethernet Overview and
Implementation Guide EPDOC-XX37-en-511A.pdf, Fault Tolerant Ethernet Installation and Service
Guide EPDOC-XX36-en-511A.pdf, and Network and Security Planning Guide EPDOC-XX75-en-
511A.pdf.
3.2 Downlink I/O Network Topology

UOC supports direct connectivity to an I/O network through its downlink Ethernet ports, ETH3 and
ETH4.
The table below provides a description of various downlink topologies supported.
- 30 -
Topology Type Description Switch Types

Topology 1 HSR ring to 900 I/O. None
Topology 2 Non-redundant star to 900 I/O Generic
Topology 3 Redundant star (via PRP) to 900 I/O Generic
Topology 4 DLR direct connection to 900 I/O and None

EIP devices
Topology 5 Non-redundant star to 900 I/O and EIP Generic and

devices StratixTM
ATTENTION
Uplink and downlink subnets must be unique. The Downlink subnet mask must be limited to
the number of addresses expected in that subnet.
For example, if a max of 64 addresses is expected, you could use a mask of 255.255.255.192.
Below sections provides detailed description of downlink topologies .
3.2.1 HSR Ring Topology with 900 I/O

High Availability Seamless Redundancy Protocol (HSR) is an industrial redundancy communication
protocol standardized by the International Electrotechnical Commission as IEC 62439-3 edition 2.
It allows system to overcome single network failure without affecting data transmission. It can be
applied to industrial Ethernet applications since it is independent of the protocols and provides
seamless failover.
HSR realizes active network redundancy by packet duplication over two independent networks that
operate in parallel.
When connecting to ControlEdge 900 I/O only, a redundant ring topology may be used. The ring
type is HSR (High Availability Seamless Redundancy). In this topology no third party redundancy
boxes are required. The UOC CPM connects directly, using its two downlink Ethernet ports.
Similarly, EPM modules connect directly using their two Ethernet ports. When a UOC downlink is
constructed in this fashion, it is not possible to connect third party I/O, Devices or PLCs. Only 900
I/O racks may be connected.
When connecting CPMs and EPMs into an I/O network ring, the numbered ports must be
connected so that odd numbered ports always connect to even numbered ports. This is shown in
the following diagram for the case of a redundant UOC rack with two UOC CPMs connecting to two,
4-I/O slot, non-redundant racks, each with its own EPM. Also shown are the CPM’s connection of
ETH1 to the A, Yellow FTE network tree and ETH2 to the B, Green FTE network tree. Note that
incorrect cabling will result in LAN ID Errors and reduced robustness. To clear the LAN ID errors
and the associated software, reset statistics.
- 31 -
Figure 3.2 Downlink I/O Network
Considerations for components that connect to a UOC’s downlink HSR ring network are
summarized in the following table.
- 32 -
Component
Comments
Type
ControlEdge The UOC CPM must be connected to the downlink I/O ring
UOC CPM such that even numbered ports always connect to odd
numbered ports. Important properties of UOC CPM
communications on the downlink network are configured on
the UOC Platform Block in Control Builder. This includes
configuration of the UOC DHCP server for assigning EPM IP
addresses. It also includes setting the Downlink Network
Configuration to Ring-HSR. For complete information on
configuring the downlink network properties on the UOC
Platform Block, see the UOC Platform Block section.
ControlEdge An EPM must be connected to the downlink I/O ring such that
900 I/O even numbered ports always connect to odd numbered ports.
Racks with Before it is inserted into its slot, the 100X rotary switch on the
EPMs EPM board must be set to indicate I/O network connectivity.
This is done by setting it to position 3. The IP address of the
EPM is assigned by the UOC CPM based on the module
number set on the 10X and 1X rotary switches. Ensure that the
values within the range of 1-12 are used, as these are the valid
values. This too must be set before the EPM is inserted into its
slot. For complete information see the ControlEdge 900 I/O
Device Connectivity section.
- 33 -
3.2.2 Redundant Star (PRP) Topology with 900 I/O
ATTENTION
The UOC does not support downlink network topologies containing both PRP and non-
redundant connected devices. If your UOC downlink network connection type is configured
for redundant star, you should only connect PRP-capable devices to the downlink network.
Parallel Redundancy Protocol (PRP) is a data communication network standardized by the

International Electrotechnical Commission as IEC 61850 edition 2. It allows systems to overcome
single network failure without affecting data transmission. It can be applied to industrial Ethernet
applications since it is independent of the protocols and provides seamless failover.
PRP provides redundancy by sending two copies of the same frame over two independent
networks. A Redundancy Control Trailer (RCT) is added to each frame (which includes a sequence
number to support detection of duplicate messages so that one may be discarded.) It supports zero
failover time.
When connecting to ControlEdge 900 I/O only, either a non-redundant or redundant star topology
may be used. The network redundancy type is PRP (Parallel Redundancy Protocol). In this topology
no third party redundancy boxes are required. The UOC CPM connects directly, using its two
downlink Ethernet ports. Similarly, EPM modules connect directly using their two Ethernet ports.
When a UOC downlink is constructed in this fashion, it is not possible to connect third party I/O,
Devices or PLCs. Only 900 I/O racks may be connected.
An example of a UOC and two 900 I/O racks on a downlink, redundant, star network is shown in
the following diagram. Also shown are the CPM’s connection of ETH1 to the A, Yellow FTE network
tree and ETH2 to the B, Green FTE network tree.
Figure 3.3 Redundant Star Network
The UOC does not support star topologies which mix redundant and non-redundant connectivity.
Downlink star networks must be set up as exclusively redundant or exclusively non-redundant.
- 34 -
Considerations for components that connect to a UOC’s downlink non-redundant or redundant

star network are summarized in the following table.
Component
Comments
Type
ControlEdge Important properties of UOC CPM communications on the
UOC CPM downlink network are configured on the UOC Platform Block in
Control Builder. This includes configuration of the UOC DHCP
server for assigning EPM IP addresses. It also includes setting
the Downlink Network Configuration to “Non-redundant” in the
case of a non-redundant star network or “Star-PRP” in the case
of a redundant star network. For complete information on
configuring the downlink network properties on the UOC
Platform Block, see the UOC Platform Block section.
ControlEdge Before it is inserted into its slot, the 100X rotary switch on an
900 I/O EPM board must be set to indicate I/O network connectivity.
Racks with For a non-redundant or redundant star network, this is done by
EPMs setting it to position 4. The IP address of the EPM is assigned
by the UOC CPM based on the module number set on the 10X
and 1X rotary switches. Ensure that the values within the range
of 1-12 are used, as these are the valid values. This too must be
set before the EPM is inserted into its slot. For complete
information see the ControlEdge 900 I/O Device Connectivity
section.
Unmanaged 900 I/O racks with EPM gateways have been qualified to
Switches communicate with UOC through unmanaged switches.
Managed switches may not be used. For information on
qualified switches see the ControlEdge 900 Hardware and
Installation Guide.
3.2.3 DLR Ring Topology with EtherNet/IP and 900 I/O devices
Device Level Ring (DLR) is layer 2 data link layer protocol that provides media redundancy, faster
network fault detection, and network fault resolution in a ring topology.
Advantages:
l DLR reduces the number of external components and associated cabling, which eases design
and installation. It also reduces the cost.
l When a ring breaks, DLR detects it and provides alternate routing of the data to help recover
the network at extremely fast rates.
l Line faults of bidirectional rings can be reconfigured quickly, as switching happens at a high
level, and thus the traffic does not require individual rerouting.
On network with only DLR devices, one device act as an active ring supervisor and other devices
form ring nodes. DLR network contain a maximum 50 IP address nodes (This is Honeywell
specification).
DLR network should have at least one node configured as ring supervisor. If there are multiple
nodes configured as supervisor, then the node with highest supervisor precedence value becomes
active supervisor, others will be backup Supervisors.
- 35 -
The active ring supervisor cyclically sends out Beacon Frames and Announce Frames on both
ports. They are received on one port of a ring node, processed and passed on to the next ring node
via the other port.
DLR ring topology which provides redundancy protection against a single network ring fault.
Installation and maintenance of a downlink EtherNet/IP network must be done in accordance with
the best practices of Ethernet networking in general and EtherNet/IP in particular.
In this topology, UOC connects directly to the ring through downlink ports ETH3 and ETH4. EPM
connects through their ETH1 port and ETH2 port directly to ring networks.
An example of a DLR Ring network is shown in the following diagram.
Figure 3.4 Downlink DLR Network
Installation and maintenance practices for the UOC’s downlink EtherNet/IP network generally
follow those described in the EtherNet IP User's Guide. Additional considerations for components
that connect to the EtherNet/IP network are summarized in the following table.
- 36 -
Component
Comments
Type
ControlEdge The UOC CPM connects to a downlink EtherNet/IP network
UOC CPM through its ETH3 and ETH4 ports. Important properties of
UOC CPM communications on the downlink network are
configured on the UOC Platform Block in Control Builder. This
includes configuration of the UOC DHCP server for assigning
EPM IP addresses. It also includes Downlink Network
Configuration to Non-redundant.
ControlEdge When 900 I/O is used, the EPM in the I/O rack serves the role
900 I/O of communication gateway into the I/O rack. When an EPM is
Racks with connected, ETH1 port and ETH2 port are directly connected to
EPMs an EtherNet/IP network. Before it is inserted into its slot, the
100x rotary switch on the EPM board must be set to indicate
the type of network connectivity in use. This is done by setting
it to position 4.
The IP address of the EPM is assigned by the UOC CPM based
on the module number set on the 10X and 1x rotary switches.
These switches must also be set before the EPM is inserted
into its slot.
For complete information on the use of ControlEdge EPM and
900 I/O, see ControlEdge 900 I/O section.
ControlLogix UOC can communicate with Rockwell Allen Bradley

PLC ControlLogix PLCs by passing instances of User Defined Types
(UDTs). References to ControLogix data are created in
Experion Control Builder with the aid of tag names provided by
the Matrikon Allen Bradley OPC server or by export of
ControlLogix tag names from the Rockwell Allen Bradley
Studio 5000 designer tool. ControlLogix PLCs on a UOC’s
downlink EtherNet/IP network must always use static IP
address assignments. For information on the configuration of
ControlLogix communications, see EtherNet IP User's Guide_
EPDOC-X399-en-511A.pdf.
EtherNet/IP UOC supports a set of EtherNet/IP devices with pre-populated

I/O and CEE block types in Experion Control Builder (CB). In addition,
Devices CB provides the Parameter Definition Editor (PDE) tool which
allows for the integration of new EtherNet/IP I/O and devices
independent of Experion release. Although some third party
EtherNet/IP devices support IP address assignment from a
network resident DHCP server, this feature cannot be used
when the EtherNet/IP network connects to UOC. All device IP
addresses must be statically assigned. For further information,
see EtherNet IP User's Guide_EPDOC-X399-en-511A.pdf.
- 37 -
Component
Comments
Type
Allen Bradley The Rockwell Allen Bradley OPC Server from MatrikonOPC can
OPC Server be installed on the Engineering Station in systems which
from incorporate UOC. The Matrikon OPC Server enables one of two
MatrikonOPC methods whereby ControlLogix tag names can be used to
make UDT references in a UOC strategy. For further
information, see EtherNet IP User's Guide_EPDOC-X399-en-
511A.pdf.
Studio 5000 Studio 5000 Logix Designer Software from Rockwell Allen
Logix Bradley is used in conjunction with UOC configurations to
Designer configure IP addresses of Rockwell Allen Bradley EtherNet/IP
Software devices. It can also be used to export a file which defines
ControlLogix tag names so that they can be used in Control
Builder to construct UDT data references from UOC. For
further information, see EtherNet IP User's Guide_EPDOC-
X399-en-511A.pdf.
ATTENTION
While using DLR (Device Level Ring) on Stratix 5700 Switch, DO NOT CONNECT a DLR
network to a Non-DLR port on the Switch. DLR should be connected only to the DLR ports
on the switch. Doing this will result in the entire downlink network going down. The recovery
is to only remove the DLR connection from the switch.
3.2.4 Non-Redundant Star to 900 I/O and EIP Devices

In addition to the DLR ring topology, the UOC can also connect to a non-redundant star
EtherNet/IP network through its ETH3 downlink port. This allows it to communicate
simultaneously with ControlEdge 900 I/O as well as EtherNet/IP-capable I/O, devices and PLCs.
Installation and maintenance of a downlink EtherNet/IP network must be done in accordance with
the best practices of Ethernet networking in general and EtherNet/IP in particular.
In this topology, CPMs connect through their ETH3 downlink port with ETH4 port disconnected.
EPMs connect through their ETH1 port with ETH2 port disconnected. An example is shown in the
diagram below.
- 38 -
Figure 3.5 UOC CPM to 900 I/O and EIP Devices
Installation and maintenance practices for the UOC’s downlink EtherNet/IP network generally
follow those described in EtherNet IP User's Guide_EPDOC-X399-en-510A.pdf for topology 2, “C300
Through EtherNet/IP”. Additional considerations for components that connect to the EtherNet/IP
network are summarized in the following table. ControlLogix PLCs and EtherNet/IP I/O and Devices
are equivalent to those for DLR ring networks.
- 39 -
Component
Comments
Type
ControlEdge The UOC CPM connects to a downlink EtherNet/IP network
UOC CPM through its ETH3 and ETH4port. Important properties of UOC
CPM communications on the downlink network are configured
on the UOC Platform Block in Control Builder. This includes
configuration of the UOC DHCP server for assigning EPM IP
addresses. It also includes Downlink Network Configuration to
Non-redundant.
ControlEdge When 900 I/O is used, the EPM in the I/O rack serves the role
900 I/O of communication gateway into the I/O rack. When an EPM is
Racks with connected to an EtherNet/IP network, its ETH1 port is
EPMs connected to the switch while its ETH2 port is left
disconnected. Before it is inserted into its slot, the 100x rotary
switch on the EPM board must be set to indicate the type of
network connectivity in use. This is done by setting it to position
4. The IP address of the EPM is assigned by the UOC CPM
based on the module number set on the 10X and 1x rotary
switches. These switches must also be set before the EPM is
inserted into its slot. For complete information on the use of
ControlEdge EPM and 900 I/O, see ControlEdge 900 I/O
Device Connectivity section.
Unmanaged 900 I/O racks with EPM gateways have been qualified to
Switches communicate with UOC through unmanaged switches. EPMs
may not be connected through managed switches. For
information on qualified switches see ControlEdge 900 Platform
Hardware Planning and Installation Guide_ HWDOC-X430.pdf.
Stratix EIP I/O, devices and PLCs may be connected to UOC through
Switches qualified, Stratix managed switches. For further information on
how to deploy and configure Stratix switches, see EtherNet IP
User's Guide_EPDOC-X399-en-511A.pdf.
3.2.5 EtherNet/IP in Experion

Experion as a whole supports a variety of topologies for connecting to EtherNet/IP networks. For
additional information see EtherNet IP User's Guide_EPDOC-X399-en-511A.pdf.
To put UOC topologies into context, supported variations, including that of UOC, are summarized in
the following table.
- 40 -
Summary
# Connectivity Description
Name
1 SCADA SCADA The Experion SCADA Server supports
Server To Server connectivity to Rockwell Allen Bradley
EtherNet/IP ControlLogix PLCs which are attached to
|
an EtherNet/IP network. The SCADA
FTE Network Server connects to the L2 FTE network
which provides a path through an L2.5
|
or L3 Router and through non-
L2.5 or L3 redundant Ethernet links, to an
Router EtherNet/IP-capable, Stratix switch.
| Access Lists of the router must be
configured as a security boundary
Ethernet between the FTE and EtherNet/IP
Link networks.
|
EtherNet/IP-
capable
Switch
|
EtherNet/IP
Network
|
PLCs
2 UOC Direct UOC The UOC controller supports

To connectivity to I/O, devices and Rockwell
|
EtherNet/IP Allen Bradley ControlLogix PLCs which
EtherNet/IP- are attached to an EtherNet/IP network.
capable The UOC connects to a DLR ring
Switch through its ETH3 (with ETH4 left
disconnected) downlink port.
|
Alternatively, it connects to a non-
EtherNet/IP redundant star network. The IP subnet of
Network the UOC on its uplink FTE ports is
| isolated from the IP subnet of the UOC
on its downlink EtherNet/IP port.
I/O, Devices Honeywell ControlEdge 900 I/O can be
and PLCs connected to the downlink EtherNet/IP
network along with third party I/O and
devices.
- 41 -
NOTE
Users who wish to use UOC with secure communications should be aware that considerable
planning and configuration is required in its setup. For further information, see section
Configuring a Secure Connection for Experion Integration.
- 42 -
CHAPTER
4 INSTALLATION
4.1 Hardware Considerations

The ControlEdge CPM (model # 900CP1-0200) can be used as a ControlEdge PLC or ControlEdge
UOC by programming in the corresponding firmware image.
To convert ControlEdge CPM (model # 900CP1-0200) to ControlEdge UOC, install the UOC
firmware image into the module.
The CPM Mode switch is not used by the ControlEdge UOC after initial firmware programming.
Therefore, once the module is programmed as ControlEdge UOC, the UOC label (see below) is
affixed over the CPM Mode Switch.
The odd device index UOC (default primary) must be inserted in the left-hand slot (slot 0). If there
is a backup module, it must be set to odd+1 and placed in the right-hand slot (slot 1). A non-
redundant controller must not be placed in slot 1. For more information on how to set the FTE
device index, see the FTE Device Index section on page 52.
For more information, see ControlEdge 900 Platform Hardware Planning and Installation Guide_
HWDOC-X430.pdf.
4.2 Firmware Considerations

Installation and maintenance of UOC firmware entails several types of activities as follows:
l Converting a PLC CPM into a UOC CPM
l Upgrading a UOC CPM to a new firmware version
l Upgrading a UOC EPM to a new firmware version
l Upgrading a UOC UI/OM to a new firmware version
- 43 -
Chapter 4 - Installation
Firmware update and CPM conversion are done using an application called Firmware Manager.
For detailed information on using Firmware manager, see Firmware Manager User Guide_EPDOC-
X470.pdf.
4.2.1 Converting PLC CPM to UOC CPM

ControlEdge UOC and PLC are distinct controllers that can be deployed using a common family of
HW. For information on ControlEdge HW components see ControlEdge 900 Platform Hardware
Planning and Installation Guide_HWDOC-X430.pdf.
The ControlEdge Control Processor Module (CPM) is the central component which communicates
on its uplink ports with the Experion PKS system and on its downlink ports with I/O and devices.
The UOC'shardware and model number are identical to that of the ControlEdge PLC but its
firmware is different. The CPM is always shipped from the factory preloaded with PLC firmware. To
use a CPM in an Experion PKS system, it must first be converted into a UOC CPM by loading
firmware over a network connection.
Network connectivity is established by using an Ethernet port and IP address that conform to the
PLC’s communication methodology. The handling of Ethernet ports and IP addresses in a
ControlEdge PLC is different from that of Experion PKS. As a result, the PLC to be converted must
be placed in a system where it can communicate without needing to be a member of an FTE
community.
There are two possible ways of doing this as follows:

l Use a Bench system with a ControlEdge power supply and rack that can host a CPM.
l Use an Experion system with a ControlEdge power supply and rack or rack slot that can host a
CPM and is not being used for on-process control.
ATTENTION
l Once the PLC is converted into a UOC, it should not be reconnected to a PLC system
as it requires Experion PKS infrastructure to operate.
l The PLC’s ControlEdge Builder is not used to perform PLC-to-UOC conversion.
Manually attempting to load UOC firmware to a PLC-CPM with the PLC’s Control
Edge Builder may result in controller firmware corruption.
l UOC-to-PLC conversion is currently not supported. Manually attempting to load PLC
firmware to a UOC-CPM may result in controller firmware corruption.
l Do not install the PLC’s ControlEdge Builder software on either an Experion node
type or a Bench laptop or PC that has Firmware Manager installed. These
applications have similar controller communication infrastructure that are not
designed to co-exist resulting in Firmware Manager to module communication
breakage.
Converting Using Bench System
The main distinction of a Bench System it that it uses a laptop or PC that is not an Experion PKS
node type. The Bench laptop or PC requires a one-time install of Bench System Firmware Manager
from Experion PKS installation media. The special nature of this install is that it also installs the
UOC firmware in addition to the Firmware Manager application used to load the UOC firmware to
the PLC-CPM. Refer to Firmware Manager User Guide_EPDOC-X470.pdf for how to create a Bench
System laptop or PC.
To complete the Bench System, a ControlEdge controller rack with a power supply must be
procured. Either a redundant or non-redundant rack may be used. For information on rack types,
see ControlEdge 900 Platform Hardware Planning and Installation Guide_HWDOC-X430.pdf.
After the Bench system has been set up, it includes the components as shown here.
- 44 -
Figure 4.1 PLC CPM to UOC CPM Conversion using Bench System
Refer to Firmware Manager User Guide_EPDOC-X470.pdf for information on:

l How to create the Bench System laptop or PC.
l How to setup the Bench System PC and the PLC-CPM for conversion.
l How to perform the PLC-to-UOC conversion.
Convert PLC to UOC Using Experion System
Using Experion Equipment

When converting PLC to UOC within an Experion PKS system that is undergoing deployment, it is
not required create a Bench system laptop or PC. It is also not required to designate a specific rack
for use in a bench system. Instead, a controller rack with power supply that is being deployed
within the new system can be identified as a temporary host of the CPM(s) under conversion.
Careful consideration must be given to the creation of spare UOC CPMs before a temporary
conversion rack is put on-line. For further comments on spares, see section Spare UOC CPMs on
page 48.
Conversion using on Experion PKS Node and Experion PKS Rack
A PLC-CPM can be converted using an Experion PKS node that has an installation of Firmware
Manager together with an off-process ControlEdge controller rack that is part of the Experion
system. The necessary system components are summarized in the following diagram.
- 45 -
Figure 4.2 PLC CPM-UOC CPM Conversion using Firmware Manager on Experion System
Refer to Firmware Manager User Guide_EPDOC-X470.pdf for information on:

l How to setup the Experion PKS node and the PLC-CPM for conversion.
l How to perform the PLC-to-UOC conversion
Conversion using Bench Laptop and Experion PKS Rack
A PLC-CPM can be converted using a laptop that has an Bench installation of Firmware Manager
together with an off-process ControlEdge controller rack that is part of an Experion system. This
hybrid method is similar to using a Bench system but it is not required to deploy a separate
controller rack and power supply. The necessary system components are summarized in the
following diagram.
- 46 -
Figure 4.3 PLC CPM-UOC CPM Conversion using Firmware Manager on Laptop
Refer to Firmware Manager User Guide_EPDOC-X470.pdf forinformation on:

l How to create the Bench System laptop or PC.
l How to setup the Bench System PC and the PLC-CPM for conversion.
l How to perform the PLC-to-UOC conversion
Spare UOC CPMs
An important consideration in converting a PLC into a UOC is whether the site requires spares.
If spares are needed, a conscious decision must be made as to whether a spare is stored as a PLC
or as UOC.
If a spare is maintained as a PLC, and if a conversion Bench System is preserved for ongoing use,
then the CPM can be converted to a UOC at any time. However, the process of conversion is not
instantaneous. If it is desired to have a UOC available for quick use in an emergency, then it must
be converted ahead of time.If no bench system is set up to support future conversions and instead
a temporarily available controller rack is used, it is recommended to create the desired number of
spare UOC CPMs before the rack is put on-line. Doing so makes them available for quick use in
case of an emergency.
If additional UOC-CPMs are needed later and no bench system has been set up for conversion,
then a means will have to be found to use existing equipment. Given that a CPM is needed, the
system may have a controller rack which is already off-line. If so, that rack may be used to do the
conversion. If not, then a CPM will have to be taken off-line in order to do the conversion.
TIP
After the CPM has been converted into an UOC, please affix the UOC label over the CPM
mode switch as described in Hardware Considerations. This facilitates a quick UOC
replacement, as the label indicates that the unit has been converted to a UOC
- 47 -
4.2.2 Upgrading UOC CPM to New Firmware Version

The UOC Control Processor Module (CPM) uses two firmware images as follows:
l Boot Image: Also known as the Boot-Recovery Image, this firmware enables the CPM to boot
up, run diagnostics, communicate and support firmware load. It does not enable the CPM to
perform its control mission. The existence of the Boot Image insures that the CPM can always
allow its firmware to be reloaded, even if the Application Image is absent or non-functional.
l Application Image: Also known as the Application-Product Image, this firmware provides all
functionalities of the Boot Image as well all enablers required for the control mission. The
Application Image allows the CPM to boot up without assistance from the Boot Image. Under
normal operation, the CPM executes out of its Application Image only. Execution enters the
Boot Image only in the event of a system failure or during the process of firmware load.
After a CPM has been converted from PLC firmware to UOC firmware, updates are done on an
Experion system using Firmware Manager. Either the Application Image, the Boot Image, or both
can be loaded.
When updating UOC firmware, only one Firmware Manager client at a time may load firmware to
the UOC. In addition, the total number of Firmware Manager clients that may connect to a UOC at
one time, for monitoring node status or for loading firmware, is limited to 4.
The UOC must be running in the application (RDY) to upgrade the recovery image and in recovery
(ALIVE) to upgrade the application. Synchronization must be disabled before attempting firmware
upgrade. The firmware manager will place the UOC in the proper state for loading each image.
Care must be taken when upgrading the firmware of a redundant UOC pair. As of R511.1, on-
process firmware upgrade of a redundant UOC is not supported. The controller must first be taken
off-line by setting the CEE state to Idle. In addition, synchronization between the primary and
secondary partners must be disabled so that the UOC does not attempt to switchover during the
firmware upgrade process. Upgrade the firmware in the backup, then the firmware in the primary.
New firmware images are frequently received with major Experion releases. They can also be
received via download from the HPS website.
For instructions on how to load firmware using Firmware Manager see Firmware Manager_EPDOC-
X404.pdf.
4.2.3 Upgrading UOC EPM to new Firmware Version

When updating to a new release, always update UOC before updating EPM.
You must always use the firmware from the Experion media. The firmware that is purchased from
ControlEdge PLC must not be used. If you have purchased the product from ControlEdge PLC, you
must perform the following procedure to upgrade the firmware.
Like the CPM, the UOC EPM uses two firmware images, a Boot Image and an Application Image.
The two images play the same role within the EPM as do the corresponding images in the CPM.
Unlike the CPM, these firmware images are of the same type as those used by the ControlEdge
PLC, though they may be at different version levels.
NOTE
To know the latest EPM Firmware version, refer to the SCN document.
NOTE
When loading firmware to an EPM, the firmware obtained with the Experion installation
- 48 -
must always be used. Firmware that might have been obtained from a ControlEdge PLC
installation must not be used.
NOTE
Update EPM only after updating UOC (if needed).
For a UOC system, updates of EPM firmware are done on an Experion system using Firmware
Manager.
The load of firmware to EPM works by sending the firmware packets to the CPM which then
forwards them to the EPM. The parent CPM of an EPM must be known to Firmware Manager in
order for the load to take place. Firmware Manager supports a means whereby the EPM children of
a CPM can be specified.
When updating EPM firmware, only one Firmware Manager client at a time may load firmware to
the EPM through its parent UOC. In addition, the total number of Firmware Manager clients that
may connect to a UOC at one time, for monitoring node status or for loading firmware, is limited to
4.
New images are sometimes received with major releases of Experion. They can also be received via
download from the HPS website.
For instructions on how to load firmware using Firmware Manager, see Firmware Manager_
EPDOC-X404.pdf.
Upgrading the UOC EPM
The procedure used to upgrade EPM firmware varies depending on the downlink network protocol
in use. In one case, the selected protocol must be temporarily changed during the course of
upgrade. In some cases, network redundancy must be temporarily disabled during the course of
upgrade.
Procedure to upgrade EPM Firmware in a UOC Nonredundant or PRP network:
NOTE
For PRP networks, redundant network connectivity should be left disconnected during the
process of EPM firmware upgrade.
1. Set the 100x switch position of the EPM as per the desired UOC downlink network protocol
(position 4 for Nonredundant or PRP).
2. Connect Ethernet Port 1 of the EPM to the UOC download link network, leaving Ethernet Port
2 disconnected.
3. Insert the EPM into the IO rack, causing it to reboot.
4. Upgrade EPM Firmware using Firmware Manager.
Procedure to upgrade EPM Firmware in a UOC HSR network:

1. Set the 100x switch position of the EPM as per the desired UOC downlink network protocol
(position 3 for HSR).
2. Connect both Ethernet Port 1 and Ethernet Port 2 of the EPM to the UOC download link
network.
Procedure to upgrade EPM Firmware in a UOC DLR network:
- 49 -
NOTE
For PRP networks, redundant network connectivity should be left disconnected during the
process of EPM firmware upgrade.
1. Temporarily set the 100X switch position of the EPM to 4 (PRP protocol).
2. Connect Ethernet Port 1 of the EPM to the UOC downlink network, leaving Ethernet port of
EPM disconnected.
5. Change the 100x switch to position 5 (DLR).
7. Connect the Ethernet Port 1 and Port 2 of the EPM to the UOC downlink network, closing the
DLR ring.
For detailed instructions on the use of Firmware Manager see the Firmware manager User Guide.
For information on which version of EPM firmware is supported in the current release see the
Software Change Notice (SCN).
4.2.4 Upgrading UOC UIOM to new Firmware Version

When updating to a new release, please update UOC and EPM before updating UIOM.
Like the CPM and the EPM, the UOC UI/OM uses two firmware images, a Boot Image and an
Application Image. The two images play the same role within the UI/OM as do the corresponding
ones in the EPM and CPM.
However, in the case of the UI/OM, the Boot Image rarely changes but both images are loadable.
Like the EPM, the UI/OM has an Application Image which is of that same type as that used by the
ControlEdge PLC, though they may be at different version levels.
NOTE
When loading firmware to a UI/OM, the firmware obtained with the Experion installation
must always be used. Firmware that might have been obtained from a ControlEdge PLC
installation must not be used.
NOTE
Update I/OM only after updating UOC and EPM (if needed).
For a UOC system, updates of UI/OM firmware are done on an Experion system using Firmware
Manager.
The load of firmware to UI/OM works by sending the firmware packets to the CPM which then
forwards them to the EPM which in turn forwards them to the UI/OM. The parent EPM of a UI/OM
must be known to Firmware Manager in order for the load to take place. Firmware Manager
supports a means whereby the UI/OM children of an EPM can be specified.
When updating UI/OM firmware, only one Firmware Manager client at a time may load firmware to
the UI/OM through its parent UOC. In addition, the total number of Firmware Manager clients that
may connect to a UOC at one time, for monitoring node status or for loading firmware, is limited to
4.
- 50 -
New Application Images are sometimes received with major releases of Experion. They can also be
received via download from the HPS website.
For instructions on how to load firmware using Firmware Manager, see Firmware Manager_
EPDOC-X404.pdf.
4.2.5 Firmware and Software Upgrade Considerations for vUOC

The Unit Operations Controller and virtual Unit Operations Controller (vUOC) are equivalent with
respect to most major functionalities. However, when it comes to platform maintenance activities
such as firmware load of the controller itself, they are different.
vUOC is deployed as a virtual machine by importing a .ova file into a virtualization hypervisor. It has
no firmware or firmware load capabilities as such. Thus, updates to vUOC software are done by
deploying a new .ova file rather than loading new firmware to a CPM.
UOC-CPM and vUOC are designed to use the same communication channels to support load of
firmware to EPM and UI/OM. Each receives packets sent by Firmware Manager and forwards them
to the target module. However, in the Experion R511 release, the vUOC capabilities to support EPM
and UI/OM firmware load are not yet enabled. Firmware Manager is used to load firmware to CPM
and UI/OM.
For further information on how vUOC software is deployed see the vUOC section.
4.2.6 Additional Maintenance Activities in Firmware Manager

In addition to conversion of a PLC CPM into a UOC CPM, update of CPM firmware, update of EPM
firmware and update of UI/OM firmware, Firmware Manager supports maintenance activities
unrelated to firmware load. Key among them is the ability to upload diagnostic data from a CPM
which is not operating properly. For information on diagnostic data upload using Firmware
Manager, see Firmware Manager_EPDOC-X404.pdf.
- 51 -
CHAPTER
5 CONFIGURATION
5.1 Configuration Studio

Configuration Studio is the central location from which you can access engineering tools and
applications to configure your Experion system. When you choose Control Strategy in the
Configuration Explorer tree and then choose the task Configure a Control Strategy, Control
Builder is launched so you can configure ControlEdge 900 I/O hardware modules and build the
process control strategies for your system.
5.2 Define and add assets in your enterprise model

If you are using Enterprise Model Builder (EMB) application to create an asset model of your
system, assets that represent UOC controllers can be created and added to your model following
the same procedures for creating assets and alarm groups. See the Enterprise Model Builder User's
Guide for details.
5.3 Control Building

For information on Control Builder, see the Control Building User’s Guide.
5.4 Specifying a Time Server

UOC requires a reference source for time in order to power up and normally operate, but limited
controller operation can be achieved in cases where system time is not available. Connection to
the time source is made at controller start up.
Network Time Protocol synchronizes the controllers and other nodes to Coordinated Universal
Time (UTC). The time source is given an IP address so that controllers and other nodes can access
time. See the Setting system preferences in the Control Building User's Guide for more information
about setting IP addresses.
Precision Time Protocol (PTP) does not require any server configuration. If a PTP server is present
on the subnet and PTP is enabled in the module, it will work.
5.5 FTE Device Index

The FTE Device Index uniquely identifies the controller on the FTE Network. The FTE Device Index
is configured in two places. First, the CPM rotary switches are used to set the FTE device index of
the UOC. Second, Experion PKS Control Builder is used to configure the FTE Device Index in the
UOC Platform Function Block.
Control Builder enforces the following:
- 52 -
Chapter 5 - Configuration
l The primary controller (of a redundant controller pair) always configured with an odd
numbered Device Index.
l A non-redundant controller is only configured with an odd numbered Device Index.
l The secondary controller of a redundant controller pair is configured with the even Device
Index that is consecutive with its primary partner’s Device Index (i.e. primary controller Device
Index plus 1).
Set the Device Index (FTE DEVICE INDEX) by turning the three rotary decimal switches (range 001
to 509). The leftmost switch on top is used for setting the hundreds digit, the right switch on top is
used for setting the tens digit, and the bottom switch sets the ones digit.
Example: For a redundant pair, the primary and secondary indexes respectively could be 001, 002;
111, 112; 507, 508 and so on. In a non-redundant setup, the index could be: 001 or 111 or 507 and
so on.
Failure to replicate the UOC Device Control Index according to their Control Builder configured
Device Indexes will lead to failure in establishing Control Builder - controller communication
thereby preventing configuration load.
For in-rack redundancy, the left controller is recommended to be configured as the odd device
index and the right controller as the event device index (of the consecutive device index pair).
Redundancy communication between a pair of redundant UOC is not possible if their device
indices are not set to a consecutive odd/even pair.
In the non-redundant case, the odd+1 address is reserved for future redundancy. It must not be
assigned to any other function.
5.6 Creating UOC Platform block
5.6.1 Method 1: Using the File Menu

Using the File menu, select File > New > Controllers > UOC - Control Edge Unit Operations
Controller.
5.6.2 Method 2: Using the Project Assignment Panel

Using the Project Assignment panel context menu, right-click in the white area of the panel and
select New > Controllers > UOC - Control Edge Unit Operations Controller.
- 53 -
5.7 UOC Platform Block

The UOC Platform Block or “UOC Block” presents parameters which describe key characteristics of
the UOC CPM platform and allows a subset of those parameters to be configured. The UOC Block is
configured within Experion Control Builder along with all other elements of UOC configuration.
Configuring and loading the UOC Block is one of the first steps required to make a UOC HW set
known to the Experion system.
The following sections describe configuration forms of the UOC Block that are accessible from
within Control Builder. Like all Control Builder forms, these can be examined under two different
views. One is the Project View which allows for configurable parameters to be assigned values
before load of the UOC Block. The other is the Monitoring View which allows parameter values of
the UOC Block to be read from the controller while it is running.
For a general introduction to the use of Experion Control builder in configuring and monitoring
platform blocks, CEE blocks, Control Modules, Sequence Control Modules and other types of
loadable objects, see Control Builder User’s Guide_EPDOC_XX19_en-511A.pdf.
- 54 -
Tab Description
Main tab
This tab is used to configure the UOC block. This tab also displays important
state information and supports generation of commands to the CEE via
parameter writes. The screenshots below show descriptions and names of
each parameter that appears on the configuration form of the Main tab. For
further information about each parameter, consult the Control Builder
Parameter Reference Guide_EPDOC-XX18-en-511A.pdf.
Take note of the following considerations when configuring the Main tab of
the UOC Platform block.
The DHCP address range used by EPMs on the downlink is configured from
the “Downlink Address Configuration” section. The UOC’s DHCP server assigns
IP addresses based on the module number set on the 10X and 1X rotary
switches of the EPM board. The address range can cover up to 12 addresses
with EPM module number 1 being mapped into the start address of the range.
If an EPM module number is set outside the DHCP address range, it will not
receive an IP address and will not be able to communicate. Care must be taken
to ensure that the address range has been configured correctly before going
on process. If the address range needs to be changed, it can only be done by
reloading the UOC platform block while the UOC is off process.
The Connection Type configured in the “Downlink Network Configuration”
section changes the way the UOC behaves with respect to downlink network
redundancy. For more information refer to to 3.2 Downlink I/O Network
Topology.
NOTE
Two screens in all the following tabs show Parameter Names”
checked/unchecked.
- 55 -
Tab Description
System Time tab

This tab provides information about the UOC’s time configuration. The “System
Time” and “System Time Synchronization Status” subgroups on this tab
provide current controller system time and indicate the synchronization time
source and the status of that source. The “NTP Status” and “Precision Time
Protocol” subgroups provide statistics related to time synchronization with
NTP and PTP servers, along with their status.
The screenshots below show descriptions and names of each parameter that
appears on the configuration form of the System Time tab. For further
information about each parameter, see Control Builder Parameter Reference
Guide_EPDOC-XX18-en-511A.pdf.
Tab Description
Statistics tab
This tab shows a variety of statistics parameters that can be monitored to learn
about the processing load and operating conditions of the UOC. Such
information includes CPU utilization, hardware temperature and
communications subsystem (CDA) statistics. The screenshots below show
descriptions and names of each parameter that appears on the form of the
Statistics tab. For further information about each parameter, see Control
Builder Parameter Reference Guide_EPDOC-XX18-en-511A.pdf.
- 56 -
Tab Description
Hardware Information tab
This tab contains data describing the UOC module including firmware and
hardware version information. The parameters provided here are used for
maintenance, troubleshooting and problem description purposes. All
parameters on this form are read-only. Note that the Hardware Information
Tab displays several parameters related to UOC retention restart. These are as
follows. The screenshots below show descriptions and names of each
parameter that appears on the form of the Hardware Information tab. For
further information about each parameter, see Control Builder Parameter
Reference Guide_EPDOC-XX18-en-511A.pdf.
Retention Data Attendance

The RETENDATAATTND parameter has enumeration values Absent and Present
to indicate when retention data does not exist and retention data has been
saved. When set to Present, the RETENTSAVETIME parameter indicates the
time when the retention data was saved.
Retention Data Save Time
When RETENDATAATTND is Present, RETENSAVETIME indicates the last time
retention data was saved.
Retention Restart Veto Reason
Initialized once on startup to indicate the reason why the controller has vetoed
retention startup.
l None – Retention restart was not vetoed.
l DeviceIndexChanged – Retention restart was vetoed due to a change in
the controller’s device index setting.
l BaseIpAddrChanged – Retention restart was vetoed due to a change in
Base IP Address (and/or Base IP Mask). A change in base IP Address
implies the controller was redeployed in a different Experion cluster
without changing its Device Index.
l UnsupportedHardware – The controller hardware is defective or was not
properly initialized when it was manufactured.
- 57 -
Tab Description
l RetentionMediaError – Retention restart was vetoed due to invalid
retention memory detected by the controller. Possible causes for invalid
retention memory are as follows:
l SD card missing.
l SD card not inserted fully or not inserted properly.
l SD card format not recognized.
l SD card locked for read-only access.
l RetentionDataAbsent – Retention data was not saved.

l RetentionDataCorrupt – Retention data exists but did not pass controller
validation.
l RetentionDataExpired – The retention data was saved more than 48 hours
ago.
l RedundancyRoleSecondary – The retention data is discarded when the
controller is in the secondary redundancy role.
l TimeSyncNotConfigured – Time-sync is not configured on the controller.
Without time-sync configured, the controller cannot determine the age of
the retention data and to be safe, the retention data is discarded.
l TimeSyncTimeout – Time-sync is configured on the controller, but the
controller timed-out waiting for the time-sync server response. Without
time-sync configured, the controller cannot determine the age of the
retention data and to be safe, the retention data is discarded.
- 58 -
Tab Description
FTE tab
This tab contains statistics related to Fault Tolerant Ethernet (FTE)
communications and performance. The FTE tab features parameters
associated with the MAC Address Resolution Table (MART) which deals with
online media access control (MAC) address mapping. All parameters of the
FTE tab are read-only. The screenshots below show descriptions and names of
each parameter that appears on the form of the FTE tab. For further
information about each parameter, see Control Builder Parameter Reference
Guide_EPDOC-XX18-en-511A.pdf.
- 59 -
Tab Description
Downlink tab
This tab shows statistics and configuration parameters related to downlink
Ethernet communications.
For DLR, the Primary defaults to ring supervisor. The supervisor parameters
are exposed and default to values appropriate for, when UOC is the only
supervisor.
The supervisor precedence must be configured as highest precedence value so
that UOC takes the active supervisor role.
NOTE
l Downlink connection type can be changed from disabled to any
Downlink connection type like HSR, PRP, Non-redundant start.

This can be done on-process.
l The supervisor parameters are exposed and default to values
appropriate for when UOC is the only supervisor.
l Changing Downlink connection type from HSR/ PRP to DLR
would require an off-process and a restart is required.
l Downlink connection type can be changed from disabled to any
Downlink connection type like HSR, PRP, Non-redundant start.
This can be done onprocess.
l Changing Downlink connection from disabled to DLR would
require an off-process and a restart is required.
NOTE
If a Rapid Fault condition is detected, manual intervention is needed
to clear the state in Control Builder or Station. This fault occurs when
a series of rapid ring faults is detected, typically with a ring fault and
recovery cycle of 5 times in 30 seconds.
NOTE
To detect the fault location in a ring network, you must clear the first
fault in the ring and click Update Locate fault .This will re-initiate the
search and locate the next fault location in the ring, if any.
For further information about each parameter, see Control Builder Parameter
Reference Guide_EPDOC-XX18-en-511A.pdf.
- 60 -
Tab Description
Tab Description
UDP/TCP tab
This tab displays statistics related to open UDP and TCP connections
associated with this UOC controller. All parameters on this form are read-only.
appears on the form of the UDP / TCP tab. For further information about each
parameter, see Control Builder Parameter Reference Guide_EPDOC-XX18-en-
511A.pdf.
- 61 -
Tab Description
IP/ICMP tab
This tab displays statistics related to IP and ICMP protocol messages
associated with (i.e. originating in or received by) this UOC controller. These
types of messages are generally associated with maintenance and status
operations on the network. All of the parameters shown on this form are
read-only.
The screenshots below show descriptions and names of each parameter
that appears on the form of the IP / ICMP tab. For further information
about each parameter, see Control Builder Parameter Reference Guide_
EPDOC-XX18-en-511A.pdf.
- 62 -
Tab Description
Soft Failures tab
This tab indicates which soft failure conditions, if any, are active. Users
typically navigate to this form after receiving a general indication that at
least one soft failure is present, such as a soft failure notification. All
parameters shown on this form are read-only.
that appears on the form of the Soft Failures tab. For further information
NOTE
The HSR/PRP LAN ID soft failure is only cleared by resetting
statistics (See Statistics tab). This will clear the LAN ID error
counts and the soft failure.
- 63 -
Tab Description
Security tab
This tab allows for the disabling of optional protocols. As an additional
security measure, Honeywell recommends disabling protocols which are
not required in a particular UOC deployment. Most UOC protocols are
required for proper function in all deployments. HART / IP can be disabled
when not in use. HART/IP must be enabled when FDM is used.
- 64 -
Tab Description
Server History tab
This tab is common to all configuration forms for tagged blocks in Control
Builder. This form allows users to specify individual parameters of the
block which are to be collected for history recording.
ATTENTION
The configuration settings you make for Server Load Options on
the System Preferences dialog determine whether or not the data
entered on the Server History tab is loaded to the Experion Server.
See Control Building User Guide for information about setting
system preferences.

that appears on the form of the Server History tab. For further information
- 65 -
Tab Description
Server Displays tab
Builder. It allows users to associate Point Detail, Group Detail, Associated
and Trend displays with the block.
that appears on the form of the Server Displays tab. For further information
- 66 -
Tab Description
Control Confirmation tab
Builder. If you have an optional Electronic Signature license, you can
configure electronic signature information for the tagged block through
this tab on the block's configuration form in Control Builder. Please refer
to the Server and Client Configuration Guide for information about the
data on this tab.
The Electronic Signature function aligns with the identical Electronic
Signatures function that is initiated through Quick Builder and Station for
Server points. When this block is loaded to a controller, its control
confirmation configuration (electronic signatures) is also loaded to the
Server. This means you can view the control confirmation configuration for
this tagged object in Station and also make changes to it. If you make
changes through Station, you must initiate an Upload or Upload with
Contents function through the Controller menu in Control Builder for the
object in the Monitoring tab to synchronize changes in the Engineering
Repository Database (ERDB). The screenshots below show descriptions
and names of each parameter that appears on the form of the Control
Confirmation tab. For further information about each parameter, see
Control Builder Parameter Reference Guide_EPDOC-XX18-en-511A.pdf.
- 67 -
Tab Description
QVCS tab
Builder. If you have a Qualification and Version Control System (QVCS)
license, this tab shows current QVCS information for the selected UOC
block. Please refer to the Qualification and Version Control System User's
Guide for more information about the data on this tab The screenshots
below show descriptions and names of each parameter that appears on the
form of the QVCS tab. For further information about each parameter, see
Control Builder Parameter Reference Guide_EPDOC-XX18-en-511A.pdf.
NOTE
It is mandatory to use the Revert Label feature for template based EIP I/OMs (E.g:
Generic Device Modules or Generic I/O Modules) to perform QVCS Revert operations.
Failure to apply a common label to the template and the corresponding instance will
lead to a deadlock situation if performing Revert Version operations. It is mandatory that
the template and the corresponding instance must have the same version label. This
can be achieved by applying the same label to both the template and its corresponding
instance.
- 68 -
Tab Description
Identification tab
Builder. It allows users to record information about the intended purpose
and maintenance history of the block.
that appears on the form of the Identification tab. For further information
5.8 Secondary UOC Platform Block

The Secondary UOC controller block is available when the ‘Module is redundant’ (MODISREDUN)
check box is checked on the Primary UOC configuration form Main tab. The Secondary UOC
configuration form contains the same tabs and parameters as the primary with the exception of a
few parameters on the Main and Redundancy tabs. The differences are described in the following
paragraphs.
- 69 -
Tab Description
Main tab
This tab of the Secondary UOC Block configuration form does not contain the
‘Module is redundant’ or ‘Secondary Tag Name’ fields. All other parameters
contained on the Primary's Main tab are present on the secondary's Main tab.
Parameters in the Advanced Configuration subgroup are copied from the
primary block to the secondary block and are view only on the secondary's
form.
NOTE
checked/unchecked.
Redundancy tab
This tab of the Secondary UOC block contains the parameter ‘Last Block
Migrated’ (LASTOPMNAME) which is not applicable on the Primary UOC block.
5.9 CEE Function Block

The CEE function block is created when a new UOC controller block is created and configured in
the CB Project tree. The following sections illustrate the Control Builder forms of each tab of the
CEE block. For more details about these parameters, see Control Builder Parameter Reference_
NOTE
The UOC’s CEE block is sometimes called the “CEE UOC” block to highlight the fact that it
has some differences from the CEE block of other controllers such as the C200, C200E,
C300. However, its major characteristics are consistent with those of other CEE controllers.
- 70 -
Tab Descripton
Main tab
This tab is used for the configuration of the CEE block. The configuration steps
are defined in Control Building User’s Guide (Control Building User’s Guide_
EPDOC-XX19-en-511A.pdf). This tab also displays important state information
and allows the store of some runtime parameters. The screenshots below show
descriptions and names of each parameter that appear on the configuration
form of the Main tab. For further information about each parameter, see
Control Builder Parameter Reference_EPDOC-XX18-en-511A.pdf.
For secondary platform block, refer section Secondary UOC Platform Block.
NOTE
checked/unchecked.
Show Parameter Names” checked/unchecked
- 71 -
Tab Description
Peer Configuration tab
This tab contains information about user-defined peer connections for the
CEE block. The Peer Configuration tab displays information about peer
connections established by this CEE. It allows a global default subscription
period for peer reads to be established and also allows different subscriptions
to be established for particular peer environments. The screenshots below
show descriptions and names of each parameter that appear on the form of
the Peer Configuration tab. For further information about each parameter, see
Control Builder Parameter Reference_EPDOC-XX18-en-511A.pdf.
Tab Description
Statistics tab
This tab displays a variety of statistical information characterizing different
types of communication mechanisms used by the CEE. The screenshots below
the Statistics tab. For further information about each parameter, see Control
Builder Parameter Reference_EPDOC-XX18-en-511A.pdf.
- 72 -
Tab Description
CPU Loading tab
This tab is organized as a set of 4 arrays, each one indexed by the number of
CEE processing cycles, 0 through 39. Statistics values which characterize a
particular cycle are shown at its corresponding cycle number.
The first column shows average CPU used for each cycle. The second shows,
for each cycle, the maximum CPU usage since the time of last UOC statistics
reset. The third and fourth columns together show the quantity of data sent
from primary to secondary, for the particular cycle, as part of redundancy
synchronization communication. Each column reflects a different redundancy
synchronization mechanism.
Each array also shows a value for index 40, indicating the value normalized
over cycles 0 through 39. In the case of CPU cycle average array, element 40
shows the average across all cycles. In the case of the 3 maximum arrays,
element 40 shows the maximum across all cycles.
appears on the form of the CPU Loading tab. For further information about
each parameter, see Control Builder Parameter Reference_EPDOC-XX18-en-
511A.pdf.
- 73 -
Tab Description
CPU Overruns tab
This tab is organized as a set of 2 arrays, each one indexed by the number of
CEE processing cycles, 0 through 39. Statistics values which characterize a
particular cycle are shown at its corresponding cycle number.
The first column shows the count of CEE processing cycle overruns that have
occurred so far in the current hour. The second column shows the count of
CEE processing cycle overruns that occurred in the previous hour. The current
hour counts in the first column accumulate until the end of the hour and then
get transferred into the second column. Start and end times for the hourly
intervals are not correlated with wall clock time.
Each array also shows a value for index 40, indicating the sum of all overrun
counts over cycles 0 through 39.
appear on the form of the CPU Overruns tab. For further information about
511A.pdf.
- 74 -
Tab Description
EtherNet/IP Statistics tab
This tab shows the IP address and connection status of each UOC downlink
connection to an EtherNet/IP device. For bridged connections to modular I/O
stations, it also shows the slot number corresponding to each I/O module. This
form displays only read-only parameters.
appear on the form of the EtherNet/IP Statistics tab. For further information
about each parameter, see Control Builder Parameter Reference_EPDOC-XX18-
en-511A.pdf.
Tab Description
CLX Statistics tab
This tab presents information about UOC’s downlink EtherNet/IP
communication with ControlLogix PLCs. Information displayed includes
counts of tagged data reads and writes initiated by the UOC, IP addresses of
connected PLCs, status of each PLC connection and transactions per second
to each PLC. This form shows only read-only parameters.
appear on the form of the CLX Statistics tab. For further information about
511A.pdf.
- 75 -
Tab Description
Batch tab
This tab shows information related to batch processing being carried out by
the UOC. This includes configurable parameters for Batch Event Settings and
Activity Configuration. It also includes 4 read-only arrays which indicate
whether any Control Recipe cycles have been skipped and for what period of
time.
appear on the form of the Batch tab. For further information about each
parameter, see Control Builder Parameter Reference_EPDOC-XX18-en-
511A.pdf.
Tab Description
Memory tab
This tab presents information on UOC memory usage within CEE’s user
memory pool. Of most interest to end users are statistics indicating used and
free memory. These are shown in units of both kilobytes and bytes. Also shown
are all descriptor counts and block counts which provide information related
to internal memory management within CEE.
appear on the form of the Memory tab. For further information about each
511A.pdf.
- 76 -
Tab Description
Peer Connections tab
This tab contains data indicating the number of peer connections for both
initiator and responder types between this UOC controller and other peer-
capable nodes. All parameters on this tab are read-only.
appear on the form of the Peer Connections tab. For further information about
511A.pdf.
Tab Description
Peer Communications tab
This tab contains information about peer connections. It gives statistics for
connections initiated by the CEE block and connections to which the CEE
responds. The screenshots below show descriptions and names of each
parameter that appear on the form of the Peer Communications tab. For
further information about each parameter, see Control Builder Parameter
Reference_EPDOC-XX18-en-511A.pdf.
- 77 -
Tab Description
Exchange Communications tab
This tab contains information about exchange connections between the UOC
controller and a target controller or programmable logic controller. It gives
statistics for connections initiated by the CEE block. The screenshots below
the Exchanges Communications tab. For further information about each
511A.pdf.
Tab Description
Display Communications tab
This tab contains information about display connections to the UOC from
Control Builder, Direct Stations and Engineering Station.
appear on the form of the Display Communications tab. For further
information about each parameter, see Control Builder Parameter Reference_
- 78 -
Tab Description
Block Types Info tab
This tab shows the name of block types supported by the CEE together with
the size and count of the corresponding block instances. All parameters on
this form are read-only.
Note that certain IOREF block configurations internally execute either a Type
Convert or a Push block. These blocks will be counted against the block types
when IOREF blocks are downloaded.
appear on the form of the Block Types Info tab. For further information about
511A.pdf.
Server History tab

Builder.
Server Displays tab

Builder.
Control Confirmation tab

This tab is a common configuration form shared by all tagged blocks in
Control Builder.
Identification tab
Builder.
- 79 -
5.10 Configure UOC for Retention Startup
5.10.1 Introduction
This section describes the functionalities and user interface of the UOC CEE RETENTIONTRIG
Block system.
5.10.2 Configure RETENTIONTRIG block
Retention Data Save
CAUTION
During retention data save, controller outputs hold, but no control or communication
processing is performed. The duration of the freeze is 40 seconds or less. An overrun count
gets added to the cycle overrun statistics. Display or peer data access with the controller
performing retention save is delayed for the duration of the retention save that may result
in.
1. Server or Console Connection TIMEOUT alarms with the controller performing the
retention save, and
2. Loss-of-control related alarms for peer connections with the controller performing
the retention save.
The UOC Retention-restart behaviors are set up by instantiating the RETENTIONTRIG block within
a Control Module (CM) strategy. It works by sensing the status of external power fed to a backup
Power Source, typically a site wide UPS, which can provide output power for a time after it's
external input power has been lost. The concept is illustrated by the following diagram.
Figure 5.1 Retention Data Save
ATTENTION
The RETENTIONTRIG block must sense the status of external power fed to a backup power
source. In addition to the backup power source, this requires:
- 80 -
1. A means for the controller to sense the binary input signal. For example, a digital
input IOPOINT.
2. Wiring from external power (or from the backup power source) to the controller’s
binary input signal.
Important points to understand include the following:

l The status of External Power fed to the Power Source is sensed. One way to do this is
illustrated in the diagram where External Power is fed through a Relay to generate an External
Power Good signal, which in turn is fed to a Digital Input Module connected to the controller.
Alternatively, if the Power Source were a UPS or other device supporting network connectivity,
the External Power Good signal might be obtained via a Modbus / TCP or similar Ethernet
connection configured within the controller. When On / True, signal “External Power Good”
indicates that external power is functioning, when Off / False, it indicates that external power
has been lost.
l Whatever the connection methodology, the External Power Good signal is sensed by a CM
configured within the controller. The core of the CM configuration is the RETENTIONTRIG block
which allows the application engineer to specify a Delay time. When the External Power Good
signal is negated, the RETENTIONTRIG starts to count down the Delay time. If the External
Power Good signal is asserted before the countdown reaches 0, no action is taken and the
Delay count is reset. If the Delay count does reach zero, actions to save the controller database
are initiated.
l Data save actions start when the RETENTIONTRIG makes a request to the Platform Manager
service of the controller. This service takes all actions necessary to ensure that data is saved as
a complete and secure set. This includes performing the save as a “double buffering” operation
where any existing data set is not eliminated until the save of a new data set is correct and
complete.
l The data saved includes all configuration data as well as operational data such as modes and
setpoints. In order to do the data save, the Platform Manager freezes controller execution for
the duration of the save action. During this time period, controller outputs hold, but no control
processing is performed. The duration of the freeze is 40 seconds or less. An overrun count
gets added to the cycle overrun statistics. Display or peer data access with the controller
performing retention save is delayed for the duration of the retention save the may result in.
1. Server or Console Connection TIMEOUT alarms with the controller performing the
retention save, and
2. Loss-of-control related alarms for peer connections with the controller performing the
retention save.
l An important responsibility of the application engineer configuring the RETENTIONTRIG block

is to choose a Delay. This value expresses the time from loss of External Power to the Power
Source, to start of the save operation. The Delay value must be short enough to be assured
that the Power Source will have at least 40 seconds of output power remaining for the data
save operation. In choosing the Delay value, the application engineer should take into
consideration the characteristics of the Power Source, its system deployment, and its power
delivery capacity as it ages over time. In the typical use case, the Power Source would be a
system wide UPS powering multiple devices.
Specific deployments of a CM with the RETENTIONTRIG block can differ in detail from the overview
scheme depicted above. For example, depending on the number of Power Sources and how they
are connected, there might be two External Power Good signals rather than just one, each with its
own delay configuration. But, the basic principles captured above always apply.
- 81 -
Retention Data Non-Volatile Storage Memory
The UOC-CPM uses its Secure Digital (SD) card as the non-volatile memory for the storage of
retention save data. The virtual UOC saves its retention data to its local hard disk. Both UOC
variants are different from controller designs which use battery-backed RAM as their non-volatile
storage medium.
ATTENTION
Retention NVS is the generic term used throughout this document for UOC-CPM SD card
memory and virtual UOC local disk retention memory.
SD Card Minimum Specifications
The Honeywell minimum SD card specifications are as follows.

l Speed class C10/U1/V10 that has minimum 10 MB/s sequential writing speed to minimize the
retention data save time.
l 8 GB capacity with 64 GB recommended for future functional expansion (without having to
upgrade the SD card).
l Ensure the SD card supports the same or greater temperature range than that of the UOC:
o Operating temperature 0 °C to 60 °C
o Storage temperature -40 °C to 85 °C
The UOC-CPM supports the three SD card types: SD Standard Capacity (SDSC), SD High Capacity
(SDHC), and SD Extended Capacity (SDXC).
The recommended SD card format is FAT32.
CAUTION
Upon SD card detection at either startup or insertion under power, the UOC formats the SD
card if it is not the expected format. Therefore, the SD card’s prior contents may be erased.
SD Card Optional Usage
Users not planning on employing UOC retention restart support do not need to insert an SD card
into the UOC-CPM. The SD card is only required if the user enables UOC retention restart support.
To enable UOC retention restart support, configure a RETENTIONTRIG block within a Control
Module (CM) and load the CM to the UOC’s CEE. This is the only step required for the virtual UOC
because the virtual UOC saves its retention data to its local hard disk. The UOC-CPM hardware
requires the additional step of inserting an SD card into the UOC-CPM. If the controller is
configured as redundant, insert an SD card in both the primary and secondary UOC-CPM. When
the RETENTIONTRIG block is loaded, the non-redundant or primary UOC generates a
“NVS/Retention Restart Media Error” soft failure notification if the SD card is absent (from the
UOC-CPM) as described in section NVS/Retention Restart Media Error.
To disable UOC retention restart support, delete the RETENTIONTRIG block from the UOC. The SD
card(s) may optionally be removed from the UOC-CPM(s); they are not used without the
RETENTIONTRIG block loaded to the UOC.
- 82 -
SD Card Removal and Insertion Under Power
CAUTION
Do not insert or remove the SD card when the UOC-CPM is powered unless the area is
known to be non-hazardous.
The UOC-CPM hardware supports SD Card removal and insertion under power (RIUP). However, it
is recommended that the SD card be inserted and not removed for the life of the controller
because:
l Retention Save is not possible when the SD card is removed.
l SD card removal during retention save results in an incomplete retention save; the partial
retention data set cannot be used for retention startup.
Retention Data Lifetime
The UOC and vUOC save retention data to enable the preservation of configuration and
operational data across a loss of external power. This allows them to automatically return to
normal operation after external power is recovered.
The data saved has a finite lifetime consistent with the above objective. It is not persisted
indefinitely. Instead, it is deleted after a controlled interval to prevent it from becoming
inconsistent with changes to the controller configuration. Retention data is deleted after 48 hours
from the last time it was saved. Upon deletion, the Retention Data Attendance parameter,
RETENDATAATTND, is updated to indicate retention data is absent.
Furthermore, consider the following scenario. If the controller performed retention save at time
T1, the user then added or deleted a strategy at time T2, and the controller power-cycled at time
T3, without having done a new retention save, then the retention restore following T3 would use
the data saved at time T1 which was missing the configuration changes applied at time T2. To
avoid the potential for unexpected behavior, this type of scenario is prevented by deleting
retention data when a control strategy is added, deleted, or reloaded. Upon deletion, the Retention
Data Attendance parameter, RETENDATAATTND, is updated to indicate retention data is absent.
retention data is absent.
It is not possible to reuse retention data with a different firmware version. Retention data cannot
be persisted across firmware upgrade.
Once retention data save is performed, the UOC or vUOC generates a hash value per retention
data file (to later validate file integrity on retention restart). For security reasons, each hash value
is signed using a unique private key to ensure it was not tampered while at rest. As a consequence,
the retention data saved on a SD Card is only valid for the controller that performed the retention
save because it is the only controller with the unique private key to validate the retention data was
not tampered.
Retention data on a SD card cannot be used for retention restart after UOC-CPM device
replacement.
Retention data is deleted on controller transition to the Fail State. This ensures controller recovery
from the Fail State in case the retention data is not corrupt but it was saved with an illogical
condition that results in controller failure.
UOC Platform Block Retention Data
Configuration changes to the platform block are retained independently from the retention data
saved by the retention trigger block. Platform block changes are saved when they are received by
the controller via parameter stores. Consider the following scenario with a non-redundant
controller (for simplicity).
- 83 -
l Controller performs retention save at time T1.

l User changes the CPU Free Low Alarm threshold on the Platform Block from the Control
Builder monitor tab at time T2.
l User changes some control strategy setpoints at time T3.
l Controller is power-cycled at time T4. (i.e. fresh retention-save not performed).
On startup, the controller performs retention restore but the control strategy is restored as it was
saved at T1, discarding the setpoint changes at time T3. However, the platform block is restored
with the changes made at time T2.
Behaviors During Power Loss
States
The way a UOC behaves over the course of power loss can be different depending on
circumstances. Differences result from how long backup power might last and from the
configuration choices made by the application engineer.
The state diagram below illustrates key events that take place over the course of a power loss
event.
Figure 5.2 Behaviors During Power Loss
Important states are as follows:
1. External Power, Normal

External power is available and the UOC is functioning normally. CEE processing within the
UOC is proceeding as normal, with all modules, blocks, and IO communications in full
execution. This is the initial state in effect when a power loss event starts. It is also the state in
effect after power returns and normal control processing resumes.
2. Backup Power, Counting Down
External power has been lost. CEE processing within the UOC is proceeding as normal. But a
countdown to the start of data save is in progress. If the countdown reaches 0 the UOC will
proceed to freeze control processing and save data.
3. Backup Power, Saving Data
External power has been lost long enough that the countdown time has expired. UOC is
saving data into retention NVS. During the save operation, CEE block execution is suspended
and outputs hold last values with fail-safe values not triggered. This state is transitional,
lasting 40 seconds or less.
- 84 -
4. Backup Power, Starting Up

External power has been lost. The UOC was configured to restart after retention save and has
entered its startup sequence. Outputs have been triggered to go to their configured fail-safe
values or to unpowered if they support no fail-safe configuration. There is no CEE control
processing in operation during the restart. This state is transitional, lasting less than 2
minutes.
This state is optional. It is used by the application engineer if he wishes to avoid a potentially
ambiguous state of the process resulting from a partial power loss where some actuators have
been left without power while other actuators are still powered. It assures that outputs go to
their configured fail-safe values or to unpowered. This condition, by common design practice,
should correspond to a safe, though nonoperational, state of the process.
Once start up completes, CEE returns to its previous state (normally Run) or goes to Idle,
subject to CEE configuration options. For information on CEE restart options see
documentation on parameter RRRCEESTATE
5. No Power
External power has been lost long enough that backup power has been exhausted. The UOC
is completely powered down.
6. External Power, Starting Up
External power has been recovered after the UOC reached a state of complete power down.
CEE control processing is not operational. All outputs are in an unpowered state. Once start
up completes, CEE returns to its previous state (normally Run) or goes to Idle, subject to CEE
configuration options. This state is transitional, lasting less than 2 minutes.
Configuration Decisions
There are several configuration decisions an application engineer makes that impact how a UOC
progresses through the states described above. These decisions are summarized below. More
detailed descriptions of configuration options are provided in subsequent sections.
l How long should the UOC wait after loss of external power before triggering a data save?
This delay time is configured in minutes via parameters SAVEDELAY1 and optionally
SAVEDELAY 2, depending on the power configuration. The value must be short enough
that that the user is confident a data save will start and complete, after loss of external
power, and before backup power has been exhausted.
l After data has been saved the first time, should the UOC go through a restart cycle?
An application engineer may use this option to force outputs to their configured fail-safe
values after the initial data save. Under default configuration, this option is disabled. When
enabled, it is not possible to enable repetitive saves while backup power lasts. This option is
configured via parameter FORCERESTART.
l After data has been saved the first time, should the UOC repeat the data save operation, at
intervals, while backup power lasts?
An application engineer may use this option to either save once after loss of external
power or to periodically save after loss of power. If data is saved only once after power loss
but backup power lasts for a significant time thereafter, the data used for restart of the
UOC could become somewhat stale. This doesn’t matter if the only data of interest is
configuration data. Configuration data generally does not change during a power loss
event. But if there could be operational data, such as setpoints or modes, which need to be
as fresh as possible at the time of restart, then the application engineer can set the save
operation to be repeated while backup power lasts.
Every time a save is done, control processing freezes for up to 40 seconds. Thus, if the
period of repetitive save were set to 10 minutes, a save and corresponding control freeze
up to 40 seconds would occur every 10 minutes. The period of repeated saves, or the
option to not repeat at all, is configured via parameter RESAVEPERIOD.
- 85 -
When a data save is repeated, with a previous data set already present and available in
retention NVS, the new save completes as normal. But only the most recently saved data is
used when the controller restarts after power up. Also, data is always saved in such a
fashion that, were power lost in the middle of a save, the previously saved and complete
data set is the one which will be used upon next restart.
l After the UOC completes startup processing, how should the CEE resume execution?
CEE restart behavior is configured via the CEE parameter RRRCEESTATE. Several
variations in behavior are selectable via this parameter but the main decision it presents is
whether the CEE should go to Idle (not executing control algorithms) or return to the state
it had just before power down (typically Run, where control algorithms are executed). For
further information on RRRCEESTATE see CEESTATE Transitions During Count Down to
Save.
The state diagram above assumes that RRRCEESTATE has been configured to return to
Run and normal control execution. The restart behavior driven by RRRCEESTATE could
occur on two different transitions. One is the transition from 6)External Power, Starting Up
to 1)External Power, Normal. The other is the transition from 4)Backup Power, Starting Up
to 2) Backup Power, Counting Down. However, the latter transition is optional. It does not
occur if the application engineer elects not to enable a restart operation following the first
data save.
Examples of Transition Sequences
Examples of state transition sequences that might occur upon UOC loss of power are shown in the
tables below. Note that, in each example cited, it is assumed that CEE has been configured to
return to its last state before power down and that this state was Run.
- 86 -
l Repeated saves, external power returns before loss of backup power
Assumptions
l SAVEDELAY1 and SAVEDELAY2 are configured with nonzero
values.
l FORCERESTART has been left at its default value of OFF.
l RESAVEPERIOD is configured with a non-NaN value.
l External power returns before backup power has been
exhausted.
State Comment
1. External The UOC is running as normal but then external power is

Power, lost.
Normal
2. Backup After a configured time interval, the count-down reaches

Power, 0.
Counting
Down
3. Backup Control freezes during save.

Power,
Saving Data
The cycle of count down and save could repeat multiple

times.

Power, 0.
Counting
Down

Power,
Saving Data
1. External External power returns before backup power exhaustion.

Power, The CEE never stops executing and does not execute any
Normal restart initialization upon return of external power.
Outputs never go to configured fail-safe values.
Note that the above sequence is one that could occur if configuration options are left at their
default values. The values of SAVEDELAY1 and SAVEDELAY2 default to 10 minutes but they
typically need to be customized to each UOC deployment. Application engineers should check
default values and change them as needed.
- 87 -
l One save with restart, external power returns before loss of backup power.
Assumptions
values.
l FORCERESTART has been set to ON.
l RESAVEPERIOD is configured to NaN, indicating that no
repeated saves are done.
l External power returns before backup power has been
exhausted.
State Comment

Power, lost.
Normal

Power, 0.
Counting
Down

Power,
Saving Data
4. Backup UOC shuts down and initiates its startup sequence.

Power, Outputs go to their configured fail-safe values. CEE
Starting Up executes its configured restart behaviors. Control
strategies execute their configured initialization behaviors
upon start up.
2. Backup The RESAVEPERIOD never counts down because it has

Power, been configured to indicate no repeated saves. The save
Counting operation is done only once after expiration of the initial
Down delay.
1. External External power returns before backup power exhaustion.

Power, CEE continues the execution it started after the previous
Normal restart.
- 88 -
l Repeated saves, backup power exhausted before return of external power.
Assumptions
values.
l FORCERESTART has been left at its default value of OFF.
l RESAVEPERIOD is configured with a non-NaN value.
l Backup power is exhausted before external power returns.
State Comment

Power, lost.
Normal

Power, 0.
Counting
Down

Power,
Saving Data
The cycle of count down and save could repeat multiple

times.
5. No Power Backup power runs out. Outputs go to the unpowered

state or to their configured fail-safe states if the IO itself
remains powered.
1. External External power returns after backup power exhaustion.

Power, CEE executes its configured restart behaviors. Control
Normal strategies execute their configured initialization
behaviors upon start up.
Note that the above sequence is one that could occur if configuration options are left at their
default values. The values of SAVEDELAY1 and SAVEDELAY2 default to 10 minutes but they
typically need to be customized to each UOC deployment. Application engineers should check
default values and change them as needed.
- 89 -
l One save with restart, backup power exhausted before return of external power
Assumptions
values.
l FORCERESTART has been set to ON.
l RESAVEPERIOD is configured to NaN, indicating that no
repeated saves are done.
l Backup power is exhausted before external power returns.
State Comment

Power, lost.
Normal

Power, 0.
Counting
Down

Power,
Saving Data
4. Backup UOC shuts down and initiates its startup sequence.

Power, Outputs go to their configured fail-safe values. CEE
Starting Up executes its configured restart behaviors. Control
strategies execute their configured initialization behaviors
upon start up.
2. Backup The RESAVEPERIOD never counts down because it has

Power, been configured to indicate no repeated saves. The save
Counting operation is done only once after expiration of the initial
Down delay.
5. No Power Backup power runs out. Outputs go to the unpowered

state or to their configured fail-safe states if the IO itself
remains powered.
1. External External power returns after backup power exhaustion.

Power, CEE executes its configured restart behaviors. Control
Normal strategies execute their configured initialization behaviors
upon start up.
- 90 -
Power Connection Options
Summary of Options
There are several different arrangements of power flow from a Power Source to the UOC’s
Controller Power Supply or Power Supplies. The configuration of the RETENTIONTRIG block must
be consistent with the chosen deployment. Configuration is done through parameter
POWERCONNOPT. Possible values of POWERCONNOPT are listed below.
l Single (Single Power Source)
A single Power Source connects to the controller module’s power supply for either a non-
redundant controller or a pair of redundant controllers, irrespective of the number of
power supplies associated with each controller module.
l Dual2PerModule (Dual Power Source, Two Per Controller Module)
This applies only to non-redundant controller modules with 2 power supplies. Two power
sources are used, each connected to one of the controller module’s two supplies. Each of
the two power sources is sensed with its own External Power Good signal.
l Dual1PerModule (Dual Power Source, One Per Controller Module)

This applies only to redundant controllers. The Device Index value of each redundant
partner plays an important role in this configuration. Two power sources are used, where
each power source is connected to an individual controller in the redundant controller
pair. Each of the two Power Sources is sensed with its own External Power Good signal.
The physical association between power source and redundant controller module is as
follows:
o PWRGOOD1 represents the power source attached to the controller module A with
the odd device index.
o PWRGOOD2 represents the power source attached to the controller module B with
the even device index.
The types of connection arrangements used with each value of POWERCONNOPT are illustrated in
the following sections.
For vUOC, POWERCONNOPT is always set to either Single or Dual2PerModule because the vUOC
does not support application redundancy as required for the Dual1PerModule configuration.
Single Power Source
This power connection option can be used with a non-redundant UOC or with a redundant UOC
pair. The diagram below shows the non-redundant usage, applied to either the single power
supply case or the double power supply case.
- 91 -
Figure 5.3 POWERCONNOPT = Single, Simplex UOC
The diagram below shows how a single power source can be used with a redundant controller pair.
Rack options do not support two power supplies per controller in this case.
Figure 5.4 POWERCONNOPT = Single, Redundant UOC
The configuration of POWERCONNOPT changes the way the RETENTIONTRIG block responds to
loss of external power. Behavior for configuration Single is summarized below.
l Loss of external power when POWRECONNOPT = Single
o The RETENTIONTRIG block in the non-redundant or primary controller reads the
External Power Good Signal from the configured connection. Parameter PWRGOOD1
indicates current status of the signal.
o If PWRGOOD1 is negated, then the TIMETOSAVE1, previously initialized to
SAVEDELAY1 starts to count down. At any point in time, parameter TIMETOSAVE1
indicates the remaining time until data save.
o If the countdown expires, the block triggers platform services to do the retention save.
Control processing freezes for up to 40 seconds during the data save. Depending on
the configuration of FORCERESTART, it may also trigger the UOC to disable
synchronization if redundant and do a restart following the retention data save.
o If the PWRGOOD1 is asserted before TIMETOSAVE1 has reached zero, then no save is
done and TIMETOSAVE1 is reset to the configured delay value, SAVEDELAY1.
Dual Power Source, Two Per Controller Module
ATTENTION
RETENTIONTRIG block load with Dual2PerModule configuration results in load error when
the UOC rack does not have redundant power supplies.
With this power option, a separate power source is used for each power supply of a non-redundant
controller. Rack options do not support redundant controllers in this case. The connection
arrangement is illustrated by the diagram below.
- 92 -
Figure 5.5 POWERCONNOPT = Dual2PerModule
Behavior for configuration Dual2PerModule is summarized below.

l Loss of external power when POWRECONNOPT = Dual2PerModule
o The RETENTIONTRIG block in the non-redundant controller reads the External Power
Good Signals corresponding to each of the two Power Sources. Parameters
PWRGOOD1 and PWRGOOD2 indicate the status of each signal.
o The data save occurs only if both PWRGOOD1 and PWRGOOD2 are negated and both
TIMETOSAVE1 and TIMETOSAVE2 countdowns have expired. When a data save does
occur, control processing freezes for up to 40 seconds and a reset of the UOC may
also be triggered, depending on the configuration of FORCERESTART.
o If PWRGOOD1 is asserted before TIMETOSAVE1 has reached zero, then no save is
done and TIMETOSAVE1 is reset to the configured delay value, SAVEDELAY1. The
same applies to PWRGOOD2, TIMETOSAVE2, and SAVEDELAY2.
Dual Power Source, One Per Controller Module
ATTENTION
RETENTIONTRIG block load with Dual1PerModule configuration results in load error when
the UOC is configured as non-redundant.
With this power option, a separate power source is used for the power supply of each redundant
partner. The External Power Good signals, 1 or 2, are connected as prescribed by the Device Index
of each redundant partner.
Figure 5.6 POWERCONNOPT = Dual1PerModule
Behavior for configuration Dual1PerModule is summarized below.
- 93 -
l Loss of external power when POWRECONNOPT = Dual1PerModule

o The RETENTIONTRIG block in the primary controller reads the External Power Good
Signals corresponding to each of the two Power Sources. The status of each signal is
reflected in parameters PWRGOOD1 and PWRGOOD2.
o Parameter PWRGOOD1 is connected to capture the External Power Good signal of the
Power Source powering the UOC A at odd Device Index. Parameter PWRGOOD2 is
connected to capture the External Power Good signal of the Power Source powering
the UOC B at even Device Index.
o If PWRGOOD1 is negated, then the TIMETOSAVE1 starts counting down from its
initialization value of SAVEDELAY1.
a. If controller A with the odd device index is a synchronized primary, the primary
triggers switchover without retention save when TIMETOSAVE1 reaches 0. If
PWRGOOD1 is asserted before expiration of the count down, then
TIMETOSAVE1 is reset to SAVEDELAY1 without taking any action.
b. If controller A with the odd device index is an unsynchronized primary, the
primary triggers retention save followed by a restart (depending on the
configuration of FORCERESTART) when TIMETOSAVE1 reaches 0. If
c. If controller A with the odd device index is the secondary controller, the primary
controller B with the even device index immediately disables and inhibits
synchronization without waiting for TIMETOSAVE1 to reach 0. The redundant
controller remains unsynchronized until external power is recovered for the
secondary controller.
o If PWRGOOD2 is negated, then the TIMETOSAVE2 starts counting down from its
initialization value of SAVEDELAY2.
a. If controller B with the even device index is a synchronized primary, the
primary triggers switchover without retention save when TIMETOSAVE2
reaches 0. If PWRGOOD2 is asserted before expiration of the count down, then
b. If controller B with the even device index is an unsynchronized primary, the
primary triggers retention save followed by a restart (depending on the
configuration of FORCERESTART) when TIMETOSAVE2 reaches 0. If
c. If controller B with the even device index is the secondary controller, the
primary controller A with the odd device index immediately disables and inhibits
synchronization without waiting for TIMETOSAVE2 to reach 0. The redundant
controller remains unsynchronized until external power is recovered for the
secondary controller.
Controller Redundancy Behaviors
The following subsections summarize the controller redundancy behavior that occurs for the
various RETENTIONTRIG power source connection options.
Single Power Source
When a single power source is used for a redundant controller, loss of external power affects both
modules in the redundant controller pair.
- 94 -
Figure 5.7 Single, Redundant UOC
Redundancy behaviors for this configuration on loss of external power are as follows.
l When the RETENTIONTRIG is configured with FORCERESTART = OFF:
o PWRGOOD1 is negated and TIMETOSAVE1 countdown expires.
o The primary controller performs a retention save. Control processing freezes for up to
40 seconds during the data save.
o The controllers remain in their previous synchronization state during the retention
save. If RESAVEPERIOD is non-NaN, additional retention saves continue to occur at
the RESAVEPERIOD until backup power has been exhausted or external power
recovers.
l When the RETENTIONTRIG is configured with FORCERESTART = ON:

o The primary controller disables and inhibits synchronization.
o The primary controller restarts and performs retention restore. The controllers
attempt to synchronize (if possible).
Dual Power Source, Two Per Controller Module
There is no controller redundancy behavior for the RETENTIONTRIG block’s POWRECONNOPT =

Dual2PerModule configuration as this option applies only to non-redundant controllers.
Dual Power Source, One Per Controller Module
When a separate power source is used module associated with the power source experiencing the
loss of external power.
- 95 -
Figure 5.8 Dual Power Source, One Per Controller Module
Redundancy behaviors for this configuration on loss of external power are as follows.
l Loss of external power to a synchronized primary.
o Assume that Controller A with the odd device index is the primary controller as a
starting condition to this sequence.
o The primary controller A triggers a switchover with no retention save.
o The original primary controller A restarts in the secondary role.
o The new primary controller B (with even device index) inhibits synchronization until
external power is restored to the secondary controller.
l Loss of external power to an unsynchronized primary.

o When FORCERESTART = ON, the primary controller restarts and performs retention
restore. The controllers attempt to synchronize (if possible).
o When FORCERESTART = OFF, the controllers remain in their previous synchronization
state during the retention save. If RESAVEPERIOD is non-NaN, additional retention
saves continue to occur at the RESAVEPERIOD until backup power has been
exhausted or external power recovers.
l Loss of external power to the secondary.

o PWRGOOD2 is negated.
o The primary controller A immediately disables synchronization without waiting for the
TIMETOSAVE2 countdown to expire.
o The primary controller A inhibits synchronization until external power is restored to
the secondary controller.
- 96 -
5.10.3 Loading Retention Trigger Block
Retention Trigger Configuration Forms
Figure 5.9 RETENTIONTRIG Form, Parameter Description View
- 97 -
Figure 5.10 RETENTIONTRIG Form, Parameter Name View
Parameters exposed on the configuration form of the RETENTIONTRIG block are described below.
For further information, see Parameter Reference Dictionary.
l POWERCONNOPT / “Power Conn. Option”
This parameter configures the behavior of the UOC upon loss of external power so that it is
appropriate for the power connectivity that has been established by the UOC deployment.
Possible values are Single, Dual2PerModule, and Dual1PerModule. The configuration of this
parameter affects whether configuration ports in boxes “Power Source 1” and “Power Source
2” are enabled for editing. When POWERCONNOPT = Single, only the ports of box “Power
Source 1” are enabled for editing. For further information, see section Power Connection
Options.
l DEVICEIDX / “Device Index”
This read-only parameter shows the FTE device index of the UOC in a redundant pair that is
currently executing as primary. Its value affects the data save behavior of the UOC when
POWERCONNOPT = Dual1PerModule. If DEVICEIDX is odd, the configuration in box “Power
Source 1” determines UOC behavior. If DEVICEIDX is even, the configuration in box “Power
Source 2” determines UOC behavior. For further information, see section Power Connection
Options.
l SAVEDELAY1 / Retention Save Delay(m), SAVEDELAY2 / Retention Save Delay(m)
These parameters configure the delay until first data save that starts counting down after the
corresponding external power source has gone bad. Units are in minutes. The default value for
each of these parameters is 10 minutes.
- 98 -
l TIMETOSAVE1 / “Time to Save”, TIMETOSAVE2 / “Time to Save”

These read-only parameters indicate the time remaining until the first retention save after the
corresponding power source goes bad. When the external power is good, their values are
static. When external power is bad, they count down from their initialization value, which is
SAVEDELAY1 for TIMETOSAVE1 and SAVEDELAY2 for TIMETOSAVE2. How the UOC behaves
when TIMETOSSAVE1 or TIMETOSAVE2 reaches 0 depends upon the configuration of
POWERCONNOPT. For further information, see section Power Connection Options .
l INVPWRGOOD1 / “Invert Power Good 1”, INVPWRGOOD2 / “Invert Power Good 2”
These are configuration parameters which allow the application engineer to invert the sense of
signals PWRGOOD1 and PWRGOOD2 without using logic external to the RETENTIONTRIG
block. When INVPWRGOOD1 is ON, PWRGOOD1 = ON is interpreted to mean the associated
power source is bad. Similarly, when INVPWRGOOD2 is ON, PWRGOOD2 = ON is interpreted to
mean the associated power source is bad.
l PWRGOOD1 / “Power Good 1”, PWRGOOD2 / “Power Good 2”
These read-only parameters indicate the status of the corresponding external power source.
When INVPWRGOOD1 = OFF, PWRGOOD1 = ON indicates that the power source is good.
Similarly, When INVPWRGOOD2 = OFF, PWRGOOD2 = ON indicates that the power source is
good. PWRGOOD1 and PWRGOOD2 are exposed pins on the RETENTIONTRIG block when it is
placed in a CM chart. They receive the input connection that delivers the external power good
signals.
l FORCERESTART / “Force Restart”
This configuration parameter allows an application engineer to specify that the UOC should be
forced to restart after the initial delay count down has expired and data has been saved. The
default value is OFF. For further information, see section Behaviors During Power Loss.
l RESAVEPERIOD / “Re-Save Period”
This configuration parameter allows an application engineer to specify that the UOC should
save to retention NVS repeatedly after external power has been lost and after the initial save
has occurred. Every save operation entails a freeze in control processing up to 40 seconds
long. When resaves are done, the data set used at the next restart is the one whose save
operation completed uninterrupted and which has the most recent time stamp.
A RESAVEPERIOD value of NaN indicates that no repeated saves are to be performed. A non-
NaN value indicates the period of repeated saves in minutes. RESAVEPERIOD cannot be set to
a non-NaN value when FORCERESTART = ON. The default value of RESAVEPERIOD is 10
minutes. The minimum allowable value is 5 minutes. For further information, see section
Behaviors During Power Loss.
l TIMETORESAVE
This read-only parameter indicates the time remaining until the UOC re-saves data to
retention NVS. After the first save is complete and the UOC comes out of its control processing
suspension, TIMETORESAVE then counts down from its initialization value of RESAVEPERIOD.
When it reaches 0, data is saved again, with associated freeze of control processing, and then
the cycle repeats, with TIMETORESAVE initialized to its starting value of RESAVEPERIOD.
TIMETORESAVE remains static until after completion of the first save driven by TIMETOSAVE1
and TIMETOSAVE2. If RESAVEPERIOD is NaN, TIMETORESAVE is set to 0 and never changes.
l TESTDATASAVE
This read-only parameter indicate the status of the test data save input. TESTDATASAVE = ON
indicates that a test data save was requested. TESTDATASAVE can be configured as an exposed
pin on the RETENTIONTRIG block when it is placed in a CM chart. It receives the input
connection that delivers the test-data-save signal.
- 99 -
Retention TRIG Chart Faceplates
Project Side Default View
Figure 5.11 RETENTIONTRIG Block, Project Side Default View
All the configuration parameters are exposed on the faceplate by default. Parameters PWRGOOD1
and PWRGOOD2 are exposed by default as pins for connection. They are read only parameters and
may not be stored directly.
Figure 5.12 RETENTIONTRIG Block, Inverted PWRGOOD1
Notice how the block shows an inversion bubble on the PWROGOOD1 pin when INVPWRGOOD1 is
set ON. The same applies for the PWROGOOD2 pin when INVPWRGOOD2 is set ON.
Monitoring Side default view
Figure 5.13 RETENTIONTRIG Block, Monitoring Side Default View
Critical monitoring parameters are exposed on the faceplate. The user can add additional
configuration parameters to the monitor faceplate as per his interest.
Testing Retention Save Without Delay - TESTDATASAVE
The RETENTIONTRIG block supports a feature that makes it easier to test block configuration and
corresponding UOC retention save behaviors before a power loss occurs. This feature can be used
by an application engineer as part of validating the trigger strategy. Also, if so configured by an
application engineer, it can be used by an operator as a means to preview what a power loss event
would look like through system HMI.
- 100 -
l TESTDATASAVE
This is a read-only parameter which receives a signal by input connection from another block.
It would typically be used with connection to a FLAG block. When TESTDATASAVE transitions
from OFF to ON, it triggers a subset of the UOC’s data save behaviors without delay.
The FLAG block or other strategy used to assert TESTDATASAVE remains in the asserted state
until it is negated but only a single retention save is performed on the OFF to ON transition.
TESTDATASAVE must transition from ON to OFF to ON to trigger a new retention save.
Behaviors triggered by the OFF to ON transition of the TESTDATASAVE parameter are these:
l Save of data to retention NVS with accompanying freeze of control processing.
Note that when POWERCONNOPT = Dual1PerModule and the redundant pair is synchronized,
TESTDATASAVE assertion does not trigger switchover but instead triggers a retention save with
accompanying freeze of control processing.
l Report of the “Control Freeze for Retention Data Save” soft failure. The soft failure returns to
normal when the data save completes.
Behaviors NOT triggered by the TESTDATASAVE parameter are these:

l Inversion of the logical sense of the signal. TESTDATASAVE always has positive logic, even
when INVPWRGOOD1 or INVPWRGOOD2, which apply to PWRGOOD1 and PWRGOOD2
respectively, is set.
l Delay before data save. The data save trigged by TESTDATASAVE is always immediate. There is
no count down corresponding to SAVEDELAY1 or SAVEDELAY2.
l Report of the “Loss of External Power” soft failure. No power loss soft failure is reported when
TESTDATASAVE is triggered.
l Repeated data saves. The data save trigged by TESTDATASAVE never results in repeated data
saves, even when RESAVEPERIOD has a non-NaN value.
l Restart of the UOC after data save. UOC restart is never triggered even if parameter
FORCERESTART is ON.
Note that, although some similar behaviors are associated with parameter TESTDATASAVE and
parameters PWRGOOD1 and PWRGOOD2, the two sets of parameters are completely independent.
Behaviors associated with PWRGOOD1 and PWRGOOD2 occur as specified regardless of whether
TESTDATASAVE is left in an ON or OFF state.
The diagram below shows how connections might look if, TESTDATASAVE were enabled in the
trigger CM. A connection to PWRGOOD1 or both PWRGOOD1 and PWRGOOD2 always exists when
the RETENTIONTRIG block is used. When TESTDATASAVE is used, there is typically also a
connection from a FLAG block to the TESTDATASAVE input pin.
Figure 5.14 RETENTIONTRIG Block, TESTDATASAVE
- 101 -
Switchover During Count Down to Save
If there is a switchover after loss of external power and before retention save, or if there is a
switchover during the count down to a data save that is to be repeated, the following applies:
l The new primary resumes the countdown from where the old primary left off rather than
starting the count over again.
l In the case of the first save, this means that TIMETOSAVE1 and TIMETOSAVE2 resumes their
countdowns rather than starting over.
l In the case of a save to be repeated, this means that TIMETORESAVE resumes is count down
rather than starting the count over again.
Changing SAVEDELAY or RESAVEPERIOD during countdown to save or

resave
If the user changes the SAVEDELAY during countdown to save, the behavior will be as follows:
l If the new value is less than TIMETOSAVE, then SAVEDELAY will be set to the new value and
TIMETOSAVE will be adjusted to the new value. (The rationale is that the user might have
identified a need to initiate the operation sooner than it was configured early).
l If the new value is greater than TIMETOSAVE, then TIMETOSAVE will not be adjusted to the
new value, but SAVEDELAY will be set to the new value.
The same case applies to RESAVEPERIOD and TIMETORESAVE.
Single Block Instance Per Controller
Only one RETENTIONTRIG block instance is allowed to be loaded to a UOC controller. If the
application engineer configures more than one RETENIONTRIG instance, then load of the second
instance onward fails.
RETENTIONTRIG Loaded Without Power Good Connection
If the application engineer attempts to load a trigger CM in which the RETTENTIONTRIG block does
not have connections established to the necessary Power Good pins, then activation after load
fails. More specifically, this means the following:
l POWERCONNOPT = Single
If PWRGOOD1 is not connected, activation after the load fails.
l POWERCONNOPT = Dual2PerModule
Unless both PWRGOOD1 and PWRGOOD2 are connected, activation after the load fails.
l POWERCONNOPT = Dual1PerModule
Unless both PWRGOOD1 and PWRGOOD2 are connected, activation after the load fails.
CEESTATE Transitions During Count Down to Save
During normal operation, a UOC has its CEE in the Run state. However, if CEESTATE is changed
from Run to Idle after external power has been lost, then the countdown timing continues while
the CEE is in Idle. More specifically, this means the following:
- 102 -
l If a countdown starts before the UOC goes to Idle and the backup capacity of the Power Source
runs out during Idle, then the UOC shuts down with no data having been saved to retention
NVS.
l If a countdown starts before the UOC goes to Idle and then the UOC’s CEE is returned to Run
before the backup up capacity of the Power Source runs out, then the countdown continues.
Data save occurs either at expiration of the count down , or immediately upon transition to Run
if the countdown expired during Idle. Alternatively, if external power has been recovered by the
time of transition to Run then the countdown is reset and no data save occurs.
The above descriptions apply equally to the countdown to first data save associated with
TIMETOSAVE1 and TIMETOSAVE2, and to the countdown to resave associated with
TIMETORESAVE.
CM EXECSTATE Transitions During Count Down to Save
During normal operation, EXECSTATE of the trigger CM is Active. However, if its EXECSTATE is
changed from Active to Inactive after external power has been lost, then the countdown timing
continues while the CM is in Inactive. More specifically, this means the following.
l If a countdown starts before the CM goes Inactive and the backup capacity of the Power
Source runs out during Inactive, then the UOC shuts down with no data having been saved to
retention NVS.
l If a countdown starts before the CM goes Inactive and then the CM is returned to Active before
the backup up capacity of the Power Source runs out, then the countdown continues. Data
save occurs either at expiration of the count down , or immediately upon transition to Active if
the countdown expired during Inactive. Alternatively, if external power has been recovered by
the time of transition to Active then the countdown is reset and no data save occurs.
The above descriptions apply equally to the countdown to first data save associated with
TIMETOSAVE1 and TIMETOSAVE2, and to the countdown to resave associated with
TIMETORESAVE.
Reconfiguration of CE900 IOM with Power Good IOPOINT
To load a configuration change to an ControlEdge 900 IOM, the IOM must be inactivated during
which time any existing active IOPOINTs go to their inactive state. If the CE900 IOM to be
inactivated has an existing IOPOINT for the RETENTIONTRIG block’s PWRGOOD1 or PWRGOOD2,
the PWRGOOD1/PWRGOOD2 parameter goes OFF. This results in false detection of external
power loss when the associated INVPWRGOOD1/INVPWRGOOD2 is OFF as the normal good state
of PWRGOOD1/PWRGOOD2 set ON transitions to OFF on IOM reconfiguration. It is recommended
to inactivate the CM containing the RETENTIONTRIG block when reconfiguring IOMs that have
IOPOINTs for the PWRGOOD1/PWRGOOD2 inputs.
ATTENTION
It is recommended to inactivate the CM containing the RETENTIONTRIG block when
reconfiguring IOMs that have IOPOINTs for the PWRGOOD1/PWRGOOD2 inputs to prevent
false detection of external power loss on IOM inactivation.
5.11 Configure ControlNet for UOC

To configure ControlNet for an UOC system, adhere to the principles and best practices in the
following document:
l see section CONFIGURING CONTROLNET IOMs IN ETHERNET/IP™ in EthernetIP User Guide.
- 103 -
5.12 Configure ProfiNet for UOC

To configure ProfiNet for an UOC system, adhere to the principles and best practices in the
following document:
l PROFINET User Guide
5.13 Configuring DLR for UOC

Every DLR Ring must have a Ring Supervisor, and should have at-least one backup supervisor.
The ring must not be physically closed until at-least one supervisor is operational. If this is not
observed, the ring will storm and become unusable.
Set UOC as a Ring Supervisor; you must consider whether to make it higher or lower precedence
that the existing ones. Configure the Beacon Interval and Beacon Timeout to match. Note that
giving the UOC a higher precedence makes additional ring diagnostics available to Experion.
Steps to configure DLR for UOC
1. Launch Control Builder. Browse to UOC block. Double click to display the block information.
2. On the Main tab, under Downlink Network Configuration section, select Ring-DLR as the
Connection Type.
NOTE
UOC supports only Auto Negotiate mode. Ensure all the devices in the ring are set to
Auto Negotiate mode.
- 104 -
NOTE
A restart is required if there is a change in Connection Type after loading the
configuration into controller, either from HSR/PRP/non-redundant to DLR or vice
versa . To restart, on the Main tab, under the Command / State section, select Restart,
from the Module Command drop-down list.
3. Check the Enable Downlink Network Interface option.

4. Type the IP Address of the downlink network and the Subnet Mask of your network.
5. On the Downlink tab, retain the default values.
- 105 -
5.14 Convert a non-redundant UOC to a redundant

controller
This procedure can be performed on-process.
5.14.1 Prerequisites:
l Control Builder is running and project/monitor tree windows are open.
l A redundant partner UOC is properly installed at the even device index.
l The UOC hardware and firmware must be identical for both controllers in a redundant pair.
5.14.2 To convert a non-redundant UOC to a redundant controller

1. In the Project view, right click on the non-redundant UOC function block and choose Module
Properties. The non-redundant UOC function block configuration form is visible.
2. Check the Module is redundant check box. A default tag name of the secondary UOC function
block appears in the Secondary Tag Name field. Usually it is the primary controller block's
name with SEC appended to it.
3. Click the OK button. The secondary UOC function block icon is added to the project view with a
double ‘V’ symbol and the previous non-redundant UOC function block icon changes to a
redundant primary UOC function block icon with a delta symbol.
4. Select the primary UOC function block icon in Project view and perform a Load to the
controller. The delta symbol disappears from the primary UOC function block icon in the
Project view. The UOC function block icon in the Monitor view indicates the controller is now
redundant. A ‘Not Synchronized’ diagnostic alarm is generated.
5. Select the secondary UOC function block icon in Project view and perform a Load to the
controller. The double ‘V’ symbol disappears from the secondary UOC function block icon in
the Project view.
6. Verify the redundant controller pair achieves a synchronized state.
- 106 -
5.15 Convert a redundant UOC to a non-redundant

controller
This procedure can be performed on-process.
5.15.1 Prerequisites
l Control Builder is running and project/monitor tree windows are open.
l Make sure that the current primary UOC is physically configured with the odd Device Index. If
not, enable synchronization, wait for initial-sync to complete, and manually command
switchover.
5.15.2 To convert a redundant UOC to a non-redundant controller

1. In the Monitor view, right click on the secondary UOC function block icon and choose Module
Properties. The secondary UOC function block configuration form is visible.
2. Select the Redundancy tab, and click on the Disable Synchronization button. Allow command
to complete. Synchronization between primary and secondary controllers terminates and the
Auto Synchronization State parameter is set to Disabled. A ‘Not Synchronized’ diagnostic
alarm is generated by both the primary & secondary controllers.
3. Delete the secondary UOC function block from the Monitor view. The secondary UOC function
block icon is deleted from Monitor view.
4. Power-off and remove the secondary controller hardware. The secondary controller hardware
is removed from system.
5. In the Project view, right click on the primary UOC function block icon and choose Module
Properties. The primary UOC function block configuration form is visible.
6. Uncheck the Module is redundant check box. Click the OK button. The secondary UOC
function block icon is deleted from the project view, the primary UOC function block icon
changes from a redundant to a non-redundant icon, and the non-redundant UOC function
block icon shows a delta symbol.
7. Select the non-redundant UOC function block icon in Project view and perform a Load to the
controller. The delta symbol disappears from the non-redundant UOC function block icon in
the Project view. The UOC function block icon in the Monitor view indicates the controller is
now non-redundant. The previous ‘Not Synchronized’ diagnostic alarm returns to normal.
5.16 Licensing Model
5.16.1 I/O Analog/Digital point(s) license

Analog and Digital I/O point licenses apply to devices that follow the I/O Channel to IO Module
configuration paradigm and connect through ControlEdge 900 I/O or EIP I/O. This typically applies
to Transmitters and Valves. Channels or I/O reference blocks assigned to I/O Modules are counted
against the licensed pool of I/O points at time of load. Users must have a license to cover each
loaded channel. The number of licensed I/O points consumed maps directly to the number of
channels loaded. If a loaded channel is deleted, by deleting the parent Control Module, then the
corresponding I/O point count is subtracted from the total used.
- 107 -
NOTE
I/O Analog/Digital point(s) License and Composite Device Point(s) License are applicable
only for UOC system.
NOTE
Process Point license is not applicable for UOC and won’t be counted on any entities.
NOTE
Unassigned channels are not counted against I/O Analog/Digital point(s) license.
5.16.2 Composite Device Point(s) License

Composite Device point licenses apply to complex devices such as PLCs, Motor Starters and Drive
controllers. They are counted against the licensed pool of points at time of load. Each composite
point counts against a single complex device. The number of Composite Device points consumed
maps directly to the number of complex devices loaded.
NOTE
Users migrating from R510 needs to perform Load Server Points operation from monitoring
side on Control Builder. This operation needs to be performed after migration.
NOTE
The maximum number of I/O connections per device should not exceed 250 connections.
5.16.3 License Matrix

The below given table provides some of the examples on the type of license applicable for each
device:
Device Controller connection License Type

Transmitter(including ControlEdge 900 I/O I/O Analog Point
HART)
Transmitter(including 3rd Party Ethernet/IP I/O Analog Point

HART) I/O
Motor/Drive Ethernet/IP Composite Device

Point
Valve Solenoid ControlEdge 900 I/O I/O Discrete Point
PLC Ethernet/IP(including Composite Device
- 108 -
Device Controller connection License Type

UDT) Point
PLC ModbusTCP(including Composite Device

PCDI) Point
Valve Limits ControlEdge 900 I/O I/O Discrete Point
Valve Limits 3rd Party Ethernet/IP I/O Discrete Point

I/O
- 109 -
CHAPTER
6 LOAD CONFIGURATION
This section includes information about tasks associated with loading UOC configuration using
Control Builder.
6.1 About load operations

The Experion system provides the ability to build control strategies offline, without being
connected to the actual field components. The process of transferring the control strategy to the
"live" working components in the field is called the load operation.
The load operation functionally copies configuration data from the control strategy that is stored
in the Engineering Repository Database (ERDB) to the assigned field component in the system
architecture. It indirectly assures that the planned system matches the actual one. The
communication addresses and physical location assignments specified for components through
Control Builder configuration must match the actual addresses and locations of components in
the system.
6.1.1 Loaded versus project database versions

The master control strategy, stored in the Engineering Repository Database (ERDB), is configured
and edited through the Project tree. After the contents of the control strategy are loaded from
Project to the applicable components, a loaded version of the Project or master database is
created. The loaded version of the databases is viewable through the Monitoring tree and
supports modification of a subset of parameters. Parameters which are modifiable are those
which may need to be changed as part of on-line operations.
An important difference between the Project and Monitoring views of UOC data is that any change
to the Project view is stored in the off-line repository whereas any change to the Monitoring view
is stored directly to the controller.
The following commands are included in the Control Builder Controller menu to synchronize data
in the loaded database with the data in the Project/master database.
l Upload/Update to Project: This command applies only to the block which has been selected, It
gives options to cause data within the controller and / or server to be uploaded to the Monitor
database and then, if desired, to be updated from the Monitor database to the Project
database.
l Upload/Update to Project with Contents: This command provides the same upload and update
options as the above command but applies to the selected block and all of its child blocks.
6.1.2 Load initiation and load dialog box

You can initiate a load operation for selected components from either the Project tree or
Monitoring tree using one of the following commands in the Control Builder Controller menu.
l Load
l Load with Contents
- 110 -
Chapter 6 - Load Configuration
Both commands invoke the Load Dialog box. The Load command applies only to the selected block
whereas the “Load with Contents” command applies to the selected block and all of its child blocks.
The following figure shows a sample Load Dialog box invoked for a load with contents operation for
a CPM. It provides a brief description of the dialog box features for quick reference. The
appearance of the dialog box will vary depending on the current load circumstances such as
whether this is an initial load or a re-load operation.
CAUTION
The load operation is inherently an offline function. The Load Dialog box provides the ability
to automatically inactivate a component during a load and then return the component to its
active state. Do not use this automatic inactivate/activate function if your process cannot
tolerate a temporary suspension of control processing. If such is the case, first make sure
the process units to be affected are put into a state where they can tolerate the temporary
suspension of control.
Figure 6.1 Sample Load Operation
6.1.3 Load action with Compare Parameters function

The capability of the load action is expanded when the Use Compare Parameters function is
enabled through the System Preferences dialog box. For more information, see Using Compare
Parameters section in the Control Building User's Guide.
6.1.4 Load options for server history and server displays

configuration
You can enable or disable the loading of history, trend, or group configuration data for a block to
Server through the System Preferences dialog box.
- 111 -
For more information, see Setting system preferences section in the Control Building User's Guide.
6.2 Initial load order guidelines

Make the initial load of control strategy components from the Project tab in the following order to
minimize the possibility of error messages. Use the Load rather than the Load with Contents
command.
Order Component Post Load Default State

1 A - UOC Platform Block OK
B – CEE Block IDLE
2 900 I/O Rack and EPM Blocks IDLE
3 900 I/O UI/O Module Blocks IDLE
4 EtherNet/IP Adaptor Blocks INACTIVE
5 EtherNet/IP I/O Module and INACTIVE

Device Blocks
6 Control Applications INACTIVE
* Please refer to the Control Building Guide for more information about
loading these components.
NOTE
Loading the UOC platform block from project without contents will
load the associated CEE block. All blocks must be configured before
loading.
6.2.1 Component deletion considerations

l Control Strategy edits must be performed from the Project tab only.
l Deleting blocks from the Project tab eliminates them from the Project version of the database
only. Only blocks that are not loaded can be deleted. Delete loaded blocks from the Monitoring
tab first before deleting them from the Project tab.
l Deleting blocks from the Monitoring tab eliminates them from the controller, Server and loaded
version (Monitoring) of the database. The blocks remain in the Project version of the database.
ATTENTION
Changes to parameters in the controller can be made from the Monitoring tab. See the
Changing Parameters while Monitoring section in the Control Building Guide.
- 112 -
6.3 Load components from Project
6.3.1 Loading UOC

Use the following general procedure to load a UOC. The load procedure is similar for all controller
components.
Note that selecting a UOC block for loading also selects the associated CEE block.
All illustrations used in the procedure are for example purposes only.
Prerequisites
l Control Builder is running
l This procedure assumes that the UOC is installed and capable of communicating with the
Server.
To load a UOC block and its associated blocks

1. Click the desired UOC block icon in the Project tab. The selected UOC block is highlighted.
2. Click Tools- > Load. Or, click the load button in the toolbar.
You can also right-click on the UOC block icon to select Load. The Load Dialog box is
displayed.
Ensure that for a redundant controller both primary and secondary blocks are loaded.
- 113 -
NOTE
Selecting the UOC block for load, automatically selects the associated CEE block.
3. Ensure the Load check box is checked and click the OK button.
4. This initiates the load to the UOC and calls up the load progress dialog.
TIP
If errors are detected, they will be displayed in the Load progress dialog and you will
- 114 -
be asked if you want to continue the load or cancel, depending on the nature of the
error. It is recommended that you cancel the load and identify and fix the errors.
Each message contains a brief description and includes an error code in
parentheses. Note the last number in the string. In some cases, more information
about the code number may be included in the Control Builder Notifications
Reference document.
5. After the load completes and the dialog box closes, click the Monitoring tab.
6. UOC icon now appears in the Monitoring tab. The default state for a loaded UOC is IDLE or
color code blue.
7. Repeat this procedure for other control components as required.
6.3.2 Loading CEE

Use the following general procedure to load a CEE block to a UOC. The load procedure is similar for
all control environment related components.
All illustrations used in the procedure are for example purposes only.
Prerequisites
l Control Builder is running.
l Make sure the UOC block is loaded.
l This procedure assumes that the UOC is installed and capable of communicating with the
Server.
To load a CEE block
- 115 -
1. Click desired CEE block icon in Project tab.

2. This action selects and highlights the component.
3. Click Tools- > Load. Or, click the load button in the toolbar.
4. This calls up the Load Dialog box
5. Ensure the Load check box is checked and click OK.
6. This initiates the load to the CEE block and calls up the load progress dialog.
TIP
If errors are detected, they will be displayed in the Load progress dialog and you will
be asked if you want to continue the load or cancel, depending on the nature of the
error. It is recommended that you cancel the load and identify and fix the errors.
The following illustration shows how error messages are typically displayed. Each
message includes an error code in parentheses. Note the last number in the string.
In some cases, more information about the code number may be included in the
Control Builder Notifications Reference document.
- 116 -
7. Once the load completes and the dialog box closes, click the Monitoring tab.
8. CEE icon now appears in Monitoring tab. The default state for a loaded CEE is inactive/idle or
color code blue.
9. Activate CEE to set the CEE to its RUN state. When this happens, the UOC Platform Block
proceeds to its CEERUN state.
10. CEE icon turns green when active.
11. Repeat this procedure for other control components as required.
6.3.3 Loading I/OMs and CMs

Follow the initial load order guidelines in “Initial load order guidelines” to load these additional
control strategy components.
Before you load 900 EPM Blocks, 900 I/O Module Blocks or EtherNet/IP I/O Module and Device
Blocks, make sure that the physical devices are communicating with the UOC, otherwise errors will
result. To load I/O Module and Device blocks, select the desired block and perform a load
command. Alternatively, you can select the parent CEE block and command “Load With Contents”
to load all configured child blocks. To load only I/O Module and Device child blocks, uncheck any
CMs or SCMs in the load list.
It is typical to load CMs and SCMs after the UOC Platform, CEE and I/OM blocks have been loaded.
CMs and SCMs can be loaded individually. Alternatively, you can select the parent CEE block and
command “Load With Contents” to load all configured child blocks. To load only CMs and SCMs,
uncheck any I/O Module or Device blocks in the load list.
See Control Building User’s Guide_EPDOC-XX19-en-511A.pdf for more details about these
procedures.
6.4 Load With Contents command

When you select “Load with Contents” from the Tools menu, the Load Dialog box shows the
selected component plus any objects, (I/OMs, CMs, etc.) that are contained by the selected
component. For example, when a CEE block is selected for loading, the Load Dialog will list all the
objects assigned to (or contained by) that CEE in the dialog window. You can then select (or
deselect) the objects that you want to load.
6.5 Reloading components from project

Reload of component configuration may be necessary when you make changes to the component
or function block configuration, or after you replace a failed field device, I/O module or controller. It
is typical to load CMs and SCMs after the UOC Platform, CEE and I/OM blocks have been loaded.
CMs and SCMs can be loaded individually. Alternatively, you can select the parent CEE block and
command “Load With Contents” to load all configured child blocks. To load only CMs and SCMs,
uncheck any I/O Module or Device blocks in the load list. It is a good idea to invoke the following
commands through the Controller menu after a reload operation.
- 117 -
l Upload / Update to Project
Restrictions and conditions for reloading operations

Re-loading parameter data to certain function blocks may incur some restrictions or conditions
with other related blocks. The following table lists conditions to consider when re-loading
previously loaded blocks.
Block to be Re-
Conditions or Restrictions
Loaded
UOC with l The following blocks are re-loaded unless they are de-
Contents selected in the Load dialog.
l UOC Block
l CEE Block with Contents
CEE l The UOC Block must be present and previously loaded.
l The state of the CEE must be IDLE.
l When Load-with-Contents is selected, all child blocks

of the CEE are loaded as well.
CM l The UOC block and CEE block must be previously

loaded.
l CM reload fails if any of the following errors are

encountered:
l The UOC block is not present and loaded.
l The CEE block is not present and loaded.
l The CM is ACTIVE.
6.6 Upload to the Monitoring database

Application engineers may change data directly in the UOC from the Control Builder Monitoring
view or from operational displays. In many cases, it may be important for this controller resident
data to be uploaded so that it becomes part of the data retained within the engineering repository.
To accomplish this, the following Control Builder commands may be invoked from the Monitoring
View.
l Upload/Update to Project
l Upload/Update to Project with Contents
Each command allows the user to select whether he only wants controller and server data to be
uploaded to the Monitoring side of the ERDB or also updated to Project side of the ERDB as well.
Refer to the Using Upload Command section in the Control Building Guide for procedures to
upload component data.
- 118 -
CHAPTER
7 CONTROLEDGE 900 I/O DEVICE CONNECTIVITY
This document covers characteristics of the CEE blocks which represent 900 I/O modules and
interface adaptors. It does not describe the characteristics of I/O Points, I/O Reference blocks or
other objects used directly within CEE control strategies to interface to 900 I/O. For information
on I/O Points and I/O References, see the Control Builder Components Theory guide.
7.1 CE900 IO in UOC
UOC supports the following IO modules:

l UIO module
l UAI module.
l DI 24VDC module.
l DO 24VDC module.
l DI High Voltage AC.
l DO High Voltage AC.
l AI16-100MS (High Level Analog Input, 16 Channels).
l AO04 (Analog Output, 4 Channels).
l AO08 (Analog Output, 8 Channels).
l DI16-DRYCT (DI - 16ch Dry Contact Type).
l DI16-VACDC (DI - 120/240 VAC, 125 VDC (16ch-Iso)).
l DO08-RELAY (Digital Output Relays, 8 Channels).
The UOC controller interfaces with the IO in two ways:

l When configured as non-redundant, the controller can communicate directly via the
backplane to the IO modules plugged directly into the controller rack.
l The controller can also communicate with IO modules plugged into IO Racks with an EPM
module.
The physical EPM and IO modules used by the UOC are the same as those used with the Control
Edge PLC product.
- 119 -
Chapter 7 - ControlEdge 900 I/O Device Connectivity
7.1.1 Model numbers
NOTE
For AI16-100MS module, model Number should be 900A16-0103 and the firmware version
should be 1.39 for the 100 ms scan rate support.
NOTE
Below table represents the model numbers mismatch between the IO module hardware and
the IO module reports.
Model Model Number report by the IO

Module Description
Number Module
Analog Output, 0 to 20mA, (4 900B01- 900B01-0101
channel) 0301
Digital Input, Contact type, (16 900G01- 900G01-0102

channel) 0202
Digital Output, Relays (8 900H01- 900H01-0102

channel) 0202
7.1.2 ControlEdge 900 IO Version Compatibility Matrix

The following table lists the ControlEdge PLC IO version compatibility matrix.
- 120 -
UOC EPM UIO DO32- DO0

DI32- DI16-
(900CP1) (900SP1) (900U01) UAI 24VDC
24VD
VAC
8-
(900A C VAC
(900G (900G
R5 R5 R1 R1 R1 R1 01) (900H (900H
32) 03)
05 10 40 50 40 50 32) 03
Syste
m
relea
se
R50 X X X
5
R51 X X X
0
R51 X X X
0
R51 X X X X X X X X
0
7.2 UOC Configuration

General information on configuration of the UOC platform block is presented in the UOC Platform
Block section. For purposes of configuring the down-link network for 900 I/O, note the following.
The Device Index establishes the IP address of the UOC on the up-link FTE network. It is unrelated
to I/O communication except that the FTE and down-link networks should always have different
subnet ranges.
The down-link IP Address and Subnet Mask establish the UOC's IP address on the down-link
network.
The UOC must always be enabled as a DHCP server to communicate with 900 I/O through EPMs in
remote racks.
The Connection Type is configured as "Non-redundant" when connecting to a downlink-
EtherNet/IP network through ETAPs. It is configured as a 'Ring-HSR" when connecting to a down-
link network with 900 I/O only.
- 121 -
- 122 -
7.3 Controller Rack

A block—representing the I/O rack containing the UOC— which is named CONTR_RACK and can
contain I/O modules (local I/O).
7.3.1 Rules
l Assignment is restricted to non-redundant UOCs. In other words, a CONTR_RACK can only be
assigned to a non-redundant controller.
l Enabling redundancy is prohibited while a CONTR_RACK is assigned to the UOC.
l There can be only one CONTR _RACK per UOC.
l The CONTR _RACK’s rack number is always zero and cannot be changed.
l The CONTR _RACK cannot contain more I/O modules than the rack type indicates.
l The rack type cannot be changed to a lesser value while the CONTR _RACK contains more I/O
modules than the current rack type.
l The rack type can be changed to a greater value at any time without restriction but must be
reloaded to apply the change.
7.3.2 Creating Controller Rack
7.3.3 Method 1: Using the CE900_I/O library

In the Library Containment panel, expand the CE900_I/O group and then drag and drop the I/O_
RACK item on to a UOC’s CEE. This will automatically create an I/O group and place the CONTR _
RACK inside it.
Library > CE900_I/O > CONTR_RACK
Figure 7.1 Controller Rack in the Library
- 123 -
Figure 7.2 Assigned Controller Rack
Method 2: Using the File menu
The CONTR_RACK can also be created from the File menu.
Figure 7.3 Controller Rack from File Menu
After it is configured, the CONTR_RACK can be found in the project view under “Unassigned”. To
assign the CONTR_RACK, drag the block into the UOC’s CEE. If an I/O group doesn’t yet exist
under the CEE, it will be created automatically.
- 124 -
7.3.4 Controller Rack Configuration
Figure 7.4 Controller Rack Configuration
As stated in the rules section, the rack number is always static for the Controller Rack. The rack
type must be set to match the physical hardware.
NOTE
It is the user’s responsibility to ensure that the configured rack type and the physical rack
type match.
7.3.5 I/OM Status Summary

Lists the configured I/O modules currently assigned and loaded to the rack and their status.
- 125 -
Figure 7.5 CONTR_RACK I/OM Status Summary
7.4 I/O Rack (EPM)

This block is similar to the Controller Rack (CONTR_RACK) in its functioning but has a few different
behaviors. An I/O Rack represents the physical rack with four to twelve slots and the I/O Rack
(EPM) module. The I/O Rack module provides communication between the UOC and I/O modules
in the rack using the downlink network.
See the Installation documentation for information regarding the setting of the rotary switches on
the EPM module.
7.4.1 Rules
l There can be up to twelve I/O RACKs per UOC.
l An I/O RACK must have a unique rack number when assigned to a UOC.
l Attempting to load with a default rack number of “blank” will be rejected.
l The I/O RACK cannot contain more I/O modules than the rack type indicates.
l The rack type cannot be changed to a lesser value while the I/O RACK contains more I/O
modules than the current rack type.
l The rack type can be changed to a greater value at any time without restriction but must be
reloaded to apply the change.
l An I/O Rack moved to unassigned will retain its rack number and child modules.
- 126 -
7.4.2 Creating I/O Rack
Method 1: Using the CE900_I/O library
In the Library Containment panel, expand the CE900_I/O group, and drag and drop the I/O_RACK
item on to a UOC’s CEE.
Figure 7.6 I/O Rack from Library
7.4.3 Hardware Information

Displays firmware versions, hardware versions. This form is static.
7.4.4 Soft Failures and Alarms

Soft failures/alarms reported to the Experion server are contained in the I/O report. This report
lists module-wide resource issues and conditions monitored by the EPM. Such soft
failures/warnings are not expected to be configured by the user.
- 127 -
Possible
Error Cause User Recommended Action(s)
(s)
I/O Rack soft EPM is l Check EPM is installed in the rack.
failures/alarms not l Check EPM is powered on.
present
No Response l Check rack number is configured on the EPM.
EPM is offline It must match the physical rack number.
l Ensure that the communication pathway
between UOC and EPM is properly connected
and not broken. See the installation guide for
proper connectivity.
7.5 I/O Module

Input/Output module that can be inserted into a CONTR_RACK or I/O_RACK slot.
7.5.1 Rules
l The associated rack number is set automatically to the parent rack number it is assigned to and
is automatically changed on reassignment.
l The slot number must be unique within that parent rack.
l The slot number cannot be greater than the rack type of the current or targeted parent rack.
l If the I/O module is unassigned, the slot number is retained.
l When an I/O module is moved to unassigned, its rack number will be set to blank.
7.5.2 I/O Module Creation
Method 1: Using the CE900_I/O library
From the “Library – Containment” panel, under the CE900_I/O group, drag and drop the desired
module on to the target rack.
- 128 -
Figure 7.7 I/O from Library
Method 2: Using the File Menu
File > I/O Modules > CE900_I/O ><select desired option>
- 129 -
Figure 7.8 I/O from File Menu
7.6 Channel
7.6.1 Rules and Behaviors

l Any change to the channel configuration requires a reload of the I/O module from the project
side. Reloading from monitoring will only reload the previously loaded configuration.
l Changing the channel type to any other channel type will automatically reset the channel
configuration to the default settings.
7.6.2 Channel Type Configuration
Method 1: From the Channel Configuration tab
1. Open the module properties by either double clicking the module in the “Project –
Assignment” panel or by right-clicking the module and selecting “Module Properties...”.
2. Select the tab labeled “Channel Configuration”.
3. Select the channel type from the combo box in the “Channel Point Type” column.
- 130 -
Figure 7.9 UI/O properties channel configuration
- 131 -
Method 2: From the Project Tree
1. Expand an I/O module in the “Project – Assignment” panel.

2. Right-click a channel and select a channel type from the “Channel Type Setting” context
menu. “Channel Type Setting” can also be accessed through the Edit menu.
Figure 7.10 Project UI/O Channel Type Setting
This method provides the added benefit of setting Channel Type for multiple channels at
once. To select multiple channels, hold the Shift key while selecting the desired channels.
Release the shift key and right-click any of the selected channels to access the “Channel
- 132 -
Type Setting” context menu.
Figure 7.11 Project UI/O type setting of multiple channels
7.6.3 Channel Configuration and Status
AO Channel Configuration
See the Parameter Reference Dictionary for more information on parameters/configurable fields.
Figure 7.12 AO Configuration
AO Parameter Configuration Rules
If Fault Option is set to UserFaultValue, you must specify the Fault Value.
AO Channel Monitoring
- 133 -
Figure 7.13 AO Status Data
AI Channel Configuration
Figure 7.14 AI Configuration
This figure does not show all the configuration parameters for the AI channel.
AI Channel Monitoring
Figure 7.15 AI Status Data
DO Channel Configuration
Figure 7.16 DO Configuration
- 134 -
DO Channel Monitoring
Figure 7.17 DO Status Data
DI Channel Configuration
Figure 7.18 DI Configuration
DI Channel Monitoring
Figure 7.19 DI Status Data
7.6.4 Soft Failures and Alarms

The I/O module reports the following module and channel soft failures/alarms to the Engineering
Station. They can be seen on Control Builder I/O Module Configuration forms under the Soft
Failure tabs: “Box Soft Failures” and “Channel Soft Failures”.
l Box Soft Failures: These are conditions that are monitored by the I/O modules and report
issues related to module-wide resource issues. These types of soft Failures/warnings are not
expected to be configured by the user.
l Channel Soft Failures: These are conditions that are monitored by the module on behalf of
each individual channel configured on the module. Some of these conditions are user
configurable (i.e. Open Wire Detect) but others are not (i.e. Short Circuit Detect).
- 135 -
I/O Module (Box) soft failures/alarms
Error Possible Cause(s) User Recommended Action(s)
No I/O module not l Check that I/O module is installed in the

Response present rack.
I/O Communication l Check that I/O module is powered on.
module is path between the l Check that rack number and slot number
offline controller and the are configured on the I/O module. They
I/O module is must match the physical I/O Rack number
broken. and slot where the I/O module is installed.
l In case of I/O racks
l Check that EPM is
communicating and is online
l Ensure that communication
pathway between UOC and EPM is
properly connected and not
broken. See installation guide for
proper connectivity.
Module The configured Check the installed I/O module on the I/O rack and the
module type does not configuration. Then replace the I/O module if the type of
Type
match the type the installed module is not expected, or change the I/O
Mismatch physically installed in module type in the configuration if the configured type is
the slot. not correct.
I/O
module
type
mismatch
Factory Factory data is either Replace the I/O module hardware

not present in the
Data error
module or corrupted.
I/O
module
contains
bad
calibration
data.
Firmware Module detected a Replace the I/O module hardware
Image error possible firmware
image inconsistency.
Watchdog Internal module Restart the I/O module by powering it off and powering it
Reset Watchdog Timer back ON. Replace I/O module if error persists.
timeout
External External 24 V power l Check 24 V connections.

Power Error supply to the module
is either disconnected l Check 24 V external power supply and
or is faulty. ensure it is powered on and connected.
- 136 -
l Check 24 V power supply does not have an

under/ over voltage.
Internal Internal power supply l Check power supply and UI/O modules
Power Error on the module or I/O
are correctly inserted in the rack and the
rack power supply is
faulty. mounting screws are tight.
l Replace I/O rack power supply if the
power supply error is still seen on this
module or other modules.
l Replace UI/O hardware if error persists.
Module Over- I/O module board l Check for sufficient ventilation between
Temperature temperature exceeds
I/O racks.
the allowable
threshold. l Check if current drawn from UI/O module
to DO and AO channels does not exceed
the specification limit of 4.2 A.
l If the error persists, replace module
hardware.
Module Not Factory calibration Replace I/O module hardware. Call GTAC.
Calibrated data is inconsistent or
not present.
- 137 -
I/O Channel soft failures/ alarms
Open Wire The field device (Analog/ Digital Input l Check field connections and
Detected or Digital Output) connection to the ensure device is properly
I/O module is open. connected to the I/O Module.
l Make sure necessary signal
conditioning resistors for OWD
are used and connected as
specified.
l Fix any connection issues found,
or disable OWD.
Short Circuit The field device (Digital Output) Check field cable and device for a
Detected connection to the I/O module is short circuit. Investigate and fix the
shorted. connection.
I/O Hardware Internal Hardware fault Replace I/O module and call GTAC
Failure
Failure in OP Analog/ Digital output channel is l Check field connections from I/O
circuit/field unable to drive desired output current module terminals to the device
wiring detected to the connected device. and fix if necessary.
l If field connection is correct and
the problem persists, work with
GTAC to replace the module.
Burnout The field device(Thermocouple/ RTD/ Check field connections from I/O
Detected milli volt source) connect to I/O module terminals to the device and fix
module is open. it.
Thermocouple Thermocouple measurement value is Check for the Thermocouple values

Warning going to be out of range. with in the range.
Thermocouple Thermocouple measurement value is Set the Thermocouple values with in

Failing out of range. the range specified
- 138 -
7.7 I/O Module Configuration
Figure 7.20 UIO module properties
7.7.1 Maintenance
Displays firmware versions, hardware revision and hardware model number. This form is static.
- 139 -
Figure 7.21 Module Maintenance Information
7.7.2 Module Configuration/Monitoring Tabs

Every module configuration form consists of set of tabs as follows:
l Main Tab: It is used to enter module specific configuration attributes and location within the
Controller/IO hardware.
l Channel Configuration Tab: It is used to set the desired channel type for each channel within
the module.
l Channel Configuration Tab, and Channel Status Data Tab (one per allowed channel type): It is
used to configure and monitor applicable channel attributes and data.
l Maintenance Tab: It is used to view the module Firmware and Hardware detailed information.
l Box Soft Failure Tab, and Channel Soft Failure Tab: It is used to view details on any active soft
failures on the module or channels.
l Server History Tab, Server Displays Tab, Control Confirmation TAB, QVCS Tab, and
Identification Tab: It is used for configuring Server History information, Detail Displays, Version
Control, etc.
For common Configuration/Monitoring tabs applicable to all modules, see Common CE900 Module
Configuration/Monitoring Tab.
For tabs of specific module type, refer below:
- 140 -
l CE900 UAI Module Configuration/Monitoring Tabs

l CE900 DI32-24VDC Module Configuration/Monitoring Tabs
l CE900 DO32-24VDC Module Configuration/Monitoring Tabs
l CE900 DI16-VAC Module Configuration/Monitoring Tabs
l CE900 DO08-VAC Module Configuration/Monitoring Tabs
l CE900 DI16-DRYCT Module Configuration/Monitoring Tabs
l CE900 DO08-RELAY Module Configuration/Monitoring Tabs
l CE900 AO04 Module Configuration/Monitoring Tabs
l CE900 AI16-100MS Module Configuration/Monitoring Tabs
l CE900 AO08 Module Configuration/Monitoring Tabs
l CE900 UIO DI Channel NAMUR Configuration/Monitoring Tabs
l CE900 DI16-VACDC Module Configuration/Monitoring Tabs
7.7.3 Common CE900 Module Configuration/Monitoring Tabs
Maintenance Tab
Figure 7.22 Maintenance Tab
- 141 -
Box Soft Failure Tab
Figure 7.23 Box Soft Failure Tab
Channel Soft Failure Tab
Figure 7.24 Channel Soft Failure Tab
- 142 -
Server History Tab
Figure 7.25 Server History Tab
Server Displays Tab
Figure 7.26 Server Displays Tab
- 143 -
Control Confirmation Tab
Figure 7.27 Control Confirmation Tab
QVCS Tab
Figure 7.28 QVCS Tab
- 144 -
Identification Tab
Figure 7.29 Identification Tab
7.7.4 CE900 UIO DI Channel NAMUR Configuration/Monitoring

Tabs
DI Configuration Tab
Figure 7.30 DI Configuration Tab
- 145 -
DI Status Data Tab
Figure 7.31 DI Status Data Tab
7.7.5 CE900 UAI Module Configuration/Monitoring Tabs
Main Tab
Figure 7.32 Main Tab
- 146 -
Channel Configuration Tab
Figure 7.33 Channel Configuration Tab
AI Configuration Tab
- 147 -
Figure 7.34 AI Configuration Tab
- 148 -
AI Status Data Tab
Figure 7.35 AI Status Data Tab
7.7.6 CE900 DI32-24VDC Module Configuration/Monitoring Tabs
Main Tab
- 149 -
- 150 -
DI Status Data Tab
7.7.7 CE900 DO32-24VDC Module Configuration/Monitoring Tabs
Main Tab
- 151 -
DO Status Data Tab
Figure 7.42 DO Status Data Tab
- 152 -
7.7.8 CE900 DI16-VAC Module Configuration/Monitoring Tabs
Main Tab
- 153 -
DI Status Data Tab
- 154 -
7.7.9 CE900 DO08-VAC Module Configuration/Monitoring Tabs
Main Tab
- 155 -
DO Status Data Tab
7.7.10 CE900 DI16-DRYCT Module Configuration/Monitoring Tabs
Main Tab
- 156 -
- 157 -
DI Status Data Tab
7.7.11 CE900 DO08-RELAY Module Configuration/Monitoring Tabs
Main Tab
- 158 -
DO Status Data Tab
- 159 -
7.7.12 CE900 AO04 Module Configuration/Monitoring Tabs
Main Tab
- 160 -
AO Configuration Tab
Figure 7.59 AO Configuration Tab
AO Status Data Tab
Figure 7.60 AO Status Data Tab
- 161 -
7.7.13 CE900 AI16-100MS Module Configuration/Monitoring Tabs
Main Tab
- 162 -
AI Configuration Tab
Figure 7.63 AI Configuration Tab
- 163 -
AI Status Data Tab
Figure 7.64 AI Status Data Tab
7.7.14 CE900 AO08 Module Configuration/Monitoring Tabs
Main Tab
- 164 -
AO Configuration Tab
Figure 7.67 AO Configuration Tab
- 165 -
AO Status Data Tab
Figure 7.68 AO Status Data Tab
7.7.15 CE900 DI16-VACDC Module Configuration/Monitoring Tabs
Main Tab
- 166 -
- 167 -
DI Status Data Tab
7.7.16 UIO Namur Support

UIO module supports 24 V NAMUR type input signals with current (Amps) levels in accordance with
IEC60947-5-6:1999 specifications on the DI channel.
When Namur is enabled, the DI channel can be configured to detect and report Open Wire and
Short Circuit conditions.
The following states are supported:
l Open Wire
l ON
l OFF
l Short Circuit
Interfacing the Namur sensor to the UIO DI channel requires:

l Third party barriers
l Termination Board
l Custom cables
UIO DI Channel Namur Configuration
To enable Numur support on the UIO DI channel, user should select the NAMUR Enable
parameter under the “DI configuration tab”.
- 168 -
Figure 7.73 DI Configuration tab
- 169 -
CHAPTER
8 ETHERNET/IP DEVICE CONNECTIVITY
UOC controller supports EtherNet/IP device connectivity. The EtherNet/IP interface facilitates a
comprehensive integration between UOC controllers and the EtherNet/IP compatible nodes and
I/O devices. This integration also supports accessing User-Defined Tags (UDT) from the
ControlLogix control system, and referencing the tags in Experion strategies (for read and write
operations).
To enable easy integration between UOC and the ControlLogix control system, Control Builder
provides options to create data blocks that match the various ControlLogix UDT structures.
Control Builder also provides options to create new I/O block types for EtherNet/IP compatible I/O
devices.
NOTE
During a switchover, UOC holds the last value for a maximum of 3 seconds. During this
period, it reconnects to the EtherNet/IP I/O devices. If for reasons, such as third-party
issues or network issues, the reconnection from the new primary UOC controller is not
completed within 3 seconds, an alarm will be raised.
For more information see EtherNet IP User's Guide_EPDOC-X399-en-511A.pdf.
8.1 EtherNet/IP Device Configuration in UOC

The UOC controller supports communication with EtherNet/IP compliant third-party devices, such
as I/Os, drives, and relays. To facilitate the integration of UOC with the EtherNet/IP compliant
devices, you must configure equivalent device blocks by using Control Builder. Each configured
device block represents an equivalent physical EtherNet/IP compliant-device which is installed on
the EtherNet/IP network.
Configuring an EtherNet/IP device includes the following tasks:
1. Configuring an EtherNet/IP device block in Control Builder.
For more information, see the following topics:
l Configuring the EtherNet/IP GenAdapter block.
l “Configuring ArmorPoint I/O module blocks” in Control Building User’s Guide.
Note that the Configuring ArmorPoint I/O module blocks section describes a specific
example. You can use a similar procedure to configure modular I/O blocks of other types.
l “Configuring PowerFlex drive blocks” in Control Building User’s Guide.
Note that Configuring PowerFlex drive blocks describes a specific example. You can use a
similar procedure to configure drives of other types.
Note that Configuring E3 relay blocks describes a specific example. You can use a similar
- 170 -
Chapter 8 - EtherNet/IP Device Connectivity
procedure to configure blocks of other types.

Note that Configuring E3 relay blocks describes a specific example. You can use a similar
procedure to configure blocks of other types.
2. Assign EtherNet/IP devices to the CEE UOC block.
8.1.1 Slot 0 Diagnostic Information

To retrieve diagnostic information from slot 0 of an adaptor device which supports Class 1
EtherNet/IP connections, Application Engineers can attach a generic device to slot 0.
- 171 -
8.1.2 Slot 0 Configuration

1. Add the Chassis Size for the adapter under the generic adapter configuration form.
2. Add device / I/OM under Generic Adapter or 1738-AENT adapter.
- 172 -
3. Provide the slot number of device or I/OM as 0 to allot the generic device to slot 0.
8.1.3 Configuring the EtherNet/IP GenAdapter Block

To enable communication with I/O Modules connected through a Generic Adaptor device, you
must configure the GenAdapter EtherNet/IP adapter block. One EtherNet/IP GenAdapter supports
multiple Ethernet I/O modules. A configured EtherNet/IP GenAdapter block represents a physical
EtherNet/IP adapter which is installed on the EtherNet/IP network.
To configure the EtherNet/IP GenAdapter block
- 173 -
1. Click File > New > Ethernet IP Devices > GenAdapter-EtherNet/IP Generic Adapter.
2. The GenAdapter configuration form appears.
For a non-consolidated connection, the Target > Originator RPI and Originator >Target
RPI are disabled and these options are enabled in I/OM block under the GenAdapter.
3. On the Main tab, specify the details for the adapter block which include the following:
l Tag Name — For example, GENADAPTER_200
l IP address of the device — For example, 11.1.11.91. For more information about
configuring the IP address of the adapter, see “Configuring the IP address of an
EtherNet/IP device”.
l Chassis Size
ATTENTION
An attempt to communicate with the I/O module may fail if the chassis size entered
does not match the physical configuration.
Therefore, ensure that the chassis size matches the number of the physically
installed I/O modules and the adapter (chassis size = number I/O modules + one for
the adapter).
For example, if the number of I/O modules is 10, the chassis size must be 11.
4. If you want to consolidate connections for a group of I/O modules which are assigned to the
adapter, under Network Configuration, select the Consolidate Connections check box.
5. For more information about Consolidating connections, see “Consolidate connections”.
- 174 -
6. If you select the Consolidate Connections option, type the following details for the Requested
Packet Interval (RPI). RPI specifies the rate at which data is updated during a connection. The
RPI specified is applicable for all the I/O modules associated to the adapter.
l Target > Originator RPI (ms) — For example, 100
l Originator >Target RPI (ms) — For example, 100
7. The Name is specified when the adaptor block is used in a C300 to configuration. When used
in a UOC configuration, it is left blank.
8. Complete the required details on all the other tabs and click OK. For more information about
the parameters on the Main tab and the other tabs, see Control Builder Parameter Reference.
Results
The GenAdapter is configured and appears in the Unassigned category of the Project Tree.
Next steps
After creating the adapter block, you must assign it to the CEE. For more information, see
Assigning EtherNet/IP GenAdapter to the CEE UOC block.
Consolidate connections
The GenAdapter provides the Consolidate Connections feature which is also referred to as Rack
Connections or Gateway Connections.
This feature consolidates connections for a set of I/O Modules and releases a single connection
instead of creating one connection per I/O Module. The data for all I/O Modules participating in a
Consolidate Connection is communicated on a single connection which reduces the number of
packets on the network, and hence optimizes the usage of network bandwidth.
You can enable this feature using the GenAdapter block configuration form.
- 175 -
To enable the Assembly connection feature, select the Consolidate Connections check box on the
adapter block configuration form. If you select this option, also provide the Requested Packet
Interval (RPI) details. RPI is used to indicate the rate at which the data is updated when connected.
The RPI details will be applicable for all the I/O modules which are assigned to the adapter.
Ensure that the RPI value is a multiple of the base cycle of the controller. If that is not the case, a
warning message informing you that the value is clamped appears during loading.
Assembly Configuration for Consolidate Connection
An Assembly Configuration consists of Connection Parameters and the Slot Assembly Map.
Connection Parameters consists of the Assembly Instance Number and the Size (Bytes) of Config,
Input and Output Assemblies. The Slot Assembly Map consists of data byte, bit offsets and bit sizes
of Input and Output Assembly data produced and consumed by the EtherNet/IP Adapter. Assembly
Configuration values for a specific family of EtherNet/IP adapter will be provided in the User
Manual of the Adapter. Project Engineers must update the values carefully after reading the User
Manual.
To configure the assembly configuration for the consolidated connection, follow these steps:
1. After you have configured the consolidated connection to the EtherNet/IP GenAdapter, select
the Assembly Configurations tab.
Figure 8.1 Assembly Configuration tab
NOTE
The EtherNet/IP GenAdapter supports only zero configuration size for consolidate
connection.
2. Enter information in the Assembly Configuration details as listed below.
- 176 -
Field Description
Connection Parameters
Assembly Description By default, the Config, Input and

Output are displayed.
Assembly Instance Number Enter the instance number

provided by the vendor manual or
from EDS (electronic data sheet)
file.
Assembly Instance Size (Bytes) Enter the instance size provided

by the vendor manual or from
EDS (electronic data sheet) file.
Run Idle Enter the run idle details provided

by the vendor.
Slot Assembly Map

This section allows you to send data to or receive data from the field
devices. This section describes mapping data to various I/O modules.
For more information on mapping, see the vendor’s manual or the EDS
file.
Byte offset (input) Enter the byte offset for input of

I/O module.
Bit offset (input) Enter the bit offset for input of I/O
module.
Bit size (input) Enter the bit size for input of I/O
module.
Byte offset output Enter the byte offset for output of

I/O module.
Bit offset output Enter the bit offset for output of

I/O module.
Slot Status Configuration for Consolidate Connection

The Slot Status Configuration values of a GenAdapter block represents the per slot status header
produced by EtherNet/IP Adapter to represent the device / I/OM removal and reinsertion from
and to chassis, when consolidate connection is active. This configurable feature is based on the
user’s selection. The Project Engineer enters values for configuration parameters and clicks OK.
The System presents the Ethernet Adapter instance in the Project side under Un-assigned node.
To configure the slot status configuration for the consolidated connection:
- 177 -
1. After configuring the consolidated connection to the EtherNet/IP GenAdapter, click the Slot
Status Configurations tab.
Figure 8.2 Slot Status Configuration tab
2. Enter information in the Slot Status configuration details as listed below. Every parameter on
this table helps you program how to determine communication failure with a module in the
chassis when participating in an assembly/gateway or adaptor connection.
- 178 -
Fields Description
Enable Slot Select this to enable the slot status processing
Status
Processing
Data type Select the data type of the slot status as defined by
the vendor manual
Slot Status Assembly Map

Enables you to map, on a per slot basis, where in the input assembly to
obtain the communication fail status information from.
Byte offset Enter the byte offset of input for I/O module
Bit offset Enter the bit offset of input for I/O module
Good value Enter the good value for the specific slot.
Current value Is the value per the defined data type picked from the
specified Byte and Bit offsets.
It is then compared with the good value and
depending upon the comparison (equal or unequal),
the I/OM in a slot is informed whether or not it faces
a diagnostic – which in this case is communication
failure.
8.1.4 Configuring the IP address of an EtherNet/IP device

A default IP address is provided by the vendor, for every EtherNet/IP device. You can access the
Network Configuration page of the device to configure the IP address based on the network
settings at your location.
Prerequisites
l The default IP address of the device
l Web browser
To configure the I/P address of a device

1. From a web browser, access the Network Configuration page using the default IP address.
2. On the Network Configuration page, specify the required IP address and all the required
details relevant to the network settings at your location.
Results
The IP address of the device is configured.
8.1.5 Configuring I/O module blocks

A configured I/O module block represents a physical I/O module which is installed on the
EtherNet/IP network. Use the following procedure to configure all the supported I/O module
blocks.
- 179 -
Prerequisites
l Install the GenAdapter I/O device.
To configure an I/O module block

1. Click File > New > Ethernet IP Devices > <Library Name > <Device>.
2. Device represents the I/O device that you want to configure.
ATTENTION
You can also create an instance of the device by using a template from the library.
3. On the Main tab, specify the required details which include the following:
l Tag name — For example, 1738E_IB16M_1234
l Item Name — For example, Armorpoint_IB16M_1234
l IP address of the device — Type the required IP address of the device. For example,
10.10.10.1.
4. For more information about configuring the IP address of the adapter, see Configuring the IP
address of an EtherNet/IP device.
5. Specify the Requested Packet Interval (RPI) values. RPI specifies the rate at which data is
updated when connected.
ATTENTION
If the RPI value does not adhere to the following, then the value will be rounded
down to the nearest base cycle and this warning will be displayed while loading:
l Ensure that the RPI value is a multiple of the base cycle of the controller and in
multiples of 50.
l Ensure that you enter a value in the following range for ArmorBlock I/O
modules — 50 ms and 750 ms.
l Target > Originator RPI (ms) — For example, 100 ms

l Originator >Target RPI (ms) — For example, 100 ms
ATTENTION
l For ArmorBlock 1732E-IF4M12, the Originator >Target RPI value must be 500
ms or 750 ms.
l For ArmorBlock 1732E-IT4IM1, the Originator >Target RPI value must be 500
ms or 750 ms.
6. If the EtherNet/IP I/O communication is through EIM, select the EIM Name through which
the EtherNet/IP I/O communication will happen.
7. Complete the required details on all the other tabs and click OK. For more information about
the other tabs, see the “Channel Configuration tab” and “Alarms tab” sections in the Control
Building User’s Guide.
- 180 -
ATTENTION
In the Data/Status tab of the configuration form, the row number of the grid starts
from 0. The row number does not indicate the channel number. It indicates that
the row number of the grid starts from 0.
In ArmorBlock output modules, when there is a channel fault, an alarm or event is
not generated by default.
However, you can configure to generate an alarm by using a flag block.
For more information about the parameters on all the tabs, see Control Builder Parameter
Reference.
Results
The I/O block is configured and appears in the Unassigned category of the Project Tree.
Next steps
After configuring the I/O block, assign it to the CEE UOC block.
8.1.6 Assigning EtherNet/IP devices to the CEE

After you configure an EtherNet/IP device block, assign it to the CEE.
However, devices which require an EtherNet/IP adapter must be assigned to the Ethernet adapter
block which is under the EtherNet/IP DEVICES category of the CEE UOC block.
To assign the EtherNet/IP devices to the CEE block:
Drag the configured EtherNet/IP devices from the Unassigned category to the CEE block, under
I/O of CEE block.
ATTENTION
You can optionally use SmartBuilder to bulk assign the EtherNet/IP devices and I/O
modules to the CEE. For more information, see Bulk Configuration Tool Help.
The module category EtherNet/IP DEVICES appears under the CEEUOC block.
To assign the I/O devices to the GenAdapter block
Drag the configured I/O module block from the Unassigned category to the EtherNet/IP adapter
block, under EtherNet/IP DEVICES.
ATTENTION
You can optionally use SmartBuilder to bulk assign the EtherNet/IP devices and I/O
modules to the CEE. For more information, see Bulk Configuration Tool Help.
The I/O module block appears under the EtherNet/IP adapter.
8.1.7 Configuring I/O Ref blocks in CMs to access data from

EtherNet/IP devices
See Control Builder Components Theory_EPDOC-XX16-en-511A.pdf and Control Builder Parameter
Reference Guides_EPDOC-XX18-en-511A.pdf for more information.
- 181 -
8.2 Configuration Parameters for arrayed custom

parameters
For arrayed parameters, the array size will be defined based on the custom parameter’s size.
Parameter name: PARAMNAME [Index].HIGHRANGE

Specific to Block: Generic Device
Description: Scaling parameter for setting high range
Data Type: FLOAT64
Range: -1.7E+308 to +1.7E+308
# Enum Size in Min. Raw Max. Raw

text bytes Value value
Default: NaN
Config Load:
Access Lock: Engineer
Residence: CEE
Related
Parameters:
Remarks:
- 182 -
Parameter name: PARAMNAME [Index].LOWRANGE

Description:
Data Type: FLOAT64
Range: -1.7E+308 to +1.7E+308
Generic Device

Default: NaN
Config Load:
Residence: CEE
Related
Parameters:
Remarks:
- 183 -
Parameter name: PARAMNAME [Index].SCALEFACTOR

Description:
Data Type: FLOAT32
Range: -1.7E+308 to +1.7E+308

Default: 1
Config Load:
Residence: CEE
Related
Parameters:
Remarks:
- 184 -
Parameter name: PARAMNAME [Index].BIAS

Description:
Data Type: FLOAT32
Range: -1.7E+308 to +1.7E+308

Default: 0
Config Load:
Residence: CEE
Related
Parameters:
Remarks:
- 185 -
Parameter name: PARAMNAME [Index].FLOATVALUE

Description:
Data Type: FLOAT64
Range: -1.7E+308 to +1.7E+308

Default: 0
Config Load:
Residence: CEE
Related
Parameters:
Remarks:
Where ‘PARAMNAME’ is the Custom parameter name and ‘Index’ is the index of arrayed custom
parameter.
NOTE
Scaling of numeric values (including floating point) alone is supported.
8.3 Configuration Parameters for scalar (non-arrayed)

custom parameters
l HIGHRANGE
l LOWRANGE
l SCALEFACTOR
l BIAS
l FLOATVALUE
For more information, see Control Builder Parameter Reference Guides_EPDOC-XX18-en-511A.pdf.
- 186 -
8.4 Scaling support for Generic Device

Scaling support covers custom parameters as well as PV and OP parameters on generic devices.
Formulae used by the controller to perform scaling:

1. FLOATVALUE for Custom Input parameters is calculated as:
2. For the Output direction, use this formula to calculate RAWVALUE from the FLOATVALUE
(which is typically written through the strategy):
The formula is the same as with Input scaling solved for 'Raw value'.
The process value that is received from field is converted to digital form by the A/D converter.
LOWRANGE and HIGHRANGE values define the normal operating range of the RAW value.
RAW value in the output direction is the final output value sent to the device in the output
assembly. This is the linearly scaled value (with some scale factor multiplied and bias added) of the
OP (which is in percentage) within the LOWRANGE and HIGHRANGE operating range of the RAW
value.
8.4.1 Scaling Configuration Tab

The following image illustrates the Scaling Configuration tab.
l Parameter name: It is the custom parameter defined for input, output and configuration
assemblies.
l Type: It defines the parameter data type.
- 187 -
l Low Range: It defines the lowest limit for the parameter value.
l High Range: It defines the highest limit for the parameter value.
l Scale Factor: It defines the ratio of the value for scaling
l Bias: It defines the calibrated engineering units.
8.4.2 Configuration
Configure custom parameters using the PDE (Parameter Definition Editor) tool.
By default, scaling parameters are not available in the configuration form. To display them in the
configuration form, manually add the scaling parameters in the form layout of the EtherNet/IP
generic device PDE.
Form layout for Custom Output Scaling Parameters
1. Create a generic device.

2. Add and configure custom parameters.
3. Configure scaling parameters for custom output parameters under the Data Command tab, in
the Form Layout page.
4. Save and close the PDE.
8.4.3 To view and modify the scaling parameters in EtherNet/IP

generic device instances
1. Create an instance of the generic device.
2. Open the configuration form of the generic device instance from Control Builder’s Project Tree
view.
3. Select the Data/Command tab to view scaling parameters.
- 188 -
NOTE
You can modify scaling parameters from the configuration form.
8.5 UOC and ControlLogix integration

The UOC controller can integrate with the ControlLogix control system. ControlLogix processors
store data in the form of tags. This integration supports the following operations:
l Reading the User-Defined Tags (UDTs) from the ControlLogix Programmable logic controller
(PLC).
l Referencing the UDTs in Experion strategies.
l Writing the updated UDTs to the ControlLogix PLC.
The UOC can read and write both multi-parameter (aggregate) UDTs and single-parameter
(scalar) UDTs.
Control Builder provides configuration options which facilitate the integration of UOC and the
ControlLogix control system. The following table lists high-level tasks for configuring the UOC and
ControlLogix integration.
- 189 -
Task Description
Step 1: “Configuring the To establish a connection between UOC controllers
ControlLogix Gateway and ControlLogix PLCs, you must configure the
block” in the Control required connection settings.
Building User’s Guide.
Step 2: “Creating To read UDTs from the ControlLogix PLC and to

Control Logix write the UDTs to the ControlLogix PLC, you must
Aggregate UDT Type” in define blocks that match the tag structures in the
the Control Building corresponding ControlLogix PLCs.
User’s Guide.
You can create the required block by configuring a
UDT type in Control Builder.
Step 3: “Defining the Create an instance of the ControlLogix UDT in a

ControlLogix tag Control Module. To ensure that the required UDTs
access” in the Control which you want to access for performing a read or
Building User’s Guide. write operation are mapped to the appropriate
ControlLogix PLC, you must specify the following:
l The gateway details which represent the
ControlLogix PLC.
l The tag name of the UDT (on the ControlLogix

PLC) that you want to access.
Step 4: “Using After creating an instance of the UDT block, you can
Aggregate or Scalar Tag connect it to other required blocks to perform a
Instance for Read and read or write operation. Load the Control Module
Write Operations” in the configuration.
Control Building User’s
Guide.
- 190 -
CHAPTER
9 UOC NODE REDUNDANCY OPERATION
The goal of controller redundancy is to improve the availability of the controller to perform its
assigned control functions. This is done by providing a pair of controllers (primary and backup) so
a component failure in one controller switches the handling of the assigned control functions to
the other controller. In this redundant arrangement, the active or primary controller is considered
to have a redundant partner or backup controller which is available to take over control functions
of the primary controller in the event of a switchover. This is considered a dual-redundant system
which is characterized by the following two main redundancy states.
l Primary - Refers to the active controller executing the assigned control mission.
l Backup or Secondary - Refers to the controller in some state of readiness to assume the
responsibilities of the Primary.
UOC supports two forms of redundancy. One is node redundancy, when two controllers are
deployed as redundant partners. The other is network redundancy, wherein the controller
participates in redundant network communications on its uplink, downlink or both. This section
focuses on node redundancy.
9.1 Redundancy configuration restrictions
9.1.1 FTE Device Index

For more information on how to set the FTE device index see the FTE Device Index section.
Redundancy communication between a pair of redundant UOCs is not possible if their device
indices are not set to a consecutive odd/even pair.
9.2 Partner controller compatibility

Controller redundancy is possible only when the primary controller has a compatible secondary
partner. After communication is established with the partner controller, the primary controller
periodically sends a partner compatibility message that contains information necessary to
perform the compatibility check, and the secondary responds with its own compatibility message.
Each module compares local information against the supplied remote values to determine
whether the partner module is compatible or incompatible. If all the compatibility criteria are
satisfied, then the partner module is compatible. Otherwise, the partner module is incompatible
and synchronization is not permitted. The following criteria are compared:
l Factory data, such as, vendor ID, product type, and product code must be identical to ensure
the same platform hardware.
l The firmware must be identical on the primary and backup controllers.
l The partner module must have a properly configured device index. If this module has an odd
- 191 -
Chapter 9 - UOC Node Redundancy Operation
device index N, the partner module must have the even device index (N+1). Otherwise, if this
module has an even device index M, the partner module has to have the odd device index (M-
1).
9.2.1 Redundancy compatibility result - RDNCMPT

RDNCMPT indicates if redundant partner modules are compatible. The RDNCMPT parameter for
the UOC platform indicates the following compatibility results.
- 192 -
RDNCMPT State Description

––– Not Module configured as non-redundant.
applicable
NOPARTNER Not Initial/default state when no partner is

applicable responding to the partner compatibility
query.
Note that redundancy communication
between a pair of redundant controllers is
not possible if their device indices are not
set to a consecutive odd/even pair.
QUERYINPROG Not Transient state while partner compatibility

applicable check is being performed.
DIRECTCMPT Compatible Indicates firmware versions are identical.
INDIRECTCMPT Compatible Compatible indication in the case where

firmware versions are different and the
secondary has a newer firmware version
than the primary. Redundant controller
synchronization is inhibited unless either
{1} the Controller Migration Wizard is
invoked to coordinate the migration to this
firmware version or {2} the Firmware
Manager is used to manually correct the
redundant controllers to have identical
firmware versions.
VENDORID Incompatible The partner's Honeywell ID does not

match.
PRODUCTTYPE Incompatible The partner's Product Type does not

match.
PRODUCTCODE Incompatible The partner's Product Code does not

match.
PLATFORM Incompatible Hardware types are consistent while

firmware types are not.
OPMSEQUENCE Incompatible Incompatible indication in the case where

firmware versions are different and the
secondary has an older firmware version
than the primary. Migration from the
primary controller with newer firmware to
the secondary controller with older
firmware is explicitly not allowed as the
- 193 -
RDNCMPT State Description

older firmware may not support the newer
firmware functionality.
Firmware Manager must be used to
manually correct the redundant controllers
to have identical firmware versions to allow
synchronization to proceed.
PARTNBOOTFMW Incompatible The partner module is executing from boot

firmware (e.g. partner is in the Alive, Ready,
or Fail state). To be compatible, both
partners must be executing from
application firmware.
9.3 UOC 1-slot I/O rack

UOC can have two single slot racks deployed separately in different areas. The distance between
the two racks can be 100 meters if you use a Cat6 shielded cable. Each 1-slot I/O rack hosts a
power supply, a controller module, and a redundancy module (Redundancy +Module (RM) is being
introduced as part of the dual rack redundancy solution). Another 1-slot I/O rack with the same
modules is deployed at a different location. The connection between the two racks is established
using a specific Ethernet LAN cable. Ethernet ports are present in both the Redundancy Modules
(RM). For more information, see Hardware Planning and Installation Guide_HWDOC-en-H.pdf
NOTE
Currently 1-slot I/O rack option is not available for PLC controllers.
NOTE
You can also use two Fiber Optics modules between the Redundancy Modules to extend the
distance to 500m (Multi-mode Transmission Distance) or 10Km (Single-mode Transmission
Distance). As an option you can use 3rd party COTS Fiber Optic modules.
9.4 Redundancy synchronization
9.4.1 Synchronization states - RDNSYNCSTATE

The RDNSYNCSTATE parameter indicates the controller’s synchronization state. Given a
redundant controller pair, synchronization is the act of transferring configuration and control data
from the primary controller to the secondary so that the secondary has the same information as
the primary when it is needed to transition into the primary role. Synchronization is only possible
for a compatible redundant controller pair. When an incompatible redundant partner is detected,
the controller transitions from the No Partner state to the Incompatible state; refer to the
- 194 -
RDNCMPT parameter for the reason the partner is not compatible. When a compatible partner is
found, the controller transitions from the No Partner state to the Partner Visible state. Initial-sync
is the act of performing first time transfer of synchronization data; during this time the controllers
are in the Sync in Progress state. The redundant controller pair enters the Synchronization
Maintenance state upon initial-sync completion. While in the Synchronization Maintenance state,
the secondary is a viable replacement for the primary controller, and only that configuration data
that is changed and the control data that changes as a consequence of primary controller
execution is synchronized to the secondary controller.
Figure 9.1 Redundancy Synchronization States of a Controller
9.4.2 Enable Synchronization - ENBLSYNCCMD

This command triggers an unsynchronized redundant module pair to attempt initial-
synchronization. Additionally, the module's Auto-Synchronization state transitions to ENABLED (if
previously set to DISABLED).
9.4.3 Disable Synchronization - DSBLSYNCCMD

This command triggers a synchronizing/synchronized/standby redundant module pair to abort
synchronization. Also, sets the module's Auto-Synchronization state to DISABLED.
9.4.4 Auto-Synchronization State - RDNAUTOSYNC

Read-only parameter that reflects the current state of Auto-Synchronization as follows:
l Enabled upon receipt of the Enable Synchronization command. When enabled, a Primary
Module automatically attempts to synchronize the Secondary, upon receipt of any “Auto
synchronization triggers” (in addition to the Enable Synchronization command).
l Disabled either upon receipt of the Disable Synchronization command or detection of a
persistent synchronization fault condition. When disabled, you must explicitly issue the Enable
Synchronization command to reset any persistent fault condition and (re)attempt initial-sync.
Auto synchronization triggers

When the primary controller has its Auto Synchronization state parameter set to enabled, the
redundant controller pair automatically commences initial-sync without user intervention. More
specifically, any action that results in the primary detecting a direct compatible partner module
triggers an initial sync attempt. such as:
- 195 -
l Reconnection of the redundancy cable

l Secondary module recovery from dual-FTE-cable disconnect
l Secondary module power up
l Secondary module reboot into Backup state following firmware update.
l Secondary module reboot into Backup state following recovery from the Fail state.
Auto synchronization retries

Once the Auto Sync state is enabled, loss of synchronization is automatically followed by an
automatic attempt to re-synchronize the redundant controller pair. However, after a maximum of
3 initial-sync failures, the Auto Sync state is disabled with an inhibit sync reason of Initial Sync Fail.
9.4.5 Inhibit Sync Reason - RDNINHIBITSYNC

Whenever the controller is not in the synchronized/standby states and initial-sync is not in
progress, the RDNINHIBITSYNC parameter is set to the inhibit sync reason. Reasons for inhibiting
initial-sync, at a minimum, include the following:
- 196 -
Inhibit Sync
Description
Reason
Startup In Initial sync is not allowed until after the controller has
Progress completed system startup. This is a transient inhibit sync
reason that is usually not seen.
Auto Sync Initial sync is inhibited while the Auto Sync state is set to
State disabled. This is a persistent inhibit sync reason that is
canceled via the Enable Sync command.
Dropping Initial-sync cannot commence until the previous abort sync

Sync operation has been completed. This is a transient inhibit sync
reason that is usually not seen.
Initial Sync There is a guaranteed 30 second delay between initial-sync

Delay attempts. Specifically, for 20 seconds after a compatible
partner is identified, initial-sync is inhibited with this transient
reason.
Initial Sync After 3 failed attempts to perform initial-sync, the Auto Sync
Fail state is automatically set to disabled and the inhibit sync
reason is set to this persistent value. Refer to the redundancy
history for the reasons why initial-sync failed, correct any
anomalies, and issue the Enable Sync command to attempt
initial-sync again.
Redundancy Initial-sync is not allowed when explicitly configured as non-

Configuration redundant. This persistent inhibit sync reason can only be
State canceled by reconfiguring the non-redundant controller
platform function block as redundant.
Platform FB Initial-sync is not allowed until after the controller platform

Load State function block has been loaded to the controller.
CEE Load Or Synchronization cannot be maintained during the database

Delete initialization that occurs upon UOC CEE function block load
or delete. This is a transient inhibit sync reason that is usually
not seen.
Partner Initial-sync is not applicable without a redundant partner.

Absent
Partner Not Initial-sync is not applicable with an incompatible redundant

Compatible partner.
Partner The redundant partner has requested initial-sync to be

Request inhibited. See the partner's RDNINHIBITSYNC parameter for
the actual reason.
- 197 -
Inhibit Sync
Description
Reason
FTE Cable The secondary inhibits sync due to dual-FTE-cable disconnect.
Status This persistent inhibit sync reason can only be canceled by
restoring FTE communications with the secondary.
Downlink The secondary inhibits sync due to downlink cable disconnect.

Cable Status This persistent inhibit sync reason can only be canceled by
restoring downlink communications with the secondary.
OPM Normal UOC initial-sync is not allowed when the application

Required firmware versions for the primary and secondary controllers
are different. The Controller Migration Wizard must be used to
perform On-Process Migration.
Unsupported Initial-sync is inhibited for controller hardware version that

Hardware does not support controller redundancy.
Version
9.4.6 Initial Sync Progress - RDNSYNCPROG

The RDNSYNCPROG parameter indicates the percentage of initial-sync completion. This is set to 0
when initial sync is not in progress, and it is set to 100 when initial-sync is complete.
9.4.7 Maximum Initial Synchronization Time - RDNISTIMEMAX

The RDNISTIMEMAX parameter indicates the maximum initial synchronization time in seconds.
This is a high-water mark for all the previous successfully completed initial-sync attempts. This
value is reset upon issuing the controller platform function block's Stats Reset command.
9.4.8 Last Synchronization Time - SYNCTIMEBEG

The SYNCTIMEBEG parameter indicates the wall-clock time at which the redundant controller pair
last transitioned into the Synchronization Maintenance state. This time updates on every
transition to the Synchronization Maintenance state.
9.4.9 Last Lost of Sync Time - SYNCTIMEEND

The SYNCTIMEEND parameter indicates the wall-clock time at which the redundant controller pair
last transitioned out of the Synchronization Maintenance state. This is updated on every transition
out of the Synchronization Maintenance state.
9.4.10 Redundancy Traffic Rate

The RDNTXRATE and RDNTXMAX parameters indicate the average and maximum redundancy
transmitted traffic in kbits per second. The RDNRXRATE and RDNRXMAX parameters indicate the
average and maximum redundancy received traffic in kbits per second. These values are reset
upon issuing the controller platform function block's Stats Reset command.
- 198 -
9.4.11 Conditions that result in loss of sync

Starting with a synchronized or standby redundant controller pair, the following conditions result
in loss of synchronization.
Disable Sync command (from primary or secondary controller platform function block).
l Loss of redundancy cable (private path) between Primary and Secondary controllers.
l Both links on FTE network are physically disconnected from secondary controller.
l Both links on downlink network are physically disconnected from secondary controller.
NOTE
Only the first link is active when downlink is configured in non-redundant mode.
l Shutdown command issued from the secondary controller platform function block.
l Secondary controller loss of input power.
l Secondary controller failure.
l Secondary controller firmware update.
l Removing the powered secondary controller from its IOTA/Rack.
l Time taken for initial synchronization (from Sync Start to Completion) exceeds 600 seconds.
l Secondary controller loss of communication with a configured 900 I/O rack when the primary
controller is successfully communicating with the same rack.
9.4.12 Conditions that do not result in loss of sync

Starting with a synchronized or standby redundant controller pair, the following conditions do not
result in loss of synchronization.
l Primary and/or Secondary controller loss of single FTE link.
l Primary controller and secondary controller loss of communication with the same 900 I/O rack.
9.5 Switchover and secondary readiness

A switchover is a process where a Synchronized or Standby Secondary controller assumes the
primary state. A switchover can be triggered immediately upon the detection of a fault in the
primary or upon the receipt of an operator command. Depending on the switchover trigger, the
original primary controller attempts to reboot into the secondary role, but this controller is not
immediately able to participate in another switchover operation. After the new secondary reboots
into the secondary role, it must first perform and complete initial-synchronization before another
switchover is allowed.
The ability of a secondary controller to take over the assigned control functions of the primary
depends upon which one of the following readiness states reflects its current state.
- 199 -
Secondary
Indication
controller state
Not Cannot assume the primary state. This is a state of non-
synchronized readiness. The only exception is the Become Primary
command which only applies to the unsynchronized
secondary controller in the absence of a primary controller.
Synchronizing Cannot assume the primary state. In this state, the secondary
controller is copying database information from the primary.
Synchronized Can assume the primary state upon switchover. In this state,
the database in the secondary is aligned with the database in
the primary. The secondary closely tracks database changes
to maintain its synchronization with the database of the
primary.
Standby Can assume the primary state upon switchover. In this state,
the secondary controller contains a database that was
previously synchronized with the primary controller but the
secondary is no longer receiving synchronization-data
updates from the primary controller. Upon switchover into the
primary role with this stale database, the UOC CEE execution
state is forced to Idle to ensure operator intervention.
9.5.1 Become Primary command - BECMPRICMD

The Become Primary command is used to cause an unsynchronized secondary module to
transition into the primary role in the absence of a partner module. Specifically, this command
applies only if the unsynchronized secondary has no view to a partner module across the
redundancy cable and the primary FTE IP address is not occupied.
9.5.2 Initiate Switchover - SWITCHCMD

The Switchover command triggers a realistic switchover scenario. The original primary controller
reboots into the secondary role and the Synchronized or Standby Secondary controller assumes
the primary role to continue control operations.
9.5.3 Max Switchover Time - RDNSOTIMEMAX

The RDNSOTIMEMAX parameter indicates the maximum switchover time in milliseconds. This is a
high- water mark for all the previous switchover occurrences. This value is reset upon issuing the
controller platform function block's Stats Reset command.
9.5.4 Conditions that result in switchover

The following conditions result in a switchover.
- 200 -
l Become Primary command.

l Switchover command.
l Primary controller loss of loss of input power.
l Primary controller failure.
l Powered primary controller removed from its IOTA/Rack.
l Primary controller loss of both FTE links.
l Secondary controller FTE link reconnect when the primary controller has both FTE links
disconnected results in initial-sync followed by immediate switchover.
l Primary controller loss of communication with a configured 900I/O rack when the secondary
controller is successfully communicating with the same rack.
ATTENTION
Controller redundancy protects against all single faults and some dual faults.
Primary UOC loss of communication with a Rack switchover triggers are dual faults
(in the presence of redundant downlink communication) and cannot be detected
until after some control may have been back-initialized with failsafe data. Although
these faults can affect control, switchover may provide automatic recovery that does
not require the operator to diagnose the downlink network anomaly.
ATTENTION
UOC switchover may take 500 msec to 2.5 sec due to EtherNet/IP priming. For more
information see EtherNet IP User's Guide_EPDOC-X399-en-511A.pdf.
9.5.5 Conditions that do not result in a switchover

The following conditions do not result in a switchover.
l Loss of redundancy cable (private path) between primary and secondary controllers.
l Loss of one or both FTE links to secondary controller.
l One or both links on downlink network are physically disconnected from secondary controller.
NOTE
Only the first link is active when downlink is configured in non-redundant mode.
l Secondary controller loss of input power.

l Secondary controller failure.
l Secondary controller firmware update.
l Removing the powered secondary controller from its IOTA/Rack.
l Inserting a controller module into a powered secondary IOTA/Rack.
l Loss of a single FTE link to primary controller.
l Loss of a single downlink network link to the primary controller (when configured for
redundant downlink network).
l Data communication failures with secondary controller during synchronization.
- 201 -
9.5.6 Network switchover considerations

The redundant controller operation accounts for the following key considerations associated with
initiating a network switchover.
For this
switchover Controller redundancy operation
consideration
FTE device The FTE device indices are fixed physical hardware identifiers
index and do not transition from primary controller to the secondary
number controller based on redundancy role.
Floating The UOC use a floating downlink IP address that does change
Downlink IP with redundancy role.
Address
The lower (odd) IP address is used on the primary controller
and the higher (even) IP address is used on the secondary
controller.
9.6 Redundancy history

The UOC supports a table with 16 entries of redundancy history. There are 3 columns
representing redundancy history time, state, and reason. Only 16 recent most entries are retained
once the number of redundancy history exceeds 16.
l RDNHISTTIME - Redundancy History time. The system time captured at the time the entry was
added to the table.
l RDNHISTSTATE - Redundancy History state. Indicates milestones with respect to redundancy-
related activities like redundancy role states, compatibility states, synchronization states, user
commands, sync abort indication, and role change indication. Set to dashes “- - -” when entry
not yet initialized.
l RDNHISTREASON - Redundancy History reason. Optionally, indicates rationale for the
occurrence of the associated RDNHISTSTATE entries. Includes reason for loss-of-sync,
redundancy role change, commencing initial sync, and partner incompatibility. Set to dashes “-
- -” when entry not applicable (or entry not yet initialized).
For the list of Redundancy History state and Redundancy History reason enumerations, see
Control Builder Parameter Reference Guides_EPDOCXX18-en-511A.pdf.
- 202 -
CHAPTER
10 OPERATION
10.1 UOC States And Transitions

The following diagram summarizes important states and transitions of the UOC. Redundancy sub-
states are not shown. For information on those, see the Redundancy section.
Figure 10.1 UOC States and Transitions
In the diagram, user visible states are shown in green and yellow. The green states (Backup,
NotLoaded, Idle, CEERun) can be read via CDA access to the UOC platform block parameter,
CPMSTATE. They can be seen from the UOC platform block detailed display, the UOC platform
block monitoring form in CB and the CB monitoring tree. They can also be seen from Firmware
Manager, though NotLoaded is shown there under the name NoDB.
The yellow states (Alive, Failed, Ready) only occur within parent states which support no CDA
communication. They can be seen from the user view provided by the Firmware Manager. For
more information, see Firmware Manager_EPDOC-X404.pdf.
The visible states are organized under parent states that indicate key properties of their child
states. These parent states are not explicitly visible within an operating UOC system. The parent
states are Executing Application Image (orange), Inoperative (blue), and Executing Boot Image
(blue). Blue states do not support CDA communication.
- 203 -
Chapter 10 - Operation
UOC has a transient state shown in gray called Executing Boot Loader. This state is also not visible
within an operating UOC system.
Characteristics of UOC states are summarized in the following table.
Normal
State Visibility Description
Operation
NotLoaded CDA Yes UOC is waiting for first time load of its
platform block. It is the primary partner of a
redundant pair or is non-redundant. UOC
has no CEE database. UOC can be shut down
from this state.
Idle CDA Yes UOC is operative but not on control. It is the

primary partner of a redundant pair or is
non-redundant. CEE is Idle. The UOC’s
platform block has been loaded and its CEE
database is either present and usable or
under construction. CEE can be transitioned
to run. UOC can be shut down from this
state.
CEERun CDA Yes UOC is operative with CEE in Run. It is the

primary partner of a redundant pair or is
non-redundant. UOC cannot be shut down
from this state. It can be transitioned to CEE
Idle. In R511, UOC does not support
automatic transition to the CEERun state
from repower. For further information on
UOC restart, see the Restart After Power Loss
section.
Backup CDA Yes UOC is operative in the secondary role.

Synchronization status can be determined by
examining relevant redundancy parameters.
For further information on redundancy, see
the UOC Redundancy section. A UOC CPM
can be shut down from this state.
Alive Firmware No UOC is waiting for load of its Application

Manager Image. Occurs only if the Application Image
is missing or has become corrupted. Can
only be exited by firmware load.
Ready Firmware No Entered when a UOC shutdown is

Manager commanded. Firmware load may be
performed. Precursor to normal upgrade of
the Application Image.
Failed Firmware No Entered when a UOC module fails. Typically,

Manager the internal UOC event log is uploaded using
- 204 -
Normal
State Visibility Description
Operation
the Firmware Manager when this state
occurs. Can only be exited by power cycle or
firmware load.
Executing None Yes All associated child states occur when the
Application Application Image is being executed within
Image the UOC CPM. UOC always executes within
this state unless the Application Image is
missing or corrupted. See Note 1.
Executing None No Has only a single child state of Alive. Does

Boot not support CDA communication. May only
Image be exited via firmware load. UOC only
executes within this state if the Application
Image is missing or corrupted. See Note 1.
Executing None No Transient state that occurs after boot up and

Boot immediately transitions to the most
Loader functional state the UOC is currently capable
of supporting. During firmware load, UOC
reenters this state after the load of each
firmware image completes.
Inoperative None No A child state of Executing Application Image.

Does not support CDA communication. Does
not support normal UOC operation. Occurs
when UOC enters an abnormal condition
that requires maintenance. May be entered
from the Idle, NotLoaded or Backup states
via explicit shutdown command in
preparation for firmware load. May be
entered from Idle, NotLoaded, Backup or
CEERun states if a module failure occurs.
May only be exited via reboot or firmware
load.
NOTE
CPMs received from the factory must be loaded with the UOC Application Image and the
UOC Boot Image before they can be used as UOCs. See the “Converting PLC CPM to UOC
CPM” section for a description of how to convert a PLC CPM into a UOC CPM.
- 205 -
10.2 UOC Front Panel Indications
10.2.1 Ethernet Port LEDs

The UOC CPM has 4 Ethernet ports on its front panel, labeled as 1 (ETH1), 2 (ETH2), 3 (ETH3), and
4 (ETH4).
ETH3 and ETH4 are used for connectivity to downlink networks using open protocols. ETH1 and
ETH2 are used for connectivity to an uplink Experion FTE network. ETH1 connects to the FTE A
Yellow cable while ETH2 connects to the FTE B Green cable.
Each Ethernet port supports two communication status LEDs whose behavior is described here.
Link Present LED

Indication (Ethernet ports Description
1, 2, 3 and 4)
OFF Link integrity check has failed. Cable is not
connected or Ethernet signal cannot be detected
for some other reason.
ORANGESolid Ethernet signal is detected.
Activity LED Indication

(Ethernet ports 1, 2, 3 Description
and 4)
OFF Link integrity check has failed. Cable is not connected
or Ethernet signal cannot be detected for some other
reason.
GREEN Link integrity is OK but there is no activity on the link.

Solid
GREEN Activity is present on the link. Typically, any Ethernet

port shows some activity if the LED is observed for
Blinking
several seconds.
NOTE
Each of the UOC’s Ethernet ports have two associated LEDs whereas Experion Series 8
modules such as the C300 have only a single LED for each FTE connector.
10.2.2 Behaviors of Status and Redundancy Role LEDs

The UOC’s Status and Redundancy Role LEDs conform to the following general behaviors.
- 206 -
l LED colors
l Green LED indicates primary or non-redundant redundancy state.
l Orange LED indicates secondary redundancy state.
l Red LED indicates startup in progress or maintenance operations only or device
failure.
l LED duty cycle

l A solid LED indicates optimal operation.
l A blinking LED indicates sub-optimal operation. Devices in this state may be off
control, not synchronized, unconfigured or have a fault detected.
As a general rule, the LEDs display solid green or orange when running in an optimal state.
l The primary UOC has a solid green Status LED and a solid green Redundancy Role LED to
indicate that the primary is on control without any fault conditions detected.
l The secondary UOC has a solid orange Status LED and a solid orange Redundancy Role LED to
indicate that the secondary is synchronized without any fault conditions detected.
See Status LED and Redundancy LED sections below for specific LED behavior descriptions.
10.2.3 Status LED

In addition to encoding information by color, the Status LED uses two different duty cycle
indications as follows.
l Solid
l Blinking: 1 second on, 1 second off
NOTE
Status LED and Redundancy Role LED tables were previously updated. All new R511
behaviors are described correctly.
Specific behaviors are described in the following table.
- 207 -
LED Summary
Detailed Description
Indication Description
GREEN Primary, on control l UOC operating as the primary of a
Solid redundant pair or as a non-
redundant controller.
l UOC database loaded and CEERun.
l UOC on control.
l UOC state is CEERun.
GREEN Primary, off control l UOC operating as the primary of a

Blinking redundant pair or as a non-
or
redundant controller.
Primary, on control,
one or more l UOC off control or on control with
abnormal one or more abnormal conditions:
conditions detected
l Soft failure detected.
l UOC database not loaded.
l UOC database loaded but CEE

Idle.
l UOC state is NotLoaded, Idle, or

CEERun (with one or more abnormal
conditions).
ORANGE Secondary, l UOC operating in secondary

Solid synchronized. redundancy role.
l Compatible partner found on

redundancy private path.
l Initial synchronization complete.
l UOC state is Backup.
ORANGE Secondary, not l UOC operating in secondary

Blinking synchronized redundancy role with one or more
abnormal conditions:
or
Secondary, l Soft failure detected.
synchronized, one
or more abnormal l No partner found on
conditions detected redundancy private path.
l Incompatible partner found on
- 208 -
LED Summary
redundancy private path.

redundancy private path. Initial
synchronization not started.

redundancy private path. Initial
synchronization in progress.
l UOC state is Backup.
RED POST in progress l UOC not operational because starting

up or because of one or more fault
Solid or
conditions:
POST failed
l Power On Self-Test (POST) in
or progress.
Online diagnostic
failed l Power On Self-Test failed.
l On-line HW diagnostic failed
l On-line SW diagnostic failed.
l Watch dog timer expired.
l UOC state is in transient executing

boot loader state.
RED Nonoperational in l UOC not operational because it is

Blinking maintenance starting up, undergoing firmware
condition load, undergoing flash-ROM update,
or in a fault condition.
or
Nonoperational in l UOC state is Alive, Ready, or Failed.
fault condition
RED Startup is in l Device startup is in progress.

Pulsing progress, waiting
One Time for FTE Ethernet l The device is waiting for FTE A or FTE
Every 5 cable connection B Ethernet cable to be physically
Seconds connected.
RED Startup is in l Device startup is in progress.

Pulsing progress,
Two Times requesting FTE l The device is requesting FTE settings
- 209 -
LED Summary
Every 5 settings from from the server (BOOTP request).
Seconds server l The device will continue startup after
FTE settings are received from the
server (BOOTP reply).
l If FTE settings are not received within
60 seconds, the device may continue
startup using last known FTE settings
(when valid in non-volatile storage).
RED Startup in progress, l Device startup is in progress.

Pulsing FTE duplicate IP
Three address detection l The device has determined a
Times redundancy role and is checking for
Every 5 any duplicate IP addresses on the
Seconds FTE network.
l The device will continue startup if no
duplicate IP addresses are detected.
l If a duplicate IP address is detected,
the offending device must be
removed from the network before
startup will continue.
RED Startup in progress, l Device startup is in progress.

Pulsing waiting for
Four Times NTP/PTP time l The device has committed to an IP
Every 5 synchronization address and has joined the FTE
Seconds network.
l The device is performing initial time
synchronization via the NTP or PTP
protocol (depending on system
configuration).
l The device will continue startup after
the clock is synchronized.
l If the clock does not synchronize
within 60 seconds, the device may
continue startup using default date
and time values.
OFF Module unpowered l Invalid firmware in both Boot-

Recovery and Application-Product
or
images.
Module unable to
start l Module unable to start up.
- 210 -
10.2.4 Redundancy Role LED

In addition to encoding information by color, the Redundancy Role LED uses three different duty
cycle indications as follows.
l Solid
l Blinking Strongly: 1 second on, 1 second off
l Blinking Weakly: 1 second on, 3 seconds off
Specific behaviors are described in the following table.
LED
Summary Description Detailed Description
Indication
Green Primary, synchronized l Redundancy is enabled.
Solid l Redundancy role is primary.
l Synchronization is being maintained.
l Role change due to commanded switchover

or fault is supported.
Green Primary, l Redundancy is enabled.

Blinking synchronization in
l Redundancy role is primary.
Strongly progress
l Synchronization is in progress.

or fault is not supported.
Green Primary, no partner l Redundancy is enabled.

Blinking
or l Redundancy role is primary.
Weakly
Primary, incompatible l Primary cannot synchronize for one of
partner several possible reasons:
or l Partner is missing
Primary, partner visible l Partner is incompatible
l Partner is visible but secondary

condition is inferior to that of the
primary

Orange Secondary, l Redundancy is enabled.

Solid synchronized
l Redundancy role is secondary.
l Synchronization is being maintained.

or fault is supported.
- 211 -
LED
Summary Description Detailed Description
Indication
Orange Secondary, l Redundancy is enabled.
Blinking synchronization in
l Redundancy role is secondary.
Strongly progress
l Synchronization is in progress.

Orange Secondary, no partner l Redundancy is enabled.

Blinking
or l Redundancy role is secondary.
Weakly
Secondary, l Secondary cannot synchronize for one of
incompatible partner several possible reasons:
or l Partner is missing
Secondary, partner l Partner is incompatible

visible
l Partner is visible but secondary
condition is inferior to that of the
primary

Alternating Startup in progress l Device startup in progress

Green and
l Redundancy is enabled.
Orange Initial redundancy role
determination in l Device is performing initial redundancy role
progress determination.
l The device will search for a redundant

partner device and choose the primary or
secondary redundancy role.
Off Redundancy disabled. l Redundancy is disabled or not supported.
or l Role change due to commanded switchover

Redundancy not
supported.
10.3 UOC Startup
10.3.1 Actions During Boot

The UOC performs a set of actions every time it boots up, starting at state Initial, as shown in the
diagram of section “UOC States And Transitions”. The steps are executed from the Application
Image if a usable one is present. Otherwise, they are executed from the Boot-Recovery Image.
- 212 -
Stage Description
1 l The Redundancy Role LED briefly displays all colors of RED,
GREEN and AMBER and then turns off until start up completes.
l The Status LED briefly displays all colors of RED, GREEN and
AMBER. It then remains solid RED until the Power-On Self-Test
(POST) completes.
2 l Power-On Self Tests (POSTs) execute to verify that critical HW is

working as intended.
l POST execution halts on the first test that finds a faulty piece of
hardware.
l If a fault is detected, the Status LED remains solid RED and the
code of any failed test is held until UOC reset. If the module fails
repeatedly every time start up is attempted, it must be returned to
Honeywell for analysis.
3 l After POST completes successfully, the Status LED starts to blink

RED.
l Step 1: Waiting for FTE Ethernet cable connection – The UOC
waits for the FTE A and/or FTE B Ethernet cables to be physically
connected.
l Step 2: Requesting FTE settings from server – The UOC obtains its
base IP address from the Experion system’s BOOTP server.
l Step 3: FTE duplicate IP address detection – The UOC negotiates

its redundancy role with any partner module it detects, either
primary or secondary. The primary module is assigned the odd IP
address corresponding to its Device Index while the secondary
module is assigned the (odd + 1) IP address. Note that, during
switchover of a redundant UOC pair, the odd IP address follows
the primary module even though the Device Index does not
change. After its redundancy role has been assigned, a UOC
module determines whether any other module on the uplink
subnet is using the same IP address. The UOC will not continue
start-up if a duplicate IP address is detected on the FTE network.
After the duplicate address is removed, the UOC resumes its boot
up sequence.
l Step 4: Waiting for NTP/PTP time synchronization – The UOC

obtains its time synchronization from the Experion system’s NTP
or PTP server, depending on configuration. It retains the time
server’s IP address.
- 213 -
After a UOC has obtained its uplink IP Address and its NTP server IP address, it retains them until
its Device Index is changed or its firmware is reloaded.
The UOC does not acquire its downlink IP address from a BOOTP or DHCP server upon startup.
The downlink address is assigned by configuration. For further information, see the Ethernet
Downlink Connectivity section.
10.3.2 Restart After Power Loss

In the R511 release of Experion, the UOC always returns to NotLoaded state when there is a power
loss followed by a power recovery. The only configuration it retains is the downlink connection type
network. After repower, site personnel may restore checkpoint and command a Warm or Cold
restart. Alternatively, they may reload the control and I/O configuration using Control Builder and
command a Cold Start.
10.3.3 vUOC States and Startup Behaviors

For information on vUOC states and startup, see the vUOC section.
10.4 Using Station displays

Operation and status information as well as statistics for UOC controllers can be monitored
through various displays located on Experion displays and stations. Some of these displays are
briefly described below. See the Operator's Guide for more information about system displays and
detail displays.
The Experion Server and Station include pre-configured Detail displays for the UOC controller.
These displays are the default entries for the Point Detail Display parameter on the Server
Displays tab of configuration forms.
After establishing communication with a UOC you can monitor the status of control system
components through points registered with the Engineering Station. Detailed displays show
parameters of the blocks representing each component, presenting information such as state,
fault status and pertinent configuration data.
- 214 -
10.4.1 Identifying UOC

Click Identify device to identify the UOC on the I/O rack. To help you readily identify and locate the
UOC installed on the chassis, it starts blinking in red, green, and amber colors for approximately
10-12 seconds.
10.4.2 UOC Controller Point Detail Display (Redundant)
Primary
Main tab
- 215 -
Redundancy tab
Soft Failures tab
FTE tab
- 216 -
Downlink tab
Checkpoint tab
- 217 -
Config Details tab
Secondary
- 218 -
Main tab
10.4.3 UOC Controller Point Detail displays (Non- Redundant)
Main tab
- 219 -
Redundancy tab
Soft Failures tab
FTE tab
- 220 -
Downlink tab
Checkpoint tab
- 221 -
Config Details tab
- 222 -
10.4.4 vUOC Controller Point Detail displays
Main tab
Redundancy tab
- 223 -
Soft Failures tab
FTE tab
Downlink tab
- 224 -
Checkpoint tab
Config Details tab
- 225 -
10.4.5 UOC-CPM (Local I/O) Racks
Main tab
- 226 -
10.4.6 UOC-EPM Racks
Main tab
Config Details tab
- 227 -
10.4.7 UIO Racks
Main tab
I/O Channel Data tab
- 228 -
Checkpoint Operations tab
Config Details tab
- 229 -
CHAPTER
11 TROUBLESHOOTING
This section provides guidance and background information about the causes and remedies for
failures which may occur in the UOC controller. The following topics are presented here.
11.1 What to do when faults occur

If a controller fails, it will not fail into a state that causes unsafe process conditions. When a fault
occurs, you must try and gather as much information as possible related to the event, such as:
the status of the controller, the conditions or sequence of events that occurred before the fault.
See “Gathering information for reporting problems to Honeywell” for a list of information. This
information can be gathered from various sources in the system. See “Initial checks” for guidance
in obtaining information from displays, diagnostic tools and log files within the Experion system.
Read the topics in this section that includes troubleshooting procedures to clear faults. Refer to
other troubleshooting sources. See “Getting further assistance”.
11.2 Initial checks

This section offers some checks that you can make to help isolate the problem. The checks are
arranged in no particular order.
11.3 Checking Control Builder error code reference

An indication of a problem may be in the form of an error dialog that includes an error message
and possibly an error code in Control Builder.
The syntax for a typical Control Builder error message is as follows: “Connection to device is not
open EPKS_E_CL_NOCONN(6L.101.3326). In this syntax, the error code is the last four digits in
the message (3326 in this example).
See the Control Builder Error Codes Reference for applicable error code information.
11.3.1 Checking faceplate LEDs

Check the UOC LED indications and compare with the data of section “UOC Front Panel
Indications”. For information on fault classification, see “Fault classification”.
- 230 -
Chapter 11 - Troubleshooting
Fault Classifications LEDs

“Hard/Severe Failures” Status LED = RED
Redundancy LED = RED
“Soft Failures” Primary controller -

Status LED = RED
Backup controller -
Status LED = RED
“Installation-Startup Failures” Status LED = RED

“Hardware Watchdog Timer Expired” Status LED = RED

“Communications Failure” Ethernet Yellow speed/link LED off

Ethernet Green activity LED not
blinking
11.3.2 Using Firmware Manager to capture diagnostic data

The Firmware Manager will show if the module is communicating at all, and if it is, what state it is
in, when communication appears lost; this must be the first check.
For a redundant controller, the Firmware Manager’s diagnostic capture procedure must be
repeated for both the primary and secondary controller.
For more information, see Firmware Manager_EPDOC-X404.pdf.
11.3.3 Viewing release information log

The ReleaseInfo.txt log provides a list of Experion software releases that have been installed on
the computer. To view the log, navigate to this file location on the server:
C:\Program Files\Honeywell\Experion\Engineering Tools\system\bin\ReleaseInfo.txt.
11.3.4 Checking server point build log

The SvrPtBld_servername.txt log provides list of process CB points built in the server database.
To check the log, navigate to this file location on the server: C:\Program Files\Honeywell\Experion
PKS\Engineering Tools\temp\SvrPtBld_servername.txt.
- 231 -
11.3.5 Checking server point build error log

The svrptblderr_servername.txt log provides a list of errors associated with process (CB) points built
in the server database
To check the log, navigate to this file location on the server: C:\Program Files\Honeywell\Experion
PKS\Engineering Tools\temp\svrptblderr_servername.txt.
11.3.6 Checking error log

The Errlog_n.txt log provides a running list of Control Builder detected errors in chronological
order. The “n” represents any number that is assigned to the most recent log.
To check the log, navigate to this file location on the server: C:\ProgramData\Honeywell\Experion
PKS\ErrLog_n.txt.
11.4 Fixing common problems

This section identifies some common problems and describes how you might fix them.
11.4.1 Loss of power

The power supply has failed, or the main power source has been shut down, or is experiencing a
brownout or blackout condition.
Item Description
Diagnostic The LEDs on the controller module are off.
Check
In the Monitoring tab, the UOC icon turns red.
Cause 1 Main power source has been disconnected or shut down either
manually or temporarily by brownout or blackout condition.
Solution Re-connect the main power source or turn it On or wait for

temporary brownout or blackout condition to pass.
Cause 2 The power supply failed.
Solution Replace the power supply with the same type.
Cause 3 The module is not fully seated in the rack.
Solution Push the module into the rack and screw it in place.
11.4.2 Power-On Self Test (POST) does not complete

A fault is detected during the Power-On Self Test (POST).
- 232 -
Item Description
Diagnostic Module does not complete startup because a critical hardware
Check feature is non-functional.
Cause POST has detected a failure that does not allow startup to
continue or complete.
Solution Cycle power on the rack. If UOC does not come back, replace it.
11.4.3 Module does not complete startup
LED Indication Description

Status LED is red, l Module is waiting for physical connection to FTE
pulsing one time network.
every 5 seconds l Ensure that FTE Ethernet cables are physically
connected to module.
Status LED is red, l Module is requesting embedded FTE network

pulsing two times configuration from Experion PKS Server (BOOTP
every 5 seconds request).
l Ensure that Experion PKS Server is present on FTE
network, embedded FTE network settings are
configured on server, and "Experion PKS BOOTP"
service is running on server.
Status LED is red, l Module is validating FTE network IP address.

pulsing three l Ensure that duplicate IP address is not present on FTE
times every 5 network.
seconds
Status LED is red, l Module is waiting for initial time synchronization.

pulsing four l Ensure that NTP configuration is correct within
times every 5 embedded FTE network settings on server, NTP
seconds and/or PTP server is present on FTE network.
- 233 -
11.4.4 One or both FTE LEDs are OFF
Item Description
Diagnostic The Link Present and Activity LEDs associated with one or both
Check uplink Ethernet ports (ETH1 and ETH2) are off.
Cause 1 No connection.
Solution Check cable connections on controller and at switch.
Cause 2 Cables bad.
Solution Swap known good cable with suspect cable. Replace bad cable.
Cause 3 Switch port bad.
Solution Swap CPMs to identify defective port. Replace CPM that contains
defective port.
11.4.5 FTE receive fault diagnostic

The UOC controller has detected an open receive signal line between either of its two Ethernet
interface devices and the processor handling incoming communication.
- 234 -
Item Description
Diagnostic The Status LED on the front panel of the UOC controller turns
Check RED.
The ‘LAN_A’ or ‘LAN_B’ indicator for the faulted port turns RED.
The indicators are found on the FTE tab of the UOC Block
configuration form.
An alarm is generated by the UOC controller that indicates “FTE
Port A Receive Fault” or “FTE Port B Receive Fault”.
Cause The following conditions may result in a spurious (false)

indication of an FTE Receive Diagnostic fault. These conditions
are external to the UOC controller that allow a carrier to be
detected by the UOC controller's Port A or Port B Ethernet
interface but eliminate FTE traffic on that port.
Throttling of Ethernet traffic during of an abnormal amount of
communication traffic on one or both of the UOC controller's
Ethernet ports.
During a ‘storm’ on the FTE network, the UOC controller initiates
limiting of incoming Ethernet traffic on its FTE ports. As a result
of this limiting, a sufficient number of FTE Diagnostic messages
may be lost so that one or both ports see ‘good’ Link Status
signals but no FTE Diagnostic messages over the sample interval
of this diagnostic. In this case, the UOC controller's FTE Receive
Fault Diagnostic will indicate a spurious fault. The spurious alarm
generated by the FTE Receive Fault Diagnostic is a relatively
minor side effect, in the case of a network storm. A network storm
is signaled by other alarms in the system.
Solution Unless you suspect that one of the causes described above exists
and is resulting in a spurious indication, you must replace the
UOC controller Module exhibiting this diagnostic at your earliest
convenience. When this fault exists, network redundancy for this
node no longer is working.
- 235 -
11.4.6 Controller does not synchronize with backup
Item Description
Diagnostic Primary controller cannot synchronize with backup.
Check
In the Monitoring tab, double-click the primary UOC icon to call
up its Parameters configuration form. Click the Redundancy tab
to display it and check the “Inhibit Sync Reason –
RDNINHIBTSYNC” parameter for a description for the controller
not achieving synchronization.
Troubleshoot to correct condition for inhibiting sync.
Cause 1 Module is not seated properly.
Solution Insure that the module is firmly inserted and the mounting
screws are snug.
Cause 2 Backup controller bad.
Solution Replace controller module.

Check to see if controllers synchronize.
Cause 3 Primary controller module bad.
Solution Replace primary controller module.

Check to see if controllers synchronize.
Cause 4 Redundant Rack is defective.
Solution Replace the rack.
Cause 5 Software problem.
Solution Contact Honeywell SSC.
11.4.7 Fatal ECC error

The UOC controller software has detected a fatal Error Checking and Correction (ECC) condition
that can be a multiple-bit error or excessive single-bit errors in the main Random Access Memory
(RAM).
- 236 -
Item Description
Diagnostic In the Monitoring tab, the UOC controller icon turns red.
Check
Cause The controller software has detected a failure that does not allow
operation to continue. There can be many causes for a failure
including hardware.
Power cycle the module to see if it can come back. If not, replace
it. If it does, tag it in case the problem happens again.
Solution Cycle power for the UOC to restart the controller. If error persists,
replace the controller.
Check the Trace log for breadcrumbs that occurred prior to the
event. See “Using Firmware Manager to capture diagnostic data”
for more information. Provide the results of the trace log to
Honeywell Solutions Support Center (SSC) for analysis.
11.4.8 Isolated (lonely) Node

For a redundant controller pair, Fault Tolerant Ethernet (FTE) communications with partner and
FTE network are lost.
- 237 -
Item Description
Diagnostic The Primary controller determines whether or not to initiate a
Check switchover. If the Secondary was known to be in better condition
than the Primary at the time of fault determination, then the
Primary should fail so the Secondary will switchover. But, the new
Secondary (old Primary) still cannot restore FTE
communications.
When both the FTE cables are removed, secondary UOC does not
reboot. In addition, the secondary controller does not synchronize
in the presence of this fault condition. FTE communication has to
be restored to the secondary controller for initial sync to be
attempted.
Cause 1 Secondary controller is defective.
Solution Replace the Secondary controller that initiated switchover when

fault was detected.
If Secondary controller synchronizes after replacement, the
removed controller is defective. Otherwise, go to Cause 2.
Cause 2 Primary controller is defective.
Solution Replace the Primary controller.

If you can command synchronization after replacement, the
removed UOC controller is defective. Otherwise, go to Cause 4.
Cause 3 There is a software problem.
Solution Contact Honeywell Solution Support Center (SSC).
11.4.9 Duplicate Device Index detection

The FTE subsystem detects duplicate Device Index settings in separate nodes.
Item Description
Diagnostic All nodes will stop tracking cable status for the detected duplicate
Check Device Index value. Communications will continue and will not
impact system performance until there is a cable fault. This fault
will also be detected by the FTE System Management Tool.
A duplicate Device Index could cause a duplicate IP Address. In
most cases, the duplicate IP Address would be detected first and
prevent the FTE diagnostic messages from being sent.
Cause 1 Device Index switches on the two modules is set to the same
value.
Solution Change Device Index switches setting on each module to a

unique value.
- 238 -
11.5 UOC Controller soft failures

Soft failures are indicated on the Soft Failures tab of the UOC block configuration form shown in
Figure 1, and Table 1 describes these soft failure conditions when the indicator is lit and detected
by the UOC controller during background diagnostic checks. The controller is permitted to
continue to operate, but many of these errors suggest that a replacement is necessary.
Figure 11.1 UOC Soft Failures Tab, Parameter Description View
- 239 -
Figure 11.2 UOC Soft Failures Tab, Parameter Name View
Soft Failures tab in Control Builder
- 240 -
Soft Fail Condition when indicator

Corrective Action
Message is lit
FTE Device The Device Index switch Verify if the Device Index switch
Index Switches changed while the setting is correct, reset if
Changed controller was operating. necessary.
This condition would If failure still persists, the module
place the controller at a may be defective.
different and unexpected
CHECK
IP Address following a
subsequent controller Reset/reboot will cause module
restart. to assume new/incorrect address.
If visibly correct, rotate each of
them 360 deg. If this does not
correct problem, replace the
module.
Factory Data The Factory Data block Replace the controller module
Error corrupted which may and return faulty module to the
cause failure of Boot factory.
Image download or
Application Image
download during a
subsequent controller
restart.
Thermometer Thermometer is not Replace module.

Failure providing valid readings.
Enclosure The module detects Re-load the UOC controller

Temperature abnormal temperature Application image.
Critical in its environment. The
If failure still persists, replace the
CA is:
controller module and return
1. Check other faulty module to the factory.
modules in the
same
environment
(including
partner) to see if
they are reporting
the same
problem.
2. Physically inspect
the installation
and correct any
airflow problems.
- 241 -

Corrective Action
Message is lit
3. Replace module.
FPGA FPGA has become Power cycle the module. If the

Hardware unreliable. problem persists, replace module.
Failure
WDT Hardware The watchdog timer Replace the controller module

Failure hardware circuit is faulty. and return faulty module to the
factory.
Critical Task Indicates that one of a Contact Honeywell SSC.

Watchdog number of key tasks
Note that an alarm associated
Warning within the controller is
with this soft failure will appear
executing less frequently
immediately after detection of a
than expected.
timeout on one of these internal
tasks.
Uncorrectable The system Replace the controller module

Internal RAM automatically attempts and return faulty module to the
Sweep Error to correct soft memory factory.
errors. This error
indicates that one or
more locations in
Module RAM cannot be
corrected. The module is
considered to be
running in degraded
mode.
Corrected The system Replace the controller module

Internal RAM automatically attempts and return faulty module to the
Sweep Error to correct the soft factory.
memory errors that may
occur during normal
operation. This error
indicates that at least
one memory location
has been corrected and
the module is running
normally. The
recommendation is to
power cycle the module
to see if the error returns
quickly. If it does, then
replace it.
- 242 -

Corrective Action
Message is lit
Minimum The module’s hardware Replace Module
Recommended is below the
HW Revision recommended revision
level.
Power The module’s power Check incoming power; if correct

Over/Under supply is out of then replace power supply.
Voltage specification. Might
Warning reflect a brownout.
Non-Genuine The UOC does not Replace module.

Hardware appear to have been
Detected manufactured by
Honeywell
FTE Network Possible error on FTE. See the error indications on the
Error FTE tab for details.
Partner Not Indicates that the Fault See “Isolated (lonely) Node” in
Visible On FTE Tolerant Ethernet (FTE) this section.
communications with
redundant controller
partner and FTE network
are lost.
Downlink The downlink network is Check cables, devices on

Network Error enabled, but there is no downlink.
communications.
Partner not Indicates that the See “Isolated (lonely) Node” in

visible on downlink this section.
Downlink communications with
network redundant controller
partner is lost.
NVS/Retention The UOC Retention Once a valid SD card is inserted

Restart Media Restart function requires in the UOC or the
Error an SD card for the RETENTIONTRIG Block is deleted
saving and restoring of from the UOC, the soft failure
retention data. When a returns to normal. The virtual
RETENTIONTRIG Block UOC does not generate this soft
is loaded to the UOC and failure.
no valid SD card is
detected, the
“NVS/Retention Restart
Media Error” soft failure
- 243 -

Corrective Action
Message is lit
is reported by the non-
redundant or primary
UOC.
Possible causes for
NVS/Retention Restart
Media Error are as
follows:
l SD card missing.
l SD card not inserted
fully or not inserted
properly.
l SD card format not
recognized.
l SD card locked for
read-only access.
External Power When all external power Once external power is recovered,
Failure feeding the UOC’s power the soft failure returns to normal.
supply(s) is lost (as
detected through signals
PWRGOOD1 and / or
PWRGOOD2) then the
“External Power Failure”
soft failure is reported by
the non-redundant or
primary UOC.
Note that if the UOC is
redundant with
POWERCONNOPT =
Dual1PerModule and all
external power feeding
the power supply(s) of
the secondary is lost,
then no power loss soft
failure is reported.
Instead, the redundant
pair is forced to drop
synchronization and a
loss of synchronization
notification is reported.
- 244 -

Corrective Action
Message is lit
Control Freeze Upon commencing the Once retention data save is
for Retention save of retention data, a complete, the soft failure returns
Data Save “Control Freeze for to normal. When the
Retention Data Save” RETENTIONTRIG Block’s
soft failure is reported by FORCERESTART configuration
the non-redundant or option is disabled, one or more
primary UOC to indicate UOC CEE overruns are reported
that control processing after the retention data save is
has been temporarily complete. Display or peer data
suspended. access with the controller
performing retention save may be
Note that this soft failure
delayed for the duration of the
may not be reported
retention save resulting in Server
when the
or Console Station Connection
RETENTIONTRIG Block’s
TIMEOUT alarms with the
FORCERESTART
controller.
configuration option is
enabled as the restart
may prevent sending of
the notification.
11.6 Additional status and fault messages
11.6.1 Redundancy-related notifications

Messages generated by the controller related to redundancy status and redundancy faults are
listed in the Redundancy section in Redundancy Related Notifications table.
11.6.2 OPM-related notifications - RDNOPMSTATUS parameter

Status and Fault messages generated by the controller during the firmware migration process of
the controller are listed in OPM Related Notifications table.
11.7 Online diagnostics

Hardware diagnostics are executed within the controller during normal operations. Some
diagnostics execute frequently, but all diagnostics are designed to complete within eight hours
(the Diagnostic Test Interval). After the controller's Power-On Self Test and startup routines are
completed successfully, these diagnostics execute to detect any of an array of faults that might
cause degradation in controller operation.
When a fault is detected by the controller, it identifies and reports the fault to the system and acts
to maintain control and view through a switchover, if required (in the case of synchronized
redundant controller pairs). Various actions are taken by the controller depending upon the
severity or type of fault (Fault classification). Even though some of these detected faults do not
cause a failure or an action (such as a switchover) by the controller, the faults are reported to alert
operators of a potential failure in the future if not corrected.
- 245 -
11.8 Fault classifications

Faults have been classified into a number of categories according to the severity of the failure. The
controller behavior when a failure is detected is determined by type of fault and whether the
controller is non-redundant, or is one of a redundant controller pair. Table 3 identifies these fault
classifications and describes controller behavior in response to the fault type.
This section also includes more detailed descriptions of these fault classifications, how these faults
are indicated both on the controller faceplate and through other system displays and corrective
actions to clear the faults.
UOC Fault Classifications and Possible Causes
- 246 -
Fault Classification Description

Hard Failure Hardware detected failure. Operation cannot continue. If
software is running, the affected controller is rebooted
into the FAIL state.
Hard failure on a synchronized primary controller
triggers a switchover to the backup controller.
Hard failure on a backup controller causes a loss-of-
synchronization (and reduced availability until fault is
corrected).
Hard failure on a non-redundant controller causes a
loss-of-control and loss-of-view.
A module with a Hard Failure may not be visible to the
process system. It may or may not be visible in Firmware
Manager.
Severe Failure Software detected failure. Operation cannot continue.

The affected controller is rebooted into the FAIL state.
Severe failure on a synchronized primary controller
triggers a switchover to the backup controller.
Severe failure on a backup controller causes a loss-of-
synchronization (and reduced availability until fault is
corrected).
Severe failure on a non-redundant controller causes a
loss-of-control and loss-of-view.
Partial Failure Software detected failure. Non-redundant controller

could continue to operate.
Partial failure on a non-redundant controller results in
some or all loss-of-view and/or loss-of-control.
However, the controller does not reboot into FAIL state
but continues to provide whatever services it can.
Soft Failure Software detected failure. Controller continues to

operate with full control and full view. Soft failures are
alarmed to the operator. FTE is monitored by the FTE
System Management Tool.
Soft failure on the synchronized primary controller does
not trigger a switchover to the backup controller.
Soft failure on the backup controller does not result in a
loss-of-synchronization.
Soft failure on a non-redundant controller does not
- 247 -
Fault Classification Description

result in loss-of-control or loss-of- view.
Installation/Startup Software detected failure. Controller may not become

Failure operational.
Installation/Startup failure on a non-redundant
controller results in the inability to commence control or
view the controller on the network.
Installation/Startup failure on the backup controller
results in the inability to complete initial synchronization
or view the controller on the network.
Installation/Startup failure does not apply to the
synchronized primary controller, because installation &
startup must be successful to reach a synchronized
primary state.
Communications Communication errors between peer controllers, nodes

Failure and/or I/O devices- including FTEB, do not cause any
controller state change.
11.8.1 Hard/Severe Failures

When a hard failure is detected, the following controller events occur depending on its redundancy
status:
l Hard/Severe failure on a synchronized primary controller triggers a switchover to the backup
controller. The I/O modules associated with the controller force their outputs to safe values. If
capable, the failed controller reboots into the FAIL state and captures diagnostic data which
may contain internal state events that occurred prior to a failure. The Firmware Manager utility
can be used to retrieve the diagnostic data.
l Hard/Severe failure on a backup controller causes a loss-of-synchronization. The Primary
controller continues operation, but enters the ‘Not synchronized’ state. If the redundant
controller pair was not synchronized when the fault occurred, then the failed controller reboots
into the FAIL state, if capable. No further synchronization will occur and no switchover will
occur.
l Hard/Severe failure on a non-redundant controller causes a loss-of-control and loss-of-view.
The I/O modules associated with the controller force their outputs to safe values. If capable,
the failed controller reboots into the FAIL state and captures diagnostic data which may contain
internal state events that occurred prior to a failure. The Firmware Manager utility can be used
to retrieve the diagnostic data.
Alarm display and function block detail display

Usually, a hard or severe failure results in a communication failure. Calling up the Alarm Detail
Display in Station or the Controller Block Detail Display will show this failure.
Control Builder indications and error log
Using Control Builder, you can view the current state of controllers in the system. In the
Control Builder Monitor tab, a hard failure in the controller is denoted by a red controller icon
indicating no communication. See “Control Builder block icon descriptions” for a complete
listing of the UOC controller icons that may appear in Control Builder.
- 248 -
The Errlog_n.txt log provides a running list of Control Builder detected errors in chronological
order. The “n” represents any number that is assigned to the most recent log.
To check the log, navigate to this file location on the server: C:\Documents and Settings\All
Users\Application Data\Honeywell\Experion\Errlog_n.txt.
11.8.2 UOC Redundancy Communication Issues if CPM is not

securely connected to the rack
UOC-CPM hardware may have intermittent redundancy communication failures if the hardware is
not tightly screwed into the rack.
Diagnostic check: Physically check if the module is inserted properly.
Cause: Module is not seated properly in the rack.
Solution: UOC-CPM hardware must be securely connected and screwed into the rack to ensure
proper redundancy communication with a partner device through the backplane.
11.8.3 Soft Failures

Soft Failures are detected also through execution of the controller's “Online diagnostics”. Soft
failures do not cause change in the state of the controller's execution environments (CEE blocks).
There is no loss of control or loss of view when a controller detects a soft failure.
In a redundant controller pair, a soft failure in a synchronized primary controller does not cause a
switchover to the backup controller. A soft failure in the backup controller does not result in a loss
of synchronization, if the redundant controller pair is synchronized.
Alarm displays and Control Builder forms
Soft failures are reported in the Alarm Summary and the UOC controller Function Block Detail
displays in Station. In Control Builder, soft failure status is indicated on:
• The Main tab of the configuration form for the associated UOC controller block (Soft Failures
Present).
• The “UOC controller soft failures” section of the controller block configuration form includes a list
of the possible soft failure conditions as shown in Figure 1. (A listing of the Soft Failures with
descriptions and corrective action is in Table 1.) An indicator next to each condition shows when
the soft failure condition is present.
• The Control Builder Monitor tab, soft failure in the controller is denoted by a controller icon with a
small red circle with an ‘x’ inside the circle.
Soft Failure alarm return to normal
The alarm will return to normal after the on-line diagnostics detect that the soft failure condition
has been corrected. Note that on-line diagnostics run on a cycle and hence it may take a period of
time for the controller to perform the subsequent diagnostic check for the condition, notice the
change and then record it.
In some cases, online diagnostics may continue to assert the soft failure condition even when it
appears to have been corrected. This may happen when one occurrence of the soft failure is
considered sufficient to require action that requires replacement of hardware. When the controller
hardware is replaced, the alarm will return to normal after the UOC controller function block is
deleted and reloaded.
- 249 -
11.8.4 Installation-Startup Failures

A fault that is detected during the UOC controller's startup or Power-On Self Test (POST) may
prevent the controller from entering an operational state. The UOC controller module executes a
boot program and POST automatically when power is applied to the controller module. These tests,
verify the presence and integrity of the controller module hardware. See “UOC Controller start up”
for more details on startup and POST. See also “Communications and system time faults during
startup” for details on abnormal startup conditions and corrective actions to clear them.
If a fault is detected during POST, the controller halts. Power cycle the controller. If the fault
persists, replace the controller module since a hardware failure is indicated.
A redundant controller that fails during startup or POST will not begin control or join the FTE
network. A backup controller that fails during startup or POST will not complete initial
synchronization with its primary or join the FTE network.
11.8.5 Hardware Watchdog Timer Expired

The watchdog timer in the controller employs an independent hardware circuit to ensure that the
controller and its connected I/O devices are brought to a safe state in case the controller software
becomes corrupted or stops executing. If a fault arises in the hardware watchdog timer circuit, the
controller would not be protected from corrupt software execution. Therefore, a run-time
diagnostic check verifies the watchdog timer hardware integrity. If a fault is detected in the
watchdog timer hardware circuit, a “UOC Controller soft failures” condition occurs. See “Hardware
Watchdog Timer Expired” for more information.
The failed controller module does not contain any diagnostic data, although the redundant partner
module may contain some useful information.
11.8.6 Communications Failure

The System Management Display software application provides the means to configure and
monitor FTE nodes in Experion. The FTE Status Server and FTE Auxiliary display includes detailed
information on FTE links monitored by the FTE Provider. See Fault Tolerant Ethernet Status
Display User's Guide for more details.
11.9 Communications and system time faults during startup

The tables in this section help to provide guidance for determining the cause of abnormal startup
conditions in the UOC controller. These conditions may occur when the controller…
l Cannot establish normal communication on the FTE network
l Cannot obtain its network address from the system's BootP server
l Cannot obtain system time from the time source configured for the domain in which it resides,
l Finds that CDA services are not available.
Various indications on the controller's front-panel or the state of the Control Builder icon that
represents the UOC controller (if the controller had been loaded previously) are described that
point to an abnormal condition.
There are six tables that detail the abnormal conditions for both redundant and non-redundant
controller configurations and whether or not the controller memory has been retained via battery
backup.
Corrective actions for resolving these conditions are found below the tables, (see “Secondary UOC
Controller with Memory Retention” ).
- 250 -
11.9.1 Non-redundant UOC Controller

See UOC Front Panel Indications for more information.
UOC
Controller Block
Problem Station Alarm Resolve
Faceplate Time
Source
Status Blinking No communication on Internal UOC OFFNET “Secondary
LED Red FTE network UOC
Controller
FTE Off Controller does not
with
LEDs complete startup.
Memory
CB Red Retention”
icon
Status Blinking Communication on FTE Internal CDA comm “Secondary

LED Red -> network Lost UOC
Blinking Connection Controller
No Communication via
with
Green CDA
Memory
FTE Blinking Unable to establish Retention”
LEDs Green connection to system
time source
CB Grey
icon
Status Blinking Communication on FTE CDA UOC Not “Secondary

LED Red -> network UOC
Synchronized
Blinking Controller
Communication via CDA
Green with
Unable to establish Memory
FTE Blinking
connection to system Retention”
LEDs Green
time source
CB Red
icon
Status Blinking Communication on FTE NTP CDA comm “Secondary

LED Green network Lost UOC
Connection Controller
No communication via
with
CDA
Memory
Established connection Retention”
to system time source
- 251 -
UOC
Controller Block
Faceplate Time
Source
UOC appears to startup
normally but Control
Builder cannot
communicate with the
UOC controller and
therefore attempts to
load or reload UOC fail. If
UOC was loaded before a
power cycle, its
associated icons in the
Monitor tab will be Red.
FTE Blinking
LEDs Green
CB Grey
icon
Status Blinking None. Normal operation NTP UOC Not None.

LED Green for non- redundant
Synchronized
controller with no battery
backup following a
power cycle.
FTE Blinking
LEDs Green
CB Yellow
icon
11.9.2 Redundant Primary UOC Controller
UOC
Controller Block
Faceplate Time
Source
Status Blinking No communication on None UOC OFFNET “Secondary
LED Red FTE network. When FTE and UOC
CDA Controller
Controller does not
communication with
complete startup.
is established: Memory
Retention”
UOC Not
Synchronized
- 252 -
UOC
Controller Block
Faceplate Time
Source
Battery
FTE Off Undervoltage
LEDs
CB Red
icon
Status Blinking Communication on FTE None UOC OFFNET “Secondary

LED Red -> network UOC
When FTE and
Blinking Controller
No Communication via CDA
with
Green CDA
communication Memory
FTE Blinking Unable to establish is established: Retention”
LEDs Green connection to system
UOC Not
time source
Synchronized
CB Grey
icon Battery
Undervoltage

LED Red > network Synchronized UOC
Blinking Controller
Green with
Unable to establish Memory
FTE Blinking
connection to system Retention”
LEDs Green
time source
CB Red
icon

LED Green network Lost UOC
Connection Controller
with
CDA UOC Not
Memory
Synchronized
Established connection Retention”
UOC appears to startup
normally but Control
Builder cannot
- 253 -
UOC
Controller Block
Faceplate Time
Source
communicate with the
UOC controller and
therefore attempts to
load or reload UOC fail.
If UOC was loaded
before a power cycle, its
associated icons in the
Monitor tab will be Red.
FTE Blinking
LEDs Green
CB Grey
icon

LED Green for redundant primary
Synchronized
controller with no
battery backup
following a power cycle.
FTE Blinking
LEDs Green
CB Yellow
icon
11.9.3 Secondary UOC Controller
UOC
Controller Block
Faceplate Time
Source
Status Blinking No communication on None None “Secondary
LED Red FTE network. UOC
Controller
FTE Off
with
LEDs
Memory
CB Red Retention”
icon
- 254 -
UOC
Controller Block
Faceplate Time
Source
Status Blinking Communication on FTE None None “Secondary

LED Orange network. UOC
Controller
FTE Blinking with
CDA
LEDs Green Memory
Unable to establish Retention”
CB Grey connection to system
icon time source

LED Orange network Synchronized UOC
Controller
with
FTE Blinking Unable to establish Memory
LEDs Green connection to system Retention”
time source
CB Red >
icon Blue

LED Orange network UOC
Lost
Controller
No communication via Connection
with
CDA
UOC Not Memory
Established connection Synchronized Retention”
FTE Blinking
LEDs Green
CB Grey
icon

LED Orange for redundant secondary Synchronized
controller with no battery
backup following a power
cycle.
- 255 -
UOC
Controller Block
Faceplate Time
Source
FTE Blinking
LEDs Green
CB Yellow
icon
NOTE
Perform the following quick checks:
Are the server nodes turned on and properly connected to the network on which the UOC
controller resides? Are CDA and system services running on the designated nodes?
NOTE
l Is the timeserver node powered and running?
l Is the time service running on the node on which it is installed?
l Is the “NTP Server IP Address” properly configured?
l Check the value configured in Control Builder Tools > System Preferences >
Embedded FTE
l Compare this to the value found on the UOC controller FB Form’s System Time
tab when opened from the Monitor tab in Control Builder or the System Time
tab of the UOC controller FB Detail Display.
l Re-run c:\Program Files (x86)\Honeywell\Experion

PKS\Utiities\NTPsetup\ntpconfig.exe on all Experion Windows machines to provide
better quality of time. To make an Experion Server into an NTP server, refer to "Setting
Up Time Syncronization" chapter in the Supplementary Installation Tasks Guide.
NOTE
l Is the Experion node running CDA Server powered and running?
l Is the CDA service running on the node on which it is installed?
- 256 -
11.10 Gathering information for reporting problems to

Honeywell
When a controller failure occurs, you must gather information about the controller and the
conditions under which it failed. This information will be beneficial to Honeywell Solution Support
Center (SSC) to help in diagnosing and correcting the fault and/or replacing the controller
hardware.
Use this list to obtain information from the controller and the system so that when you contact
Honeywell SSC a complete description of the problem can be made.
l Use the Firmware Manager utility to retrieve internal controller state information to aid
technical personnel in diagnosing the failure. See “Using Firmware Manager to capture
diagnostic data” for the steps to retrieve problem report data for a failed controller.
l Remove and replace the failed controller. See the “Replacing a UOC Controller module” section
for details.
l Install the failed controller in a safe off-process location and start it up.
Obtain the following

l Hardware revision number of the controller
l The Experion System Release number in which the controller was operating
l Additional information regarding the operating conditions of the controller and sequence
of events:
l Was the controller operating in a redundant or non-redundant hardware configuration?
l What was the redundancy state of the controller at the time of the failure, if redundant?
l If I/O was supported, were there any status indications given on the I/OMs?
l Any other status or fail indications on the controller's faceplate observed at the time of the
failure or following the event?
l What were the Control Builder Monitor view indications at the time of the failure or
following the event?
l Generate an Event Journal Report for the time period starting as early as 1-2 hours before
the issue was observed and 1-2 hours after.
l Provide a detailed summary of the sequence of events leading up to the failure.
l What operations preceded the event, such as: load, activate, change parameter, delete,
power cycle, synchronization, switchover, etc.
11.11 Guidelines for requesting support

If you cannot resolve a problem by using this guide, you can request support from your Honeywell
Solutions Support Center. When requesting support, please supply as many relevant details about
the problem by referring to “Gathering information for reporting problems to Honeywell” to obtain
the problem-related information.
- 257 -
CHAPTER
12 CONTROL EXECUTION ENVIRONMENT
The Control Execution Environment (CEE) is a platform for executing control applications and
interfacing with I/O modules (EtherNet/IP and CE900 I/O). A CEE-based controller has a base
software layer called Infrastructure Services. These include Scheduling and Communication
Services. They set up an environment in which the execution and communication requirements
of control strategies can be met.
UOC allows for the creation of large batch strategies with a user block memory of 32 MB (128 MB
for vUOC). Function block libraries hosted by UOC are listed in the following table.
Block Library
AUXILIARY
CONTROLLOGIX
DATAACQ
DEVCTL
EIP_ARMOR_BLOCKI/O
EIP_ARMOR_POINTI/O
EIP_DRIVE
EIP_I/OCHANNEL
EIP_RELAY
ETHERNET_IP
I/OPOINTS
I/OREFERENCES
LOGIC
MATH
PCDI
POWERGEN
REGCTL
SYSTEM
UTILITY
- 258 -
Chapter 12 - Control Execution Environment
12.1 Functional Highlights

l CEE Block: Hosts a set of configuration and status parameters that describe the CEE hosting
execution environment itself. See the section CEE Function Bock and the Parameter
Reference Guide for further information.
l ControlEdge 900 I/O Blocks: Rack and I/O Module blocks allowing direct connection to field
signals can be configured within CEE and accessed from CEE control strategies. I/O Modules
can be located in remote racks or in the same rack as the UOC controller. For more information
see the ControlEdge 900 I/O Device Connectivity section.
l EtherNet/IP I/O and Device Blocks: Adaptor, I/O Module and Device blocks allowing direct
connection EtherNet/IP-connected devices can be configured within CEE and accessed from
CEE control strategies.
l ControlLogix Tagged Data Access: User defined Type blocks that allow read and write of tagged
data from ControlLogix PLCs. For more information, see the EtherNet I/P Device Connectivity
section.
l Control Modules:
o A set of control strategy configuration charts that configure the continuous
algorithms (Control Module) and sequential batch algorithms (Sequential Control
Module, Recipe Control Module, Unit Control Module). For further information, see
Control Builder Components Theory_EPDOC-XX16-en-511A.pdf.
o A set of function blocks designed to support either continuous or sequential control
within the execution context set up by control modules.
l The CEE supports the execution of function blocks available in the Control Builder libraries
shown in the following table
CEE in UOC supports 50 ms base period. CEE in vUOC supports 50 and 500 ms base period.
- 259 -
CHAPTER
13 VUOC
13.1 Introduction
The Virtual UOC, or vUOC, is a virtualized Unit Operations Controller that can be deployed on a
VMWare ESXi 6.0 or higher hypervisor. It has a Control Execution Engine (CEE) and is capable of
executing the same Experion PKS control strategies as the UOC CPM.
vUOC can communicate with EtherNet/IP devices and ControlEdge 900 I/O modules over
Ethernet networks.
UOC CPMs connect to a Level 2/1 FTE Network, (Downlink I/O Network) for connecting to I/O
devices, and a Private Path network (for future use). How those networks are deployed will vary
based on project needs and goals for availability, performance, and scalability.
The networks for I/O and Private Path always exist in the Virtual Machine Definition. So, when the
application does not require an external connection to EtherNet/IP or ControlEdge 900 I/O
hardware, (Peer to Peer implementations, and all cases for Private Path) those networks should
be mapped to an internal host only network.
13.1.1 vUOC controllers with Private Path and Downlink I/O adapters
Figure 13.1 vUOC controllers with Private Path and Downlink I/O adapters connected to virtual
networks with no external network access
In the diagram above, vSwitches represent the following:
- 260 -
Chapter 13 - vUOC
l FTE Yellow vSwitch – represents both Level 2 and 1 FTE primary network connections.
l FTE Green vSwitch – represents both Level 2 and 1 FTE secondary network connections.
l Private Path vSwitch – represents a private network connection, reserved for a future function
use (migration).
l Downlink I/O vSwitch – represents connections for I/O networks. Without devices, this can be
shared across controllers.
When the application calls for a vUOC to be connected to EtherNet/IP or ControlEdge 900 I/O
hardware, two network configurations are supported:
l Flat-network only approach where isolation is achieved through physical separation of
networking equipment.
l VLAN-tagged approach where one or more networks share physical networking equipment
and isolation is achieved through the use of VLAN-tagging in both the VMWare and physical
switch environments.
13.1.2 Flat Network Downlink I/O Topology
Figure 13.2 Flat Network Downlink I/O Topology

use (migration).
l Downlink I/O vSwitch – represents connection to an I/O network. If connected to an ETAP, only
one vUOC is permitted per vSwitch. If connected to a physical switch, multiple vUOCs are
permitted through use of VLAN-tagging. See Creating Network Connections for more
information.
Advantages:
- 261 -
Chapter 13 - vUOC
l Simple approach.
l Network Isolation.
Disadvantages:
l Operational Costs
o Dedicated host NIC required for each vUOC to support connections to I/O Devices.
o Individual network lines – Physical cabling requirements between virtual host (Control
Room) and I/O Devices.
l Scalability
o Limited by number of NIC ports available in virtual host.
o Lower vUOC density per host.
13.1.3 VLAN Tagged Network Downlink I/O Topology
Figure 13.3 VLAN Tagged Network Downlink I/O Topology

use (migration).
l I/O Port Groups – represent segmented connection to I/O.
- 262 -
Chapter 13 - vUOC
l vSwitch (I/O) – represent a combined connection to I/O.

l Trunk connection – combines each I/O Network to an external network infrastructure.
l I/O Switch – physical switch where I/O devices are connected (Additional downstream devices
may be required to provide paths to additional I/O devices.)
See Creating Network Connections for more information.

Advantages:
l Increase scalability through the use of shared network resources.
l Reduces the physical cabling requirements between virtual host (Control Room) and I/O
Devices.
l Physical isolation of FTE and Downlink I/O networks.
Disadvantages:
l Requires at least one free virtual host NIC to establish a Downlink I/O Network connection.
l Increase bandwidth requirements on virtual host NICs and connected switches.
l Increase scope of loss when faults occur in common physical network equipment.
13.1.4 Network Downlink I/O Topology
- 263 -
Chapter 13 - vUOC
Figure 13.4 Network Downlink I/O Topology

use (migration).
l I/O Port Groups – represent segmented connection to I/O.
l Trunk connection – combines each Network to an external network infrastructure.
l I/O specific traffic is then split from FTE Network to I/O Switches. When multiple I/O Networks
are hosted, connection between FTE and I/O is also trunked.
l I/O Switch – physical switch where I/O devices are connected (Additional downstream devices
may be required to provide paths to additional I/O devices.)
See Creating Network Connections for more information.

Advantages:
l Increase scalability through the use of shared network resources.
l Reduces the physical cabling requirements between virtual host (Control Room) and I/O
Devices.
Disadvantages:
l Increase bandwidth requirements on virtual host NICs and connected switches.
l Increase scope of loss when faults occur in common physical network equipment.
vUOC requires an Experion Virtualization Host Environment with connection to the Level 2/1 Fault
Tolerant Ethernet (FTE) network and available networks for connections to the Downlink I/O
Networks. Before implementing a new solution, you should review any existing connection
requirements. Consult the Experion Virtualization Planning and Implementation Guide to
implement the Virtualization Host environment itself, Security requirements, and the connections
to the FTE Network. When complete, return to this document to configure the connections for the
Downlink I/O Network.
13.2 Guidelines for integration of virtual controllers

If it does not exist already, a connection to the FTE Network supporting Level 2/1 is required.
Configurations utilizing a Flat Network I/O Topology approach must provide a private network for
each Downlink I/O Network (per controller).
l One network port on host per Downlink I/O for each virtual controller.
Configurations utilizing a VLAN Tagged Network I/O Topology approach must use a different
unique VLAN ID for each Downlink I/O Network (per controller).
l Use of VLAN IDs require that it be defined consistently throughout the network in all devices
between the controller and I/O connections.
l A frequent practice is to implement VLAN ID’s at lower values and increment up from there.
l Network designers need to evaluate any existing Port Groups defined, any VLAN IDs currently
in use, and plan accordingly.
l There are IDs that are reserved, so first consult the table below for IDs that should not be used
and your Switch Vendor’s documentation for any additional reservations:
- 264 -
Chapter 13 - vUOC
VLAN ID Why it should not be used

0 Reserved value that does not carry a VLAN tag and may be used to
signify priority; to be evaluated for Class of Service applications.
1 Default value used by most vendors for network management. Most

switches supporting VLANs will automatically assign all ports to use
VLAN 1 by default.
101 Configured by Honeywell for FTE networks and should not be used
for other networks.
999 Configured by Honeywell as the “native” VLAN. Used for both

interoperability with older switches and as a security measure for
handling of untagged packets.
1002 - Range is reserved by most Cisco Switches for source-based bridging

1005 on Token Ring and/or FDDI networks.
3969 - Range used internally by Cisco Nexxus switches for Virtual Device
4094 Contexts (VDCs), to provide:
Administration and Management separation.
Change and failure domain isolation.
Address, VLAN, Virtual Routing Protocol (VRP), and Virtual Port

Channel (VPC) isolation.
4095 Reserved for implementation use. It can be used to indicate a

wildcard match in management operations or filtering database
entries. Used in VMWare for Virtual Guest Tagging (VGT).
13.3 Creating Network Connections

The instructions provided in this section can be used for creating any type of switch for any type of
network.
The type of topology and the features you need to support (Fault Tolerance, for example) will
impact the number of NICs required in each of the hosts and the type of virtual switches you need
to have available.
Evaluate any existing host you are targeting and its current configuration or make sure the
platform you are ordering can support the needs of the solution. Plan for adding any additional
network cards (or swap existing ones for higher port density).
A standard vSwitch works only within one host (host specific). Configurations utilizing Fault
Tolerance require that the same definition of networks be accessible on each host.
Deployments utilizing VLANs should continue with Defining Port Groups after the switches are
configured.
- 265 -
Chapter 13 - vUOC
13.3.1 Creating a Standard vSwitch

After logging into the vSphere Web Client as a user who is a member of the
SystemConfigurationAdministrators group within VMWare, perform the following tasks:
- 266 -
Chapter 13 - vUOC
# Task
1 On the Home screen choose Hosts and Clusters.
2 On the left pane, click the Host that will host the Virtual Controller.
3 In the middle screen, click the Manage Tab, then click Networking tab in
the sub-menu:
- 267 -
Chapter 13 - vUOC
# Task
4 Under Virtual Switches, click the button to “Add Host Networking”
5 The following dialog will appear:
Choose “Virtual Machine Port Group for a Standard Switch” and click
Next.
- 268 -
Chapter 13 - vUOC
# Task
6 Select Target Device Appears:
Select “New Standard Switch” and click Next.
7 Create a Standard Switch is displayed:
If creating a vSwitch with an external connection requirement Click the

Plus and continue to Step 8
If creating a vSwitch with no external connection requirement, click Next.
The following dialog will then be displayed:
Click OK, then skip to step 11
- 269 -
Chapter 13 - vUOC
# Task
8 Create a Standard Switch is displayed:
On left side, select the NIC you wish to use for the I/O Connection and
click OK.
9 You are returned to the prior dialog, now showing your NIC selection:
Click Next
10 If you have not yet made a connection to the nic (not yet active), you may
be presented with the following dialog:
- 270 -
Chapter 13 - vUOC
# Task
If prompted, click OK to continue.
11 Connection Settings will Appear:
Rename the Network Label to something that makes sense for you to
associate this network with. Then Click Next.
12 Ready to Complete is then shown:
Click Finish
- 271 -
Chapter 13 - vUOC
13.4 Defining Port Groups

Port Groups are a group of ports supporting logical segmentation on a switch. By default, all
networks are configured with a default Port Group and VLAN ID of zero.
Additional Port Groups can be defined on a Standard vSwitch. Network isolation is achieved by
defining each additional Port Group with a different VLAN ID.
Deployments utilizing VLANs may also need to consider the impact to existing networks.
13.4.1 Adding a Port Group to a Standard vSwitch

- 272 -
Chapter 13 - vUOC
# Task
1 On the Home screen choose Hosts and Clusters.
2 On the left side the screen, click on the Host where you wish to define the
port group:
In the center area, click the Manage Tab
3 In the middle screen, verify the networking sub-tab is clicked under the
Manage Tab:
- 273 -
Chapter 13 - vUOC
# Task
Then select the appropriate vSwitch created previously. Hint: Clicking on a

vSwitch# will show additional details below, including any names you may
have set.
4 Under Virtual Switches, click the button to “Add Host Networking”:
5 The Add Networking dialog will appear:
Choose “Virtual Machine Port Group for a Standard Switch” and click Next.
6 Select Target Device Appears:
- 274 -
Chapter 13 - vUOC
# Task
Verify the vSwitch chosen in the “Select an existing standard switch” and
click Next.
7 Connection settings are displayed:
In the Network label, assign a name to something that makes sense for you
to associate this network with. Assign the appropriate VLAN ID, and click
Next.
8 Ready to complete is displayed:
- 275 -
Chapter 13 - vUOC
# Task
Verify the information is correct and click Finish.
13.5 Physical network support for VLAN topologies

Example Configuration Commands for the following configurations:
l Connections from VMWare Host to Physical Switcher
l Switch to Switch Connections
l Connections to I/O Devices
13.5.1 First level Switch configurations
NOTE
The example below assumes a two level topology and integration with FTE. However the
commands in this chapter can be mixed and match to support any required network
topology. Care should be taken to map and only allow access to the required ports that are
necessary for any particular network.
The network connections from the VMWare Hosts to the physical switch and any downstream
switch inter-connect need to be defined as Trunks when supporting VLANs. Consult the diagram
for the example switch location to which these configuration statements apply:
- 276 -
Chapter 13 - vUOC
Run the example set of Cisco I/Os commands to configure the switch to support the example
topology.
Enable the switch to support more than just a single VLAN (the default) by configuring a VLAN
database by setting the mode for the VLAN Trunking Protocol (VTP) and defining each VLAN ID
required to support the I/O devices. In the example below, VLAN IDs 201, 202, 203, and 204 are
declared for downlink I/O networks. Add or subtract as many as required based on the site's
requirements.
NOTE
If the switch is supporting FTE, a VLAN ID of 101 may likely already exist. It is repeated here
to show all VLANs supported by the switch and will not be an issue if defined again.
!
! Configure VLAN Database
!
vtp mode transparent
vlan 101
vlan 201
vlan 202
vlan 203
vlan 204
!
To prevent a possible security threat, we are going to configure a default tag for any packet
exchange between the VMWare Host and Switch that was not tagged previously. However, to
accomplish this, we must configure an interface for it. The example below defines this with a VLAN
tag ID of 999:
!
interface vlan 999
no ip address
no shutdown
!
- 277 -
Chapter 13 - vUOC
The next Step is to configure the ports used for connections to the VMWare Hosts. By default, it will
be configured as an access port. To use VLANs, it now needs to be defined as a Trunk Port.
(Note the assignment of ID 999 as the Native VLAN.)
The commands below changes two ports; 9 and 10, to trunk ports:
!
interface FastEthernet0/9
switchport mode trunk
switchport trunk allowed vlan all
switchport trunk native vlan 999
no ip address
!
switchport trunk allowed vlan all
no ip address
!
If the endpoints for communication exist on downstream switches, then the port used to
interconnect the two switches together must also be defined as a Trunk Port.
Care should be taken to only allow the traffic that is necessary to be sent to the appropriate
connection.
To allow for support of other nodes and Experion Network Management functions, VLAN 101
should also be allowed (besides any I/O VLANs). Some of that traffic (based on its origin) may not
be tagged. Setting a native VLAN will tag untagged traffic to 101.
The remaining allowed IDs represent the I/O VLANs.
The interface definition assumes this is using a Gigabit interlink port.
!
interface GigabitEthernet0/1
switchport trunk allowed vlan 101,201,202,203,204
switchport nonegotiate
no ip address
no cdp enable
13.5.2 Downstream Switch configurations

Consult the diagram for the example switch location to which these configuration statements
apply:
- 278 -
Chapter 13 - vUOC
Run the example set of Cisco I/Os commands to configure the switch to support the example
topology.
Enable the switch to support more than just a single VLAN (the default) by configuring a VLAN
database by setting the mode for the VLAN Trunking Protocol (VTP) and defining each VLAN ID
required to support the I/O devices. In the example below, VLAN IDs 201, 202, 203, and 204 are
declared for downlink I/O networks. Add or subtract as many as required based on the sites
requirements.
NOTE
If the switch is supporting FTE, a VLAN ID of 101 may likely already exist. It is repeated here
to show all VLANs supported by the switch and will not be an issue if defined again.
!
! Configure VLAN Database
!
vtp mode transparent
vlan 101
vlan 201
vlan 202
vlan 203
vlan 204
!
The port used to interconnect the two switches together must also be defined as a Trunk Port.
Care should be taken to only allow the traffic that is necessary to be sent to the appropriate
connection.
- 279 -
Chapter 13 - vUOC
To allow for support of other nodes and Experion Network Management functions, VLAN 101
should also be allowed (besides any I/O VLANs). Some of that traffic (based on its origin) may not
be tagged. Setting a native VLAN will tag untagged traffic to 101.
The remaining allowed IDs represent the I/O VLANs.
The interface definition assumes this is using a Gigabit interlink port.
!
interface GigabitEthernet0/1
switchport trunk allowed vlan 101,201,202,203,204
switchport nonegotiate
no ip address
no cdp enable
13.5.3 I/O Device Port configurations

When utilizing VLANs, any switch supporting I/O Devices should have those ports where the
device is connected restricted to the associated VLAN ID.
In the example below. Ports 1 through 4 are supporting devices connected communicating with
our first controller (using VLAN Tag 201). Ports 5 and 6 are supporting our second controller (using
VLAN Tag 202), Port 7 our third controller (using VLAN Tag 203) and Port 8 our forth controller
(using VLAN Tag 204). Assign ports as required matching your device requirements:
switchport access vlan 201
switchport mode access
no ip address
no cdp enable
spanning-tree portfast
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
- 280 -
Chapter 13 - vUOC
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
13.5.4 Control Edge 900 IO and Switch Configurations

When attempting to network Control Edge 900 Expansion Processor Modules (EPMs) with the
vUOC, some additional considerations must be made when configuring the network switches
between them.
The Control Edge 900 IO protocol utilizes priority-tagged Ethernet frames – IEEE P802.1p format
or “dot1p”. Most switch ports in their default access mode will drop these frames and not pass
them on to the rest of the network. Therefore, it is necessary to configure the switch ports
connected to Control Edge 900 IO capable devices, such as EPMs, to allow dot1p messages while in
access mode. This additional configuration is not required on switch ports in trunk mode, such as
those connected to vUOC’s ESXi host for purposes of trunking multiple downlink IO network
vLANs, see First level Switch configurations.
The following is an example Cisco IOS switch port configuration for an EPM intended to be
networked to a vUOC via VLAN 201. Highlighted is the configuration that will enable EPM
communication on this switch port.
switchport voice vlan dot1p
no ip address
no cdp enable
- 281 -
Chapter 13 - vUOC
13.6 Download
The Virtual UOC software is distributed as an Open Virtual Appliance (OVA) image file. This file can
only be obtained electronically through one of two methods:
l For Experion PKS General Releases (e.g. R511.1) - The image can be retrieved via download
link received with purchase of an “Electronic Download Experion PKS” license. See the General
Release README for more details.
l For Experion PKS Maintenance Releases, Updates, and Patches (e.g. R511.1) - The Virtual UOC
image can be retrieved from the Honeywell Process Solutions website
(http://www.honeywellprocess.com). See the associated Software Change Notice (SCN) for
more details.
Only one version of the Virtual UOC software image is required for deployment. For example, to
deploy the R511.1 Maintenance Release version of the Virtual UOC, it is not required to first
download and deploy the R511.1 General Release software image.
NOTE
It is strongly recommended to verify the integrity of software downloads using the Honeywell
Software Download Manager.
File Description
VirtualUOC_ The OVA file containing the VirtualUOC software image. This
<part file will be imported into a VMWare vCenter system when
number>.ova deploying a vUOC.
13.7 vUOC Deployment

Deploying OVA template
# Task
1 Login in to the VSphere Web Client.
- 282 -
Chapter 13 - vUOC
# Task
2 Right-click on your vCenter Server and click Deploy OVF Template.
3 In the Navigator Pane, choose Hosts and Clusters.

The following screen appears.
- 283 -
Chapter 13 - vUOC
# Task
NOTE
If you get a message about having to install the Client Integration
Plugin, install it and repeat the process.
4 Click Browse.
Navigate to the location where you stored the downloaded ova file and
select it.
5 Click Open.
It should return you to the previous screen with the OVA selected.
6 Click Next.
The Review details page appears.
- 284 -
Chapter 13 - vUOC
# Task
7 Click Next.
The Select name and folder page appears.
Update Name to something that will aid you in uniquely identifying the
virtual machine later. It can be helpful to include the following types of
properties: Type = For example, vUOC, Execution Cycle = 50 ms or 500 ms ,
FTE Index value = For example, 103.
Select a folder or datacenter location from the tree.
8 Click Next.
The Select a resource page appears.
- 285 -
Chapter 13 - vUOC
# Task
If necessary, expand the tree presented and select where the VM will be
hosted.
9 After the selection, click Next.

The Select storage page appears.
10 Select the appropriate datastore and click Next.
NOTE
If Fault Tolerance is intended, then a shared storage device should
be selected.
Storage devices presented will contains both local and shared
disks.
- 286 -
Chapter 13 - vUOC
# Task
The Setup networks page appears.
Use the destination drop-down to make the appropriate network

assignments.
The Destination for “FTE Yellow” and “FTE Green” should be the port
groups you setup on the associated vSwitches that represent the Level 2/1
FTE-A (or Yellow) and FTE-B (or Green) networks. The vUOC will use these
networks to communicate with Experion PKS Server, Console nodes, as well
as other controllers.
For “Downlink I/O”, select the port group on a vSwitch that you configured
to support the I/O devices that will connect to this virtual machine.
For “Private Path”, select the port group on a vSwitch that you configured
to support the private path network.
Your final configuration should look something like the following:
- 287 -
Chapter 13 - vUOC
# Task
11 When completed, click Next.

The Ready to complete page appears.
Review the options.

Optional – Check the Power on after deployment checkbox.
12 Click Finish.
When the virtual machine has been deployed, a completion message
appears in the Recent Tasks display of the client.
- 288 -
Chapter 13 - vUOC
# Task
13.7.1 Reconfigure Network Assignments

Network assignments can re-assigned post deployment.
After logging into the vSphere Web Client with a user who is a member of the
SystemConfigurationAdministrators group within VMWare, locate and click the VM you wish to
modify. In the center area, click the Manage Tab.
# Task
1 On the Home screen choose VMs and Templates.
2 On the left hand side, locate and click the VM you wish to modify.
- 289 -
Chapter 13 - vUOC
# Task
In the center area, click the Manage Tab. With the VM Hardware selected,
click Edit.
3 Edit Settings:
Click the Dropdowns next to each adapter and select the appropriate Switch
or Port Group. Once Completed, click OK.
13.8 vUOC Provisioning (first-time start up only)

The first time the vUOC is powered on, it must be provisioned with:
1. A base control execution cycle of 50 or 500 milliseconds. Guidance for selecting the base
execution cycle is as follows:
l 50ms - This setting should be used when vUOC will be deployed as a stand-in for a
physical UOC as part of a development or qualification/validation system.
l 500ms - This setting should be used when vUOC will be deployed as a centralized batch or
supervisory controller as part of a development, qualification/validation, or production
system.
- 290 -
Chapter 13 - vUOC
The vUOC CEE block "Base Execution Period" field in Control Builder must be configured
to match this selection or attempts to load the vUOC controller from Control Builder will
fail indicating "BASEPERIOD: Selected value is not supported by the CEE personality".
2. A device index which the vUOC will use to request an IP address from the Experion Cluster.
The IP address will be assigned based on the base IP address of the Cluster and the selected
device index.
This information is only entered once and cannot be changed. Simply delete the vUOC and re-
deploy with the desired settings, if needed.
# Task
1 Power on the vUOC and open its display console.
2 Click once inside the console window.

The startup sequence will pause and prompt for a device index.
Enter 50 or 500 to select the desired base cycle and press Enter.
3 The startup sequence will pause and prompt for a device index.
Enter the device index for this vUOC and press Enter.
- 291 -
Chapter 13 - vUOC
# Task
4 Upon startup completion, the vUOC will present a status display indicating:
l Local date and time
l Device index
l Application version
l Detailed status of each network interface
5 When the vUOC has obtained an IP address from the Experion PKS FTE
Community BOOTP service, it will be reflected in the ‘fte’ network adapter
status details.
- 292 -
Chapter 13 - vUOC
# Task
13.9 vUOC Configuration and Usage

See the Configuration section to begin configuring and using the vUOC as part of the Experion
PKS control system. The downlink LED on vUOC faceplate is always grayed out irrespective of
configuration. To troubleshoot this perform the below steps:
1. Configure vUOC and Downlink Network with EIP and EPM_UIO.
2. Load all the configurations and ensure all the EIP devices and UIO modules are
communicating with valid data.
3. Open Station and call Detail Display of vUOC.
4. The downlink LED remains OFF irrespective of downlink configuration.
13.10 vUOC and Virtualization Host Maintenance

During the lifecycle of a vUOC deployment, updates to the VMWare ESXi host software or
underlying hardware may be required. This typically requires the ESXi host under maintenance to
be shutdown temporarily.
In order to shutdown an ESXi host, all running VMs including the vUOC must be stopped or moved
to another ESXi host.
vMotion is an advanced VMWare feature that allows for moving VMs from one ESXi host to
another without observable service interruption. vUOC supports this live migration, or moving a
running VM, under the conditions for vMotion specified in Virtualization Planning and
Implementation Guide and Virtualization with the Premium Platform documents. ESXi hosts must be
configured for vMotion. vUOC virtual disks must be deployed to shared, not local, storage. vUOC
should be connected to distributed port groups and vSwitches shared by the current and target
ESXi hosts. It is also important to note that when moving a running vUOC to another ESXi host,
the target ESXi host must have the same or greater CPU family than the current host otherwise
the vUOC will have to be restarted and re-loaded or restored from Control Builder.
- 293 -
Chapter 13 - vUOC
The following is a step-by-step example for moving a running vUOC to another ESXi host, for
reference:
# Task
1 Identify the vUOC VM to be moved, right-click, and select Migrate…
2 Select the Change compute resource only option.

Click Next.
NOTE
Changing storage is not supported for live migration of a vUOC

using vMotion. Observable service interruption of the vUOC may
occur if storage is changed.
3 Select the host or cluster to which the vUOC will be moved.

Click Next.
Upon completion, the vUOC will present a status display indicating
- 294 -
Chapter 13 - vUOC
# Task
NOTE
Upon selecting a the target host or cluster, validation warnings will

appear under "Compatibility:" indicating that the vUOC's hard disk
controllers and network adapters are not supported by the target.
These warnings are benign and have no impact on the ability of the
vUOC to migrate to the target host without service interruption.
4 The destination network should not have to be changed if same port group
definitions are defined on the target.
If destination network will be changed, ensure that the new destination
network is associated with a vSwitch that is connected to the same physical
network as the source network and its associated vSwitch. Otherwise
observable service interruption to the vUOC will occur.
Click Next.
5 Select the Schedule vMotion with high priority (recommended) option.
NOTE
Selecting regular vMotion may result in an observable service

interruption to the vUOC.
Click Next.
6 On the Ready to complete screen, review selections and click Finish to move
the vUOC VM to the new compute host.
- 295 -
Chapter 13 - vUOC
# Task
Once the vUOC VM and other critical VMs have been moved to another ESXi host maintenance of
the original ESXi host may begin.
13.11 vUOC and Virtualization Host Availability

During the lifecycle of a vUOC there may be incidents where the hardware supporting a VMWare
ESXi host fails, resulting in a service interruption for the VMs running on that ESXi host.
VMWare’s vSphere Fault Tolerance, or FT, feature can automatically create and maintain a
secondary VM on another ESXi host that is continuously available to takeover for a primary VM in
the event that the primary VM’s ESXi host fails – resulting in no observable service interruption to
the VM and its applications.
The vUOC, which is a non-redundant controller, can be configured for FT which provides
considerable protection for the vUOC in the event of a hardware failure in a ESXi host.
FT is an advanced VMWare feature and many considerations must be made when planning for its
use with vUOC or other Experion PKS VMs in a virtualized environment. Please refer to
Virtualization with the Premium Platform for more information on VMWare vSphere Fault Tolerance.
13.11.1 Turning on Fault Tolerance protection for vUOC

Before attempting to enable Fault Tolerance on a vUOC VM ensure the following conditions are
met:
l The vUOC is currently hosted in a Fault Tolerance (FT) Cluster.
l The vUOC disks are stored on a shared datastore such as VSAN or NAS.
The following is a step-by-step example for enabling FT on a vUOC VM, for reference:
# Task
1 Identify the vUOC VM for which FT will be enabled, right-click, navigate to

Fault Tolerance, and select Turn On Fault Tolerance.
- 296 -
Chapter 13 - vUOC
# Task
2 Choose the storage location for the Configuration, Tie Breaker, and three
Hard disks of the secondary vUOC by clicking Browse, selecting from the list
of available datastores, and clicking OK.
When finished, click Next.
3 Select the host for the secondary vUOC VM.
NOTE
The secondary vUOC VM cannot be on the same host as the primary

vUOC VM.
Click Next.
- 297 -
Chapter 13 - vUOC
# Task
4 On the Ready to complete screen, review selections and click Finish.
5 The secondary vUOC VM will be started automatically.

On the Summary tab of the vUOC VM, a Fault Tolerance section will appear
indicating the protection status of the vUOC VM.
When the secondary vUOC VM startup completes, the Fault Tolerance field
should display Protected.
13.11.2 Disabling Fault Tolerance protection for vUOC

To turn off or disable Fault Tolerance protection of a vUOC VM, follow this step-by-step example:
- 298 -
Chapter 13 - vUOC
# Task
1 Identify the vUOC VM for which FT will be disabled, right-click, navigate to
Fault Tolerance, and select Turn Off Fault Tolerance.
2 A dialog will appear warning that turning off Fault Tolerance on the vUOC
VM will remove it from fault protection.
Click Yes.
- 299 -
CHAPTER
14 PERFORMANCE AND CAPACITY CONSIDERATIONS
14.1 Key Specifications
Constraint Specification
Uplink FTE Communications
Data Access Response 4000 Parameters per second

Rate
(All Displays and Peer
Nodes)
Peer to Peer Connection 30 peer connections

Count
Sustained Alarm and 2 notifications per second

Event Generation
UOC Configuration
User Memory UOC and vUOC-50 MS: 32 MB

vUOC-500 ms: 128 MB
Tagged Object Count 4095

(Platform Blocks, CMs,
SCMs, UCMs, RCMs,
I/OMs, MRs and
Activities)
Formula and Report 750

parameters per Data
block of Master Recipes
Downlink I/O Communications
Number of I/O Networks 1 dedicated downlink Ethernet per UOC (100

Mb/s)
Supported I/O Network l Nonredundant Star (CE 900 I/O only)

Topologies l Redundant Star PRP (CE 900 I/O only)
l Ring HSR (CE 900 I/O only)
l Ring DLR (CE 900 I/O, EIP I/O and Devices)
- 300 -
Chapter 14 - Performance and Capacity Considerations
Total I/O Point 2048
Connection Count
(Across All I/O Types)
ControlEdge 900 I/O
ControlEdge 900 I/O 12

Racks per UOC
Ethernet / IP I/O and Devices
Addressable Ring DLR 50

Node Count
EIP I/O Connection 160

Count
(Class 1 CIP Connections)
EIP Peer Controller 10

Connection Count
(Class 3 CIP Connections)
User Defined Types (UDTs) to Ethernet / IP Peer Controller
Parameters Per Multi- 64

Parameter UDT
Input Size of Multi- 480 Bytes

Parameter UDT
(To Read Parameters)
Output Size of Multi- 256 Bytes

Parameter UDT
(To Write Parameters)
Parameters Per Scalar 1

UDT
Input Size of Scalar UDT 4 Bytes

(To Read Parameters)
Output Size of Scalar UDT 4 Bytes

(To Write Parameters)
Multi-Parameter UDTs 65
Per UOC
(To All Peer Controllers)
Scalar UDTs Per UOC 465
- 301 -
(To All Peer Controllers)
Profinet
Number of Profinet 1 (Downlink Interface of UOC)

Interfaces
Number of Ports 1 (Only port 3 of UOC downlink when Downlink is

configured with non-redundant mode)
2 (If Downlink mode is set to DLR)
Number of IO devices 128

that can be connected
Fastest Scan Time 1 ms

Supported (minimum
cycle time)
Maximum size of total 64 KB Includes 10xS status bytes (This maximum

Cyclic Input & Output amount of data that UOC can exchange with
Data Devices using cyclic data exchange protocol)
Maximum number of 1440 bytes including IOxS status bytes

Cyclic Input Data per
Device
Maximum number of 1440 bytes including IOxS status bytes

Cyclic Output Data per
Device
14.2 Managing Processing Load
14.2.1 Relevant Parameters

Application engineers must be aware of information provided by the UOC to indicate if its
configured execution load is close to an overload condition. Indicators provided include the
following.
- 302 -
Parameter Description Parameter Name CB Monitoring Form

Current Hr. Cycle Overruns CRCYCLEOVRN CEE Block, CPU Overruns
tab
Previous Hr. Cycle LSCYCLEOVRN CEE Block, CPU Overruns

Overruns tab
Avg. CPU Used per Cycle CPUCYCLEAVG CEE Block, CPU Loading tab
CPU Free, all cores (%) CPUFREEAVG UOC Platform Block,

Statistics tab
CPU Free, core 0 (%) CPU0FREEAVG UOC Platform Block,

Statistics tab
CPU Free, core 1 (%) CPU1FREEAVG UOC Platform Block,

Statistics tab
CPU Free Low Alarm (%) CPUFREELOWLM UOC Platform Block, Main
tab
Max. Redun. Count per RDNCNTCYCMAX CEE Block, CPU Loading tab
Cycle
Redun. Cnt. per Cycle RDNCNTCYCTP CEE Block, Main tab

Trippoint
14.2.2 Overall Load Limits

Performance and capacity characteristics of a UOC system are multifaceted, involving multiple
types of behaviors and multiple types of specifications. A summary of relevant specifications is
provided in section “Control Capacity and Performance” of the Experion Control Builder Component
Theory Guide. Targeted specifications are listed there, such as Maximum Total Parameter Access
Response Rate, Maximum Push/Store Request Rate and others. However, in addition to targeted
specifications, UOC application engineers must be aware of overall performance specifications that
apply when multiple types of load are imposed at the same time. Key, overall performance limits
are summarized in the following table.
Load
Parameter Description Parameter Name
Limit
CPU Free, core 0 (%) CPU0FREEAVG >=
20%
Average unused capacity in the UOC’s core 0 CPU.
CPU Free, core 1 (%) CPU1FREEAVG >=

20%
Average unused capacity in the UOC’s core 1 CPU.
Avg. CPU Used per Cycle CPUCYCLEAVG <=

[40] 60%
Average CPU processing capacity used across the
40 CEE processing cycles.
- 303 -
Note that the overall performance specifications for vUOC are the same as those for UOC.
For further information on the parameters noted above, as well as general guidance on how to
monitor and correct UOC performance issues, see the sections below.
14.2.3 Cycle Overruns

A CEE cycle overrun alarm is reported if two, consecutive, 2-second intervals of CEE execution
occur in which at least one cycle overrun has been reported. The alarm clears once four,
consecutive, 2-second intervals of CEE execution occur in which no cycle overruns have been
reported. The presence of cycle overruns that have been captured in the current hour or in the
last hour can be observed from parameters CRCYCLEOVRN and LSCYCLEOVRN.
When a CEE cycle overrun alarm is reported it indicates at least one of these conditions.
l One or more CEE processing cycles have too many block executions to do.
l Or one or more CEE processing cycles have too much redundancy data to transfer.
To correct a CEE cycle overrun alarm, do the following.

l Identify cycles where an overrun has occurred.
l Rebalance or reduce the load on those cycles by identifying CMs or SCMs which run on those
cycles and moving them to different cycles.
Note that in a redundant UOC, cycle N-1 has an impact on the processing load of cycle N. This is
because data produced in cycle N-1 is transferred to the secondary during cycle N. As a result, if an
overrun occurs on cycle N, it may be necessary to consider the CMs which execute on both cycle N
and cycle N-1. If changing the execution cycle of CMs or SCMs does not eliminate the overruns, it
may be necessary to reduce the load by reducing the CM or SCM processing speed (increasing the
configured PERIOD) or by eliminating some CMs or SCMs from the configuration.
In addition to overrun counts, parameter CPUCYCELAVG may be observed to get a sense of the
processing load on CEE execution cycles. Indices 0 through 39 of this parameter ( CPUCYCLEAVG
[0] through CPUCYCLEAVG[39] ) give the time averaged CPU consumed on CEE cycles 0 through
39. Index 40 of this parameter ( CPUCYCLEAVG[40] ) give the average of CPUCYCLEAVG[ ] across
cycles 0 through 39. As noted above, CPUCYCLEAVG[40] should be kept at 60% or lower.
14.2.4 CPU Free

An alarm on the overall CPU available in the UOC is reported if the value of a CPU Free Average
statistic goes too low. The trip point of this alarm is established by parameter CPUFREELOWLM.
CPUFREELOWLM defaults to a value of 20%. You may set it to a lower value (down to 10%) if
desired, though doing so is not recommended.
The UOC uses a CPU with two processing cores, core 0 and core 1. The condition for generation of
a CPU free low alarm is the following.
l The time averaged, free CPU on Core 0 is below CPUFREELOWLM
l Or, the time averaged, free CPU on Core 1 is below CPUFREELOWLM.
To correct a CPU free low alarm, the application engineer must examine CPU0FREEAVG,
CPU1FREEAVG and may also examine CPUFREEAVG which is the average of the other two. Based
on observations of these parameters, the following considerations apply.
l If Core 1 CPU is too low, it may mean that the CEE block processing load is too heavy. CEE block
processing is executed only on Core 1. A heavy load there could indicate that the configuration
is approaching the point where overruns might start to occur. Consider reducing the count or
execution speed of CMs and SCMs.
- 304 -
l If Core 1 CPU is too low, it might also mean that the 900 I/O communication load is too heavy.
900 I/O communication processing is done only on Core 1. If there is a heavy 900 I/O
communication load present, consider reducing the quantity of I/O data being accessed or the
rate at which the I/O data is being collected.
l If Core 1 CPU is not too low but the Core 0 CPU is too low, consider the overall communication
load the UOC is experiencing. On the downlink, EtherNet/IP communication contributes to
Core 0 CPU consumption. On the uplink, CDA, PCDI blocks and Exchange blocks contribute.
Consider whether the volume or rate of any such communications can be reduced.
14.2.5 Redundancy Throughput

An alarm on the quantity of data transferred from primary to secondary each cycle is reported
when it exceeds a trip point. The trip point is established by parameter RDNCNTCYCTP. You may
increase the trip point if desired, though doing so is not recommended.
When a redundancy throughput high alarm is reported, it indicates the following condition.
l The volume of data transferred from primary to secondary on at least one CEE processing cycle
is high. A heavy redundancy load could indicate that the configuration is approaching the point
where overruns might start to occur.
To correct a redundancy throughput high alarm, examine the per cycle redundancy throughput
statistics shown by parameter RDNCNTCYCMAX. Determine whether there are particular cycles
where the redundancy throughput is particularly high. If so, consider rebalancing or reducing the
count of CMs and SCMs that execute on those particular cycles.
- 305 -
CHAPTER
15 SECURITY GUIDELINES FOR UOC
15.1 General
The UOC uses a “defense in depth” security strategy. Implementation of defense in depth
requires not only device and system security measures, but also physical and organizational
security measures to be taken.
The UOC is well-tested for security robustness. Network protection is addressed by
communication filters and storm protective communication handling is incorporated in the uplink
networking firewall.
System designers must always maintain an awareness of security vulnerabilities that might arise
when setting up network connections and must always follow Honeywell’s recommended security
best practices.
For more information on recommended security practices within Experion, see Network_and_
Security_Planning_Guide_EPDOC-XX75-en-511A.pdf.
15.2 Organizational Security

Organizational security considerations include site security guidelines, security awareness
training, ControlEdge UOC software version audits. For more information, see Network and
Security Planning Guide_EPDOC-XX75_en-511A.pdf.
15.3 Physical Security

Physical security includes controlling the accessibility of all spaces relevant to a ControlEdge UOC
placement. This includes securing access to control rooms, control and I/O cabinets, field
mounted control and I/O devices, system infrastructure integration equipment, wires / cables,
and other support equipment. Whenever possible, ControlEdge UOC devices must be placed in
secure locations, preferably in locked cabinets, with site control over personnel who are given
access privileges.
All networking equipment that the ControlEdge UOC communicate through, including, for
example, FTE switches and downlink network redundancy boxes, must also be placed in secure
locations.
For installations where the UOC is to be placed in a location remote from a central control room or
from main equipment rooms, consideration must still be given to physical security. Placement
within a secure, patrolled zone is preferable.
Switches with available ports to which rogue devices could be connected must be locked into end
point cabinets.
Considerations with respect to physical security apply equally to a UOC’s uplink network (FTE),
downlink, and redundancy networks.
- 306 -
Chapter 15 - Security Guidelines for UOC
One of the most prevalent threats to a computer system’s security comes from within the user’s
organization. If end users do not remain vigilant or become complacent regarding physical
security, the UOC may become vulnerable to security attacks. Periodic inspection and validation of
the networks and equipment attached to the UOC is a security focus end-users need to consider.
15.4 Communication Hardening

The ControlEdge UOC hardens communication access by blocking all unused communication
ports, by applying protocol-specific input validation checks, and disabling unused services.
15.5 Securing Connection to Uplink Network

The UOC provides a built-in uplink firewall that rejects traffic outside the parameters required to
fulfill its mission. This means, for example, that the UOC can be connected directly to a third party
level 2 switch.
The UOC processes correctly formed messages that originate from operational displays, control
configuration tools and system configuration tools. To insure that only authorized personnel can
initiate such communications, the UOC delegates authorization and role based access
responsibilities to the Experion system.
The UOC also initiates and receives communications with Honeywell peer controllers, such as
UOCs and C200 controllers. The complement of peer communications involving a particular UOC
is determined by the control and system configuration.
All Experion recommended practices must be followed with regard to user accounts and access
privileges. In addition, due diligence must be applied to the deployment of all networking
equipment. For example, switch configuration must disable unused ports and such configuration
must be secured from tampering with password protection.
Excessively high traffic on the FTE uplink to which a UOC connects could be an indication of a
Denial of Service (DOS) attack. Honeywell recommends the use of Honeywell Risk Manager or
SolarWinds to detect unintended and excess network traffic.
15.6 Securing Connection to Downlink Network

The ControlEdge UOC provides a built-in downlink firewall that rejects traffic outside the
parameters required to fulfill its mission. When the ControlEdge UOC connects to a downlink
network, the firewall is open to any messages that conform to the supported protocols, specifically
900 I/O and EtherNet/IP protocol.
If a third party network is connected to the UOC downlink, security considerations are similar to
those that apply to the FTE uplink. Vulnerabilities from the downlink are potentially greater
because third party devices, PCs and applications may or may not have been designed to the same
standards of security as Honeywell products.
Site practices must insure that third party components and network infrastructure are deployed in
a manner consistent with site security requirements and with all security guidelines provided by
the relevant vendors. Practices must insure that only competent and trusted personnel have
access to HMI stations and network infrastructure. Due diligence must be applied to the
deployment of all networking equipment. For example, switch configuration must disable unused
ports. Such configuration must be secured from tampering with password protection. Special
consideration must be given to information flows from third party devices or tools into Experion
that do not come over network communication. This applies in particular to files developed using
third party tools that must be imported into Experion to achieve the desired connectivity.
Securing the downlink relies on users maintaining practices of physical security. In particular,
users must ensure that switch ports available in star topologies only convey user authorized
messages, only permit user authorized access, do not spread viruses and do not wreak havoc on
the downlink network or the UOC(s) connected to it.
- 307 -
Users should be aware that the use of movable equipment can give rise to switch ports which are
left unconnected for long periods of time. Such ports are typically used only when special purpose
equipment must be connected for particular phases of a production cycle. Physical security must
be managed so that such open ports cannot be accessed for purposes of network penetration.
15.7 Maintenance, Configuration and Operation

As with the whole of Experion, access to the tools used to maintain, configure and operate the UOC
must be limited to trusted and competent personnel. This applies to the tools used at level 2 and
above and also to the tools used on a third party network if connected under the UOC.
15.8 Third Party Configuration Files

Files exported from third party tools are often used to create the Experion configuration needed for
communication with third party devices. This applies in the case of UOC, where EDS files can be
used to create C300 block types that can be instantiated to connect to EtherNet/IP devices.
Whenever third party files are imported into Experion there is the potential for viruses or other
malicious agents to be imported with them. Also, it is possible for the files to have been tampered
with, leading to improper behavior of the resultant configuration.
Specific procedures to follow for UOC configuration files imported into Experion include the
following:
l Ensure that an approved antivirus application is installed on the node used to import any third
party files.
Examples of third party files include, for example, EDS files used in connection with the UOC
application image.
l Ensure that all third party files are stored under one of these folder trees.
l Default path: C:\ProgramData\Third Party Files\
l Custom installation path: <Experion Runtime Data Folder Path>\Third Party Files\
15.9 Third Party Firmware Files

Care must be taken to assure that authentic and unaltered firmware files are being used when
new code versions are loaded to mission critical devices. This applies to Experion devices in general
and to the UOC in particular. It also applies to third party devices.
In the case of UOC, built-in services that recognize and prevent execution of counterfeit firmware
are provided. However, in cases where UOC is connected to third-party devices, the detection of
counterfeit firmware may or may not be provided.
15.10 Private Redundancy Network Path

UOC single-rack redundancy employs a backplane path that creates a point-to-point
communication link. This prevents, for example, use of a switch in the redundancy path, thus
eliminating potential tampering by adding devices to the redundancy path.
In cases where the user deploys dual rack redundancy rather than single rack redundancy, the
communication path for redundancy synchronization goes over an external Ethernet cable. The
security discipline which applies to that link is physical security. It is the user’s responsibility to
insure that physical security is maintained and that only 2 devices, the redundant UOC partners,
are connected to the redundancy link.
- 308 -
15.11 Patch Management

Integrity of firmware versions and updates is secured by a Secure Boot capability. Version visibility
is available for human interface display access.
15.12 Backup/Recovery Capability

ControlEdge UOC supports backup and recovery capability to support disaster recovery.
- 309 -
CHAPTER
16 CONFIGURING A SECURE CONNECTION FOR

EXPERION INTEGRATION
16.1 Secure Communications

Secure communications is required when two entities are communicating and do not want a third
party to listen in (i.e. avoid man in the middle attacks). For that they need to communicate in a way
not susceptible to eavesdropping or interception. Honeywell ControlEdge UOC secures its
communications using IPSec and X.509 standards compliant certificates.
This chapter is the first user assistance that all customers, system integrators and planners need
to read before installation, configuration and setup of Secure Communications for a ControlEdge
UOC or a system including a ControlEdge UOC with the intent to deploy Honeywell Secure
Communications.
The solution described in this chapter allows users to select which node-to-node communication
paths will be secured. Most communication paths to the UOC, both encrypted and unencrypted,
must be explicitly configured. You will need a single CA Server per trust zone, which is
recommended to be a single FTE community. As such you will need to install and configure your
CA Server only once per zone. After that it is a matter of using the Certificate Manager
Configuration Console (CMCC) to configure your ControlEdge UOCs, and then configure IPSec on
the Windows nodes. This will include generating the required certificates for these as the
instructions dictate.
For UOCs
All communication paths to all external nodes, whether on the FTE network or on the downlink
network, must be configured. Therefore policies must be created for the each of the following:
l Encrypted communications to other nodes (Windows nodes or peer controller nodes such as
other UOCs or C300s) on the FTE network
l Cleartext communication to other nodes on the FTE network
l Cleartext communication to devices on the downlink network
This may require dozens or hundreds of cleartext policies to be configured on a redundant UOC
pair, depending on the number of devices being used.
For Windows nodes
For each UOC that will be operating in secure communications mode:
l Encrypted communications to the UOC must be explicitly configured
l Certain protocols/services must be explicitly configured as cleartext (aka exceptions)
No explicit configuration is required to communicate with nodes that are not using secure
communications.
Phases of UOC Set-up
- 310 -
Chapter 16 - Configuring a Secure Connection for Experion Integration
There are four main phases in the set-up of each UOC before IPSec can be enabled. Some of the
configuration data is included in the synchronization from Primary to Secondary modules and
some is not.
l Setting Enrollment Information
l Enrolling for TLS communication (required for the next step)
l Enrolling for IPSec communication (uses TLS)
l Setting and activating security policies
This chapter details how to create a standalone root CA which can be used to issue certificates for
Engineering Station and Direct Stations, as well as for ControlEdge UOC. It also details how to
request certificates from this CA for two different purposes:
l Internet Protocol Security (IPSec) – for use with secure communications between the
Engineering Station, and any other Windows nodes that communicate with the ControlEdge
UOC
l Certificate Manager Configuration Console (CMCC) – to facilitate a secure connection when
configuring the ControlEdge UOC
In addition this chapter will provide details on how to install the certificate on each Engineering
Station and then how to enable IPSec policy to secure communications between the Engineering
Station and the ControlEdge UOC. To support secure communications between the Engineering
Station/Console, the ControlEdge UOC and redundant ControlEdge UOC, network layer security
provided by IPSec policies will be employed. To achieve this, UOC and the Server node need a
certificate issued by a certification authority (CA) trusted by both.
Points to note
l Accurate system time and time synchronization are essential to the operation of secure
communications. All certificates created during the set-up process are time-stamped at the
time of creation. Therefore all nodes times must be accurate and in sync from the very
beginning, even at the time the Certificate Authority is installed.
l IP address configuration should be completed before secure communications have been set-
up. Changes to the system, especially to IP addresses, after secure communications has been
set-up may cause significant re-work. For example:
o Using a Certificate Authority at a different IP address will invalidate all certificates that
have been created with the original CA. All set-up steps, including enrollment, on the
UOCs will have to be backed out and re-done.
o Changing the uplink (FTE) IP address of a module will require that all of the steps to
set-up the module for secure communications be backed out and re-done. This
includes the case where index switches are changed from their original setting.
o Changing the downlink IP address of a module will require the modification and re-
application of the relevant security policies. Enrollment will not have to be redone in
this case.
l There are certain important restrictions to how the Certificate Authority is deployed:
o Cannot be installed on domain controllers
o Must be installed only when logged in as the Administrator account.
o Node time must be set or synchronized correctly when the CA is installed.
o IP address must be set correctly when the CA is installed.
o Will not work across split subnet network in L2 FTE. Each network requires its own
Certificate Authority.
- 311 -
16.1.1 Secure Communication System Planning

As a first step to using Honeywell secure communications, the objective of this planning step is to
define the nodes involved and the level of secure communications desired. The output of this
planning session is a systems communication diagram. The figure below is an illustrative example
of a systems communication diagram for ControlEdge UOC.
Figure 16.1 System Communication Diagram
There are two windows nodes and 2 ControlEdge UOCs deployed at this site. Windows node 1 is
participating with the ControlEdge UOCs (at 192.168.0.3 and 192.168.0.5) in Secure
Communications. Windows node 2 is excluded from this due to its network placement or
interoperability reasons from this setup. Additionally, the diagram depicts the level of secure
communication expected (annotated as Cleartext and Encrypted). Refer to the following sections
for further technical information on implementation of Honeywell Secure Communications
solution.
16.1.2 Configure and Setup Steps

After completion of a systems communication diagram, the next step is to complete installation of
Secure Communications components. Secure Communications can subsequently be configured
and enabled using the below steps:
1. Install and Configure a Certificate Authority (one time operation for an install) – See "Creating
the Certificate Authority" for more information.
2. Creating different certificate types - See Creating a certificate for Engineering Station and
Console
3. Configure IPSec onto UOC - See Configure ControlEdge UOC for use with IPSec
- 312 -
4. Install IPSec configuration application and prime it for use with UOC - See "Installing
Certificate Manager Configuration Console" for more information.
5. Prime the Windows node and UOC for IPSec configuration – See "Setup certificates and IPSec
policy in UOC" for more information.
6. Configure IPSec policies (access control based on IP addresses) – See "Setup certificates and
IPSec policy in UOC" for more information.
7. Configure Windows IPSec (access control based on IP addresses) – See "Enable IPSec policy
on PCs" for moreinformation.
8. Enable IPSec on UOC and Windows nodes – See "Enable IPSec policy rules in the UOC" for
more information.
16.1.3 Advanced Technical Information

This section will provide a reader with advanced technical information about the underlying
technology used to ensure Secure Communications for Honeywell ControlEdge UOC.
Secure communication protocols provide a way to authenticate clients and servers and protect the
integrity and confidentiality of communication between clients and servers.
Protocol Secure Communications Technology

Builder Communication IPSec
HART-IP IPSec
PTP No secure Communication
Certificate Authority HTTP
IPSec Configuration App TLS
16.1.4 Certificate Management

Trust is established between nodes by presenting and verifying X.509 (v3) certificates. Below are
the characteristics of these certificates as they are distributed:
l ECDSA P-256 signatures
l Use of standard protocol SCEP (Simple Certificate Enrollment Protocol) for distribution,
renewal and CRL retrieval capabilities
16.1.5 Secure Communications using IPSec

IPSec is the selected method for communication between nodes within the same subnet. As such,
IKE protocol, defined under IPSec, is used during initial negotiation to authenticate a partner
endpoint and agree upon algorithms for subsequent attempts to secure communication. Below
are the default security constructs and algorithms selected for all nodes using IPSec:
l Use of main mode IKEv1 and IKEv2 when supported by peer
l SHA-256 message authentication
l AES-CBC 128-bit encryption
l ECDH P-256 Key algorithm
- 313 -
Subsequent to establishing trust, IPSec security constructs selected for securing communication
are
l Deny all communication unless explicitly granted
l ESP mode only, no AH • AES-GCM 128 bit message authentication, NULL encryption
l AES-GCM 128 bit message authentication and encryption
The above security constructs apply to a “security area”, a structural grouping of nodes used to
establish Secure Communications relationships. The below policies are options for all nodes that
form a security area:
l No Communication: to prevent explicit communication
l Cleartext Communication: no security measures intended for interoperability scenarios
l Authentication and Encryption (Message Integrity and Data Confidentiality): Full encryption
that helps preserve confidentiality
Enroll for IPSec communication

This step enrolls the UOC with the CA for IPSec communications.
Data Sync: This step must be performed separately on each module, as this data is not
synchronized between the modules. Furthermore if the two modules are not fully enrolled then
synchronization will be disabled.
16.1.6 Secure Commuincations Using TLS

TLS is the selected method to secure communications for the IPSec configuration tool. In this
scenario version 1.2 or higher is primarily selected with the below security constructs and
characteristics:
l SHA256/SHA384 hashing
l ECDHE (Forward secrecy, Ephemeral DH keys)
l AES-GCM 128 bit encryption
Enroll for TLS communication

This step prepares the module to retrieve the IPSec certificate from the CA over a secure channel.
Data Sync: This step must be performed separately on each module, as this data is not
synchronized between the modules. Furthermore if the two modules are not fully enrolled then
synchronization will be disabled.
16.1.7 Secure Boot

UOC firmware is signed to ensure authenticity. Firmware signing uses the following security
construct:
l RSA-2048
16.2 Obtaining and Installing the software

From the Honeywell Process Solutions website (www.honeywellprocess.com), download the
Secured Communications for ControlEdge PLC and Experion PKS package.
Once downloaded, extract the package and run the file “Secured Communications for ControlEdge
PLC and Experion HS.msi” with default settings to install the necessary files.
- 314 -
The files are installed to %Software Files%\Honeywell\Experion PKS\CertAuth, where %Software

Files% is potentially a custom install path for Experion programs. Default location is C:\Program
Files (x86)\Honeywell\Experion PKS\CertAuth\. For the rest of this document, the C:\Program
Files (x86) location should be substituted with the correct CIP path location, if a CIP install was
performed.
16.3 Overview of an IPSec deployment

Before starting to configure IPSec it is important that you identify the IP address of all NICs in PCs
(especially those used to communicate to ControlEdge UOCs and other devices) as well as the IP
address of all Ethernet ports on the ControlEdge UOCs and other devices used to communicate
with PCs. It is worth keeping a list of all these IP addresses for easy reference.
As some nodes will require different IPSec policies it is best to sort your IP address and hence node
list into four sections:
l PCs that will not be using IPSec (e.g. the CA server, RDP Clients)
l PCs that will be using IPSec to communicate with the ControlEdge UOC and other PCs using
IPSec
l Devices that will use IPSec (e.g. ControlEdge UOCs)
l Devices that will not use IPSec (e.g. C300, Flex stations)
For the purposes of this guide, a sample system is taken into account as shown below:
From this diagram it can be seen that IPSec encryption will only be used between Windows nodes
and the UOC.
Clear text communications will be permitted:
1. Between RDP Client and all Windows nodes in the control system subnet for RDP connections
only, as RDP traffic is already encrypted.
2. Between the Engineering Station and the UOC as this device does not support any other form
of communications.
3. Between the CA Server and the ControlEdge UOC, as this communication will be via an HTTPS
connection.
4. Between the ControlEdge Builder node with the CMCC tool to the UOC, as this connection will
utilise a TLS encrypted socket for the bulk of the communication.
5. Between the CA Server and the Windows nodes in the control system, as the PFX certificate
files are password protected.
6. Between all Windows nodes in the control system subnet.
- 315 -
IPSec encrypted communication would then occur:

1. Between the Engineering Station and the ControlEdge UOC
2. Between the Windows node running the ControlEdge Builder tool and the ControlEdge UOC.
From this system the nodes can be split as follows:
l PCs without IPSec
o RDP Client (Windows Node 1)
o CA Server (Windows Node 2)
o Experion PKS eServer (Windows Node 4)
l PCs with IPSec

o Engineering Station (Windows Node 3)
o Experion PKS Configuration Studio and ControlEdge Builder (Windows Node 5)
l Device with IPSec

o ControlEdge UOC
l Device without IPSec
This document will guide you through the process of configuring a CA Server, issuing certificates
for PCs, configuring IPSec on PCs and enrolling and configuring IPSec on the ControlEdge UOC.
16.4 Set Enrollment Information

Configure the information required for enrollment of the UOC with the Certificate Authority. Some
of this information becomes part of the certificate that is issued by the CA during the enrollment
process. There are two enrollment steps that follow.
Data Sync: The enrollment information is configured on the Primary module only, and is
synchronized to the Secondary.
16.5 Creating the Certificate Authority

The Certification Authority Server needs to be:
l Running Windows Server 2016 – Standard
l Able to receive traffic on port 80/tcp and port 443/tcp from the UOC without going through any
Network Address Translation (NAT) layers. Access to the CA Server might work through NAT but
it is not a supported topology.
CAUTION
The Certificate Authority is a critical asset from security perspective and should be restricted
from physical access within the network. Only authorized individuals should be allowed
access for all operations on this node.
CAUTION
The node's permanent IP address should be configured before the CA is installed. Once the
CA is installed it will not work properly if the node IP is subsequently changed.
- 316 -
CAUTION
All nodes participating in secure communications must have synchronized clocks. If not,
then the certificates that are created and exchanged as part of these procedures (either
manually or automatically) may fail validation and may cause errors in subsequent steps.
This PC should not be used for any other purpose. This is a Windows Server node running
Windows Server 2016, and the screenshots and PowerShell scripts included in this document
were developed using Windows Server 2016
These instructions will create a standalone root Certificate Authority (CA) that can work in both a
domain and workgroup environment. It will also configure the CA to support Network Device
Enrollment Scheme (NDES) which is Microsoft’s implementation of Simple Certificate Enrollment
Protocol (SCEP) which allows network devices (such as the ControlEdge UOC) to enroll for a
certificate.
This CA needs to be on the same network as the UOC and Experion Node, ideally the CA Server
would always be available, but as a minimum it needs to be available for initial enrollment with
IPSec for all PCs and UOCs. If the CA Server is not available on an ongoing basis this will impact
the ability for the PCs and UOCs to receive updated Certificate Revocation Lists and for the UOC to
auto- renew its certificate when it gets close to expiry.
Take UOC as an example:
CAUTION
Perform ALL install and configuration instructions on the CA Server under the local
Administrator account, not just an account in Administrators, but the actual Administrator
account. If the CA is installed improperly it cannot be uninstalled easily, so a first-time
successful installation is essential.
1. From the Experion PKS R510 media install the MSI file Secured Communications for
ControlEdge UOC and Experion PKS.msi and accept all defaults.
2. Start an Administrative PowerShell command prompt by going to the Start menu and going to
the Windows PowerShell folder then right click on the Windows PowerShell item in this menu
and choose Run as Administrator.
- 317 -
3. Change to the C:\Program Files (x86)\Honeywell\Experion PKS\CertAuth folder with the

following command:
cd 'C:\Program Files (x86)\Honeywell\Experion PKS\CertAuth\'
4. Run the following command to commence installing and configuring the CA:
.\Install-CA.ps1
When prompted:
a. Enter a password for the NDESop account, The NDESop is a service account used to
support generation of one time passwords (OTP) for enrollment of the UOC into IPSec.
b. Enter a password to protect the TLS certificate generated by this script.
c. Enter any additional IP addresses that the CA Server machine uses that are not shown,
press Enter on a blank entry when complete, or Enter at first Blank entry if no more to
add.
- 318 -
All the Windows components will then be installed and configured, this will take 5-10
minutes.
5. Check for invalid IP address in the CA’s CRL Distribution Point

a. Open MMC.
b. From the File menu select Add/Remove Snap-in …
c. Select Certification Authority from the panel on the left, and add the snap-in for Local
Computer.
d. From the main navigation tree on the left-hand panel expand the Certification Authority
entry and right-click on the machine name under Certification Authority, then select
Properties.
e. Select the Extensions tab and review the list of CRL Distribution points.
- 319 -
f. If there is an IP address in the list of locations that is not expected or is invalid for the
machine, such as similar to 169.x.x.x, right-click on the entry with the invalid IP address
and select Remove.
NOTE
Use Power Shell to re-install the IPSec certificate.
g. Select Apply, and close the Properties window.
The install and configuration of the CA Server is now complete.
16.6 Creating a certificate for Engineering Station and

Console
This sections describes how to make the different certificate types required, See "Installing
Certificate Manager Configuration Console" for more information.See "Enable IPSec policy on
PCs" for more information. And it should be followed to generate the appropriate certificate when
directed to by those sections.
To create a certificate, generate a key pair, create a certificate signing request (CSR) and then let
the CA sign the CSR. The key pair and CSR can be created either on the Windows node target
machine or on the CA itself. If creating on the target machine you will need to manually transfer
the CSR to the CA server. The example will guide on how to create the key pair and CSR on the CA
as in this way you can perform this action disconnected from the target machines and potentially
in a different location.
- 320 -
TIP
These instructions can be used to make the certificate for IPSec use for Windows nodes that
connect to the UOC, in addition these instructions can also be used to make the Certificate
Manager Configuration Console (CMCC) and GetChallenge IIS web page TLS certificate. The
TLS certificate for the CA GetChallenge web page is created automatically as part of the
.\Install-CA.ps1 PowerShell script.See "Creating theCertificate Authority" for more
information.. So no further mention of it appears outside of this section. The steps for
creating all 3 certificate types (IPSec, CMCC & TLS) are largely the same, where they differ
the steps below will clearly state this.
16.6.1 Creating a certificate
TIP
Ensure that you log in as an Administrator.
1. Ensure the PowerShell script CACertificateRequest.ps1 is at C:\Program Files

(x86)\Honeywell\Experion PKS\CertAuth (or the equivalent CIP location)
2. On the CA Server start an Administrative PowerShell command prompt (See "From the
Experion PKS R510 media install the MSI file Secured Communications for ControlEdge UOC
and Experion PKS.msi and accept all defaults." for more information. Steps 1 & 2 for explicit
details.) or continue using previously open prompt.
3. Change to a directory that you wish to store your certificates in, eg
C:\Users\Administrator\Desktop\MyCerts
4. Run the PowerShell script as follows:

& 'C:\Program Files (x86)\Honeywell\Experion PKS\CertAuth\CACertificateReques t.ps1'
And answer the prompts as follows:

CertificateType: Is the type of certificate and should be one of CMCC, TLS or IPSec
Computer: This is the name of the computer the certificate will be installed on (eg the
Experion PKS Server…)
Organization: This is the name of the company that owns this system
Country: Is the two letter country code where this system is installed
IPaddrs[n]: Is the IP address of the computer is installing to, if the computer has multiple
IP addresses type each and press enter, up to 10 IP addresses can be entered, once
complete press enter on a blank line
- 321 -
PFXPassword: Is the password to be used to protect the private key in the output PFX file
5. On completion of the script it will show the name and location of where it stored the output
PFX file which contains the certificate and private key.
This file should now be copied to the target machine. The following section will detail how to install
the certificate at the target machine.
16.6.2 Importing certificate and private key on target machine

The process for importing certificates is largely the same for all three certificate types, however the
store location and store do vary by certificate type.
Certificate Store
Store Reason What nodes?
type Location
TLS Local WebHosting Used by IIS for CA Server
Machine (Web the
Hosting) GetChallenge
web page
CCMC Current My Used by the Node used to setup

User (Personal) CMCC IPSec on UOC typically
command line an Engineering Station
tool
IPSec Local My Used by l Engineering

Machine (Personal) Windows for Station connecting
IPSec to UOC
l Nodes using
ControlEdge
Builder to
configure UOC
The instructions in this section will explicitly state what needs to be done for each certificate type
as this information varies.
- 322 -
TIP
1. Locate the certificate PFX file in Windows Explorer (it should have been copied to this node at
end of last section) and then double click on it
2. The certificate store location then needs to be chosen, this varies by certificate type.
a. For IPSec and TLS certificates only:
At the Welcome to the Certificate Import Wizard choose the Store Location to be Local
- 323 -
Machine then click Next.
b. For CMCC certificate types only click Next.
3. If presented with a User Account Control dialog click Yes or provide appropriate credentials.
- 324 -
4. At the File to Import dialog verify that it is showing the name of the file you specified and click
Next.
5. At the Private key protection dialog enter the password you set when exporting the certificate,
ensure the Mark the key as exportable option is disabled and that the Include all extended
properties option is enabled then click Next.
- 325 -
6. The correct Certificate Store needs to be chosen for the certificate type, this varies based on
Certificate Type:
- 326 -
a. For IPSec or CMCC certificate types only

At the Certificate Store dialog ensure the option Automatically select the certificate
store based on the type of certificate is enabled and click Next.
b. For the TLS certificate type only

At the Certificate Store dialog ensure the option Place all certificates in the following
store is enabled and click Browse… then choose Web Hosting and click OK and then
click Next.
- 327 -
7. At the Completing the Certificate Import Wizard dialog click Finish
- 328 -
8. After the certificate import completes a dialog should popup to confirm that The import was
successful now click OK
With the certificate now installed, and the CA installed as a Trusted Root CA this certificate and
others issued by the CA should now be accepted by this machine without need for the CA to be
online and available.
16.7 Configure ControlEdge UOC for use with IPSec

This section will help configure IPSec onto the UOC, but it will not enable it. Instructions to enable
it should be undertaken when all PCs, devices and UOCs have been configured for IPSec, and are
all ready to be enabled. See "Enable IPSec policy rules in the UOC" for more information.
16.7.1 Installing Certificate Manager Configuration Console
TIP
It is recommended to install and use the CMCC tool on a Flex Station.
TIP
1. From the Experion PKS R510 media install the MSI file Secured Communications for
ControlEdge UOC and Experion PKS.msi and accept all defaults.
2. Go to the machine you wish to use for configuring certificates on to the UOC, note this
machine should not be the CA Server. Then open Windows Explorer on this machine and in
the root directory of C:\ make a new folder called CertMgmt and then navigate into this folder.
- 329 -
3. Copy the contents of CertManagerConfigConsole.zip stored in C:\Program Files

(x86)\Honeywell\Experion PKS\CertAuth into this folder so that there is now a
CertManagerConfigConsole folder (or similar) in the C:\CertMgmt folder.
4. See "Creating a certificate for a Windows node" for more information. To create a certificate of
type CMCC for the Windows computer you’ve just installed the CMCC software on, ensuring
that you install it to the Current User store at step 2 See "Importing certificate and private key
on target machine" for more information.
5. Start up a management console (mmc.exe) accepting a User account control prompt or
providing appropriate credentials if shown:
6. From the File menu click on Add/Remove Snap-in…
- 330 -
7. On the Add or Remove Snap-Ins dialog select Certificates and click Add >
8. On the Certificates snap-in dialog select My user account and click Finish.
- 331 -
9. Back on the Add or Remove Snap-ins dialog, verify that the Selected snap-ins column shows
Certificates – Current User then click OK
10. Go to the File menu and click Save.
- 332 -
11. Call this console “Certificate Management” and save it somewhere you will remember, in this
example it will be saved to the desktop.
12. In the left hand navigation pane navigate to Certificates – Current User then click on Trusted
Root Certification Authorities then click Certificates on the right hand pane should now show
the CA’s certificate that was just imported.
- 333 -
13. Double click on this certificate and go to the Details tab
14. On the Certificate dialog Details tab click Copy to File… to save the certificate.
15. At the Certificate Export Wizard dialog click Next.
- 334 -
16. On the Export File Format dialog ensure that the format selected is DER encoded binary X.509
(.CER) then click Next.
- 335 -
17. On the File to Export dialog enter the name and location of a file to store the certificate in
using the .CER extension and then click Next.
- 336 -
18. At the Completing the Certificate Export Wizard dialog click Finish to complete the export.
- 337 -
19. After the file is saved to disk a dialog should popup to indicate that The export was successful
now click OK.
TIP
Note this .CER file will be needed at step 4 in the following section.
16.7.2 Setup certificates and IPSec policy in UOC

NOTE
Install of the CA node fails if CA is in domain.
- 338 -
1. Start a Command Prompt and change to the Certificate Manager Configuration Console
(CMCC) folder with the following command (or similar):
cd \CertMgmt\CertManagerConfigConsole
2. Run the following command:

CertMngrConfigConsole.exe ip:<UOC IP Address>
Where <UOC IP Address> is the IP of the UOC, or the Primary UOC if using redundant UOCs,
you are connecting to.
3. First the Enrollment information needs to be setup. So, at the CMCC prompt type:
SetEnrollInfo
4. At the prompts enter the following information:

CACertificate – Enter the full path to a copy of the CA certificate (this is the .CER file saved. See
"Installing Certificate ManagerConfiguration Console" for more information.)
Copy the CA certificate locally to Flex node.
CAHostname – Enter the IP address of the CA
CAPort - Leave this at the default of 80
SntpHostname – Leave this as default unless you have an SNTP Server
NOTE
The tool accepts only one SntpHostname, so enter the Primary SNTP host name
here. The Secondary SNTP host would not be supported in this case.
DeviceIPAddressN – Enter the IP addresses of the UOC (The first should be the Uplink IP
address of the primary UOC, and the second should be the uplink address of the secondary
- 339 -
UOC. The third and fourth IP address entries should be left blank), press enter after each and
if less than 4 then pressing enter at a blank prompt will signal the tool to stop further
DeviceIPAddress prompts. The first IP address should be pre-populated with the IP address
you used to start the CMCC.
Install CA certificate both on primary and secondary UOC.
5. To verify that the enrolment information has been set in the UOC at the CMCC prompt type:
GetEnrollInfo
<Enter>
This step should not be done on secondary UOC.

6. Next is enrolling the Certificate Manager, to do this at the CMCC prompt type:
CMProfile
This will bring up the CMProfile menu to Enroll the Certificate Manager in the UOC with the CA
- 340 -
a. Open a web browser to the CA Server:

https://<CA Server IP Address>/GetChallenge
Note: If you are using Internet Explorer on a Windows Server OS, first add the CA site to
your “Trusted Sites”.
When prompted login with the local Administrator account credentials for the CA Server,
ensure “Remember my credentials” remains un-checked.
Note: If your web browser is running on a machine in a domain ensure you use
“.\Administrator” as the user name.

b. Select Generate random challenge and click on Submit to RA, the page should then
display the Generated Challenge (also known as a one time password, OTP).
- 341 -
ATTENTION
The OTP should be handled with extreme care and ensure the value is
communicated to the UOC in a controlled manner. Loss of the OTP may allow
the introduction of a separate node as trusted node within the system, if it is
used elsewhere between generation and step 9 below you will receive an
error from the CMCC tool indicating the OTP is invalid.
c. Back in the CMCC tool the UOC’s Certificate Manager module can be enrolled by typing
the following command at the CMCC prompt:
EnrollWithPassword
Then type the OTP from the previous step, the enrolment should then succeed.
7. Exit out of the CMProfile menu by using the following commands:

exit
8. To continue on in CMCC, it needs to be re-connected to the UOC securely, so to achieve that

type the following commands at the CMCC prompt:
Reconnect
- 342 -
9. A pop-up window will be displayed, select the CMCC client certificate that was created and
installed at step 3 of section See"Installing Certificate Manager Configuration Console" on
page 63for more information.
10. The CMCC will reconnect to the UOC but will use TLS security on the connection now, to start
the Enroll IPSec process on the UOC type the following command at the CMCC prompt
Profiles
a. Press <Enter> to choose IPSec
b. Start a new web browser instance and connect to the CA Server:

Note: If you are using Internet Explorer on a Windows Server OS, first ensure the CA site
has been added to your “Trusted Sites”.
c. Select Generate random challenge and click on Submit to RA, the page should then
display the Generated Challenge (also known as a one time password, OTP).
- 343 -
d. Back in the CMCC tool the UOC can now have its IPSec enrolled by typing the following
command at the CMCC prompt: EnrollWithPassword
e. In the CMCC tool revert back to the top level menu by typing the following command at
the CMCC prompt:
Exit
Skip to step 34 for non-redundant UOCs.

Screenshots have been omitted for most steps for Backup UOC as they are identical to
those previously seen for Primary UOC.
f. Exit out of the CMCC tool by using the following command:
Redundant UOCs only:
Exit
11. Redundant UOCs only:

Run the following command:
CertMngrConfigConsole.exe ip:<UOC IP Address> Where <UOC IP Address> is the IP of the
backup UOC you are connecting to.
Open a web browser to the CA Server:
Note: If you are using Internet Explorer on a Windows Server OS, first ensure the CA site has
been added to your “Trusted Sites”.
Next is enrolling the Certificate Manager, to do this at the CMCC prompt type:
CMProfile
This will bring up the CMProfile menu to Enroll the Certificate Manager in the UOC with the CA
Select Generate random challenge and click on Submit to RA, the page should then display
the Generated Challenge (also known as a one time password, OTP).
Back in the CMCC tool the UOC’s Certificate Manager module can be enrolled by typing the
following command at the CMCC prompt type:
EnrollWithPassword
- 344 -
A pop-up window will be displayed, select the CMCC client certificate that was created and
installed at step 3 of section See "Installing Certificate Manager Configuration Console" on
page 63 for more information.
To continue on in CMCC, it needs to re-connected to the UOC securely, so to achieve that type
the following commands at the CMCC prompt to exit from the current menu and then re-
connect:
Exit
Reconnect
The CMCC will reconnect to the UOC but will use TLS security on the connection now, to start
the Enroll IPSec process on the UOC type the following command at the CMCC prompt type:
Profiles
Press <Enter> to choose IPSec.
Start a new web browser instance and connect to the CA Server:
Note: If you are using Internet Explorer on a Windows Server OS, first ensure the CA site has
been added to your “Trusted Sites”.
Select Generate random challenge and click on Submit to RA, the page should then display
the Generated Challenge (also known as a one time password, OTP).
Back in the CMCC tool the UOC can now have its IPSec enrolled by typing the following
command at the CMCC prompt type: EnrollWithPassword
Then exit out of the CMCC tool by using the following commands:
Exit
Exit
Run the following command: CertMngrConfigConsole.exe ip:<UOC IP Address> Where <UOC IP
Address> is the IP of the Primary you are connecting to.
Re-join steps here for single UOC, and continue on for Redundant UOCs:
25. Now enter the following command to enter the IPSec menu at the CMCC prompt:
IPSec
- 345 -
26. Now enter the following command to Edit Policies at the CMCC prompt:
EditPolicies
27. Press Ctrl+Insert to insert a new line into the policies list and press enter to edit the first
column (Local IP).
a. Enter the UOC’s IP address (159.99.79.146 in this example) in the Local IP column and
press enter
b. Move to the right (by pressing right arrow) and press enter again, now enter the PC
accessing the UOC's IP address (159.99.79.148 in this example), press enter.
c. Move to the right (by pressing right arrow) and press enter again, now select the
required policy rule using up and down arrows (encrypt/plain- text/authenticate) in this
example POLICYENCRYPT, then press enter.
28. Use Crtrl+Insert plus steps a-c to add further rules for all IP addresses for primary and backup
controller (in Local IP column), and for each Windows PC (Remote IP column) requiring access
(eg Primary and Backup Server as well as ControlEdge UOC Builder)
29. Use Crtrl+Insert plus steps a-c to add further rules for all IP addresses for primary and backup
controller (in Local IP column) to any EPM (Remote IP column) connected to the UOC,
however create these with a cleartext policy.
30. Then press Esc and then Enter and then Enter again to apply the policies.
31. To exit the tool type the following commands at the CMCC prompt:
Exit
Exit
- 346 -
TIP
Note if using redundant UOCs the policies will be saved and applied automatically at
the backup UOC.
16.8 Configuring IPSec to secure traffic to the UOC

Only when the UOC pair is fully configured, and when the necessary connection rules have been
configured on the Windows nodes, can IPSec be enabled on a UOC.
Establishing secure communications requires the following key steps:
l Manually enabling IPSec on the Primary UOC
l Manually enabling the corresponding connection rules on each Windows node that is
participating in secure communication
There may naturally be some lag in the establishment of secure communications since it is difficult
to execute these two steps simultaneously.
CAUTION
Similarly deactivating IPSec requires the opposite steps to be performed, and unless these
steps are perform simultaneously there may be a loss of communication until both steps are
executed.
16.8.1 Configure and Activate Security Policies

Every communication channel, whether secure (encrypted) or non-secure (cleartext), must be
explicitly configured on the Primary UOC. This includes communication from the UOC to nodes on
the FTE as well as to nodes on the downlink network (e.g. EIP nodes).
Data Sync: This information is entered on the Primary module only as is synchronized to the
Secondary.
16.8.2 Enable IPSec policy on PCs

The content in this section describes rules based on the setup outlined in section See "Obtaining
and Installing the software" for more information., using the device IP addresses.
l CA Server – 192.168.2.2
l Engineering Station (Windows Node 3) – 192.168.10.3, 192.168.11.3
l PlantCruise by Experion Configuration Studio and ControlEdge Builder (Windows Node 5) –
192.168.10.5, 192.168.11.5
l ControlEdge UOC – 192.168.10.6, 192.168.11.6
l C300, C200 – 192.168.10.7, 129.168.11.7
- 347 -
Before proceeding with applying IPSec section ensure that all machines that need to communicate
with the UOC and the UOC itself have installed their certificates and have the CA in their Trusted
Root CA list.
Application of IPSec policy involves laying down a blanket no connection without IPSec rule,
followed by setting a number of exceptions to this rule to control how the various nodes and
devices communicate with and without IPSec.
Use the examples below to formulate your own policies.
CAUTION
The configuration performed in this section should not be performed in an on-process/live
system as you will lose communications to one or all of the nodes in the system as you roll
out this policy, until all nodes have been configured.
To enable IPSec a series of commands must be executed to setup the various policies, these
policies take effect immediately so once the “Default Closed” policy is applied non-IPSec (clear text)
communications to the nodes will be lost, hence it is important that an exception for RDP is made if
the configuration of the nodes is being performed via RDP, otherwise this connection will be lost.
The following set of steps need to be run on all nodes connecting to the UOC, in the example being
used here, these steps would need to be performed on Node 3 and Node 5. Note in all examples
below “endpoint2” should represent the node the rule is being added on, and “endpoint1”, where
specified, is the node that is being remotely connected to/from.
1. Use section 3 to create and install an IPSec certificate for this Windows node
2. Start an Administrative Command prompt
3. Run the following commands to set the main mode parameters on Node 3 & Node 5 only (as
those nodes alone communicate to the UOC).
l netsh advfirewall set global mainmode mmsecmethods ecdhp256:aes128-sha256
l netsh advfirewall set global mainmode mmforcedh yes
l netsh advfirewall consec delete rule name=all
4. To setup the clear text communication exception rules for the control system subnet, using
the example earlier, this system will need to allow Node 4 and Node 5 to connect to Node 3,
and Node 3 and Node 4 to connect to Node 5.
a. When configuring on Node 3 the following commands need to be run, note each point is
a single command:
l netsh advfirewall consec add rule name="Node 4 Exception" description="Node 4 to
this node clear text comms" action=noauthentication
endpoint1="192.168.10.4,192.168.11.4" endpoint2="192.168.10.3,192.168.11.3"
l Further commands similar to these would be run for any other non-IPSec nodes
that need to connect to Node 3, simply modify the values in bold underline to tailor it
for your system.
b. When configuring on Node 5 the following commands need to be run, note each point is
a single command:
this node clear text comms" action=noauthentication"
- 348 -
endpoint1="192.168.10.4,192.168.11.4" endpoint2="192.168.10.5,192.168.11.5
l Further commands similar to these would be run for any other non-IPSec nodes
that need to connect to Node 5, simply modify the values in bold underline to tailor it
for your system.
5. If you are using RDP to connect to the nodes that will communicate with the UOC, then you
will need to create an RDP exception rule (RDP uses TCP port 3389 on the machine being
connected to, i.e. Nodes 3 & 5 below).
a. When configuring on node 3 the following command needs to be run:
l netsh advfirewall consec add rule name="Node 1 RDP Exception" description="Node
1 RDP clear text comms" action=noauthentication endpoint1="192.168.1.1"
endpoint2="192.168.10.3,192.168.11.3" port2="3389" protocol="tcp"
l If there are additional nodes that use RDP to this node, then just create additional
exception rules by modifying the text in bold underline.
b. When configuring on node 5 the following command needs to be run:

l netsh advfirewall consec add rule name="Node 1 RDP Exception" description="Node
1 RDP clear text comms" action=noauthentication endpoint1="192.168.1.1"
endpoint2="192.168.10.5,192.168.11.5" port2="3389" protocol="tcp"
l If there are additional nodes that use RDP to this node, then just create additional
exception rules by modifying the text in bold underline.
6. For Windows PC nodes that will use the CMCC tool to connect to the UOC you will need the
following exceptions to allow CMCC to communicate in clear text to the UOC when IPSec is
enabled, CMCC uses TLS to encrypt this traffic and the UOC has internal rules to not require
IPSec on this connection, so this rule ensures Windows PC nodes do the same. For such
nodes you will need to create an RDP exception rule, take UOC as example:
a. If node 3 uses CMCC the following command needs to be run:
l netsh advfirewall consec add rule name="UOC CM port Exception" description="UOC
CertMngr to this node clear text comms" action=noauthentication
port1="55601,55602" protocol=tcp
l If there are additional UOCs that this node will use CMCC to connect to, then just
create additional exception rules by modifying the text in bold underline.
b. If node 5 uses CMCC the following command needs to be run:

l netsh advfirewall consec add rule name="UOC CM port Exception" description="UOC
CertMngr to this node clear text comms" action=noauthentication
port1="55601,55602" protocol=tcp
l If there are additional UOCs that this node will use CMCC to connect to, then just
create additional exception rules by modifying the text in bold underline.
7. For nodes that use the ControlEdge Builder software, a clear text exception rule needs to be
created for the ControlEdge Builder software to be able to receive multi-cast packets to detect
the presence of a ControlEdge UOC, taking UOC as example:
a. When configuring node 5 the following command needs to be run:
l netsh advfirewall consec add rule name="ControlEdge UOC Discovery Exception"
description="ControlEdge UOC discovery port exception" action=noauthentication
endpoint1="any" endpoint2="192.168.10.5,192.168.11.5" port1="24558" protocol=udp
l Note: the value of port1 specifies the multicast address port that the packets are
received from, this is fixed port for all ControlEdge UOCs.
- 349 -
8. To apply IPSec encryption to the nodes communicating with the UOC, then the following IPSec
rules need to be applied, takeing UOC as example:
a. When configuring on node 3 the following command needs to be run
l netsh advfirewall consec add rule name="UOC Encryption" description="PC to UOC
encrypted comms" action=requireinrequireout auth1=computercertecdsap256
auth1ecdsap256ca="<CA Cert SubjectName>" qmsecmethods=ESP:aesgcm128-
aesgcm128
l For any additional UOCs this PC needs to connect, update the items in bold
underline and run for each UOC.
l The <CA Cert SubjectName> is the string in the Subject field of the CA certificate,
with items in reverse order eg "C=US, O=Honeywell, CN=AS01HSCCASRV" or based
on CA created in section See "Creating the Certificate Authority" onpage 48 for more
information. simply "CN=AS01HSCCASRV-CA"
l If you have redundant UOCs you will need to either make a second version of this
rule, or add the Backup UOC’s IP addresses into the endpoint1 parameter,
separating them by commas.
b. When configuring on node 5 the following command needs to be run

l netsh advfirewall consec add rule name="UOC Encryption" description="PC to UOC
encrypted comms" action=requireinrequireout auth1=computercertecdsap256
auth1ecdsap256ca="<CA Cert SubjectName>" qmsecmethods=ESP:aesgcm128-
aesgcm128
l For any additional UOCs this PC needs to connect, update the items in bold
underline and run for each UOC.
l The <CA Cert SubjectName> is the string in the Subject field of the CA certificate,
with items in reverse order eg "C=US, O=Honeywell, CN=AS01HSCCASRV" or based
on CA created in section See "Creating the Certificate Authority" onpage 48 for more
information. simply "CN=AS01HSCCASRV-CA"
l If you have redundant UOCs you will need to either make a second version of this
rule, or add the Backup UOC’s IP addresses into the endpoint1 parameter,
separating them by commas.
9. For nodes that use the SNTP servere, a clear text exception rule needs to be created for the
ControlEdge Builder software to be able to receive multi-cast packets to synchronize with the
SNTP server:
When configuring node 6, the following command needs to be run:
netsh advfirewall consec add rule name="SNTP Server Exception" description="SNTP Server
port exception" action=noauthentication endpoint1="any" endpoint2="192.168.10.8"
port1="123" protocol=udp
To ease enabling of IPSec policy on Windows nodes, it is worth creating a batch file per Windows
node, enableIPSec.bat, and storing all the required netsh commands in this file, this will make it
easier to add new rules as new nodes are introduced to your system. It also allows you to backup
your Windows node IPSec rules configuration by just taking a copy of this file. You will need a
separate instance of this batch file for each machine.
CAUTION
Although the rules above will appear in the Windows Advanced Firewall console under
Connection Security, do not use that console to modify these rules as some of the settings in
these rules are not supported by the console and may result in the rules being inadvertently
modified to an unusable state.
- 350 -
CAUTION
Although not required it is advisable to leave the CA running during process operation. If not
there can be seconds delay while secure connections are established, even during
controller switchover. To reduce any such delays during switchover the CA should remain
network-connected and operational at all times.
16.8.3 Disable IPSec policy on Engineering Station/Console
NOTE
In Server, Experion PKS Policy Agent and Experion policy Decision Point, and in console,
Experion PKS policy agent, must be disabled so that the configured rules will not be erased
form the windows node.
1. Start an Administrative Command prompt

2. Run the following command to clear the IPSec rules
netsh advfirewall consec delete rule name=all
Like with enabling IPSec on a Windows node, for disabling it is worth creating a batch file per
Windows node, disableIPSec.bat, and storing the command above in it, as remembering to type
“disableIPSec” to disable IPSec will be easier than the command above. Given there is no machine
specific data in this batch file, a single disableIPSec.bat can be copied and used on multiple nodes.
16.8.4 Enable IPSec policy rules in the UOC

Before enabling IPSec policy rules in the UOC ensure:
l The system is not currently on process
l That all Experion nodes connected to the UOC and all other devices using IPSec to the UOC are
completely configured to use an IPSec Encrypted policy
TIP
If using redundant UOCs when IPSec is enabled on the primary UOC, this change will be
replicated to the backup UOC and hence IPSec does not need to be manually enabled on
the backup UOC.
1. Connect the CMCC tool to the UOC with the following command:
CertMngrConfigConsole.exe ip:<UOC IP address>
Where <UOC IP address> is the IP address of the UOC (Primary UOC if using redundant UOCs)
- 351 -
2. Confirm the certificate to use for CMCC by clicking OK
3. At the top menu enter the following command to enter the IPSec menu
IPSec
4. Ensure the current IPSec state is Disabled then type the following command to enable IPSec
at the CMCC prompt type:
Enable
Exit
- 352 -
Exit
16.8.5 Disable IPSec policy rules in the UOC

Before disabling IPSec policy rules in the UOC ensure:
l The system is not currently on process
l That all PCs connected to the UOC and all other devices using IPSec to the UOC are configured
to use IPSec policies to this device set to Cleartext.
1. Connect the CMCC tool to the UOC with the following command:
CertMngrConfigConsole.exe ip:<UOC IP address> Where <UOC IP address> is the IP address of
the UOC (Primary UOC if using redundant UOCs)
2. Confirm the certificate to use for CMM by clicking OK
3. At the top menu enter the following command to enter the IPSec menu
IPSec
- 353 -
4. Ensure the current IPSec state is Enabled then type the following command to enable IPSec
at the CMCC prompt
Disable
Exit
Exit
- 354 -
16.9 Backup and Restore of CA
16.9.1 Backup
1. On the CA Server start up a management console (mmc.exe) accepting a User account control
prompt or providing appropriate credentials if shown.
2. From the File menu choose Add/Remove Snap-in
- 355 -
3. In the left column choose Certification Authority and click Add, then ensure Local Computer is
selected and click Finish and then OK
- 356 -
4. In the left hand pane expand Certification Authority (Local) and then right click on your CA
and choose All Tasks and then Back up CA…
5. At the Welcome to the Certification Authority Backup Wizard dialog click Next
- 357 -
6. Ensure that you enable both the Private key and CA certificate as well as the Certificate
database and certificate database log items, then choose a directory to back up to (if it does not
exist you will be prompted to confirm the creation of it) and click Next
- 358 -
7. Enter and confirm a password to protect the CA’s private key and then click Next
8. Finally confirm the settings and click Finish
- 359 -
9. Then to confirm that the backup has occurred use Windows Explorer to navigate to the folder
you specified in step 6 and check that files have been output to that location.
The CA has now been backed up to the location specified, please ensure this location is included in
any backup jobs, or copy the directory and all its contents to a backup location. You should also
backup the folder where you store certificates created for CMCC, TLS and IPSec created. See
"Creating a certificate" for more information.
- 360 -
16.9.2 Restore
1. On the CA Server start up a management console (mmc.exe) accepting a User account control
prompt or providing appropriate credentials if shown.
2. From the File menu choose Add/Remove Snap-in
- 361 -
3. In the left column choose Certification Authority and click Add, then ensure Local Computer is
selected and click Finish and then OK
- 362 -
4. In the left hand pane expand Certification Authority (Local) and then right click on your CA
and choose All Tasks and then Restore CA
5. If the CA is running a prompt will be shown to confirm that it will be stopped, if shown click OK
6. At the Welcome to the Certification Authority Restore Wizard click Next
- 363 -
7. Enable the options Private key and CA certificate and Certificate database and certificate
database log and set a directory to restore the CA from, then click Next
8. At the Provide Password dialog enter the password that was used at step 7 of See "Backup" for
more information.and click Next
- 364 -
9. Finally confirm the settings and click Finish
10. Once the restore is complete click Yes to restart the CA.
The CA Server has now been restored to have the state from the time of the backup used.
16.10 Renewal and revocation of certificates

If the CA Server is installed via the scripts described in this chapter then the certificates generated
by it for TLS, CMCC and IPSec will all be valid for 20 years or the remaining life of the CA root
certificate, whichever is lower.
16.10.1 CA Root certificate

Based on the install scripts in this chapter the CA root certificate will be valid for 50 years.
- 365 -
16.10.2 Renewing the CA Root certificate

1. Start the Certificate Management console on the CA Server and in the left pane navigate to
your Certification Authority.
2. Right click on the CA and choose All Tasks and then Renew CA Certificate.
3. At the Install CA Certificate dialog click Yes to stop the Active Directory Certificate Services
- 366 -
4. At the Renew CA Certificate dialog box, choose No to re-use the existing CA keys and click OK
5. The Root certificate will then be renewed and the Active Directory Certificate Services
restarted.
16.10.3 PC certificates
Renewal
To renew the CMCC and IPSec certificates, See "Creating a certificate for a Windows node" for
more information. to issue and install new certificates for each type for the PC requiring them.
Once the new certificate has been installed, you can optionally delete the old certificate by right
clicking on it and then clicking Delete, and answering any prompts requiring confirmation. If the
old certificate was in use deleting it will force the connection to re-negotiate its encryption with the
new certificate. Optionally, you could also revoke the certificate at the CA Server once you’ve
deleted it from the PC using it.
16.10.4 Revocation
If you need to revoke a PCs CMCC or IPSec certificate then:
- 367 -
1. Start the Certificate Management console on the CA Server and in the left pane navigate to
your Certification Authority.
2. Then navigate to Issued Certificates and in the middle pane look for the certificate you wish to
revoke.
Some tips to help find the correct certificate:
a. The Issued Common Name column will contain the name of the computer the certificate
was created for
b. If you open a certificate and go to Details tab:
i. A CMCC certificate will:
l Have the computer name as the CN value in the Subject field
l Have an Enhanced Key Usage field with value Client Authentication,
l Have a Key Usage field with value Digital Signature
ii. A TLS certificate will:

i. Have the computer name as the CN value in the Subject field
ii. Have an Enhanced Key Usage field with value Server Authentication,
iii. Have a Key Usage field with value Digital Signature
iii. An IPSec certificate will:
i. Have the computer name as the CN value in the Subject field
ii. NOT have an Enhanced Key Usage field at all
iii. Have a Key Usage field with values Digital Signature and Key Agreement.
- 368 -
3. Right click on the certificate and choose All Tasks and then Revoke Certificate
4. From the Certificate Revocation dialog choose an appropriate Reason code and then specify
the time to revoke the certificate from, note it defaults to the current time.
- 369 -
5. Then click Yes to revoke the certificate, this will revoke the certificate and you should now see
the certificate listed in the Revoked Certificates list for the CA.
16.10.5 UOC certificates

Renewal
The Certificate Manager built-in to the UOC will check the lifetime of its certificate at least once
every 7 days, and if the CA is available to communicate with it will automatically renew the
certificate with its CA within 90 days of its expiry.
The CMCC tool also provides a manual method to renew the certificate if the CA is not always
available, use the “Renew” item on the “CMProfiles” and “Profiles” menus.
16.10.6 Revocation
If the UOC certificate is revoked in the CA it will continue to work until the nodes it is connecting to
receive an updated CRL from the CA Server, typically this would be within 48 hours of the
certificate being revoked at the CA.
The Certificate Manager on the UOC will retrieve the Certificate Revocation List (CRL) from the CA
once every 24 hours if the CA is available. The CA will publish a full CRL once every 30 days and a
delta CRL every day, the CRL is then valid for up to 30 days past the CRL publish period by the CA
Server (30 days publish + 30 days overlap = 60 days CRL validity)
e.g. if the CA Server publishes a CRL on September 1, and then its next CRL on October 1, if the
UOC retrieves the CRL during September this CRL would remain valid until October 31 (30 days
after October CRL is published, or 60 days after September CRL was published).
16.11 Troubleshooting
This section provides guidance and background information about the causes and remedies for
failures which may occur in the UOC controller. The following topics are presented here.
16.11.1 How to reset UOC for IPSec configuration?

Connect the CMCC tool to your UOC
- 370 -
From the top level menu type “ResetToDefault” to reset the Certificate Manager in the UOC, this
will reset only the IPSec functionality in theUOC, then See "Setup certificates and IPSec policy in
UOC" for more information. and See "Enable IPSec policy rules in the UOC" for more information.to
setup and enable IPSec in the UOC again.
16.11.2 How to reset IPSec configuration on Windows?

See "Disable IPSec policy on PCs" for more information. to disable and then See "Enable IPSec
policy on PCs" for more information.to configure IPSec on Windows.
16.11.3 Diagnosing IPSec with Network Analysis Software

Network traffic analysis software, such as WireShark, can be used to help determine whether
IPSec is being used for communication between the Windows nodes and UOC. If running this
software on the Engineering Station you would set a filter for the UOCs IP address and view traffic
to/from that node.
l If clear text is in use you will see packets marked as “OPCUA” and “TCP” amongst several
packet types between the PC and UOC,
l If an IPSec session is being established you will see some packets marked with “ISAKMP” as
the IPSec connection is established,
l And once IPSec communications has been established ALL packets should be marked as
“ESP”.
16.11.4 If CMCC upload a large number of policies, the read data from
the transport connection can not be received
The default time out value in CMCC are not sufficient for ControlEdge UOC to handle all of the
policies.
Workround:
1. Start a Command Prompt and change to the Certificate Manager Configuration Console
(CMCC) folder with the following command (or similar): cd
\CertMgmt\CertManagerConfigConsole
2. Run the following command: CertMngrConfigConsole.exe ip:<CMCCtimeout
catimeout:CMCCtimeout> <UOC IP Address>
3. Where <UOC IP Address> is the IP of the UOC, or the Primary UOC if
4. using redundant UOCs, you are connecting to and CMCCtimeout is the timeout for the
policies.
- 371 -
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:
hpsdocs@honeywell.com
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
- 372 -
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.
- 373 -

UOC UserGuide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UOC UserGuide

Uploaded by

Copyright:

Available Formats

EXPERION PKS

UOC User Guide

Copyright 2020 - Honeywell International Sàrl

4.2.4 Upgrading UOC UIOM to new Firmware Version 50

5.6.2 Method 2: Using the Project Assignment Panel 53

5.7 UOC Platform Block 54

5.11 Configure ControlNet for UOC 103

5.15 Convert a redundant UOC to a non-redundant controller 107

5.16.2 Composite Device Point(s) License 108

Chapter 6 - Load Configuration 110

6.2 Initial load order guidelines 112

6.3 Load components from Project 113

6.3.2 Loading CEE 115

6.4 Load With Contents command 117

7.2 UOC Configuration 121

7.3.5 I/OM Status Summary 125

7.4 I/O Rack (EPM) 126

7.4.4 Soft Failures and Alarms 127

7.5 I/O Module 128

7.6 Channel 130

7.7 I/O Module Configuration 139

7.7.6 CE900 DI32-24VDC Module Configuration/Monitoring Tabs 149

7.7.8 CE900 DI16-VAC Module Configuration/Monitoring Tabs 153

7.7.12 CE900 AO04 Module Configuration/Monitoring Tabs 160

7.7.15 CE900 DI16-VACDC Module Configuration/Monitoring Tabs 166

Chapter 8 - EtherNet/IP Device Connectivity 170

8.1.6 Assigning EtherNet/IP devices to the CEE 181

8.2 Configuration Parameters for arrayed custom parameters 182

8.5 UOC and ControlLogix integration 189

9.2 Partner controller compatibility 191

9.3 UOC 1-slot I/O rack 194

9.4.4 Auto-Synchronization State - RDNAUTOSYNC 195

9.4.7 Maximum Initial Synchronization Time - RDNISTIMEMAX 198

9.4.10 Redundancy Traffic Rate 198

9.5 Switchover and secondary readiness 199

9.6 Redundancy history 202

10.3 UOC Startup 212

10.4 Using Station displays 214

10.4.7 UIO Racks 228

Chapter 11 - Troubleshooting 230

11.3.2 Using Firmware Manager to capture diagnostic data 231

11.4 Fixing common problems 232

11.4.4 One or both FTE LEDs are OFF 234

11.5 UOC Controller soft failures 239

11.7 Online diagnostics 245

11.8.6 Communications Failure 250

11.9 Communications and system time faults during startup 250

11.10 Gathering information for reporting problems to

13.1.4 Network Downlink I/O Topology 263

13.2 Guidelines for integration of virtual controllers 264

13.4 Defining Port Groups 272

13.5 Physical network support for VLAN topologies 276

13.6 Download 282

13.8 vUOC Provisioning (first-time start up only) 290

Chapter 14 - Performance and Capacity Considerations 300

14.2.5 Redundancy Throughput 305

Chapter 15 - Security Guidelines for UOC 306

16.2 Obtaining and Installing the software 314

16.7 Configure ControlEdge UOC for use with IPSec 329

16.8 Configuring IPSec to secure traffic to the UOC 347

16.8.2 Enable IPSec policy on PCs 347

16.8.5 Disable IPSec policy rules in the UOC 353

16.9 Backup and Restore of CA 355