MXPA99003081A - Process control network with redundant field devices and busses - Google Patents

Abstract

Functional elements within a two-wire, loop-powered, two-way digital communications environment are interconnected using selective redundant connections and selective redundant functional elements. The redundant functional elements and redundant connections provide a smooth transition from operation of a primary process loop element to a secondary process loop element in the event of a failure of the primary process loop element. Redundancy is selectively implemented using a redundant pair of field devices or a redundant bus pair having a primary bus and a redundant bus. In a first case, redundancey is selectively implemented using a single set of communication media (202 in fig. 6), such as a single communication loop, but implementing redundant functional elements (204, 206), such as field devices, so that recovery is achieved upon failure of a functional element but not upon failure of the communication media. In a second case, redundancy is selectively implemented using a redundant set of communication media (302, 303 in fig. 7) in addition to use of redundant devices (304, 306) so that recovery is attained both for a failing device and a failing communication media. In a third case, redundancy is selectively implemented using a redundant set of communication media (402, 403 in fig. 8) but using a single device (404) so that recovery is attained for a failing communication media but not for a failing device.

Description

PROCESS CONTROL NETWORK WITH FIELD DEVICES AND REDUNDANT COLLECTOR BARS RELATED APPLICATION This is a partial continuation of the United States of America Patent Application Serial Number 08 / 726,266 filed on October 4, 1996.

FIELD OF THE INVENTION The present invention relates in general to process control networks, and more specifically, to a process control network that implements process control functions in a distributed manner, using redundant functional elements, such as field and communication busbars.

DESCRIPTION OF THE RELATED TECHNIQUE Large processes, such as chemical and petroleum manufacturing and refining processes, and others, include numerous field devices arranged in different locations to measure and control the parameters of a process, in order to perform this way the control of the process. These field devices, for example, may be sensors, such as temperature, pressure, and flow rate sensors, as well as control elements, such as as valves and switches. Historically, the process control industry used manual operations such as manually reading the level and pressure gauges, turning the valve wheels, etc., to operate the measurement and control field devices within a process. Beginning in the 20th century, the process control industry began to use a local pneumatic control, where local pneumatic controllers, transmitters, and valve placers were placed in different places within a process plant to control the certain places on the floor. With the emergence of the distributed control system (DCS) based on microprocessor in the 1970s, the control of distributed electronic process in the process control industry became prevalent. As is known, a distributed control system includes an analog or digital computer, such as a programmable logic controller, connected with numerous electronic monitoring and control devices, such as electronic sensors, transmitters, current-to-pressure transducers, valve placers, etc., located through a whole process. The computer of the distributed control system stores and implements a centralized and often complex control scheme, to carry out the measurement and control of the devices within the process, in order to control in this way the parameters of the control system. process according to some global control scheme. Normally, however, the control scheme implemented by a distributed control system is proprietary to the controller manufacturer of the distributed control system, which in turn makes the distributed control system difficult and expensive to expand, refine, reprogramming, and serving, because the supplier of the distributed control system must become involved in a comprehensive manner to perform any of these activities. In addition, equipment that can be used by, or can be connected to, any particular distributed control system can be limited, due to the proprietary nature of the controller of the distributed control system, and the fact that the supplier of the control system is distributed. Distributed control system controller may not support certain services or functions of devices manufactured by other vendors. To overcome some of the problems inherent in the use of proprietary distributed control systems, the process control industry has developed a number of open standard communication protocols, including, for example, the HARTR, PR0FIBUSR, 0RLDFIPR, Device-NetR protocols. , and CAN, which make it possible for field devices made by different manufacturers to be used together within the same process control network. In fact, you can use any field device that complies to one of these protocols within a process, to communicate with, and to be controlled by, a controller of the distributed control system or another controller that supports the protocol, even when that field device is made by a manufacturer other than the manufacturer of the device. controller of the distributed control system. Moreover, there is now a movement within the process control industry to decentralize process control, and thus simplify the controllers of distributed control systems, or eliminate the need for distributed control system controllers to a large extent. grade. Decentralized control is obtained by having the field-mounted process control devices, such as valve placers, transmitters, etc., perform one or more process control functions, and then communicating the data through a busbar structure to be used by other process control devices in the performance of other control functions. To implement these control functions, each process control device includes a microprocessor that has the capability to perform a control function, as well as the ability to communicate with other process control devices, using a standard and open communication protocol. In this way, field devices made by different manufacturers can be interconnected within a process control network, to communicate with each other, and to perform one or more process control functions, forming a control cycle without the intervention of a controller of the distributed control system. The two-wire, all-digital bus bar protocol, which is now being promulgated by the Fieldbus Foundation, known as the FOUNDATION ™ Fieldbus protocol (hereafter referred to as "Fieldbus"), is an open communication protocol that allows devices made by Different manufacturers interoperate and communicate with each other through a standard busbar, to perform decentralized control within a process. No matter what the communication protocol is, process control elements, such as fluid control valves, are commonly used in hostile process control environments, where the temperature and pressure scales vary widely. The applications of fluid control valves for which hostile environments are common, include applications of oil and gas pipelines, nuclear power generating stations, and different process control applications. In these environments, substantial maintenance is common, including periodic preventive maintenance, maintenance due to valve rupture, and testing to verify that valves are functioning. appropriately. The control elements become fatigued or fail in these hostile environments, and occasionally must be replaced. Both the failure of a control element, as the replacement of a control element, usually requires the deactivation of the process control system, which is highly expensive and time consuming, due to the long intervals of time necessary to bring the system of process control to a stable condition following deactivation. Accordingly, it is desirable to provide an apparatus and an operating method that allows a process control network to use, for example, a two-way, two-wire digital communication protocol, energized by the cycle, or any other protocol. function of the distributed process, remain operative, despite the failure or replacement of functional elements in the network.

COMPENDIUM OF THE INVENTION In accordance with the present invention, functional elements are interconnected within a process control system, such as a two-way, two-way digital communications environment, energized by the cycle, using selective redundant connections and selective redundant functional elements. Redundant functional elements and redundant connections they provide a smooth transition from the operation of one element of the primary process cycle to one element of the secondary process cycle in the event of a failure of the primary process cycle element. In accordance with one aspect of the present invention, redundancy is selectively implemented using two sets of communication means, including a pair of redundant bus bars having a primary bus and a redundant bus. In accordance with another aspect of the present invention, redundancy is selectively implemented using a single set of communication means, such as a single communication bus, but implementing redundant devices, such as field devices, in such a manner as to achieve recovery when a device or other functional element fails, such as a function block, but not for the failure of the communication medium. In one embodiment, a cycle controller, such as a controller of the digital control system (DCS) or a field device, controls the redundancy operation of a single communication cycle having redundant functional elements therein. In this mode, the cycle controller is connected to a single communication bus, and the single communication bus is connected to a redundant pair of functional elements, such as devices. The functional elements selected, such as the control logic, detect a failure state, and communicate this state to a controller, or the controller detects a cessation of communications from a failed redundant functional element, and then automatically reconfigures the communication cycle, to reset in this way the communication status. In accordance with a further aspect of the present invention, redundancy is selectively implemented using a redundant set of communication media in addition to the use of other redundant functional elements, such as devices, in such a way that recovery is obtained for both a device that fail as for a means of communication that fails. In accordance with the present invention, a cycle controller, such as a digital control system (DCS) controller or a field device, controls the redundancy operation of a redundant pair of communication cycles having redundant bus bars connected to each other. the redundant devices. The cycle controller is connected to both a primary busbar and a redundant busbar of the redundant pair of communication cycles, and the redundant devices are connected to the redundant busbars, so that a primary device is connected to the cycle primary, and that a redundant device is connected to the redundant cycle. The selected functional elements detect and communicate a failure state to the cycle controller, or the cycle controller detects a cessation of communications from a failed functional element. In the case of a failure, for example, when the controller or control logic detects a failed functional element (either a busbar or a device), or the cycle controller detects a cessation of communications from an element, the controller cycle automatically reconfigures the redundant pair of communication cycles to restore the communication status. In accordance with a still further aspect of the present invention, redundancy is selectively implemented using a redundant set of communication means connected with a single device, so that recovery is obtained for a communication medium that fails, but not for a device that fails. In accordance with the present invention, a cycle controller, such as a digital control system (DCS) controller or a field device, controls the redundancy operation of the redundant communication means. The cycle controller is connected to both a primary busbar and a redundant busbar of the redundant pair of communication means, while a plurality of other functional elements, such as devices, are connected to the redundant pair of communication means. The selected functional elements detect a bad communication state, and the controller of cycle detects a cessation of communications. In this configuration, the cycle controller automatically reconfigures the redundant pair of communication media when a functional element detects a bad communication state, or the cycle controller detects a cessation of communications from an element, in order to restore the state Communication. Many advantages are achieved through the process control system described and the operating method. For example, it is desirable to avoid deactivating a process control line when a process device or communication bus experiences problems. It is also convenient to exploit the self-diagnostic functionality of the functional elements inside the process control system, to disable the failed elements, and to enable the replacement of the functional elements in an automatic way. In the same way, it is convenient that the two-way communication protocol of the process control system is exploited, in such a way that the redundant functional elements are activated automatically when a primary functional element fails.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a schematic block diagram of an exemplary process control network that uses the Fieldbus protocol. Figure 2 is a schematic block diagram of three Fieldbus devices having function blocks therein. Figure 3 is a schematic block diagram illustrating the function blocks inside of some of the devices of the process control network of Figure 1. Figure 4 is a schematic of the control cycle for a process control cycle inside the process control network of Figure 1. Figure 5 is a time diagram for a macrocycle of a busbar segment of the process control network of Figure 1. Figure 6 is a diagram of Schematic blocks illustrating a control system network, where redundancy is selectively implemented using a single set of communication media in combination with redundant devices. Figure 7 is a schematic block diagram illustrating a control system network, where redundancy is selectively implemented using a redundant communication means in combination with redundant devices. Figure 8 is a schematic block diagram illustrating a control system network, where it is implemented selectively redundancy using redundant communication media in combination with a single device. Figure 9 is a schematic block diagram illustrating a control system network having two functional elements connected in a single cycle of two wires. Figure 10 is a schematic block diagram illustrating a control system network having two transmitters connected in a single cycle of two wires. Figure 11 is a schematic block diagram illustrating a control system network having a redundant function block configuration. Figure 12 is a schematic block diagram illustrating a control system network that implements the redundancy of the field device in accordance with the present invention. Figure 13 is a schematic block diagram showing a digital field device having a digitally communicating, two-way, two-wire setter, energized by the cycle, for use in a process control network of the present invention. Figure 14 is a block diagram illustrating a field device controller suitable for use in the control of the digital field device of Figure 13.

