Patent Description:
Process control systems, such as those used in chemical, petroleum or other process plants, typically include one or more process controllers communicatively coupled to at least one host or operator workstation and to one or more field devices via analog, digital, or combined analog/digital communication links.

The process controllers receive signals indicative of process measurements made by sensors and/or field devices and/or other information pertaining to the field devices and execute a controller application that runs, for example, different control modules that make process control decisions, generate control signals based on the received information and coordinate with the control modules or blocks being performed in the field devices, such as HART®, Wireless HART®, and FOUNDATION® Fieldbus field devices. The control modules in the controller send the control signals over the communication lines or links to the field devices to thereby control the operation of at least a portion of the process plant or system.

The field devices, which may be, for example, valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, level and flow rate sensors), are located within the process environment and generally perform physical or process control functions such as opening or closing valves, measuring process parameters, etc. to control one or more process executing within the process plant or system. Smart field devices, such as field devices conforming to the well-known Fieldbus protocol may also perform control calculations, alarming functions, and other control functions commonly implemented within the controller.

Information from the field devices and the controller is usually made available over a data highway to one or more other hardware devices, such as operator workstations, personal computers or computing devices, data historians, report generators, centralized databases, or other centralized administrative computing devices that are typically placed in control rooms or other locations away from the harsher plant environment. Each of these hardware devices typically is centralized across the process plant or across a portion of the process plant. These hardware devices run applications that may, for example, enable an operator to perform functions with respect to controlling a process and/or operating the process plant, such as changing settings of the process control routine, modifying the operation of the control modules within the controllers or the field devices, viewing the current state of the process, viewing alarms generated by field devices and controllers, simulating the operation of the process for the purpose of training personnel or testing the process control software, keeping and updating a configuration database, etc. The data highway utilized by the hardware devices, controllers and field devices may include a wired communication path, a wireless communication path, or a combination of wired and wireless communication paths.

A particular set of process control devices used to achieve a particular control objective (e.g., controlling an inlet valve to a tank based on one or more measured process parameters) may be referred to as a process control loop. Furthermore, each valve or other device may, in turn, include an inner loop wherein, for example, a valve positioner controls a valve actuator (which may be electric, pneumatic, or hydraulic in nature) to move a control element, such as a valve plug, in response to a control signal and obtains feedback from a sensor, such as a position sensor, to control movement of the valve plug. This inner loop is sometimes called a servo loop.

In the case of a hydraulic valve actuator, the control element may move in response to changing fluid pressure on an actuator such as a spring biased diaphragm, which may be caused by a valve positioner responding to a change in the command signal. For example, in one standard valve mechanism, a command signal with a magnitude varying in the range of <NUM> to <NUM> mA (milliamperes) causes the valve positioner to alter the amount of fluid and thus, the fluid pressure, within a pressure chamber in proportion to the magnitude of the command signal. Changing fluid pressure in the pressure chamber causes the actuator (i.e., the spring based diaphragm in this example) to move, which causes the control element (e.g., a valve plug) to move. Accurate and precise control depends on a known relationship between (i) a change in pressure exerted on the control element and (ii) the resulting travel of the control element (sometimes simply referred to as travel of the valve).

In some cases, the relationship between supplied pressure and control element travel changes due to wear and tear on the valve, changes in process conditions (e.g., temperature or pressure of material flowing through the valve itself), changes in atmospheric conditions, etc. In some circumstances, the relationship between supplied pressure and control element travel is dynamic over time, and thus must consistently be reevaluated to maintain high performance control.

Generally speaking, valves can be diagnosed using offline diagnostics or online data. Performing offline diagnostics typically involves stroking the valve through its entire range of travel while collecting diagnostics data (e.g., data indicative of the relationship between the supplied pressure and the travel of the valve). While offline diagnostics often provide a comprehensive picture of the overall behavior of a valve, these diagnostics may fail to capture valve behavior similar to what would be found in a commissioned, operating valve. This failure to capture "real world" valve behavior can be attributed to the fact that the conditions may vary greatly from on-line to off-line operation due to extreme temperature, pressure, or other conditions. Rather than moving in a manner similar to what one would expect to see in the field, the valve is typically taken through a full range of travel at a standardized, slow, and methodical pace. While this slow pace removes various dynamics from valve behavior and makes it easier to compare the valve to other similar valves for the purpose of identifying valve health metrics, it is not always helpful by itself in determining whether the health of an operating valve has deteriorated over time. Moreover, even if offline diagnostics more closely captured valve behavior similar to that expected in online operation, offline diagnostics require that the valve be taken out of service because it is not likely that the valve can be taken through a full range of travel while simultaneously maintaining control of a process. Consequently, the process must often be halted for offline diagnostic testing of a valve, which can be costly in terms of lost material and profit. As a result, offline diagnostics testing is infrequent, and control valves often go years without updating offline diagnostics, resulting in a situation where offline diagnostics results, which may be years old, fail to account for break-in and normal wear and tear.

Online diagnostics are typically considered less invasive than offline diagnostics, as online diagnostics can be utilized in-situ (i.e., while the valve is in service). In short, during online diagnostics, the valve operates in normal operating condition while diagnostics data is collected. This has an advantage of not only maintaining normal operation of the valve and process while diagnostics data is collected, but also of accounting for the effect process conditions (e.g., temperature, pressure, etc.) have on the performance of the valve. Unfortunately, online diagnostic methods may also provide limited benefits. Because diagnostics data is only collected during normal online operation, online diagnostics methods may fail to capture diagnostics data pertaining to rare or unexpected conditions. For example, many valves have a limited (e.g., <NUM>% - <NUM>%) travel range during typical operation. As a result, online diagnostics may fail to capture diagnostics data regarding how the valve would respond to a command to adjust the valve to a position outside of this limited range. <CIT> discloses a valve used in a process, and more particularly to a method for determining whether the valve is closed or open without the use of a limit switch or pressure sensor.

An integrated diagnostics system utilizes online and offline diagnostics techniques to evaluate control valves found in process plant environments. In some instances, embodiments of the integrated diagnostics system may utilize prognostics, predictive analytics, and/or other suitable analytics techniques. The integrated diagnostics system improves on existing diagnostic systems, which typically rely exclusively on online diagnostics or offline diagnostics.

In an embodiment, a method is provided as defined in claim <NUM>.

In an embodiment, a system is provided as defined in claim <NUM>.

Each of the figures described below depicts one or more aspects of the disclosed system(s) and/or method(s), according to an embodiment. Wherever possible, the Detailed Description refers to the reference numerals included in the following figures.

Generally speaking, an integrated diagnostics system of this disclosure utilizes online and offline diagnostics data to evaluate parameters of a control valve operating in a process plant environment. Rather than relying exclusively on online diagnostics or offline diagnostics, the integrated diagnostics system uses both types of data to more accurately detect such issues as deteriorating valve health, in a wider range of cases. Moreover, the integrated diagnostics system operates in a non-intrusive manner and generally does not require that a valve be taken offline for testing.

