MXPA00003216A - Remote diagnostics in a process control network having distributedcontrol functions - Google Patents

Abstract

A diagnostic system is adapted to perform device and process diagnostics in a process control network having a plurality of process control devices communicatively linked over a bus, wherein each of the devices is capable of preforming a process control function and of communicating over the bus using scheduled periodic communications. The diagnostic system is disposed in a first one of the devices and includes a signal generator that produces a diagnostic control signal, a communicator configured to deliver the diagnostic control signal to a second one of the devices using scheduled periodic communications, and an output signal receiver adapted to receive an output signal developed by the second device in response to the diagnostic control signal. The diagnostic system may use the received output signal to perform diagnostics or may send this signal to a host device for diagnostic analysis.

Description

REMOTE DIAGNOSIS IN A PROCESS CONTROL NETWORK THAT HAS CONTROL FUNCTIONS DISTRIBUTED FIELD OF THE INVENTION The present invention generally relates to a process control network and, more specifically, to a method of, and an apparatus for performing remote diagnostics in a process control network having distributed control functions.

DESCRIPTION OF THE RELATED TECHNIQUE Large processes such as chemical, oil, and other manufacturing and refining processes, include numerous field devices arranged in different locations to measure and control the parameters of a process so that control of the process is exercised in this manner. . These field devices can be, for example, detectors such as temperature, pressure and flow rate detectors, as well as control elements such as valves and switches. Historically, the process control industry was carried out through manual operations such as manual reading of level and pressure gauges, rotating valve wheels, etc., to operate the measurement and control field devices within a process. At the turn of the 20th century, the process control industry began using local pneumatic control, in which local pneumatic controllers, transmitters, and valve positioners were located in different locations within the process plant to exercise control of certain places on the floor. With the emergence of the distributed control system (DCS) based on a microprocessor in the 1970s, the use of distributed electronic process control in the process control industry became widespread. As is known, a distributed control system includes an analog or digital computer, such as a programmable logic controller, connected to numerous electronic control and monitoring devices, such as electronic detectors, transmitters, current-to-pressure transducers, positioners valves, etc., located through a process. The DCS computer stores and implements a centralized and, often, complex control scheme to perform the measurement and control of devices within the process in order to control the parameters of the process in accordance with some general control scheme. Generally, however, the control scheme implemented by a distributed control system is owned by the DCS controller manufacturer which, in turn, makes the possibility of extending, updating, reprogramming and servicing the system more difficult and costly. of distributed control because the supplier of the distributed control system must be involved in an integral way to carry out any of these activities. In addition, equipment that can be used by or connected to any particular DCS may be limited due to the ownership nature of the DCS controller and the fact that the DCS controller provider may not support certain devices or functions of the DCS controller. devices manufactured by other suppliers. To overcome some of the problems inherent in the use of patented distributed control systems, the process control industry has developed a number of standard open communication protocols, including, for example, the HART®, PROFIBUS®, ORLDFIP®, Device protocols. -Net®, and CAN, which allow other field devices made by different manufacturers to be used together, within the same process control network. In fact, you can use any field device that conforms to one of these protocols, within a process to communicate and be controlled by a DCS controller or any controller that supports the protocol, even if that field device has been made by a manufacturer other than the controller manufacturer DCS. On the other hand, there is now a movement within the process control industry to decentralize process control and, in this way, simplify DCS controllers or substantially eliminate the need for DCS controllers. Decentralized control is obtained by having established the process control devices, such as valve positioners, transmitters, etc., to perform one or more process control functions and then communicate the data through a busbar structure to be used by other process control devices in the performance of other control functions. To implement these control functions, each of the process control devices includes a microprocessor that has the capability to perform a control function, as well as the ability to communicate with other process control devices that use a standard and open protocol. Communication. In this way, field devices made by different manufacturers can be interconnected within a process control network to communicate with one another and to perform one or more process control functions that form a control cycle without the intervention of a DCS controller. The protocol of the double cable bus, all digital, which is currently being promulgated by the Fieldbus Foundation, known as the FOUNDATION1 ^ Fieldbus protocol (hereinafter "Fieldbus") is an open communication protocol that allows them to Devices made by different manufacturers interoperate and communicate with each other through a standard busbar to exercise decentralized control within a process. As previously indicated, the decentralization of process control functions simplifies and, in some cases, eliminates the need for a patented DCS controller, which, in turn, reduces the need for a process operator to depend on the manufacturer of the process. DCS controller to change or update a control scheme implemented by the DCS controller. However, decentralized control also makes it even more difficult to carry out diagnostics, such as process diagnostics, which the DCS controller has typically done. In a standard DCS environment, a computer (such as a personal computer) is coupled to the network and performs device diagnostics on, for example, a valve or a combination of positioner / valve, by sending a control signal Diagnostic for the positioner, which then forces the valve through a test stroke or test cycle associated with the diagnostic control signal. During this time, the computer measures the outputs of the positioner and / or the valve, such as changes in the position of the valve, that occur in response to the diagnostic control signal and, thereafter, performs the analysis of the measured outputs to determine the operation condition of the valve or of the positioning / valve device. A standard DCS controller or other computer device generally carries out process diagnostics by sending a diagnostic control signal to a device, such as a positioner, to cause a controlled change within a process, which measures one or more parameters of the process in that or in other locations within the process, and then analyze the process parameters measured to determine the operation condition of the process. In a standard DCS environment, diagnostics can be performed without rewiring or reconfiguring the system because the DCS controller (or other computer) is already configured to control the set points (or other inputs) of the different devices within the process, and to measure device outputs and other process parameters to implement a control strategy associated with the normal operation of the process. As a result, the operating diagnostics in a standard DCS environment are really a matter of using the DCS controller or a specially configured computer in a slightly different way, to control one or more devices within the process and use the DCS controller or a computer to read the parameters of the process or device, as it is configured to be done. As a result, in a standard DCS environment, routines can be stored in and used by a centralized DCS controller or other computer to perform device or process diagnostics, and these diagnostic routines can be used without reconfiguration. the process control network in a significant way. Unfortunately, due to the centralized nature of these diagnostic routines, they do not provide much detailed information about individual field devices. However, in a process control network that has distributed control functions, a centralized system controller, to the extent that it exists, is not configured to individually control all field devices within a process and is not configured to receive the characteristic data of all the suitable devices or the parameters of the process that are necessary to carry out the diagnostics of the devices and of the process. Instead, different process control cycles of the control strategy are implemented by means of a number of communicatively linked devices, located in distributed locations within the process control network. Typically, these devices are configured to use scheduled periodic communications to communicate the data necessary for the implementation of specific control functions, associated with a process control cycle and to communicate other data (such as setpoint changes) using communications. aperiodic or asynchronous. As a result, in a process control network that has distributed control functions implemented using a diagnostic control signal to a process control device while the system is configured to implement the normal control strategy because the host computer must use asynchronous communications to deliver the diagnostic control signal and, therefore, has no way to control the precise time that the diagnostic control signal (or different parts there) arrives at the device being tested or controlled. In fact, when using asynchronous communications, a host computer has no way of knowing when the diagnostic control signal (or any part of it in particular) actually arrives at the input of the device being controlled. As a result, for a host computer to send a deterministic diagnostic control signal to a device in a process control network that has distributed control functions, the network control configuration must be reconfigured, which requires that the process is taken offline. Alternatively, some devices within a process control network that have distributed control functions have the capability to perform self-diagnostics and, therefore, do not need to be controlled by a host computer to carry out the diagnostics. However, these devices are typically more expensive and do not have the capability to perform diagnostics on other devices. Therefore, to perform device diagnostics in a process control network that has distributed control functions, a process operator must purchase a device with self-diagnostic capability for each location in which the diagnostics are to be performed, which is expensive, or the process operator must reconfigure network communication interconnections to allow a host computer to use the scheduled communications to send a diagnostic control signal to a device that is under test whenever it is going to perform a diagnosis of a device or process, which is not desirable because the above requires the control strategy of the network that is to be reconfigured. On the other hand, it is very difficult for a main computer to make an exact diagnosis of the process in a process control network that has distributed control functions because, as previously indicated, the normal process control strategy must be reconfigured to allow the main computer to deterministically control a device, which, in turn, changes the way in which the variable measures of the process are produced. In other words, when the process control scheme is reconfigured to allow a host computer to control a device in a deterministic manner, the measured variables of the process during diagnosis are no longer indicative of the process under normal operation, but rather they are only indicative of the process under the diagnostic control scheme. As a result, the conclusions of the process diagnosis can not be indicative of the operation of the process during the normal operation of the process.

