CN100485557C - Coordination of field device operations with inefficacy and bypasses in process control and safety system - Google Patents

Abstract

The process control or safety instrumentation system can use function block logic to coordinate logic within the process control or safety instrumentation system with these operating states even when the operating states of the field devices are externally activated for the process control or safety system. Logic within an input or voting function block associated with a field device can monitor or determine when the associated field device is placed in test or calibration mode and can automatically initiate the appropriate override or invalidation in response to these detected field device configuration states (bypass or override) function. Similarly, function block logic may automatically remove ignored or invalid functions when field devices are placed back into their normal operating configuration.

Description

Process control and safety systems use voids and overrides to coordinate field device operations

This application is a continuation-in-part, claiming from co-pending titled "On-Line Device Testing Block Integrated Into a Process Control/Safety System" with serial number Priority to US Patent Application No. 10/404,156, filed April 1, 2003, the entire disclosure of which is hereby expressly incorporated by reference.

technical field

The present invention relates generally to process control and safety systems for use in process facilities, and more particularly to a system for coordinating field device operation through the use of bypass or override within a process controller or safety system controller.

Background technique

Process control systems, such as those used in chemical, petroleum, or other processes, generally include one or more process controllers communicatively connected to at least one host computer or operator workstation and one or more field devices. Field devices can be, for example, valves, valve positioners, switches, and transmitters (eg, temperature, pressure, and flow rate sensors) that perform respective functions within a process facility, such as opening or closing valves and measuring process parameters. Process controllers receive signals from field devices representing process measurements, and/or other information about field devices, use this information to execute a control program, and then generate control signals that are transmitted to the field via a bus or wire device to control the operation of the process. information from field devices and controllers, generally available to one or more applications executed by an operator workstation, to enable the operator to perform any desired function related to the process, such as configuring the process, viewing the current status of the process , Modify process operations, etc.

In addition, in many processes, a separate safety system is provided to detect important safety-related problems in the process facility. When a problem occurs in the facility that may cause or cause serious hazards, such as toxic chemical spills, explosions, etc., the safety system Will automatically close valves, shut off power to equipment, switch flow, and more within the facility. These safety systems typically have one or more separate controllers, called logic solvers, separate from the standard process control controllers, which are connected to the safety field devices via separate buses or communication lines installed within the process facility. Logic solvers use safety field devices to detect process conditions related to important events, such as the position of certain safety switches or shutdown valves, overflow or underflow in a process, operation of critical power generation or control equipment, fault detection equipment operations, etc., whereby "events" are detected within the process facility. When an event is detected, the safety controller takes some action to limit the harmful effects of the event, such as closing valves, shutting down equipment, shutting off power from sections of the facility, and the like. Typically, these actions include switching safety equipment into a tripped or "safe" mode of operation designed to prevent serious or dangerous conditions within the process facility.

For example, when a signal is received from a field device that is bad, when logic within the field device is in a bad or abnormal mode, or when a manual signal is sent from an operator workstation to initiate such an override or disable, a safety instrumented system or logic solution Function blocks within the calculator can be programmed with logic that ignores or disables the use of signals or detection conditions of field devices. For example, programming some analog input (AI) or digital input (DI) function blocks will ignore or invalidate the logic provided to the safety system controller, preventing the safety system controller logic from using the output of the field device (i.e., AI or DI output of the block) as a valid input to determine whether an event has occurred. However, these function blocks typically provide such ignored or inactive signals in relation to manual activation signals, such as those issued by operators or engineers when the field device is undergoing maintenance.

Similarly, it is common in safety instrumented systems to use redundant input devices such as transmitters and switches to detect events within the system, providing greater safety integrity or process variable measurement validity. In such systems, it is sometimes necessary to provide voting logic functionality in the shutdown logic to determine whether process conditions are acceptable or hazardous based on redundant inputs. This voting logic is fairly simple, since it generally only requires a majority vote to determine the input to detect whether an event condition has occurred. In addition, as detailed in U.S. Patent Application Serial No. 10/409,576 entitled "Voter Logic Block Including Operational and Maintenance Overrides in a Process Control System" Descriptively, this patent application assigned to the assignee of the present invention, and expressly incorporated herein by reference, is capable of providing null and ignore capabilities to voting function blocks to prevent shutting down system operation, for example, during process control system start-up , enabling maintenance personnel to perform maintenance operations on one or more input devices, allowing selected process conditions to be temporarily ignored, and more.

However, in general, these overrides or invalidations, and in particular maintenance overrides, are manually initiated by the operator or maintenance personnel at the start of the maintenance program. For voting logic or cases where overrides or invalid auto-starts are made within the logic solver, these invalidations and overrides are generally related to actions being taken by the logic system, such as start-up procedures, delay characteristics, etc. Externally initiated changes in test or calibration state are irrelevant. Thus, while in the past, during the run of the field device test program, the engineer coordinated the ignore or invalidation of the field device to coincide with the operating state of the logic solver in the system instrumentation system, this time, this coordination was a manual process and was performed by This is subject to human error. For example, when running a maintenance program on a field device, the engineer has to manually provide an ignore start signal to the safety instrumentation logic, causing input blocks such as AI, DI, etc., or voting logic blocks related to the field device to ignore the signal from the field device or Input to prevent safety logic from identifying or detecting an event based on a field device signal and initiating a shutdown sequence. Function blocks within the logic solver have no mechanism for recognizing an externally initiated change in field device state as a test condition, and no mechanism for automatically providing disregard or invalidation of device outputs as a result of such a change in the field device.

Therefore, if the engineer forgets to manually set Ignore or Disable in the logic solver before initiating the field device test, the logic solver may detect a problem in the facility based on the signal from the field device under test, and unnecessarily Start the shutdown procedure. Such shutdown procedures are wasteful in terms of loss of material and time within the process facility, and can be hazardous or dangerous to persons conducting equipment testing, especially if equipment testing is being run manually from the bottom of the facility. Furthermore, if manual overrides or overrides are set within the safety logic solver, after the maintenance procedure is complete, the engineer may forget to clear the Such a procedure of field device measurement or condition, when applicable, may result in failure to initiate the shutdown procedure.

Furthermore, typical field devices incorporate write protection mechanisms designed to prevent configuration changes to the field device from unauthorized sources. In particular, field devices often incorporate write-protected variables which, when set, prevent any changes in the configuration settings of the field device and, when not set, allow such changes. In addition, many of these field devices must be subjected to power cycling to recognize the changed state of such a write-protected variable. In order to change the configuration of the field device, the write-protected variable must be set to In the unprotected state, the field device must cycle through the power-on sequence. While making the system less susceptible to unauthorized changes to the field device, this write-protect feature typically enables only manual tests to be run on the field device, since resetting the write-protect variable places the field device at the point where the field device can be tested. After the state, the field device should be manually powered off and on. It is generally difficult or practically impossible for a safety logic solver to automatically initiate a device test or calibration procedure for a field device when the field device is in the protected state because the field device write protection mechanism must be manually changed or turned off.

Contents of the invention

Process control or safety instrumentation systems use function block logic to coordinate logic within the process control or safety instrumentation system to coincide with field device operating states even when these operating states are initiated externally to the process control or safety instrumentation system. In particular, logic within an input or voting function block associated with a field device can monitor and determine when the associated field device is placed into test or calibration mode, and can automatically initiate appropriate overrides associated with such detected field device conditions. or invalid function. Similarly, function block logic may automatically remove ignored or invalid functions when field devices are placed back into their normal operating modes. Such ignored and ineffective automatic activation helps prevent safety systems within a process facility from initiating shutdown procedures as a result of manually initiated equipment testing performed by, for example, a handheld device attached to a field device. Similarly, automatic removal of overrides and invalidations helps prevent safety systems within a process facility from malfunctioning due to users forgetting to manually remove overrides or invalidations that were set up to allow equipment testing.

Also, the logic system and field devices can be programmed with a subset of instructions that can be activated by the safety logic system to place the field device in test or calibration mode even when the field device is write protected. In this case, the logic system and field device may have an additional protection command incorporating a write-check mechanism, as required by IEC61511, but this command can also cause the field device to enter a fixed current while the field device is still configured as write-protected. mode or calibration mode with the ability to send and start. New commands do not need to be protected by a field device write protection mechanism, since they are initiated by a known and trusted source, such as a safety logic system. However, these new commands enable the logic system to change the configuration of the field device, put the field device in test or calibration mode, without requiring power-up or other manual procedures. The safety logic system is then able to coordinate the required maintenance functions of the field devices in a safe manner without subjecting the field devices to other unwanted configuration changes. Similarly, even when the field device is otherwise write-protected, the security system and field device can store a record of the commands and responses passed between the field device and the logic solver, providing full visibility into the actions taken on the field device. log. If desired, additional command subsets may be in a vendor specific class such as Hart commands and thus be able to act with existing commands supported by the field device. Using this vendor communication capability, logic solvers can continuously monitor the status of field devices.

