Diagnostics in a process control system

A diagnostic tool automatically collects and stores data indicative of a variability parameter, a mode parameter, a status parameter and a limit parameter associated with each of the different devices, loops or function blocks within a process control system, processes the collected data to determine which devices, loops or function blocks have problems that result in reduced performance of the process control system, displays a list of detected problems to an operator and then suggests the use of other, more specific diagnostic tools to further pinpoint or correct the problems. When the diagnostic tool recommends and executes a data intensive application as the further diagnostic tool, it automatically configures a controller of the process control network to collect the data needed for such a tool.

FIELD OF THE INVENTION
 The present invention relates generally to process control systems and,
 more particularly, to the automatic detection of problems existing within
 function blocks, devices and loops of a process control system.
 DESCRIPTION OF THE RELATED ART
 Process control systems, like those used in chemical, petroleum or other
 processes, typically include a centralized process controller
 communicatively coupled to at least one host or operator workstation and
 to one or more field devices via analog, digital or combined
 analog/digital buses. The field devices, which may be, for example valves,
 valve positioners, switches and transmitters (e.g., temperature, pressure
 and flow rate sensors), perform functions within the process such as
 opening or closing valves and measuring process parameters. The process
 controller receives signals indicative of process measurements made by the
 field devices and/or other information pertaining to the field devices,
 uses this information to implement a control routine and then generates
 control signals which are sent over the buses to the field devices to
 control the operation of the process. Information from the field devices
 and the controller is typically made available to one or more applications
 executed by the operator workstation to enable an operator to perform any
 desired function with respect to the process, such as viewing the current
 state of the process, modifying the operation of the process, etc.
 In the past, conventional field devices were used to send and receive
 analog (e.g., 4 to 20 milliamp) signals to and from the process controller
 via an analog bus or analog lines. These 4 to 20 ma signals were limited
 in nature in that they were indicative of measurements made by the device
 or of control signals generated by the controller required to control the
 operation of the device. However, in the past decade or so, smart field
 devices including a microprocessor and a memory have become prevalent in
 the process control industry. In addition to performing a primary function
 within the process, smart field devices store data pertaining to the
 device, communicate with the controller and/or other devices in a digital
 or combined digital and analog format, and perform secondary tasks such as
 self-calibration, identification, diagnostics, etc. A number of standard
 and open smart device communication protocols such as the HART.RTM.,
 PROFIBUS.RTM., WORLDFIP.RTM., Device-Net.RTM., and CAN protocols, have
 been developed to enable smart field devices made by different
 manufacturers to be used together within the same process control network.
 Moreover, there has been a move within the process control industry to
 decentralize process control functions. For example, the all-digital,
 two-wire bus protocol promulgated by the Fieldbus Foundation, known as the
 FOUNDATION.TM. Fieldbus (hereinafter "Fieldbus ") protocol uses function
 blocks located in different field devices to perform control operations
 previously performed within a centralized controller. In particular, each
 Fieldbus field device is capable of including and executing one or more
 function blocks, each of which receives inputs from and/or provides
 outputs to other function blocks (either within the same device or within
 different devices), and performs some process control operation, such as
 measuring or detecting a process parameter, controlling a device or
 performing a control operation, such as implementing a
 proportional-derivative-integral (PID) control routine. The different
 function blocks within a process control system are configured to
 communicate with each other (e.g., over a bus) to form one or more process
 control loops, the individual operations of which are spread throughout
 the process and are, thus, decentralized.
 With the advent of smart field devices, it is more important than ever to
 be able to quickly diagnose and correct problems that occur within a
 process control system, as the failure to detect and correct poorly
 performing loops and devices leads to sub-optimal performance of the
 process, which can be costly in terms of both the quality and the quantity
 of the product being produced. Many smart devices currently include
 self-diagnostic and/or calibration routines that can be used to detect and
 correct problems within the device. For example, the FieldVue and
 ValveLink devices made by Fisher Controls International Inc. have
 diagnostic capabilities that can be used to detect certain problems within
 those devices and also have calibration procedures that can be used to
 correct problems, once detected. However, an operator must suspect that a
 problem exists with the device before he or she is likely to use such
 diagnostic or calibration features of the devices. There are also other
 process control tools, such as auto-tuners that can be used to correct
 poorly tuned loops within a process control network. Again, however, it is
 necessary to identify a poorly operating loop before such auto-tuners can
 be used effectively. Similarly, there are other, more complex, diagnostic
 tools, such as expert systems, correlation analysis tools, spectrum
 analysis tools, neural networks, etc. which use process data collected for
 a device or a loop to detect problems therein. Unfortunately, these tools
 are data intensive and it is practically impossible to collect and store
 all of the high speed data required to implement such tools on each
 process control device or loop of a process control system in any kind of
 systematic manner. Thus, again, it is necessary to identify a problem loop
 or a device before being able to effectively use these tools.
 Still further, each device or function block within a smart process control
 network typically detects major errors that occur therein and sends a
 signal, such as an alarm or an event, to notify a controller or a host
 device that an error or some other problem has occurred. However, the
 occurrence of these alarms or events does not necessarily indicate a
 long-term problem with the device or loop that must be corrected, because
 these alarms or events may be generated in response to (or be caused by)
 other factors that were not a result of a poorly performing device or
 loop. Thus, the fact that a device or a function block within a loop
 generates an alarm or event does not necessarily mean that the device or
 loop has a problem that needs to be corrected. On the other hand, many
 devices can have problems without the problem rising to the level of
 severity to be detected as an alarm or an event.
 To initially detect problems within the process control system, a process
 control operator or technician generally has to perform a manual review of
 data generated within a process control system (such as alarms and events,
 as well as other device and loop data) to identify which devices or loops
 are operating sub-optimally or are improperly tuned. This manual review
 requires the operator to have a great deal of expertise in detecting
 problems based on raw data and, even with such expertise, the task can be
 time-consuming at best and overwhelming at worst. For example, an
 instrumentation department of even a medium-sized operating plant may
 include between 3,000 and 6,000 field devices such as valves and
 transmitters. In such an environment, the instrument technician or control
 engineer responsible for a process area simply does not have the time to
 review the operation of all the field device instrumentation and control
 loops to detect which loops or devices may not be operating properly or
 may have some problem therein. In fact, because of limited manpower, the
 only devices usually scheduled for maintenance are those that have
 degraded to the point that they dramatically impact the quantity or
 quality of the product being produced. As a result, other devices or loops
 which need to be retuned or which otherwise have a problem therein that
 could be corrected using the tools at hand are not corrected, leading to
 the overall degraded performance of the process control system.
 SUMMARY OF THE INVENTION
 A diagnostic tool for use in a process control system automatically
 collects and stores data pertaining to the different function blocks of
 devices and loops within the system, processes that data to determine
 which function blocks, devices, or loops have problems that may result in
 the reduced performance of the process control system, and then may
 suggest the use of other, more specific diagnostic tools to further
 analyze and correct the problem. The diagnostic tool may detect problems
 or identify poorly performing devices or loops using a variability
 indication, a mode indication, a status indication or a limit indication
 associated with each of the function blocks or devices within a process
 control system. The variability indication is preferably determined or
 partially determined by each function block within the process control
 system to provide a statistical measurement of the deviation of a
 parameter associated with the device or function block from a set point or
 other value associated with the device or function block. The mode
 indication identifies the mode in which a function block or device is
 operating, e.g., a normal mode or a non-normal mode, to indicate if the
 device or function block is operating in its designed mode. The status
 indication identifies the quality of a signal associated with the function
 block or device at any given time. The limit indication may identify if a
 function block signal is limited in nature.
 The diagnostic tool may determine which function blocks, devices or loops
 have problems associated therewith based on the instantaneous values or on
 a compilation of the historical values of one or more of the variability
 indication, the mode indication, the status indication, the limit
 indication or other data associated with each function block or device.
 Thereafter, the diagnostic tool may report detected problems to an
 operator via a display screen and/or may generate written reports (such as
 printed reports) or electronic reports sent, for example, over the
 internet (e.g., through E-mail) to concerned persons.
 Furthermore, upon detecting problems within one or more process control
 devices or loops, the diagnostic tool may suggest the proper tool(s) to be
 used to further pinpoint the problem and/or to correct the detected
 problem. If requested to do so, the diagnostic tool executes these further
 tools on a host workstation to enable an operator to perform further
 diagnostic functions. In cases where the diagnostic tool requires the use
 of further data intensive tools to diagnose or pinpoint a specific problem
 (such as an expert system or a correlation analysis tool), the diagnostic
 tool may automatically configure the host system to collect the data
 needed to run that further tool.
 In this manner, the diagnostic tool identifies the function blocks,
 devices, loops, etc. which need attention without requiring an operator to
 review massive amounts of data pertaining to numerous devices and loops
 within a process control system. This saves time on the part of the
 operator and does not require the operator to have a great deal of
 expertise in detecting problem loops and devices. Also, upon detecting a
 problem, the diagnostic tool may recommend the use of further tools to
 pinpoint and/or correct the problem, which enables the operator to correct
 problems without having to guess as to which tool is the most appropriate
 in any given situation. Besides saving time, this function reduces the
 burden on the operator and helps to assure that the proper diagnostic
 tools are used in each circumstance.