COMPENDIUM OF THE INVENTION The present invention is directed to a method of, and a device for carrying out device and process diagnostics on, or using another device within a process control network having distributed control functions, and to a method of, and a device to carry out process diagnostics while controlling a process essentially under the same control strategy as that implemented during the normal operation of the process.

The method and device of the present invention can be used by a process maintenance person to carry out the diagnosis of the device in a device that does not have the self-diagnosis characteristic, which, in turn,? Allows the process maintenance person to use cheaper devices in many locations within a process control network. On the other hand, the method and device of the present invention provide the diagnostic capability that can be implemented in a process control network without affecting the control strategy or the behavior of the process control network. In accordance with one aspect of the present invention, there is provided a diagnostic system for use in a process control network having a plurality of devices linked in communication over a busbar in a first device, and includes a signal generator which produces a diagnostic control signal, a communicator that supplies a diagnostic control signal to an input of a second device using scheduled periodic communications, and an output signal receiver developed by another device, such as a second device, in response to the diagnostic control signal. The diagnostic system may include a process signal receiver adapted to receive one or more process signals from other process control devices and a memory unit for storing the one or more process signals, the received output signal, and / or the diagnostic control signal. The diagnostic system can supply the stored process, the output, and / or the control signals to a third device capable of carrying out diagnostic analysis activities using the stored process, the output, and / or the control signals after which a process or a diagnosis of the device has been executed. On the other hand, the diagnostic system may include a signal input control adapted to receive the process control signal developed by a fourth device and a switch coupled to the control signal input and to the signal generator that supplies one of the control signals or the diagnostic control signal to the second device. In this case, a regeneration unit within the diagnostic system supplies the output signal received to the fourth device so that the fourth device uses it in the creation of the process control signal. When the device receiving the regeneration signal (ie the fourth device) includes a control function that is capable of operating in different modes, the diagnostic system preferably includes a drive unit mode that at least indirectly controls the mode of operation. the control function within the fourth device while sending the diagnostic control signal to the second device. In accordance with another aspect of the present invention, a diagnostic function block is provided for use in a process control network having a plurality of devices coupled in communication to a busbar, wherein each of the devices includes one or more function blocks capable of performing an input function, an output function, or a control function within the process control network, and where each of the devices is capable of communicating over the bus using communications scheduled journals. The diagnostic function block according to the present invention includes a signal generator that produces a diagnostic control signal, a communicator configured to communicate the diagnostic control signal to a second function block within a different process control device using the scheduled periodic communications, and a signal receiver that receives an output signal developed by another function block , such as a second function block, in response to the diagnostic control signal. In accordance with yet another additional aspect of the present invention, a method is provided for performing diagnostics for use in a process control network having a plurality of process control devices linked in communication over a busbar, wherein each of the devices includes one or more function blocks capable of performing a process control function within the process control network, and capable of communicating over the busbar using scheduled periodic communications. The diagnostic method according to the present invention includes the steps of connecting a first device, having a diagnostic function block that generates a diagnostic control signal in that, to the bus of the process control network that links a communication output of the diagnostic function block to a second function block in a second device that uses the scheduled periodic communications, and links in communication one output of the diagnostic function block to an output of another function block, such as a second function block, to receive the output signals developed by another function block in response to the diagnostic control signal. The method also includes the step of sending the diagnostic control signal to the second function block using the programmed periodic communications so that in this way it controls the operation of the second function block in accordance with the diagnostic control signal.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a schematic block diagram of an example of the process control network using the Fieldbus protocol.

Figure 2 is a schematic block diagram of Fieldbus devices that has a set of three function blocks therein. Figure 3 is a block diagram illustrating the function blocks within some of the devices of the process control network of Figure 1. Figure 4 is a schematic of a control cycle for the process control cycle within the process control network of Figure 1. Figure 5 is a time diagram for a macrocycle of a busbar segment of the process control network of Figure 1. Figure 6 is a schematic of a control cycle including a remote diagnostic device function block in accordance with the present invention. Figure 8 is a schematic block diagram of the diagnostic function block of Figure 7.

