stefan secker, honeywell process solutions best …. 2012 honeywell users group americas 1 stefan...
TRANSCRIPT
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