Patent Description:
Control systems, which include process control systems and safety instrumented systems (SIS), typically include one or more controllers to control the process or safety system. The controllers in these systems frequently use field devices to perform a variety of functions within the control environment. For example, in a liquid level control system, the field devices may be used to monitor and/or control the amount of a liquid in a holding tank. When the level of the liquid has reached a predetermined position (high or low), the control system may respond by utilizing one of the field devices, such as a valve, to adjust the flow of liquid entering or exiting the holding tank. A float assembly checking system is described for example in the document <CIT>. A method and device for making measurements, the results of which are dependent on liquid status, are described for example in the document <CIT>. A testing device for level switch of moisture separator is described in the document <CIT>. Improvements in float-operated electric relays are described in the document <CIT>.

Proper maintenance of the process control system or the SIS of a process plant may include monitoring the operation of the field devices, testing the field devices, and repairing or replacing the field devices. An important concern for control personnel managing a control system is knowing whether the field devices being used are available and operational. In a level control system implementing a high-level detection application, the field device is commonly considered to be operating in a "dry" state or condition because the field device is not tripped or actuated until the level of the liquid rises to reach a high-level target or limit. The field device may therefore appear idle or static during the time the liquid level remains below the high-level target. If a movable portion of the field device is stationary or idle for an extended period of time, there is a concern that the field device will not function or may otherwise be inhibited from operating properly when the liquid does reach the high-level target. Control personnel may therefore prefer to periodically validate that the level detecting field device is operational and available.

Commonly utilized techniques to validate the operability and/or availability of a level detecting field device generally require control personnel to visit the site of the control system to replicate a rise or fall of the liquid level or simulate a level detection by the field device. One known validation technique involves changing the liquid level to engage or trip the level detecting field device and confirm that the field device is operational. However, changing the liquid level may require an extensive amount of time to raise or lower the liquid to the target level so that the field device can be tripped. Another known validation technique requires control personnel to manually manipulate the field device to simulate the tripping of the field device. However, manually manipulating the field device may not be possible with some level controllers, such as electronic devices, which are not mechanical in nature.

Example systems and methods to validate the availability and/or operability of a field device within a control plant are herein described. A float liquid level control system according to the invention is defined in the annexed independent claim <NUM>. Other advantageous features are defined in the annexed dependent claims <NUM> to <NUM> related to the system. A method according to the invention of validating a level control system is defined in the annexed independent claim <NUM>. Other advantageous features of the method are defined in the annexed claim <NUM>.

In <FIG>, a process plant <NUM> is shown to include a process control/safety control node <NUM>, which may include a process control system <NUM> integrated with a safety system <NUM> (depicted within dotted lines). The safety system <NUM> generally operates as a safety instrumented system (SIS) and may monitor the operation of the process control system <NUM> to ensure the safe operation of the process plant <NUM>. If necessary, the safety system <NUM> may override control of the process control system <NUM>.

The process plant <NUM> also includes one or more host workstations <NUM> or computing devices, which may be any type of computer, for example. Each workstation <NUM> may include a processor <NUM>, memory device <NUM>, and/or a user interface <NUM> such as a display monitor and/or keyboard that are accessible by control personnel. In the example process plant <NUM> illustrated in <FIG>, two workstations <NUM> are shown connected to the process control/safety control node <NUM> and to an external memory device <NUM> via a common communication line or bus <NUM>. The communication bus <NUM> may be implemented using any desired bus-based or non-bus-based hardware, hardwired or wireless communication structure, or suitable communication protocol, such as an Ethernet protocol.

The process plant <NUM> includes both process control system devices and safety system devices operatively connected together via the bus structure that may be provided on a common backplane <NUM> into which different process controllers and input/output devices are attached. The process plant <NUM> illustrated in <FIG> includes at least one process controller <NUM> having a processor <NUM> and one or more process control system input/output (I/O) devices <NUM>, <NUM>, <NUM>. Each process control system I/O device <NUM>, <NUM>, <NUM> is communicatively connected to a set of process control related field devices, illustrated in <FIG> as controller field devices <NUM>, <NUM>. The controller <NUM>, the I/O devices <NUM>, <NUM>, <NUM>, and the field devices <NUM>, <NUM> generally make up the process control system <NUM> of the process control/safety control node <NUM>.

