MXPA99003076A - Method and apparatus for debugging and tuning a process control network having distributed control functions - Google Patents

Abstract

A system and method for debugging and tuning a process control network having distributed control functions implemented by a set of field devices communicatively linked over a bus include an operational scheduler that schedules the execution of each of a number of process control functions and communication functions performed by the field devices to define a process control scheme and an indicator that indicates one or more process control scheme locations at which the process control scheme is to be automatically or conditionally interrupted to thereby enable debugging and/or tuning of the process control network. A controller interrupts execution of the process control scheme at the indicated flow locations, communicates process data to a user to display the current or a past state of the process to a user and waits for user input before continuing with operation of the process control scheme. In a tuning mode, the controller delivers data pertaining to a process parameter to a tuning device or to a user which determines a new tuning parameter, such as a gain, to be used within the process control scheme based on the process parameter data.

Description

METHOD AND APPARATUS FOR DETERMINING AND TUNING A PROCESS CONTROL NETWORK THAT HAS CONTROL FUNCTIONS DISTRIBUTED RELATED APPLICATION This is a partial continuation of the United States of America patent application serial number 08 / 726,263 filed on October 4, 1996.

FIELD OF THE INVENTION The present invention relates in general to process control networks and, more specifically, to a method and apparatus for use in the debugging and tuning of a process control network having distributed control functions.

DESCRIPTION OF THE RELATED TECHNIQUE Large processes such as chemical, petroleum processes and other manufacturing and refining processes include numerous field devices arranged in various places to measure and control process parameters to thereby control the process . These field devices can be, for example, sensors such as temperature, pressure, and flow rate sensors as well as control elements such as valves and switches. Historically, the process control industry used manual operations such as manual reading of level and pressure gauges, turning valve handwheels, etc., to operate the measurement and control of field devices within a process. At the beginning of the 20th century, the process control industry began to use local pneumatic control, in which local pneumatic controllers, transmitters, and valve placers were placed in various places within a process plant to effect control of certain elements of the plant. In the emergence of the microprocessor-based distributed control (SCD) system in the 1970s, distributed electronic process control became prevalent in the process control industry. As is known, a distributed control system includes an analog or digital computer, such as a programmable logic controller, connected to numerous electronic monitoring and control devices, such as sensors, transmitters, pressure current transducers, valve placers, and so on. , located through the process. The computer of the distributed control system stores and implements a centralized and often complex control scheme to perform the measurement and control of process parameters according to some global control scheme. However, usually the control scheme implemented by a distributed control system belongs to the manufacturer of the distributed control system which, in turn, makes the distributed control system difficult and expensive to extend, update, program , and to attend, because the supplier of the distributed control system must be involved in a comprehensive manner to perform any of these activities. In addition, the equipment that can be used or connected to any distributed control system may be limited due to the nature of property rights of the distributed control system and the fact that the distributed control system provider may not support certain devices or devices. functions of devices manufactured by other vendors. To overcome some of the problems inherent in the use of copyrighted distributed control systems, the process control industry has developed several open, standard communication protocols that include, for example, the HART®, PROFIBUS®, ORLDFIP® protocols. , LONWORKS®, Device-Net®, and CAN, which allow field devices made by different manufacturers to be used together within the same process control cycle. In fact, any field device that conforms to one of these protocols can be used within a process to communicate and be controlled by a distributed control system or other controller that supports the protocol, even if that field device is made by a different manufacturer than the controller manufacturer of the distributed control system. Moreover, there is now a shift within the process control industry to decentralize process control and, by this, simplify the controllers of distributed control systems or eliminate to a large extent the need for distributed control system controllers . Decentralized control is obtained by making process control devices, such as valve placers, transmitters, etc. perform one or more process control functions and then communicate data through a busbar structure for use by other process control devices. To implement control functions, each process control device includes a microprocessor that has the ability to perform one or more basic control functions as well as the ability to communicate with other process control devices using an open and standard communications protocol. In this way, field devices made by different manufacturers can be interconnected within a process control cycle to communicate with each other and perform one or more process control functions or control cycles without the intervention of a distributed control system . The two-wire, all-digital cycle protocol, now being promulgated by the Fieldbus Foundation, known as FOUNDATION MR (hereinafter the "Protocol") is an open communication protocol that allows devices made by different manufacturers to interoperate. and communicate with each other via a standard busbar to perform decentralized control within a process. As noted above, the decentralization of process control functions simplifies and, in some cases, eliminates the need for a proprietary distributed control system, which in turn, reduces the need for a process operator to depend on the manufacturer of the distributed control system to implement, change or update a control scheme for a process control network. In fact, locating the basic process control functions within the field devices interconnected by a standard communications busbar allows a process to be reconfigured, updated, enlarged, or changed in some other way by reconfiguring the manner in which the devices of field communicate with each other. This reconfiguration of communications is relatively simple, however, because all devices that perform control functions conform to an open communication standard. As a result, the reconfiguration of this control system does not involve or use owner information of any particular manufacturer nor does it require the reprogramming of any device in a manner with owner rights. In addition, decentralized control reduces the number or length of cables needed within a process environment because each of the process control devices does not need to be directly connected to a distributed control system or to another controller but, more Well, all the devices can be connected together using a busbar architecture. Also, decentralized control results in an increase in the overall control speed of a process due to the shorter distances that each communication signal must travel and because the bottlenecks of the data flow that typically occur are reduced. in a controller of the distributed control system. Although decentralized control makes a process control network easier to reconfigure, it also makes the process of debugging and tuning a process control network, for example, the start of the network, is much more difficult, precisely because different control functions are implemented at different times through different devices distributed throughout the process control network. In fact, a process control network having distributed control functions, such as a Fielbus network, includes many control elements and functional devices that interact in a very complex manner using synchronous communications over a busbar and, thus, The interactions between the different control elements and the functional devices are difficult to model and may not be fully appreciated by an operator that was not fully involved in the design of the process control system. Of course, the greatest complexity and difficulty of operation arises when a process control network is analyzed for the first time or "carried online". This initialization process commonly requires much dexterity because a process control network that becomes unstable can be very dangerous, particularly in oil and gas pipe applications, nuclear power generating stations, chemical product processing applications and the like. . In addition, as soon as the process control system is operational, it may be necessary to tune or refine the system. Because the process control network that has distributed control functions does not include a decentralized controller that stores a global control algorithm that can be programmed to pass through each of the different operations or stop at previously determined moments to allow the debugging and tuning of the process control scheme, it is difficult to debug these systems when they are carried online and it can be difficult to refine these systems. In fact, because the different functions of the: global control scheme are carried out in different places within the process control network and these different control functions are programmed to be implemented in predetermined time, based on synchronous communications that are presented on a busbar, there is no mechanism to stop the control scheme at several points to see variable values, etc., to pass through the control scheme one operation at a time or to refine the control scheme, all of which is advantageous when implementing a new control scheme or when debugging or refining a process control scheme.

SUMMARY OF THE INVENTION The present invention is directed to a method and apparatus for debugging and fine-tuning a process control network having distributed control functions. According to one aspect of the present invention, during the initialization and tuning of a process control network having distributed control functions, a method stops a process cycle during execution and retains the process control information for display. to a user. After this, when directed by the user, the method continues the execution of the process control network to isolate system errors or "hassles". The method can also monitor and save parameters of control functions in real time at cycle execution speeds to provide a "trace" function that is useful for tuning or refining the process control network. According to another aspect of the present invention, a method and apparatus receives requests to fine-tune parameters for control of selected processes, adjusts the parameters on a busbar, and monitors input and output parameters of control functions within a control cycle of real-time processes to allow an operator to determine if a process control cycle that has distributed control functions is tuned appropriately. According to yet another aspect of the present invention, a process control cycle operating in a two-way, two-way digital communications environment includes control logic to access a process control variable in real time during the execution of the process control cycle and a memory that stores the variable. The process control variable may be available locally in a device within the process control cycle or peripherally in a central device connected or coupled to the process control cycle. In one embodiment, the process control cycle may include a routine defining one or more inflection points and directing the control cycle to execute the inflection point, in which a specific event, condition or address is presented. of execution of program code. The process control cycle may also include a routine that is operative in the occurrence of a turning point or in some other place of flow control, up to a single step through subsequent functional blocks of the process control scheme. The inflection points can be implemented both between the control functions and within the control functions stored in the process control devices within a process control cycle. For example, an inflection point can be set after the data is secured in a field device over a bus and a second inflection point can be set after the field device executes a control function. In another example, a first inflection point is set after a control algorithm is executed but before the data is transferred to another control function, which may be in the same or in a different process control device, while a second inflection point is set after the data is transmitted from one device to another but before an algorithm associated with the next process control function starts running. With the method and apparatus of the present invention, the diagnostic test time is substantially reduced due to the ability to take a single step through a process control scheme in a process control network that has distributed control functions or make this process control scheme stop at previously determined inflection points.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a schematic block diagram of an exemplary process control network using the Fieldbus protocol; Figure 2 is a schematic block diagram of Fieldbus devices having a set of three function blocks therein; Figure 3 is a schematic block diagram illustrating the function blocks within some of the devices of the process control network of Figure 1; Figure 4 is a schematic control cycle for a process control cycle within the process control network of Figure 1; Figure 5 is a time diagram for a macrocycle of a bus segment of the process control network of Figure 1, - Figure 6A is a flow chart illustrating the operation of a tipping point routine for use to debug the process control network of Figure 1; Figure 6B is a flow chart illustrating the operation of a stepped routine to be used for debugging the process control network of Figure 1; Figure 6C is a flow chart illustrating the operation of a tuning routine for use in tuning the process control network of Figure 1; Figure 7 is a schematic block diagram illustrating the operation of a set of function blocks in the process control cycle of Figure 4 during a tuning routine; and Figure 8 is a diagram of a trace-tuning function block that allows inflection, one-step, and tuning points according to the present invention.