DESCRIPTION OF THE PREFERRED MODALITIES Although the remote diagnostics of the present invention are described in detail in conjunction with a process control network that implements the process control functions in a decentralized or distributed manner using Fieldbus devices, it should be noted that the Remote diagnostics of the present invention can be used with process control networks that perform distributed control functions that use other types of field devices and communication protocols, including protocols that rely on others other than busbars. two cables and protocols that support analog and digital communications. Therefore, for example, the remote diagnostics of the present invention can be used in any process control network that performs distributed control functions even if this process control network uses HART communication protocols, PROFIBUS, and so on, or any other communication protocol that currently exists or that may be developed in the future. Before entering into details of the remote diagnostics of the present invention, a general description of the Fieldbus protocol will be provided, the field devices configured in accordance with this protocol, and the manner in which communication occurs in a process control network that uses the Fieldbus protocol. However, it should be understood that, although the Fieldbus protocol is a relatively new digital all-communication that was developed for use in process control networks, this protocol is known and described in detail in numerous articles, brochures and sheets in the art. of published, distributed and available specifications from, among other sources, the Fieldbus Foundation, a non-profit organization that has its headquarters in Austin, Texas. In particular, the manuals "Communications Technical Specification" and "User Layer Technical Specification" of the Fieldbus Foundation, which are fully incorporated herein by reference, describe in detail the Fieldbus protocol, and the manner of communication with, and to store data on devices that use the Fieldbus protocol. The Fieldbus protocol is an all-digital, serial, two-way communication protocol that provides a standardized physical interface to a two-wire cycle or field equipment that interconnects the busbar such as detectors, triggers, controllers, valves, etc. located in an instrumentation or process control environment of, for example, a factory or a plant. The Fieldbus protocol provides, in effect, a local area network for field instruments (field devices) within a process, which allows these field devices to perform control functions in locations distributed throughout the facilities of process, and that they communicate with each other before and after performing these control functions to implement a general control strategy. Because the Fieldbus protocol allows the functions to be distributed across the process control network to be controlled, the workload is reduced, or completely eliminates the need for a centralized process controller typically associated with a Distributed control system. Referring to Figure 1, a process control network 10 using a Fieldbus protocol can include a host computer 12 connected to a number of other devices such as a program logic controller (PLC) 13, a number of controllers 14, another main computer device 15 and a set of field devices 16, 18, 20, 22, 24, 26, 28, 30 and 32 by means of a two-wire Fieldbus cycle or a busbar 34. Busbar 34 includes sections or different segments, 34a, 34b, and 34c, which are separated by bridge devices 30 and 32. Each of the sections 34a, 34b, and 34c are interconnected with a subset of devices adhered to the busbar 34 to allow communications between the devices in the manner described below. Of course, the network of Figure 1 is only illustrative, since there are not many other ways in which the process control network can be configured using the Fieldbus protocol. Typically, a configurator is located in one of the devices, such as the main computer 12, and is responsible for adjusting or configuring each of the devices (which are "intelligent" devices in the sense that they include a capable microprocessor). of performing the communication and, in some cases, controlling the functions), as well as of recognizing when new field devices are connected to the busbar 34, when field devices are removed from the busbar 34, recognizing the data generated by the field devices 16-32, and of placing interfaces with one or more user terminals, which may be located in the main computer 12 or in any device connected to the host 12 in any way. The busbar supports or. it allows purely digitized communication in both directions, and can also provide an energy signal to any or all devices connected to it, such as field devices 16-32. Alternatively, any of the devices 12-32 may have its own power source or may be connected to external power sources by means of separate cables (not shown). Although the devices 12-32 are illustrated in Figure 1 as being connected to the busbar 34 in a standard bus-type connection, in which many devices are connected to the same pair of wires that make up the segments 34a, 34b , and 34c of the busbar, the Fieldbus protocol allows other device / cable topologies that include point-to-point connections, in which each device is connected to a controller or a host computer, by means of a pair of two cables separately (similar or typical of 4-20 mA analog DCS systems), and tree or branch connections in which each device is connected to a common point in a two-wire bus that can be, for example, a junction box or a termination area in one of the field devices within a process control network. The data can be sent over the different segments 34a, 34b, and 34c of the busbar in the same or in different proportion or baud rate of communication in accordance with the Fieldbus protocol. For example, the Fieldbus protocol provides a communication speed (Hl) of 31.25 Kbits / second, which is illustrated as being used by the busbar segments 34b and 34c of the Figure 1, and a communication speed (H2) of 1.0 Mbit / s or 2.5 Mbit / s, which will typically be used for advanced process control, remote input / output, and high-speed factory automation applications, and is illustrated as being used by the busbar segments 34a of Figure 1. In the same way, the data can be sent over the busbar segments 34a, 34b, and 34c in accordance with the Fieldbus protocol using the voltage signaling mode or the current signaling mode. Of course, the maximum length of each segment of the bus 34 is not strictly limited but, instead, is determined by the communication speed, the type of cable, the size of the wire, the power option of the busbar, etcetera, of that section. The Fieldbus protocol classifies the devices that can be connected to bus 34 in three primary categories, namely, basic devices, master link devices, and bridge devices. The basic devices (such as devices 18, 20, 24, and 28 of Figure 1) can communicate, that is, send and receive communication signals, on or from bus 34, but are not able to control the order or the communication time that occurs in busbar 34. Master link devices (such as devices 16, 22, and 26, as well as host 12 of Figure 1) are devices that communicate over the busbar 34, and are able to control the flow of, and time of, the communication signals in the busbar 34. The bridge devices (such as devices 30 and 32 of Figure 1) are devices that have been configured to communicate over, and to interconnect individual segments or branches of a Fieldbus bus to create larger process control networks. If desired, bridging devices can convert between different data rates and / or different data signal formats that are used in different segments of the bus 34, they can amplify the signals that run between the bus segments 34 , can filter the flow of signals between - **%, the different segments of the busbar 34 and transmit only those signals intended to be received by a device in one of the segments of the busbar to which the bridge has been coupled, and / or may take other actions to link the different segments of the busbar 34. The bridge devices that connect the bus segments that operate at different speeds must have link master capabilities on the side of the lower speed segment of the bridge. The main computers 12 and 15, the program logic controller 13, and the controllers 14 can be any type of busbar device, but will typically be master link devices. Each of the devices 12-32 is able to communicate through the busbar 34 and, very importantly, is capable of independently performing one or more process control functions using the data acquired by means of the device, from the process, or from a different device, by means of communication signals in the busbar 34. The Fieldbus devices are, therefore, capable of directly implementing portions of a global control strategy which, in the past, were performed by a digital controller centralized of a distributed control system. To perform control functions, each Fieldbus device includes one or more standardized "blocks" that are implemented in a microprocessor inside the device. In particular, each Fieldbus device includes a resource block, zero or more function blocks, and zero or more transducer blocks. These blocks are referred to as block objects. A resource block stores and communicates device-specific data, which have to do with some of the characteristics of a Fieldbus device including, for example, a device type, a device revision indication, and indications of where another device can be obtained specific information of the device inside a device memory. Although different device manufacturers can store different types of data in the resource block of a field device, each field device that complies with the Fieldbus protocol includes a resource block that stores some data. A function block defines and implements an input function, an output function, or a control function associated with the field device and, in this way, function blocks are generally referred to as input function blocks, exit, and control. However, other categories of function blocks such as hybrid function blocks may exist or may be developed in the future. Each input or output function block produces at least one process control input (such as a process variable from a process measurement device), or process control output (such as a valve position sent to a device). activation), while each control function block uses an algorithm (which may be proprietary in nature), to produce one or more process outputs from one or more process inputs and control inputs. Examples of standard function blocks include analog input (AI) function blocks, analog output (AO), bias (B), control selector (CS), discrete input (DI), discrete output (DO), manual charger (ML), proportional / derivative (PD), proportional / integral / derivative (PID), proportion (RA), and signal selector (SS). However, there are other types of function blocks, and new types of function blocks can be defined or created to operate in the Fieldbus environment. A transducer block couples the inputs and outputs of a function block to local hardware devices, such as detectors and device triggers, to enable function blocks to read the outputs of local detectors, and to order local devices to perform one or more functions such as moving a valve member. The transducer blocks typically contain the information that is necessary to interpret the signals sent by means of a local device, and to appropriately control local hardware devices including, for example, information that identifies the type of a local device, calibration information associated with a local device, etcetera. A single transducer block is typically associated with each block of input or output functions. Most function blocks are capable of generating alarm or event indications based on previously determined criteria, and are capable of operating differently in different ways. Generally speaking, the function blocks can operate in an automatic mode, in which, for example, the algorithm of a function block operates automatically; an operator mode in which the input or output of a function block is controlled manually; an out-of-service mode in which the block does not operate; a cascade mode in which the operation of the block is affected from (determined by) the output of a different block; and one or more remote modes in which a remote computer determines the mode of the block. However, there are other modes of operation in the Fieldbus protocol. Importantly, each block is able to communicate with other blocks on the same or different field devices through the Fieldbus bus, using standard message formats defined by the Fieldbus protocol. As a result, combinations of function blocks (on the same or different devices) can communicate with each other to produce one or more decentralized control cycles. In this way, for example, a PID function block in a field device can be connected via the busbar 34 to receive an output of a function block AI in a second field device, to send data to a block of AO functions in the third field device, and to receive an output of the AO function block as feedback, to create a separate process control cycle apart from any DCS controller. In this way, the combinations of the function blocks move the control functions out of a centralized DCS environment, which allows the DCS multi-function controllers to perform supervision or coordination functions, or to eliminate them altogether. In addition, the function blocks provide a graphical structure, oriented to the blocks, for the easy configuration of a process, and to enable the distribution of functions between field devices of different suppliers, because these blocks use a consistent communication protocol . In addition to containing and implementing block objects, each field device includes one or more additional objects that include link objects, trend objects, alert objects, and view objects. The link objects define the links between the inputs and outputs of the blocks (such as the function blocks) both internal to the field device and through the fieldbus bus 34. The trend objects allow to indicate the tendency of the function block parameters to be accessed by other devices such as the main computer 12 or the controllers 14 of Figure 1. The trend objects retain short-term historical data related to some, for example, function block parameter, and report this data to other devices or function blocks via bus 34 in an asynchronous manner. The alert objects report alarms and events through the busbar 34. These alarms or events can be related to any event that occurs inside the device or one of the blocks of a device. View objects are pre-defined groupings of block parameters that are used in the standard human / machine interface, and can be sent to other devices to view them from time to time. Referring now to Figure 2, three Fieldbus devices are illustrated, which may be, for example, any of the field devices 16-28 of Figure 1, as if they included resource blocks 48, function blocks 50, 51, or 52 and transducer blocks 53 and 54. In the first device, the function block 50 (which may be a block of input functions) is coupled through the transducer block 53 to a detector 55, which may be, for example, a temperature detector, a set point indication detector, and so on. In the second device, the function block 51 (which can be a block of output functions) is coupled through the transducer block 54 to an output device such as a valve 56. In the third device, the function block 52 (which may be a control function block) has a trend object 57 associated with it to indicate the trend of the input parameter of the function block 52. The link objects 58 define the block parameters of each of the associated blocks, and the alert objects 59 provide alarms or alarm notifications for each of the associated blocks. The view objects 60 are associated with each of the function blocks 50, 51, and 52 and include or group lists of data for the function blocks with which these are associated. These lists contain the necessary information for each of a set of different defined views. Of course, the devices of Figure 2 are merely exemplary, and other numbers of, and types of block objects, link objects, alert objects, trend objects, and view objects can be provided in any field device. Referring now to Figure 3, a block diagram of process control network 10 illustrating devices 16, 18, and 24 as positioner / valve devices and devices 20, 22, 26, and 28 as transmitters, also illustrates the function blocks associated with the positioner / valve 16, the transmitter 20, and the bridge 30. As illustrated in Figure 3, the positioner / valve 16 includes a resource block (RSC) 61, a transducer block (XDCR) ) 62, and a number of function blocks that include an analog output function block (AO), two PID function blocks 64 and 65, and a signal selection function block (SS) 69. The transmitter 20 includes a resource block 61, two transducer blocks 62, and two analog input function blocks (AI) 66 and 67. In addition, the bridge 30 includes a resource block 61 and a PID function block 68. As will be understood, the different function blocks of Figure 3 can operate together (by communication through the busbar 34) in many control cycles, and in FIG. 3 the control cycles in which the function blocks of the positioner / valve 16, the transmitter 20, and the control unit are located are identified. bridge 30, by means of a cycle identification block connected to each of these function blocks. In this way, as illustrated in FIG. 3, the function block AO 63 and the PID function block 64 of the positioner / valve 16, and the function block AI 66 of the transmitter 20 are connected within an indicated control cycle. as L00P1, while the function block SS 69 of the positioner / valve 16, the function block AI 67 of the transmitter 20, and the PID function block 68 of the bridge 30 are connected in a control cycle indicated as L00P2. The other PID function block 65 of the positioner / valve 16 is connected within a control cycle indicated as L00P3. The blocks of interconnected • functions that make up the control cycle indicated as LOOP1 in Figure 3, are illustrated in more detail in the schematic of this control cycle illustrated in Figure 4. As can be seen from Figure 4, the cycle The LOOP1 control is completely formed by communication links between the function block AO 63 and the PID function block 64 of the positioner / valve 16 and the function block AI 66 of the transmitter 20 (FIG. 3). The control cycle diagram in Figure 4 illustrates the communication interconnections between these function blocks using lines connecting the process and control inputs and outputs of these function blocks. In this way, the output of the function block AI 66, which may comprise a process measurement or process parameter signal, is communicatively coupled by means of the busbar segment 34b, to the input of the PID function block 64. having an output comprising a control signal communicatively coupled to an input of the function block AO 63. An output of the function block AO 63, comprising a feedback signal indicating, for example, the position of the valves 16, is connected to a control input of the PID 64 function block. The PID 64 function block uses this feedback signal together with the process measurement signal of the AI 66 function block to implement the appropriate control of the AO function block 63. Of course, the connections indicated by the lines in the control cycle diagram of Figure 4 can be made internally inside a field device. or when, as with the case of function blocks AO and PID 63 and 64, the function blocks are inside the same field device (for example, the positioner / valve 16), or these connections can be implemented through the two-wire communication bus 34, using standard Fieldbus synchronous communications. Of course, other function blocks that are communicatively interconnected in other configurations implement other control cycles. To implement and carry out communication and control activities, the Fieldbus protocol uses three general categories of technology, identified as a physical layer, a communication "stack", and a user layer. The user layer includes the control and configuration functions provided in the form of blocks (such as function blocks), and objects within any particular process control device or field device. The user layer is typically designed in a proprietary manner by the device manufacturer, but must be capable of receiving and sending messages in accordance with the standard message format defined by the Fieldbus protocol, and of being configured by a user in a manner standards The physical layer and the communication stack are necessary to effect communication between different blocks of different field devices in a standardized way, using the two-wire busbar 34, and can be molded by means of the well-known layer communication model Open Systems Interconnection (abbreviations in English for Open Systems Interconnect). The physical layer, which corresponds to the OSI layer 1, is embedded in each field device and the busbar 34, and operates to convert the electromagnetic signals received from the Fieldbus transmission medium (the two-wire busbar 34) to messages capable of being used by the communication stack of the field device. The physical layer can be considered as the busbar 34 and the electromagnetic signals present in the busbar 34 at the inputs and outputs of the field devices.