The process controller <NUM>, which may be, by way of example only, a DeltaV™ controller sold by Emerson Process Management or any other desired type of process controller, is programmed to provide process control functionality using the I/O devices <NUM>, <NUM>, <NUM> and the field devices <NUM>, <NUM>. In particular, the processor <NUM> of the controller <NUM> implements or oversees one or more control processes or control strategies in cooperation with the field devices <NUM>, <NUM> and the workstations <NUM> to control the process plant <NUM> or a portion of the process plant in any desired manner. The field devices <NUM>, <NUM> may be any desired type, such as sensors, valves, transmitters, positioners, etc., and may conform to any desired open, proprietary, or other communication or programming protocol including, for example, the HART or the <NUM>-<NUM> ma protocol (as illustrated for the field devices <NUM>), any bus protocol such as the Foundation® Fieldbus protocol (as illustrated for the field devices <NUM>), or the CAN, Profibus, and AS-Interface protocols, to name but a few. Similarly, each of the I/O devices <NUM>, <NUM>, <NUM> may be any known type of process control I/O device using any appropriate communication protocol.

The controller <NUM> may be configured to implement the control process or the control strategy in any desired manner. For example, the controller <NUM> may implement a control strategy using what are commonly referred to as function blocks, wherein each function block is a part or object of an overall control routine and operates in conjunction with other function blocks (via communications called links) to implement process control loops within the process control system <NUM>. Function blocks typically perform one of: an input function such as that associated with a transmitter, a sensor, or other process parameter measurement device; a control function such as that associated with a control routine that performs PID, fuzzy logic, etc. control; or, an output function that controls the operation of some device such as a valve to perform some physical function within the process control system <NUM>. Hybrids of these function blocks, as well as other types of function blocks, may also exist. While the description of the control system is provided herein using a function block control strategy that incorporates an object oriented programming paradigm, the control strategy or control routines or control loops or control modules could also be implemented or designed using other conventions, such as ladder logic or sequential function charts, for example, or using any other desired programming language or paradigm.

For the purposes of this disclosure, the terms control strategy, control routine, control module, control function block, safety module, safety logic module, and control loop essentially denote a control program executed to control the process and these terms may be interchangeably used herein. However, for the purposes of the following discussion, the term control module will be used. It should further be noted that control module described herein may have parts thereof implemented or executed on by different controllers or other devices if so desired. In addition, the control modules described herein to be implemented within the process control system <NUM> and/or the safety system <NUM> may take any form, including software, firmware, hardware, and any combination thereof. For example, the control modules, which may be control routines or any part of a control procedure such as a subroutine or parts of a subroutine (such as lines of code), may be implemented in any desired software format, such as using ladder logic, sequential function charts, control routine diagrams, object oriented programming or any other software programming language or design paradigm. Likewise, the control modules described herein may be hard-coded into, for example, one or more EPROMs, EEPROMs, application specific integrated circuits (ASICs), programmable logic controllers (PLCs), or any other hardware or firmware elements. The control modules may be designed using any design tools, including graphical design tools or any other type of software/hardware/firmware programming or design tools.

One or more control modules <NUM> may be stored on memory <NUM> in the controller <NUM> and executed on the processor <NUM> of the controller <NUM>, which is typically the case when these function blocks are used or associated with standard <NUM>-<NUM> ma devices and some types of smart field devices such as HART devices. The control modules <NUM> may also be stored on other memory locations <NUM>, <NUM> within the system <NUM> or implemented by the field devices <NUM>, <NUM> themselves, which may be the case with Fieldbus devices.

