Print this article

Comment

01 July 2004

Working from within

Benefits of a performance assessment solution embedded to a field device.

By Pasi Airikka, Pasi Heikkinen, Ismo Niemelä, and Oliver Jenkins

Only by consistent and systematic monitoring is it possible to obtain confidential information about the target process. Users especially monitor process control with low-level control loops to maintain an adequate level of control performance. Online performance monitoring and diagnostics could improve control performance in general, especially when more sophisticated high-level control procedures such as model predictive or fuzzy controllers use low-level controllers (PID controllers) as slaves to fulfill their commands.

Foundation fieldbus (FF) is a fieldbus standard amongst many others, but it is a powerful technology providing the means to distribute computational intelligence into field devices. Consequently, it is possible to design and implement manufacturer-specific blocks into the FF field devices. Engineers were able to design and implement a control performance monitor (CPM) block into a field device to monitor and diagnose performance of proportional, integral, derivative (PID) control loops. CPM became a manufacturer-specific function block. The implemented device description makes CPM compatible with all distributed control systems (DCSs) that work with FF.

There are several arguments regarding implementing process control in the field instead of having a centralized controller. Actually, it is not a new idea to put control in the field. At the time of pneumatics control, single-loop controllers were in the field, but the era of computer control moved them to the control room. Arguments for distributing low-level controls to the field are improved reliability, reduced complexity, increased flexibility, and decreased traffic.

During the past two decades, several different methods focused on control loop oscillation detection or general control performance evaluation. These methods use the control error and control signal of the control loop. The CPM block contains several different methods for detecting different kinds of phenomena in a control loop, such as loop oscillation, control saturation, and excessive noise and actuator wear. The primary aim is to detect online control loop performance degradation as well as to diagnose control loops by preserving performance history. The data source is the PID controller function block with its signal and status information.

There are several benefits to having the performance assessment solution embedded in a field device.

Firstly, it guarantees a high availability of control performance assessment. There is no need for external software, licenses, and databases (except for displaying information). Secondly, control performance assessment starts to operate as soon as the field device with the PID controller is ready and in use. Thirdly, no maintenance is required after the field device itself is intact and functioning.

CPM on an FF field device provides PID control loop performance assessment through monitoring and diagnostics. Monitoring comes from calculated performance measures, whereas diagnostics relies on monitoring history. In addition, PID controller mode, parameter history log, and signal statistics with signal distribution charts also provided by CPM facilitate performance assessment and control maintenance.

CPM provides a set of performance monitoring measures for online monitoring. These relative measures are performance indexes, and they mainly normalize into the range of 0–100% for easy reading and interpretation. The performance indexes provide real-time information about PID control loop performance. CPM also provides a set of performance monitors for online monitoring.

The monitors announce control loop problems, and therefore they are binary flags with a value of either zero or one. If the monitor value is one, then the corresponding control problem is valid.

Performance indexes

• Control performance index: The control performance index is a relative performance measure (0–100%) of the control loop performance level. The higher the index is, the better the control. This index can rank troublesome control loops to detect bottlenecks.
• Oscillation index: The oscillation index (0–100%) is a relative measure for indicating how oscillatory the control loop is. The higher the oscillation index is, the worse the situation. When the oscillation index is 100%, then the corresponding oscillation monitor value is set to one.
• Saturation index: The saturation index (0–100%) is a relative measure for indicating how frequently the control loop suffers from control saturation. The higher the saturation index is, the worse the situation. When the saturation index is 100%, then the corresponding saturation monitor value is set to one.
• Noise index: The noise index (0–100%) is a relative measure for indicating how noisy the control loop is. The higher the noise index is, the worse the situation. When the noise index is 100%, then the corresponding noise monitor value is set to one.
• Control error: Control error (–100–100% of process variable range) is an error between the targeted control loop set point and the process variable. In its simplicity, the control error may be an effective indicator of control loop success. For integrating control (PI or PID), the control error should be zero mean. When control error exceeds its predefined lower or higher limit, then the corresponding monitor value is set to one.
• Variability control: Variability (0–100% of process variable range) is a relative measure of control loop variability. The higher the variability, the worse the control loop performance is. When variability exceeds its predefined limit, then the corresponding monitor value is set to one.
• Control utility index: The control utility index (0–100%) is a measure of how frequently the control loop has been in automatic mode (automatic, cascade, or remote cascade). The lower the control utility index is, the more often the control loop has been in manual. When the control utility index is 100%, then the corresponding monitor value is set to one.
• Mode compatibility index: The mode compatibility index (0–100%) is a measure for comparing the targeted and the actual mode of the PID controller function block. The mode compatibility index is a measure of how frequently these two modes are not equal. The higher the index is, the more they differ from each other.
• Actuator wear indexes: Actuator wear indexes (control travel and control reversal, 0–100%) are measures for actuator (or valve) wear. The higher the index, the higher actuator wear is. High actuator wear decreases the device lifetime and deteriorates its performance.

