Apparatus and method for assessing exceedance of a process beyond safe operating limits

Abstract

An apparatus and method implementable with a software application for checking or assessing exceedances process variables beyond safe operating limits is disclosed. The process has instruments, a process history database, and one or more external databases. The instruments measure process variables and can be associated with the equipment. The process history database stores a plurality of values of the process variables measured by the instruments. Data of the equipment, the associated instrument, and the safe operating limit for the equipment is defined in a limit sequence of the software application. Preferably, the data of the equipment, the instrument, and the safe operating limit is imported from the one or more external databases. The process history database is searched for one or more exceedance values that are measured by the defined instrument and that exceed the defined safe operating limit. The “apparent” exceedance values are then imported from the process history database into the software application. Finally, the user uses to software application to evaluate and validate the exceedance values.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is filed concurrently with U.S. patent application having Express Mail No. EV 277226575 US, Attorney Docket No. 319-0003US, and entitled “Apparatus and Method for Performing Process Hazard Analysis,” which is hereby incorporated by reference.

FIELD OF THE INVENTION

The subject matter of the present disclosure generally relates to an apparatus and method for assessing the history of a process and more particularly relates to a software application and databases implementable on a computer system for assessing measured exceedances of a process independent of the instruments and other devices used to prevent excursions.

BACKGROUND OF THE INVENTION

Referring to FIG. 1, a process 10 is schematically illustrated. A typical process 10 may have thousands of pieces of equipment 12, such as valves, vessels, pumps, pressure chambers, relief valves, etc., interconnected by piping 14. Each piece of equipment 12 can have several operating parameters, safeguards, overpressure scenarios, or the like. A Distributive Control System (DCS) 16 is typically used to monitor and control aspects of the process 10 automatically. The DCS 16 has a plurality of instruments 18 wired to the DCS 16. The instruments 18 are positioned along the process 10 and measure various process variables, such as pressure, temperature, flow, level, etc. The instruments 18 can be flow indicators, temperature sensors, pressure sensors, etc., which may or may not be associated with a piece of equipment 12. The DCS 16 typically uses instrument tags, which are numbers identifying particular instruments 18 in the process 10.

An Engineering Information Management (EIM) framework 20 is also typically used with the process 10. The EIM framework 20 has external applications 21 and a plurality of external databases 22-26, which store process information on a computer or network. The external applications 21 can include, but are not limited to, Lotus Notes, Microsoft Access, DOC 3000 by Plant Automation Services Inc., and Uniformance Process History Database (PHD) by Honeywell, Inc. Briefly, DOC 3000 is Windows-based software and is a data import tool for the Honeywell TPS and TDC3000 systems. Uniformance PHD by Honeywell, Inc. is also based on Microsoft technologies. Uniformance PHD provides data collection, data storage, historization, and visualization for process environments. The external databases 22-25 typically include an equipment database 22, a drawing database 23, a safe operating limit database 24, and a process history database 25. In the process industry, there is no standard structure for such databases, and the databases 22-25 can have a variety of different information depending on the process 10 or particular implementation.

The equipment database 22, which can be created in Lotus Notes, stores details about equipment 12 used in the process 10. For example, the equipment database 22 typically contains equipment numbers or tags and descriptions of the equipment 12. The equipment tags can identify a specific piece of equipment 12 or can provide the functional location of the piece of equipment 12 in the process 10. The drawing database 23, which can be created in Lotus Notes, stores details of the drawings of the process 10. For example, the drawing database 23 can contain drawing numbers of the process 10, revision dates, and descriptions or titles of the drawings.

The safe operating limit (SOL) database 24, which can be created in Lotus Notes or Microsoft Access, stores details of safe operating limits for the process 10, such as the maximum or minimum pressure, temperature, levels, flow rates, compositions, etc. In the database 24, the safe operating limits are typically associated with the instrument tags of the instruments 18 used to measure the limits. In addition, the safe operating limits in the database may be associated with equipment 12 that should not exceed a specific safe operating limit.