The safety system <NUM> of the process control/safety control node <NUM> includes one or more safety system logic solvers <NUM>, <NUM>. Each of the logic solvers <NUM>, <NUM> is a safety controller (also invariably referred to as an I/O device) having a processor <NUM> capable of executing safety logic modules <NUM>. The safety logic modules <NUM>, which may be similar to the control modules <NUM>, may be stored in a memory <NUM> location of one or both logic solvers <NUM>, <NUM>. The logic solvers <NUM>, <NUM> are communicatively connected to provide control signals to and/or receive signals from safety system field devices <NUM>, <NUM>. The safety controllers <NUM>, <NUM> and the safety system field devices <NUM>, <NUM> generally make up the safety system <NUM> of <FIG>.

The safety field devices <NUM>, <NUM> 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, the field devices <NUM>, <NUM> may be safety-related field devices of the type that are conventionally controlled by a separate, dedicated safety-related control system, such as a liquid level detector or an emergency shutdown (ESD) valve. In the process plant <NUM> illustrated in <FIG>, the safety field devices <NUM> are depicted as using a dedicated or point-to-point communication protocol, such as the HART or the <NUM>-<NUM> ma protocol, while the safety field devices <NUM> are illustrated as using a bus communication protocol, such as a Fieldbus protocol. Generally, the safety devices (both the controllers <NUM>, <NUM> and the safety system field devices <NUM>, <NUM>) used as part of the safety system <NUM> will be rated as safety devices, which typically means that these devices must go through a rating procedure to be rated by an appropriate body as a safety device.

The backplane <NUM> (indicated by a dashed line through the process controller <NUM>, the I/O devices <NUM>, <NUM>, <NUM>, and the safety controllers <NUM>, <NUM>) is used to connect the process controller <NUM> to the process control I/O cards <NUM>, <NUM>, <NUM> as well as to the safety controllers <NUM>, <NUM>. The process controller <NUM> is also communicatively coupled to the bus <NUM> and operates as a bus arbitrator to enable each of the I/O devices <NUM>, <NUM>, <NUM> and the safety controllers <NUM>, <NUM> to communicate with any of the workstations <NUM> or the memory device <NUM> via the bus <NUM>. The backplane <NUM> also enables the safety controllers <NUM>, <NUM> to communicate with one another and coordinate safety functions implemented by each of these devices, to communicate data to one another, or to perform other integrated functions.

The workstations <NUM> may each include a workstation processor <NUM> and a memory <NUM>. One or more control modules <NUM> and/or safety logic modules <NUM> may be stored on the memory <NUM> and may be capable of being executed by any of the processors <NUM>, <NUM>, <NUM> within the process plant <NUM>. In general, one or more of the modules <NUM>, <NUM> may be executed by one of the processors to control and/or monitor a process via one or more field devices <NUM>, <NUM>, <NUM>, <NUM>. A display module <NUM> is illustrated in an exploded view in <FIG> as being stored in the memory <NUM> of one of the workstations <NUM>. However, if desired, the display module <NUM> may be stored and executed in a different workstation <NUM> or in another computing device associated with the process plant <NUM>. The display module <NUM> may be any type of interface that, for example, enables a user to manipulate data values (for example, perform reads or writes) to thereby alter operation of the control <NUM> or safety modules <NUM> within either or both of the control system <NUM> and the safety system <NUM>. Thus, if a write is specified to be made to the control module <NUM> associated with the control system <NUM> or to one of the field devices <NUM>, <NUM>, for example, the display module <NUM> enables that write to take place. Additionally, if the write is specified to be made to the safety logic module <NUM> associated with the safety system <NUM> or to one of the field devices <NUM>, <NUM>, for example, the display module <NUM> enables that write to occur.

By and large, a control system includes a controller that is configured to respond to a target or an occurrence of an event trigger associated with a process condition. One or more control modules may be executed by one or more processors to monitor and/or control the process via one or more field devices. Process or safety information is attained by the field device and passed on to the controller wherein the controller may adjust the process, if necessary. For example, in a level control system, a controller may monitor the process for the occurrence of an event trigger relating to a liquid level exceeding an upper threshold limit within a holding tank. The controller may utilize a sensor to detect the position of a device such as a float or displacer situated within the liquid. Should the displacer exceed the upper threshold limit, the sensor will be tripped and related information may be provided to the controller. The controller may store and/or report the information to control personnel and/or adjust a set-point or position of another field device, such as a valve, to prevent liquid from entering the holding tank.