DESCRIPTION OF THE PREFERRED MODALITIES Although the process control network having redundant field devices and busbars of the present invention is described in detail as a process control network that implements process control functions in a decentralized or distributed manner using a set of Fieldbus devices, it should be noted that the process control network having redundant characteristics of the present invention, can be a process control network that performs distributed control functions using other types of field devices and communication protocols, including protocols that are support two-wire busbars and different protocols that support analog and digital communications. Accordingly, for example, the process control network having redundant characteristics of the present invention, can be any process control network that performs distributed control functions, even when this process control network uses the HART communication protocols. , PROFIBUS, etc., or any other communication protocols that exist now or that may be developed in the future. Before discussing the details of the process control network having redundant characteristics 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 communication occurs in a process control network using the Fieldbus protocol. However, it should be understood that, although the Fieldbus protocol is a relatively new all-digital communication protocol developed for use in process control networks, this protocol is known in the art and is described in detail in numerous articles, brochures, and published, distributed, and available in, among others, the Fieldbus Foundation, a nonprofit organization with central offices in Austin, Texas. In particular, the Fieldbus protocol, and the way to communicate with, and store data in, devices using the Fieldbus protocol, is described in detail in the manuals called Communications Technical Specification and User Layer Technical Specification of the Fieldbus Foundation, which they are incorporated herein by reference in their entirety. The Fieldbus protocol is a two-way communication protocol, all digital, in series, that provides a standardized physical interface to a two-wire cycle or a "field" of busbar interconnection, such as sensors, actuators, controllers , valves, etc., located in an environment controlling the process or instrumentation of, for example, a factory or a plant. He Fieldbus protocol provides, in effect, a local area network for field instruments (field devices) inside a process, which makes it possible for these field devices to perform control functions in distributed locations throughout an entire process installation, and communicate with each other before and after the completion of these control functions to implement a global control strategy. Because the Fieldbus protocol makes it possible for control functions to be distributed throughout a process control network, it reduces the workload of, or entirely eliminates the need for, the centralized process controller normally associated with a system of distributed control. Referring to Figure 1, a process control network 10 using the Fieldbus protocol may include a central 12 connected to a number of other devices, such as a program logic controller (PLC) 13, a number of controllers 14, another central device 15, and a set of field devices 16, 18, 20, 22, 24, 26, 28, 30, and 32, by means of a Fieldbus cycle or two-wire busbar 34. Busbar 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 the devices connected to the busbar 34, to enable the communications between the devices in a manner described later herein. Of course, the network of Figure 1 is illustrative only, there being many other ways in which a process control network can be configured using the Fieldbus protocol. Normally, a configurator is located in one of the devices, such as the central 12, and is responsible for establishing or configuring each of the devices (which are "intelligent" devices, because each includes a microprocessor that can perform communication, and in some cases, control functions), as well as recognizing when connecting new field devices to the busbar 34, when field devices are removed from the busbar 34, recognizing the data generated by the field devices 16-32 , and interconnecting with one or more user terminals, which may be located in the exchange 12 or in any other device connected to the exchange 12 in any way. The collection bar 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 they may be connected to external power supplies by separate wires (not shown). Although devices 12-32 are illustrated in Figure 1 connected to the busbar 34 in a standard busbar type connection, where multiple devices are connected to the same pair of wires forming the busbar segments 34a, 34b and 34c, the Fieldbus protocol allows other device / wire topologies, including point-to-point connections, where each device is connected to a controller or to a central unit by means of a pair of separate wires (similar to typical analog DCS systems). -20 mA), and tree connections or "meshing", where each device is connected to a common point in a two-wire bus bar, which can be, for example, a junction box or a termination area in one of the field devices inside a process control network. The data can be sent over the different bus segments 34a, 34b, and 34c, at the same or different communication baud rates, according to the Fieldbus protocol. For example, the Fieldbus protocol provides a communication speed of 31.25 Kbits / second (Hl), illustrated used by the busbar segments 34b and 34c of Figure 1, and a communication speed of 1.0 Mbits / second and / or 2.5 Mbits / second (H2), which will normally be used for advanced process control, remote input / output, and automation applications in the high-speed factory, and illustrated used by busbar segment 34a of FIG. 1. In the same manner, data may be sent on busbar 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 instead is determined by the communication speed, the type of cable, the size of the wire, the power option of the bus, etc., of that section. The Fieldbus protocol classifies the devices that can be connected to bus 34 in three primary categories, namely, basic devices, master link devices, and bridge devices. Basic devices (such as devices 18, 20, 24, and 28 of Figure 1) can communicate, i.e., send and receive communication signals on or from bus 34, but are not able to control the order or the time of the communication that is presented on the busbar 34. The master link devices (such as devices 16, 22, and 26, as well as exchange 12 of Figure 1), are devices that communicate over the busbar 34, and are capable of controlling the flow and time of the communication signals on the busbar 34. The bridge devices (such as devices 30 and 32 of Figure 1), they are devices configured to communicate on, and to interconnect individual segments or branches of a Fieldbus bus, in order to create larger process control networks. If desired, the bridge devices can convert between different data rates and / or different data signaling formats used in the different segments of the busbar 34, they can amplify the signals traveling 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 on one of the segments of the busbar, with which the bridge is coupled, and / or can take other necessary measures to link different segments of the busbar 34. The bridge devices that connect the bus segments that operate at different speeds must have link master capabilities on the side of the lowest speed segment of the bridge. The exchanges 12 and 15, the logic controller of the program 13, and the controllers 14, can be any type of Fieldbus device, but will normally be master link devices. Each of the devices 12-32 can communicate over the busbar 34, and in an important way, independently can perform one or more control functions of the process, using the data acquired by the device, from the process, or from a different device by means of communication signals on the busbar 34. Consequently, Fieldbus devices are capable of directly implementing portions of a control strategy that, in the past, were performed by 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 inside the device. In particular, each Fieldbus device includes a resource block, zero or more function blocks, and zero or more transducer blocks. These blocks are referred to as block objects. A resource block stores and communicates device-specific data pertaining to some of the characteristics of a Fieldbus device, including, for example, a device type, a device revision indication, and indications of whether other specific information can be obtained from the device. device inside a device memory. Although different device manufacturers can store different types of data in the resource block of a field device, each field device that complies with the Fieldbus protocol includes a resource block that stores some data.