CPM function block shown through an FF configuration tool by listing the parameters for performance monitoring.

Monitors

• Oscillation monitor: The oscillation monitor (0/1) announces the existence of detected oscillation. If the oscillation monitor value equals one, then it detects oscillation and a corresponding alert goes out. Also, it will publish the detected oscillation amplitude and period.
• Saturation monitor: The saturation monitor (0/1) announces detected control saturation. If the saturation monitor value equals one, then it detects saturation and sends out a corresponding alert.
• Noise monitor: The noise monitor (0/1) announces the existence of detected excessive noise in the control loop. If the noise monitor value equals one, then it detects excessive noise and publishes a corresponding alert.
• Control error monitor: The control error monitor (0/1) announces a detected control error limit violation. If the control error monitor value equals one, then it detects a control error limit violation and publishes a corresponding alert.
• Variability monitor: The variability monitor (0/1) announces detected excessive control variability. If the variability monitor value equals one, then it detects excessive variability and sends out a corresponding alert.
• Control utility monitor: The control utility monitor (0/1) announces the existence of low control utility degree. If the control utility monitor value equals one, then it detects low control utility degree and publishes a corresponding alert.
• Mode compatibility monitor: The mode compatibility monitor (0/1) announces the existence of PID controller mode incompatibility between its targeted and actual mode. If the mode compatibility monitor value equals one, then it publishes a corresponding alert.

Control performance alerts are textual announcements of detected control loop problems. Whenever any of the performance monitors are on, then a CPM function block publishes a corresponding control performance alert. The alert informs users about the specific control loop problem and can give additional information about the quality and the magnitude of the process control problem.

CPM is capable of storing control performance indexes for a whole device lifetime. Performance history is stored into the field device as averaged values with a time stamp. The performance history covers the present value of each performance index, their daily averages from the last full month, their monthly averages from the last full year, and annual averages all the way back to the device start-up, thus covering the device lifetime.

The PID controller has scalar parameters and modes that a user can alter. To track these changes, CPM provides a log for PID controller parameter changes and another log for PID controller mode changes. The parameter log maintains a list of PID controller gain, reset, and rate changes with a time stamp. In addition, it records feedforward gain and process variable filtering and derivation gain limit changes. The mode log maintains a list of PID controller actual mode changes (e.g., manual, automatic, cascade, remote cascade, local override), external signal tracking (on/off), and controller bypass (on/off) with a time stamp.

CPM has parameters for retaining process control loop signal statistics. Loop signal statistics contain statistical information about process variables and control signals. For each signal, the (exponentially weighted moving) average and variance undergo calculation and then update at every control period. Also, the device calculates the average control error. The signal distributions for process variable, control signal, and control error update using a histogram presentation. Each distribution has a signal range as its horizontal axis, and each vertical bar in the histogram presents the relative share of the signal values gaining that specific value.

Fieldbus connections

Foundation fieldbus is an all-digital, serial, two-way, digital communication protocol and a programming language. FF covers two networks: host-level network high-speed Ethernet (HSE) and device-level network H1. H1 interconnects field devices such as sensors, actuators, and I/O by providing 31.25-kilobits-per-second data transfer capability. HSE integrates high-speed controllers (e.g., PLCs), H1 subsystems (via linking devices), data servers, and workstations.

Foundation fieldbus has the built-in capability to distribute the control application across the network. FF increases communication capabilities between the system and the devices, reduces wiring and wire terminations due to multiple devices on one wire, increases selection of device vendor suppliers due to interoperability, reduces loading on control room equipment due to distribution of control and I/O functions to field devices, and lastly, connects larger systems to the HSE backbone.

FF uses resource and transducer blocks to configure devices and standard function blocks to implement the control strategy. The function blocks are standardized automation functions. The control system has functions such as analog input, analog output, and PID. Control may occur through the field device itself instead of through the centralized controller in the DCS. Function blocks allow distribution of automation functions in field devices from different manufactures and vendors in an integrated manner. Distribution of control into the field devices can reduce the amount of I/O and control equipment needed, including cabinets and power supplies. Consequences of system failure become limited when automation functions are in the field.