For example, for a certain control valve the integrated diagnostics system can determine an offline "signature" (a characteristic response of a process variable to a control signal) and one or more online signatures, each of which may correspond to a full range of travel or a part of the range of travel. The integrated diagnostics system can collect online operating data for the control valve and compare the collected online operating data to the offline and online signatures. The integrated diagnostics system can select a diagnostic metric and compare current values for the diagnostic metric to those found in the online and offline signature. Examples of such metrics include the time required to move a valve a given amount in response to a given pressure, the rate at which valve changes for a given increase in pressure, etc..

Advantageously, the integrated diagnostics system can reduce the number of false positives that the existing diagnostics systems relying exclusively on online or offline diagnostics techniques are prone to generate. Because the integrated diagnostics system can establish a baseline with an offline signature and also tracks recent behavior with an online signature, the integrated diagnostics system can establish a range of behavior that might be expected for a wide variety of circumstances. For example, a system relying only on online diagnostics may generate a false positive regarding the health of the valve when the valve is operated outside of its normal routine (e.g., opening or closing the valve to an atypical position at an atypical rate) simply because the system has little diagnostics data describing behavior of the valve outside of normal behavior. By contrast, the integrated diagnostics system can compare the behavior of the valve to an offline signature to more accurately determine whether the behavior of the valve represents a problem.

Below, section I describes, referencing <FIG>, an example plant environment in which the integrated diagnostics system can be implemented. Section II describes, referencing <FIG>, an example control valve that may be diagnosed and analyzed by an integrated diagnostics system. Section III describes, referencing <FIG>, an example valve controller that can implement diagnostics functions of an integrated diagnostics system. Referencing <FIG> and <FIG>, section IV describes example plots that may be generated and analyzed by an integrated diagnostics system. Section V describes, referencing <FIG>, an example method of performing an integrated diagnostics analysis. Finally, Section VI includes additional remarks.

<FIG> is a block diagram depicting an integrated diagnostics system <NUM> that may be implemented to diagnose and analyze one or more control valves in a process plant <NUM> (sometimes referred to as a "process control system" or "process control environment"). The process plant <NUM> is described below, followed by a description of the integrated diagnostics system <NUM>.

The process plant <NUM> includes one or more process controllers that receive signals indicative of process measurements made by field devices, process this information to implement a control routine, and generate control signals that are sent over wired or wireless process control communication links or networks to other field devices to control the operation of a process in the plant <NUM>. Typically, at least one field device performs a physical function (e.g., opening or closing a valve, increasing or decreasing a temperature, taking a measurement, sensing a condition, etc.) to control the operation of a process. Some types of field devices communicate with controllers by using I/O devices. Process controllers, field devices, and I/O devices may be wired or wireless, and any number and combination of wired and wireless process controllers, field devices and I/O devices may be included in the process plant environment or system <NUM>.

For example, <FIG> illustrates a process controller <NUM> that is communicatively connected to wired field devices <NUM>-<NUM> via input/output (I/O) cards <NUM> and <NUM>, and that is communicatively connected to wireless field devices <NUM>-<NUM> via a wireless gateway <NUM> and a process control data highway or backbone <NUM>. One or more of the field devices <NUM>-<NUM> and <NUM>-<NUM> may be a control valve. The process control data highway <NUM> may include one or more wired and/or wireless communication links, and may be implemented using any desired or suitable or communication protocol such as, for example, an Ethernet protocol. In some configurations (not shown), the controller <NUM> may be communicatively connected to the wireless gateway <NUM> using one or more communications networks other than the backbone <NUM>, such as by using any number of other wired or wireless communication links that support one or more communication protocols, e.g., Wi-Fi or other IEEE <NUM> compliant wireless local area network protocol, mobile communication protocol (e.g., WiMAX, LTE, or other ITU-R compatible protocol), Bluetooth®, HART®, WirelessHART®, Profibus, FOUNDATION® Fieldbus, etc..

The controller <NUM>, which may be, by way of example, the DeltaV™ controller sold by Emerson Process Management, may operate to implement a batch process or a continuous process using at least some of the field devices <NUM>-<NUM> and <NUM>-<NUM>. In an embodiment, in addition to being communicatively connected to the process control data highway <NUM>, the controller <NUM> is also communicatively connected to at least some of the field devices <NUM>-<NUM> and <NUM>-<NUM> using any desired hardware and software associated with, for example, standard <NUM>-<NUM> mA devices, I/O cards <NUM>, <NUM>, and/or any smart communication protocol such as the FOUNDATION® Fieldbus protocol, the HART° protocol, the WirelessHART® protocol, etc. In <FIG>, the controller <NUM>, the field devices <NUM>-<NUM> and the I/O cards <NUM>, <NUM> are wired devices, and the field devices <NUM>-<NUM> are wireless field devices. Of course, the wired field devices <NUM>-<NUM> and wireless field devices <NUM>-<NUM> could conform to any other desired standard(s) or protocols, such as any wired or wireless protocols, including any standards or protocols developed in the future.

The process controller <NUM> of <FIG> includes a processor <NUM> that implements or oversees one or more process control routines <NUM> (e.g., that are stored in a memory <NUM>). The processor <NUM> is configured to communicate with the field devices <NUM>-<NUM> and <NUM>-<NUM> and with other nodes communicatively connected to the controller <NUM>. It should be noted that any control routines or modules described herein may have parts thereof implemented or executed by different controllers or other devices if so desired. Likewise, the control routines or modules <NUM> described herein which are to be implemented within the process control system <NUM> may take any form, including software, firmware, hardware, etc. Control routines may be implemented in any desired software format, such as using object oriented programming, ladder logic, sequential function charts, function block diagrams, or using any other software programming language or design paradigm. The control routines <NUM> may be stored in any desired type of memory <NUM>, such as random access memory (RAM), or read only memory (ROM). Likewise, the control routines <NUM> may be hard-coded into, for example, one or more EPROMs, EEPROMs, application specific integrated circuits (ASICs), or any other hardware or firmware elements. Thus, the controller <NUM> may be configured to implement a control strategy or control routine in any desired manner.

The controller <NUM> implements a control strategy using what are commonly referred to as function blocks, where each function block is an object or other part (e.g., a subroutine) of an overall control routine and operates in conjunction with other function blocks (via communications called links) to implement process control loops within the process control system <NUM>. Control based function blocks typically perform one of an input function, such as that associated with a transmitter, a sensor or other process parameter measurement device, a control function, such as that associated with a control routine that performs PID, fuzzy logic, etc. control, or an output function which controls the operation of some device, such as a valve, to perform some physical function within the process control system <NUM>. Of course, hybrid and other types of function blocks exist. Function blocks may be stored in and executed by the controller <NUM>, which is typically the case when these function blocks are used for, or are associated with standard <NUM>-<NUM> mA devices and some types of smart field devices such as HART® devices, or may be stored in and implemented by the field devices themselves, which can be the case with FOUNDATION® Fieldbus devices. The controller <NUM> may include one or more control routines <NUM> that may implement one or more control loops which are performed by executing one or more of the function blocks.