Process standards and the Occupational Safety and Health Administration (OSHA) § 1910.119(d)(2) (29 C.F.R. § 1910.119) require that a process maintains safe upper and lower limits for various process variables and require that operators evaluate the effects of exceedances from such process variables. As noted previously, a safe operating limit (SOL) is a set limit for any operating variable, the exceedance of which has the potential of causing a hazardous situation in the process 10. Safe operating limits are established for all pressurized or otherwise potentially hazardous equipment 12 of the process 10. A safe operating limit can be inherent to the design of a piece of equipment 12. Also, a safe operating limit can be dictated by the process 10 and the interdependence of the process equipment 12. Examples of safe operating limits can include, but are not limited to, maximum allowable working temperature (MAWT), maximum allowable working pressure (MAWP), safe upper temperature limit (SUTL), safe lower temperature limit (SLTL), safe upper pressure limit (SUPL), safe lower pressure limit (SLPL), and the like. Other safe operating limits may also be established for operating variables as required and can include excess speed for steam turbines or minimum flow for pumps.

Software packages for recording the history of a process are known in the art. Process history software is primarily directed to providing a log of process history conditions or values of process variables. Process history software records process variables measured from the various instruments 18 and stores the measurements in a process history database 25. The process variables are typically recorded at regular, predefined intervals (e.g., every minute) in the process history database 25. Typically, the process history database 25 holds a considerable amount of recorded data that is maintained for years. The process history database can be used to compare operation of the process during different time periods. If an incident does occur, the process history database can be used to investigate the event. The data in the process history database 25 typically includes instrument tags of the instruments 18, time entries for each measurement, and values of the process variables measured by the instruments 18. One example of process history software includes PHD by Honeywell, which stores data in an Oracle database.

To monitor and maintain the operating conditions of the process 10, the DCS 16 uses alarms, pressure relief valves, safety shutdowns, or other safeguards for the process 10. For example, alarms can be triggered when a process variable measured by an instrument 18 exceeds a predefined operating limit. When the alarm is triggered, the DCS 16 may automatically respond by opening a valve or performing some other action. Alternatively, the operators may take specific action when an alarm is triggered.

Software packages for storing the event history of the DCS 16 are also known in the art. The event history software creates a log of various DCS events, such as alarm events, triggered safeguards, alarm set point changes, alarm responses, etc. Examples of event history software includes Process Guard software by Matricon Pty. Ltd., Event Logger by Nikos, Inc., and AMO Suite™ by Plant Automated Systems. Event history software allows operators to review logs of triggered events, alarms, or other safeguards of the process 10. For example, for frequent alarms, which are often referred to as nuisance alarms, the operators can review the log and fix any setpoints if necessary.

Industry personnel may improperly assume that the number of triggered alarms or other safeguards offer a measure of the safety of the process 10. However, the process 10 typically has a large number of alarms or other safeguards, and some alarms or safeguards may be unnecessary, may be improperly set, or may be inadvertently omitted. Thus, the number of triggered alarms or other safeguards may represent an improper estimate of the safety of the process 10. Therefore, a need exists in process industries for software that can be used to monitor a process 10 proactively and to determine whether the process 10 is legitimately operating safely with respect to actual equipment and process limits, independent of safeguards, and before an incident occurs.

The subject matter of the present disclosure is directed to overcoming, or at least reducing the effects of, one or more of the problems set forth above.

SUMMARY OF THE PRESENT DISCLOSURE