The communication stack, which is present in each Fieldbus device, includes a data link layer, which corresponds to the OSI 2 layer, a Fieldbus access sublayer, and a Fieldbus message specification layer, which corresponds to the OSI layer 6. There is no corresponding structure for the OSI 3-5 layers in the Fieldbus protocol. However, applications of a Fieldbus device comprise a layer 7 while a user layer is a layer 8, not defined in the OSI protocol. Each layer in the communication stack is responsible for encoding or decoding a portion of the message or signal that is transmitted in the Fieldbus bus 34. As a result, each layer of the communication stack adds or removes certain portions of the Fieldbus signal such as preambles, start delimiters, and end delimiters and, in some cases, decodes the stripped portions of the Fieldbus signal, to identify where the rest of the signal or message must be sent, or the signal must be discarded because, for example, it contains a message or data for function blocks that are not inside the receiving field device. The data link layer controls the transmission of messages on the busbar 34, and manages the access to the busbar 34, in accordance with the deterministic centralized bus controller, called an active link scheduler, which is to be described. in more detail later. The data link layer removes a preamble from the signals in the transmission medium, and can use the received preamble to synchronize the internal clock of the field device with the incoming Fieldbus signal. In the same way, the data link layer converts the messages in the communication stack to physical Fieldbus signals, and encodes these signals with clock information to produce a "synchronous series" signal having a suitable preamble for transmission in the busbar 34 of two cables. During the decoding process, the data link layer recognizes the special codes inside the preamble, such as start delimiters and end delimiters, to identify the start and end of a particular Fieldbus message, and can perform a checksum to verify the integrity of the signal or the message received from the busbar 34. In the same way, the data link layer transmits the Fieldbus signals in the busbar 34, by adding start and end delimiters to the messages in the communication stack, and placing these signals in the transmission medium at the appropriate time. The Fieldbus message specification layer allows the user layer (i.e., the function blocks, objects, etc., of a field device) to communicate through the busbar 34 using a standard set of message formats, and describes the communication services, message formats, and protocol behaviors that are required to construct messages that are to be placed on the communication stack, and which are to be provided to the user's layer. Because the Fieldbus message specification layer provides standardized communications for the user layer, specific Fieldbus message specification communication services are defined for each type of object described above. For example, the Fieldbus message specification layer includes dictionary services that allow a user to read an object dictionary from a device. The object dictionary stores descriptions of objects that describe or identify each of the objects (such as block objects) of a device. The Fieldbus message specification layer also provides context management services that allow the user to read and change communication relationships, known as virtual communication relations (VCRs) described later herein., associated with one or more objects of a device. Still further, the Fieldbus message specification layer provides variable access services, event services, upload and download services, and program invocation services, all of which are well known in the Fieldbus protocol and, therefore, do not they will be described in more detail in the present. The Fieldbus access sub-layer maps the Fieldbus message specification layer to the data link layer. To allow or enable the operation of these layers, each Fieldbus device includes a management information base (MIB), which is a database that stores VCRs, dynamic variables, statistics, timing programs of active link scheduler, timing of execution of function block and device label and address information. Of course, you can access or change the information inside the MIB at any time, using standard Fieldbus messages or commands. In addition, a description of the device is usually provided with each device, to give a user or a host computer an extended view of the information in the VFD. A description of the device, which typically must be set to pass-through password for use by a host computer, stores information necessary for the host computer to understand the meaning of the data in the VFDs of a device. As will be understood, to implement any control strategy using distributed function blocks throughout a process control network, the execution of the function blocks must be precisely programmed, with respect to the execution of other blocks of functions. functions in a particular control cycle. In the same way, communication between different function blocks in the busbar 34 must be precisely programmed in such a way that appropriate data is provided to each function block before that block is executed. Now we will describe the way in which different field devices (and different blocks within the field devices) communicate through the Fieldbus transmission medium, with respect to Figure 1. For communication to occur, one of the devices link masters in each bus segment 34 (eg, devices 12, 16, and 26) operates as an active link scheduler (LAS) that actively plans and controls communication in the associated bus segment 34 The LAS for each bus segment 34 stores and updates a communication program (an active link program) that contains the times that each function block of each device is planned, to start the periodic communication activity in the bar collector 34, and the space of time for which this communication activity will occur. Although there may be one and only one LAS device active in each bus segment 34, other link master devices (such as device 22 in segment 34b) may serve as back-up LASs, and become active when, for example, fail the LAS in progress. Basic devices do not have the capacity to become an LAS at any time. Generally speaking, the communication activities through the busbar 34 are divided into repeating macrocycles, each of which includes a synchronous communication for each active function block in any particular segment of the busbar 34, and one or more asynchronous communications for one or more of the function blocks or active devices in a bus segment 34. A device can be active, i.e., send data to, and receive data from, any bus segment 34, even if these are physically connected to a different segment of the busbar 34, through the coordinated operation of the bridges and the LASs in the busbar 34. During each macrocycle, each of the active function blocks in a particular segment of the bus 34 executes, usually at a different time, but programmed in a precise (synchronous) manner and, at another time programmed in a precise manner, publishes its output data in that segment of the busbar 34, in response to a mandatory data command generated by the appropriate LAS. Preferably, each function block is scheduled to publish its output data shortly after the end of the function block execution period. In addition, the data publication times of the different function blocks are planned in series, in such a way that two function blocks in a particular segment of bus 34 do not publish data at the same time. During the time that synchronous communication is not occurring, each field device, in turn, is allowed to transmit alarm data, view data, and so on in an asynchronous manner, using communications directed by passwords. The execution times and the amount of time required to complete the execution of each function block are stored in the management information base (MIB) of the device, where the function block resides, while, as noted above, the times for sending the mandatory data commands to each of the devices in a busbar segment 34, are stored in the LAS device's MIB for that segment. These times are typically stored as outdated times because they identify the times at which a function block will execute or send data as a phase shift from the beginning of an "absolute link program start time", which all devices are aware of. connected to the busbar 34. To carry out communications during each macrocycle, the LAS, for example, the LAS 16 of the segment 34b of the busbar, sends a mandatory data command to each of the devices in segment 34b of the bus collector, in accordance with the list of transmission times, stored in the active link program. After receiving a mandatory data command, a function block of a device publishes its output data in the busbar 34 for a specific amount of time. Because each of the function blocks is typically programmed to run in such a way that the execution of each block is completed shortly before the block is scheduled to receive a command of mandatory data, the data published in response to a command The mandatory data must be the most recent output data from the function block. However, if a function block runs slowly and has no new output closed when it receives the mandatory data command, the function block publishes the output data generated during the last execution of the function block, and indicates that the Published data is old data using a time stamp. After the LAS has sent the mandatory data command to each of the function blocks in the particular segment of the busbar 34, and during the times that the function blocks are executing, the LAS can cause activities to occur of asynchronous communication. To perform asynchronous communication, the LAS sends a passcode message to a particular field device. When a field device receives a passcode message, that field device has full access to the busbar 34 (or a segment thereof) and can send asynchronous messages, such as alarm messages, trend data, changes of the operator's adjustment point, etc., until the messages are complete or until a maximum assigned "password timeout" has expired. After the same, the field device releases the busbar 34 (or any particular segment thereof) and the LAS sends a passcode message to another device. This process is repeated until the end of the macrocycle, or until the LAS is programmed to send a mandatory data command to perform synchronous communication. Of course, depending on the amount of message traffic and the number of devices and blocks coupled to any particular segment of the bus 34, not every device can receive a password pass message during each macrocycle. Figure 5 illustrates a timing diagram illustrating the times in which the function blocks are executed in segment 34b of the busbar of Figure 1 during each macrocycle of segment 34b of the busbar, and times in which synchronous communications occur during each macrocycle associated with segment 34b of the busbar. In the timing program of Figure 5, the time is indicated on the horizontal axis, and the activities associated with the various function blocks of the positioner / valve 16 and the transmitter 20 (of Figure 3) are illustrated on the vertical axis . Figure 5 identifies the control cycle in which each of the function blocks operates, as a subscribed designation. In this way AI OOPl refers to the function block AI 66 of the transmitter 20, PIDL00P1 refers to the PID function block 64 of the positioner / valve 16, and so on. The execution period of the block of each of the illustrated function blocks is represented by a shaded box, while each programmed synchronous communication is identified by a vertical bar in Figure 5. In this way, in accordance with the program of timing of Figure 5, during any particular macrocycle of segment 34b (Figure 1), the function block AI L00P1 is executed first during the period of time specified by table 70. Then, during the period of time indicated by vertical bar 72, the output of function block AIL00P1 is published in segment 34b of the busbar, in response to a mandatory data command from LAS for segment 34b of the busbar. In the same way, tables 74, 76, 78, 80, and 81 indicate the execution times of function blocks PIDL00P1, AILOOP2 'AOLOOPÍ' SSLOOP2 'AND PIDLOOP3' respectively (which are different for each of the different blocks), while the vertical bars 82, 84, 86, 88, and 89 indicate the times that the function blocks PIDL00P1, AIL00P2, A0L00P1, SSLOOP2 'and PIDLOOP3' respectively, publish the data in segment "34b of the busbar As will be evident, the timing diagram of Figure 5 also illustrates the times available for asynchronous communication activities, which may occur during the execution times of any of the function blocks, and during the time at the end of the macrocycle, during which no function block is being executed, and when no asynchronous communication is taking place in the segment 34b of the busbar Of course, if desired, you can intentionally program the different function blocks to execute at the same time, and not all function blocks they must publish data in the busbar if, for example, no other device subscribes to the data produced by a function block. The field devices are capable of publishing or transmitting data and messages through the bus 34, using one of three virtual communication relations (VCRs), defined in the Fieldbus access sublayer of the stack of each field device. A client / server VCR is used for linear, unscheduled, user-initiated, one-to-one communications between devices in the busbar 34. Those messages in the linear list are sent and received in the order presented for transmission , in accordance with its priority, without overwriting previous messages. In this way, a field device can use a client / server VCR when it receives a password pass message from a LAS, to send a requested message to another device in the bus 34. The requester is called "client "and the device that receives the request is called the" server ". The server sends a response when it receives a password pass message from the LAS. The client / server VCR is used, for example, to make requests initiated by the operator such as setpoint changes, access and changes of the tuning parameter, alarm acknowledgments, and device charges and downloads. A VCR of distribution of reports is used for communications in linear list, not programmed, initiated by the user, one to many. For example, when a field device with an event or trend report receives a pass password from a LAS, the field device sends its message to a "group address" defined in the Fieldbus access sublayer of the communication stack. of that device. Devices that are configured to listen on that VCR will receive the report. The VCR type of distribution of reports is typically used by Fieldbus devices to send alarm notifications to operator consoles.