Description of drawings

Figure 1 is a block diagram of an exemplary process facility with a safety system that incorporates a process control system and uses one or more configurable AI, DI, and voting function blocks to automatically control system shutdown and maintain Neglect and Ineffective Action;

Figure 2 is a block diagram of a configurable voting function block in Figure 1, incorporating ignore and invalid functions;

FIG. 3 is a table of exemplary voting schemes including an ignore input that may be used by the voting functional block in FIG. 2;

Figure 4 is an exemplary table showing the manner in which the voting scheme will be degraded when an input to the voting functional block is in a bad state; and

Figure 5 is a block diagram of an input function block with field device state detection and activation logic that communicates between the field device and the associated ignore and disable functions in the function block for use in safety logic based on the sensed state of the field device Control logic within the solver, and configuration for controlling field devices.

Detailed ways

Referring now to FIG. 1 , a process facility 10 includes a process control system 12 incorporating a safety system 14 (indicated by dashed lines), which typically operates as a Safety Instrumented System (SIS), monitors and disables the control provided by the process control system 12, The possible safe operation of the process plant 10 is thereby maximized. The process facility 10 also includes one or more host workstations, computers or user interfaces 16 (which can be any type of personal computer, workstation, PDA, etc.) that can be accessed by facility personnel such as process control operators, maintenance personnel, security Engineer and more. In the example shown in FIG. 1 , two user interfaces 16 are shown connected to two separate process control/safety control nodes 18 and 20 and configuration database 21 via a common communication line or bus 22 . Communications network 22 may be implemented using any desired bus-type or non-bus-type hardware, using any desired hardwired or wireless communication architecture, and using any desired or suitable communication protocol, such as the Ethernet protocol.

Generally speaking, each of the nodes 18 and 20 of the process facility 10 includes process control system equipment and safety system equipment, which are connected together by a bus structure, which may be provided on a backplane, different Equipment is attached in this pedestal. Node 18 is shown in FIG. 1 as including process controller 24 (which may be a redundant pair of controllers) and one or more process control system input/output (I/O) devices 28, 30, and 32, while node 20 Illustrated to include a process controller 26 (which may be a redundant pair of controllers) and one or more process control system I/O devices 34 and 36 . Each process control system I/O device 28, 30, 32, 34, and 36 is communicatively coupled to a set of process control-related field devices, illustrated in FIG. 1 as field devices 40 and 42. Process controllers 24 and 26 , I/O devices 28 - 36 , and controller field devices 40 and 42 generally make up process control system 12 of FIG. 1 .

Similarly, node 18 includes one or more safety system logic solvers 50 , 52 , while node 20 includes safety system logic solvers 54 and 56 . Each logic solver 50-56 is an I/O device having a processor 57 executing a safety logic module 58 stored in memory 79 and communicatively coupled to provide control signals to safety system field devices 60 and 62, and and/or receive signals from security system field devices 60 and 62 . Additionally, each of the nodes 18 and 20 includes a message dissemination device (MPD) 70 or 72, communicatively connected to each other via a ring bus connection 74 (only partially shown in FIG. 1). Safety system logic solvers 50-56, safety system field devices 60 and 62, MPDs 70 and 72, and bus 74 generally make up safety system 14 of FIG.

Fieldbus协议(如图示用于现场装置42的)、或者CAN，Profibus，AS-Interface协议，仅举出几个名字。类似地，I/O设备28-36可为使用任何适当通信协议的任何已知类型的过程控制I/O设备。Process controllers 24 and 26 may be, by way of example only, DeltaV ^™ controllers sold by Emerson Process Management or any other conceivable type of process controller, using I/O devices 28, 32 and 32 (for controller 24), I/O devices 34 and 36 (for controller 26), and field devices 40 and 42, program the process controller to provide process control functions (using modules commonly referred to as control modules). In particular, each controller 24 and 26 implements or supervises one or more process control programs stored therein or otherwise associated therewith, and communicates with field devices 40 and 42 and workstation 14 for any desired mode controls the process 10 or a part of the process 10. Field devices 40 and 42 may be any desired type of field device, such as sensors, valves, transmitters, positioners, etc., and may conform to any desired open, proprietary, or other communication or programming protocol, such as including HART or 4-20ma protocol (as shown for field device 40), any field bus protocol such as

Fieldbus protocol (as shown for field device 42), or CAN, Profibus, AS-Interface protocols, just to name a few. Similarly, I/O devices 28-36 may be any known type of process control I/O device using any suitable communication protocol.

Safety logic solvers 50-56 in FIG. 1 may be any conceivable type of safety system control device that includes a processor 57 and memory storing a safety logic module 58 adapted for execution on processor 57, Control functions associated with security system 14 are provided using field devices 60 and 62 . Of course, safety field devices 60 and 62 may be any desired type of field device, conforming to or using any known or desired communication protocol, such as those mentioned above. In particular, field devices 60 and 62 may be safety-related field devices of the type that are traditionally controlled by separate, dedicated safety-related control systems. In process facility 10 shown in FIG. 1 , safety field device 60 is depicted using a proprietary or point-to-point communication protocol, such as HART or the 4-20ma protocol, while safety field device 62 is shown using a bus communication protocol, such as Fieldbus protocol. The safety field device 60 may perform any desired function, such as a shut-off valve, a shut-off switch function, and the like.

A common chassis 76 (represented by dashed lines passing through controllers 24 and 26, I/O devices 28-36, safety logic solvers 50-56, and MPDs 70 and 72) is used at each of nodes 18 and 20, which will Controllers 24 and 26 are connected to process control I/O cards 28 , 30 and 32 or 34 and 36 , and to safety logic solvers 50 , 52 , 54 or 56 , and to MPD 70 or 72 . Controllers 24 and 26 are also communicatively coupled to bus 22 and operate as bus arbitrators for bus 22, enabling each of I/O devices 28-36, logic solvers 50-56, and MPDs 70 and 72 to communicate with any workstation via bus 22. 16 communication.

As will be appreciated, each workstation 16 includes a processor 77 and memory 78 that stores one or more configuration and/or browsing applications adapted for execution on the processor 77 . Configuration application 80 and browsing application 82 are shown in the exploded view of FIG. 1 as being stored on one workstation 16 , while diagnostic application 84 is shown as being stored on another workstation 16 . However, these and other applications may be stored and executed on different workstations 16 or other computers associated with process facility 10, if desired. In general, the configuration application 80 provides configuration information to the safety engineer, enabling the safety engineer to configure some or all of the elements of the process plant 10 and store the configuration in the configuration database 21 . As part of the configuration action performed by the configuration application 80, a safety engineer may generate a control program or control module for the process controllers 24 and 26, and may generate a safety logic module 58 for any and all safety logic solvers 50-56 (including inputs, voting, and other functions used in the safety logic solvers 50-56 or even for generation and programming in the controllers 24 and 26), and via the bus 22 and controllers 24 and 26, these The various control and safety modules are downloaded into the appropriate process controllers 24 and 26 and safety logic solvers 50-56. Similarly, configuration application 80 may be used to generate and download other programs and logic to I/O devices 28-36, any field devices 40, 42, 60, and 62, and so on.

Conversely, the browsing application 82 can be used to provide one or more displays to a user, such as a process control operator, a safety operator, etc., including information about the process control in separate views or in the same view, if specifically desired. Information on the status of the system 12 and security system 14. For example, the browsing application 82 may be an alert display application that receives alert indications and displays the alert indications to an operator. If desired, such an alarm viewing application may be employed, for example, in U.S. Patent No. 5,768,119 entitled "Process Control System Including Alarm Priority Adjustment" and entitled "Integrated Alarm Display in a Process Control Network ( Integrated Alarm Display in a Process Control Network) in the form disclosed in U.S. Patent Application No. 09/707,580, both of which are assigned to the assignee of the present application and are expressly incorporated herein by reference. It will be understood, however, that the alarm displays or alarm bars of these patents may receive and display alarms from both process control system 12 and security system 14 in an integrated alarm display, whereby alarms from both systems 12 and 14 will be communicated to The operator workstation 14 executing the alarm display application will be recognizable as alarms from different devices. Similarly, operators can handle security alarms displayed in the alarm bar in the same manner as process control alarms. For example, an operator or user could use the alarm display to acknowledge the security alarm, turn off the security alarm, etc., which would transmit the message to the appropriate process controllers 24, 26 within the security system 14 using communications on the bus 22 and pedestal 76, to take appropriate action related to the security alert. In a similar manner, another browsing application could display information or data from both the process control system 12 and the security system 14, whereby these systems could use the same type and kind of parameters, security and Any data from one of 14 can be integrated into displays or views customarily provided for process control systems.