In some control systems, there may be one or more components that are required to move during normal operation, and yet some of these components may be normally inactive or idle during a significant portion of its operation. For example, the movable components associated with the detecting mechanism of a high-level sensor may be idle for a considerable amount of time if the liquid level rarely reaches the upper threshold limit. However, when the liquid level does rise to the upper threshold limit, there is a concern that the movable components of the sensor may not function properly due to the prolonged inactivity. To validate that the field device is available and to ensure its operability, a diagnostic check of the field device may be performed wherein the controller may simulate the occurrence of the event trigger to trip the sensor portion by moving the movable components of the field device. The periodic excitation of the movable components may protect against the sedentary nature of the high-level detecting field device and its normally "dry" state of operation. After excitation of the movable components of the field device, the controller may record the operation and take the necessary actions depending on the observed proper or improper result, such as recording and/or transmitting corresponding information associated with the diagnostic check and adjusting other field devices in the control system.

One example implementation of the present invention for validating the availability and operability of a field device <NUM> used in a control system <NUM> of a process plant is shown in <FIG>. In this implementation, the field device <NUM> is used to monitor and control a level of liquid in a holding tank <NUM>, which is shown in phantom lines in <FIG> and generally includes an inlet <NUM> and an outlet <NUM>. However, it is to be understood that any other type of field device having a movable portion, such as a valve or switch used for any other type of corresponding function, may be integrated with the system and method of the invention. The field device <NUM> includes a movable assembly <NUM> having an elongated member such as a bar or rod <NUM> operatively attached to a fulcrum <NUM>. A displacer or float device <NUM> is connected to the distal end of the bar <NUM>. The bar <NUM> moves or pivots about the fulcrum <NUM> in response to movement of the displacer <NUM>. A zero spring <NUM> may be attached to the proximate end of the bar <NUM> and may be used as desired by control personnel to adjust the field device <NUM> for operation with respect to the displacer's <NUM> characteristics and/or the expected operating environment.

The displacer <NUM> includes one or more characteristics, such as a mass, volume, and buoyancy, for example, and is situated within the liquid of the holding tank <NUM>. The displacer <NUM> is responsive to its operating environment and, in particular, to one or more properties or characteristics of the liquid, such as the level, viscosity, density, and temperature, for example. The displacer <NUM> essentially floats within the liquid held within the holding tank <NUM> and is adaptable to the fluctuating level of the liquid. The position of the displacer <NUM> within the liquid of the holding tank <NUM> is monitored by a processor <NUM> via a communication link or bus <NUM> and related information may be provided to control personnel at any of the workstations within the plant.

An actuator <NUM> is operatively connected to the movable assembly <NUM>. In the example embodiment shown in <FIG>, the actuator <NUM> is connected between the bar <NUM> and the control node <NUM>. The actuator <NUM> may be any type of device that is capable of imparting movement to the movable assembly <NUM>, such as to replicate movement of the displacer <NUM> resulting from a changing liquid level. The actuator <NUM> may be an electric, mechanical, or electromechanical device, such as a solenoid or electromagnet, for example. The processor <NUM>, which is coupled to the actuator <NUM> via the communication line or bus <NUM>, is capable of actuating the actuator <NUM> and facilitating movement of the displacer <NUM>.

Control modules <NUM>, which may include one or more diagnostic modules, are stored on a memory <NUM> that is communicatively coupled to the processor <NUM>. When executed on the processor <NUM>, the diagnostic module is capable of performing a diagnostic check, or a portion of a diagnostic check, on the field device <NUM>. For example, the diagnostic module may include: an actuating module <NUM> that facilitates actuating the actuator <NUM>, an exhibiting module <NUM> that facilitates exhibiting the result of the diagnostic check at an output device <NUM>, and an analyzing module <NUM> that may analyze and compare the results of one or more diagnostic checks. The diagnostic module includes commands or instructions that may be sent to the actuator <NUM>, via the processor <NUM>, to impart movement to the displacer <NUM>. The commands may be initiated by control personnel and discretely transmitted via the processor <NUM> as needed and/or the commands may be programmed for periodic transmission or in response to an event trigger, such as the passage of a period of inactivity for the field device <NUM>, for example. Control personnel may designate the time and/or the event trigger for executing the diagnostic check of the level control field device <NUM>, which may provide increased flexibility in maintaining the field device <NUM>. All formulations, comparisons, and determinations involving the diagnostic check and any subsequent response action may be administered through the cooperation of the control node <NUM>.