From a functionality point of view, the function blocks have four subclasses: input, output, calculation, and control. Input and output blocks deal with measuring and actuating functions; calculation blocks cover mathematical operations; and control blocks deal with process control such as PID control. Another function block categorization method arises from a specification point of view: standard blocks, enhanced blocks, manufacturer-specific blocks, and flexible function blocks. In this case, the concept of block must broaden to cover transducer blocks as well. Standard blocks are blocks with prefixed standardized functionality. Enhanced blocks are standard blocks with some additional features added by the device manufacturer.

Manufacturer-specific blocks are custom blocks created by the device manufacturer, and these blocks have only a few mandatory parameters specified by the FF standards.

Manufacturer-specific blocks enable the device manufacturer to increase device intelligence by adding more functionality to the device. The functionality can be device condition monitoring, device diagnostics, or control loop performance monitoring and diagnostics. A digital valve controller is an example of a field device containing a manufacturer-specific block. The digital valve controller contains a standard function block analog output, a resource block, and an enhanced PID controller function block (predictive PID), but it also has a manufacturer-specific transducer block especially developed for device diagnostics.

CPM function blocks can reside either in an actuating device or in a transmitting device as long as the same device has a PID controller function block that is responsible for controlling the process. If the operating PID controller is located either in the central controller (in a DCS) or in another field device not having CPM functionality, then CPM cannot be used.

Field devices assessment

CPM function blocks were designed, developed, and implemented in a digital valve controller ND9000F supporting Foundation fieldbus technology.

There are prerequisites for a CPM function block to operate and to monitor a control loop:

• CPM and PID control function blocks must reside in the same field device
• PID controller (in the field device) is operating
• CPM function block is in auto mode

A CPM function block has two block modes: auto and out of service. When CPM is in out-of-service mode, it stops running. In auto mode, CPM starts to monitor the process control loop. If any of the control loop signal comes equipped with a bad status or the PID controller's actual mode is manual, then the CPM function block provides limited control performance information.

CPM has a high availability because it has predetermined configuration parameters. As soon as the network and devices with control strategy have configured, CPM is automatically available. CPM has a few configuration parameters for control performance indexes such as limits for control error and variability and minimum amplitude of oscillation to be detected; however, these limit values have default values to start with. In addition, CPM provides a procedure for estimating appropriate configuration limits on a user's request when needed.

Case in point

In a simulated case, a PI controller controls a self-regulating process having slow dynamics. It monitors the control loop for thirty days, during which it suffers from external process disturbances, static friction in the control valve, and mode (automatic versus manual) and set point changes.

Studying the control utility trend reveals the control loop was in automatic for most of the month until five days ago, when it was set in manual. It seems that in that day the control loop was out of control for more than twelve hours. Examination of the control reversal trend does not reveal any change in control signal activity, as it has been at a rather steady level for the whole month. The decline of the control reversal level that occurred five days ago is a consequence of the PID controller being in manual. Looking at the oscillation trend clearly reveals the control loop suffered from process variable oscillation starting a week ago. Oscillation forced the controller into manual, and oscillation did not diminish until the control valve problem (stiction) was solved.

CPM would have reported the detected oscillation much earlier using its alert mechanism. Also, the detected oscillation amplitude and period (in this case almost three hours) would be available.

However, this example shows how users can assess stored performance information afterward, not just online, and use it for reporting purposes. After all, not many control problems resulting in poor control performance require rapid actions, but rather they deserve notice among other control loops—especially slowly degrading control loops that fit in without receiving any attention until the whole process is about to fall down.

The CPM function block operates in a Foundation fieldbus device, and it monitors and diagnoses PID control loop performance.

The CPM block can detect and give alert to control loop problems, including loop oscillation, control variability, control saturation, excessive noise, and actuator wear. It provides a general performance measure for detecting control performance deterioration for ranking the control loops. In addition, CPM maintains a log of controller history events, loop statistics, and performance diagnostics. The prerequisite for using a CPM block is the FF field device must have an operating PID controller, that is, the control is in the field instead of in the centralized controller. The device containing both PID and CPM functionality can be either an actuating device (e.g., digital valve controller) or a transmitter.

Behind the byline

Pasi Airikka is a senior research engineer; Pasi Heikkinen is a product manager; and Ismo Niemelä is a business development manager for Metso Automation in Finland. Oliver Jenkins is a director of fieldbus and smart products for Metso Automation in the U.K.