DESCRIPTION OF THE PREFERRED MODALITIES Although the method and apparatus for the purification and tuning of a process control network of the present invention is described in detail together with a process control network that implements process control functions in a decentralized manner or distributed using a set of Fieldbus devices, it should be noted that the method and apparatus for debugging and tuning of the present invention can be used with process control networks that perform distributed control functions using other types of field devices and communication protocols, including protocols that depend on protocols other than those of two-wire bus bars and protocols that only support analog communications or both analog and digital. Thus, for example, the debugging and tuning method and apparatus of the present invention can be used in any process control area that performs distributed control functions even if these process control networks use HART communication protocols. , PROFIBUS, etc. or any other communications protocol that exists now or that may be developed in the future. Before discussing the details of the debugging and tuning method and apparatus of the present invention, a general description of the Fieldbus protocol, the field devices configured in accordance with this protocol, and the manner in which the communication is presented in a process control network that uses the Fieldbus protocol. However, it should be understood that, although the Fieldbus protocol is a relatively new fully digital communications protocol developed for use in process control networks, this protocol is known in the art and is described in detail in numerous articles, brochures and published, distributed specifications, available, among others, in the Fieldbus Foundation, a non-profit organization with main offices in Austin, Texas. In particular, the Fieldbus protocol, and the way of communicating with and storing data in devices that use the Fieldbus protocol, is described in detail in the manuals known as Communication Technical Specification and User Layer Technical Specification of the Fieldbus Foundation, which incorporated herein by reference in its entirety. The Fieldbus protocol is a two-way, serial, all-digital communication protocol that provides a standardized physical interface to a two-wire bus cycle that interconnects "field" equipment such as sensors, triggers, controllers, valves, etc. located in an environment of process control or instrumentation 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 installation, which allows these field devices to perform control functions at distributed locations through a process and communicate with each other before and after performing these control functions to implement a global control strategy. Because the Fieldbus protocol allows control functions to be distributed through a process control network, it reduces complexity or completely eliminates the need for the centralized process controller typically associated with a distributed control system.

Referring to Figure 1, a process control network 10 using the Fieldbus protocol can include a central computer 12 connected with several other devices such as a program logic controller (PLC) 13, various controllers 14, another computer device central 15 and a set of field devices 16, 18, 20, 22, 24, 26, 28, 30 and 32 via a two-wire Fieldbus cycle or bus 34. The bus 34 includes different sections or segments, 34a, 34b, and 34c, which are separated by bridge devices 30 and 32. Each of the sections 34a, 34b, and 34c, interconnects a subset of devices attached to the busbar 34 to allow communications between the devices a manner described here below in the present. Of course, the network of Figure 1 is only illustrative, there being other ways in which a process control network can be configured using the Fieldbus protocol. Typically, a configurator is located in one of the devices, such as in the central computer 12, and is responsible for establishing or configuring each of the devices (which are "intelligent" devices because each includes a microprocessor capable of performing communication and, in some cases, control functions) as well as recognizing when new field devices are connected to the busbar 34, when the field devices are removed from the busbar 34, receiving data generated by the field devices 16-32, and linking to one or more user terminals, which may be located in the central computer 12 or in any other device connected to the central computer 12 in any way. The busbar 34 supports or allows purely two-way digital communication and can also provide a power signal to any or all devices connected thereto, such as field devices 16-32. Alternatively, any or all of the devices 12 - 32 may have their own power supplies or may be connected to external power supplies via separate cables (not shown). Although the devices 12.32 are illustrated in Figure 1 as connected to the busbar 34 in a standard busbar connection, in which multiple devices are connected to the same pair of cables forming busbar segments 34a, 34b, and 34c, the Fieldbus protocol allows for other device / cable topologies that include point-to-point connections, in which each device is connected to a controller or a central computer via a separate pair of two cables (similar to typical analogue distributed control systems). -20 mA), and tree connections or "branch" in which each device is connected to a common point in a two-wire bus which 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 on different segments of bus 34a, 34b, and 34c, at the same baud rate or different communication speeds according to the Fieldbus protocol. For example, the Fieldbus protocol provides a communication rate of 31.25 Kbit / second (Hl) illustrated to be used by bus segments 34b and 34c of Figure 1, and a communication rate of 1.0 Mbit / second and / or 2.5 Mbit / second (H2), which would typically be used for advanced process control, remote input / output, and high-speed factory automation applications and is illustrated as being used by bus segment 34a of Figure 1. In the same manner data can be sent over the bus segments 34a, 34b, and 34c, according to the Fieldbus protocol using voltage mode signaling or current mode signaling. Of course, the maximum length of each busbar segment 34 is not strictly limited but, rather, is determined by the communication rate, the type of cable, the size of the wire, the power option of the busbar , etc. of that section. The Fieldbus protocol classifies the devices that can be connected to the busbar 34 into three categories, namely, basic devices, master link devices, and bridge devices, the basic devices (such as the devices)., 20,24, and 28 of Figure 1) can communicate, that is, send and receive communication signals in or from the bus 34, but they are not able to control the order and synchronization of the communication presented in the busbar 34. The master link devices (such as the devices 16, 22, and 26 as well as the host 12 of Figure 1) are devices that communicate over the busbar 34 and are capable of controlling the flow of the bus. and the synchronization of the communication signals on the busbar 34. The bridge devices (such as devices 30 and 32 of Figure 1) are devices configured to communicate on and interconnect individual segments or branches of a Fieldbus busbar to create large process control networks. If desired, the bridge devices can be converted between different data rates and / or different data signaling formats used on the different segments of the busbar 34, they can amplify travel signals between the busbar segments 34, they can filter the signals that flow between the different segments of the busbar 34 and pass only the signals destined to be received by a device or one of the segments of the busbar to which the bridge is coupled and / or can take other necessary actions to link different segments of the busbar 34. The bridge devices that connect the bus segments that operate at different speeds must have master link capabilities on the side of the lowest speed segment of the bridge. The central computers 12 and 15, the program logic controller 13, and the controllers 14 can be any type of Fieldbus device but, as typically, will be master link devices. Each of the devices 12-32 is capable of communication over the busbar 34 and, importantly, is capable of independently performing one or more process control functions using data acquired by the device, from the process, or from of different devices via communication signals on the busbar 34. Fieldbus devices are therefore capable of directly implementing portions of a global control strategy which, in the past, was carried out by means of a centralized digital controller of a Distributed control system. To perform control functions, each Fieldbus device includes one or more standardized "blocks" which are implemented in a microprocessor within 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 known as block objects. A resource block stores and communicates device-specific data that relates to some of the characteristics of a Fieldbus device including, for example, a device type, a device revision indication, and indications of whether another device can be obtained device-specific information within a device memory. Although different device manufacturers can store different types of data in the resource block of a field device, each field device according to 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, thus, the function blocks are generally known as input, output function blocks , and control. However, other categories of function blocks such as hybrid function blocks may exist or may be developed in the future. Each block of input or output function produces at least one input process control (such as a process variable from a process measurement device) or process control output (such as a valve position sent to an activation device) while each control function block uses an algorithm (which can be proprietary) to produce one or more process outputs from one or more process inputs and control inputs. Examples of standard function blocks include the analog input (AI), analog output (AO), deviation (B), control selector (CS), discrete input (DI), discrete output (DO), manual loader (ML), proportional / derivative (PD), proportional / integral / derivative (PID), ratio (RA), and signal selector function blocks (SS). However, there are other types of function blocks and you can define or create new types of function blocks to operate in the Fieldbus environment. A transducer blocks couples the inputs and outputs of a function block with local hardware devices such as device triggers and sensors to allow the function blocks to read the outputs of the local sensors and instruct the local devices to perform one or more functions such as moving a valve member. The transducer blocks typically contain information that it is necessary to interpret signals released by a local device and adequately control local hardware devices that include, for example, information that identifies the type of a local device, calibration information associated with a local device, etc. . Typically a single transducer block is associated with each input or output function block.