An apparatus and method implementable with a software application for checking or assessing exceedances of process variables outside of safe operating limits is disclosed. The process has instruments, a process history database, and one or more external databases. The instruments measure process variables and can be associated with the equipment. The process history database stores a plurality process variables measured by the instruments. Data of the equipment, the associated instrument, and the safe operating limit for the equipment is defined in a limit sequence of the software application. Preferably, the data of the equipment, the instrument, and the safe operating limit is imported from the one or more external databases. The process history database is searched for one or more exceedance values that are measured by the defined instrument and that exceed the defined safe operating limit. The “apparent” exceedance values are then imported from the process history database into the software application. Finally, the user uses the software application to evaluate and validate the exceedance values. For example, the software application allows the user to determine whether the correct instrument tag is assigned to the equipment or portion or the process, whether the correct safe operating limit is assigned to the instrument or process variable, or whether the exceedance is legitimate and requires further investigation or updating.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing summary, preferred embodiments, and other aspects of subject matter of the present disclosure will be best understood with reference to a detailed description of specific embodiments, which follows, when read in conjunction with the accompanying drawings, in which:

FIG. 1 schematically illustrates a process, a Distributive Control System, and an Engineering Information Management (EIM) Framework according to the prior art.

FIG. 2 schematically illustrates an embodiment of an exceedance checker according to certain teachings of the present disclosure in relation to the system of FIG. 1.

FIG. 3 illustrates a flowchart showing steps for performing an analysis of exceedances beyond safe operating limits using the disclosed exceedance checker.

FIG. 4 illustrates an embodiment of a reporting screen of the disclosed exceedance checker.

FIG. 5 illustrates a screen listing limit sequences having the same equipment.

FIG. 6 illustrates an embodiment of a graphing screen of the disclosed exceedance checker.

FIG. 7 illustrates an embodiment of a validation screen of the disclosed exceedance checker.

While the disclosed exceedance checker and validation techniques are susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and are herein described in detail. The figures and written description are not intended to limit the scope of the inventive concepts in any manner. Rather, the figures and written description are provided to illustrate the inventive concepts to a person skilled in the art by reference to particular embodiments, as required by 35 U.S.C. § 112.

DETAILED DESCRIPTION

A. Overview

Referring to FIG. 2, an embodiment of an exceedance checker 50 according to certain teachings of the present disclosure is schematically illustrated. The exceedance checker 50 is used in relation to a process 10, a Distributive Control System (DCS) 16, and databases 22-25 of an EIM Framework 20, which are discussed above. As noted above, the DCS 16 has instruments 18, which measure operating variables of the process 10. The external databases 22-24 store data on the equipment 12, instruments 18, drawings, and safe operating limits of the process 10. Furthermore, the process history database 25 stores a history of process variables measured by the instruments 18.

The exceedance checker 50 allows a user to import data from the databases 22-25 and to store the imported data in an exceedance database 52. In one embodiment, the exceedance checker 50 is implemented in Visual Basic, and the exceedance database 52 is formatted in Microsoft Access 2000. However, it will be appreciated that the exceedance checker 50 and database 52 can be created by other techniques for creating a computer software application and database.

With the exception of the process history database 25, the other databases 22-24 are preferably relational databases where data is organized as sets of formally described tables from which data can be accessed or reassembled in many different ways without having to reorganize the database tables. By importing data from these databases 22-24, the user can readily access the data while using the exceedance checker 50. Features available in Visual Basic, Microsoft Access, or other programs can be used to import the data into the exceedance databases, and the interface for importing data from the relational databases 22-24 is preferably a structured query language (SQL). For example, ActiveX® Data Objects (ADO), which is a programming language for interacting with databases, can be used by the exceedance checker 50 to access data in the external databases 22-24. ADO can be used with databases created by Microsoft Access, Lotus Notes, DOC 3000, and Uniformance. In addition, Lotus NotesSQL, which is an ODBC (Open Database Connectivity) driver for Notes and Domino, can read, report, and update information that is stored in Domino databases (“.nsf” files).