A function block defines and implements an input function, an output function, or a control function associated with the field device, and consequently, function blocks are generally referred to as input, output function blocks, and control. However, there may be other categories of function blocks, such as hybrid function blocks, or they may be developed in the future. Each input or output function block produces at least one process control input (such as a process variable from a process measurement device), or a process control output (such as a valve position sent to a drive device), while each control function block uses an algorithm (which may be of a proprietary nature) to produce one or more process outputs from one or more process inputs and control inputs. Examples of standard function blocks include analog input (AI) function blocks, analog output (AO), bias (B), control selector (CS), discrete input (DI), discrete output (DO), charger manual (ML), proportional / derivative (PD), proportional / integral / derivative (PID), ratio (RA), and signal selector (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 block couples the inputs and outputs of a function block with local hardware devices, such as sensors and device drivers, to enable the function blocks to read the outputs of the local sensors, and to instruct the local devices to perform one or more functions, such as move a valve member. The transducer blocks usually contain information that is necessary to interpret the signals supplied by a local device, and to appropriately control the local hardware devices, including, for example, identifying information of the type of a local device, calibration information associated with a local device, etc. A single transducer block is usually associated with each input or output function block. Most function blocks can generate alarm or event indications, based on previously determined criteria, and are able to operate in different ways in different ways. Generally speaking, the function blocks can operate in an automatic mode, in which, for example, the algorithm of a function block operates in an automatic way; an operator mode where the input or output of a function block is manually controlled; an out-of-service mode, where the block does not operate; a cascade mode, where the operation of the block is affected (determined) by the output of a different block; Y one or more remote modes, where a remote computer determines the mode of the block. However, there are other modes of operation in the Fieldbus protocol. It is important that each block can communicate with other blocks in the same or different field devices on 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. Accordingly, for example, a PID function block of a field device can be connected via the busbar 34, to receive an output of an AI function block in a second field device, to supply data to a AO function block in a third field device, and to receive an output of the AO function block as a feedback, to create a separate process control cycle apart from any distributed control system controller. In this way, combinations of function blocks take control functions out of a centralized environment of the distributed control system, which allows the multi-function controllers of the distributed control system to perform supervisory or coordination functions, or eliminate completely. In addition, the function blocks provide a graphical structure oriented to the blocks for easy configuration of a process, and make possible the distribution of functions between the field devices of different suppliers, because these blocks use a consistent communication protocol. In addition to containing and implementing block objects, each field device includes one or more different objects, including link objects, trend objects, alert objects, and viewing objects. The link objects define the links between the inputs and outputs of the blocks (such as the function blocks), both internal to the field device, and through the Fieldbus 34 bus. Trend objects allow trends to be drawn parameters of the function block for access by other devices, such as central 12 or controllers 14 of Figure 1. Trend objects retain short-term historical data belonging, 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 bus 34. These alarms or events can be related to any event that occurs inside a device or one of the blocks of a device. The View objects are previously defined groupings of block parameters used in the standard human / machine interconnection, and can be sent to other devices to be viewed from time to time. Referring now to Figure 2, three Fieldbus devices are illustrated, which may be, for example, any of the field devices 16-18 of Figure 1, including resource blocks 48, function blocks 50, 51 , or 52, and the transducer blocks 53 and 54. In the first device, the function block 50 (which may be an input function block) is coupled through the transducer block 53 with a sensor 55, which may be , for example, a temperature sensor, an established point indication sensor, and so on. In the second device, the function block 51 (which may be an output function block) is coupled through the transducer block 54 with an output device such as a valve 56. In the third device, the function block 52 (which may be a control function block) has a trend object 57 associated with it, to determine the trend of the input parameter of the function block 52. The link objects 58 define the block parameters of each of the associated blocks, and the alert objects 59 provide alarms or event notifications for each of the associated blocks. The objects of vision 60 they 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 the necessary information for each of a set of different defined views. Of course, the devices of Figure 2 are purely exemplary, and other numbers and types of block objects, link objects, alert objects, trend objects, and objects of vision can be provided in any field device. Referring now to Figure 3, a block diagram of process control network 10, illustrating devices 16, 18, and 24, such as valve / positioning devices, and devices 20, 22, 26, and 28 as transmitters, it also 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 recloser block (RSC) 61, a transducer block (XDCR) 62, and a number of function blocks, including an analog output function block (AO) 63, two PID function blocks 64 and 65, and a signal selection function block (SS) 69 The transmitter 20 includes a resource block 61, two transducer blocks 62, and two analog input function blocks (AI) 66 and 67. Also, the bridge 30 includes a resource block 61, and a PID function block 68. As will be understood, the different function blocks of Figure 3 can operate together (communicating on the busbar 34) in a number of control cycles, and the control cycles in which the function blocks of the setter / valve 16, the transmitter 20, and the bridge are located. , are identified in Figure 3 by a cycle identification block connected to each of these function blocks. Accordingly, as illustrated in FIG. 3, the function block AO 63 and the PID function block 64 of the setter / valve 16, and the function block AI 66 of the transmitter 20, are connected within an indicated control cycle. as LOOP1, while the function block SS 69 of the setter / valve 16, the function block AI 67 of the transmitter 20, and the PID function block 68 of the bridge 30, are connected in a control cycle indicated as LOOP2. The other PID function block 65 of the setter / valve 16 is connected within a control cycle indicated as L00P3. The interconnected function blocks that form the control cycle indicated as LOOP1 in Figure 3 are illustrated in more detail in the scheme of this control cycle illustrated in Figure 4. As can be seen in Figure 4, the cycle of control L00P1 is completely formed by communication links between the function block AO 63 and the PID function block 64 of the setter / valve 16, and the function block AI 66 of the transmitter 20 (FIG. 3). The control cycle diagram in Figure 4 illustrates the *? 8 communication interconnections between these function blocks, using lines that connect the process and control inputs and outputs of these function blocks. Accordingly, the output of the function block AI 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 PID function block 64, which has an output comprising a control signal that is communicatively coupled with an input of the function block AO 63. An output of the function block AO 63, comprising a feedback signal indicating, for example , the position of the valve 16 is connected to a control input of the PID function block 6. The PID function block 64 uses this feedback signal together with a process measurement signal from the AI 66 function block, to implement an appropriate control of the AO 63 function block. Of course, the connections indicated by the lines in the control cycle diagram of Figure 4, can be performed internally, inside a field device, when, as with the case of function blocks AO and PID 63 and 64, the function blocks are inside the same field device (for example, the setter / valve 16), or these connections can be implemented over the two wire communication bus 34 using standard fieldbus synchronous communications. Of course, they are implemented other control cycles through other function blocks that are interconnected in a communicative manner in other configurations. To implement and carry out communication and control activities, the Fieldbus protocol uses three general categories of technology identified as a physical layer, a communication "stack", and a user layer. The user layer includes the control and configuration functions provided in the form of blocks (such as function blocks) and objects within any particular process control device or field device. The user's layer is usually designed in a proprietary way for the device manufacturer, but must be capable of receiving and sending messages according to the standard message format defined by the Fieldbus protocol, and of being configured by a user in conventional ways . The physical layer and the communication stack are necessary to effect communication between different blocks of different field devices in a standardized way, using the two-wire busbar 34, and can be modeled by the well-known layering communication model Open Systems Interconnect (OSI). The physical layer, which corresponds to the OSI layer 1, is embedded in each field device and the busbar 34, and operates to convert the electromagnetic signals received. from the Fieldbus transmission medium (the two-wire busbar 34) in messages that can be used by the communication stack of the field device. The physical layer can be thought of as the busbar 34 and the electromagnetic signals present on 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, corresponding to the OSI 2 layer, a Fieldbus access sublayer, and a Fieldbus message specification layer, which corresponds to the OSI layer 6. There is no corresponding structure for OSI 3-5 layers in the Fieldbus protocol. However, the applications of a Fieldbus device comprise a layer 7, while a user layer is a layer 8, not defined in the OSI protocol. Each layer in the communication stack is responsible for encoding or decoding a portion of the message or signal that is transmitted over the Fieldbus 34 bus. As a result, each layer of the communication stack adds or removes certain portions of the Fieldbus signal , such as preambles, start delimiters, and end delimiters, and in some cases, decode the separate portions of the Fieldbus signal, to identify where the rest of the signal or message should be sent, or to discard the signal because, for example, it contains a message or data for function blocks that are not inside of the receiving field device. The data link layer controls the transmission of messages on the busbar 34, and manages the access to the busbar 34 in accordance with a deterministic centralized bus controller called an active link scheduler, which will be described in more detail more ahead. The data link layer removes a preamble from the signals on the transmission medium, and may use the received preamble to synchronize the internal block of the field device with the input Fieldbus signal. In the same way, the data link layer converts the messages on the communication stack into physical Fieldbus signals, and encodes these signals with the clock information to produce a "synchronous in series" signal having an appropriate preamble to be transmitted over the two-wire busbar 34. During the decoding 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. In the same way, the data link layer transmits the Fieldbus signals on the busbar 34 by adding start and stop delimiters. end to the messages on the communication stack, and placing these signals on the transmission medium at the appropriate time. The Fieldbus message specification layer allows the user layer (i.e., function blocks, objects, etc., of a field device) to communicate through 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 to be placed on the communication stack, and to be provided to the user's layer. Because the Fieldbus message specification layer provides standardized communications for the user layer, specific Fieldbus message specification communication services are defined for each type of object described above. For example, the Fieldbus message specification layer includes object dictionary services that allow a user to read a dictionary object of a device. The object dictionary stores object descriptions 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, which allow a user to read and change the communication relationships, known as virtual communication relations (VCRs) described hereinafter, associated with one or more objects of communication. a device Still In addition, the Fieldbus message specification layer provides variable access services, event services, upload and download services, and program invocation services, all of which are well known in the Fieldbus protocol, and therefore, 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 VCRs, dynamic variables, statistics, time programs of the active link programmer, programs of function block execution time, and label information and device address. Of course, the information inside the MIB can be accessed or changed at any time using standard Fieldbus messages or commands. In addition, a description of the device with each device is usually provided to give a user or a central office an extended view of the information in the VFD. A description of the device, which normally must be handled with tabs to be used by a central office, stores the information necessary for the exchange to understand the meaning of the data in the VFDs of a device. As will be understood, to implement any Control strategy using the function blocks distributed throughout a process control network, the execution of the function blocks must be precisely programmed with respect to the execution of other function blocks in a particular control cycle. In the same way, the communication between different function blocks on the busbar 34 must be precisely programmed, in such a way that the appropriate data is provided to each function block before that block is executed. Now we will describe the way in which different field devices (and different blocks within the field devices) are communicated on the Fieldbus transmission medium, with respect to Figure 1. For communication to occur, one of the master devices of link on each segment of the busbar 34 (for example, devices 12, 16, and 26) operates an active link scheduler (LAS), which actively programs and controls communication on the associated bus segment 34 The LAS for each segment of the busbar 34 stores and updates a communication program (an active link program) that contains the times in which each function block of each device is programmed to initiate the activity of periodic communication on the bar collector 34, and the time during which this communication activity will be presented. Although there may be, and there is only, one active LAS device in each bus segment 34, other link master devices (such as device 22 over segment 34b) can serve as back-up LASs, and can become active when, for example, the current LAS fails. . The basic devices do not have the capacity to become a LAS at any time. Generally speaking, the communication activities on the busbar 34 are divided into repeating macrocycles, each of which includes a synchronous communication for active function block in any particular segment of the busbar 34, and one or more communications asynchronous for one or more of the function blocks or active devices on a bus segment 34. A device may be active, that is, it may send data to, and receive data from, any bus segment 34, inclusive when physically connected to a different segment of the busbar 34, through a coordinated operation of the bridges and the LASs on the busbar 34. During each macrocycle, each of the active function blocks on a particular segment of the bus bus 34 is executed, usually at a different time, but precisely programmed (synchronous), and in another time precisely programmed mpo publishes its output data on that segment of the busbar 34 in response to a command of Compulsory data generated by the appropriate LAS. Preferably, each function block is programmed to publish its output data shortly after the end of the execution period of the function block. In addition, the data publication times of the different function blocks are programmed in series, such that there are no two function blocks on a particular segment of the bus 34 that publish data at the same time. During the time when the synchronous communication is not being presented, each field device, in turn, is allowed to transmit alarm data, vision data, etc., in an asynchronous manner, using the card-driven communications. The execution times and the amount of time necessary to perform the execution of each function block are stored in the management information base (MIB) of the device in which the function block resides, while, as mentioned above , the times to send the required data commands to each of the devices on a bus segment 34 are stored in the LAS device's MIB for that segment. These times are normally stored as outdated times, because they identify the times when a function block is to be executed, or it will send data as a phase shift from the beginning of an "absolute link program start time", which is known by all the devices connected to the busbar 34.

In order to carry out the communications during each macrocycle, the LAS, for example, the LAS 16 of the bus segment 34b, sends a forced data command to each of the devices on the bus segment 34b according to the list of times transmission stored in the active link program. Upon receipt of a mandatory data command, a function block of a device publishes its output data on the bus 34 for a specific amount of time. Because each of the function blocks is normally programmed to run in such a way that execution of that block is performed shortly before the block is scheduled to receive a command of bound data, the data published in response to a command The required data must be the most recent output data of the function block. However, if a function block is running slowly, and has not locked new outputs when it receives the required data command, the function block publishes the output data generated during the last execution of the function block, and indicates that the Published data is old data, using a time stamp. After the LAS has sent a forced data command to each of the function blocks on a particular segment of the busbar 34, and during the times in which the function blocks are being executed, the LAS can cause asynchronous communication activities to occur. To perform asynchronous communication, the LAS sends a passcard message to a particular field device. When a field device receives a passcard message, that field device has absolute access to the busbar 34 (or a segment thereof), and can send asynchronous messages, such as alarm messages, trend data, changes of established point of the operator, etc., until the messages are completed, or until a maximum assigned "record holding time" has expired. Subsequently, the field device releases the busbar 34 (or any particular segment thereof), and the LAS sends a passcard message to another device. This process is repeated until the end of the macrocycle, or until the LAS is programmed to send a forced data command, in order to perform the synchronous communication. Of course, depending on the amount of message traffic and the number of devices and blocks coupled with any particular segment of bus 34, not all devices can receive a passcard message during each macrocycle. Figure 5 illustrates a time scheme illustrating the times in which the function blocks are executed on the bus segment 34b of Figure 1 during each macrocycle of busbar segment 34b, and times in which synchronous communications occur during each macrocycle associated with the busbar segment 34b. In the time program of Figure 5, the time is indicated on the horizontal axis, and the activities associated with 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. Accordingly, AI?, 00Pl refers to the function block AI 66 of the transmitter 20, PIDL00P1 refers to the PID function block 64 of the setter / valve 16, and so on. The block execution period of each of the illustrated function blocks is illustrated by a shaded box, while each programmed synchronous communication is identified by a vertical bar in Figure 5. Therefore, according to the time schedule of Figure 5, during any particular macrocycle of segment 34b (Figure 1), function block AI L00P1 is executed first during the period of time specified by table 70. Then, during the period of time indicated by vertical bar 72 , the output of the function block AILQQp -? _ is published on the bus segment 34b, in response to a forced data command from the LAS for bus segment 34b. In the same way, tables 74, 76, 78, 80, and 81 indicate the execution times of the function blocks PIDL00p ?, AIL00p2, A0L00P1, SSL00p2, 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 in that the function blocks PIDL00P1 'AIL00P2' A0L00P1 'SSL00P2' and PIDL00P3 'respectively, publish the data on bus segment 34b. As you can see, the time diagram 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 there are no function blocks running, and when synchronous communication on the bus segment 34b is not taking place. Of course, if desired, different function blocks can be intentionally programmed to run at the same time, and not all function blocks must publish the data on the bus if, for example, no other device subscribes to the data produced. for a function block. Field devices can publish or transmit data and messages about bus 34, using one of three virtual communication relationships (VCRs) defined in the Fieldbus access sublayer of the stack of each field device. A VCR of client / server for in-line, unscheduled communications, initiated by the user, one by one, between the devices on the busbar 34. These messages in a row are sent and received in the order presented for transmission, according to their priority, without overwriting previous messages. Accordingly, a field device can use a client / server VCR when it receives a passcard message from a LAS, to send a request message to another device on the bus 34. The requester is called the "client". ", and the device that receives the request is called the" server ". The server sends a response when it receives a passcard message from the LAS. The client / server VCR is used, for example, to make requests initiated by the operator, such as changes of established point, access and changes to the tuning parameter, acknowledgments of alarm, and charges and downloads of the device. A report distribution VCR is used for in-line, unscheduled communications, initiated by the user, from one to many. For example, when a field device with an event or trend report receives a pass token from an LAS, 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 on that VCR, they will receive the report. The report distribution VCR type is normally used by Fieldbus devices to send alarm notifications to operator consoles. A type of publisher / subscriber VCR is used for one to many communications placed in buffer zone. The communications placed in buffer zone are those that store and send only the latest version of the data, and therefore, the new data completely overwrite the previous data. The outputs of the function block, for example, comprise data placed in the buffer area. A "publisher" field device publishes or transmits a message using the publisher / subscriber VCR type, to all "subscriber" field devices on bus 34, when the publisher device receives a mandatory data message from the LAS or from a subscriber device. The publisher / subscriber relationships are previously determined, and are defined and stored within the Fieldbus access sublayer of the communication stack of each field device. To ensure proper communication activities on the busbar 34, each LAS periodically sends a time distribution message to all field devices connected to a busbar segment 34, which enables the receiving devices to adjust their time of local application to stay in synchronization with each other. Among these synchronization messages, a clock time is independently maintained in each device based on its own internal clock. Clock synchronization allows field devices to time the data through the entire Fieldbus network to indicate, for example, when the data was generated. In addition, each LAS (and another master link device) on each busbar segment stores a "live list", which is a view of all the devices that are connected to that busbar segment 34, that is, all the devices that are responding appropriately to a passcard message. The LAS continuously recognizes new devices added to a busbar segment, periodically sending probe node messages to addresses that are not on the live list. In fact, each LAS is required to poll at least one address after it has completed a cycle of sending passcard messages to all field devices in the live list. If a field device is present in the probed address, and receives the message from the probe node, 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 by sending a node activation message to the polled field device. A field device remains on the live list provided that the field device responds appropriately to the passcard messages. However, a LAS removes a field device from the live list if the field device, after three successive tests, does not use the card, or immediately returns the card to the LAS. When a field device is added or removed from the live list, the LAS transmits changes to the live list for all other master link devices over the appropriate segment of bus 34, to allow each master link device to maintain a current copy of the live list. As mentioned above, the communication interconnections between the field devices and the function blocks thereof are determined by a user, and are implemented inside the process control network 10, using a localized configuration application, for example , in the central 12. However, after being configured, the process control network 10 operates without considering the diagnosis of the device or the process, and therefore, interconnects with the control unit 12 to perform conventional input / output functions. Referring now to Figure 6, a schematic block diagram illustrates a control system network 200 where redundancy is implemented selectively according to the present invention, using a single set of communication means in a single communication cycle 202 with redundant functional elements, including a primary field device 204 and a redundant field device 206. A cycle controller 208, such as a digital control system (DCS) controller or a field device, is connected to the single cycle of communication 202, and the single communication cycle 202 is connected to the redundant pair of field devices 204 and 206. Field devices 204 and 206 optionally detect and communicate a fault state. The cycle controller 208 continuously monitors the operation of the devices in the network of the control system 200, using two-way digital communications, and detects a cessation of communications from a failed field device. The network of the control system 200 is recovered from a failure of the primary field device 204, but not from the failure of the single communication means set 202. The cycle controller 208 controls the operation redundancy of the single communication cycle 202 in combination with the redundant field devices 204 and 206, and detecting the failure of a functional element, either by receiving a failure state from one or more of the functional elements, such as the control logic within the devices, or by detecting a discontinuance of messages from one or more of the functional elements. For example, a field device, such as a process control valve, includes a sensor and a feedback signal that indicates the status of the sensor, which in turn indicates the operating status of the process control valve. The status of the operation of the valve may include a designation of a failure state, an operating state, or a state indicating different degrees of functionality. The process control valve, and other selected functional elements, preferably use the two-way communications communication cycle 202, to transmit a status message to the cycle controller 208. The cycle controller 208 automatically reconfigures the communication cycle of the redundant pair by deactivating a failed or failing device, such as the primary field device 204, and the activation of the corresponding alternative device, illustrated as the redundant field device 206. The functional elements may include detection elements, such as transmitters, and control elements such as valves or motors, as well as other field devices and control devices within a process. To detect the elements, the transmissions from a failed transmitter are ignored. For a failed control element, the cycle controller issues a command to deactivate the failed control element to a fail-safe operating mode. Referring now to Figure 7, a schematic block diagram illustrates a control system network 300 wherein the redundancy is selectively implemented using a redundant set of communication means, including a primary communication bus 302, and a redundant communication bus 303, with redundant devices, including a primary field device 304, and a device redundant field 306 connected to it. A cycle controller 308, such as a digital control system controller (DCS) or a field device, is connected to the primary communication bus 302, and to the redundant communication bus 303, to form a redundant pair of communication cycles. The primary field device 304, and the redundant field device 306, optionally detect and communicate a failure state. The cycle controller 308 controls the redundancy operation of the redundant communication cycles, continuously monitoring the operation of the devices in the network of the control system 300, using two-way digital communications, and detects the failure of a functional element (which it can be a busbar or a device), either by receiving a fault status from the functional element, or by detecting a discontinuance of the messages from the functional element. The cycle controller 308 automatically reconfigures the redundant pair of communication cycles by deactivating a cycle, such as that associated with the bus bar. primary communication 302, or one or more of the elements within the primary cycle when the bus 302 or the primary field device 304 fails, and then activating the corresponding alternative cycle (e.g., that associated with the redundant communication bus 303 ), and / or one or more functional devices on the bus 303, such as the redundant field device 306. In accordance with the above, recovery is obtained for both a failing functional element and a failing communication medium. . Referring to Figure 8, a schematic block diagram illustrates a control system network 400 where redundancy is selectively implemented using a redundant set of communication media, including a primary communication bus 402, and a bus bar. redundant communication 403, with a single additional functional element, such as a field device 404 connected thereto. The field device 404 includes two sets of interface electronics (not shown) for exploiting the redundant medium. A cycle controller 408 is connected to a primary communication bus 402 and to the redundant communication bus 403, to form a redundant pair of communication cycles. The device 404 has a first input connection and a first output connection to the communication bus 402, and has a second input connection and a second output connection to the redundant communication bus 403. Accordingly, the device 404 is connected inside the redundant pair of communication cycles. The unique field device 404 optionally detects and communicates a fault state. The cycle controller 408 controls the redundancy operation of the redundant communication cycles, continuously monitoring the operation of the devices in the network of the control system 400, using two-way digital communications, and detects the failure of a functional element, since either by receiving a fault state from the functional element, or by detecting a message discontinuance from the functional element. The cycle controller 408 automatically reconfigures the redundant pair of communication cycles by deactivating a busbar, such as the primary communication bus 402, when the primary communication bus 402 fails, and by activating the busbar alternative redundant communication communication 403. However, in this configuration, the cycle controller 408 can not recover from a failure of the field device 404. According to the above, the network of the control system 400, which has a redundant medium but a single device or other functional element, achieves recovery for a means of communication that fails, but does not recover functionality in the case of the device that fails or another functional element. Referring to Figure 9, a schematic block diagram illustrates a control system network 500 having two functional elements, a primary process control valve 502, and a redundant process control valve 504 connected in a flow stream of the process 512. In the network of the control system 500, the primary process control valve 502 and the redundant process control valve 504 are connected to a single two-wire communication cycle 506, which is controlled by a controller of cycle 508. Cycle 506 includes a transmitter 510 located distal to control valves 504 and 506 from cycle controller 508. Normally, the primary process control valve 502 is active, and the control valve of the redundant process 504 is in a waiting or derivative state. The cycle 506 uses two-way digital communication, such that the control valves 504 and 506, and the transmitter 510, receive all messages and transmit messages to the cycle controller 508. Accordingly, the cycle controller 508 receives information indicating the precise status of the functional elements within the network of the control system 500. The controller of the cycle 508, upon receiving information that indicates a failure or other inappropriate state of a functional element, initiates a response to disable the functional element that fails, and activate a redundant element, if available. The cycle controller 508 normally deactivates selected functional elements by placing the functional elements in a fail-safe mode of operation. In some embodiments, the 504 and 506 control valves are set to operate at half capacity in the bypass mode, and the response to a single valve failure is the deactivation of the failing valve and activation at full capacity of the valve. functional valve. In addition, the valves 504 and 506 can be connected in series, such that one remains open while the other controls the flow. Referring to Figure 10, a schematic block diagram illustrates a network 'of control system 600 that includes two functional elements, a primary transmitter 602, and a redundant transmitter 604 connected in a stream of process 612. In the network of the control system 600, the primary transmitter 602 and the redundant transmitter 604 are connected with a single cycle of two wires 606, which is controlled by a cycle controller 608. The primary transmitter 602 is active, and the redundant transmitter 604 is in a waiting or derived state. Cycle 606 uses two-way digital communication, such that transmitters 604 and 606 receive both messages and transmit messages to the cycle controller 608. In accordance with the above, the cycle controller 608 receives information indicating the precise status of the functional elements within the network of the control system 600. The cycle controller 608, upon receiving the information that indicates a fault or other inappropriate state of a transmitter, simply ignores the transmissions from a non-functional transmitter. Referring now to Figure 11, a block diagram of a process control cycle 700 is illustrated, which has distributed control functions implemented using redundant function blocks, such as those of a Fieldbus communication network. The cycle 700, which can implement a simple feedback valve control cycle, such as that associated with FIG. 4, is illustrated by including a single function block AI 702 connected with a pair of redundant PID function blocks 704 and 706, which in turn are connected through an error detection function block 708, with a pair of redundant AO function blocks 710 and 712. During operation, the AI 702 function block, one of the PID function blocks 704 or 706, and one of the function blocks AO 710 and 712, operate in conjunction with the error detection function block 708, to implement the simple feedback control cycle. As will be evident from Figure 11, the block of AI function 702 directs its output to the PID function blocks 704 and 706, one of which operates to produce a control signal that is supplied through the function block of the error detector 708, to one of the function blocks AO 710 or 712. The same PID function block 704 or 706 also receives a feedback signal from one of the function blocks AO 710 or 712 through the function block of the error detector 708, by means of one of the lines of Accordingly, for example, during normal operation, the cycle 700 can operate with the PID function block 704 and the AO 710 function block connected through the error detection function block 708. The block error detection function 708 analyzes the mode of blocks 704 and 710 (as well as blocks 706 and 712), or analyzes the signals received from blocks 704 and 710, to detect whether any of these function blocks ion is working badly. If the error detection function block 708 detects an error state in any of the blocks 704 or 710, the error detection block 708 immediately causes a redundant function block to operate, either the redundant PID function block 706 (if the PID function block 704 is malfunctioning), or the redundant function block AO 712 (if function block AO 710 is malfunctioning) within cycle 700, to thereby switch the functioning function block bad out of cycle 700, which in turn allows the cycle 700 to continue without having to deactivate the cycle 700, or to deactivate the process in which the cycle 700 is connected. Of course, the error detection function block 708 can switch the operation of the cycle 700 in any desired manner, including switching both redundant function blocks 706 and 712 to operate together when either of the function blocks 704 or 710 malfunction, to switch the cycle 700 in such a way that the PID function block 704 and the block function AO 712 operate together when, for example, function block AO 710 malfunctions, or switch cycle 700 in such a way that redundant PID function block 706 and function block AO 710 operate together when, for example, fail the PID function block 704. In the same way, the error detection function block 708 can be coupled between any set of redundant function blocks and a single function block, or between It has two sets of redundant function blocks inside a process control cycle, in order to provide redundancy in it. Further redundancy can be achieved by providing at least one redundant function block for each of the function blocks within a cycle, such as by adding a redundant AI function block in cycle 700 of Figure 11. However, it can be achieved less redundancy when providing a redundant function block for only one or for only a limited number of function blocks in one cycle. It will also be understood that the error detection function block 708 can be connected in any desired manner, and can be located on any device within a process control system, provided that the error detection function block 708 is connected communicatively with the other function blocks within a redundant cycle by means of a busbar, such as a Fieldbus communication bus. Also, redundant function blocks, for example blocks 704 and 706, or blocks 710 and 712, can be located on them or on different devices. Still further, if desired, the outputs of the PID function blocks 704 and 706 can be directly coupled with the function blocks AO 710 and 712 (as well as with the error detection function block 708) of Figure 11, while the feedback from the function blocks AO 710 and 712 can be coupled directly with the PID function blocks 704 and 706 (as well as with the error detection function block 708). In this configuration, the error detection function block 708 detects the errors inside the function blocks 704 and 706, or 710 and 712, and causes a function block that is malfunctioning to be switched out of the cycle, while simultaneously causing the associated redundant function block is switched into the cycle, without actually passing signals between them, for example, the PID and AO function blocks inside the cycle 700. Referring now to Figure 12, a schematic block diagram illustrates a control system network 100 that implements the redundancy of the field using, for example, any or all of the redundant connections illustrated in Figures 6 through 11, as well as any other redundant connection. The network of the illustrated control system 100 includes a computer 102, such as a personal computer or a workstation, which is connected to a network bus 104 by a controller 106, such as a digital control system, and a pair of redundant communication lines 107. Network bus 104 includes a primary cycle 112 and a redundant cycle 113, each of which implements two-way, two-wire digital communications, energized by the cycle, according to, for example, , with the Fieldbus protocol or any other communication protocol associated with a process control system that has distributed control functions. The network of the control system 100 communicates with an external network 114 by means of a connection of the busbar of the network 104 in a node 115. The network of the control system 100 includes a plurality of field devices 116 which are connected to the network bus 104 directly, or which are connected to the busbar of the network 104 by means of bridges 118 and local busbars 120. In the network of the illustrated control system 100, a local bus 120 (labeled 122) is connected to the node 115 by a redundant busbar of external network 124, having a primary cycle 126 and a redundant cycle 128. Redundancy can be implemented selectively at the field device level using a primary field device (labeled 130), and a redundant field device (labeled 132), which are connected to a first bridge (labeled 134) through a redundant connection 136, to a local bus 138, and which are connected to a second bridge (labeled 140) by a redundant connection 142, to the local bus 122. A fully redundant functional element has the same established function or function block capacity as a corresponding primary functional element. A functional element with limited redundancy has an established function that omits at least one function or characteristic of a corresponding primary functional element. The illustrated control system network 100 implements redundancy at many levels in a two-way, two-wire digital communication environment, energized by the cycle, in a four-wire communication environment, or in any other environmental environment. process control that uses distributed control functions. First, the computer 112 is connected to the controller 106 using redundant lines 107. Second, the busbar of the network 104 includes a primary cycle or bus 112, and a redundant cycle or bus 113. Third, the bridges 118 and the devices Fields directly connected 116 are connected to the busbar of the network 104, with redundant connections. Fourth, the primary field device 130 and the redundant field device 132 are connected to the first bridge 134 via the redundant connection 136, to the local bus 138. Fifth, the primary field device 130 and the redundant field device 132 they are connected to the first bridge 134 by a redundant connection 136, to a local bus 138, and are connected to a second bridge 140 via a redundant connection 142, to the local bus 122. Sixth, the local bus 122 is connected in a redundant manner to the external network 114 in the node 115 by the network bus 104 and the redundant external network bus 124. Seventh, the redundant external network bus 124 is a redundant bus bar. Eighth, the redundant function blocks are placed inside the devices (for example, the devices 116) connected to the network 100. In other embodiments of a control system network, the redundancy is selectively implemented for the bus of the network 104 alone, or is implemented to selected field devices 116, for all field devices 116, or for no field device 116. In a similar manner, the redundancy of the connections of the local bus 120 to node 115 and of the function blocks is optional . The network of the control system 100 that implements the redundancy of the field device, operates for cycles that implement two-way, two-wire digital communications, energized by the cycle, as well as four-wire cycles or other cycles that implement control functions of the process in a distributed manner, including cycles that implement a Fieldbus standard (Fieldbus Foundation, Austin, Texas), a WORLDFIP standard, a LONWORKS standard, a PROFIBUS standard, any other SP-50 communication standard, and the like. The network of the control system 100 that implements the redundancy of the field device also operates for cycles that implement mixed analog / digital protocols, including, for example, the HART standard. Referring now to Fig. 13, a schematic block diagram illustrates one of the digital field devices 116 (of Fig. 12), which is a two-way, two-wire, digitally communicating valve-setter / valve combination for the cycle. The digital field device 116 includes a field device controller 1102, an I / P transducer 1104, a pneumatic relay 1106, a actuator 1108, and a valve 1109, which are interconnected by different pneumatic and electric lines. The field device 116 receives operational signals, and transmits the status and data information in a digital form by means of the two-wire busbar 122, preferably in accordance with the Fieldbus standard, and therefore, is a field setter. two wires In a similar manner, the field device 116 receives power, primarily to drive the controller of the device 1102, and the I / P transducer 1104, by means of the two-wire continuous cycle bus bar segment 120, and therefore, is a device energized by the cycle. As illustrated in Figure 13, the I / P transducer 1104 is electrically connected to the device controller 1102 by means of an I / P transducer control line 1110, and in the illustrated embodiment, communicates with the device controller 1102 using analog control signals. The I / P transducer 1104 generates a pneumatic signal that causes the actuation of the valve 1109, and is highly useful in electromechanical devices for converting the electrical signals into air pressure for a pneumatic fitter. The actuator 1108 controls the position of a valve member 1114 (which may be a valve stem) of the valve 1109, while a position sensor 1116 senses the position of the valve member 1114, and generates a feedback signal that is communicated to the device controller 1102 by means of of a signal line 1117. This position signal can be used by the device controller 1102 to control the operation of the field device 116, such that the I / P 1104 transducer drives the pneumatic pressure in a manner that makes the valve member 1114 is in a desired position. The position and other feedback information can be stored in a storage unit or in a memory of the controller of the device 1102, and accessed externally by means of the bus 120, to detect, for example, an error state of the device 116. As is conventional, the field device 116 receives a supply of pressurized air from an external source (not shown), by means of a pneumatic line 1118 connected to the I / P transducer 1104, and to the pneumatic relay 1106. An input sensor 1120, normally positioned between the external air source and the I / P transducer 1104, measures the pneumatic input supply pressure in pneumatic line 1118, and supplies this measurement to the device controller 1102. The I / P transducer 1104 is connected to the pneumatic relay 1106 by means of a pneumatic control line 1122, and a I / P sensor 1124 between the I / P transducer 1104, and the pneumatic relay 1106, for measuring the pneumatic supply pressure on the line 1122. In the same way, the pneumatic relay 1106 is connected to the actuator 1108 by means of a pneumatic supply line 1126, and a relay sensor 1128 is placed between the pneumatic relay 1106 and the actuator 1108, to measure the pneumatic supply pressure on the line 1126. The pneumatic lines 1118, 1122, and 1126 are considered parts of a single pneumatic line interconnecting the transducer 1104 and the valve 1109. During operation, the device controller 1102 controls the actuation of the valve 1109 by controlling the I / P transducer 1104, to establish a controlled operating pressure of the valve in the pneumatic control line 1126. The controller of the device 1102 sends a control signal to the I / P transducer 1104, by means of the transducer control line I / P 1110, for controlling an output pressure of the combination of the I / P transducer 1104 and the relay 1106, to be between approximately 3 and 100 psi (0.21-7.06 kscm), which is applied to a control input of the actuator 1108. The actuator 1108 it generates an output pressure that is applied to operate the valve 1109. Accordingly, as is known, the I / P transducer 1104 converts the electrical signals into a pneumatic air pressure signal. An example of a suitable I / P transducer 1104 is disclosed in U.S. Patent No. 5,439,021, entitled "Electro-Pneumatic Converter", issued to B.J. Burlage et al. On August 8, 1995, which is incorporated herein by reference in its entirety. In the same way, the pneumatic relay 1106, which serves as a pneumatic amplifier, is controlled by the I / P transducer 1104, as directed by the device controller 1102, to increase the air pressure of the drive signal line 1126 tire by a controlled amount. Accordingly, generally speaking, the pneumatic relay 1106 supplies a controlled output pressure to a charging or operating device, such as an actuator or a piston, in response to a control signal from the controller of the device 1102. A suitable relay is described in U.S. Patent Number 4,974,625, entitled "Four Mode Pneumatic Relay", issued to SB Paullus et al. On December 4, 1990, which is incorporated herein by reference in its entirety. In the illustrated mode, relay 1106 is a multi-function pneumatic four-mode relay, which can be configured for any combination of direct / instantaneous, direct / proportional, reverse / instantaneous, or inverse / proportional operation. In the proportional mode, the pneumatic relay 1106 develops a pressure output that is proportional to a pressure or pressure input. force. In an on / off or instantaneous mode, the pneumatic relay 1106 generates a constant pressure output, normally equal to the pressure of the applied supply, in response to the application of a defined range of force or pressure control inputs. In a direct operating mode, the output pressure of the pneumatic relay 1106 is increased with an increasing input signal. In a reverse operation mode, the output pressure of the relay decreases with a decreasing input signal. The input sensor 1120, the I / P sensor 1124, and the relay sensor 1128, are pressure transducers that contain a pressure converter to an electrical signal to convert a pressure signal into an electrical signal, and supply feedback signals to the controller of the device 1102 by means of a line 1130. The I / P sensor 1124 is diagnostically useful for detecting the failure of the I / P transducer 1104 or the pneumatic relay 1106, and for determining, for example, whether a fault is a mechanical failure or electrical failure. The I / P sensor 1124 is also useful for detecting some system problems, including a determination of whether the air pressure input to the digital field device 16 is sufficient. As a result, the I / P sensor 1124 allows it to be quickly diagnose the state of the I / P 1104 transducer and the 1106 pneumatic relay, so that these devices can be replaced quickly, if necessary, and in such a way that a process controller can be alerted to switch to the use of a different redundant device, if possible. In one embodiment, a suitable valve 1109 for use in the digital field device 116 is a valve and actuator assembly that utilizes a spring and diaphragm actuator on a slide rod valve that is used in an analog device described in the US Pat. United States of America Number 4,976,144 entitled "Diagnostic Apparatus and Method for Fluid Control Valves", issued to WV Fitzgeral, December 11, 1990, which is incorporated herein by reference in its entirety. In this example embodiment, a pressure signal of about 3 psi (0.21 kscm) is provided to the actuator 108, in response to an approximate 4 mA signal applied by the device controller 1102 to the I / P 1104 transducer, resulting in a corresponding pressure in the pneumatically actuated signal line 1126, which is insufficient to move the valve 1109 from a fully open position. If the field device controller 1102 changes the control current applied to the I / P transducer 1104 to about 20 mA, the I / P transducer 1104 generates a pressure in the pneumatic drive line 1126 of approximately 15 psi (1.06 kscm), which forces valve 1109 to a fully closed position. They are obtained Different positions of the valve 1109 between the fully open position and the fully closed position through the operation of the device controller 1102, controlling the input current applied to the I / P 1104 transducer in the range of 4 mA to 20 A. device controller 1102 performs digital communications of a relatively high speed, to receive control signals, and to transmit the position and pressure information, to an external processor or workstation in the process control network, by means of the bar collector 120. Device controller 1102 includes a storage or memory for storing the results of multiple diagnostic tests, so that relevant data for analysis is available. Diagnostic operations, such as diagnostics of the device, are generally in the form of software program codes, and are typically encoded, stored, and executed in the device controller 1102, of the field device 116. it can perform a diagnostic evaluation of the valve device 1109 through the operation of the device controller 1102, by controlling the input current applied to the I / P transducer 1104 in a sufficient range to test the valve 1109 between fully open and closed positions. completely closed. During the evaluation of device diagnostics, the outputs of the input sensor 1120, the I / P sensor 1124, and the relay sensor 1128, are monitored by the device controller 1102, to detect the pneumatic pressure in the pneumatic lines 1118, 1122, and 1126, respectively, that are used for the analysis. The output of the position sensor 1116 is also monitored to detect the position or movement of the valve stem 1114, which corresponds to a position or movement of a valve plug (not shown) inside the valve 1109. Accordingly, it is performs an operational test cycle of the valve 1109 under the control of the device controller 1102, by applying a controlled variable current to the I / P transducer 1104, detecting the pressure inside the pneumatic lines 1118, 1122, and 1126 , and detecting the position of the rod of the valve 1114, using the position sensor 1116. In this way, the device controller 1102 simultaneously receives variable time electrical signals, which indicate the pressures in the illustrative locations, and the position of valve 1109, and these signals can be used to determine any number of diagnostic parameters of the device of any any known or desired way. In one embodiment, the I / P transducer 1104 and the pneumatic relay 1106 are tested using a test procedure that drives the I / P 1104 transducer to be fully open, in order to measure the complete air pressure provided to the 1109 valve. While the I / P 1104 transducer is driven to open, the I / P sensor 1104 constantly measures the pressure in the pneumatic control line 1122. If the pressure begins to decrease, the test indicates that the air supply may be insufficient. An additional diagnostic test of the adequacy of the air supply is made by pumping the valve 1109, by applying an oscillatory signal to the I / P transducer 1104, such that the valve 1109 initiates a suction action with respect to the supply of air, and then the maximum flow and pressure values are measured using the I / P sensor 1124. As illustrated in Figure 14, the device controller 1102 includes a microprocessor 1140, an interface 1142, a bar isolation circuit collector 1144, a plurality of storage devices, such as a random access memory (RAM) 1146, a read-only memory (ROM) 1148, and a non-volatile random access memory (NVRAM) 1150, and a plurality of devices signal processing, such as an analog-to-digital converter 1152, a digital-to-analog converter 1154, and a multiplexer 1156. The interface 1142 (which is a bar connector) collector) is a circuit that performs the conversion of the serial to parallel protocol, and the conversion of the protocol from parallel to serial, and is used to add frame information to the data packets according to any desired protocol definition, such as the Fieldbus protocol. The busbar isolation circuit 1144 is a circuit which is used to convert a communication signal from the medium of two wires onto the busbar 120, in a digital representation of the communication signal, and supplies the energy received from the busbar 120 to other circuits in the controller of the device 1102, as well as to the I / P transducer 1104. The bus isolation circuit 1144 can also perform the wave configuration and the signaling on the bus 120. The analog-to-digital converter 1152 is connected to transducers, such as position and pressure transducers of position sensor 1116 and pressure sensors 1120, 1124, and 1128 of Figure 13, as well as any other desired analog input devices. Although analog-to-digital converter 1152 may have a limited number of input channels, multiplexer 1156 may be used to allow multiple signals to be sampled. If desired, multiplexer 1156 may include a bank of amplifiers connected between signal lines 1117 and 1130 (Figure 13), to amplify the position, pressure, and other feedback signals supplied to the same. The digital-to-analog converter 1154 performs the conversion from digital to analog over the signals developed by the microprocessor 1140, to be supplied to the analog components, such as the I / P transducer 1104. The illustrated modes of a control system network that implements redundancy, conveniently provides security to a cycle that implements two-way, two-wire digital communications, energized by the cycle, or other communications, by retaining the network operation of the control system despite the failure of a functional element. This advantage is important in process control systems where the expense of a deactivation of the process control line is enormous. Of course, the process control network that has redundant elements can use redundancy in other configurations, as desired. In addition, although the process control network with redundant elements has been described herein, including transmitters and valve / setter devices, it is noted that this network can include other types of devices, such as those having movable elements such as shock absorbers, fans, etc., as well as controllers, bridge devices, sensors, and so on. Moreover, although the switching logic of the process control network with redundant elements described in the present preferably is implemented in the software stored in, for example, a process control device or controller, in an alternative or additional way, it can be implemented in the hardware, in the firmware, etc., as desired. If implemented in the software, this logic can be stored in any computer readable memory, such as a magnetic disk, a laser disk, or other storage medium, in a RAM or a ROM of a computer, and so on. In the same way, this software can be supplied to a user or to a device by means of any known or desired delivery method, including, for example, on a communication channel, such as a telephone line, Internet, and so on. Accordingly, although the present invention has been described with reference to specific examples, which are intended to be illustrative only, and not limiting of the invention, it may be seen by those of ordinary skill in the art, that changes, additions may be made. , or deletions to the modalities disclosed, without departing from the spirit and scope of the invention.