The wired field devices <NUM>-<NUM> may be any types of devices, such as sensors, valves, transmitters, positioners, etc., while the I/O cards <NUM> and <NUM> may be any types of I/O devices conforming to any desired communication or controller protocol. In <FIG>, the field devices <NUM>-<NUM> are standard <NUM>-<NUM> mA devices or HART® devices that communicate over analog lines or combined analog and digital lines to the I/O card <NUM>, while the field devices <NUM>-<NUM> are smart devices, such as FOUNDATION® Fieldbus field devices, that communicate over a digital bus to the I/O card <NUM> using a FOUNDATION° Fieldbus communications protocol. In some embodiments, though, at least some of the wired field devices <NUM>, <NUM> and <NUM>-<NUM> and/or at least some of the I/O cards <NUM>, <NUM> additionally or alternatively communicate with the controller <NUM> using the process control data highway <NUM> and/or by using other suitable control system protocols (e.g., Profibus, DeviceNet, Foundation Fieldbus, ControlNet, Modbus, HART, etc.).

In <FIG>, the wireless field devices <NUM>-<NUM> communicate via a wireless process control communication network <NUM> using a wireless protocol, such as the WirelessHART® protocol. Such wireless field devices <NUM>-<NUM> may directly communicate with one or more other devices or nodes of the wireless network <NUM> that are also configured to communicate wirelessly (using the wireless protocol or another wireless protocol, for example). To communicate with one or more other nodes that are not configured to communicate wirelessly, the wireless field devices <NUM>-<NUM> may utilize a wireless gateway <NUM> connected to the process control data highway <NUM> or to another process control communications network. The wireless gateway <NUM> provides access to various wireless devices <NUM>-<NUM> of the wireless communications network <NUM>. In particular, the wireless gateway <NUM> provides communicative coupling between the wireless devices <NUM>-<NUM>, the wired devices <NUM>-<NUM>, and/or other nodes or devices of the process control plant <NUM>. For example, the wireless gateway <NUM> may provide communicative coupling by using the process control data highway <NUM> and/or by using one or more other communications networks of the process plant <NUM>.

Similar to the wired field devices <NUM>-<NUM>, the wireless field devices <NUM>-<NUM> of the wireless network <NUM> perform physical control functions within the process plant <NUM>, e.g., opening or closing valves, or taking measurements of process parameters. The wireless field devices <NUM>-<NUM>, however, are configured to communicate using the wireless protocol of the network <NUM>. As such, the wireless field devices <NUM>-<NUM>, the wireless gateway <NUM>, and other wireless nodes <NUM>-<NUM> of the wireless network <NUM> are producers and consumers of wireless communication packets.

In some configurations of the process plant <NUM>, the wireless network <NUM> includes non-wireless devices. For example, in <FIG>, a field device <NUM> of <FIG> is a legacy <NUM>-<NUM> mA device and a field device <NUM> is a wired HART® device. To communicate within the network <NUM>, the field devices <NUM> and <NUM> are connected to the wireless communications network <NUM> via a wireless adaptor 52a, 52b. The wireless adaptors 52a, 52b support a wireless protocol, such as WirelessHART, and may also support one or more other communication protocols such as Foundation® Fieldbus, PROFIBUS, DeviceNet, etc. Additionally, in some configurations, the wireless network <NUM> includes one or more network access points 55a, 55b, which may be separate physical devices in wired communication with the wireless gateway <NUM> or may be provided with the wireless gateway <NUM> as an integral device. The wireless network <NUM> may also include one or more routers <NUM> to forward packets from one wireless device to another wireless device within the wireless communications network <NUM>. In <FIG>, the wireless devices <NUM>-<NUM> and <NUM>-<NUM> communicate with each other and with the wireless gateway <NUM> over wireless links <NUM> of the wireless communications network <NUM>, and/or via the process control data highway <NUM>.

As already noted, the process control system <NUM> includes an integrated diagnostics system <NUM>, which may execute on a host (sometimes referred to as a "server," "computer," etc.) <NUM> and may be communicatively coupled to the data highway <NUM>. The host <NUM> may be any suitable computing device, and may include a memory (not shown) storing the system <NUM> as one or more modules, applications, or sets of instructions; and a processor (not shown) to execute the system <NUM>. The memory may be any system or device including non-transitory computer readable media for placing, keeping, and/or receiving information (e.g., RAM, ROM, EEPROM, flash memory, optical disc storage, magnetic storage, etc.). In some configurations, the host <NUM> may be a portable handheld tool, including a touch interface, for example. Further, in some instances, the system <NUM> is an application-specific integrated circuit (ASIC). While <FIG> shows the host <NUM> as including a display, in some instances the host <NUM> does not include a display.

The integrated diagnostics system <NUM> performs online diagnostics, offline diagnostics, and/or an integrated diagnostics analysis on a control valve (as noted, one or more of the field devices <NUM>-<NUM> and <NUM>-<NUM> may be a control valve). As shown, the host <NUM> provides all of the functionality associated with the system <NUM>. However, in some configurations the integrated diagnostics system <NUM> is a distributed system. For example, online diagnostics functionality of the diagnostics system <NUM> may be implemented by a valve controller for a control valve, and the offline diagnostics functionality and integrated diagnostics analysis functionality may be implemented by a host communicatively connected to the data highway <NUM>. In this implementation, the valve controller may transmit collected diagnostics data (e.g., via the I/O card <NUM> or <NUM> and the data highway <NUM>) to the host <NUM> where the integrated diagnostics analysis is performed.

It is noted that although <FIG> only illustrates a single controller <NUM> with a small number of field devices <NUM>-<NUM> and <NUM>-<NUM>, wireless gateways <NUM>, wireless adaptors <NUM>, access points <NUM>, routers <NUM>, and wireless process control communications networks <NUM> included in the example process plant <NUM>, this is only an illustrative and non-limiting embodiment. Any suitable number of controllers <NUM> may be included in the process control plant or system <NUM>, and any of the controllers <NUM> may communicate with any number of wired or wireless devices and networks <NUM>-<NUM>, <NUM>-<NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> to control a process in the plant <NUM>. This system could be integrated as local analytics, edge based analytics, or remote analytics performed in the Cloud.