Diagnostic application 84 may be used to perform diagnostic or maintenance procedures within the process control and safety systems of facility 10 . Such a diagnostic application may perform any desired type of diagnostic or maintenance process, such as running a process and valve test, starting a process, etc., which may or may not be reported to one or more AI, DI, or voting function blocks used within the process facility 10 Invalidation is provided to prevent safety system operation caused by the diagnostic routine based on input from one or more devices. Similarly, a handheld configuration or test device 85 can be connected to any of the field devices 40, 42, 60, and 62 on which to perform the configuration, test, and calibration The OR voting function block transmits or does not transmit the ignore or invalid signal.

In any event, applications 80, 82, and 84, as well as any other applications, may communicate individual configuration and other signals to each process controller 24 and 26 and each safety system logic solver 50-56, and may Each process controller 24 and 26 and from each safety system logic solver 50-56 receives data. These signals may include process level information related to operating parameters controlling process field devices 40 and 42 , and may include safety level information related to controlling operating parameters of safety-related field devices 60 and 62 . When the safety logic solvers 50-56 are programmed to recognize both process level information and safety level information, the safety logic solvers 50-56 are able to discriminate between the two types of information and will not be able to level configuration signal programming or implementation. In one example, the programming information communicated to the process control system device may include certain fields or addresses that are recognized by the safety system device and prevent those signals from being used to program the safety system device.

Safety logic solvers 50-56 may use the same or a different hardware or software design than that used for process control I/O cards 28-36, if desired. The use of alternate techniques for devices within the process control system 12 and devices within the safety system 14 may minimize or eliminate collectively caused hardware or software failures. In addition, security system devices including logic solvers 50-56 may use any desired isolation and security techniques to reduce or eliminate the chance of unauthorized changes, thereby enabling related security functions to be performed. For example, secure logic solvers 50-56 and configuration application 80 may require a person with a particular level of authority, or at a particular workstation, to make changes to secure modules within logic solvers 50-56, which This level of authority or location is different than the authority, level of access, or location required to make changes to the process control functions performed by controllers 24 and 26 and I/O devices 28-36. In this case, only those persons designated within the security software or at workstations authorized to make changes to the security system 14 have authorization to change security-related functions, thus minimizing the chance of corruption of the security system 14 operation . As will be appreciated, to achieve this security, processors within the safety logic solvers 50-56 evaluate input information for proper form and security, and operate as gatekeepers to the safety logic solvers. Changes are made by the security level control module 58 executing within 50-56.

The use of backbone 76 in each node 18 and 20 enables safety logic solvers 50 and 52 and safety logic solvers 54 and 56 to communicate locally with each other, coordinate the safety functions implemented by each of these devices, and communicate data with each other , or perform other integrated functions. MPDs 70 and 72 , on the other hand, operate so that portions of safety system 14 located at many different locations in facility 10 can still communicate with each other, providing coordinated safety operations at different nodes in process facility 10 . In particular, MPDs 70 and 72 coupled to bus 74 enable safety logic solvers associated with different nodes 18 and 20 of process facility 10 to be communicatively cascaded together, considering relevant safety functions within process facility 10 according to assigned priorities cascade. Additionally, two or more related safety functions at different locations within process facility 10 may be interlocked or interconnected without running dedicated lines to each safety field device within separate zones or nodes of facility 10 . In other words, the use of MPDs 70 and 72 and bus 74 enables a safety engineer to design and configure safety system 14 that is physically distributed throughout process facility 10, but with its communicatively interconnected different components, making each Security-related hardware communicates with each other when needed. This feature also provides scalability of the safety system 14, as it enables additional safety logic solvers to be added as they are required, or as new process control nodes are added to the process facility 10. onto the security system 14.

Logic solvers 50-56 may be programmed to perform control actions associated with safety devices 60 and 62, if desired, using a function block programming mode. In particular, as shown in the expanded view of one safety control module 58a (stored in memory 79) of the logic solver 54, the safety control module may comprise a set of communicatively interconnected function blocks that may be generated and downloaded to logic solver 54 for implementation during operation of process 10 . As shown in FIG. 1, the control module 58a includes two voting function blocks 92 and 94 having inputs communicatively interconnected with other function blocks 90, which may be, for example, analog inputs (AI), digital inputs (DI) function block, or other function blocks designed to provide signals to the voting function block 92. Voting function blocks 92 and 94 have at least one output connected to one or more other function blocks 91 which may be an analog output (A0), a digital output (D0), a cause, and a target for effect logic Effect function blocks, control and diagnostic function blocks that may receive output signals from voting function blocks 92 and 94 to control the operation of safety devices 60 and 62, and the like. Of course, the security control module 58a can be programmed in any desired manner to include any type of function block together with one or more voting function blocks configured in any desired or useful manner to perform any desired Function. Additionally or alternatively, other input function blocks such as AI and DI function blocks can be directly connected to the safety system logic to provide a safety logic control module that activates one or more A shutdown device, in response to these events detected by the AI or DI function block.

Thus, while the expanded view of safety control module 58a in FIG. 1 includes a digital voting function block 92 with five digital inputs and an analog voting function block 94 with three analog inputs, it will be appreciated that any number of different safety logics can be created module 58, and for use within each of the various logic solvers 50-56, each of these modules may include any number of AI, DI, voting, or other input functional blocks having the ability to communicate in any desired manner to Any desired number of inputs to other function blocks. Similarly, if used in, for example, a Fieldbus network, the voting function blocks 92 and 94 may be any Fieldbus type function blocks or any other function blocks connected thereto, capable of being set up and implemented in other devices, such as in field device 62 . If used external to the safety system, the voting function blocks 92 and 94 and other input function blocks may be implemented in the process controllers 24, 26, I/O devices 28-36, field devices 42, etc. As is generally understood, voting function blocks 92 and 94 typically receive redundant inputs provided by redundant sensors or transmitters within safety system 14 and apply a voting scheme to these inputs to determine whether a safety system is present based on all those inputs. error condition. In addition, these voting function blocks can be programmed to initiate override or invalidation within the safety system logic.

FIG. 2 is a block diagram illustrating components of the voting function block 94 of FIG. 1 with an example of ignore and disable functionality. Voting function block 92 is an analog voting function block in that it processes an analog input signal delivered through eg analog input (AI) function block 90 . Generally, voting function block 94 includes three inputs labeled IN1, IN2, and IN3 that are adapted to receive analog input signals from, for example, redundant sensors or other redundant elements within process facility 10, such as field device 60 in FIG. and 62. Each input IN1, IN2 and IN3 is provided to a fault bound checking block 95a, 95b or 95c and a predetermined bound checking block 96a, 96b or 96c. A failure limit check block 95 compares the input delivered thereto with preset limits to determine if the input signal has reached a value associated with a failure condition (the value may be an upper limit, a lower limit, or a value within a predetermined range) . In a similar manner, the predetermined limit check block 96 compares the input delivered to it with preset predetermined limits to determine whether the input signal has reached a value (which may be an upper limit value) associated with an alarm or warning indicating a failure condition , the lower limit, or a value within a predetermined range), although the error condition does not exist yet, it is about to occur. In effect, the predetermined limit check block 96 enables an alarm or event signal to be generated, indicating that a dangerous or other undesirable condition, although not yet present, is imminent.

The output of each error limit check block 95 and predetermined limit check block 96 (for example, the output may be a digital signal, which is set to an upper limit value when a limit or a predetermined limit is reached in blocks 95 and 96) is delivered to a set of Input ignores one of inhibit blocks 98a, 98b, and 98c. Input ignore disable block 98 performs input disable on the respective inputs IN1, IN2 and IN3 so that one or more of these inputs can be disabled, that is, they are not used within the voting function block 94 to determine whether an error condition exists or whether a predetermined A false alarm condition exists. Each input override inhibit block 98 provides an output for the associated error margin condition to error voting logic block 100a and an output for the associated predetermined boundary condition to predetermined error voting logic block 100b. Voting logic blocks 100a and 100b implement any desired operational voting logic to determine from their inputs whether a fault condition or a predetermined fault alarm condition exists.