A publisher / subscriber VCR type is used for communications in the buffer zone, from one to many. The communications in buffer zone are ones that store and send only the latest version of the data and, in this way, the new data is completely overwritten to the previous data. The outputs of the function block, for example, comprise data placed in the buffer area. A "publisher" field device publishes or transmits a message using the VCR type of publisher / subscriber to all "subscriber" field devices in the busbar 34, when the publisher device receives a mandatory data message from the LAS or from a subscriber device. The publisher / subscriber relationships are previously determined, and are defined and stored within the Fieldbus access sublayer of the communication stack of each field device. To ensure proper communication activities through the busbar 34, each LAS periodically sends a time-distribution message to all field devices connected to a bus segment 34, which enables the receiving devices to Adjust your local application time, to be in sync with each other. Among these synchronization messages, clock time is maintained independently in each device, based on its own internal clock. Clock synchronization allows field devices to stamp the time of the data along the Fieldbus network, to indicate, for example, when the data was generated. In addition, each LAS (and other link master devices) in each busbar segment stores a "live list", which is a list of all the devices that are connected to that busbar segment 34, ie , all devices that are responding appropriately to a password pass message. The LAS continuously recognizes new devices added to a bus segment, by periodically sending probe node messages to addresses that are not on the live list. In fact, each LAS is required to poll at least one address after it has completed a cycle of sending passcode messages to all field devices on the live list. If a field device is present in the polled address, and receives the probe node message, the device immediately returns a probe response message. After receiving a probe response message, the LAS adds the device to the live list, and confirms by means of sending a node activation message to the polled field device. A field device remains on the live list as long as that field device responds appropriately to password pass messages. However, a LAS removes a field device from the live list if the field device, after three successive attempts, does not use the password or immediately returns the password to the LAS. When a field device is added to, or removed from the live list, the LAS transmits the changes in the live list to all other link master devices in the appropriate segment of the busbar 34, to allow each master device link maintain a current copy of the live list. As noted above, the communication interconnections between the field devices and the function blocks thereof, are determined by a user, and implemented within the process control res 10, using a local configuration application in, for example, the main computer 12. However, after having been configured, the process control network 10 operates without any consideration of the device or the process diagnostics and, therefore, interconnects with the main computer 12 to perform standard I / O functions, but not diagnostic functions. When a user wishes to perform diagnostics, the user can cause the host computer 12 to send setpoint changes to, for example, the AO 63 function block of the control LOOP1, and record the feedback in the AO 63 function block, using a trend object associated with the function block AO 63. However, to perform this type of communication, the main computer 12 must use asynchronous (unpublished) communications that allow the host 12 to access the bus 34, only when the main computer 12 receives a password pass message from a LAS. As a result, the different parts of the diagnostic signal generated by the main computer 12 may not reach the AO 63 function block at precisely determined times (or precisely programmed times), which means that the diagnostic signal received in the function block AO 63 it will have a shape that, at least in part, is determined by the subsequent communication record in the busbar 34 at any particular time. For this reason, any diagnostic signal sent using asynchronous communications will not be strictly deterministic and, thus, may not be very effective for performing diagnostics on a device or a process. Furthermore, the main computer 12 has no way of guaranteeing that the feedback data gathered by the trend object (s) will not be lost due to overwriting, and so on. In addition, the main computer 12 has no way to control the mode of the other function blocks in LOOP1, such as the PID 64 function block, without specifically changing the mode of that block.

