Communications: electrical – Condition responsive indicating system – With particular system function
Reexamination Certificate
2000-11-07
2004-08-10
Crosland, Donnie L. (Department: 2636)
Communications: electrical
Condition responsive indicating system
With particular system function
C340S500000, C340S525000, C340S506000, C340S521000, C700S017000, C700S083000, C702S183000, C702S188000
Reexamination Certificate
active
06774786
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to process control systems and, more particularly, to the display of alarm conditions within a process control system.
DESCRIPTION OF THE RELATED ART
Process control systems, like those used in chemical, petroleum or other processes, typically include one or more centralized process controllers communicatively coupled to at least one host or operator workstation and to one or more field devices via analog, digital or combined analog/digital buses. The field devices, which may be, for example valves, valve positioners, switches and transmitters (e.g., temperature, pressure and flow rate sensors), perform functions within the process such, as opening or closing valves and measuring process parameters. The process controller receives signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices, uses this information to implement a control routine and then generates control signals which are sent over the buses or other communication lines to the field devices to control the operation of the process. Information from the field devices and the controllers is sometimes made available to one or more applications executed by the operator workstation to enable an operator to perform desired functions with respect to the process, such as viewing the current state of the process, modifying the operation of the process, etc. Some known controller/operator interface software is designed to generate and display process alarms resulting from process control operations performed by software in the controllers or other devices.
The DeltaV process control system sold by Fisher Rosemount Systems, Inc. uses function blocks located or installed in controllers or different field devices to perform control operations. The controllers and, in some cases, the field devices are capable of storing and executing one or more function blocks, each of which receives inputs from and/or provides outputs to other function blocks (either within the same device or within different devices), and performs some process control operation, such as measuring or detecting a process parameter, controlling a device or performing a control operation, like implementing a proportional-derivative-integral (PID) control routine. The different function blocks within a process control system are configured to communicate with each other (e.g., within a single device or over a bus) to form one or more process control loops, the individual operations of which can thus be spread throughout the process.
Typically, the function blocks or the devices in which these function blocks are implemented are configured to detect errors, faults or problems that occur within the process control loops or the functions being performed therein and to send a signal, such as an alarm message, to notify an operator at an operator workstation or other user interface that an undesirable condition exists within the process control system or within a control loop of the process control system. Such alarms may indicate, for example, that a function block is not communicating, has received or generated an out of range input or output, is undergoing a fault or other undesirable condition, etc. In the current alarm display systems, an application executed at, for example, an operator interface/workstation, is configured to receive messages containing process alarms related to process operation and to display these process alarms in a coherent and manageable manner to thereby enable an operator to manage alarms in some organized or logical way. Such an operator interface system is described in U.S. Pat. No. 5,768,119, entitled “Process Control System Including Alarm Priority Adjustment” which is hereby expressly incorporated by reference herein.
Known operator interface applications, such as that described in U.S. Pat. No. 5,768,119, are typically configured to enable an operator, i.e., the person overseeing the actual day-to-day operation of a process control system, to view the most critical process alarms, e.g., the alarms with the highest priority, first. Because these applications are designed with the object of providing information to a process control operator, they only display alarms associated with the functioning of the process itself. These applications are not configured to display other types of errors or alarms, such as alarms associated with malfunctioning field devices or other hardware like controllers or input/output (I/O) devices. Thus, for example, in the system described in U.S. Pat. No. 5,768,119, an operator display application displays a section of a process control system and provides an alarm banner on the bottom of the display indicating the highest priority process alarms. The displayed alarms are process alarms because they are generated by function blocks or other software used to implement a process control scheme or a process control loop and to indicate an error in the functioning of a process control loop. When an operator selects one of the process alarms at the operator workstation, the application provides the operator more information related to the selected alarm, such as the function block or module which generated the alarm, the priority of the alarm, whether the alarm has been acknowledged, etc. and may display information about the process relevant to the alarm, such as a faceplate for the loop in which the alarm occurred, a primary control display related to the portion of the plant in which the alarm occurred, etc.
Using these known displays, an operator can recognize the existence of an alarm and can try to fix the problem using other software applications available to the operator. In some cases, the operator may determine, based on the process alarms present, that one or more field devices or other hardware components may need repair or replacement. If this is the case, the operator may call or otherwise contact a maintenance person to schedule the device for testing, repair or replacement. Similarly, the operator may call an engineer to handle the alarm. In this manner, the operator detects a device or hardware problem based on received process alarms and manually hands the problem off to maintenance or engineer personnel to correct the problem. However, it requires an experienced or knowledgeable operator to detect device or hardware problems from process alarms.
In the past, conventional field devices were used in process control systems to send and receive analog (e.g., 4 to 20 milliamp) signals to and from the process controller via an analog bus or analog lines. However, these 4 to 20 ma signals are limited in nature in that they are indicative of process measurements made by the device or of process control signals generated by the controller required to control the operation of the device during runtime. As a result, the conventional 4-20 ma devices are incapable of generating alarms pertaining to the operational capability of the device itself. As a result, alarms associated with these devices have generally not been available within process control systems. However, in the past decade or so, smart field devices including a microprocessor and a memory have become prevalent in the process control industry. A number of standard and open smart device communication protocols such as the Foundation™ Fieldbus (hereinafter “Fieldbus”), HART®, PROFIBUS®, WORLDFIP®, Device-Net®, and CAN protocols, have been developed to enable smart field devices made by different manufacturers to be used together within the same process control network. In addition to performing a primary function within the process, smart field devices may store data pertaining to the device, communicate with the controller and/or other devices in a digital or combined digital and analog format, and perform secondary tasks such as self-calibration, identification, diagnostics, etc. Importantly, the devices conforming to at least some of these protocols are capable of detecting problems within the device itself and
Fletcher J. Clint
Havekost Robert B.
Ott Michael G.
Schleiss Trevor D.
Scott Cindy
Crosland Donnie L.
Fisher-Rosemount Systems Inc.
Marshall & Gerstein & Borun LLP
LandOfFree
Integrated alarm display in a process control network does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Integrated alarm display in a process control network, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Integrated alarm display in a process control network will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3284491