DESCRIPTION OF THE PREFERRED EMBODIMENTS
 Referring now to FIG. 1, a process control system 10 includes a process
 controller 12 connected to a host workstation or computer 13 (which may be
 any type of personal computer or workstation) having a display screen 14
 and connected to field devices 15-22 via input/output (I/O) cards 26 and
 28. The controller 12, which may be by way of example, the DeltaV.TM.
 controller sold by Fisher-Rosemount Systems, Inc., is communicatively
 connected to the host computer 13 via, for example, an ethernet connection
 and is communicatively connected to the field devices 15-22 using any
 desired hardware and software associated with, for example, standard 4-20
 ma devices and/or any smart communication protocol such as the Fieldbus
 protocol. The controller 12 implements or oversees a process control
 routine stored therein or otherwise associated therewith and communicates
 with the devices 15-22 and the host computer 13 to control a process in
 any desired manner.
 The field devices 15-22 may be any types of devices, such as sensors,
 valves, transmitters, positioners, etc. while the I/O cards 26 and 28 may
 be any types of I/O devices conforming to any desired communication or
 controller protocol. In the embodiment illustrated in FIG. 1, the field
 devices 15-18 are standard 4-20 ma devices that communicate over analog
 lines to the I/O card 26 while the field devices 19-22 are smart devices,
 such as Fieldbus field devices, that communicate over a digital bus to the
 I/O card 28 using Fieldbus protocol communications. Generally speaking,
 the Fieldbus protocol is an all-digital, serial, two-way communication
 protocol that provides a standardized physical interface to a two-wire
 loop or bus that interconnects field devices. The Fieldbus protocol
 provides, in effect, a local area network for field devices within a
 process, which enables these field devices to perform process control
 functions (using function blocks) at locations distributed throughout a
 process facility and to communicate with one another before and after the
 performance of these process control functions to implement an overall
 control strategy. It will be understood that, while the Fieldbus protocol
 is a relatively new all-digital communication protocol developed for use
 in process control networks, this protocol is known in the art and is
 described in detail in numerous articles, brochures and specifications
 published, distributed, and available from, among others, the Fieldbus
 Foundation, a not-for-profit organization headquartered in Austin, Texas.
 As a result, the details of the Fieldbus communication protocol will not
 be described in detail herein. Of course, the field devices 15-22 could
 conform to any other desired standard(s) or protocols besides the Fieldbus
 protocol, including any standards or protocols developed in the future.
 The controller 12 is configured to implement a control strategy using what
 are commonly referred to as function blocks, wherein each function block
 is a 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 10. 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
 10. Of course hybrid and other types of function blocks exist. Function
 blocks may be stored in and executed by the controller 12, which is
 typically the case when these function blocks are used for, or are
 associated with standard 4-20 ma devices and some types of smart field
 devices, or may be stored in and implemented by the field devices
 themselves, which is the case with Fieldbus devices. While the description
 of the control system is provided herein using function block control
 strategy, the control strategy could also be implemented or designed using
 other conventions, such as ladder logic.
 The left side of the controller 12 illustrated in FIG. 2 includes a
 schematic representation of interconnected function blocks 30, 32, and 34
 making up an example process control loop 36 configured to use the
 standard 4-20 ma devices 17 and 18. Because the function blocks 30, 32 and
 34 are related to the operation of 4-20 ma devices, these function blocks
 are stored in and executed by the controller 12. In a preferred
 embodiment, in which a DeltaV controller is used, the function blocks 30,
 32 and 34 are configured to be similar to, that is, to use the same or
 similar protocol, as Fieldbus function blocks. However, this convention is
 not necessary as other function block configurations could be used
 instead. As illustrated in FIG. 2, the function block 30 is an analog
 input (AI) function block that provides a measurement made by, for
 example, the transmitter (sensor) device 17, to the function block 32. The
 function block 32 is a PID function block that performs calculations using
 any desired PID strategy and delivers a control signal via a link to the
 function block 34, which is preferably an analog output (AO) function
 block. The AO function block 34 communicates with, for example, the valve
 device 18 to cause the valve 18 to open or close according to the control
 signal from the PID function block 32. The AO function block 34 also
 delivers a feedback signal, which may be indicative of the position of the
 valve 18, to the PID function block 32, which uses this feedback signal to
 generate the control signal. The controller 12 includes a device interface
 38 (which may be implemented in the controller 12 or in the I/O device 26
 of FIG. 1) to communicate with the devices 15-18 to get measurements made
 thereby and to deliver control signals thereto according to the control
 loop 36 or other control loops. The device interface 38 systematically
 receives signals from the devices 15-18 and delivers these signals to the
 proper function block within the controller 12 associated with the sending
 device. Likewise, the device interface 38 systematically delivers control
 signals from function blocks within the controller 12 to the proper field
 devices 15-18.
 The right side of the controller 12 in FIG. 2 illustrates a sample control
 loop 40 implemented using Fieldbus function blocks 42, 44 and 46 located
 down within the Fieldbus field devices 19 and 22. In this instance, the
 actual function blocks 42, 44, and 46 are stored in and executed by the
 field devices 19 and 22 and communicate their associated attributes to
 shadow function blocks 42S, 44S and 46S (illustrated as dotted-line boxes)
 within the controller 12. The shadow function blocks 42S, 44S and 46S are
 set up according to the function block configuration used by the
 controller 12 but mirror the state of the actual function blocks 42, 44
 and 46, respectively, so that it appears to the controller 12 that the
 actual functions associated with the function blocks 42, 44 and 46 are
 being executed by the controller 12. The use of shadow function blocks
 within the controller 12 enable the controller 12 to implement a control
 strategy using function blocks stored in and executed within the
 controller 12 as well as within field devices. Of course, the controller
 12 can implement control loops having both standard function blocks (like
 function blocks 30, 32 and 34) and shadow function blocks therein. For
 example, the PID shadow function block 44S, associated with the actual
 function block 44 in the valve positioner 22, could be linked to the AI
 function block 30 and the AO function block 34 to form a process control
 loop. The creation and implementation of shadow function blocks is not the
 subject of the present invention and is described in more detail in U.S.
 patent application Ser. No. 09/151,084 entitled "A Shadow Function Block
 Interface for Use in a Process Control Network," filed Sep. 10, 1998,
 which is assigned to the assignee of the present invention and the
 disclosure which is hereby expressly incorporated by reference herein.
 In one embodiment of the present invention, the controller 12 includes a
 diagnostic data collection unit 48 which may be, for example, a short term
 memory that collects and stores certain kinds of data associated with each
 of the function blocks (or shadow function blocks) of the process control
 system 10 for use in detecting problems with those function blocks, or the
 devices or loops associated with those function blocks. The data
 collection unit 48 may, for example, collect and store a variability
 indication, a mode indication, a status indication and/or a limit
 indication for each of the function blocks within the process control
 network 10. If desired, the data collection unit 48 may perform some
 processing on the collected data as described below. The data collection
 unit 48 periodically sends the collected or processed data to the operator
 workstation 13 via the ethernet connection for storage in a long term
 memory or historian 50 and for use by a diagnostic tool 52 located at
 least partially within the operator workstation 13. The diagnostic tool
 52, which is preferably implemented in software stored in a memory of the
 operator workstation 13 and executed by a processor 54 of the operator
 workstation 13, detects problems within the process control system 10,
 reports these problems and suggests tools for use in further analyzing and
 correcting these problems. If desired, portions of the diagnostic tool
 software can be executed within the controller 12 or even within the field
 devices.
 The diagnostic tool 52 systematically detects problems using one or more
 operating parameters of the function blocks or devices within the process
 control system 10 including, for example, a variability parameter, a mode
 parameter, a status parameter and a limit parameter determined by (or
 associated with) each of the function blocks or devices within the process
 control network 10. An indication of the variability parameter can be
 calculated or otherwise determined for each device or function block
 within the process control system (whether those function blocks are
 implemented within the controller 12 or down within one of the field
 devices 19-22) to indicate the error between two parameters of the
 function block. These two parameters may be different signals associated
 with the function block or may be two different measurements of the same
 signal. For example, for AI function blocks, the variability indication
 may indicate the error between a statistical measure (such as the mean,
 median, etc.) of the measurement made by a sensor over a predetermined
 amount of time and the actual or instantaneous value of the measurement.
 Similarly, for an AO function block, the variability indication may be
 calculated based on the differences between a historical statistical state
 of a device over a predetermined amount of time (such as the average
 location of the valve in a valve device) and the current state of the
 device (such as the current location of the valve). For control function
 blocks, such as PID, ratio, fuzzy logic function blocks and the like, the
 variability indication may be based on a deviation of a process parameter
 input to the function block and a set point or target provided to the
 function block for that parameter.
 In one embodiment, a variability index may be determined as the integrated
 absolute error (IAE) over a particular interval, such as a ten minute
 evaluation period. In such a case, the variability index can be calculated
 as:
 ##EQU1##
 wherein:
 N=the number of samples in the evaluation period;
 X(i)=the value of the ith sample of the desired function block parameter,
 such as the input to the function block for AI blocks and control blocks;
 and
 S=the statistical or target value of the parameter to which the function
 block parameter is compared, e.g., the set point (for control blocks), the
 average value of the function block parameter over the last evaluation
 period (for AI blocks), etc.
 If the variation between the X and S variables of equation (1) is Gaussian
 in nature, then the IAE is equal to the standard deviation times the
 square root of the product of two over pi. Of course, any other
 variability indication could be used in addition to or instead of the IAE
 calculation described above and, thus, the variability indication is not
 confined to that of equation (1).
 Preferably, each function block, and especially those located within the
 field devices 19-22, automatically calculates a variability indication
 over each evaluation period (e.g., over a predetermined amount of time or
 number of execution cycles) and, after each evaluation period, sends the
 calculated variability indication to the data collection device 48 within
 the controller 12 or to the data historian 50 within the operator
 workstation 13. This variation indication may be, for example, the
 variability index given above or may be subparts thereof which can be used
 to determine the variability index given above. If the function blocks are
 Fieldbus function blocks located within one of the field devices 19-22,
 then the variability indication may be sent to the controller 12 using
 asynchronous communications. While the final variability index for each
 function block could be completely calculated by the controller 12 or the
 operator workstation 13, this would require each function block to send
 data to such devices after every execution cycle (typically on the order
 of every 50-100 milliseconds), which would require a lot of additional
 communications over the buses of the process control network 10. To
 eliminate this additional communication, it is preferable to design each
 function block to calculate a variability indication therefor and then
 send this variability indication over the communication buses once every
 evaluation period, which will typically be on the order of once every
 minute, ten minutes or more. Currently, no known standard function blocks
 provide this capability and, therefore, it should be added to the function
 blocks used within the process control system 10.
 In one embodiment, the calculations for a final variability index
 associated with a function block are split between the function block and
 the diagnostic tool 52. In particular, because the computation of the
 variability index takes computing resources, the most computationally
 consuming parts of these calculations are done in the workstation 13 or
 the controller 12. For this discussion, the calculations for a variability
 index for input and output blocks will be referred to simply as a
 variability index (VI) while the variability index for control function
 blocks will be 10 referred to as a control index (CI). The VI (which is
 used for input blocks, output blocks and control blocks in manual mode)
 and the CI (which is used for control blocks in auto mode) can be
 calculated by the workstation 13 or the controller 12 as follows:
 ##EQU2##
 wherein:
 S.sub.lq =minimum standard deviation expected with feedback control;
 S.sub.tot =actual measured standard deviation; and
 S=sensitivity factor used to make the calculations stable.
 S.sub.lq may be calculated as:
 ##EQU3##
 wherein:
 S.sub.capab =estimated capability standard deviation (standard deviation at
 process ideal operation).
 A small bias value s is added to the S.sub.capab and S.sub.tot values in
 equations (2) and (3) because it has been discovered that, if the
 disturbance to noise signal ratio (i.e., the low frequency to high
 frequency disturbance ratio) is too high, the VI and CI calculations give
 too high of values. Fast sampling with very small differences between
 consecutive measurements also attributes to this problem. The bias value
 s, it has been found, makes the computations stable. The recommended bias
 value s is 0.1% of the measurement range (approximately the measurement
 accuracy). It will be understood that a valve of zero for the VI or CI
 calculations of equations (2) and (3) is the best case while a value of
 one is the worst case. However, these or other variability indices could
 be calculated so that a value of one (or even some other value) is the
 best case.
 If desired, a percent improvement (PI) value can be established for the
 control blocks as 100 times the CI value for the control block.
 To perform the above VI, CI and PI calculations in the most efficient
 manner possible, each of the function blocks in, for example, the DeltaV
 environment or the Fieldbus environment may calculate the S.sub.capab and
 S.sub.tot values as variability indications and make these values visible
 to the controller 12, which can then calculate the VI and CI values using
 equations (2) and (3) or can provide the S.sub.capab and S.sub.tot values
 to the diagnostic tool 52 in the workstation 13 which can calculate the VI
 and CI values. The intermediate calculations needed to determine the
 S.sub.capab and S.sub.tot values will be performed each execution of the
 function block and the S.sub.capab and S.sub.tot values will be updated
 once every N executions of the function block (i.e., once every evaluation
 period). In one implementation, the S.sub.capab and S.sub.tot values may
 be updated after 100 executions of the function block.
 The total standard deviation S.sub.tot can be calculated in the function
 block using the so-called moving time window computation as follows:
EQU S.sub.tot.ident.1.25 MAE (5)
 wherein MAE is the mean absolute error calculated as:
 ##EQU4##
 and wherein:
 N=the number of executions in an evaluation period;
 y(t)=the value of the t'th instantaneous sample of the desired function
 block parameter, such as the input to the function block; and
 y.sub.st =the statistical or target value of the parameter to which the
 function block parameter is compared, e.g., the average or mean value of
 the function block parameter over the last evaluation period.
 Generally speaking, the process value (PV) of the function block will be
 used in the I/O blocks to calculate y.sub.st. In control blocks, either
 the working setpoint or the PV will be used as Y.sub.st depending on the
 block mode.
 The capability standard deviation, S.sub.capab, can be calculated as
 follows:
 ##EQU5##
 wherein MR is the average moving range, which may be calculated as:
 ##EQU6##
 To reduce computations, only the summing component associated with the MAE
 and MR will be done during each execution cycle of the function block. The
 division of the sum by N or N-1 can be done as part of the S.sub.tot and
 S.sub.capab calculations once every N executions (i.e., once every
 evaluation period). From the above formulas it is evident that:
 ##EQU7##
 wherein the Error.sub.abs and the Delta.sub.abs are the summations in
 equations (6) and (8) respectively and are calculated on an ongoing basis
 during each execution cycle of the function block.
 Of course, the quality of the input to the function block used in these
 calculations is important and, thus, it is desirable to only use data that
 has good status and data that is not limited. When using Fieldbus or
 DeltaV function blocks, the mode variable takes the status of the PV, set
 point and BackCalibration variables into account, and so the mode variable
 can be used to assure proper calculations for the variability index. For
 example, in the OOS (out of service) mode, the S.sub.toot and S.sub.capab
 variables are not determined but are, instead, set to the best case valve
 (e.g., zero) to prevent the detection of an error. On warm starts, if the
 mode changes from OOS to any other mode, the S.sub.tot and S.sub.capab
 variables can be set to zero (a best case value), the scan counter can be
 reset and the Error.sub.abs and Data.sub.abs variables of equations (9)
 and (10) can be set to zero. Also, the previous values of y and y.sub.st
 should be reset.
 FIG. 3 illustrates a function block 55 having an input 56, an output 57 and
 a variability indication generator 58 connected to the input 56. If
 desired the variability indication generator 58 may be additionally or
 alternatively connected to the output 57 and/or to other parts of the
 function block 55 to receive other function block parameters or signals
 (these connections being illustrated by dotted lines in FIG. 3). If the
 function block 55 is, for example, a control function block, the
 variability index calculator 58 receives the input 56 (which may be the
 process value that is being controlled by the loop in which the control
 block 55 operates) and compares that input to a set point previously
 supplied to the function block 55. The variability indication generator 58
 may determine the variability index according to equation (1) and send
 that index to a communicator 59 which sends the variability indication to
 the controller 12 every evaluation period (every N samples). However, as
 described above, the variability indication generator 58 may determine the
 S.sub.tot and S.sub.capab values in the manner described above and send
 these values to the controller 12 or workstation 13, which can determine
 the VI and/or CI values therefrom. If the function block 55 is a function
 block being executed within the controller 12, the controller 12 could
 include a separate routine to determine the variability indication for
 each function block, as no bus communications would need to take place
 after each sample interval. The communicator 59 can be any standard
 communication unit associated with a function block or a communication
 protocol.
 A second function block operating parameter that may be used to determine
 problems within the process control system 10 is an indication of the mode
 in which each of the function blocks (or loops or devices) is operating.
 In the case of Fieldbus function blocks, as well as some other known
 function blocks, each function block has a mode parameter that is
 available to the controller 12 to indicate the mode in which the function
 block is operating. From this mode indication, a data analyzer within the
 diagnostic tool 52 can determine a value of the mode parameter to indicate
 if the function block (and thereby the loop, module or device) is
 operating in its desired or designed mode or, alternatively, if something
 has occurred to cause the function block (device or loop) to operate in a
 different, less preferable mode. Fieldbus function blocks operate in one
 of a number of modes. For example, AI function blocks operate in an
 out-of-service mode (wherein an operator may have put the device
 out-of-service to perform maintenance), a manual mode in which some
 signal, such as an output of the function block, is being set manually
 instead of based on the designed operation of the function block, and an
 automatic mode, in which the function block is operating in a normal
 manner, i.e., the way in which it was designed to operate. Fieldbus
 control blocks can also have one or more cascade modes wherein the mode is
 controlled by other function blocks or by an operator. Typically, Fieldbus
 function blocks have three modes variables associated therewith at any
 given time including a target mode, which is the mode in which the
 operator has set the block to operate (which can be other than the normal
 or automatic mode), an actual mode, which is the mode in which the control
 block is actually operating at any given time, and a normal mode, which is
 the mode in which the function block was designed to operate and is
 associated with the normal operation of the function block. Of course,
 these or other mode indications may be used as desired.
 The mode indication may be periodically provided to the controller 12
 and/or to the operator workstation 13. If the function block is within the
 controller 12, the mode indication for each function block may be provided
 to the data collection unit 48 at any desired time or interval. For
 Fieldbus function blocks or other function blocks within the field
 devices, the controller 12 may periodically request the mode parameters
 for each function block using a ViewList request (in the Fieldbus
 protocol). If desired, the data collection unit 48 within the controller
 12 may store the mode at each sampling period or evaluation period and
 provide the stored data to the data historian 50. Thereafter, the
 diagnostic tool 52 may determine mode values indicating when or how long
 the function block spent in the different modes or in a normal mode (or a
 non-normal mode) or indicating what percent of a specific time period the
 function block was in a normal mode (or a non-normal mode). Alternatively,
 the data collection unit 48 or some other specifically designed unit
 within the controller 12 could detect when each function block is out of
 its normal mode (by, for example, comparing the function block's normal
 mode with its actual mode at any given time). In this case, the data
 collection unit 48 could communicate the mode of any function block by
 indicating when changes in the mode took place or are detected, which
 reduces the amount of communication needed between the controller 12 and
 the operator workstation 13.
 A status parameter is another function block operating parameter that may
 be used to detect problems within process control devices and loops. A
 status indication provided by each function block may define or identify
 the status of the primary value (PV) associated with the function block or
 device. In addition or alternatively, one or more of the inputs and
 outputs of a function block may have a status indication associated
 therewith. Fieldbus function blocks have a status parameter associated
 therewith which can take on the form of "good", "bad" or "uncertain" to
 indicate the status of the function block PV, inputs and/or outputs. A
 status indication may also identify or include a limit indication, such as
 the limits associated with the PV or other function block parameter. Thus,
 for example, the limit indication may indicate whether the PV of the
 function block is high or low limited. Again, the diagnostic tool 52 may
 determine status values or limit values indicating when, how long or what
 percent of a specific time period the status of the function block was a
 normal status (or a non-normal status), and when, how long or what percent
 of a specific time period a function block variable was at one or more
 limits (or not at the one or more limits), or was a bad status or a
 questionable status.
 Similar to the mode indication, the status indication and the limit
 indication may be sent by each function block to the controller 12
 periodically or on request (using, for example, the ViewList command in
 the Fieldbus protocol) and changes therein may determined by the
 controller 12 and sent to the operator workstation 13. Alternatively, the
 status and limit indications may be sent to the operator workstation 13
 without being processed. If desired, the function blocks may be set up to
 communicate mode, status and/or limit indications only when changes
 therein actually take place, which further reduces the amount of
 communications between the controller 12 and the function blocks within
 field devices. However, when using this communication scheme, the current
 state of all the required parameters is needed to establish a base against
 which to compare the changes when the diagnostic tool 52 is first placed
 on line. This current state may be measured or collected by having the
 controller 12 periodically report parameter values (even though they have
 not changed) or by having the diagnostic tool 52 cause the controller 12
 to report parameters defined for exception reporting. Based on the status
 of each of the function blocks, the diagnostic tool 52 can quickly
 identify measurements which are bad, and need attention (uncertain status)
 or which have been incorrectly calibrated because they have a measurement
 or PV that is limited. Of course, the status and limit indications may
 take on one of any different number and types of values, depending on the
 type of system in which they are being used.
 Furthermore, a status indication may be used for any different variables
 (other than the PV) of a function block, device or loop. For example, in a
 control loop having feedback control, the status of the feedback variable
 may be used to detect problems within function blocks and loops. The
 status of this feedback variable (e.g., the back calibration or BackCal
 variable for control or actuator function blocks in the Fieldbus
 protocol), or any other variable, can be examined by the diagnostic tool
 52 to detect when a function block has an output that is limited by, for
 example, a downstream function block or other downstream condition.
 Similar to the mode indication, the controller 12 may detect and store
 actual status values or may store changes in the status values as the
 status indication.
 Other data associated with a process control function block, device or loop
 may be used to detect problems as well. For example, the operator
 workstation 13 (or the controller 12) may receive, store and review events
 and alarms generated by the devices or function blocks within the process
 control network 10. In, for example, the Fieldbus environment, function
 blocks support a block error parameter that reports abnormal processing
 conditions detected by a transducer or a function block. Fieldbus devices
 reflect any problem that is detected by the device or function block using
 one of 16 defined bits in a block error bitstream sent to the controller
 12. Fieldbus devices report the first detected problem to the controller
 12 as an event or alarm and these events or alarms can be forwarded by the
 controller 12 to an operator workstation 14 event journal. In one
 embodiment, the diagnostic tool 52 analyzes or reviews the 6th bit of the
 block error parameter (in the Fieldbus protocol) to detect when a device
 needs maintenance soon and, thus, when a condition exists that must be
 addressed but which is not currently limiting device operation. Similarly,
 the diagnostic tool 52 analyzes the 13th bit of the block error parameter
 (in the Fieldbus protocol) to determine when correct device operation is
 not possible because of a condition detected by the device and, thus,
 immediate action is required. Of course, other events, alarms, other bits
 within the block error parameter or other types of error indications may
 be used by the diagnostic tool 52 to detect problems associated with the
 operation of the process control network 10, and such other events, alarms
 etc. may be associated with the Fieldbus protocol or any other desired
 device or controller protocol.
 In some instances, function blocks may have parameters, such as mode or
 status parameters that are set to other than normal or good for reasons
 unrelated to the correct operation of the process or loop in which these
 function blocks operate. For example, in batch processes, when a batch is
 not being run, the modes of the function blocks used within that process
 are set to non-normal values. However, it would be undesirable to detect
 these non-normal mode (or status) indications and identify problems with
 the system based thereon because the batch process is designed to have
 down times. It is preferable, therefore, to provide each function block
 (or the module or loop in which it is run) with an application state
 parameter indicating if the function block (or module) is purposely in a
 non-normal mode, or has a bad status. In other words, the application
 state parameter will indicate when alarming or problem detection for the
 function block should be prevented. For function blocks used in batch
 processes, for example, the application state parameter will be set to one
 value to indicate when the function blocks are operating to perform a
 batch run application and will be set to another value to indicate when
 the function blocks are purposely not being used to perform a normal
 function within a batch run application and so no detection of problems
 should be based on the operations of these function blocks at these times.
 Such an application state parameter is illustrated in FIG. 3 to be
 communicated to the controller 12 via the communicator 59. The controller
 12 and/or operator workstation 13 may detect the application state
 parameter for each function block and ignore data (such as variability,
 mode, status and limit data) associated with function blocks that are in
 the second category, e.g., that are purposely set to non-normal or bad
 states, in order to prevent false alarms. Of course, there are other
 reasons that the application state parameter may be set to prevent
 detection of problems besides the down time associated with batch
 processes.
 The diagnostic tool 52 is preferably implemented in software within the
 operator workstation 14 and, if necessary, some parts may be implemented
 in the controller 12 and even down within the field devices, such as the
 field devices 19-22. FIG. 4 illustrates a block diagram of a software
 routine 60 that may be executed in the operator workstation 14 to detect
 and help correct problem function blocks, devices, loops or other entities
 within the process control network 10. Generally speaking, the software
 routine 60 collects data pertaining to each of the function blocks within
 a process, such as variability indication, mode indications, status
 indications, limit indications, alarm or event information, etc., on an
 ongoing basis as the process is running and detects the existence of
 problem measurements, calculations, control loops, etc. based on the
 collected data. The software routine 60 may send a report or create a
 display listing each detected problem and its economic impact on plant
 operation when configured or requested to do so. When viewing a display of
 the detected problem loops on, for example, the display 14 of the operator
 workstation 13, an operator can select a particular problem for review or
 correction. The software routine 60 then suggests and may automatically
 implement other diagnostic tools to further pinpoint the problem or to
 correct the problem. In this manner, the diagnostic tool 52 processes data
 generated by the function blocks or devices of a process control system,
 automatically recognizes problems based on the data and then suggests and
 executes other diagnostic tools to further pinpoint the cause of the
 problem and to correct the problem. This saves the operator enormous
 amounts of time and effort in detecting and correcting problems within a
 process control system and also helps to assure that the appropriate
 diagnostic tools (which may not be totally familiar to the operator) are
 used to correct the problem.
 A block 62 of the routine 60 receives and stores the variability, mode,
 status, limit, alarm, event and other data used to detect problems within
 devices, blocks and loops of the process control system 10 on an ongoing
 basis, i.e., whenever the process is running. Preferably, this data is
 stored in the data historian 50 within the operator workstation 13.
 Alternatively, however, this data could be stored in any other desired
 memory, such an in a memory associated with the controller 12. Likewise,
 this data may be sent to the operator workstation 13 in any format and may
 be sent as compressed data, if so desired.
 A block 63 detects or determines when an analysis of the data is to be
 performed because, for example, a periodic report is to be generated or
 because a user is requesting such an analysis. If no analysis is to be
 performed, the block 62 simply continues to collect data and may process
 that data to determine values for the function block operating parameters.
 If an analysis is to be performed, a block 64 analyzes the stored data or
 stored parameter values to determine which function blocks, devices or
 loops may be having problems. Generally speaking, the data may be analyzed
 based on the current or instantaneous values of the function block
 operating parameters, or may be analyzed on a historical basis to
 determine which function blocks, devices or loops are having problems over
 a specific period of time. The historical analysis helps to detect
 problems that are long term in nature based on the performance over a
 specified period of time. To detect a problem, the block 64 may, if
 necessary, calculate a variability index from the variability indications
 supplied by the function blocks and then compare the variability index to
 a specific range or limit (which may be set by the operator) to see if
 either the instantaneous value of, or some statistical measure of the
 historical value (such as the average or median value) of the variability
 index is outside of the range or above or below the specified limit for a
 function block. If so, a problem may exist and the function block, device
 or loop associated with the out-of-range variability index is listed as
 having a problem to be corrected.
 Likewise, the block 64 may compare the actual mode of a function block or
 device with the normal mode of that function block or device to see if
 they match. As indicated above, the controller 12 may perform this
 function and send indications of the result, or of mismatches to the
 historian 50. If desired, however, the operator workstation 13 may perform
 these comparisons directly. Using the historical data, the block 64 may
 determine loop utilization, i.e., the percent of time that the loop (or
 function block) operated in the designed (normal) mode. In the
 instantaneous analysis, the function block, loop or device may be
 considered to have a problem when it is currently not operating in the
 designed or normal mode.
 Similarly, the block 64 may analyze the status and limit indication(s) of
 each function block to determine when the status is bad or uncertain or
 otherwise not a designed or normal status or when a function block signal
 is at a limit. A historical analysis may calculate or determine if a
 particular function block has a status indication that is bad or uncertain
 for a predetermined percentage of a specified amount of time, may
 determine which PVs or other variables reached a limit or stayed at a
 limit for a predetermined percentage of a specified amount of time, or may
 analyze the status indication or limit indication in any other manner to
 determine if a problem exists within the function block or device or loop
 in which a function block is located. Likewise, the block 64 may
 determine, in an instantaneous evaluation, which function blocks, devices
 or loops have status values that are currently not in the designed or
 normal state and/or which signals or variables have reached a limit (i.e.,
 are value limited). The block 64 may review the alarm and event
 notifications to see if any devices need maintenance, either now or in the
 future. The blocks which exceed the variability or control index limits
 and the blocks which have an active bad, limited, or mode condition will
 be identified and temporarily saved. This summary information can support
 the creation of "current" summary display. The instantaneous values and
 conditions can be integrated by the diagnostic tool 52 on, for example, an
 hour, shift and daily basis to obtain the average value of variability
 index and the percent improvement and the percent time the bad status,
 limited signal or non-normal mode condition existed. Of course, the block
 64 may perform other types of processing on the variability, mode, status,
 limit, event, alarm and/or any other desired data to detect problems.
 Furthermore, the block 64 may run the analysis using different limits,
 ranges, historical times, etc., all of which may be set by a user or an
 operator.
 For function blocks used in, for example, batch mode processes, data
 associated with times when a function block intentionally was not
 operating is discarded or not used in the analysis based on the
 application state parameter for the function block.
 After the block 64 has detected the problems within the process control
 network, a block 66 determines if any written or electronic reports should
 be generated because, for example, periodic reports have been requested by
 a user. If so, a block 68 creates a report listing the problem function
 blocks, devices, loops, etc. and their economic effect on the process
 control system. Such an economic impact may be determined by having an
 operator or other user specify the dollar amount associated with each
 percentage point of reduced operation of the process or a loop in the
 process. Then, when a loop is found to have a problem, the actual
 performance of the process loop may be compared to a known optimum
 performance value to determine the percentage difference. This percentage
 difference is then multiplied by the specified dollar amount to percentage
 point ratio to determine the economic impact in terms of dollars. The
 report may be printed out on a printing device, displayed on a computer
 screen (such as the display 14) or other electronic display, sent to a
 user via E-mail, the Internet or any other local area or wide area
 network, or may be delivered to a user in any other desired manner. If
 desired, the diagnostic tool 52 may be configured to automatically notify
 a plant maintenance system whenever a problem loop is detected and this
 notification can be sent to the maintenance system as an event using the
 event/alarm capability of the known OPC interface.
 A block 70 determines if an operator has requested an analysis to be
 performed at the workstation 13 and, if so, a block 72 enters a display or
 dialog routine that enables a user to find out different information
 related to the problem or to select different parameters for performing
 the analysis. In one embodiment, an operator or other person that uses the
 diagnostic tool 52 is presented with a dialog when he or she logs onto the
 workstation 13. The dialog summarizes the conditions that need to be
 addressed in the system without identifying the loops that are the source
 of the problem. The dialog may convey the information in a graphical
 format such as on screen display 80 as shown in FIG. 5. The screen display
 80 summarizes the percent of total input, output or control function
 blocks in the process or plant that currently violate the default limits
 set for utilization (mode), limited signals, bad status or high
 variability. Because multiple conditions may exist in a single block, the
 total could potentially exceed 100%. If the total exceeds 100 percent,
 then the percent for each category can be scaled so that the total equals
 100 percent. Modules that have input, output, or control blocks that
 violate the preset limits are summarized in a tabular list 82. In FIG. 5,
 module FIC101 has one or more function blocks operating in undesigned
 modes and one or more function blocks with high variability, while the
 module LIC345 has one or more function blocks with bad status.
 More information about the nature of the problems, such as the limits
 associated with the function blocks, can be shown graphically by, for
 example, clicking on a module name within the list 82. Furthermore, by
 selecting a filter button 84 on the screen of FIG. 5, the user may be
 presented with a dialog allowing the user to select a summary time frame,
 the types of blocks to be included in the summary and the limit for each
 category or block. Such a dialog screen 86 is illustrated in FIG. 6, where
 the limits for the mode, limited, and bad status of input blocks are set
 at 99 percent utilization and where the limit for the variability index
 for input blocks is set at 1.3. In this case, the percent utilization of a
 block is determined as the percent of a specific time period in which the
 mode or status is normal and a function block signal was not limited.
 However, the limits could also be set as the percent of time that the mode
 or status was non-normal or a function block variable was at a limit, in
 which case the limits should be set closer to zero. Of course, by choosing
 all of the loop selections within the screen 86, all modules that include
 an input, output or control block will be included in the summary.
 A Timeframe box 88 of the screen 86 can be manipulated by changing the
 setting therein to alter the historical time frame for which the analysis
 is performed. For example, by choosing a "Now" selection within the
 Timeframe box 88, the instantaneous or current value of the block
 parameters are used to determine if each module will illustrated as a
 problem module in the summary list 82. While any time frame may be
 specified, some example time frames that can be used in filtering are the
 Current Hour or Last Hour, Current Shift or Last Shift, Current Day or
 Last Day, etc. For these time frames, a module is included in the summary
 list only when a detected condition is present for a significant portion
 (i.e., a predetermined portion) of the selected time frame as defined by
 the limit condition.
 If desired, the user may change the limit values used for variability
 index, either per block or on a global basis. To facilitate setting
 variability limits, the user may select the desired limit to be changed
 and then may be provided with a choice of either editing that limit for a
 particular block or of setting that limit for all of the blocks
 simultaneously. When the user wants to set the variability limit for all
 of the blocks together, the user is presented with a dialog box that
 allows the variability limit to be set to the current value of a
 variability plus a specified bias provided by the user. Of course, the
 limits for variability, mode, status and limited variables may be applied
 to all of the function blocks within a module, an area, a system, or any
 other logical unit and may all be changed in a similar manner. Default
 limits may be initially provided for a configuration as 1.3 for
 variability index and 99% utilization for mode, limited and status
 indications. Of course, these default values may be changed from the
 module summary display as described above.
 By selecting a module name within the summary 82 of FIG. 5, the user can be
 provided a dialog screen having further details related to that module.
 Such a dialog screen 90 is illustrated in FIG. 7, for the module FIC101
 using the Last Shift time frame. The screen 90 illustrates the performance
 of a PID1 block and an AI1 block within the FIC101 module. The information
 provided in the screen 90 allows the user to easily identify the
 particular measurement, actuator, or control block that caused the module
 to be included in the summary and the percent time that the condition was
 detected. In particular, the percent of time of the last shift that a
 block was in its normal mode, normal status and not limited is illustrated
 in FIG. 7 as loop utilization. Of course, the screen of FIG. 7 could be
 configured to illustrate the percent of time during the last shift that a
 block was in a non-normal mode, or had a non-normal status or the percent
 of time in the last shift that a function block variable was at one or
 more limits. A measure of variation is shown for the blocks illustrated in
 FIG. 7 along with limits therefor. The variability measure in this case is
 calculated so that a value of one is the best case and values greater than
 one indicate more and more variability error. However, using the CI and VI
 calculations of equations (2) and (3) for the variability index will cause
 the variability index to be between zero and one, with zero being the best
 case. In this case, the variability limit should be set to be between zero
 and one. Furthermore, the percent improvement (PI) that is possible in a
 control loop is illustrated in FIG. 7 for control blocks, namely the PID1
 block. If desired, the percent utilization values that fall below (or
 above) the respective limits can be highlighted or otherwise marked to
 indicate the detected problem(s).
 Of course, any other screen display may be used to summarize which loops,
 devices, function blocks or measurements have a high variability index
 (such as being greater than a user specified limit), operate in a
 non-normal mode or have process measurements that have bad or uncertain
 status or that are limited. As noted above, using an historical analysis,
 the diagnostic tool 52 may provide displays for a specified time frame to
 identify devices, loops or function blocks that have a variability index,
 mode, status or limit variable that has changed significantly from its
 normal value. Of course, the diagnostic tool 52 may enable a user to
 choose how many and which tests should be used (and must be failed) before
 a process control condition is identified as having a problem associated
 therewith.
 Referring again to FIG. 4, when a user selects one of the function blocks
 in, for example, the display 90 of FIG. 7, a block 93 detects the
 selection of the problem function block and a block 94 displays a set of
 options to be used to correct the problem block or loop. For example, for
 control blocks, the diagnostic tool 52 may allow the user to use an
 autotuner or other tuner to tune a loop or may allow the user to perform
 trend analysis on the loop. By selecting the autotuner option, the
 diagnostic tool 52 automatically finds and executes the autotuner
 application for the selected control block or loop. However, when the
 trend option is selected, the workstation 13 will begin to collect
 trending data as describe hereinafter.
 For input or an output function blocks, the block 94 may allow the user to,
 for example, use a further diagnostic tool for that block or to perform
 trend analysis. If, for example, the selected input or output block is
 within a Fieldbus or Hart device, then selecting the diagnostics option
 will activate the diagnostic application for the associated transducer
 block using tools known in the art such as any device calibration tools.
 In a DeltaV environment, the asset management solutions (AMS) diagnostic
 tool manufactured and sold by Fisher-Rosemount can be used for this
 purpose to communicate with a device, to obtain specific information
 therewith and to implement diagnostics associated with the device. Of
 course, other tools or recommendations could be made as well. For example,
 for transmitter problems, or function blocks associated with transmitters,
 the block 94 may recommend that a device calibration be used to calibrate
 the transmitter while, for a valve, any of the valve diagnostic routines
 can be used to detect and possibly correct the specific problem within the
 valve. Generally speaking, the recommendations made by the block 94 may be
 determined based on whether the problem falls into one of a number of
 predetermined types of problems, the nature or identity of the source of
 the problem (e.g. whether it originated in a control or input function
 block, a transmitter or a valve, etc.) or any other desired criteria. Of
 course, any desired diagnostic tools can be used, including those now
 known or those developed in the future.
 If the specific nature of the problem is not easily detected from the
 variability, status, mode, limit or other data that pointed to the
 existence of a problem, the block 94 can recommend the use of other, more
 complex diagnostic tools, such as plotting routines, correlation (such as
 auto-correlation and cross-correlation) routines, spectrum analysis
 routines, expert analysis routines or any other desired routine or tools
 provided for the process control system 10. Of course, the diagnostic tool
 52 may recommend or suggest the use of more than one tool and allow the
 operator to choose which tool should be used in any situation.
 Furthermore, the block 94 may limit its suggestions to tools actually
 available within the process control network 10, e.g., those loaded onto
 the operator workstation 13, or may suggest tools that would have to be
 purchased or loaded into the process control system 10 before being used.
 Of course, the block 94 can also suggest the use of manual tools, i.e.,
 those which are not run on the operator workstation 13, controller 12 or
 one of the devices 15-28.
 After the block 94 recommends one or more further diagnostic tools, a block
 96 waits for a user to select a tool for implementation, and, upon
 receiving such an instruction from the operator, a block 98 finds and
 executes the selected tool to enable the operator to further analyze and
 pinpoint the cause of the problem or to fix the problem. After
 implementing the diagnostic tool, a block 100 enables the operator to
 select a different tool for the selected problem and a block 102 enables
 the operator to select a different problem.
 In one embodiment, the block 94 can recommend analysis tools typically
 referred to as trending applications that require the collection of a
 relatively large amount and/or a lot of samples of data before being able
 to be run. Examples of such trending applications include a correlation
 analysis, a neural network, a fuzzy logic control procedure, an adaptive
 tuning procedure, a spectrum analysis routine, etc. Unfortunately, when
 the diagnostic tool 52 detects problems, the data required for the
 trending tool is typically unavailable because this data was not
 previously collected. This data may be needed to be collected at a high
 frequency data rate that is not practically achievable using simple
 communications between the controller 12 and the workstation 13. As a
 result, when the operator selects a tool that requires the collection of
 this data (fast data), the block 98 may automatically configure the
 controller 12 to collect the necessary data from the process control
 system 10.
 When such data needs to be collected from Fieldbus function blocks or
 devices, i.e., from the devices via the Fieldbus bus, the controller 12
 may use one or more Fieldbus trend objects to collect the data, may bundle
 and store the collected data as packets of data, and may then send the
 packets of data to the operator workstation 13 at any desired time so that
 the fast data is delivered to the operator workstation 13 in a non-time
 critical manner. This operation reduces the communication load between the
 controller 12 and the operator workstation 13 for the collection of this
 data. Typically, a trend object is set up to collect a predetermined
 number of samples (e.g., 16) of any desired data pertaining to a function
 block and, when the predetermined number of samples has been collected,
 these samples are communicated to the controller 12 using asynchronous
 communications. The use of one or more trend objects 110 for Fieldbus
 function blocks is illustrated in FIG. 8. The trend object(s) 110 are used
 to collect and send desired data to the data collection device 48 within
 the controller 12 and originate within the actual function blocks down
 within the Fieldbus devices. These trend objects 110 may be provided by
 the Fieldbus device or by the shadow function blocks (illustrated
 generally as shadow function blocks 112S in FIG. 8) within the controller
 12. Similarly, for function blocks located within and executed by the
 controller 12 (illustrated generally as function blocks 113 in FIG. 8),
 virtual trend objects 114 can be set up within the controller 12 to
 collect the desired data delivered from the 4-20 ma (or other devices).
 Samples for such virtual trend objects 114 may be collected at any desired
 rate, such as every 50 milliseconds. The virtual trend objects 114 may be
 configured to be similar to the actual trend objects of the Fieldbus
 protocol and are delivered to the data collection device 48. The data
 collection device 48 delivers the collected data to the data historian 50
 within the operator workstation 13 as noted above.
 The trend objects 110 and 114 are collected until enough data has been
 stored to run the desired diagnostic tool. After enough fast data has been
 collected, the block 98 of FIG. 4 executes or otherwise implements the
 further diagnostic tool using the collected data so as to perform high
 level processing and loop analysis.
 While the diagnostic tool 52 has been described as being used in
 conjunction with Fieldbus and standard 4-20 ma devices, it can be
 implemented using any other external process control communication
 protocol and may be used with any other types of function blocks or
 devices having function blocks therein. Moreover, it is noted that the use
 of the expression "function block" herein is not limited to what the
 Fieldbus protocol or the DeltaV controller protocol identifies as a
 function block but, instead, includes any other type of block, program,
 hardware, firmware, etc., associated with any type of control system
 and/or communication protocol that can be used to implement some process
 control function. While function blocks typically take the form of objects
 within an object oriented programming environment, this need not be case.
 Although the diagnostic tool 52 described herein is preferably implemented
 in software, it may be implemented in hardware, firmware, etc., and may be
 implemented by any other processor associated with the process control
 system 10. Thus, the routine 60 described herein may be implemented in a
 standard multi-purpose CPU or on specifically designed hardware or
 firmware as desired. When implemented in software, the software routine
 may be stored in any computer readable memory such as on a magnetic disk,
 a laser disk, or other storage medium, in a RAM or ROM of a computer or
 processor, etc. Likewise, this software may be delivered to a user or a
 process control system via any known or desired delivery method including,
 for example, on a computer readable disk or other transportable computer
 storage mechanism or over a communication channel such as a telephone
 line, the internet, etc. (which are viewed as being the same as or
 interchangeable with providing such software via a transportable storage
 medium).
 Thus, while the present invention has been described with reference to
 specific examples, which are intended to be illustrative only and not to
 be limiting of the invention, it will be apparent to those of ordinary
 skill in the art that changes, additions or deletions may be made to the
 disclosed embodiments without departing from the spirit and scope of the
 invention.