<FIG> is a conceptual block diagram depicting the integrated diagnostics system <NUM> (also shown in <FIG>) communicatively connected to a control valve <NUM>, which is part of a single-input, single-output process control loop <NUM>. The integrated diagnostics system <NUM> collects information from the control valve <NUM> and various sensors, and uses this information to perform online diagnostics, offline diagnostics, and/or an integrated analysis of diagnostics data resulting from the online and offline diagnostics, enabling the integrated diagnostics system <NUM> to track the behavior and health of the control valve <NUM>. The components of the control loop <NUM> are described below, followed by a discussion of the system <NUM> and its interactions with the components of the control loop <NUM>.

In addition to the control valve <NUM>, the control loop <NUM> includes a transmitter <NUM>, summing junction <NUM>, and a controller <NUM>. The control valve <NUM> can operate in the plant <NUM> shown in <FIG>, and may be similar to one or more of the field devices <NUM>-<NUM> or <NUM>-<NUM>. For example, the control valve may be communicatively connected to the data highway <NUM> via the I/O devices <NUM> or <NUM>, the controller <NUM>, and/or the gateway <NUM>. In normal operation, the process controller <NUM> controls the control valve <NUM> to manipulate a process variable of a process <NUM>. To implement control of the valve <NUM>, the controller <NUM> sends, for example, a <NUM> to <NUM> mA command signal to the control valve <NUM>. The control valve <NUM> is illustrated as including a positioner <NUM> (which may be a current-to-pressure (I/P) transducer) that typically sends a <NUM> to <NUM> psig pressure signal to a valve actuator <NUM> (e.g., a pneumatic relay and/or an actuator) which, in turn, pneumatically controls a control element <NUM> (e.g., a plug) with a pressure signal (air). By adjusting the control element <NUM>, flow through the control valve <NUM> can be controlled, enabling control of a process variable within the process <NUM> (e.g., a fluid level in a tank, a flow level in a pipe, a temperature or pressure of a material, etc.).

As is standard, a transmitter <NUM> measures the process variable of the process <NUM> and transmits an indication of the measured process variable to a summing junction <NUM>. The summing junction <NUM> compares the measured value of the process variable (converted into a normalized percentage) to a set point to produce an error signal indicative of the difference. The summing junction <NUM> then provides the calculated error signal to the process controller <NUM>. The set point, which may be generated by a user, an operator or another controller is typically normalized to be between <NUM> and <NUM> percent and indicates the desired value of the process variable. The process controller <NUM> uses the error signal to generate the command signal according to any desired technique and delivers the command signal to the control valve <NUM> to thereby effect control of the process variable.

While the control valve <NUM> is illustrated as including the positioner <NUM>, the actuator <NUM> and the control element <NUM>, the control valve <NUM> may include any other type of valve mechanisms or elements instead of or in addition to those illustrated in <FIG> including, for example, an electro-pneumatic positioner having an I/P unit integrated therein. As another example, the actuator <NUM> may be spring-based, and may exert a mechanical force on the control element <NUM> in response to the pressure signal received from the positioner <NUM>. Additionally, an electro-pneumatic positioner may also integrate an array of one or more sensors, and/or a memory, and/or a parameter estimation unit therein. Furthermore, it should be understood that the control valve <NUM> may be any other type of device (besides a valve controlling device) that controls a process variable in any other desired or known manner. The control valve <NUM> may be, for example, a damper, etc..

As noted, the integrated diagnostics system <NUM> collects data from various devices in the loop <NUM> and utilizes the collected data to estimate various loop parameters (friction, dead time, dead band, etc.) and to perform online and offline diagnostics. One or more components of the system <NUM> may be implemented by the host <NUM> (e.g., a server connected to the various sensors via the data highway <NUM>, a portable tool directly or indirectly connected to the various sensors, etc.). In some configurations, one or more components of the integrated diagnostics system <NUM> can be internal to the control valve <NUM> or any other process control device (e.g., field device) in a process control network. If the control valve <NUM> is a micro-processor based device, the integrated diagnostics system <NUM> can share the same processor and memory as that already within the control valve <NUM>. Thus, it is contemplated that a statistical analysis (e.g., for the online diagnostics, offline diagnostics, or integrated analysis) may be performed in the device in which the measurements are made (such as in any field device) with the results being sent to a user display or to a host device (e.g., the host <NUM>) for use or, alternatively, the signal measurements may be made by a device (such as a field device) with such measurements then being sent to a remote location (such as the host <NUM>) where the statistical analysis is performed. In any event, regardless of the precise nature of the system <NUM>, it collects via various sensors data pertaining to the valve <NUM>.

For example, the integrated diagnostics system <NUM> may detect one or more of the command signals delivered to the positioner <NUM> using a current sensor <NUM>, the pressure output from the positioner <NUM> using a pressure sensor <NUM>, the actuator command signal output by the actuator <NUM> using a pressure sensor <NUM>, and the valve position at the output of the control element <NUM> using a position sensor <NUM>. If desired, the integrated diagnostics system <NUM> may also or alternatively detect the set point signal, the error signal at the output of the summing junction <NUM>, the process variable, the output of the transmitter <NUM> or any other signal or phenomena that causes or indicates movement or operation of the control valve <NUM> or process control loop <NUM>. It should also be noted that other types of process control devices may have other signals or phenomena associated therewith that may be used by the integrated diagnostics system <NUM>.

As will be evident, the integrated diagnostics system <NUM> may also read an indication of the controller command signal, the pressure signal, the actuator command signal, or the valve position when the control valve <NUM> is configured to communicate those measurements. Likewise, the integrated diagnostics system <NUM> may detect signals generated by other sensors already within the control valve <NUM>, such as the valve position indicated by the position sensor <NUM>. Of course, the sensors used by the integrated diagnostics system <NUM> can be any known sensors and may be either analog or digital sensors. For example, the position sensor <NUM> may be any desired motion or position measuring device including, for example, a potentiometer, a linear variable differential transformer (LVDT), a rotary variable differential transformer (RVDT), a Hall effect motion sensor, a magneto resistive motion sensor, a variable capacitor motion sensor, etc. It will be understood that, if the sensors are analog sensors, the integrated diagnostics system <NUM> may include one or more analog-to-digital converters which samples the analog signal and stores the sampled signal in a memory within the integrated diagnostics system <NUM>. However, if the sensors are digital sensors, they may supply digital signals directly to the integrated diagnostics system <NUM> which may then store those signals in memory in any desired manner. Moreover, if two or more signals are being collected, the integrated diagnostics system <NUM> may store these signals as components of data points associated with any particular time. For example, each data point at time T1, T2,. Tn may have an input command signal component, a pressure signal component, an actuator travel signal component, etc. Of course, these data points or components thereof may be stored in memory in any desired or known manner.

As shown in <FIG>, the integrated diagnostics system <NUM> includes a diagnostics module <NUM> and an integrated diagnostics analyzer <NUM>, each of which may take any desirable form, including software, firmware, hardware, etc. For example, each of the components <NUM> and <NUM> may be a module, application, or a set of instructions stored to a memory of a computing device and executable by a processor of the computing device.