Claims (27)

1. A process control system that performs process control functions within a process in a distributed manner, which includes: a communication bus that performs a communication process function in the process; a plurality of devices linked in a communicative manner on the communication bus, wherein each of the devices performs a different process function within the process; a pair of redundant elements that include a primary redundant element and a secondary redundant element, which are adapted to perform the same function of the process inside the process; and a controller coupled with the pair of redundant elements, to detect a failure of one of the redundant elements, and to operatively connect the other of the redundant elements in the process control system when detecting the failure of one of the redundant elements.

2. The process control system of claim 1, wherein the communication busbar implements a two-wire digital communication protocol, two-way, energized by the cycle.

3. The process control system of claim 2, wherein the communication protocol is a Fieldbus communication protocol.

4. The process control system of claim 1, wherein the communication busbar implements a four-wire communication protocol.

5. The process control system of claim 1, wherein the communication busbar implements a two-wire mixed digital and analog communications protocol, energized by the cycle.

The process control system of claim 1, wherein the primary redundant element comprises the communication bus, and the secondary redundant element comprises an additional communication bus.

The process control system of claim 1, wherein the primary redundant element comprises one of the plurality of devices, and the secondary redundant element comprises an additional device that is coupled with the communication bus.

The process control system of claim 7, wherein the primary redundant device and the secondary redundant device are valves that are operatively connected in parallel with one another in the process.