In addition to importing data from databases 22-24, the exceedance checker 50 allows the user to search the process history database 25 and to import process history data into the exceedance database 52. Using the exceedance checker, the user searches the process history database 25 for measured process variables that exceed defined safe operating limits. When searching, the exceedance checker 50 preferably uses the instrument tags of the instruments 18 imported from the databases 22-24. The exceedance checker 50 can use ADO or Visual PHD to search and import data in the process history database 25. Moreover, the exceedance checker 50 can use standard trend, query, and extract tools known in the art for retrieving process history data with Visual Basic or Visual Basic for Applications using ActiveX components.

After searching the process history database 25 and importing data on apparent exceedances, the exceedance checker 50 allows the user to assess and validate the apparent exceedances imported. For example, the apparent exceedances can be organized and validated using graphical user interfaces of the exceedance checker 50. Ultimately, the exceedance checker 50 allows the user to eliminate spurious exceedances and investigate valid exceedances.

Referring to FIG. 3, a flowchart 60 shows some steps for assessing and validating exceedances beyond safe operating limits using the disclosed exceedance checker. The following steps are meant to be illustrative. It is understood that not all of the steps need to be performed and that the steps need not be performed in the particular order given.

Instruments first measure process variables, such as pressure, temperature, or level, at specific points in the process (Step 62). An external application, such as Uniformance PHD, stores the measured process variables in a process history database (Step 64). Next, the user searches the process history database with the disclosed exceedance checker and imports process variables exceeding a defined safe operating limit and measured by a particular instrument of the process (Step 66). Because the process history database (25; FIG. 2) typically contains a substantially large amount of data, the exceedance checker preferably searches for exceedances in the process history database according to an algorithm before importing data. Details of the algorithm are described in more detail with reference to FIG. 4.

Once imported, the data from the database generally corresponds to an “apparent” exceedance of the process variable. Therefore, the user determines whether the apparent exceedance is valid using the disclosed exceedance checker (Step 68). If the user determines that the apparent exceedance is valid, the user records information about the valid exceedance within the exceedance checker. Then, the user can perform standard investigative techniques to correct the process, equipment, instruments, or safe operating limits (Step 70). Standard investigative techniques may involve investigating the process to determine why the exceedance occurred, re-evaluating the equipment or instruments, resetting the safe operating limits, or performing other steps.

If the user determines that the apparent exceedance is invalid, the user records information about the invalid exceedance within the exceedance checker. Then, the user determines whether the exceedance checker needs to be revised (Step 72). The exceedance checker may need to be revised, for example, if the wrong instrument tag for measuring a safe operating limit has been improperly associated with a piece of equipment. In addition, the exceedance checker may need to be revised if the wrong safe operating limit has been assigned to a piece of equipment or instrument. If necessary, the exceedance checker allows the user to revise the instrument tag, safe operating limit, process variable, etc. (Step 74). For example, the user can change parameters, values, or filters defined in the exceedance checker and then search the process history database again for exceedances. Monitoring the safe operating performance with the exceedance checker can then be ended once actual exceedances have been investigated, illegitimate exceedances have been invalidated, or the exceedance checker has been revised (Step 76).

B. Embodiment of Exceedance Checker

FIGS. 4 through 7 illustrate an embodiment of an exceedance checker according to certain teachings of the present disclosure. The disclosed exceedance checker is implemented as a software application having a graphical user interface (GUI). Accordingly, the exceedance checker includes a plurality of GUI screens 100, 108, 160, and 200, which allow a user to perform various tasks. In general, the tasks include defining data on the equipment, the instruments, and the safe operating limits of the process; searching and importing data in the various databases (22-25, FIG. 2); and validating apparent exceedances obtained from the process history database (25, FIG. 2). The screens 100, 108, 160, and 200 described below with reference to FIGS. 4 through 7 have some of common features of graphical user interfaces, such as menu bars, record navigation buttons, and scroll bars. These and other common features of a graphical user interface are not described in the following screens and may simply be omitted from the FIGS. 4 through 7 for clarity.