The integrated diagnostics system <NUM> may implement the diagnostics module <NUM> to perform offline diagnostics on the control valve <NUM>. Generally speaking, during offline diagnostics, the control valve <NUM> is taken offline. The system <NUM> then controls the valve <NUM>, driving the throttling element of the valve <NUM> through its full range of travel. As the valve <NUM> is opening or closing, the system <NUM> collects data from one or more of the sensors <NUM>-<NUM> and uses the collected data to generate an offline valve signature (e.g., stored as offline signature data). For example, an offline valve signature can include a set of expected sensor measurements corresponding to a set of respective positions of the valve <NUM>. As a more specific example, the offline valve signature can specify how measurements from the pressure sensor <NUM> relate to measurements from the position sensor <NUM>, thus relating pressure exerted on the actuator <NUM> to the position of the actuator <NUM> and/or to the position of the control element <NUM>.

Further, the integrated diagnostics system <NUM> may implement the diagnostics module <NUM> to perform online diagnostics on the control valve <NUM>. During online diagnostics, the system <NUM> collects data from one or more of the sensors <NUM>-<NUM> and uses the collected data to generate an online valve signature (e.g., stored as online signature data). Similar to an offline valve signature, an online valve signature can include a set of expected sensor measurements corresponding to a set of respective positions of the valve <NUM>. Notably, when performing online diagnostics, the integrated diagnostics system <NUM> does not require the control valve <NUM> be taken offline or out of the normal operating environment. Rather, the system <NUM> collects data while the valve <NUM> is controlled by the controller <NUM> during normal online operation. As a result, the online valve signature may correlated sensor measurements to valve positions over a more limited range. For example, unlike an offline signature which may relate sensor measurements to valve positions for a range of <NUM>% open to <NUM>% open, an online signature may relate sensor measurements to valve positions for a range that it typically experiences during normal online operation, such as <NUM>% open to <NUM>% open.

The system <NUM> in general may implement the integrated diagnostics analyzer <NUM> to analyze an current operating data, an online valve signature, and offline valve signature, and may rely on that analysis to estimate a behavior or health of the valve. Example techniques that may be implemented by the analyzer <NUM> are discussed below with reference to <FIG> and <FIG>.

<FIG> illustrates an example digital valve controller (for simplicity, "controller") <NUM> capable of controlling a valve <NUM> and implementing diagnostics functions <NUM>, which may be similar to the diagnostics module <NUM> shown in <FIG>. The valve <NUM> and controller <NUM> may be referred to as a "smart valve" or "smart field device," and may be similar to one or more of the field devices <NUM>-<NUM> or <NUM>-<NUM> shown in <FIG>. The controller <NUM> may be communicatively connected to the data highway <NUM> shown in <FIG> via the I/O devices <NUM> or <NUM>, the controller <NUM>, and/or the gateway <NUM>.

As discussed below, the controller <NUM> is capable of fast, dynamic in situ process control for various types of process variables, performance optimization, real-time diagnostics, etc. By implementing PID control directly at a valve or another field device, the controller <NUM> can deliver improved loop performance. Moreover, the controller <NUM> effectively replaces several devices, thereby simplifying installation and maintenance. A single supplier can provide the controller <NUM> for total loop control.

In the example configuration of <FIG>, the controller <NUM> operates on the valve <NUM>, which is installed in a pipeline <NUM>. The valve <NUM> and the pipeline <NUM> can be similar to the valve <NUM> discussed above with reference to <FIG>. The controller <NUM> includes function modules <NUM>, a memory <NUM> and a pneumatic output module <NUM> (which may be similar to the actuator <NUM> shown in <FIG>). In some implementations, the controller <NUM> also can include a sensor, such as a pressure sensor <NUM>. Further, the integrated controller <NUM> can include a network interface module <NUM>. In an example implementation, the components <NUM> - <NUM> are coupled to a backplane <NUM>. The controller <NUM> can receive a setpoint for a process variable and configuration data via a communication line <NUM>, and provide process information and reports to a remote host via a communication line <NUM>. The lines <NUM> and <NUM> are not necessarily physically separate channels, and in general can be communication channels on a same wire or a set of wires, different radio channels or different timeslots of a same channel, or any other suitable types of physical or logic channels. The lines <NUM> and <NUM> may be communicatively connected to a data highway, such as the data highway <NUM> shown in <FIG>.

Next, the components <NUM> - <NUM> are briefly considered individually, followed by a discussion of operation of the controller <NUM>.

Depending on the implementation, the function modules <NUM> can include a general-purpose central processing unit (CPU) configured to execute instructions stored in the memory <NUM> and/or one or several special-purpose modules, such as application-specific integrated circuits (ASICs) configured to execute PID functions. The CPU can include a real-time clock accurate to within a certain number of minutes (e.g., <NUM>) per year over the entire range of temperatures at which the controller <NUM> can operate. More generally, the function modules <NUM> can include one or more processors of any suitable type. As schematically illustrated in <FIG>, the function modules <NUM> can implement one or several PID functions <NUM>, one or several tuning functions <NUM>, one or several real-time positioning functions <NUM>, the online diagnostics module <NUM> discussed with reference to <FIG>, and, if desired, additional functions related to monitoring, troubleshooting, process variability optimization, etc. The function modules <NUM> can implement these functions in hardware, firmware, software instructions executable by one or more processors, or any suitable combination of hardware, firmware, and software.

In an example scenario, the function modules <NUM> receives a pressure setpoint via a communication line <NUM> for the pipeline <NUM> from a remote host via the network interface <NUM>, receives sensor data from the pressure sensor <NUM>, executes a PID algorithm to generate a positioning command (or, more generally, an output signal), and applies the positioning command to the valve <NUM> via the pneumatic output module <NUM>. It is noted that the function modules <NUM> can receive a setpoint for a process variable rather than for a field device. The function modules <NUM> can retrieve the tuning parameters for the PID loop from the memory <NUM>. These parameters can be pre-configured, received from a remote host, determined and/or adjusted used auto-tuning, etc., as discussed in more detail below. Thus, the function module <NUM> can use locally collected sensor data to locally, without relying on a remote host, execute control functions. Depending on the implementations, the function modules <NUM> can implement functions to control many different process variables, such as pressure, position, temperature, flow rate, or pH.

More generally, the function modules <NUM> allow the integrated controller <NUM> to quickly and efficiently react to device issues (e.g., detect a problem with the valve <NUM>, detect failure of the sensor <NUM>), control loop issues (e.g., determine that PID parameters should be adjusted), carry out emergency procedures (e.g., shut down flow through the pipeline <NUM>), generate alerts for output via the local UI module <NUM> and/or for reporting to a remote host.