A sensor <NUM> is mechanically connected and/or operatively coupled to the movable assembly <NUM> in any desired configuration wherein the sensor is able to measure a quantity that is representative of a characteristic of the field device <NUM> and/or its operating environment. A characteristic of the field device <NUM> or the operating environment may include the level of the liquid, the viscosity of the liquid, the buoyancy of the liquid, the density of the liquid, the mass of the displacer, the weight of the displacer, or the buoyancy of the displacer, for example. The sensor <NUM> is capable of converting the measured quantity into a signal of information, which may be in the form of a mechanical signal or an electrical signal, such as an analog or digital voltage, for example.

In the example implementation shown in <FIG>, the sensor <NUM> is capable of measuring and/or detecting movement of the displacer <NUM> via the bar <NUM>, which may be mechanically connected or operatively coupled to the actuator <NUM>. Movement of the displacer <NUM> facilitated by the actuator <NUM> may therefore be detected by the sensor <NUM> via movement of the bar <NUM>. The movement of the displacer <NUM> may be measured and converted to information to be provided at an output of the sensor <NUM>. The information may be in the form of an electrical signal, such as an analog or digital voltage, or the position of a switch, for example, and is capable of being read by an observer or an operatively connected device, such as the processor <NUM>. The processor <NUM> may take further action in response to the information provided by the sensor <NUM>, and/or the information may be displayed visually and/or audibly at an output device <NUM> and/or stored on memory <NUM> within the control node <NUM>.

<FIG> depicts a flowchart <NUM> of an example method of the invention that may be used with the configuration shown in <FIG> where the operability and/or availability of the field device <NUM> can be validated on a discrete or periodic basis. In particular, the field device <NUM> can be checked to ensure that the displacer <NUM> is movable and capable of functioning properly. Movement of the displacer <NUM> is monitored by the processor <NUM> via the sensor <NUM> (block <NUM>). The output of the sensor <NUM> may include one or more states. For example, a first state may be associated with a portion of the field device <NUM> being at a first position, such as the displacer <NUM> being at a position below a predetermined level, while a second state may be associated with the displacer <NUM> being at a second position at or above the predetermined level. The actuator <NUM> is actuated via execution of an actuation module <NUM> by the processor <NUM> (block <NUM>). The actuation module <NUM> may be stored in one of the memory locations in the control system. After the actuator <NUM> is actuated by the processor <NUM>, the state of the sensor <NUM>, or whether the sensor has changed its state, is determined by the processor <NUM> (block <NUM>). If the sensor <NUM> has changed state, the processor <NUM> may execute a first command (block <NUM>). The first command may include recording the resultant state in one or more memory devices and/or exhibiting the result via execution of the exhibiting module <NUM>. The resultant state may be visually and/or audibly presented at the output device <NUM> of one or more user interfaces or workstations in the control system. Alternatively, if the sensor <NUM> has not changed state, the processor <NUM> may execute a second command (block <NUM>). The second command may include recording the resultant state in one or more memory devices and/or presenting the result visually and/or audibly, via the exhibiting module <NUM>, at the output device <NUM> of one or more user interfaces or workstations in the control system.

Another example embodiment of the invention for validating the operability and availability of a field device integrated in a control system is shown in <FIG>. The field device <NUM> in this example embodiment is used to monitor and control the level of liquid within a holding tank <NUM>, which is shown in phantom lines in <FIG> and generally includes an inlet <NUM> and an outlet <NUM>. However, it is to be understood that the field device may be any other type of field device having a movable portion, such as a valve or switch that may be integrated with the system and method of the invention. The field device <NUM> includes a movable assembly <NUM> having an elongated member such as a bar or rod <NUM> operatively attached to a fulcrum <NUM>. A displacer or float device <NUM> is connected to the distal end of the bar <NUM>. The bar <NUM> moves or pivots about the fulcrum <NUM> in response to movement of the displacer <NUM>. A zero spring <NUM> may be attached to the proximate end of the bar <NUM> and may be used to adjust the field device <NUM> with respect to the displacer's <NUM> characteristics and/or the expected operating environment.