1. Obtaining Exceedances with the Exceedance Checker

Referring to FIG. 4, a reporting screen 100 of the exceedance checker allows the user to obtain and input data on apparent exceedances from the process history database.

Only one limit sequence is displayed on the screen 100. The limit sequence corresponds to a session for obtaining exceedances of a process variable for a given time period. Each limit sequence is given a number, as shown in the LimitSeq field 106, and a time stamp field 107 (“LastCheck TS”) for indicating the date of the last exceedance check. This number enables the user to organize the various limit sequences performed on the process.

a. Defining Equipment, Safe Operating Limits, and Instruments

Before obtaining exceedances from the process history database, the user defines equipment of the process to be assessed, the instrument for measuring the process variable, and the safe operating limit for the process variable. To that end, the reporting screen 100 includes equipment fields 110 and safe operating limit fields 120. The equipment fields 110 define information on the equipment, such as SAP equipment number, related documents, name, description, type, and flowsheet. The SOL fields 120 define information on the instrument and the safe operating limit, such as type of SOL, instrument tag name, value for SOL, high/low range, exceedance limit value, and maximum or minimum measured values. The exceedance limit value (“Limit”) is typically a more conservative value between the “SOL Type” and the “Range Hi/Lo.” Preferably, the fields 110 and 120 are populated from data imported into the exceedance checker from external databases (22-24; FIG. 2), but the screen 100 may also allow free text entry of information in these fields 110 and 120.

In addition to fields 110 and 120 for defining information, the reporting screen 100 allows the user to review related limit sequences having similar information. For example, a text field 130 allows the user to enter other tags of other instruments related to the instrument of the present limit sequence. Furthermore, buttons 112 allow the user to view other limit sequences having the same entry within the given field 110 or 120 next to the button 112. (FIG. 5 shows a screen 108 displaying limit sequences stored in the exceedance checker database that have the same piece of equipment number.) Moreover, buttons 114 allow the user to view drawings defined in some of the fields 110 and 120. To access and view the drawings, the exceedance checker preferably uses VoloView by AutoDesk, which is a program for viewing CAD drawings.

b. Searching the Process History Database for Exceedances and Importing Apparent Exceedances

Once information on the equipment, safe operating limit, and instrument tag has been defined in fields 110 and 120, an action button 102 (“Check SOLs”) allows the user to search data in the process history database (25, FIG. 2) and import apparent exceedances. In particular, the exceedance checker searches the process history database for exceedances measured by the defined instrument tag (“InstTagName”) beyond the defined safe operating limit or instrument limit (“Limit Value”). Field 104 (“Only Show SOLs with Exceedances since [DATE]”) allows the user to limit the search of the process history database beyond a specified date. After finding “apparent” exceedances, the exceedance checker imports the data from the process history database (25, FIG. 2) and displays the “apparent” exceedances as exceedance records 142 in a table 140.

Because the process history database typically contains a substantial amount of data, the exceedance checker preferably uses an algorithm to search the process history database for exceedances. Beyond the date defined in field 104 (if any), the exceedance checker searches for values that are measured by the defined instrument tag and that exceed the defined SOL limit. When an interval of exceedance values is encountered, the exceedance checker preferably calculates an average value over a duration of the apparent exceedance. Ultimately, the exceedance checker displays the start, end, duration, and average exceedance value in columns of the table 140. Although the average values of the exceedances are calculated and displayed on the screen 100, discrete values of the apparent exceedances are preferably stored in the exceedance database (52, FIG. 2) for merging records 142, graphing the exceedances, and other purposes described herein.

The duration of some of apparent exceedances in the records 142 may be very long, indicating a potentially sustained problem. On the other hand, the duration of some apparent exceedances in the records 142 may be relatively short and may be as short as the time interval for making measurements. Very short durations may be the result of hysteresis in the process, an improperly defined safe operating limit, a damaged instrument, or other issue. Due to these issues, a large number of exceedance records 142 may be repeatedly reported in short succession to one another in the table 140. Therefore, the exceedance checker is preferably capable of ignoring or combining such short, repeated apparent exceedances when searching the process history database.