The memory <NUM> can be any suitable non-transitory computer-readable medium and can include volatile and/or non-volatile components. Thus, the memory <NUM> can include random-access memory (RAM), a hard disk, a flash drive, or any other suitable memory components. The memory <NUM> can store PID parameters <NUM>, online diagnostics data <NUM>, valve signature data <NUM>, and process signature data <NUM>. In particular, the PID parameters <NUM> can specify proportional, derivate, and integral gain values for a loop controlling the valve <NUM> or another field device. The PID parameters <NUM> can be provided configured by a remote operator via a remote host and provided via the network interface <NUM>, a local operator via the UI module <NUM>, pre-stored in the memory <NUM> by the manufacturer of the integrated controller <NUM>, etc. In some scenarios, the integrated controller <NUM> can adjust PID parameters <NUM> in response to receiving a new setpoint <NUM> or upon conducting diagnostics, for example.

The valve signature data <NUM> and the process signature data <NUM> can describe expected behavior of the valve <NUM> and the loop for controlling the valve <NUM>, respectively. Generally speaking, signatures stored in the memory <NUM> can describe the expected response of a sub-system to input signals, for comparing to the actual response of the sub-system and determining whether the sub-system operates properly. The signatures stored in the memory <NUM> may include online signatures such as those described with reference to <FIG>.

The integrated controller <NUM> can locally collect data for determining the actual response to a sub-system such as the valve <NUM> and again locally compare the collected data to the signature <NUM>, the signature <NUM>, or another signature. In this manner, the integrated controller can quickly and efficiently detect valve problems (e.g., actuator being stuck, pressure loss, leakage of fluid), process upsets, control loop degradation, etc. Further, if desired, the integrated controller <NUM> can execute the appropriate tuning function <NUM> to create a process signature. Using the process signature, the controller can detect a suitable set of tuning parameters for the desired control loop response.

Further, the memory <NUM> can retain configuration information, logs, history data, status of input and output ports, etc. The integrated process controller <NUM> can be configured to retain in the memory <NUM> an event log, an alert log, real-time clock data, a loop log, historical data, database data, status of input/output channels, function module attributes, user lists, etc., in the event of a power failure.

With continued reference to <FIG>, the pneumatic output module <NUM> can actuate the valve <NUM> during operation. The pneumatic output module <NUM> can include an I/P transducer and one or more relay components. In an example implementation, the pneumatic output module <NUM> includes an I/P module and a double-acting relay. Further, in one implementation, the pneumatic output module <NUM> includes a relay that bleeds and one that locks in the last value in the event of a power failure. The controller <NUM> can provide indications of output pressure of the pneumatic output module <NUM> via the local UI <NUM> or the RUI of a remote host. It is noted that the controller <NUM> can monitor operation of the pneumatic output module <NUM> by sensing output pressure, for example, and perform real-time online diagnostics to detect complete or partial failure early.

When used in applications in which natural gas is the medium, the controller <NUM> can include one or several no-bleed pneumatic components to comply with emission regulations. The controller <NUM> in these implementations allows continued use of the medium while reducing the emissions compared to traditional pneumatic devices.

In an example implementation, the pressure sensor <NUM> is an integral pressure sensor module configured to measure pressure as the process variable (PV). The pressure sensor <NUM> may bolt directly to the housing <NUM>. In alternative implementations, however, the pressure sensor <NUM> can be provided as a separate device coupled to the controller <NUM> by a wired link or a short-range wireless link. Similar to the pneumatic output module <NUM> discussed above, the controller <NUM> can display live data for the pressure sensor <NUM> via a local UI module (not shown) or the RUI at the remote host. Further, the controller <NUM> can support commands using which an operator can request, or pull, live data via the local or remote interface.

Although the example implementation depicted in <FIG> includes a pressure sensor <NUM> integral with the remaining assembly of the controller <NUM>, in other implementations the controller <NUM> can include additional I/O modules such as a valve position sensor or a temperature sensor. These and other modules can be inserted into the backplane <NUM>, or the controller <NUM> can communicate with the additional modules via short-range communication links.

The network interface module <NUM> can support general-purpose protocols such as the Internet Protocol (IP) as well as special-purpose process control and industrial automation protocols designed to convey commands and parameters for controlling a process plant, such as Modbus, HART, Profibus, etc. The network interface module <NUM> can support wired and/or wireless communications. As discussed above, the controller <NUM> can receive a setpoint value from a remote host via a long-range communication link to which the network interface module <NUM> is coupled. The network interface module <NUM> can support Ethernet ports and, in some implementations, implement protection against unauthorized access.

The backplane <NUM> can be a component with no active circuitry, residing in the housing <NUM> and having connections for mounting various modules. As illustrated in <FIG>, the backplane <NUM> can interconnect the function modules <NUM>, the memory <NUM>, the network interface <NUM>, the pneumatic output module <NUM>, etc. The backplane <NUM> in general can include connections to receive power, select lines, communication ports, etc. In some implementations, the CPU module is selected or designed so as to prevent mis-insertion into the backplane <NUM>.

In operation, the controller <NUM> can perform real-time prognostics to allow operators to quickly gain accurate insight into process changes, issues related to the valve <NUM>, transmissions and communications, control maintenance, etc. Thus, the controller <NUM> can carry out control functions in the field. In other words, rather than operating based on commands generated by a remote host that implements a PID loop, the controller <NUM> can control the valve <NUM> and/or loop parameters locally and, if desired, report information to a host via a communication network via the communication line <NUM>.

Further, although the controller <NUM> can receive the setpoint value <NUM> via a wireless communication link, which may introduce a communication delay, the controller <NUM> then can drive the process variable to the setpoint using wired signaling between components within the same devices, or even on-chip signaling. More specifically, the controller <NUM> need not report pressure, position, temperature, level, flow rate, or other measurements to another device capable of calculating new control signals. Updates to the setpoint therefore may be limited by the speed of wireless communications, but communications between sensors, modules calculating proportional, derivate, and integral values, etc. occur at higher speeds.

<FIG> illustrates an example plot <NUM> of actuator pressure versus valve position for a typical sliding stem valve, generated by the integrated diagnostics system <NUM> performing online diagnostics. The plot <NUM> may also be referred to as an online valve signature. Each point in the plot <NUM> corresponds to a concurrent measurement obtained by the integrated diagnostics system <NUM> of pressure exerted on the actuator <NUM> shown in <FIG> (i.e., "actuator pressure") and a position of the actuator <NUM> or control element <NUM> shown in <FIG> (i.e., "valve position"). While the plot <NUM> is discussed with reference to the valve <NUM> shown in <FIG>, it may be implemented with respect to any suitable valve.

The plot <NUM> corresponds to a single cycle of operation of the valve <NUM>. This single cycle of operation may be referred to as an "online signature" for the valve <NUM>. The system <NUM> may collect multiple online signatures. In some instances, the system <NUM> may generate an online signature based on a full cycle, a partial cycle (e.g., representing a trend across two data points, three data points, etc.), or may generate an online signature based on multiple cycles, representing an average cycle over a given period of time or a certain number of cycles, rather than a single cycle (e.g., the online signature may be a rolling average of the past ten online signatures).