An actuator <NUM> is operatively connected to the movable assembly <NUM> and may be connected between the bar <NUM> and the processor <NUM> of the control node <NUM>. The actuator <NUM> may be any type of device that is capable of imparting movement to the movable assembly <NUM>, which ultimately causes movement to the displacer <NUM>. The actuator <NUM> may be an electric, mechanical, or electromechanical device, such as a solenoid or electromagnet, for example. The processor <NUM>, which is coupled to the actuator <NUM> via a communication line or bus <NUM>, is capable of actuating the actuator <NUM> and facilitating movement of the displacer <NUM>.

Control modules <NUM>, which may include one or more diagnostic modules, are stored on a memory <NUM> that is communicatively coupled to the processor <NUM>. When executed on the processor <NUM>, the diagnostic module is capable of performing a diagnostic check, or a portion of a diagnostic check, on the field device <NUM>. For example, the diagnostic modules may include: an actuating module <NUM> that facilitates actuating the actuator <NUM>, an exhibiting module <NUM> that facilitates exhibiting the result of the diagnostic check at an output device <NUM>, and an analyzing module <NUM> that may analyze and compare the results of one or more diagnostic checks. The diagnostic module includes commands or instructions that may be sent to the actuator <NUM>, via the processor <NUM>, to impart movement to the displacer <NUM>. The commands may be initiated by control personnel and discretely transmitted via the processor <NUM> as needed and/or the commands may be programmed for periodic transmission or in response to an event trigger, such as the passage of an inactive period for the field device <NUM>, for example. Control personnel may designate one or more times or event triggers for executing the diagnostic check of the level control field device <NUM>, which may provide increased flexibility in maintaining the field device <NUM>. All formulations, comparisons, and determinations involving the diagnostic check and any subsequent response action may be administered through the cooperation of the control node <NUM>.

The operating environment and/or one or more characteristics of the displacer <NUM> may be monitored by the processor <NUM> via a sensor <NUM> mechanically connected and/or electrically coupled to the movable assembly <NUM>. The sensor <NUM> may be a discrete or digital sensor capable of receiving and/or taking one or more measurements of a quantity that is representative of the operating environment or one or more of the characteristics of the field device <NUM>. Alternately, the sensor <NUM> may be a proportional or analog sensor capable of continuously receiving and/or measuring a quantity or that is representative of the operating environment or one or more of the characteristics of the field device <NUM>. A characteristic of the field device <NUM> or the operating environment may include the level of the liquid, the viscosity of the liquid, the buoyancy of the liquid, the density of the liquid, the mass of the displacer, the weight of the displacer, or the buoyancy of the displacer, for example. The sensor <NUM> is capable of converting the received and/or measured quantity into a signal of information, which may be in the form of a mechanical signal or an electrical signal, such as an analog or digital voltage, for example.

The information provided by the sensor <NUM> may be analyzed by the control processor <NUM> to determine the operating condition of the displacer <NUM>. The analysis may include a comparison of standard information to information attained through the measurement. In addition, the analysis may include a comparison of information attained through several measurements taken at different times. The standard information and the information attained by measurement may be stored in the memory <NUM> of the control system. Depending on the result of the comparison, the control processor <NUM> may store the resultant analysis in memory <NUM> within the control system <NUM> and/or display the resultant analysis visually and/or audibly at the output device <NUM>.