9. The process control system of claim 7, wherein the primary redundant device and the secondary redundant device are transmitters that are operatively connected in series with one another in the process.

The process control system of claim 1, wherein the primary redundant element comprises a first function block that performs a particular process function, and the secondary redundant element comprises a second function block that performs the process function particular.

The process control system of claim 10, wherein the first and second function blocks are located in devices different from the plurality of field devices.

The process control system of claim 10, wherein the controller includes an additional function block communicatively coupled to the first and second function blocks, which detects a malfunction of the first and second function blocks.

The process control system of claim 1, wherein the primary redundant element comprises a cycle that includes the communication busbar connected to one of the devices, and the secondary redundant element comprises a redundant cycle that includes a busbar redundant communication connected to a redundant device.

The process control system of claim 1, which further includes a control logic that operates on a functional element associated with the pair of redundant elements, the control logic being adapted to detect an operational state of one of the redundant elements, and to communicate the operating state to the controller.

15. The process control system of claim 1, wherein the controller includes a detector that detects the termination of communications from one of the pair of redundant elements, to detect the failure of one of the pair of the redundant elements.

16. A process control system, which comprises: a cycle controller that includes a control logic that implements a two-wire digital communication protocol, two-way, energized by the cycle; a redundant pair of two-way communication cycles coupled with the cycle controller, including a primary communication cycle and a redundant communication cycle; and a plurality of devices coupled with the redundant pair of two-way communication cycles.