Until now, in order to ensure complete and strictly deterministic diagnostics in a process, a user had to take the process control network 10 offline and reconfigure the communication interfaces in it, in such a way that the computer 12 was able to send the setpoint changes to the appropriate devices, and to receive the measured data by the appropriate devices, by means of synchronous communications. However, as noted above, this procedure suspends the process, and requires an operator to reconfigure the process control network whenever diagnostics are going to be performed, both being undesirable. In addition, the control implemented by the main computer 12 during this diagnostic procedure is different from the control implemented by the communicatively linked function blocks during the normal operation of the process and, therefore, the data of the gathered process may not be indicative of the process operation while the process is being controlled normally. As a result, the main devices typically do not include the ability to allow a user to switch between normal and diagnostic operations in order to enable diagnostics. To overcome these problems in, for example, a Fieldbus process control network, a new type of function block is provided, in accordance with the present invention, for performing device and / or process diagnostics on, or using a different device. to the one in which the new diagnostic function block is located. The remote diagnostic function block of the present invention is configured to communicate with the function blocks of other devices through the busbar 34, using synchronous periodic communications (e.g., publisher / subscriber VCR of the Fieldbus protocol) and to receive data, such as measurements of device parameters or other parameters of the process, using periodic synchronous communications. In this way, the diagnostic function block of the present invention is capable of sending a deterministic diagnostic control signal to a different function block, and of receiving and storing data related to a device or a process parameter in a way periodical In addition, the remote diagnostic function block of the present invention can be stored in a device other than the device on which a diagnosis is being made, which allows the diagnostic function block to be used to perform diagnostics on, or use any number of different devices within a process control network. Thus, for example, a remote diagnostic function block according to the present invention can be stored in the positioner of the positioner / valve device 16, 18, and 24. In the same way, a diagnostic function block according to the present invention it can be stored in the main computer 12, to enable that function block to be used in any device within any bus segment 34. Generally speaking, the remote diagnostic function block of the present invention can be communicatively linked to a function block of another device (or the same device) during the times when a device diagnosis is being made, and then uncoupled from the other function block during times when it is not being performed no device diagnosis. Alternatively, the remote diagnostic function block of the present invention can be placed in a control cycle, in such a way that it remains communicatively linked to other function blocks within the control cycle, even when diagnostics are not being performed., such as device or process diagnostics. Referring now to Figure 6, a diagnostic function block 90 is illustrated, as being communicatively linked or coupled to the function block AO 63 of the positioner / valve 16 (Figure 3), such that an output of the function block of diagnostic 90 is connected to an input of function block AO 63, and an output of function block AO 63 is connected to a feedback input of diagnostic function block 90. During operation, diagnostic function block 90 sends a diagnostic control signal that specifies the changes in the set point of the function block AO 63 through the segment 34b of the busbar (Figure 3), by means of regularly scheduled periodic communications (for example, using a VCR of publisher / subscriber), and also receives a feedback signal from function block AO 63 that indicates, for example, the position of a member of the valve of the valve 16, through the segment 34b of the busbar, through periodic communications regularly scheduled. Diagnostic function block 90 stores the feedback signal produced by function block AO 63 and, after the entire diagnostic signal is sent to function block AO 63, or at one or more intermediate times during diagnosis, sends the received feedback signal and, if desired, an indication of the diagnostic control signal that is used to control the function block AO 63, to the main computer 12 for processing. Of course, if desired, the diagnostic function block 90 may also have a processor or other device that performs device diagnostics, using the diagnostic control signal and the feedback signals received from the AO 63 function block. As it was noted above, the inter-device communication connections illustrated by means of the diagnostic control cycle of Figure 6, are implemented using synchronous periodic communications and, therefore, the diagnostic control signal generated by the block is guaranteed. of functions 90 is the same signal received at the input of function block AO .63. In the same way, these synchronous communications ensure that the output data developed by the AO 63 function block is traversed and recorded in a periodic manner. Of course, to implement the diagnostic control cycle of Figure 6, a host computer, such as the host computer 12, must reconfigure the process control network 10 to connect the diagnostic function block 90 to the host block. functions AO 63 in the manner indicated in Figure 6, and then must inform the diagnostic function block 90 to run a diagnostic test in function block AO 63. After the diagnostic test and the block functions 90 has sent all the stored data to the main computer 12 (or other device) for processing, the main computer 12 must reconfigure the process control network 10 to reinstall the control scheme used during the operation normal of the process control network 10. Preferably, the main computer 12 (or other configurator) stores the normal or existing control scheme, while it is implementing or executing the diagnostic cycle illustrated in Figure 6. Although the diagnostic function block 90 of Figure 6 is illustrated as being located in the device 18 to perform a device diagnosis in the positioner / valve device 16 , this function block can be located in any other device in the process control network 10, and can be used to perform diagnostics on any device in the process control network 10, including any output device such as a positioner, a positioner / valve device, a shock absorber, a fan, and so on. However, as noted above, a diagnostic function block in accordance with the present invention can be connected within a process control cycle configuration at all times during the operation of that process control cycle, to enable the device and process the diagnostics that will be implemented or performed, without reconfiguring the process control network. Referring now to Figure 7, a control cycle 91 is illustrated which includes the AI 66 function block, the PID 64 function block, the AO 63 function block, and a diagnostic function block 92. As can be seen Figure 7, the diagnostic function block 92 is inserted (communicatively linked) within the control cycle 91, between the function block AO 63 and the PID 64 function block. During the normal operation of the process control cycle 91, the function block AI 66 sends a measurement of the process or process parameter to the PID function block 64, which then sends a developed process control signal to the diagnostic function block 92. The diagnostic function block 92 passes this process control signal through an input of the function block AO 63 inside the positioner / valve device 16, and receives a feedback signal indicating, for example, the position of to valve, from the function block AO 63. The diagnostic function block 92 then passes the feedback signal to a control input of the PID 64 function block, which uses this feedback signal (together with the input from the block of functions AI 66) to calculate a new process control signal. In this way, during the normal operation of the process control cycle 91, the diagnostic function block 92 simply passes the signals between the PID 64 function block and the AO 63 function block, to allow these function blocks to operate. in essentially the same way as when they are connected in the control cycle of Figure 4. However, when a user wishes to implement a diagnosis of a device or a process, the main computer 12 glows a start signal to the function block Diagnostics 92 (via asynchronous communications), which causes the diagnostic function block 92 to disconnect the process control signal developed by the PID 64 function block from the input of the AO 63 function block, and to send the a diagnostic control signal at the input of the function block AO 63. Of course, the diagnostic control signal can be any desired signal that is used to implement device or process diagnostics. Simultaneously, the diagnostic function block 92 starts to store the feedback data received from the function block AO 63 and / or to store other measurements of the sampled process received from, for example, the AI 66 function block and / or any other process measurement devices or function blocks within the process, indicated in Figure 7 by a block 94. Of course, the process parameters of block 94 and function block AI 66 can be stored in the diagnostic function block 92, using trend objects or any other desired storage unit for eventual shipment to the host computer 12 to be used for diagnostic analysis.