Most function blocks are capable of generating alarm or indication of events based on previously determined criteria and are capable of operating differently in different ways. In general, 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, for example, a function block, is controlled manually; an out-of-service mode in which the block does not operate; a cascading mode in which block operation is affected from (determined by) the outputs of a different block, and one or more remote modes in which a remote computer determines the block mode. However, there are other modes of operation in the Fieldbus protocol. Importantly, each block is able to communicate with other blocks in the same or different field devices over the Fieldbus bus 34 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. Thus, for example, a proportional / integral / derived function block in a field device can be connected via the busbar 34 to receive an output of an analog input function block in a secfield device so as to release data in an analog output function block in a third field device, and receive an output from the analog output function block as feedback to create a separate process control cycle apart from any distributed control system controller . In this way, the combinations of function blocks move the control functions out of a centralized distributed control system environment, which allows multiple function controllers of distributed control systems to perform supervision or coordination functions or be totally eliminated. . In addition, the function blocks provide a graphical structure, oriented by blocks for the easy configuration of a process and allow the distribution of functions between field devices of different suppliers because these blocks use a protocol of consistent communications. In addition to containing and implementing block objects, each field device includes one or more other 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 block (such as the function blocks) both internal to the field device and through the Fieldbus bus 34. Trend objects allow local parameter trends of function blocks to be accessed by other devices such as central computer 12 or controllers 14 of Figure 1. Trend objects retain short-term historical data belonging to, for example, to some 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 on the busbar 34. These alarms or events can be related to any event that occurs within a device or one of the blocks of a device. View objects are previously defined groupings or block parameters used in the standard human / machine interface and can be sent to other devices for viewing from time to time. Referring to Figure 2, Fieldbus devices, which may be, for example, any of the field devices 16-28 of Figure 1, are illustrated as including resource blocks 48, function blocks 50, 51 , or 52 and transducer blocks 53 and 54. In the first device, the function block 50 (which can be an input function block) is coupled through the transducer block 53 to a sensor 55 which can be, for example , a temperature sensor, a fixed reference point indication sensor, etc. In the second device, the function block 51 (which may be an output function block) 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 therewith for making the trend of the input parameter of the function block 52. The link objects 58 define the block parameters for each of associated blocks and alert objects 59 provide alarms or event 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 they are associated. These lists contain necessary information for each of a set of different views defined. Of course, the devices of Figure 2 are merely exemplary and other quantities and types of objects of blocks 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 the process control network 10 representing devices 16, 18 and 24 as the positioning / valve devices and devices 20, 22, 26, and 28 as the transmitters as well. illustrates the function blocks associated with the setter / valve 16, the transmitter 20, and the bridge 30. As illustrated in FIG. 3, the setter / valve 16 includes a resource block (RSC) 61, a transducer block (XDCR). ) 62, and several function blocks that include an analog output function block (AO) 63, two proportional / integral / derived function blocks (PID) 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. Also the bridge 30 includes a resource block 61 and a proportional / integral / function block. derived 68. As will be understood, the different is function blocks of Figure 3 can operate together (communicating on the busbar 34) in several control cycles and control cycles in which the function blocks of the setter / valve 16, the transmitter 20, and the bridge 30 are located are identified in Figure 3 by a cycle identification block connected to each of these function blocks. Thus, as illustrated in Figure 3, the analog output function block 63 and the proportional / integral / derivative function blcque 64 of the setter / valve 16 and the analog input function block 66 of the transmitter 20 are connect within the control cycle indicated as L00P1, while the signal selector function block 69 of the setter / valve 16, the analog input function block 67 of the transmitter 20, and the proportional / integral / derivative function block 68 of the bridge 30 are connected in a cycle of control indicated as L00P2. The other proportional / integral / derivative function block 65 of the setter / valve 16 is connected within a control cycle indicated as L00P3. The interconnected function blocks that make up the control cycle indicated as LOOP1 in Figure 3 are illustrated in greater detail in the control cycle scheme shown in Figure 4. As can be seen from Figure 4, the control cycle L00P1 it is formed entirely by communication links between the analog output function block 63 and the proportional / integral / derivative function block 64 of the setter / valve 16 and the analog input function block 66 of the transmitter 20 (FIG. 3). The control cycle diagram of Figure 4 illustrates the communication interconnections between these function blocks using lines joining the process and control inputs and outputs of these function blocks. In this way, the output of the analog input function block 66, which may comprise a process measurement or a process parameter signal, is communicatively coupled via the busbar segment 34b with the input of the proportional function block / integral / derivative 64 having an output comprising a control signal communicatively coupled with an input of the function block of the analog output 63. An output of the analog output function block 63, which comprises a feedback signal indicating , for example, the position of the valve 16, is connected to a control input of the proportional / integral / derivative function block 64. The proportional / integral / derivative function block 64 uses this feedback signal together with the signal of process measurement from the analog input function block 66 to implement the appropriate control of the analog output function block to 63. Of course, the connections indicated by the lines in the control cycle diagram of Figure 4 can be made internally within a field device when, as in the case of the analog and proportional output function blocks / integral / derived 63 and 64, the function blocks are within the same field device (for example, the setter / valve 16); or these connections can be implemented over the two-wire communication bus 34 using standard Fieldbus synchronous communication. Of course, other control cycles are implemented by other function blocks that are communicatively interconnected in other configurations. To implement and perform communication and control activities, the Fieldbus protocol uses three general categories of technology identified as the physical layer, a communication "stack", and a user layer. The user layer includes 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 configured by a user in a standard manner. The physical layer and the communication stack are necessary to effect communication between different blocks of different field devices in a standardized manner using the two-wire busbar 34 and can be modeled by the well-known layer communication model Open Systems Interconnect (OR IF) . The physical layer, which corresponds to layer 1 of the interconnection of open systems, is embedded in each of the field devices and of the busbar 34 and operates to convert the electromagnetic signals received from the fieldbus transmission medium (the two-wire busbar 34) in 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 open systems interconnection layer 2, a Fieldbus access sublayer, and a Fieldbus message specification layer , which corresponds to layer 6 of interconnection of open systems. There is no corresponding structure for layers 3-5 of interconnection of open systems in the Fieldbus protocol. However, Fieldbus device applications comprise a layer 7 while the user layer is a layer 8, not defined in the open systems interconnection protocol. Each layer in the communication stack is responsible for encoding or decoding a portion of the message or signal that is transmitted over 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 limiters and, in some cases, decode the striped portions of the Fieldbus signal to identify whether the rest of the signal or message should be sent or if the signal should be discarded due to, for example , which 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 over the busbar 34 and handles access to the busbar 34 in accordance with a deterministic centralized bus controller called an active link scheduler, which will be described in more detail below. . 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. Similarly, the data link layer converts the messages in the communication stack into Fieldbus signals and encodes these signals with clock information to produce a "synchronous series" signal having a preamble of its own for transmission in the bus bar. two cables 34. During the coding process, the data link layer recognizes special codes within 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 message received from the busbar 34. Likewise, the data link layer transmits Fieldbus signals over the busbar 34 by adding start and end delimiters to the messages in the communication stack and placing these signals in the means of transmission at the right time. The Fieldbus message specification layer allows the user layer (i.e., 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, the message formats, and the protocol behaviors required to construct messages that are to be placed in the communication stack and to be provided to the user 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 object dictionary services that allow a user to read an object dictionary of 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 a user to read and change communication relationships, known as virtual communication relations (VCRs) described hereinafter, associated with one or more objects of a device. Furthermore, the Fieldbus message specification layer provides variable access service, event services, upload and download services, and program invocation services, all of which are well known in the Fieldbus protocol and, therefore, they will not 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 make possible the operation of these layers, each Fieldbus device includes a management information base (MIB), which is a database that stores the virtual communication relationships, dynamic variables, statistics, synchronization programs, active programmer of link, the program of synchronization of execution of blocks of function and the information of direction and label of device. Of course, information within the administration information base can be accessed or changed at any time using standard Fieldbus messages or commands. In addition, a description of the device is usually provided with each device with each device to give a user or a central computer an extensive view of the information in the VFD. A device description, which typically must be signed for use by a central computer, stores the information necessary for the central computer to understand the meaning of the data in the VFDs of a device. As will be understood, to increase any control strategy that uses blocks of distributed functions in a whole process control network, the execution of the function blocks must be programmed with precision with respect to the execution of other function blocks in a cycle of particular control. Similarly, communication between different function blocks must be precisely programmed in the busbar 34 so as to provide adequate data for each function block before the block is executed. The manner in which different field devices (and different blocks within the field devices) communicate over the Fieldbus transmission medium will now be described with respect to Figure 1. For the communication to be presented., one of the master link devices of each bus segment 34 (e.g., devices 12, 16 and 26) operates as an active link scheduler (LAS) that actively programs and controls communication in the associated segment of the busbar 34.

The active link scheduler for each bus segment 34 stores and updates a communication program (an active link program) that contains the types in which each function block of each device is programmed to begin the periodic communication activity in the bus 34 and the length of time for which this communication activity will occur. Although there may be one and only one active link programming device in each bus segment 34, other master link devices (such as device 22 in segment 34b) may serve as active back-link schedulers and become active when, for example, the current active link scheduler fails. Basic devices do not have the ability to become an active link scheduler at any time. In general, the communication activities on 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 and receive data from any bus segment 34, even if it is physically connected to a bus. different segment of the busbar 34, through the coordinated operation of the bridges and the active link programs in the busbar 34. During each macrocycle, each of the active function blocks in a particular segment of the busbar 34 executes, usually at a different time, but precisely programmed (synchronous) and at another time programmed with precision, publishes its output data in that busbar segment 34 as the response to a mandatory data command generated by the appropriate active link program. Preferably, each function block is programmed to publish its output data shortly after the completion of the execution period of the function block. In addition, the data publication times of the different function blocks are programmed in series so that two function blocks do not publish data in a particular segment of the busbar 34 at the same time. During the time when synchronous communication is not present, each field device, in turn, is allowed to transmit alarm data, view data, etc. in an asynchronous manner using symbol-driven communications. The execution times and the amount of time necessary for the complete execution of each function block are stored in the information and administration database (MIB) of the device in which the function block resides, while, as mentioned above, the times for sending the mandatory data commands to each of the devices in a bus segment 34 are stored in the management information base of the active link programming device for that segment. These times are typically stored as displaced times because they identify the times in which a function block will execute or send data as a shift from the beginning of an "absolute link program start time", which is known by all the positive signals connected to the busbar 34. To carry out communications during each macrocycle, the active link program, for example, the active link program 16 of the busbar segment 34b sends a mandatory data command to each one. of the devices in bus segment 34b according to the list of transmitted 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 so that the execution of that block is completed shortly after the block is programmed to receive a mandatory data command, the data published in response to a mandatory data command should be the largest the most recent output data of the function block. However, if a function block runs slowly and does not have new outputs secured when it receives the mandatory data command, a function block publishes the output data generated during the last run of the function block and indicates that the published data is old data using a time stamp. After the active link program has sent a mandatory data command to each of the function blocks on a particular segment of the busbar 34 and during the times when the function blocks are executed, the active link programs they can cause asynchronous communication activities. To perform asynchronous communication, the active link program sends a pass-through message to a particular field device. When the field device receives a passcode message, the field device has full access to the busbar 34 (or a segment thereof) and can send asynchronous messages such as alarm messages, trend data, change of fixed point of operator, etc. until the messages are complete or until an assigned maximum "sign support" time expires. After that, the field device releases bus 34 (or any particular segment thereof) and the active link program sends a passcode message to another device. This process is repeated until the end of the macrocycle or until the active link program 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 all devices can receive a pass-through message during each macrocycle. Figure 5 illustrates a schematic schedule representing the times at which the bus segment function blocks 34b of Figure 1 execute during each macrocycle of the busbar segment 34b at the times at which the synchronous communication is presented during each macrocycle associated with the busbar segment 34b. In the synchronization program of Figure 5, the time is indicated on the horizontal axis and the activities associated with the different function blocks of the setter / valve 16 and the transmitter 20 (of Figure 3) are illustrated on the vertical axis. The control cycle in which each of the function blocks operates is identified in Figure 5 as a subscript designation. In this way AILooPl to the function block 66 of the transmitter 20, ID OOPI refers to the function block Al 66 of the transmitter 20, PIDLOOPI refers to the function block 64 of the setter / valve 16, and so on. The execution period of the block of each of the illustrated function blocks is represented by the shaded cross box while each programmed synchronous communication is identified by a vertical bar in Figure 5. In this way, according to the timing program of Figure 5, during any particular macrocycle of segment 34b (Figure 1), the function block AILQOPI executes first for the period of time specified by box 70. Then, during the period of time indicated by vertical bar 72, the The output of the AILooPl function block is published in the bus segment 34b in response to a mandatory data command from the LAS for bus segment 34b. Likewise, boxes 74, 76, 78, 80, and 81 indicate the execution times of the function blocks PIDLOOPl <; AILOOPl 'AOPLOOPl < 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 PID OOPI 'AILOOP2' AOLOOPl ' ssLOOP2 'and PIDLOOP3' respectively, publish data in the busbar segment 34b. As will be apparent, the synchronization program in 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 function blocks are not being executed and when synchronous communication is not occurring on the busbar segment 34b. Of course, if desired, different function blocks can be intentionally programmed to run at the same time, and not all function blocks should publish or transmit data and messages about the busbar if, for example, no other device subscribes to them. data produced by a function block. The field devices are capable of publishing or transmitting data and messages about the busbar 34 using one of the three virtual communication relations (VCR) defined in the Fieldbus access sublayer of the stack of each field device. A virtual client / server communication relationship is used for queued communications, unscheduled, initiated by the user, one by one among the devices in the busbar 34. These queued messages are sent and received in the order submitted for transmission , according to your priority, without overwriting in previous messages. In this way, a field device can use a virtual client / server communication relationship when it receives a passcode message from the LAS to send a request message to another device in the busbar 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 pass-through message from the LAS. The client / server virtual communication relationship is used, for example, to effect the requests initiated by the operator such as fixed point changes, access and change to the tuning parameter, alarm acknowledgments, and device loads and discharges. A report distribution of virtual communication relationship is used for queued communications, initiated by the user, one with many. For example, when a field device with an event or trend report receives a LAS step sign, that field device sends its message to a "group address" defined in the Fieldbus access sublayer of the communication stack. of that device. The devices that are configured to listen in that virtual communication relationship will receive the report. The distribution of VCR type reports is typically used by Fieldbus devices to send alarm notifications to operator consoles. A virtual communication relationship type editor / subscriber is used for one-to-many communications stored in buffer. The communications in buffer are those that are stored and send only the latest version of the data and, thus, the new data is completely overwritten in the previous data. The outputs of the function blocks, for example, comprise buffer data. An "editor" field device publishes or outputs a message using the publisher / subscriber type virtual communication relationship for 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. Publisher / subscriber relationships are previously determined and defined and stored within the Fieldbus access sublayer of the communications stack of each field device. To ensure adequate communication activities on the busbar 34Each LAS periodically sends a time distribution message to all field devices connected to a bus segment 34, which allows the receiving devices to adjust their local application time to be in synchronization with the other. Among these synchronization messages, the clock time is maintained independently in each device based on its own internal clock. Clock synchronization allows field devices to stamp time throughout the Fieldbus network to indicate, for example, when the data was generated. In addition, each LAS (and other master link device) 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 pass-through message. The LAS continuously recognizes new devices added to a bus segment by periodically sending probe node messages to addresses that are not in the live list. In fact, each LAS is required to poll at least one address after it has completed a cycle of sending pass-through messages to all field devices in the live list. If a field device is present at the polled address and receives the probe node message, the device immediately returns a probe response message. Upon receiving a probe response message, the LAS adds the device to the live list and confirms it by sending a node activation message to the polled field device. A field device remains in the live list for as long as the field device responds appropriately to the pass-word messages. However, a LAS removes a field device from the live list if the field device, after three successive attempts, does not use the sign or immediately returns the sign to the LAS. When a field device is added to or removed from the live list, the LAS broadcasts live list changes to all other master link devices in the appropriate segment of the busbar 34 to allow each device to Master link keep a current copy of the list live. As mentioned above, the communication interconnections between the function blocks of the field devices and the execution times of the function blocks are determined by a user and implemented within the process control network 10 using an application of configuration located in, for example, the central computer 12 which programs the LAS to program the execution times and the communication times of the function blocks. It is generally inconvenient, however, to simply implement a process control scheme and then start the process by running it without first testing that scheme to ensure that there are no parasites and to ensure that the process control cycles of the control scheme are tuned in a adequate In fact, a small error somewhere in the process control scheme can cause the process to become unstable very fast, which can be unsafe and can damage the process control components. In addition, even if the control scheme is correct, there are parameters, such as time parameters, gains, etc., that need to be fine-tuned to ensure proper process operation. It is convenient, therefore, to provide a mechanism to stop and start the operation of the process at different times during the operation of any given control cycle and to provide a mechanism to view the status of the process or a process control cycle looking at the values of the process parameters at distributed positions within the control cycle to ensure that the control cycle is operating in accordance with the desired plan and / or to fine tune certain parameters within the control cycle. Although a Fieldbus process control network could be debugged or tuned by having a central computer 12 establish trend blocks in each of the devices, collect the values of the trend data and then display that data to the user after the process control cycle has begun to run, to perform this type of communication, the central computer 12 must use asynchronous communications (unpublished ) that allow the central computer to access the busbar only when the central computer 12 receives a pass-sign message from a LAS. As a result, the central computer 12 may have no way of guaranteeing that the feedback data collected by the targeted objects will not be lost due to overwriting, and so on. Also, host 12 may have no way to determine precisely when the trend data was collected with respect to the operation of other blocks within the control cycle or may have to regenerate cycle synchronization to determine which control functions were occurring when the data was collected. This process can be inaccurate, tedious and time consuming and, in addition, does not actually stop the operation of the process control cycle when the data is collected. In accordance with the present invention, the inflection points or one-stop stopping points are set in or between the devices and / or the function blocks that constitute a process control cycle and operate to allow a control cycle of process within a process control network that has distributed control functions to stop when one of the inflection points or one-step stopping points is reached. Moreover, a tuning procedure can enable the process control cycle to execute one or more complete cycles to produce a "trace" of the process control cycle, which can then be used to refine the process control cycle. Thus, according to the present invention, the values of the variables or process control parameters are stored in a memory of one or more of the field devices and are sent, via the busbar, to a user to enable the user see the status of the process control cycle at each of the inflection points or one-step stopping positions, or during a tuning procedure. If desired, turning points or single-step stopping points can be located on a device and occur when the device operates within the process control scheme, they can be located between the different process control functions, such as between the function blocks, of the process control cycle and / or can be located within an algorithm that constitutes any particular process control function. Of course, a device manufacturer must typically provide one-step stopping point and point of stopping functionality within the algorithm that constitutes the function block because these algorithms are typically owned by the device manufacturer and are usually set or they are permanently encoded within a memory within the field device. At each of the inflection points, the single-step stopping points or tuning stopping points, the operation of the process control scheme automatically stops until the user orders to start again via asynchronous communications on the bar collector 34. If desired, any of the inflection points, single-step stopping points or tuning procedures, may have one or more conditions associated with them, which, when they coincide, cause the algorithm or the process control network ceases the operation and, if they do not coincide, they make the process control scheme continue without interruption. The condition may be associated with the value of some variable, a time, or any other desired condition. Of course, turning points and stopping points can also be turned off and on, so that the user can control how many points of inflection, of stopping, will be operative during a particular debugging procedure. Upon reaching a turning point or a one-stop stopping point, one or more devices emit the values of the variables desired to the user on the busbar 34 using communications either synchronous or asynchronous, to allow the user to see the status of the process control network at the inflection point or the single-stop point and to see the condition that caused the inflection or arrest to occur. Although inflection points and single-step stopping points are typically located within or between the function blocks of a process control cycle, a tuning procedure may have a localized interruption at the end of a cycle execution cycle Process control (that is, at the end of each macrocycle or after completing a previously determined number of macrocycles of a busbar segment) to stop the execution of the cycle. After this, the tuning procedure can provide the user with data pertaining to the cycle operation during the previous macrocycles and allows the user to change certain tuning parameters within any of the process control functions or function blocks to refine by this the process control cycle. Of course, these communications can be made using asynchronous communications in the busbar 34 while the normal operation of the control cycle is suspended. Referring now to Figures 6A, 6B and 6C, the flowcharts of the methods for debugging and tuning a process control cycle according to the present invention are illustrated. The methods to debug and fine-tune a process cycle are generally used by a process engineer to achieve visibility with respect to the operations of the process control network while controlling the flow of the process control cycle. These methods to debug and fine-tune a process control cycle allow the process engineer to initialize the process control cycle and detect problems resulting from inadequate initialization or resulting from changes in the system over time. Of course, the methods for debugging and fine-tuning a process control cycle of Figure 6 can be activated as normal start activities to carry out an online process control cycle. It should be noted that the elements or routines that make up these cycles can be stored in one or more memories in a central computer device and / or in memories in one or more of the field devices as mentioned in more detail below. When debugging and refining a process control cycle, three general routines can be used which include a turning point management routine 102 (Figure 6A), a one-step mode management routine 104 (Figure 6B), and a tuning management routine 106 (Figure 6C). Each of the three routines 102, 104, and 106 are operative only in an operation tuning or tuning mode which can be initiated by a central computer, such as the central computer 12 of Figure 1, by sending a command to the function blocks that have one-way, one-step, and tuning capabilities to cause one-step and inflection point operations to be activated. At this time, the central computer 12 can specify (according to the user's instructions) which inflection points should be turned on, what the inflection conditions will be at each inflection point and what data should be collected at the inflection points (or one-step stopping points) to be sent to the central device 12 for visual display to a user. For a tuning procedure, the central computer 12 can specify the parameters that are to be viewed and / or potentially changed, the number of cycle execution cycles that will be performed before the changes in the tuning parameters are allowed, and so on. In effect, this command or series of commands places the process control network in a debug mode or a tuning mode. Referring to Figure 6A, the inflection point handling routine 102 controls the flow of a process control cycle as the control cycle executes function blocks in multiple field devices, such as field devices 16, 18 , 20 and 22 in the busbar segment 34b of FIG. 1. A block 110, which can be implemented by software within a central device having a user interface, location and other data associated with each of the desired inflection points is fixed using, for example, asynchronous communications on the busbar 34. The inflection points can be set at an instruction level (step 112), in which the execution of a particular instruction within a device or a function block of a device causes an interruption condition to be examined, at a level of the function block (step 114), in which the data flow to or from a block The particular function or execution of a function block of a process control cycle causes an interrupt condition to be examined, and / or at the device level (step 116), in which the data flow to or from a device or the operation of a device causes an interruption condition to be examined. Of course, multiple inflection points can be set and different inflection points can be set at different levels of instruction, function block and devices. At the instruction level, the inflection points are set within a function block at a selected instruction address location. In the execution of a designated instruction address, the condition of the inflection point is examined to see if the condition is satisfied. If it is satisfied, the execution ends. Although this type of inflection point is similar to the capacity of the inflection point of centralized processors in general, the referenced instruction is inside a device located at a remote location with respect to the user interface terminal, not the central device. . At the function block level, the inflection points are fixed in the data transfer between function blocks or at the end or beginning of the execution of a function block. The inflection points between the function blocks can be forced by controlling the active link scheduler in the operating system to prevent a mandatory data message from being applied to the next function block until after the user has sent a message indicating that the operation of a process control cycle should continue. In this case, the active link scheduler, which is controlled by the Fieldbus communication stack, is directed to stop executing a selected function block until a user orders it to be executed. At the device level, the inflection points are set within a function block at the location of a specified device address. In the execution of the designated device, execution is terminated or stopped based on the inflection point condition. A step 118 sets each of the defined inflection points to be presented unconditionally or conditionally after a selected event and stores an indication of the parameters of that event (e.g., the values of a parameter causing a conditional interruption, etc.) ) in an active link programming device or in other devices according to the user input applied to the central computer 12. A step 120 sets a function block, typically the function block more upstream of a control cycle such as an analog output function block (AO), for the simulation of the operating status so that the data parameters that are accessed during the operation of the control cycle they are sent to the central computer device 12 via the busbar 34. After that, in step 122, the process control cycle is executed until an active inflection point is detected by step 124. In general, one or more controllers to implement the inflection point handling routine 102 may reside in the device having the active link scheduler devices and / or other devices and may control the active link scheduler for the appropriate bus segment to allow that the process control network executes, until it reaches a point of inflection. At the inflection point, the active link controller or other controller stops the execution of the process control cycle, and allows access to selected parameters stored in the function blocks of the field devices within the process control cycle relevant. Thus, a step 126 has access to selected parameters and a step 128 transmits these parameters together with data indicative of the location of the inflection point and data corresponding to the reason that the inflection point was presented (for example, the condition) to the central computer 12 for visual display for a user. The central computer 12 can also acquire additional process data (for display to the user) using any known or desired communication method. In a Fieldbus system, a view function block operation, which allows the Fieldbus communication software stack of a device to read published variables by adding the link objects to the general-purpose input blocks, as necessary, or A client function block that runs to update a deployment of published variables can be used to inspect process data at a tipping point. The operation of the view function block eliminates the need to examine the variables separately, which, in turn, reduces the number of busbar cycles required to recover data that is already available in the busbar. A step 130 continues to execute the process control scheme (returning to step 122) when instructed to do so by the user via the central computer 12. If the user does not wish to continue but, rather, wishes to terminate or change the turning points , a step 132 clarifies or changes the inflection points within the process control network as instructed by a user via the central computer 12. A step 133 then continues executing the process control scheme with the new inflection point or the conditions of the inflection point installed (the control returning to step 122) or the inflection point routine 102 terminates. As will be described in more detail hereafter, different steps are preferably performed by software in the active link programmer device of the busbar or individual field devices as necessary to control the operation (stop and start) of the blocks of f anointing within the process control cycle that is being debugged. Referring now to Figure 6B, the one-step mode that handles routine 104 controls the flow of a process control cycle as the control cycle executes the function blocks in multiple field devices within the control network of processes 10. The routine that manages the one-step mode 104 can control the active link scheduler device to run the process control network until a one-step stop point is reached, to stop the cycle execution, to then access selected parameters stored or generated by the function blocks of the field devices within the process control network 10 and then send this data to the central computer device for visual display to a user. In particular, a step 134 sets a step level at an instruction level (step 136), at a function block level (step 138) and / or at a device level (step 140), similar to those levels in the routine 102 of Figure 6A. Thus, when scaling at an instruction level, the steps are set at each instruction address location within a function, i.e., they are set within the algorithm that implements a function of a function block. In the execution of the designated instruction address, the execution ends. When scaling at the block level, the addresses between each function block are specified. As in inflection points between inflection blocks, these single-step stopping points can be carried out by controlling the active link scheduler in the cycle to stop execution at the end of each execution time or function block publication . In one embodiment, the active link scheduler is controlled by the communication stack to stop execution of selected blocks. When scaling at the device level, the steps are set at the location of an address of each device. In the execution of the designated device, the execution of the process control scheme for the cycle is terminated. In step 142 the process control network then runs, for example, allowing the active link scheduler device to issue mandatory data commands and a step 144 determines whether a one-step stop point has been reached. If not, step 142 repeats until a one-step stop point is reached. When a stopping point is reached, a step 146 retrieves the parameters or other specified data associated with the one-stop stopping point, and a step 148 transmits this data to the user in the central computer device. At this time, data indicative of the location of a one-stop stopping point can also be sent to the central computer device for deployment to a user. The one-step mode that governs routine 104 continues in a block 150 and, in the address of a user via central computer 12, returns control to step 142, unless central computer 12 directs the end of the process. routine that handles the one-step mode 104. If it ends, the one-step mode is deleted by a step 150 and routine 104 ends. The routine that handles the inflection point 102 and the routine that handles the one-step mode 104 allow an operator to analyze process data and function blocks and detect problems that may be present in a control strategy without the scheme of process control that runs through a large number of cycles, during this time the process control network can become unstable. In addition, these routines allow a user to see data associated with the process control cycle that would not normally be sent to a central computer device or to deploy a user to thereby allow the user to debug a process control scheme. Referring now to Figure 6C, a flowchart illustrating the operation of the tuning routine 106 is provided. Tuning is typically used to set gains or time constants in, for example, proportional / integral / function blocks differential such as the proportional / integral / differential function block 64 of Figure 4, so that the control cycles produce adequate outputs during the operation. Of course, the proportional / integral / differential control is preferably adjusted so that the process control cycle responds reasonably quickly to changes in inputs (i.e., so that the cycle is not overdamped) but in such a way that the process control cycle does not respond so fast that the cycle oscillates a lot as a response to a change (that is, so that the cycle does not rise again).

The tuning routine 106 begins with a step 162 that initiates a control cycle with a set of test tuning parameters. After the control cycle (such as LOOP1 of Figure 4) is executed for a selected amount of time or a predetermined number of macrocycles, a step 164 changes a fixed operational point or some other parameter or value of the cycle and, after this, a step 166 determines the trend of the data or parameters of the cycle by means of collecting and storing predetermined parameter values in a memory during, for example, each cycle macrocycle. After, for example, a predetermined number of runs of the process control cycle (ie, macrocycles), the response of the cycle can be determined because a trace of the cycle has been captured. At this time, the execution of the cycle is terminated or interrupted and the captured data is administered to a tuning device and / or to a user. In the tuner, a step 168 then calculates new tuning parameters based on the past performance of the cycle (i.e., the trend parameters) or, alternatively, a user sees the data and provides new tuning parameters manually. Next, a step 170 inserts the new tuning parameters (such as proportional / integral / differential gain, time constants, etc.) into the appropriate function blocks within the cycle being tuned. If desired, steps 162 to 170 can then be repeated as desired to adjust the tuning parameters. After a suitable set of gain or other tuning parameters is identified, the control cycle continues to run (in step 172) and a step 174 checks the stability of the cycle with the new parameters. When the cycle is stable and finely tuned, the tuning routine 106 can be discontinued and the cycle can be brought online in any desired manner. The methods 102, 104 and 106 for debugging and tuning a process control cycle operate by displaying data in real time (or in suspended times) as the cycles of the process control cycle and controlling the cycle to have control of, for example the active link programmer to perform inflection and one-step operations. In addition, the parameters are adjusted during real-time operations of the control cycle while other devices in the busbar 34 continue to operate normally, which allows a control cycle to be isolated and debugged without taking the rest of the process off-line. There are several different ways in which the debugging and tuning methods of the present invention can be implemented in a process control network having distributed control functions. For example, the routing, single pass, and cycle tuning 102, 104, and 106 routines can be implemented by having all the necessary debugging and / or tuning parameters (such as the directions of the inflection point and the trigger point). stop, conditions, cycle execution conditions, etc.) stored in the communication stack of the active link scheduler to control communications and control the execution of the function blocks within a process control cycle when the control cycle of processes is in a debug mode or a tuning mode. Referring to Figure 7, the process control cycle, L00P1, of Figure 4 is illustrated as having communicatively interconnected function blocks 66, 64 and 63, (each having a communication stack associated therewith) . In addition, a communication stack 190 of the active link programming device, which can be any of the devices on, for example, the bus segment 34b of Figure 1, is also shown to illustrate communications between the link scheduler active and function blocks 66, 64, and 63. In this embodiment, the communication stack 190 is configured to include the debugging and / or plot-tuning procedures used to allow the function blocks 66, 64 and 63 (or devices in which function blocks are located) operate independently, in a "partial output" mode of operation, thereby enabling the use of inflection points, single-step stopping points, and tuning procedures. In addition, in this configuration, the batteries associated with function blocks 66, 64, and 63 are slave cells that do not become operational unless they are intruded to do so by an instruction of the master stack, in this case the stack 190 of the active link scheduler device. To perform point of inflection, signal step or cycle analysis, master stack 190 sends mandatory data messages to function blocks 66, 64 and 63 in the order specified, for example, by the time program of Figure 5 However, the trace-tuning feature of the master stack 190 stores or otherwise maintains the trace of the locations of each of the inflection points or single-point stopping points (or tuning stopping points). and, when this inflection point or stopping point is reached, the operation of the process control cycle is stopped to determine whether the inflection point condition has been reached or the operation is stopped in the presence of an inflection point of a just happened. To perform these functions, the master stack 190 may receive an instruction from a function block or may receive data from a function block that allows the master stack to determine if an inflection point condition is satisfied. Of course, when a condition associated with an inflection point is not satisfied, the active link programmer continues to issue communication that allows the messages (mandatory data messages) to implement the process or strategy control scheme. However, when a valid inflection point or stopping point is reached, the trace-tuning procedure of the master stack 190 publishes collected or trend data for the user via the bus, forces one or more suitable devices to publish collected or trending data for the user via the bus bar or takes other necessary steps to inform the user (via a central computer device) that a cut has been presented, or a one-step stop, the reason for the inflection point , and / or the cycle conditions at the point of inflection or stopping point. Similarly, the master stack 190 can receive instructions from the user (via the central computer 12) to continue, change tuning parameters, and so on. The master stack 190 continues to execute the process control network by sending other mandatory data commands and passcode commands on the busbar 34 when an inflection point (or a one-step stop point) has not been reached or when the user orders the master stack (via bus 34) to continue until the next turning point, a single step or until a trace of the cycle has been recorded. In this way, the master stack within the active link scheduler device (or some other device) controls the operation of the process control cycle to allow the implementation of inflection points, stopping points, and routing characteristics of the routines 102, 104 and 106 of Figure 6. Of course, the trace-tuning instructions can be encoded in the stack of the active link scheduler device or other device and can include instructions necessary to communicate with a central computer or a user to receive the appropriate initialization data (which inflection points to turn on, what data to publish, etc.). When used in the tuning routine 106, the master stack 190 can deliver trend data or other data collected during the previous execution of the process control cycle to a tuner 192 located in the central computer, in the active link scheduler device or any other device, and / or can Send the data to a central computer for deployment to a user. The tuner 192 uses this data to calculate a new tuning parameter and / or may receive a new tuning parameter from a user. The tuner 192 then sends the new tuning parameter to the suitable device for use therein and the active link scheduler device then starts the process control scheme or allows the control scheme to continue.

In another embodiment, a separate trace-tuning function block may be associated with each of the blocks or devices within a process control cycle and these one or more trace-tuning function blocks may operate to control the blocks of the cycle's dentxo function during a tuning or debugging procedure to allow inflection points, single-point stopping points and tuning of the process control cycle. For example, with reference to Figure 8, the analog input function block 66 is illustrated as including a trace-tuning function block 200 while the proportional / integral / differential function block 64 and analog output function block 63 are illustrated as sharing a trace-tuning function block 202. However, if desired, separate trace-tuning function blocks can be provided for each of the proportional / integral / differential function and analog output function blocks. 64 and 63 or a trace-tuning function block can be used for any combination of function blocks within a device. As also illustrated in Figure 8, each of the function blocks 66, 64 and 63 includes places of inflection points and / or stopping points 204, each of which may have one or more conditions associated therewith. . As will be understood, function blocks 66, 64 and 63 may include any number of inflection points or other one-step stopping points programmed within the algorithm thereof and / or these inflection points or stopping points may be located in other directions within function blocks or in directions within a device. When a turning point, a single-step stopping point or a cycle tuning procedure is initiated, the trace-tuning function block 200 or 202 associated with each function block within the cycle is initiated, for example, by a central computer 12, and these trace-tuning function blocks are used to set the inflection point conditions at each of the inflection point locations 204 after receiving these conditions from a user or from a function block trace-master tuning _ located within, for example, a central computer device. After point-of-inflection conditions, a single step, cycle tuning, directions or other pointers that identify each point of inflection, single-step or cycle tuning are stored in trace-tuning function blocks 200 and 202 or function blocks 66, 64 and 63, the active link scheduler associated with the control cycle begins execution until a turning point, a single-pass stop point or a tuning stop point is reached Cycle. In particular, each inflection point within an algorithm, such as the algorithm of the analog input function block 66 is checked to see if the inflection point condition associated with an inflection point is satisfied and, if so, a indication of this is communicated to the trace-tuning function block 200, which immediately changes the mode of the analog input function block 66 to an inflection mode in which, in turn, causes the cascade or spill of the mode in Upstream function blocks in the process control cycle. At this time, the trace-tuning function block 200 may publish data within or associated with the analog input function block 66 and the inflection point condition via the synchronous or asynchronous bus communications to deliver this data to a user (or central computer device) or a trace-tuning function block that controls communication with a central computer device. The user can then send a signal on the busbar 34 to command the trace-tuning function block 200 that allows the function block 66 to continue the operation, which changes the tuning parameters, etc. or perform other functions specified in the routines 102, 104 and 106. When the analog input function block 66 is completed, the trace-tuning function block 200 can stop the operation of the cycle placing the analog input function block 66 back into a break mode before the analog input function block 66 posts its data in the busbar 34 to thereby cause a one-step function. Again, at this time, the relevant device or the data of the function block can be sent to the guest by the trace-tuning function block 200. Of course, this data can be stored in the function block 66, 64 or 63, performing the process control function or can be stored in the trace-tuning function block 200. After the user has indicated that the process control routine should continue, the trace-tuning function block 200 changes the function mode of the analog input block 66 back to normal mode, which causes the analog input function block 66 to continue execution or publish its data to the proportional / integral / differential function block 64 which can start the operation. During this time, the trace-tuning function block 202 is connected to the proportional / integral / differential function block 64 and the analog output function block 63 to determine if any inflection point, a single step, is reached, or location of tuning stop, and if so, change the mode of the block of the appropriate function 64 or 63 to thereby stop the operation of the process, which in turn, causes the spills of the mode in the current function blocks above the function block in which the interruption occurred. Similar to the trace-tuning function block 200, the trace-tuning function block 202 detects the occurrence of inflection points, single-step stopping points or tuning stopping points before, during or after execution of the function blocks 64 and 63 to thereby enable the operation of any of the routines 102, 104 or 106. In this manner, the trace-tuning blocks 200 and 202 can control cut points or stopping points within the code of the algorithms of any of the function blocks of a control cycle as well as between any pair of function blocks of a control cycle, such as immediately before or after a function block publishes its data in the bus 34 at the start of any device operation. Similarly, the trace-function function blocks 200 and 202 can send trend data or other requested data to a host device when a turning point or stopping point is reached. In addition, trace-tuning function blocks 200 and 202 control the stop and start of a cycle by changing the mode of a device with which it is associated. When used in a tuning routine, trace-tuning function blocks 200 or 202 can cause the associated function blocks to form trending or otherwise collect appropriate tuning data, can see this data or store that data in a memory associated with the trace-tuning function block and can send this data to a tuner or central computer device for use for visual display to a user and / or calculate a new tuning parameter, such as a proportional gain / integral / differential. In the same way, a trace-tuning function block associated with, for example, a proportional / integral / differential function block, such as block 64, can store the new tuning parameter at the appropriate memory location in the proportional / integral / differential 64 function block, and allow the cycle process to continue or start. Of courseyou. , at the beginning of a point of inflection routine, a single step or tuning routine, trace-tuning function blocks 200, 202, etc., must be initialized to ensure that they operate to adequately control each of the blocks of function within the control cycle. The trace-tuning function blocks 200 and 202 can be set so as not to interfere with the process control cycle during normal process operation and only stop the cycle operation when a debug or tuning procedure is initiated. In order to collect and send data belonging to a function block, a device, or a control cycle for a user, the trace-tuning function blocks 200 and 202 can form the data trend or can cause the function blocks that control the data trend and can provide trend data to the central computer for use to identify identification process conditions at a tipping point or stopping point and to identify new tuning parameters after the execution of any particular cycle of a process control cycle. Of course, if desired, other methods of implementing trace-tuning function blocks or trace-tuning functions such as inflection points, one-step points and tuning points as desired in a control network may be used. of processes to control the individual operation of each of the function blocks or devices within a process control cycle to enable, by this the stylized and specialized stop and start of those function blocks in previously determined or desired positions of debugging and fine-tuning a process control network. Although function blocks 200 and 202 were described herein for use in performing debugging and tuning procedures on or using a cycle comprising a function an analog output function block, an analog input function block and a block of proportional / integral / differential function connected in a simple control cycle configuration, the trace-tuning function blocks and other debugging and tuning routines of the present invention can be used in conjunction with other function blocks and other control functions such as is desired and may be implemented in control cycles having configurations other than those illustrated herein. In addition, the operations of function blocks 200 and 202 can be performed by software within a device related to the function blocks of that device without being a "function block" Fieldbus. However, it is advantageous to use function blocks to allow easy communication on the busbar during the debugging or tuning mode. Moreover, although the debugging and tuning capabilities as used with, and performed by Fieldbus "function blocks" are described herein, it is noted that the debugging and tuning capabilities of the present invention can be implemented. using other types of blocks, programs, equipment, unalterable memory programs, etc., associated with other types of control systems and / or communication protocols. In fact, while 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, it is not limited, and includes all kinds of devices, programs, routines, or other entity capable of performing a process control function in any way in positions distributed within a process control network. Thus, the debug and tuning function blocks or the routines described herein may be implemented in other process control networks or using other process control communication protocols or schemes (which may exist now or may be developed in the future ) which do not use what the Fieldbus protocol strictly identifies as a "function block" insofar as these networks or protocols provide or allow the control functions to perform in distributed positions within a process. further, although the functions of debugging and tuning and control blocks have been described here as being used to perform the debugging and tuning of control cycles that include placing devices / valves, it is noted that these functions and function blocks can be used to perform debugging and tuning, in control cycles that use other types of devices, such as those that have mobile elements such as shock absorbers, fans, and so on. Moreover, although the debugging and tuning functions described herein are preferably implemented in the software stored in one or more process control devices, alternatively or additionally they can be implemented in hardware, programs in unalterable memory, and so on, as want. If implemented in software, the debugging and tuning functions of the present invention can be stored in any readable computer memory such as on a magnetic disk, a laser disk, or other storage medium, in a direct access memory or a read-only memory of a device, and so on. In the same way, this software can be sent to a user or to a device via any known or desired delivery method, including, for example, over a communication channel such as a telephone line, the internet, and so on. Thus, although the present invention was described with reference to specific examples, which are intended to be illustrative only and not limiting of the invention, it will be apparent to those skilled in the art that changes, additions or deletions may be made to the embodiments described without departing from the spirit of the invention. spirit and scope of the invention.

Claims (28)

1. A system for use in debugging or tuning a process control network having distributed control functions implemented by a plurality of field devices communicatively linked over a busbar, wherein each of the field devices is capable of performing one or more process control functions and one or more communication functions, the system comprising: a process control operation programmer that programs the execution of each of the process control functions and the communication functions performed by the plurality of devices to define a process control scheme; an indicator indicating the position of process control scheme implemented by one of the plurality of field devices in which the process control scheme is to be interrupted when the process control scheme is in debug / tuning mode; and a controller that stops the execution of the process control scheme at the indicated flow position when the indicated flow position is reached and the process control scheme is in the debug / tuning mode.

The system of claim 1, wherein the programmer controls the communication on the bus by sending communication enable messages to the plurality of field devices and where the controller is coupled to the programmer to prevent the programmer from sending enabling messages. of communication to the field devices when the process control scheme is in the position of the process control scheme indicated in order to interrupt the process control scheme.

The system of claim 1, wherein the controller further includes a communicator that receives-instructions from a central computer device communicatively connected to the busbar and elements to make the operation of the process control program continue in response to a user data entry in the central computer device.

The system of claim 3, wherein the communicator includes elements for retrieving process control data to the state of the process in which the process control scheme is interrupted and elements for sending the process control data retrieved to the device. central computer to display it visually for a user.

The system of claim 3, wherein the indicator indicates a conditional inflection point in the process control scheme and the indicator includes elements for storing a condition associated with the conditional inflection point and elements to determine whether the associated condition with the conditional inflection point is satisfied when the inflection point is reached within the process control scheme.

The system of claim 3, wherein the indicator indicates a multiplicity of single-step stopping points in the process control scheme.

The system of claim 3, wherein the indicator indicates a tuning stop point within the process control scheme, and wherein the system further includes elements for storing process data for a process parameter generated prior to that the process control scheme is interrupted, a tuner that determines a process tuning parameter for the process control network based on the stored process data and elements for communicating the process tuning parameter to one of the plurality of field devices.

The system of claim 7, wherein the process tuning parameter is a gain.

The system of claim 1, wherein the indicator indicates one of the plurality of field devices so that the process control scheme is interrupted when one of the plurality of field devices is programmed to operate within the scheme of control of process.

10. The system of claim 1, wherein the indicator indicates an instruction address within one of the functions of one of the plurality of field devices to cause the interruption of the process control scheme when the instruction address is implemented in the process control scheme.

The system of claim 1, wherein the indicator indicates a function of one of the plurality of field devices to cause the interruption of the process control scheme when the function is implemented by a device of the plurality of field devices in the process control scheme.

The system of claim 1, wherein the controller includes elements located in at least one of the plurality of field devices, to interrupt the operation of a function performed by one of the plurality of field devices when the indicated position is associated with the operation of one of the plurality of field devices.

The system of claim 1, wherein the controller includes interruption elements located in each of the plurality of field devices, wherein each of the interruption elements interrupts the operation of a function performed by a field device. associated when the indicated position is associated with the operation of the associated field device.

14. A method for debugging and fine-tuning a process control network having distributed control functions implemented by a plurality of field devices communicatively linked on a busbar, wherein each of the field devices is capable of performing one or more process control functions and one or more communication functions, the method comprising the steps of: scheduling an execution order for process control functions and communication functions to define a process control scheme; mark one or more positions of process control schemes associated with the process control functions or communication functions in which the process control scheme is to be interrupted. execute the process control scheme; detecting when any of the plurality of field devices implements a control function or a communication function that constitutes one of the positions of the process control scheme marked; interrupt the execution of the process control scheme in the position of the process control program marked; wait for a user to indicate that the execution of the process control scheme should continue; and initiate the process control scheme in the position marked upon receipt of a user's indication that the execution of the process control scheme should continue. The method of claim 14, wherein the step of executing the process control scheme includes the step of sending messages that enable communication to the different devices of a plurality of field devices at different times and the step of interrupting the execution of the process control scheme includes the step of discontinuing the step of sending messages that enable communication until reception of the user's indication. The method of claim 14, which further includes the steps of retrieving process data pertaining to the process state when the process control scheme is interrupted and which sends the retrieved process data via the bus bar to a central computer to display it to a user. The method of claim 14, wherein the marking step includes the steps of marking one of the positions of the process control scheme as a conditional inflection point and storing a condition associated with the conditional inflection point, and in where the interruption step includes the steps of determining whether the condition associated with the inflection point conditions "is satisfied when the process control scheme reaches the conditional inflection point and continues automatically with the process control scheme if the condition does not The method of claim 14, wherein the marking step includes the step of marking a multiplicity of positions of the process control scheme as single-step stopping points 19. The method of claim 14. , where the marking step includes the step of marking one or more of the positions of the process control scheme as a stopping point of a control of processes within the scheme of: 3 process control, and wherein the method further includes the step of recovering process data associated with a process parameter from one of a plurality of field devices before it is interrupted the process control scheme, determining a process tuning parameter for the process control network using stored process data and communicating the process tuning parameter to another of the plurality of field devices. 20. A process control device for use in a process control network having distributed control functions implemented by a plurality of field devices communicatively coupled to a busbar, wherein each of the field devices includes or more function blocks capable of performing a data entry function, a data output function, or a control function within the process control network and capable of communication in the busbar, the process control device comprising: a first function block that implements a process function to perform a portion of a process control scheme; a memory that stores an indication of a point within the process control scheme associated with the first function block or with the device; and a trace-tuning function block communicatively ac-side to the first function block that includes elements for controlling the process control device to interrupt the process control scheme when the process control scheme reaches the indicated point. The device of claim 20, wherein the first function block includes an algorithm that performs the process function and the software that is communicated via the bus bar after the execution of the algorithm and wherein the indication indicates a point before or after the execution of the algorithm of the first function block. The device of claim 20, wherein the first function block includes a set of instructions that perform the function of the process, wherein the indicated point is associated with one of the set of instructions and wherein the control element of the block of function the trace-tuning stops the operation of the first function block when the first function block reaches the indicated one of the set of instructions. The device of claim 20, wherein the trace-tuning function block includes elements that respond to a user to restart the execution of the process control scheme at the indicated point. 24. The device of claim 20, wherein the trace-tuning function block includes elements for communicating data of the communication process from the process control device via the bus when the execution of the process control scheme is interrupted. . 25. The device of claim 20, wherein the trace-tuning function block further includes elements for indicating a condition to be satisfied at the indicated point, elements for determining whether the condition is satisfied at the indicated point and elements for stop the execution of the process control scheme when the condition is satisfied at the indicated point. 26. The device of claim 20, wherein the trace-tuning function block includes elements for changing the mode of the first function block when the process control scheme reaches the indicated point. The device of claim 20, wherein the trace-tuning function block includes elements for storing data associated with a process parameter during the operation of the process control scheme and elements for communicating the data stored via the bus when the process control scheme reaches the indicated point. The device of claim 20, wherein the trace-tuning function block includes elements for communicating process data from the first function block via the bus when the process control scheme reaches the indicated point. SUMMARY A system and method for debugging and fine-tuning a process control network having distributed control functions implemented by a set of field devices communicatively linked over a busbar includes an operational scheduler that schedules the execution of each of several control functions of processes and communication functions performed by the field devices to define a process control scheme and an indicator that indicates one or more process control scheme positions in which the process control scheme is to be interrupted automatically or conditionally to enable, through this the debugging and / or tuning of the process control network. A controller interrupts the execution of the process control scheme at the indicated flow positions, communicates process data to a user to display the current status or a past state of the process to a user and waits for the user's data entry before continuing with the operation of the process control scheme. In a tuning mode, the controller outputs data belonging to a process parameter to a tuning device or to a user that determines a new tuning parameter, such as a gain, to be used within the process control scheme based on the data of the process parameters.