In one embodiment when performing the searching algorithm, the exceedance checker can automatically merge or combine adjacent exceedances found in the process history database that are only separated by a predefined interval. For example, if the checker locates a first exceedance spanning two hours and locates a second exceedance spanning thirty minutes but only separated from the first exceedance by two minutes, the exceedance checker can combine the two time spans and average all of the measured values to produce a “single” exceedance record 142 for the table 140. In addition, for example, if the checker locates fifteen separate exceedances spanning several minutes apiece but only separated from each other by one minute, the exceedance checker can combine the time spans and average all of the measured values to produce a “single” exceedance record 142 for the table 140. In addition to automatically merging adjacent exceedances, the user can manually merge records 142 by selecting adjacent records 142 and using a merge button 150. In addition to merging records, a record 142 can be separated or unmerged into separate records using the exceedance checker. For example, a record 142 (having data values in a given interval) can be automatically or manually separated or unmerged into a plurality of separate records 142 (having separate portions of the data values in separate portions of the given interval).

2. Viewing Exceedances

After importing the apparent exceedances, the user can view a graph of the measured values. Graph button 152 pulls up a graphing screen 160 shown in FIG. 6. The graphing screen 160 shows information 162 populated from the selected exceedance record (142; FIG. 4). In addition, a graph 164 shows the measured values 166 for the apparent exceedance in conjunction with the defined SOL limit 168. The exceedance checker preferably uses Visual PHD to produce the graph 164.

3. Evaluating the Exceedances

Once apparent exceedances are imported from the process history database, the exceedance checker includes tools for the user to assess and validate the apparent exceedances. For example, the table (140; FIG. 4) in the present embodiment includes columns for marking the apparent exceedance as invalid, for showing the reasons the user has determined the exceedance record as being invalid, and for showing any follow-up action required to investigate a valid exceedance. A comment button 154 pulls up a validation screen shown in FIG. 7 for entering information for these columns. In FIG. 7, the validation screen 200 includes complementary records 202 for each of the exceedance records (142; FIG. 4). The records 202 each include validation fields 210, follow-up fields 220, and standard editing buttons 206.

The validation fields 210 allow the user to enter comments on the record 202 and to mark the record 202 as “Valid,” “Invalid,” or “Unknown.” For invalid exceedance records 202, predetermined reasons can be chosen to indicate why the exceedance is actually invalid. In one embodiment, the predetermined reasons can include “Incorrect Limit-Instrument Range,” “Incorrect Limit-SOL,” Incorrect Reading,” and “Wrong Instrument Tag.” When analyzing the history of a process, the user may use these and other predefined reasons for invalidating an apparent exceedance measured from the process.

By way of example, the exceedance may be invalid because the safe operating limit has been defined in the exceedance checker largely outside the instrument's range. Thus, the exceedance record is based on an erroneous instrument range, and the user may infer that an actual safe operating limit was never reached. By way of another example, the safe operating limit for a process variable may be incorrectly set. Alternatively, the instrument reading may be incorrect because the instrument measures a different process variable than required by the safe operating limit. The defined instrument tag may be wrong, for example, because the instrument tag defined in the exceedance checker does not actually measure the operating condition of the process or designated piece of equipment.

The follow-up fields 220 allow the user to enter comments for follow-up on a valid record 202 by providing predefined options, such as a follow-up type dropdown, a status dropdown, and start and end fields. These fields 220 allow the user to track any follow-up investigations required on invalid and legitimate exceedances. In one embodiment, the predefined follow-up options in the dropdown can include “Investigate Exceedance,” “Check Instrument Name Tag,” “Check Instrument Range,” “Reconfigure and Reprocess,” and “Maintain Instrument.” When analyzing the process hazard history of a process, the user may use these and other predefined follow-up options for investigating invalid and legitimate exceedances.