Fail vote logic block 100a and scheduled fail vote logic block 100b provide a fail signal and a preset fail alert signal, respectively, to an inhibit or disable block 102 (when these conditions are determined to exist), which disables the voting function 94 in, for example, desired Any fault signal or predetermined fault alarm signal output is provided during start-up or other work, run-time or maintenance procedures where operation of the voting block 94 is to be inhibited. Inhibit block 102 issues a determined miss output signal (labeled Out) as a result of miss voting logic block 100a operating and enabling disable block logic, and also develops a determined Pre_out signal as a predetermined miss voting logic block 100b operating and enabling disable block logical result. The Out signal can be used to drive shutdown sequence operations within the safety system 14 of FIG. 1 , while the Pre_out signal can be used to provide an alert of the impending fact of an error condition within the process facility 10 . Of course, the Out and Pre_out signals can also be used for other purposes if so desired.

The voting function block 94 may include a set of parameters, some of which are indicated in FIG. operation. In particular, the Trip Limit (Trip_Lim) and Pre_Trip_Lim parameters are used to set or establish the trip limit used in the Trip Limit block 95 and to set the Pre_Trip Limit used in the Pre_Trip_Lim block 96 . The margin of error and/or the predetermined margin of error parameter may be the same for each of the different blocks 95 and 96 or may be set individually for each block 95 and 96 . Similarly, the miss hysteresis (Trip_Hys) and predetermined trip hysteresis (Pre_Trip_Hys) parameters are used to set the hysteresis induced by blocks 95 and 96 that must propagate between successive trips. That is, once a block 95 or 96 detects an input signal above (or below) the limit, the hysteresis value of the type hysteresis parameter (for block 95) and the hysteresis value of the predetermined error hysteresis parameter (for block 96) The value determines how far the input signal must travel below (or above) the limit before the miss signal (or predetermined miss signal) is turned off, or before a second miss signal (or predetermined miss signal) can be set by the block.

Voting function block 94 also has an internal error-type configuration parameter named Trip_Type that defines normal and error status values associated with the inputs and/or outputs of voting function block 94 . For example, when the voting function block 94 is configured as "De-energized to Trip" (which may be the default value), the normal operating value of the output is one and the trip status value is zero. Conversely, when the voting function block 94 is configured as "Energized to Trip", the normal operation value is zero and the error state value is one. This initial determination is made at error bound checking blocks 95a, 95b, and 95c, and at predetermined bound checking blocks 96a, 96b, and 96c, which correspond to inputs IN1, IN2, and IN3, respectively. The Detect_Type parameter can be used to determine whether the comparison to the margin of error is greater than (upper bound) the comparison, or less than (lower bound) the comparison. This comparison occurs at the appropriate error limit check block 95 and predetermined limit check block 96 to determine whether the input signal has reached a predetermined limit.

As will be appreciated, the output of each miss limit check block 95 will indicate whether a miss has been indicated by a corresponding one of inputs IN1, IN2 and/or IN3. As described above, a maintenance invalidation or override can be applied by the input ignore disable block 98 to each individual input IN1 , IN2 and IN3 to prevent those inputs from being used in the voting logic applied by the voting logic block 100 . This override feature is highly desirable when, for example, maintenance is being performed on a transmitter or other field device providing an input signal to the voting function block 94 . When using voting logic to determine a false output from multiple inputs, maintenance overrides are not always necessary because misvoting a false signal (which may be due to a maintenance action on the sensor providing the input) does not necessarily result in a false. However, this override function is needed to prevent erroneous mistakes during maintenance actions, and may be needed in some voting logic, such as in an alternative voting logic scheme, where even from redundant sensors The presence of a single miss signal will also cause a miss.

When an input ignore inhibit block 98 causes an input to be ignored, the ignored input will not be used by the voting logic blocks 100a and 100b to generate the fail signal even if the input value exceeds the limit specified by the faillimit or predetermined faillimit parameters Or pre-determined error warning signal. In order to enable bypassing, the Bypass_Permit parameter can firstly control whether input bypassing is allowed in the first place. In general, if the Bypass_Permit parameter is set or activated, bypassing on the input will be allowed; and if the Bypass_Permit parameter is not set or activated, input bypassing will not be allowed. While a single Bypass_Permit parameter is applicable to all bypass prohibit blocks 98, a separate bypass permission will be set for each input bypass prohibit block 98a, 98b, 98c.

If the Bypass_Permit parameter is set or activated, the BYPASSx parameters can be used to cause one or more bypass inhibit blocks 98 to operate to disable the use of an associated input IN1, IN2 or IN3. The x in the BYPASSx parameter indicates which of the inputs IN1, IN2 or IN3 is disabled. If desired, more than one input can be disabled at any particular time, or the voting block 94 can be configured to allow only one input to be disabled at a time. The Bypass_Permit and BYPASSx parameters can be set or issued in any desired way, such as via an operator display button on an operator or maintenance screen, a physical key switch, a discrete input to enter safe mode, via a configuration, control, display or diagnostic application, By another input function block (described in more detail below), or by any other means. Of course, if in any particular implementation of the voting function 94 the use of bypass permissions is not required, a default value of the Bypass_Permit parameter can be set to be active in the configuration of the voting function 94 .

The Bypass_Timeout parameter can be used to set the amount of time after which bypass is set for a block 98 such that the bypass will automatically expire. In this case, each input bypass inhibit block 98 may include a bypass timer as one of a set of timers 110, which timer is set to the Bypass_Timeout parameter value, and which timer may count down when the bypass starts . In this case, the input bypass disable block 98 may disable the use of the associated input until BYPASSx is turned off, or until the bypass timer reaches zero. As will be appreciated, an ignore timer may be used to ensure that the ignore is removed after a predetermined amount of time.

If desired, the input override inhibit block 98 can also be configured to provide a reminder alert to users such as operators, safety engineers, technicians, etc., to remind or draw the user's attention to the approaching override timeout. If ignore is configured to disappear or not activate on an ignore timeout, then notifications can be sent to the user or other operator before the timeout by setting the REMINDER_TIME parameter to some non-zero value. In this case, if the ignore timer is non-zero but less than the alert_time parameter, and either ignore input votes as a miss, a reminder alert can be activated to provide an alert to the user that an alert will occur with the imminent expiration of the ignore timer shutdown. If the input vote is not ignored, it is not necessary to activate the alarm, although it can still be activated. However, it will be appreciated that even when the ignore timeout alarm is activated, a failure will not come immediately because there are not enough other inputs voting as failures to cause the failure voting logic block 100a to generate a failure signal.

In one embodiment, the ignore timer can only be re-armed when the first ignore times out. However, the ignore timer can be a writable parameter such that after notification that a timeout is imminent, the ignore timer can be increased using an operator display button (or some other suitable technique) to extend the ignore time. This feature enables the user to extend the ignore time, eg, by providing an override input to voting function 94 while a maintenance procedure is still in progress on the field device. In addition, notification of an ignore timeout may be used for indication purposes, eg, only if the ignore is activated when the ignore timer expires. In this case, even if the reminder time parameter is set to zero, the reminder alarm can be set to be active when the ignore timer times out. However, if the reminder time parameter is non-zero, the reminder will still occur prior to the timeout (if the input vote was a miss). Reminder alerts and ignore alerts can be acknowledged or unacknowledged alerts.

The voting logic performed by the voting logic blocks 100a and 100b may be a logic function of "M out of N (M out of N)". According to this function, out of a total of N inputs, M inputs must vote as false. For example, voting block 94 may be configured for 2 out of 3 (2oo3) voting, which means that two of the three inputs must meet the error threshold before the output of voting logic block 100a is set to the error state value, and Two of the three inputs must meet predetermined error limits before the error voting logic block 100b is set to the predetermined error alarm value. The N value in the "N to M" function is determined by the number of uninhibited inputs, and the M value is determined by a block internal parameter called the number of errors (NUM_TO_TRIP). Its default value can be set to any value equal to or less than N in the configuration. want value. Common voting schemes may include, for example, two out of three (2oo3), one out of two (1oo2), two out of two (2oo2) and the like. However, any other voting logic could also be used. Due to other features of block 94, voting function block 94 can also be used in single transmitter applications, as in the case of one-to-one (1oo1) voting function logic.

In general, a 1oo2 or 1oo1 voting scheme would require a maintenance override function, since disabling even one transmitter during a maintenance action would necessarily result in a fault condition set by the voting logic block 100a in a manner that is not valid for that transmitter. A misdetection condition is caused at the input of the voting function block 94 of the detector. However, voting function blocks configured to require multiple voting misses can still benefit from the ignore function for maintaining multiple predictable behaviors during the procedure.