In the implementation shown in <FIG>, the processor <NUM> is capable of actuating the actuator <NUM> to lift the displacer <NUM> out of the liquid. Upon the return of the displacer <NUM> to the liquid, the continuous sensor <NUM>, which may include a Hall effect sensor, may receive continuous measurements related to the displacer's <NUM> position within the liquid. More specifically, after returning back into the liquid, the displacer <NUM> will likely bob up and down, eventually arriving at a more steady position in the liquid. During this time, the sensor <NUM> may attain information related to the displacer's <NUM> bobbing, for example, the frequency, amplitude, dampening, and/or resonance of the bobbing displacer. This information may be related to the characteristics of the displacer <NUM> and/or the operating environment. The sensor <NUM> is capable of converting the information received from the movable assembly <NUM> into a representative signal to be provided as an output signal to the control processor <NUM>. The information of the representative signal may be stored in memory <NUM> and/or analyzed via the analyzing module <NUM> and compared against other related information stored in memory to determine if a change has occurred in the operating characteristic of the displacer <NUM> and/or the operating environment. The information may also be compared to an information standard to assist in determining whether one or more of the characteristics of the displacer are in proper working order or whether the operating environment has changed.

An analysis of the information may uncover that one or more characteristics of the displacer <NUM> have changed from its initial condition. Any change to the displacer's characteristics may affect the measurement capability and accuracy of the field device <NUM> and repair or replacement of the displacer <NUM> may be needed. For example, paraffin and other foreign substances have been known to attach to a displacer during use, which may affect the buoyant characteristics of the displacer. The change in the buoyant characteristic of the displacer may be deduced through an observed change in the frequency, amplitude, dampening, and/or resonance of the bobbing displacer.

The analysis of the information may also uncover that the operating environment of the displacer has changed from its initial condition. In particular, any change to the fluid within the holding tank <NUM> may be detectable by a change in respect to the initially measured characteristics of the displacer <NUM>. That is, if a different liquid was added to the holding tank <NUM>, a change in the viscosity, density, or grade of the liquid may be detectable by a change in the frequency, amplitude, dampening, and/or resonance of the displacer <NUM>. Thus, by knowing the characteristic property(ies) of the displacer <NUM> and the environment in which the displacer is expected to operate in, changes detected in any of the characteristic property(ies) of the displacer may represent a change in the operating condition of the displacer or the operating environment of the displacer, such as the level or density of the liquid.

<FIG> depicts a flowchart <NUM> of an example method of the invention capable of being utilized with the embodiment shown in <FIG> where the operability of the sensor <NUM> can be validated on a continuing basis via the proportional sensor <NUM>. In particular, the processor of the controller continuously monitors the field device via the proportional sensor (block <NUM>). The actuator <NUM> is actuated by the controller (block <NUM>) and the displacer <NUM> is lifted from the liquid and allowed to return to the liquid. A continuous signal is received at the sensor <NUM>, converted, and provided to the controller (block <NUM>) for analysis. The analysis may include comparing the most recently received output signal to a standard of information associated with the characteristics of the displacer and/or the displacer's operating characteristics, or the analysis may include comparing the most recently received output signal to a previously received output signal or a compilation of previously received output signals (block <NUM>). The controller <NUM> determines, via execution of the analyzing module on the processor <NUM>, whether a change occurred to the initially measured characteristics of the displacer (block <NUM>) and/or the operating environment. If there was a significant change to one or more of the displacer's characteristics and/or the operating environment, the processor <NUM> may execute a first command (block <NUM>). The first command may include recording this result in memory <NUM> and/or displaying the result visually and/or audibly at the user interface <NUM>. In addition, the first command may include displaying and/or logging an alarm associated with the changed signal. If there was not a sufficient change to the displacer's characteristics, the processor <NUM> may execute a second command (block <NUM>). The second command may include recording this result in memory <NUM> and/or displaying the result visually and/or audibly at one or more user interfaces within the control plant. Displaying the status of the device may be facilitated by one or more of the processors executing the indicating module.

Past validation techniques for liquid holding tanks incorporating level control field devices required control personnel to be present at the site of the field device. In addition, for holding tanks with integrated bridles, the level control system must be suspended while the bridle is removed, drained, refilled, and checked. It is apparent from the description above that the present invention is readily adaptable to existing electromechanical level control systems and is capable of providing a quick and accurate assessment of the components and operating environment of a remote field device without interruption to the control system and without the need for control personnel to be present at the site of the field device.

