Sustain.Ability.

2012 Honeywell Users Group Americas

1

Stefan Secker, Honeywell Process Solutions

Best Practices for Deployment of CPM, Loop

Management Solution

2

2

What is Control Performance Monitor (CPM)?

• CPM is an application to monitor the performance of

regulatory assets

– PID, APC

– Instruments, Analyzers

• DCS and APC vendor-independent

• Runs in the background automatically on periodic basis

• Calculates metrics (KPIs) from historical process data

per asset that allow for a performance rating

3

3

CPM Reporting Features

• Web portal based visualization of control asset

performance

o Drill down plant hierarchy

o Sort, filter and prioritize control assets

o Trend and track their control performance

• Automated notification of impending control

issues

o Customizable workflow integration

o Automated email notification

o Disposition escalation mechanism

VIS

UA

LIZ

E

IDE

NT

IFY

4

4

Business Value

1.5%

0.8%

1.4%

0.5%

Ref: Brisk et al (2004) Scale

Complexity & Cost

1

1500

15

~10.000 $

~100.000 $

5

5

Value of Reduced Variability

• Can increase product quality and throughput

• Optimal operation point can reduce energy consumption and

maintenance cost

thro

ughput

time

Current Performance

Optimal Performance

Process Constraint

$

Identify Variability

Reduce Variability

Move Target

Monitor & Sustain

6

6

Turn Data Into Knowledge

PV, SP, OP, MODE

Controller is oscillating

Off-spec performance

83.20

83.25

83.30

83.35

83.40

83.45

83.50

83.55

83.60

83.65

83.70

83.75

0 250 500 750 1000 1250 1500 1750 2000

Raw Data Graph for DataSource1

Value

Sample Number

SP PV

7

7

Typical CPM Project

• Typical Scale Example

– 1-3 Plants

– 1-3 DCS

– 500-1500 Loops

– 5-25 Users

• Typical Infrastructure

– 1 CPM server

• Includes data collector

• OPC DA Interface to DCS OPC Server

• Typical Implementation Time

– 2-4 weeks

8

8

A Case Study - Enterprise Wide Deployment

Scope

• Integration of Alarm Management and Loop Management

• Combination of continuous and batch process operations

• Need to publish KPI at the enterprise level

• Inclusion of overall system health monitoring

9

9

Enterprise Wide Deployment

• Large Scale Site

– ~150 Plants

– ~200 DCS

– ~55 000 Loops

– 500+ Users

• Selected Infrastructure

– 20 CPM Servers

– 20 virtual data collection servers

• OPC DA Interface to PIMS

– 2 redundant Enterprise Servers

• Project Schedule

– 18 Month

CPM Server (1)

Control Performance Monitor

Operational Insight

CPM Server (1)

Control Performance Monitor

Operational Insight

CPM Server (1)

Control Performance Monitor

Operational Insight

CPM Server (n)

Control Performance Monitor

Operational Insight

IP.21 PI

DCS

PIMS PIMS PIMS

DCS DCS

PHD

ESX host (1)

OPC Desktop

Historian

OPC Desktop

Historian

OPC Desktop

Historian

CPM Server (1)

Control Performance Monitor

Operational Insight

CPM Server (1)

Control Performance Monitor

Operational Insight

CPM Server (1)

Control Performance Monitor

Operational Insight

CPM Server (1)

Control Performance Monitor

Operational Insight

OPC Desktop

Historian

OPC Desktop

Historian

OPC Desktop

Historian

OPC Desktop

Historian

OPC Desktop

Historian

ESX host (n)

CPM Enterprise

Control Performance

Monitor

Operational Insight

2KPI SYNCHRONIZATION

OPC HDA

Firewall

... ...

... ...

OPC DA 1MTK TRANSFER

Custimization needed using

PI SDK / API

Custimization needed using

synchronization service

Domain Controller

Active Directory

LDAP

10

10

Project Challenges And Solutions (1)

• Need for configuration work necessary for

– Control Performance Monitor / TaiJiPID Tuning / Alarm Manager

– OPC Desktop Historian / OPC Servers

– Users/Groups and Access Rights

Creation of configuration automation tools to speed up

deployment process significantly

• Number of interfaces to be connected to:

– Alarm & Event input streams

– Real time process data

Reduce interface types to standardized ones

– Process Data: OPC DA (from PIMS systems)

– Event Data: OPC A&E, TXT

11

11

Project Challenges And Solutions (2)

• CPM/AM System to represent the “real” asset hierarchy

– No plant-specific asset hierarchy

– One master for the full system

Creation of interface to SAP

– Online hierarchy synchronization with SAP