Voting function blocks 100a and 100b can be implemented in one of two ways by ignoring one of the inputs IN1, IN2 or IN3. The number of inputs required to determine a failure condition (or predetermined failure alarm condition) can be reduced by one, or this number can be left constant. For example, when voting logic block 100a is configured as a 2oo3 voting logic block, and one input IN1, IN2 or IN3 is ignored, the voting scheme can later become a 1oo2 voting scheme, meaning that the number of inputs that need to vote as wrong is reduced by one (same as available together with the number of inputs). Optionally, the 2oo3 voting scheme can be changed to a 2oo2 voting scheme when the selected input is ignored, meaning that the number of inputs required to vote as false remains the same (even if the number of available inputs is reduced by one). When ignoring an input, the ignore option parameter can be used to determine whether the exact amount required for the error is reduced by one or not. Figure 3 illustrates the results of this option in several different voting schemes. The first column in Fig. 3 represents the voting logic scheme configured without inhibiting the input; the second column in Fig. 3 represents the voting logic when an input is prohibited and the initial configuration number M of judgment errors is used; the first column in Fig. 3 The three columns represent the voting logic when an input is disabled and the number of misdecisions M is reduced by one. Of course, additional input inhibition may also cause similar changes in the values indicated in the second and third columns of FIG. 3 . Regardless, the miss vote logic block 100a (and the scheduled miss vote logic block 100b) generally do not reduce the actual number of inputs required to determine a miss to less than one, and when the possible inputs for a vote miss are reduced to zero, as in In the 1oo1 voting scheme, mistakes will be prohibited.

Configurable input overrides disable the default behavior of block 98 to allow only one input override at a time. This function can be enforced by a write-protect feature, preventing the second input from being bypassed. Optionally, multiple inputs can be ignored at the same time. The BYPASSx parameters may have additional write protection if desired, which requires setting the BYPASS_PERMIT parameter to ignore permission or make it true before the BYPASSx parameters are set.

After voting is performed at the miss voting logic block 100a, depending on the selected N-to-M voting scheme, the miss delay on time parameter TRIP_DELAY_ON may be applied such that for a configurable period of time before the OUT signal changes to the miss state value (its absence A provincial value can be set at zero seconds) the vote miss condition must act. In a similar manner, a miss delay off time parameter TRIP_DELAY_OFF (whose default value may be set at zero seconds) may be applied when the vote is cleared for a miss condition, i.e., when the miss condition is determined to not exist by its input to the miss vote logic block 100a , to delay time, during which the OUT signal returns to the normal state value. Of course, the miss-delay on time parameter and the miss-delay off time parameter can have different and any desired values, and can be applied to the OUT signal generated by the miss-voting logic block 100a and the Pre_out alarm generated by the scheduled miss-voting logic block 100b Signal on both, or apply to either. The Fail Delay On Time and Fail Delay Off time periods are independently configurable for Fail Voting Logic 100a and Scheduled Fail Voting Logic 100b and tracked by a timer 110, if desired.

As noted above, disable block 102 is a startup or other operationally disabled function. If desired, this deactivation function can be initiated by another function block, such as in an input function block (as will be described in more detail below). For example, it may be desirable to negate the output of voting function block 94, forcing the OUT signal to a normal state for short periods of time during startup or other temporary operating situations, including some field device testing situations. This inhibit or disable function can be used, for example, to cancel persistent fault requests generated by voting function block 94 because the process or its corresponding part is in a shutdown state, a field device is in a maintenance state, etc., thereby allowing the process start-up routine to enter such a point, at Here the process value provided at the input of the voting function block 94 is no longer a value indicating that a fault should be initiated, or a value that enables a complete maintenance procedure to be performed on one or more field devices.

In one example, disable block 102 may include a default action, upon receiving a startup indication that may be indicated by setting the Startup parameter, disable block 102 to force the OUT signal, if desired, and the Pre_out signal to a normal state value, after a delay determined by the startup ( STARTUP_DELAY) parameter for a configurable period of time. Disable block 102 may include an enable countdown timer as one of timers 110 that is set to a value specified by the enable delay parameter and begins counting down after receiving an enable indication via the enable parameter. When the countdown counter times out, the fault voting logic block 100a and the predetermined fault voting logic block 100b resume normal fault detection. The disable block 102 may be configured such that successive settings of the activation parameters do not affect the activation time while the activation timer is counting down. Optionally, each new setting of a startup parameter may be allowed to re-arm the startup timer so that when it times out, the error that would otherwise occur can be avoided.

Similar to the input ignore prohibition block 98, the prohibition block 102 may have a reminder function, which can be turned on, for example, by setting an ignore parameter. While this reminder function operates for input override (maintenance override), it also operates for activation override in substantially the same manner. Thus, when the start timer is greater than zero but less than the configurable reminder time (REMINDER_TIME) parameter (which can be set at configure time), and there are enough vote misses, the reminder alarm condition becomes active, indicating that the ignore is about to expire , depending on the values of inputs IN1, IN2 and IN3, will result in a stop.

If desired, the startup timer may additionally or alternatively automatically expire when the input has stabilized, that is, when there are not enough vote misses for a configurable period of time. This settling time may be tracked by a settling timer, which may be one of timers 110, and detects when the output of voting logic block 100a is stable, eg, for a specified period of time, a non-false or normal value. In this case, when the countdown timer is started, the steady timer can be counted up whenever there are not enough vote misses, and can be reset whenever miss votes meet or exceed the required number of misses. If the settling timer reaches the configured settling time value, the startup timer is reset to zero and normal error detection functionality resumes. Of course, the stability timer is not reset at the end of the enable time period, but can be reset at any time at the start of the enable and during the enable inhibit period when there are enough miss votes.

Additionally, the enable ignore time need not be based on a fixed time period or the value of the inputs IN1, IN2 and IN3 of the voting function block 94, but may instead be based on the occurrence or non-occurrence of an event. In this case, boot ignore ends when the boot reset parameter is set or becomes set or true, which can follow the detection of an event. In this manner, initiation of ignore may depend on the presence or absence of an event of indeterminate length of time.

The state of inputs IN1, IN2 and/or IN3 can be used to affect the action of voting function block 94, if desired, and this state behavior can be set using the state option parameter. As will be appreciated, in many systems, such as HART and Fieldbus systems, a transmitter or other field device will transmit a status signal along with a process variable signal or value, where the status signal represents the status of the transmitter itself. Such a status signal may indicate that the transmitter is in a normal or good condition, or in an abnormal condition, such as a bad or other undesirable condition, which may cause the process variable value sent by the transmitter to be suspect. Thus, the state of the input signals provided to the IN1, IN2 and IN3 inputs of the voting function block 94 can be determined and used to implement the voting scheme or manner in which the input is to be used.

If desired, the voting scheme used by block 100 can be set so that a failed transmitter (i.e., an input with a bad state) is not automatically activated when other transmitters are validly representing the rms value of the measured process variable mistake. When considering the state of the input signal, an option will always use the value of input IN1, IN2 or IN3, regardless of the state of the input. In this way, hardware failure does not have to cause downtime, and there will be time to allow repairs. Another option would be to handle a bad state on an input, similar to ignoring the input, in the same way as the input ignore disable block 98 described above, preventing that input from voting as a miss. The third option will automatically consider the input as a miss vote if the input state is bad. This can be configured as a default option, providing the highest level of security for the 1ooX voting scheme. Figure 4 illustrates the manner in which several shared voting schemes are degraded when one input signal is in a bad state for each of the above options. For example, as shown in the first row, first column of Figure 4, a 2oo3 voting scheme effectively degrades to a 2oo3 (if the signal value from a bad transmitter is a non-miss value) or a 1oo2 voting scheme ( If the signal value from a bad transmitter is a false value). Conversely, as shown in the first row, second column of Figure 4, if no bad transmitter values are used, the 2oo3 voting scheme degrades to a 2oo2 voting scheme (or to a 1oo2 scheme depending on the selected ignore feature). Similarly, as shown in the first row, third column of Figure 4, if the bad transmitter's value is treated as a miss vote, then the 2oo3 voting scheme will effectively degrade to a 1oo2 voting scheme regardless of what the actual value of that signal may represent.

Of course, the use of the input status of the voting function block 94 may be handled the same or differently in each of the miss voting logic block 100a and the predetermined miss voting logic block 100b. If desired, the state of the 0ut and Pre_out signals can be set to Good, unless all non-ignored inputs are bad, in which case the state of the Out and Pre_out signals can be set to Bad. If desired, an alarm condition parameter indicating a bad input may be set by voting function block 94 when any not ignored input is bad.

As will be understood from the above discussion, the voting function block may thus include ignore and disable functions therein. However, in the past, this function has been initiated by the mode or state of the voting function block input, or by a manual signal from the operator, such as by an operator display device 16, to initiate this function. However, the input function block itself can be configured to detect when the field device is placed in a configuration or mode that is not relevant to the normal operation of the field device, such as a test or calibration mode. For example, a HART device can be placed in fixed current mode to check logic solver inputs and writes to associated field lines, or to perform calibration, and after doing so, Hart communications can be used to indicate that the field device is in fixed current mode. The logic solver uses an input function block that is able to detect this fixed current pattern and automatically initiates an ignore or disable function within the logic solver (such as the voting function block ignore or disable function described above) to process the input from the field. Device related input, if ignored. Similarly, the input function block can detect the return of the field device from the fixed current mode to the normal operation mode, and can include logic to remove ignore or invalid, thereby automatically ensuring that the field device input is used in the safety logic to detect the process facility. event. Of course, other removal logic, such as the timeout feature described above, can also be used to automatically remove ignored or invalid features detected by input function blocks.