Those of ordinary skill in the art will appreciate that upon a reversal of direction by the valve <NUM>, the control element <NUM> operates through a friction zone in which the applied pressure increases or decreases a significant amount with little or no resulting movement of the control element <NUM>. This friction zone, which is caused by friction within the valve <NUM>, is generally indicated by the more vertical lines <NUM> in <FIG>. Upon exiting the friction zone, the control element <NUM> then moves a significant amount with relatively little change in the applied pressure. This operation is generally indicated by the more horizontal lines <NUM> in <FIG>. Of course, other methods of representing the relationship between actuator pressure and actuator or control element position are also available. For example, actuator pressure and actuator position can be plotted separately versus time. By aligning the two resulting plots along the same timeline, the plots can be simultaneously analyzed to detect the amount of pressure required to enable the movement of the actuator <NUM> and/or control element <NUM>. Thus, one of ordinary skill in the art will appreciate that the exemplary plots discussed herein are presented by way of illustration only.

<FIG> illustrates an example plot <NUM> of actuator pressure versus valve position, generated by the integrated diagnostics system <NUM> performing an integrated diagnostics analysis that utilizes both online and offline diagnostics. The plot <NUM> includes an offline signature <NUM>, an online signature <NUM>, data points <NUM>, trend lines <NUM> and <NUM>, and a measurement <NUM> of a diagnostic metric.

The offline signature <NUM> is generated by taking the valve offline, controlling the valve through a full range of travel, and collecting data over time pertaining to pressure exerted on a valve actuator compared to travel or position of the control element of the valve. In other words, the system <NUM> collects data so that at multiple discreet points in time, pressure can be compared to valve position. Because the valve is typically taken through a full range of motion during offline diagnostics testing, these relationships can be observed for the full range of the valve. Utilizing the collected data, the system <NUM> can generate the offline valve signature <NUM>. In short, this represents the typical behavior of the valve when the valve is being stroked. Depending on the embodiment, the offline signature may be based on a partial cycle (e.g., <NUM>% to <NUM>% open, but not vice versa), a full cycle, or multiple cycles (e.g., representing an average of the multiple cycles).

The online diagnostics signature <NUM> may be similar to the online signature discussed with reference to <FIG>. In short, the system <NUM> generates the online signature by observing the valve operate over time under normal operating conditions. In contrast to the offline signature, which is usually generated based on data collected while the valve moves through a full range of travel, the online signature is often generated based on data collected while the valve moves through a more limited range of travel because the valve may be configured to typically only move through that limited range of travel during normal operation.

The plot <NUM> further includes current data points <NUM>. Generally speaking, the system <NUM> collects the current data points <NUM> during normal operation of the valve and utilizes the current data points <NUM> to generate or identify an online valve signature such as the signature <NUM>. In some instances, the current data points <NUM> may be compared to previous online valve signatures. For example, <FIG> shows data points <NUM> above the signature <NUM>, indicating that, for the valve positions associated with these data points <NUM>, the valve required more pressure than expected or observed based on the online signature <NUM>. Similarly, the plot <NUM> shows three data points <NUM> below the online signature <NUM>, indicating that at certain points the valve required less pressure for a given position.

Finally, the plot <NUM> includes trend lines <NUM> and <NUM> that are generated by the system <NUM> from the current data points <NUM>. The system <NUM> can generate the trend lines <NUM> and <NUM> and analyze these lines to evaluate the health of the valve. In some instances, the trend lines <NUM> and <NUM> may be part of an online valve signature, or may themselves represent an online valve signature (in this case, an incomplete valve signature).

The trend lines <NUM> and <NUM> can be compared to the online signature <NUM> and offline signature <NUM> to evaluate the health of the valve. Because the trend lines <NUM> and <NUM> can be compared to both an online signature and offline signature, the system <NUM> can better evaluate the health of the valve when compared to other diagnostic systems.

For example, if one were to compare the trend line <NUM> to the offline signature <NUM> alone (something often done in typical diagnostic evaluations), one would observe that an excessive amount of pressure is required to move the valve to a given position (relative to the offline signature), and might thus conclude that the valve is behaving in an abnormal manner. Similarly, one could compare the trend line <NUM> to the online signature <NUM> alone and conclude that the valve is requiring less pressure to move, and might consequently conclude that the valve is behaving abnormally. However, an analysis of the trend line <NUM> in light of the signature <NUM> and signature <NUM> reveals that, for a given valve position, the valve actuator requires pressure within an expected range when both the online signature <NUM> and offline signature <NUM> are considered.

The plot <NUM> also shows a measurement <NUM> of a diagnostic metric. This particular metric is a pressure differential that reveals the size of the friction zone associated with the valve. In short, the measurement <NUM> is of a difference between: (i) a pressure measured for a valve position as the valve is opening, and (ii) a pressure measured for that same valve position as the valve is closing. The measurement <NUM> reveals a level of friction associated with the valve. As already noted with reference to <FIG>, a valve operates through a friction zone in which the applied pressure increases or decreases a significant amount with little or no resulting movement of the valve. This friction zone, which is caused by friction within the valve, is generally indicated by the more vertical lines of the offline signature <NUM> and the online signature <NUM>. Upon exiting the friction zone, the valve then moves a significant amount with relatively little change in the applied pressure. This zone of easier movement is represented by the more horizontal lines of the offline signature <NUM> and the online signature <NUM>. The measurement <NUM> reveals the size of the friction zone.

The integrated diagnostics system <NUM> can identify, from the data points <NUM>, a current friction zone measurement (not show), which can be compared to the measurement <NUM> and/or to a measurement of a friction zone associated with the online signature <NUM>. Thus, the integrated diagnostics system <NUM> can determine whether the current friction zone is near the friction zone of the signatures <NUM> and <NUM>. Further, the system <NUM> can monitor the friction zone over time to determine whether the friction zone is increasing or decreasing (either of which may indicate a problem with the health of the valve), and a rate at which the friction zone is increasing or decreasing.

The integrated diagnostics system <NUM> can similarly observe other diagnostic metrics. For example, the integrated diagnostics system <NUM> can monitor the slope of the more horizontal lines of the offline signature <NUM>, the offline signature <NUM>, and/or trends <NUM> and <NUM>. This slope generally correlates to a spring rate associated with the valve. Thus, the system <NUM> can monitor these slopes and determine whether the slope is increasing or decreasing over time (which, again, may indicate a problem with the health of the valve).