By way of example, investigating the exceedance can be selected when the exceedance appears valid and the user must investigate why the exceedance occurred. Checking the instrument tag can be selected when the assigned instrument tag does not appear to correspond with the piece of equipment to which it is associated. Checking the instrument range can be selected when the instrument range is frequently exceeded and further investigation is required. Reconfiguring and reprocessing can be selected when the exceedance appears invalid and the user must correct the safe operating limit and recheck for exceedances. Finally, maintaining the instrument can be selected when the instrument reading appears incorrect and the instrument needs replacement.

4. CONCLUSION

The exceedance checker allows a user to import data from existing databases of an EIM Framework, search a process history database for apparent exceedances, import the apparent exceedances from the process history database, display and organize the apparent exceedances, and validate and comment on the apparent exceedances. After validating exceedances and entering comments and any follow-up options for the exceedances, the user can disregard invalid exceedances, investigate why an exceedance is invalid, investigate causes of valid exceedances, and revise the exceedance checker as necessary.

The foregoing amply illustrates to a computer programmer of skill how to make and use the disclosed exceedance checker and its accompanying user interfaces and other functional aspects. Therefore, programming such accompanying user interfaces and other functional aspects would be a routine matter to a computer programmer of skill and can be accomplished with many different programming languages and within the context of many different operating systems. Of course, the exceedance checker disclosed herein would be ultimately coded into a computer code and stored on a computer-readable media, such as a compact disk, a tape, stored in a volatile or non-volatile memory, etc.

The foregoing description of preferred and other embodiments is not intended to limit or restrict the scope or applicability of the inventive concepts conceived of by the Applicant. In exchange for disclosing the inventive concepts contained herein, the Applicant desires all patent rights afforded by the appended claims. Therefore, it is intended that the appended claims include all modifications and alterations to the full extent that they come within the scope of the following claims or the equivalents thereof.

Claims

1. A method implementable on a computer system for assessing a process, the process having equipment and having an instrument for measuring a process variable, the computer system having access to a process history database storing a process variable measured by the instrument, the method comprising:

(a) electronically importing information indicative of the instrument and information indicative of a safe operating limit of the process variable from at least one external database to create a reporting record;

(b) electronically searching the process history database for data values of the process variable outside of the safe operating limit;

(c) electronically importing the data values from the process history database into the reporting record; and

(d) evaluating the data values by updating the reporting record.

2. The method of claim 1, wherein step (a) further comprises limiting the search of the process history database according to a defined time.

3. The method of claim 1, further comprising calculating an average of the data values in an interval.

4. The method of claim 1, further comprising electronically merging data values from a first interval with data values in a second interval.

5. The method of claim 4, wherein electronically merging comprises automatically merging the data values when the intervals occur within a predefined separation of time.

6. The method of claim 1, further comprising electronically separating the data values in a given interval into a plurality of portions of the data values in separate portions of the given interval.

7. The method of claim 1, wherein evaluating the data values comprises electronically accessing other data values corresponding to the same equipment, instrument, or safe operating limit.

8. The method of claim 1, wherein evaluating the data values comprises electronically accessing a drawing of the process having the equipment or instrument.

9. The method of claim 1, wherein evaluating the data values comprises validating the process variable, the equipment, the instrument, or the safe operating limit associated with the data values.

10. The method of claim 9, wherein validating the process variable, the equipment, the instrument, or the safe operating limit associated with the data values comprises selecting predefined validation criteria.

11. The method of claim 10, wherein the predefined validation criteria includes reasons indicating that the instrument or the safe operating limit is incorrectly set or defined in the search of the process history database.

12. The method of claim 9, wherein validating the process variable, the equipment, the instrument, or the safe operating limit associated with the data values comprises selecting predefined follow-up actions.