Figure 5 illustrates an input function block 120, which in this case is an AI function block incorporating logic that automatically detects the configuration state of the associated field device and uses this detected state to generate or activate Ignored or invalid functions within logic solvers. As shown in FIG. 5 , functional block 120 is communicatively coupled to field devices 125 , voting logic 127 , and other safety system logic 129 . The input function block 120 may include a standard communication stack 130 that communicates with the field device 125 using any desired communication protocol, such as a standard communication protocol such as the HART communication protocol or the Fieldbus communication protocol. Of course, the communications stack provides software for field device 125 to communicate, receive standard (or non-standard if desired) communications from field device 125, and send information to field device 125 if desired.

Device configuration detection block 132 is coupled to communication stack 130 and receives and decodes information from field device 125 to determine the configuration status of field device 125 . Standard software is not shown in FIG. 5 but is included in the input function block 120 for communicating with the field devices, receiving signals from the field device 125, decoding and interpreting these signals, and generating the IN1 signal at the output of the function block 120. The IN1 signal may be provided to, for example, voting function block 127 or any other desired block within the safety system logic.

The input function block 120 may also include a device configuration detection block 132, which may, for example, receive and detect a signal (e.g., a message) from the field device 125 indicating that the field device 125 has been placed in a fixed current mode (indicating Field device 125 has been placed in test mode externally by, for example, handheld configuration device 85 in FIG. 1 ) or in some other non-normal operating configuration mode. If desired, device configuration detection block 132 may periodically or in response to a detected change in field device condition, transmit a signal to field device 125 querying the configuration condition of field device 125, thereby causing field device 125 to respond to a Device 125 signals the configuration status.

Upon detecting a change in configuration status or a change in the state of field device 125 from a normal operating configuration state to a non-normal operating configuration state, the device configuration detection block 132 sends a signal to the ignore/invalid logic block 134, which uses any desired/ Appropriate logic to enable override or disable (associated with field device 125 ) and provide such ignore or disable signal to voting function 127 . For example, the disable/ignore logic 134 may automatically generate ignore or disable for use in the voting function block 127, preventing the voting function Block 127 uses output signals from field devices 125 in detection events within the process facility. In a similar manner, the invalidation/ignore logic 134 may automatically remove the previous signal sent to the voting function block 127 as it detects that the field device 125 has been placed into the normal operating mode from a test or calibration mode (e.g., a non-normal operating configuration state). , thereby causing the voting function block 127 to again use the output signal of the field device 125 (ie, the IN1 signal) to detect events within the process facility.

In this manner, input function block 120 includes logic to automatically coordinate with changes in field device configuration even when the change is caused by an external device without other coordination with safety system logic Neglect and invalid use. As a result of this coordination, when a field device is placed in a test, calibration or other abnormal operating state by any user or source, the safety system will automatically ignore or invalidate the input from the field device. Conversely, when a field device is placed into a normal operating state from a test, calibration, or other non-normal operating configuration state, the safety system will automatically remove the disable or override, thereby reconciling the state of the field device with the use of the disable and ignore in the safety system.

When the invalidation/ignore logic 134 is described as removing invalidation or ignoring when detecting a field device to return to normal operation, the invalidation/ignore logic 134 may alternatively or additionally employ automatic timer-based invalidation or ignoring, as with the voting function in FIG. 2 Block 94 relates to those described above. Thus, the disable/ignore logic 134 may include logic that automatically removes the ignore or disable when the timer expires after the override or disable has been initiated, alerts the user that the time has expired or is about to expire, or uses the same voting function block 94 void or neglected removal of any other action related to the above.

In addition, even when the field device 125 is in a write-protected state, the security system can also be protected by being able to place the field device 125 from a normal operating state into a test, calibration, or other non-normal operating state without manual assistance from a user or operator. Further coordinate testing of field devices. In particular, the input function block 120 may include a device configuration control block 140 capable of accessing a set of instructions 142 and sending the instructions 142 to the field device 125 to change the Configuration settings for field device 125 . If desired, the device configuration control block 140 may cause changes in the field device configuration in response to signals provided by other logic within the logic solver, i.e., the SIS logic 129, thereby enabling the logic 129 to run through test procedures, calibration procedures, etc. Field devices as part of the safety system logic.

Instructions 142 may be a subset of specially configured instructions that can cause configuration changes of field device 125 , such as from normal operation mode to constant current mode, etc., even if field device 125 is write-protected. Such a set of instructions would generally need to be added to the set of instructions recognized by the field device 125, and thus, the field device 125 would need to be programmed to respond to one or more active signals from, for example, the safety logic system from the device configuration control block 140. Received, activates these configuration changes. Such a set of commands may include Command 35 of the HART protocol, which is a "write range value" command that can be used to reconfigure the HART device. Of course, other write commands from HART or other protocols could also be used.

In the example shown in FIG. 5 , field device 125 includes a typical communication stack 150 that communicates to and from field device 125 using any desired or known communication protocol. The field device 125 also includes configuration control software that controls the configuration state of the field device 125 . Such configuration control software may be standard configuration control software, as used in known field devices, which uses the write protection parameter 154 to control whether the required configuration changes are made. However, the configuration control software 152 can be programmed to recognize a set of instructions 142 from a trusted source, such as from a known logic or process controller, and while the write protect parameter 154 is still set to the protected state, after one of these instructions is effectively received , to initiate a change in the configuration of the field device 125 . In this manner, a logic controller, process controller, or other trusted source can make configuration changes to field device 125 without changing write-protected parameters 154 to an unprotected state (which would also allow other configuration changes to be made by other unauthorized sources) without forcing the field device through power cycling. If desired, instructions 142 may include instructions to cause a configuration change, such as from a normal operating state to a test or calibration state, or vice versa, and may include a designation of the source of the instruction, ie, the device sending the instruction. The field device 125 can also be programmed to initiate a configuration change specified by one of the commands 142 (whether or not the field device 125 write protection feature). In this manner, even when field device 125 is write-protected, as defined by write-protect variable 154, command 142 can be sent by a trusted source, causing a configuration change in the field device.

In any event, using the new set of instructions, the logic solver may cause the field device 125 configuration to change, causing the field device 125 to enter or leave a test or calibration mode. In addition to causing the field device to enter fixed current mode or calibration mode, these new commands can also be combined with a write check mechanism, as required by IEC61511, and can be sent and initiated while the field device 125 is still configured as write protected. However, new commands do not need to be protected by the write protection mechanism 154 of the field device 125 since they are initiated by a known and trusted source, namely the safety logic system. As a result of these instructions, the safety logic system is able to coordinate the necessary maintenance functions for the field devices in a safe manner without subjecting the field devices 125 to other unwanted configuration changes.

If desired, as part of this process, either or both of the device configuration control block 140 of the input function block 120 and/or the field device 125 may include logs 160 and 162, which are stored or recorded by the device configuration control block 140. information and configuration changes, and the responses generated by the field device 125 to these information. Of course, these logs can be configured in any standard, known or desired way. In this manner, the safety system and field device 125 can store a record of commands and responses between the field device 125 and the safety system logic solver, providing information on the field device 125 even when the field device 125 is otherwise write-protected. Full log of actions taken.

If desired, and as noted above, once placed in a test, calibration, or other non-normal operating mode, only a subset of instructions 142 are initiated by the logic solver, such as by device configuration control block 140 in FIG. A source such as a logic solver within security system 14 can use these instructions to make configuration changes, although field device 125 may be operated by other sources, such as handheld configuration device 85 in FIG. 1 or the like. Also, if desired, the field device 125 can be equipped so that it is only configurable by the logic solver or has changes in configuration, thereby ensuring that any configuration changes to the field device 125 are consistent with the operation of the safety system 14 .