<FIG> is a flow chart depicting an example method <NUM> of performing integrated diagnostics analysis. The method <NUM> may be implemented, in whole or in part, by the integrated diagnostics system <NUM> shown in <FIG>. Software instructions that implement the method <NUM> may be saved in a non-transitory, computer-readable memory. While the method <NUM> is discussed with reference to the valve <NUM> shown in <FIG>, in general the method <NUM> can be applied to any suitable valve.

The method <NUM> can be implemented to evaluate the stability of a valve over time. In short, offline and online behaviors of the valve are observed and compared to each other. This relationship is observed over time. The system <NUM> can generate an alarm when the relationship begins to change, indicating that the behavior of the valve is beginning to change when compared to historic performance.

At block <NUM>, the system <NUM> collects offline diagnostics data. As already noted, this generally involves taking the valve <NUM> offline, stroking the valve <NUM> through its entire range of travel, and collecting (e.g., via the sensors <NUM>-<NUM>) diagnostics data as the valve <NUM> is moving. In some instances, the diagnostics data includes a timestamp generated by a clock (e.g., an internal hardware or software clock of the host <NUM> shown in <FIG> or of the valve controller <NUM> shown in <FIG>). Once this diagnostics data has been collected, the system <NUM> can generate an offline signature such as the signature <NUM> shown in <FIG>.

At block <NUM>, the system <NUM> calculates an offline response from the offline diagnostics data and/or offline signature (TR-OFF). In short, the offline response represents a response by an output variable (e.g., the valve <NUM> in this case) to a change in an input variable during offline diagnostics testing. Generally speaking, the input variable is the pressure applied to the actuator <NUM> or the pressure applied by actuator <NUM> to the control element <NUM>, and the output variable is the response time (e.g., the time it takes for the control element <NUM> to move and reach a steady state). In some instances, the output variable is the position at which the control element <NUM> reaches at steady state (e.g., <NUM>% open) after responding to the change in the input variable. In some configurations, the input variable could be the <NUM>-<NUM> command received by the positioner <NUM>.

At block <NUM>, the system <NUM> collects online diagnostics data. The online diagnostics data is data collected (e.g., via one or more of the sensors <NUM>-<NUM>) during online operation of the valve <NUM>. While the online diagnostics data is being collected, the controller <NUM> typically controls the valve <NUM> as it normally would to implement the control logic of the process <NUM>.

At block <NUM>, the system <NUM> calculates an online response from the online diagnostics data (TR-ON). Generally speaking, the online response represents a response by an output variable (e.g., the valve <NUM> in this case) to an input variable during online operation. Like the offline response, the online response may relate a response of any given output variable (e.g., measured by one of the sensors <NUM>-<NUM>) to a manipulation of any other input variable (e.g., measured by one of the sensors <NUM>-<NUM> and/or a clock). That said, the input and output variables utilized for the calculated online response are generally the same input and output variables that were utilized when calculating the offline response. For example, if the offline response utilizes as an input variable a pressure signal applied on the actuator <NUM> and utilizes as an output variable the position of the control element <NUM> (as measured by the sensor <NUM>) responding to changes in the pressure signal, the online response similarly utilizes the pressure signal and control element position as the input variable and output variable, respectively.

At block <NUM>, the system <NUM> calculates a response ratio based on the calculated online and offline responses (e.g., TR-ON/TR-OFF). For example, if during online operation the valve <NUM> takes three seconds to respond to a given pressure applied to the actuator <NUM> and the offline signature indicates that the valve <NUM> took two seconds to respond to that same pressure, the response ratio is <NUM> (<NUM>/<NUM>). Alternatively, if the valve takes two seconds to respond to the given pressure, the response ratio is <NUM> (<NUM>/<NUM>).

Generally speaking, the response ratio indicates how closely the online behavior of the valve <NUM> mimics the behavior of the valve <NUM> observed during offline diagnostics testing. In some instances, it is expected that online performance of the valve differs from performance during offline diagnostics testing. This could be caused by a number of factors, such as wear and tear on the valve since offline diagnostics testing was performed, changes in process conditions, changes in environmental conditions, etc. Consequently, a response ratio value greater or less than one does not necessarily suggest the valve is experiencing a problem.

At block <NUM>, the system <NUM> analyzes the rate-of-change of the response ratio over time. For example, the system <NUM> may estimate a line of best fit by evaluating the response ratio value for each of the last ten online responses that have been calculated. With reference to the previous example, the last ten online response might be (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>), meaning the corresponding values for the response ratio would be (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>). As can be seen, the response ratio is relative stable for the first five or six samples, but then progressively increases over the last five or six samples. This could indicate the behavior of the valve is becoming unstable, suggesting a potential problem with the valve.

As noted above, it is sometimes expected that online performance of the valve differs from offline performance. The system <NUM> can account for this expected difference in online and offline behavior by observing the trend of the response ratio over time. This trend or rate of change indicates whether the relationship between the offline response and the online response remains stable over time. That is, the offline and online responses may differ, but so long as the response ratio between the two remains relatively stable, the valve is likely in good condition. Said another way, a small or nonexistent rate of change of the response ratio indicates that the monitored valve <NUM> is exhibiting relatively consistent behavior over time. For example, a rate of change near zero may indicate that, relative to past performance, the valve <NUM> is opening or closing to expected positions in an expected amount of time in response to a given pressure exerted on the actuator <NUM>. Thus, when the rate of change does not exceed a threshold, which may be any suitable value (e.g., <NUM>), the system <NUM> continues collecting online data (block <NUM>).

However, if the rate of change of the response ratio exceeds a threshold (e.g., <NUM>), this indicates that the valve is deviating further and further from past performance. Consequently, if the rate of change exceeds a threshold, an alarm is generated (block <NUM>). Depending on the configuration, the alarm can be visual or audible in nature. The alarm can be displayed or sounded at an operator display, a display for a valve controller, etc..

Unless specifically stated otherwise, discussions herein using words such as "processing," " computing," "calculating," "determining," "identifying," "presenting," "displaying," or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.

Claim 1:
A method comprising:
receiving, by one or more processors (<NUM>), offline diagnostics data for a control valve (<NUM>-<NUM>, <NUM>-<NUM>, <NUM>), the offline diagnostics data describing a first relationship between pressure and valve position observed during a response of the control valve to a first control signal for a full range of travel when the control valve is not in service in a process plant (<NUM>);
calculating an offline response of the control valve using the offline diagnostics data;
receiving, by the one or more processors, online diagnostics data (<NUM>) for the control valve, the online diagnostics data describing a second relationship between pressure and valve position observed during a response of the control valve to a second control signal for a part of the full range of travel when the control valve is in service in the process plant;
calculating an online response of the control valve using the online diagnostics data;
calculating a response ratio based on the calculated offline and online responses;
analyzing a rate of change of the response ratio over time;
determining whether or not the rate of change of the response ratio exceeds a threshold value; and
in response to determining that the rate of change of the response ratio exceeds the threshold value, generating an indication to be provided to an operator via a user interface.