17. The process control system of the claim 16, wherein the plurality of devices includes a first redundant device that connects to the primary communication cycle, and a second redundant device that couples with the redundant communication cycle.

18. The process control system of claim 16, wherein one of the plurality of devices is coupled to the primary communication cycle and the redundant communication cycle.

19. The process control system of claim 16, wherein the cycle controller implements a Fieldbus communication protocol.

20. A process control system, which comprises: a cycle controller that includes a control logic that implements a two-wire digital communication protocol, two-way, energized by the cycle; a two-way communication cycle coupled with the cycle controller; and a redundant pair of functional elements including a primary functional element coupled with the communication cycle, and a redundant functional element coupled with the communication cycle.

21. A method for configuring a process control system that performs process control functions in a process in a distributed manner, including the method the steps of: providing a communication bus that performs a communication process function in the process control system; communicating in a communicative manner a plurality of devices on the communication bus, in such a way that each of the devices performs a different process function within the process; use a pair of redundant elements, including a primary redundant element and a secondary redundant element, inside the process, to perform the same function of the process; and detect a failure of one of the redundant elements; and operatively connect the other of the redundant elements in the process control system, in response to the failure of one of the redundant elements.

The method of claim 21, wherein the primary redundant element comprises the communication bus, and the secondary redundant element comprises an additional communication bus, and further includes the step of connecting the communication bus and the Additional communication busbar to the same device.