Although certain example methods, apparatus and articles of manufacture have been described herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus, and articles of manufacture fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents.

For example, the control system <NUM> may include, but is not limited to, any combination of a LAN, a MAN, a WAN, a mobile, a wired or wireless network, a private network, or a virtual private network. Moreover, while only two workstations are illustrated in <FIG> to simplify and clarify the description, it is understood that any number of workstations or user interfaces are supported and can be implemented.

Additionally, certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied on a machine-readable medium or in a transmission signal) or hardware modules. A hardware module is tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.

It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software), may be driven by cost and time considerations.

Accordingly, the term hardware should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where the hardware modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different hardware modules at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.

Hardware and software modules can provide information to, and receive information from, other hardware and/or software modules. Where multiple of such hardware or software modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the hardware or software modules. In embodiments in which multiple hardware modules or software are configured or instantiated at different times, communications between such hardware or software modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware or software modules have access. For example, one hardware or software module may perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware or software module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware and software modules may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).

Similarly, the methods or routines described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or processors or processor-implemented hardware modules. In some example embodiments, the processor or processors may be located in a single location (e.g., within a plant environment, an office environment, or as a server farm), while in other embodiments the processors may be distributed across a number of locations.

The one or more processors may also operate to support performance of the relevant operations in a "cloud computing" environment or as a "software as a service" (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs).

In some example embodiments, the one or more processors or processor-implemented modules may be located in a single geographic location (e.g., within a plant or office environment).

As used herein, an "algorithm" or a "routine" is a self-consistent sequence of operations or similar processing leading to a desired result. In this context, algorithms, routines and operations involve physical manipulation of physical quantities.

In addition, use of the "a" or "an" are employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the description. This description should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise.

Claim 1:
A float liquid level control system including a validation mechanism, the system comprising:
a fulcrum (<NUM>, <NUM>);
a movable assembly (<NUM>, <NUM>) including a bar (<NUM>, <NUM>), wherein the bar (<NUM>, <NUM>) of the movable assembly (<NUM>, <NUM>) including a proximate end and a distal end, and wherein the bar (<NUM>, <NUM>) is configured to pivot about the fulcrum (<NUM>, <NUM>); and
a float (<NUM>, <NUM>) attached to the distal end of the bar (<NUM>, <NUM>); and characterized by:
an actuator (<NUM>, <NUM>) that is operatively connected to the movable assembly (<NUM>, <NUM>) between the proximate end of the bar (<NUM>, <NUM>) and the fulcrum (<NUM>, <NUM>) and that is configured to impart movement to the movable assembly (<NUM>, <NUM>) to thereby move the float (<NUM>, <NUM>);
a processor (<NUM>, <NUM>) configured to actuate the actuator (<NUM>, <NUM>) to thereby move the float (<NUM>, <NUM>) via the movable assembly (<NUM>, <NUM>);
a sensor (<NUM>, <NUM>) including an input and an output, the input of the sensor (<NUM>, <NUM>) operatively coupled to the movable assembly (<NUM>, <NUM>) for receiving an input signal representative of a characteristic of the float (<NUM>, <NUM>), the output of the sensor (<NUM>, <NUM>) operatively coupled to the processor (<NUM>, <NUM>) for providing an output signal associated with the input signal;
a memory (<NUM>, <NUM>) coupled to the processor (<NUM>, <NUM>);
an actuating module (<NUM>, <NUM>) stored on the memory (<NUM>, <NUM>) and configured to be executed on the processor (<NUM>, <NUM>), thereby causing the processor (<NUM>, <NUM>) to actuate the actuator (<NUM>, <NUM>);
an output device (<NUM>, <NUM>) coupled to the processor (<NUM>, <NUM>); and
an exhibiting module (<NUM>, <NUM>) stored on the memory (<NUM>, <NUM>) and configured to be executed on the processor (<NUM>, <NUM>), thereby causing the processor (<NUM>, <NUM>) to exhibit the output signal of the sensor (<NUM>, <NUM>) on the output device (<NUM>, <NUM>).