While the input function block used to provide coordination between the field device and the logic solver is described in detail as an AI function block, any type of function block such as AI, DI, voting or other input function blocks can be programmed to provide this functionality . Thus, while device configuration control logic 140 and device configuration detection logic 132 are shown and described as being provided within input functional blocks, such logic can be provided instead or in addition to other functional blocks, including associated logic in logic solvers. independent function blocks. Furthermore, while described as bound and used in a logic solver, the device configuration detection and control blocks 132 and 140 described herein can be used in other types of control blocks or routines, such as blocks that perform traditional process control functions Those implemented in, such as the control software in the controllers 24 and 26 in FIG. 1 or any other device that performs control actions. Also, while the input function block 120 in FIG. 5 is described as providing an ignore or invalid signal to the voting function block 127 in the safety logic system, the input function block 120 may instead or additionally provide such an invalid or ignore signal to the safety system ( or other elements within a process control system) that cause other types of neglected or ineffective other functions associated with those systems. Thus, the explanations of the voting block disable and ignore features provided above represent only one example of the way in which automatically generated ignore or disable signals can be used and are not considered the only way to use these ignore or disable signals.

While described in the example using the HART communication protocol, the device configuration detection and control logic described herein can be used with any other desired communication and device protocol, such as Fieldbus, Profibus, CAN, etc. Alternatively, this logic can be used in the Foundationantion Fieldbus protocol or any other system where the safety function is or can be used entirely in the field device. Thus, while illustrated as being controlled in a separate device from the field device, the device detection and configuration logic described herein may be implemented in the field device itself.

While FIG. 1 shows that safety logic system 14 uses a voting function block to receive input from an AI, DI, or other input function block, system logic system 14 may use input from any other type of function block, or may generate input as a process Other types of signals within facility 10. For example, and as will be understood, structural support may be provided at one level above the communication stack in a security system for reading input/output values and device status/condition/mode signals, and for extracting any other information sent between devices Instructions or information that enable the detection of configuration changes within a device. This structure can also be used in other control languages such as ladder logic, sequential function table, state transition, and custom function block languages, just to name a few, by observing or reading signals that represent state changes, or these languages Among other operations within the system, it represents a configuration change or other change within the system that would result in an ignored or invalid activation or non-activation within the security system.

Also, while the outputs of voting function blocks 92 and 94 in FIG. 1 are shown as being connected to output function blocks, such as AO, DO or other function blocks such as cause and implement function blocks or control routines, these outputs may be connected to Any other desired type of function blocks associated with safety logic system 14 , such as sequential function blocks, hierarchical function blocks, etc., or may even be directly connected to other applications or programming environments within process facility 10 . Similarly, when logic described herein is implemented using a function block programming style, the same logic can be provided in other types of programming environments and still be considered a function block as used herein. Thus, while the function blocks described herein are described for use in a safety system in a process facility or process control environment, these or similar function blocks can be used in a standard process control environment, or for other desired uses other than in a safety system usage of.

When implemented, any of the elements described herein, including input blocks, voting blocks, inhibiting blocks, voting logic blocks, device configuration and detection blocks, signal connections, etc., may be implemented in software stored in any computer readable memory, Such as on a magnetic disk, on a laser or optical disk, or on other storage media, in a computer's RAM or AOM or in a processor, etc. The signals and signal lines described herein may take any form, including actual wires, data registers, memory locations, and the like. The software described herein may take any form, including application software executing on a general-purpose computer or processor, or hard-coded software burned into, for example, an application-specific integrated circuit (ASIC), EPROM, EEPROM, or any other firmware device . Similarly, such software may use any known or contemplated method of delivery, including on a computer-readable disk or other transferable computer storage mechanism, or via a communication channel such as a telephone line, the Internet, the World Wide Web, any other local area network or Wide area network, etc. (this delivery is considered to be the same as or interchangeable with providing such software via a transportable storage medium), to a user, process facility, operator workstation, controller, logic solver, or any other computing device. Additionally, such software may be provided directly without modulation or encryption, or may be modulated and/or encrypted using any suitable modulated carrier and/or encryption techniques prior to transmission over the communication channel.

Of course, the function blocks described herein can be implemented using any external process control communication protocol (in addition to the Fieldbus protocol or the DeltaV protocol), and can be used to communicate with any type of function block, including those specifically identified or supported by the Fieldbus protocol. Any functional block that is similar or identical to any different functional block. Additionally, while the input and voting function blocks in this one embodiment may be Fieldbus "function blocks", note that the use of the term "function block" herein is not limited to those defined by the Fieldbus protocol as function blocks, instead, may is any other type of block, program, hardware, firmware, etc., entity associated with any type of control system and/or communication protocol that can be used to implement some process control routine functionality, or has a predetermined setup or protocol , used to provide information or data to these other function blocks. Thus, although function blocks typically take the form of objects within an object-oriented programming environment, this is not necessarily the case, and instead other logic units may be used, to use any desired programming structure or pattern in the process facility or control Perform specific control (including input and output) functions within the environment.

Accordingly, when the present invention has been described with reference to specific examples, such examples are for illustration only and not for limitation, and it will be apparent to those skilled in the art that changes, additions, or deletions may be made to the disclosed embodiments, without departing from the spirit and scope of the invention.

Claims (57)

1. functional block entity, be used in and have communication link and fetch in the process environment of processor of the one or more field devices of control, in this field device at least one is to can be configured to multiple different configuration status, this state comprises normal running configuration status and at least one abnormal operation configuration status, and this functional block entity comprises:

Computer-readable medium; With

Functional block is stored on the computer-readable medium and is suitable for carrying out on processor, and this functional block comprises:

Input, it is suitable for receiving the input signal from the process environment, and input signal is represented the configuration status of at least one field device;

Detecting unit, it is connected to input, detects when this at least one field device is in the abnormal operation configuration status; With

Forbid logic, when it is in the abnormal operation configuration status when this at least one field device, produce inhibit signal automatically, to ban use of further signal from this at least one field device.

2. functional block entity as claimed in claim 1 is forbidden wherein that logic produces and is ignored signal, is used to ignore the use from the further signal of this at least one field device.

3. functional block entity as claimed in claim 1 forbids that wherein logic produces invalid signals, is used for the judgement that invalid use is carried out from the further signal of this at least one field device.

4. functional block entity as claimed in claim 1, wherein functional block comprises second input, is used to receive the further signal from this at least one field device.

5. functional block entity as claimed in claim 1, wherein detecting unit is according to the input signal from described at least one field device, detect further when described at least one field device enters the normal running configuration status from the abnormal operation configuration status, and wherein when described at least one field device is in the normal running configuration status, forbid that logic removes inhibit signal automatically, allow use from the further signal of this at least one field device.

6. functional block entity as claimed in claim 1, wherein said at least one field device comprises the write-protect variable, and when described at least one field device can switch between normal running configuration status and abnormal operation configuration status the State Control of this variable; Wherein functional block comprises that further stored configuration changes the storer of instruction, when the write-protect variable is in the following time of state of forbidding between normal running configuration status and abnormal operation configuration status switching described at least one field device, this configuration change instruction makes this at least one field device change between normal running configuration status and abnormal operation configuration status; And wherein functional block comprises commander sender, sends the configuration change instruction to this at least one field device, causes described at least one field device generation configuration change, and without reset write protection variable.

7. functional block entity as claimed in claim 6, wherein functional block comprises daily record, represents when functional block sends the configuration change instruction to this at least one field device.

8. functional block entity as claimed in claim 7, wherein functional block comprises another daily record, when described at least one field device has responded the configuration change instruction that receives from functional block in expression.

9. functional block entity as claimed in claim 1, wherein input is suitable for receiving the input signal that meets HART communication protocol.

10. functional block as claimed in claim 1 wherein at the fixed time after the total amount, forbids that logic is suitable for removing automatically inhibit signal.

11. functional block according to claim 10 wherein further comprises notification logic, notifies the described inhibit signal of user to be activated second schedule time total amount.

12. functional block as claimed in claim 10 wherein further comprises notification logic, after the total amount, forbids notifying this inhibit signal of user to be removed before the logic removal inhibit signal at the fixed time.

13. functional block as claimed in claim 1 further comprises notification logic, notifies the described inhibit signal of user to be activated a schedule time total amount.

14. a Process Control System that is used in the process environment comprises:

Field device configurablely is provided with multiple different configuration status, comprises normal running configuration status and abnormal operation configuration status, and wherein field device produces the signal of relevant process;

Communication link; With

Controller is connected via communication links to field device, and is suitable for using the interior control activity of signal implementation environment of relevant process, and this controller comprises:

Processor;

Signal receiving unit, it is suitable for carrying out on processor, by the one or more signals of communication link reception from field device;

Detecting unit, it is suitable for detecting according to the one or more signals from field device when field device is in the abnormal operation configuration status; With

Forbid the unit, when it is in the abnormal operation configuration status when field device, produce inhibit signal automatically, in process environment, carry out the control activity by controller, forbid from the use of the relevant process signal of this field device.

15. Process Control System as claimed in claim 14, wherein detecting unit is further adapted for according to the one or more signals from field device, detects when field device enters the normal running configuration status from the abnormal operation configuration status; And wherein when field device is in the normal running configuration status, forbid that the unit removes inhibit signal automatically, allow to carry out use from the relevant process signal of field device by controller.