23. The method of claim 21, wherein the The primary redundant element comprises one of the plurality of devices, and the secondary redundant element comprises an additional device, and further includes the step of connecting one of the plurality of devices and the additional device to the communication bus.

The method of claim 21, wherein the primary redundant element comprises a first function block that performs a particular process function, and the secondary redundant element comprises a second function block that performs the function of the particular process, and it also includes the step of alternately coupling in a communicative manner the first or second function blocks within a process control cycle in the process.

25. The method of claim 24, which further includes the step of locating the first and second function blocks in different devices of the plurality of field devices. The method of claim 24, which further includes the step of communicatively connecting a function block of the controller with the first and second function blocks, to detect the failure of one of the first and second function blocks. . The method of claim 21, wherein the primary redundant element comprises a primary cycle that includes the communication busbar connected to one of the devices, and the secondary redundant element comprises a redundant cycle that includes a redundant communication busbar connected to a redundant device, and that also includes the step of operatively connecting only one of the primary cycle or the redundant cycle, inside the control system of the process, at a particular time. SUMMARY Functional elements are interconnected within a two-way, two-wire digital communications environment, energized by the cycle, using selective redundant connections and selective redundant functional elements. Redundant functional elements and redundant connections provide a smooth transition from the operation of one element of the primary process cycle to one element of the secondary process cycle in the case of a failure of the primary process cycle element. Redundancy is implemented selectively using a redundant pair of field devices, or a redundant busbar pair that has a primary busbar and a redundant busbar. In a first case, the redundancy is selectively implemented using a single set of communication means (202 in Figure 6), such as a single communication cycle, but implementing redundant functional elements (204, 206), such as field devices , in such a way that recovery is achieved when a functional element fails, but not when the means of communication fail. In a second case, the redundancy is selectively implemented using a set redundant communication means (302, 303 in Figure 7) in addition to using the redundant devices (304, 306), so that recovery is obtained for both a failing device and a failing communication medium . In a third case, the redundancy is implemented selectively using a redundant set of communication means (402, 403 in Figure 8), but using a single device (404), in such a way that recovery is obtained for a means of communication that fails, but not for a device that fails.