13. The method of claim 12, wherein the predefined follow-up actions include actions directed to: (i) investigating the equipment or the instrument, (ii) verifying an electronic tag of the instrument, (iii) verifying a range of the instrument, or (iv) changing the instrument or the safe operating limit and researching the process history database.

14. A method implementable on a computer system for assessing a process, the process having equipment and having an instrument for measuring a process variable, the computer system having access to a process history database storing a process variable measured by the instrument, the method comprising:

(a) entering information indicative of the instrument and information indicative of a safe operating limit of the process variable into a reporting record;

(b) using the information indicative of the instrument and information indicative of the safe operating limit to electronically search the process history database for data values of the process variable outside of the safe operating limit;

(c) electronically importing the data values from the process history database into the reporting record; and

(d) evaluating the data values by manually updating the reporting record with information regarding actions to be taken with respect to the data values.

15. The method of claim 14, wherein step (a) comprises electronically importing information indicative of the instrument and information indicative of a safe operating limit of the process variable from at least one external database to create a reporting record.

16. The method of claim 14, wherein step (b) further comprises limiting the search of the process history database according to a defined time.

17. The method of claim 14, further comprising calculating an average of the data values in the interval.

18. The method of claim 14, further comprising electronically merging data values from a first interval with data values in a second interval.

19. The method of claim 18, wherein electronically merging data values comprises automatically merging the data values when the intervals occur within a predefined separation of time.

20. The method of claim 14, further comprising electronically separating the data values in a given interval into a plurality of portions of the data values in separate portions of the given interval.

21. The method of claim 14, wherein evaluating the data values comprises electronically accessing other data values corresponding to the same equipment, instrument, or safe operating limit.

22. The method of claim 14, wherein evaluating the data values comprises electronically accessing a drawing of the process having the equipment or instrument.

23. The method of claim 14, wherein evaluating the data values comprises validating the process variable, the equipment, the instrument, or the safe operating limit associated with the data values.

24. The method of claim 23, wherein validating the process variable, the equipment, the instrument, or the safe operating limit associated with the data values comprises selecting predefined validation criteria.

25. The method of claim 24, wherein the predefined validation criteria includes reasons indicating that the instrument or the safe operating limit is incorrectly set or defined in the search of the process history database.

26. The method of claim 23, wherein validating the process variable, the equipment, the instrument, or the safe operating limit associated with the data values comprises selecting predefined follow-up actions.

27. The method of claim 26, wherein the predefined follow-up actions include actions directed to: (i) investigating the equipment or the instrument, (ii) verifying an electronic tag of the instrument, (iii) verifying a range of the instrument, or (iv) changing the instrument or the safe operating limit and researching the process history database.

28. A computer-readable medium having instructions to perform a method implementable on a computer system for assessing a process, the process having equipment and having an instrument for measuring a process variable, the computer system having access to a process history database storing the process variable measured by the instrument, the method comprising:

(a) electronically importing information indicative of the instrument and information indicative of a safe operating limit of the process variable from at least one external database to create a reporting record;

(b) electronically searching the process history database for data values of the process variable outside of the safe operating limit;

(c) electronically importing the data values from the process history database into the reporting record; and

(d) evaluating the data values by updating the reporting record.

29. A computer-readable medium having instructions to perform a method implementable on a computer system for assessing a process, the process having equipment and having an instrument for measuring a process variable, the computer system having access to a process history database storing the process variable measured by the instrument, the method comprising:

(a) entering information indicative of the instrument and information indicative of a safe operating limit of the process variable into a reporting record;

(b) using the information indicative of the instrument and information indicative of the safe operating limit to electronically search the process history database for data values of the process variable outside of the safe operating limit;

(c) electronically importing the data values from the process history database into the reporting record; and

(d) evaluating the data values by manually updating the reporting record with information regarding actions to be taken with respect to the data values.