16. Process Control System as claimed in claim 14, wherein field device is a sensor.

17. Process Control System as claimed in claim 14, wherein field device is the valve by controller control.

18. Process Control System as claimed in claim 14, its middle controller is the security system controller, uses the signal of relevant process to come the interior shutdown procedure of start-up course environment.

19. Process Control System as claimed in claim 14; wherein field device comprises the write-protect variable; when field device can switch between normal running configuration status and abnormal operation configuration status the State Control of this variable; and its middle controller comprises that further stored configuration changes the field device dispensing unit of instruction; when the write-protect variable is in the following time of state of forbidding between normal running configuration status and abnormal operation configuration status switching field device, this instruction is suitable for causing that field device changes between normal running configuration status and abnormal operation configuration status.

20. Process Control System as claimed in claim 19, its middle controller or field device comprise daily record, write down when controller transmission configuration change instructs to field device.

21. Process Control System as claimed in claim 19, its middle controller or field device comprise daily record, write down when field device changes between a normal running configuration status and abnormal operation configuration status and another normal running configuration status and abnormal operation configuration status.

22. Process Control System as claimed in claim 19, its middle controller further comprises logic, sends a signal to the field device dispensing unit, makes the field device dispensing unit cause field device to produce configuration status and changes.

23. Process Control System as claimed in claim 14, wherein the abnormal operation configuration status of field device is the fixed current pattern.

24. Process Control System as claimed in claim 23, wherein field device is observed the HART agreement.

25. Process Control System as claimed in claim 14 forbids that wherein the unit is suitable for removing inhibit signal after the total amount at the fixed time.

26. Process Control System as claimed in claim 25 further comprises notification logic, notifies the described inhibit signal of user to be activated second schedule time total amount.

27. Process Control System as claimed in claim 25 further comprises notification logic, after the total amount, forbids notifying the user will remove inhibit signal before the unit removal inhibit signal at the fixed time.

28. Process Control System as claimed in claim 14 further comprises notification logic, notifies the described inhibit signal of user to be activated a schedule time total amount.

29. control system that is used in the process environment, have field device and the communication link that is connected to field device, this field device can be configured to multiple different configuration status, comprises normal running configuration status and abnormal operation configuration status, and this control system comprises:

Storer;

Processor;

First control routine, it is stored on the storer, is suitable for carrying out on processor, uses first signal from field device to come process control function in the implementation environment; With

Second routine comprises:

Input, it is suitable for by the secondary signal of communication link reception from field device, expression field device configuration status;

Detecting unit, it is suitable for according to secondary signal, detects when field device is in the abnormal operation configuration status; With

Forbid the unit, it automatically produces inhibit signal when field device is in the abnormal operation configuration status, and provides this inhibit signal to first control routine, forbids use from field device first signal by first control routine.

30. control system as claimed in claim 29, wherein second routine stores and is suitable for carrying out on processor on storer.

31. control system as claimed in claim 29 further comprises the second memory and second processor, wherein second routine stores and is suitable for carrying out on second processor on second memory.

32. control system as claimed in claim 29, wherein detecting unit is further adapted for according to the secondary signal from field device, detects when field device enters into the normal running configuration status from the abnormal operation configuration status; And wherein when field device is in the normal running configuration status, forbid that the unit is suitable for removing automatically the inhibit signal from first control routine, allow to carry out use from first signal of field device by first control routine.

33. control system as claimed in claim 32, wherein first control routine is the security system control routine, uses first signal from field device to come shutdown procedure in the start-up course environment.

34. control system as claimed in claim 29 is forbidden wherein that the unit produces and is ignored signal as inhibit signal, makes and whether carry out in the evaluation of process control function that first control routine does not use first signal from this field device.

35. control system as claimed in claim 29, forbid that wherein the unit produces invalid signals as inhibit signal, make that first control routine is the implementation control function not when use first signal determining in first control routine when whether the logical expressions process control function of implementation function should be carried out.

36. control system as claimed in claim 29, wherein this field device comprises the write-protect variable, and when field device can switch between normal running configuration status and abnormal operation configuration status the State Control of this variable; And wherein control system comprises that further stored configuration changes the 3rd routine of instruction; with the sender unit that the configuration change instruction is sent to field device; when the write-protect variable is in the following time of state of forbidding between normal running configuration status and abnormal operation configuration status switching field device, this configuration change instruction causing field device is changed between normal running configuration status and abnormal operation configuration status.

37. control system as claimed in claim 36, wherein the 3rd routine is connected to first control routine communicatedly, and is suitable in response to the control signal from first control routine, changes instruction to the field device transmission configuration.

38. control system as claimed in claim 36, wherein the 3rd routine comprises daily record, the record configuration change instruction when the 3rd routine sends to field device.

39. control system as claimed in claim 36, wherein second routine comprises daily record, the configuration change that sends to field device in response to the 3rd routine instructs, and writes down when field device changes between a normal running configuration status and abnormal operation configuration status and another normal running configuration status and abnormal operation configuration status.

40. control system as claimed in claim 29 forbids that wherein the unit is suitable for removing inhibit signal automatically after the total amount at the fixed time.

41. control system as claimed in claim 40 further comprises clock, determines the preset time total amount.

42. control system as claimed in claim 40 further comprises notification logic, after the total amount, forbids notifying user's inhibit signal to be removed before the unit removal inhibit signal at the fixed time.

43. control system as claimed in claim 42 forbids that wherein the unit makes the user increase the preset time total amount before forbidding that inhibit signal is removed in the unit.

44. control system as claimed in claim 29 further comprises notification logic, notifies the described inhibit signal of user to be activated a schedule time total amount.

45. method that is used in the process environment controller, with the logic in the field device tuning controller, wherein field device is connected via communication links to controller, and configurablely be set to multiple different configuration status, comprise normal running configuration status and abnormal operation configuration status, this method comprises:

Reception is from first signal of field device, and uses first signal to carry out the control function relevant with process environment;

By the secondary signal of communication link reception from field device, the configuration status of this signal indication field device;

According to secondary signal, detect when field device is in the abnormal operation configuration status from field device; With

When field device is in the abnormal operation configuration status, forbid the use of first signal in the execution control function automatically.

46. method as claimed in claim 45 wherein detects the secondary signal that further comprises according to from field device, detects when field device enters the normal running configuration status from the abnormal operation configuration status; And wherein forbid automatically comprising and when field device is in the normal running configuration status, allow the use of first signal in the execution control function automatically.

47. method as claimed in claim 45, wherein control function is the security system control function, uses from the shutdown procedure in the first signal enabling process environment of field device.

48. method as claimed in claim 45, wherein field device comprises the write-protect variable, and when field device can switch between normal running configuration status and abnormal operation configuration status the State Control of this variable; And wherein this method comprises that further stored configuration changes instruction; when the write-protect variable is in the following time of state of forbidding switching field device between normal running configuration status and abnormal operation configuration status; the instruction of this configuration change is suitable for causing that field device changes between normal running configuration status and abnormal operation configuration status; concurrent delivery is put and is changed instruction and give field device, makes field device generation configuration change and without reset write protection variable.

49. method as claimed in claim 48 further comprises storing daily record, this daily record represents when controller transmission configuration change instructs to field device.

50. method as claimed in claim 48 further comprises storing daily record, the configuration change instruction when field device response slave controller receives is represented in this daily record.

51. method as claimed in claim 45, wherein forbid the use of first signal in the execution control function automatically, comprise producing and ignore signal that this ignores signal makes the logic that is used for judging execution control function whether not use first signal in the execution control function whether evaluating.

52. method as claimed in claim 45, the use of wherein forbidding first signal in the execution control function automatically comprises the generation inhibit signal, when using first signal determining logical expressions control function of execution control function should be carried out, this inhibit signal makes and is used for the logic execution control function not of execution control function.

53. method as claimed in claim 45 wherein forbids being included in the use that allows first signal in the execution control function after the schedule time total amount automatically automatically.

54. method as claimed in claim 53 is wherein forbidden automatically comprising and is used clock to determine the preset time total amount.

55. method as claimed in claim 53 wherein forbids being included in after the schedule time total amount automatically, after the schedule time total amount and allow making of first signal to be used for notifying the user will allow the first signal execution control function before the execution control function automatically.

56. method as claimed in claim 55 after wherein forbidding automatically being included in schedule time total amount, allows to use before the first signal execution control function automatically, makes the user can increase the preset time total amount.

57. method as claimed in claim 45 wherein forbids being included in after the schedule time total amount automatically, notifies the user to prevent to use first signal to come execution control function.

Images