• Central store of CPM/AM configuration

– Distributed system, but central store

– Support for workflow process between client and Honeywell

personnel

Creation of “Deployment Database” and UI to store

– Hierarchy, CPM and AM configuration

– User and access rights management

12

12

Deployment Database Principle

PIMS Configuration

Deployment DB

Control Performance Monitor

OPC Server Configuraton

OPC Client Configuraton

Groups & Users Access Permissions

User / Override Configuration

DCS Configuration

Alarm Manager

System Health Monitor

Asset Hierarchy

13

13

Project Challenges And Solutions (3)

• Batch plants to be monitored

– Typical batch parameters (e.g., product name, batch number,

run time) to be included in the analysis

Development of CPM for Batch extension

– Asynchronous execution of analysis triggered by batch end

– Batch start / end detection by PIMS tag or proprietary Batch

Interface

• User Management in MS Active Directory

– Single configuration location for client to manage user access

Creation AD Reader / Profile Manager services

– Create Groups / Users and access rights on distributed

system in various products

– Synchronize all configuration against AD changes

14

14

Project Challenges And Solutions (4)

• Interface to MES System

– Expose CPM/AM KPIs to MES layer via HTTP/SOAP

Creation of KPI Web Service

– Distributed system to read from source servers

– Buffer on separate server to serve high-resolution

short-time queries

• Health monitoring of complex distributed system

– Various components to monitor for each product and server

Use of System Health Monitor

– Distribute application doing local checks

– Root of application creates event in Alarm Manager

– Reporting of issues in Alarm Manager and per email notification

15

15

System Health Monitor Principle

• Distributed over systems /

machines involved in

overall infrastructure – Each machine hosts one

SHM instance

• Central storage of check

results as alarms in

Alarm Manager – Root instance of SHM sends

data to A&E Collector via TCP

– Leverages all AM reporting

functionality

– Can make use of emergency

notification and escalation methods

(Notification Manager)

System Health Monitor

Enterprise Server

Enterprise DB

AM/CPM Server 1

PIMS Server

AlarmManager

DB

Interfaces

AM/CPM Server n

TCP

single port TCP

single port

TCP

single port

TCP

single port

TCP

single port

TCP

single port

PIMS Server

Interfaces

16

16

Project Challenges And Solutions (5)

• Reporting on enterprise level (distributed large scale

systems)

– How to display data of a distributed system in one report?

– Where to find detailed data on a distributed system?

Creation of Enterprise KPI Server

– Management level reporting (using “CPM report engine”)

– Central point of entry for all individual “plant” servers

– KPIs of various source systems in one view

– Redundancy through load balancing of two identical servers

17

17

Enterprise KPI Server Principle

Site A

User A

Site C

User C Site B

User B

HQ Aggregated results are

transferred to central

instance periodically

Data is aggregated

locally for hierarchy

assets

Data is aggregated

locally for hierarchy

assets

18

18

Reporting Examples (1) Enterprise Hierarchy

• Enterprise hierarchy

contains only high level

views

• Reports are aggregates on

available levels

• On click of lowest level in

the enterprise hierarchy,

users are routed to local

server

19

19

Reporting Samples (2) 7d Roll Up Table

CPM KPIs AM KPIs

20

20

Reporting Samples (3) 7d Tree Map

21

21

On-going Support Needs

• Product and Application Specific Support

– Clear Definition

– Training for continuity in support resources

• Tiered Support Model

– Shared responsibilities between Honeywell and Client teams

• Regular review of support

– Quarterly report

– Bi-annual meetings of application owners

• Extended support

– Monthly health check service

– Identification of application improvement

22

22

Lessons Learned (1) Configuration Standard!

• A defined standard for a CPM configuration reduces effort for

– Setting up a new system

– Changing configuration of an existing CPM system

– Training personnel to use and administer the CPM system

– Identifying a problem in case a CPM system doesn„t work properly

– Maintaining a CPM system

• But...

– Keeping to a standard manually demands a stern discipline

– Might make configuration more complex for individuals at first sight

• Automation based on defined standards and central store

– Speeds up deployment

– Allows for easier maintenance

23

23

Lessons Learned (2) = Best Practices

• Dedicated historian for process data reading from PIMS systems

– Seamless integration into existing infrastructure

– Prevent archive overload of existing PIMS systems

• Integration into customer workflow

– Mandatory to leverage CPM„s findings

• Health checks and support

– Online monitoring of system health essential

– Support needs to be appropriate to system size

• CPM is no magic bullet

– A tool does not replace engineering knowledge

– It complements it and eliminates menial tasks

24

24

Question & Answer

25

25

Thank You