During the operation of a device or process diagnosis, the diagnostic function block 92 can send feedback data to the PID 64 function block and can, if desired, alter this feedback signal to indicate to the PID 64 function block that a diagnosis is running. In this way, the diagnostic function block 92 controls the behavior (mode) of the PID function block 64 and / or the behavior (mode) of other function blocks in the control cycle 91 while performing a diagnosis of a device or of a diagnosis that, in the case of the PID 64 function block, helps to avoid coiling. After the diagnostic function block 9 ~ 2 terminates the sending of the diagnostic control signal to the function block AO 63, the diagnostic function block 92 is switched to send again the process control signal developed by the controller. PID function block 64 to function block AO 63, and to provide undisturbed feedback signals from function block AO 63 to PID function block 64. In addition, at one or more intermediate times during diagnosis or after the If the diagnostic is complete, the diagnostic function block 92 can send information of the parameter control signal and / or process diagnostics, of collected feedback, to the main computer 12 (or other device) through the busbar 34 using , for example, asynchronous communications. As will be understood, the diagnostic function block 92 is communicatively linked to the PID function block 64 and the function block AO 63, by means of programmed periodic communications and, therefore, causes the operation of the control cycle 91 to take a little more time during each macro cycle associated with the control cycle 91. That is, each macrocycle for the control cycle 91 must have more time devoted to the synchronous communications and the executions of the function block than the macrocycle for the cycle of control of Figure 4, due to the additional periodic communication schedule that is needed for the diagnostic function block 92. In fact, to properly insert the diagnostic function block 92 within the control cycle of Figure 4, you must insert an execution period for function block 92, within the timing program of Figure 5, after bar 82 (the scheduled communication associated with the PID 64 function block) and a communication period must be inserted (publication) programmed for communication between diagnostic function block 92 and function block AO 63 within the timing program of Figure 5, after the inserted execution period of function block 92, and before frame 78 (the execution period of the AO 63 function block). In the same way, the programmed execution and the communication periods for carrying out the feedback communication between the diagnostic function block 92 and the PID 64 function block must be inserted into the timing program of Figure 5, after the bar 86 (the communication period programmed for function block AO 63). Of course, the VCRs of the function block AO 63 and the PID function block 64 must be altered to appropriately perform the scheduled communications between these function blocks and the diagnostic function block 92. Although the diagnostic function block 92 can remain in the control cycle 91 during the normal operation of the process control network 10 (i.e., when a diagnosis is not being made), if desired, the diagnostic function block 92 can be inserted within the program of a control cycle, such as control cycle 91, only at the times when the diagnosis is to be made, such that the control cycles of a process control network 10 are configured to be executed as soon as possible possible, when a diagnosis is not being made. However, this operation requires that a new process control configuration be downloaded into the network, whenever a process diagnosis is to be executed.

The diagnostic function block 92, illustrated in more detail in Figure 8, includes a diagnostic machine 95 that receives and decodes the start and stop signals of the main computer 12, sends the gathered data to the main computer 12 for analysis , and generally controls the operation of the rest of the diagnostic function block 92. When the diagnostic machine 95 receives and decodes a start signal, the diagnostic machine 95 causes a diagnostic signal generator 96 to send a control signal of stored diagnosis to a switch 97. Simultaneously, the diagnostic machine 95 causes the switch 97, comprising a signal communicator, to connect an output thereof to the diagnostic signal generator 96, in such a way that the diagnostic control signal provided by the diagnostic signal generator 96 is provided to a control signal output of the function block 92 for sending to, for example, an input of the function block AO 63. Before being directed to connect the output of the control signal to the diagnostic signal generator 96, the switch 97 couples a process control signal input ( connected to receive a process control signal from, for example, the PID function block 64) to the output of the control signal. Of course, the switch 97 is typically implemented in the software and, therefore, may comprise any switching logic designed to control whether the diagnostic control signal or the process control signal is sent (at the signal input). process control) at the output of the control signal of the diagnostic function block 92. When operating to perform a device or process diagnosis, the diagnostic machine 95 enables a data capture unit 98 to collect and store signals for measuring the process or process parameters, gathered by other function blocks within the process control network 10, and sending them to the diagnostic function block 92 using scheduled periodic communications. As will be understood, any number of process parameters can be sent to the data capture unit 98, depending on the type of diagnosis being performed. A feedback unit 99 receives feedback signals developed by the function block AO 63 (or any other function block that is controlling the diagnostic function block 92) and, if directed to do so by the diagnostic machine 95, stores these signals in memory. In the same way, the feedback unit 99 can send the received feedback signals to the PID 64 function block (or any other function block such as the one that generates the process control signal that is used to control the function block AO 63).

Typically, in a Fieldbus environment, the signals received by the feedback unit 99 include a valve and a state, wherein the state indicates the different states of the control cycle 91, associated with the received feedback signals. If desired, the feedback unit 99 may change the state of the signals received from the function block AO 63 from, for example, a "good-cascade-non-specific" state, which indicates the normal operation of the control cycle. , to a "good-cascade-annular" state, which indicates that a local override has taken place and, therefore, the signal according to the normal operation of the control cycle 91 is not being generated. When the signal feedback with the altered state is sent to, for example, the PID 64 function block, the PID 64 function block decodes the state of that signal, and recognizes that the output of the PID 64 function block is no longer being used for control the function block AO 63. The PID 64 function block can, after the same, change or change the mode to, for example, a manual mode, in which the function block PID &; 4 close your output and stop calculating new process control signals of the AO feedback signals, and the output of the AI 66 function block. This mode mute process prevents the PID function block 64 from entering a state of escape in which the control signal produced by the PID 64 function block is quickly triggered to one end, because the PID function block 64 is trying to force the feedback signal to a controlled value without any effect. As will be understood, the change in the mode of the PID function block 64 may cause other function blocks within the control cycle 91, or within the process control network 10 to also change the mode. Of course, when a diagnosis is completed and the control cycle 91 is operating to allow the PID &4 function block to control the function block AO 63, the feedback unit 99 passes the feedback signal through it without change the state of that signal. To effect the operation of the appropriate mode, a mode management unit 100 stores the logic and data related to the appropriate changes of state to be made to the feedback signal or other signals gathered, to effect the desired changes. in other function blocks, and communicates this information to the diagnostic machine 95. Of course, the diagnostic machine 95 can start and stop the diagnostics, or it can control one of a number of different diagnostic control signals based on any desired criteria and can, for example, use one or more of the feedback signals from the function block AO 63, and the process parameter signals gathered by the data capture unit 98, as limiting factors when a test is implemented. diagnosis. On the other hand, in a Fieldbus network, the diagnostic control signals are preferably stored as digital signals, or are generated in accordance with some functions stored in the diagnostic signal generator 96. However, the diagnostic control signals they may be stored or generated in the diagnostic function block 92 in any other desired manner. As will be understood, the diagnostic function blocks 90 and 92 described herein allow or enable device and / or process diagnostics to be implemented, using scheduled, synchronous communications, to ensure that a deterministic signal is sent to a device during a diagnostic procedure. In the same way, the diagnostic function block 92 described herein allows or enables device and process diagnostics to be implemented using the same process control configuration as they are implemented during the normal operation of a process, which enables a user to perform a diagnosis of a device or a process, without having to reprogram or reconfigure a process control network in any meaningful way, and which allows accurate process measurements to be made during diagnosis.

Although diagnostic function blocks 90 and / or 92 have been described herein as performing diagnostics in, or using, a downstream AO 63 function block (which is a block of output functions), and as receiving inputs from , and sending feedback to an upstream PID function block 64 (which is a control function block) connected in a simple control cycle configuration, the diagnostic function block or other diagnostic function routine of the present invention. , may be used in conjunction with other output functions or function blocks and other control functions or function blocks as desired, and may be implemented in control cycles having different configurations than that illustrated in Figure 7. in this way, for example, the diagnostic function block 92 can be configured to control a function block, receive a feedback signal from a different function block, and receive a process control signal from an additional function block. Furthermore, although the diagnostics described herein have been implemented in the form of a "function block" Fieldbus, it is noted that the diagnostics of the present invention can be implemented using other types of blocks, programs, hardware, microprogramming, and so on, associated with other types of control systems and / or communication protocols. In fact, although the Fieldbus protocol uses the term "function block" to describe a particular type of entity capable of performing a process control function, it is noted that the term function block, as used herein, is not thus limited, and includes any kind of device, program, routine, or other entity capable of performing a process control function in any way, in locations distributed within a process control network. In this way, the diagnostic function blocks described and claimed herein may be implemented in other process control networks, or by using other process control communication protocols or schemes (which may exist now, or may be developed). in the future) that do not use what the Fieldbus protocol strictly identifies as a "block of functions", as long as these networks or protocols provide or allow control functions that are to be carried out in distributed locations within a process. Still further, although the function blocks of process and device diagnostics have been described herein as being used to perform diagnostics on (or use) positioner / valve devices, it is noted that these function blocks can be used to perform diagnostics in (or using) other types of devices, such as those that have movable elements such as shock absorbers, fans, and so on. In addition, although the diagnostics described herein are preferably implemented in the software stored in a process control device, these can be implemented alternatively or additionally in hardware, microprogramming, etc., as desired. If implemented in the software, the diagnostics of the present invention can be stored in any computer readable memory such as a magnetic disk, a laser disk, or other storage medium, in a RAM or ROM of a computer, and so on. In the same way, this software can be sent to a user or to a device by means of any known or desired delivery method including, for example, through a communication channel such as a telephone line, the internet, and so on. Although the present invention has been described with reference to specific examples, which are intended to illustrate only and which are not limiting of the invention, it will be apparent to those of ordinary skill in the art that changes, additions or deletions to the embodiments may be made. described, without departing from the spirit and scope of the invention.

Claims (28)

1. A diagnostic system for use in a process control network, which has a plurality of communicatively linked devices on a busbar, wherein each of the devices is capable of performing a process control function, and of communicating on the bus bar using scheduled periodic communications, the diagnostic system comprising: a signal generator arranged in a first of the devices, which generates a diagnostic control signal; a communicator coupled to the signal generator, and configured to send the diagnostic control signal to a one second input of the devices, using the scheduled periodic communications; and a signal receiver that receives an output signal developed by another device in response to the diagnostic control signal.

2. The diagnostic system of the claim 1, characterized in that it also includes a storage unit that stores the received output signal.

3. The diagnostic system of the claim 2, characterized in that it also includes an element for sending the output signal stored to a third of the devices, capable of performing diagnostic analysis activities using the stored output signal.

The diagnostic system of claim 1, wherein the signal receiver includes an element for receiving the output signal using the scheduled periodic communications.

The diagnostic system of claim 1, wherein the diagnostic control signal is a digital signal, and wherein the signal generator includes a memory that stores the digital diagnostic control signal. 6 '.

The diagnostic system of claim 1, characterized in that it also includes a control signal input, adapted to be coupled to receive a process control signal developed by a third of the devices, and wherein the communicator includes a switch coupled to the control signal input and the signal generator, - to send one of the process control signal or the diagnostic control signal to the second device.

The diagnostic system of claim 6, wherein the second device is the same device as the third device.

The diagnostic system of claim 6, characterized in that it also includes a feedback unit that sends the received output signal to the third device.

9. The diagnostic system of claim 8, wherein the feedback unit includes an element for sending the received output signal to the third device, using the scheduled periodic communications.

10. The diagnostic system of the claim 8, wherein _ the process control function performed by the third process control device is capable of operating in different modes, and also includes a handling unit so that it controls the mode of the process control function within the third device.

The diagnostic system of claim 6, characterized in that it also includes a process signal receiver, adapted to receive one or more process signals, and a storage unit that stores the one or more process signals.

12. The diagnostic system of claim 11, characterized in that it also includes an element, for sending the stored process signals to a fourth device capable of performing diagnostic analysis activities using the process signals.

The diagnostic system of claim 1, wherein the other device is the second device.

14. A diagnostic function block capable of being implemented in a process control device, and of being used in a process control network having a plurality of devices communicatively coupled to a busbar, wherein each of the devices includes one or more function blocks capable of performing an input function, an output function, or a control function within the process control network, and capable of communicating in the busbar, using scheduled periodic communications, the diagnostic function block comprising: a signal generator that generates a diagnostic control signal; a communicator configured to communicate the diagnostic control signal to a second function block within the process control network, using the scheduled periodic communications; and a signal receiver that receives an output signal developed by another function block, in response to the diagnostic control signal.

15. The diagnostic function block of claim 14, characterized in that it also includes a storage unit for storing the received output signal.

16. The diagnostic function block of claim 14, wherein the diagnostic control signal is a digital signal, and wherein the signal generator includes a memory that stores the digital diagnostic control signal.

17. The diagnostic function block of claim 14, characterized in that it also includes a control signal input, adapted to be coupled to an output of a third function block, using. the scheduled periodic communications, and a switch coupled to the control signal input and the signal generator, to alternatively provide one of the output of the third function block or the diagnostic control signal to the second function block.

18. The diagnostic function block of claim 17, characterized in that it also includes a feedback network that sends the received output signal to the third function block.

The diagnostic function block of claim 18, wherein the third function block is capable of operating in different modes, and further includes a control unit so that it controls the mode of the third function block when the switch sends the diagnostic control signal to the second function block.

The diagnostic function block of claim 17, characterized in that it also includes a process signal receiver, adapted to receive one or more process signals from other function blocks within the process control network, and a unit storage that stores the one or more process signals.

21. A method for performing diagnostics in a process control network, having a plurality of devices communicatively coupled to a busbar, wherein each of the devices includes one or more function blocks capable of performing a control function of process inside the process control network, and capable of communicating in the busbar, using scheduled periodic communications, the method comprising the steps of: connecting a first device that includes a diagnostic function block that has a signal generator, that generates a diagnostic control signal, to the bus of the process control network; communicatively linking an output of the diagnostic function block to a second function block in a second device, using the scheduled periodic communications; communicatively linking one input of the diagnostic function block to an output of another function block, to receive output signals developed by the other function block, in response to the diagnostic control signal; and sending the diagnostic control signal to the second function block, using the scheduled periodic communications to, by means of the same, control the operation of the second function block, in accordance with the diagnostic control signal.

22. The method for performing diagnostics in a process control network, according to claim 21, characterized in that it also includes the step of storing the output signals received in the diagnostic function block.

23. The method for performing diagnostics in a process control network, according to claim 21, characterized in that it also includes the steps of communicatively linking an output of a third function block to a process control signal input of the block of diagnostic functions, and operating the diagnostic function block to switch between a first operating state in which the diagnostic function block sends the output of the third function block to the second function block, and a second operating state in which the Diagnostic function block sends the diagnostic control signal to the second function block.

24. The method for performing diagnostics in a process control network, according to claim 23, characterized in that it also includes the step of communicatively linking a feedback output of the diagnostic function block to a feedback input of the third block of functions, to communicate the output signals received from the other function block to the third function block.

25. The method for performing diagnostics in a process control network, according to claim 24, characterized in that it also includes the step of having the diagnostic function block control the operation mode of the third function block when the block of Diagnostic functions sends the diagnostic control signal to the second function block.

26. The method for performing diagnostics in a process control network, according to claim 24, characterized in that it also includes the steps of communicatively linking one or more signal inputs of the diagnostic function block to one or more other blocks of communication. functions, to receive one or more process parameter signals developed by the one or more other function blocks, and store the one or more process signals received in the diagnostic function block.

27. The method for performing diagnostics in a process control network, according to claim 26, characterized in that it also includes the steps of recovering the one or more process signals stored in the diagnostic function block, and using the one or more process signals recovered to perform a process diagnosis.

28. The method for performing diagnostics in a process control network, according to claim 21, characterized in that it also includes the steps of storing the output signals in the diagnostic function block, recovering the output signals stored in the block of diagnostic functions, and use the recovered output signals to perform a diagnosis of the device.