Quality Review Management System

Abstract

To provide quality review management systems that enable advanced quality review procedures with respect to operations of plants, processes, batches, and other activities implemented in manufacturing plants.SOLUTION: A quality review management system includes: a rule DB 124 which stores exception rules 152; a data source which transmits collected process data; an exception engine 122 which determines whether or not an exception exists using the exception rules, generates an exception record upon identifying an exception, and stores the exception record in the exception DB; a plug-in which analyzes data from an external source, transmits external information of the external source to the exception engine, detects a further exception based on the external information, generates a further exception record, and stores the record on the exception DB, the plug-in being connected to communicate with the external source and the exception engine; and a quality review management system 112 which reviews the exceptions or further exceptions identified by the exception engine and stored in the exception DB as the exception records and the further exception records.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] Related Applications This application claims the benefit under 35 U.S.C. §119(e) of U.S. Provisional Application No. 62 / 659,325, filed April 18, 2018, entitled "Quality Review Management System," the entire disclosure of which is expressly incorporated herein by reference.

[0002] The present invention relates generally to manufacturing control systems, and more particularly to a quality review control system that enables advanced quality review procedures regarding the operation of plants, processes, batches, and other operations performed in a manufacturing plant. [Background technology]

[0003] A manufacturing plant, such as a processing plant, typically produces one or more products from a set of raw or pre-processed materials. Often the products produced should be of a particular quality or must be manufactured according to one of a variety of different quality standards to meet customer requirements, industry standards, Food and Drug Administration (FDA) requirements, safety requirements, labeling requirements, etc. Often separate quality reviewers are tasked with performing various tasks associated with ensuring that the products produced meet a pre-established set of standards or requirements or have been manufactured to a particular standard. Such tasks may include reviewing the state or values ​​of various parameters of the manufacturing equipment, materials, or processes used to manufacture the product to ensure that the proper manufacturing steps were performed, that the product was manufactured under various desired conditions, such as within a particular temperature range, PH range, pressure range, etc. Naturally, these quality review tasks depend on the type of product being manufactured, the manufacturing process or equipment used to manufacture the product, the quality standards being met, etc. Quality review is therefore a highly specialized activity in many manufacturing environments, requiring in-depth knowledge of the product, the manufacturing process, and the quality standards.

[0004] As an example, batch processes are typically used to manufacture various types of food or pharmaceutical products that are highly regulated by various food and pharmaceutical industries or organizations, such as the FDA. The specific process steps and conditions under which these products are manufactured are typically established or regulated in some manner to ensure the safety of the product produced or to ensure that the product meets certain labeling standards (e.g., the product is gluten-free, kosher, etc.). As an example, the process steps used to manufacture the product may require or mandate that certain process steps are performed on raw or intermediate materials during the manufacturing process, that certain cleaning procedures are performed on process equipment within or between manufacturing steps of the manufacturing process, that various parameters, such as temperature, pressure, PH balance, etc., are maintained within certain ranges or above or below certain thresholds throughout the process or at critical times in the process, etc. As a result, product manufacturers often need to collect and store data regarding the actual operation of manufacturing equipment during the manufacturing process so that they can prove to regulators or customers that the product produced meets appropriate quality standards, e.g., that the product was produced according to or under pre-established procedures or conditions.

[0005] Process plants used to manufacture various types of products, such as food, oil, pharmaceuticals, etc., are generally complex and highly automated. In particular, industrial process plants, such as those used for chemical, oil refining, food production, pharmaceutical manufacturing, or other processes, generally include one or more process control networks having centralized or distributed process controllers communicatively coupled to one or more field devices, which may be, for example, valve positioners, switches, sensors (such as temperature, pressure, and flow sensors), tanks, mixers, heaters, etc. These field devices or field equipment may perform physical control functions within the process plant (such as opening and closing valves, stirring or mixing materials in tanks, heating containers, etc.), may take measurements within the process plant for use in controlling the operation of the process plant, or may perform any other desired function within the process plant. Process controllers have historically been connected to the field devices via one or more analog signal lines or buses, which may carry, for example, 4-20 mA (milliamp) signals to or from the field devices. However, in the past few decades, the process control industry has developed a number of standard, open, digital, or mixed digital and analog communication protocols that can be used to effect communication between process controllers and field devices, such as Foundation® FIELDBUS (hereinafter "Fieldbus"), HART®, PROFIBUS®, WORLDFIP®, Device-Net®, and CAN protocols. Generally speaking, a process controller receives signals indicative of measurements made by and / or other information about one or more field devices and uses this information to implement typically complex control routines and generate control signals that are sent over signal lines or buses to the field devices, thereby controlling the operation of the process plant.

[0006] Certain types of process control networks, such as those used in batch processes, typically include multiple replicated equipment sets, each designed to have the same or similar hardware performing essentially the same basic functions within the processing plant. Thus, for example, a cookie manufacturing plant may have multiple mixing equipment sets, multiple baking equipment sets, and multiple packaging equipment sets, with some or all of the individual mixing equipment connected to operate in parallel and in series with some or all of the baking and packaging equipment. In such systems, the same general control algorithm or routine is typically used to control the operation of any particular replicated equipment set to produce the same product (as defined by a particular batch recipe). Thus, any particular batch run, defined by instructions specifying or identifying a particular quantity of a particular type of product to be produced, may be performed on any combination of a variety of different equipment sets within the plant. Typically, each such batch run or instruction includes a specific control procedure that sequentially executes a number of different steps or stages for implementing the recipe, such as finishing a first stage before starting a second stage. Thus, in the cookie manufacturing plant described above, a batch run or instruction may implement a batch control procedure to control the mixing equipment, then implement a procedure to run the baking equipment on the products produced by the mixing equipment, and then execute a third procedure to control the packaging equipment to package the products produced by the baking equipment, with each step taking a finite amount of time. Often, a batch run also implements procedures such as cleaning, emptying, and filling tanks or other containers or equipment in the plant as part of each instruction. Of course, each instruction may have a different set of specifications, which may require a different set of raw materials, different recipes to be implemented on the raw materials, different flow or batch procedures, and even different quality standards.

[0007] One batch control standard promulgated by the International Society for Measurement and Control, an international organization involved in process control issues, is entitled Batch Control Part 1: Models and Terminology, often referred to as the ISAS88.01-1995 standard or one of its revisions (referred to herein as the "S88 standard"). The S88 standard defines models of equipment and procedures for use in automated batch processes and defines specific terminology for use in referring to those models and their elements. For example, the S88 standard defines a "batch process" as a process that results in the production of a finite amount of material by applying, in a finite amount of time, a fixed amount of input material to an ordered set of processing operations using one or more pieces of equipment. As another example, a "batch" is defined by the S88 standard as the material that is or has been produced by a single run of a batch process.

[0008] As noted above, batch processing equipment (e.g., controllable elements such as valves, heaters, mixers, etc.) are operated during a batch process or run according to a predefined procedure to produce a batch. All such batch processing equipment is referred to herein interchangeably as equipment, equipment modules, processing equipment, and / or physical elements. The procedures for operating such physical elements are often referred to in the S88 standard as a "procedural model." According to the S88 standard, a procedural model is structured as a hierarchical ranking of procedures, with the highest level encompassing each of the lower levels, the next higher level encompassing each of the levels below it, and so on. Levels of the S88 procedural model of particular interest include, in descending order, "procedures," "unit procedures," "operations," and "phases." The term "procedural element" or batch subprocedure is used herein to refer to any embodiment or implementation of any of these levels of the S88 procedural model, as well as any other hierarchical definition of a set of batch procedures.

[0009] As noted above, the highest level S88 procedural elements of interest are referred to as procedures, and procedures are organized into one or more unit procedures. Each unit procedure is, or can be, in turn organized into one or more operations, which in turn can each be organized into one or more phases. Furthermore, the S88 procedural model does not preclude the definition and use of other hierarchical levels in specific applications. Rather, the S88 standard and the procedural elements referred to herein are intended to provide a broad, standardized model for describing procedures followed in automated batch process control, and these elements are not limited to the four procedural elements defined by the S88 standard.

[0010] The different procedural elements of a batch are generally implemented as computer programs executed by and within data processing devices, including in practice personal computers, workstations, and programmable controllers. Execution of a typical procedural element typically results in electrical or optical outputs from the data processing device that can be used to control physical elements, either by connecting the output of the data processing device directly to the physical elements or indirectly through a local or wide area network. A procedural element performs an assigned or associated task by invoking a "primitive control" on at least one physical element. This type of control is typically dedicated to establishing and maintaining a particular desired state of the physical element. Primitive controls include, for example, initiating or maintaining the flow of material in a storage vessel element, heating starting materials in a polyvinyl chloride reactor element, etc. In practice, the lower levels (i.e., phases) of the procedural model perform the actual communication with the actual physical elements, thereby invoking or executing the primitive controls. The higher levels of the procedural model are essentially abstractions to refine the organization and structure of the procedural model, as well as the physical model.

[0011] Additionally, many batch systems use a batch executive to control the operation of one or more batches in a plant according to the procedural model being used. The batch executive may be or use a state machine model as a logical structure that describes the state of a batch process or operation. The state machine model describes or defines a number of process states together with the actions that cause transitions between those states. The state machine model of a process is said to be in a particular state due to a previous transition to that state. When a particular event occurs or a particular status is sensed, the state machine model transitions to another state that corresponds to the particular event or sensed status. State machine models are a useful technique for defining and implementing the behavior of procedural elements of a batch process. In particular, a procedural element defined and implemented as a state machine initiates an action when, for example, its associated state machine transitions from an old state to a new state.

[0012] Of course, the S88 standard allows for the definition and implementation of procedural elements that follow a standard state machine model. Although the S88 standard does not mandate this approach, it has been widely adopted in the process control industry and allows for a high degree of interoperability between products from various vendors. One current commercial application of the S88 standard with procedural elements defined and implemented according to a state machine model is Emerson Process Management's DeltaV™ Batch product. In DeltaV™ Batch, a server or batch executive program runs on a data processing device that executes the various procedural elements. The server or batch executive program (referred to as the "batch executive") coordinates the execution of the procedural elements according to one or more state machine models such that the procedures, corresponding unit procedures, corresponding operations, and corresponding phases are sequenced through their respective steps by the server program. In either case, during the execution of a particular batch run or a particular batch process associated with an instruction, such as when a phase is started by a server program, the phase communicates a start request to a phase logic interface in the programmable controller. The programmable controller then executes the actual state logic or control routines for the phases and provides the necessary process control via communications to the process equipment.

[0013] As will be appreciated from the foregoing discussion regarding process quality review, it is desirable to collect data representative of the operation of a batch process, including historical events orchestrating the processing of a batch run, so that it can be determined whether a batch run to an instruction operated or performed satisfactorily in accordance with applicable quality standards. Such historical data may be useful not only for quality review purposes, but also for determining trends in quality control or for determining when equipment used in a batch process requires inspection. Many types of data are potentially useful in reviewing the quality and progress of a batch process. One such data source is continuous data generated by various data points in a batch process during the processing of a batch. A data point is a single, such source of continuous data that reflects some control value or other status or measurement of a batch process. For example, a particular level of material flow rate or material temperature, as measured by a sensor, may be such a data point. Current control valve settings, the time a sample was taken, etc. may be other data points. Each such data point may have a series of continuous data values ​​that are sensed or controlled over time by their associated batch process application. A summary of all such continuous data generated during the processing of a batch is often logged by the batch processing system and stored as part of a batch log file in a batch database. These batch log records typically include a timestamp and the current value along with other identifying information for the data point, such as a tag to identify the source of the data.

[0014] Another type of data useful in reviewing the quality and progress of a batch process is batch state and event information, which relates to or includes information describing the batch process with respect to the execution of a procedural model (e.g., the state of the batch process, the transitions between states of the batch model, etc.). For example, batch events describing the start and end times of a particular phase of a procedural model or a particular operation, unit procedure or step constitute event information. Event information also includes process events, which include information generated by physical elements of the batch process or by an operator. In particular, each equipment module, cell, etc. of the process may generate process events indicating one or more specific actions in starting, stopping, or running a particular phase (i.e., performing a particular basic control action). Alarms and event conditions recognized by process equipment are further examples of process events. Process events may also include information regarding operator changes to the batch process made during operation of the batch process.

[0015] Furthermore, many batch processing systems utilize operator interface programs running on dedicated operator interface devices such as workstations to allow an operator to view the current state of a batch run, take manual steps within the batch run, e.g., manually set various parameters, select process equipment for execution of various batch procedures, operations, phases, etc., make notes regarding unexpected operations or conditions during a batch run or instruction, etc. One such operator interface program is known as a workflow program (such as the Syncade Workflow program provided by Emerson Automation Solutions), which intercepts or receives various information from the batch executive or process equipment (e.g., process controllers) used to implement the batch run for each instruction being processed. The workflow program may subscribe to various types of data from the batch executive or process control system and present this data to the operator to enable the operator to view the current state of the batch run, view transitions between states of the batch model, make changes to the batch run, manually stop and start various batch procedures, operations, phases, or equipment, and respond to problems or unexpected events that occur within the batch run. For example, often unexpected errors or problems may occur during a batch run, such as batch equipment or raw materials being unexpectedly unavailable, process parameters being outside of expected or desired ranges, etc. In these cases, the workflow program allows the operator to make and implement decisions about how to proceed, such as skipping a batch step or procedure, designating other equipment or materials for use, or modifying process plant variables, set points, or parameters to address the alarm or event in the process. Generally speaking, the workflow program stores data indicative of the operator's actions in a batch log file along with the raw batch data stored in the batch log file.Often the workflow program also allows the operator to make notes or store explanations about what was happening in the batch at the time of the action, why the operator took a particular action, etc., and these notes are also stored in the batch log file.

[0016] In either case, in many industries, after a batch run occurs and the product or order is completed, a quality control engineer or other quality control personnel (generally referred to herein as a quality control engineer) must verify that the product meets appropriate quality standards. To perform this review, the quality control engineer accesses and views the batch log file of the order's batch run (typically on an order-by-order basis) to ensure that the batch run was completed according to or within expected parameters, workflows, and ranges. Generally, to perform this review, the quality control engineer must scroll through the raw data in the batch data file looking for "exceptions" to the expected behavior of the batch run. The term "exception" is used generally herein to indicate a deviation from an expected procedure, process, step, workflow, range, value, etc. in a manufacturing process or plant. Exceptions may be, for example, one or more process variables or parameters being outside of expected or desired ranges or above or below expected or desired thresholds, a batch procedure, operation or phase skipping or not performing an expected sequence, a batch procedure, operation or phase stopping or starting at an unexpected time or taking longer or shorter than expected operating time, different or unexpected materials being used in a batch procedure, additional steps or actions being performed by an operator during a batch run, changes to the recipe, notes generated by an operator during a batch run, alarms and events occurring during a batch run, etc.

[0017] In either case, the quality control engineer must identify the exceptions based on the raw data stored in the batch log file and then determine the impact or severity of each such exception and what would happen if any steps were taken to handle or "close" the exception. For example, in many cases, the exceptions may only represent minimal or insignificant deviations in the expected batch run that do not at all or significantly reduce the quality of the product produced according to the quality standards in place. In other cases, the exceptions may need to be documented for later review by a notified body or by the customer, but their impact may not be significant enough to result in a significant reduction in the quality of the product. In still other cases, the exceptions may be significant or significant enough to require one or more additional steps to be performed on the product to ensure the desired quality or one or more tests to be performed on the product to ensure the quality of the product. In still other cases, the quality control engineer may determine, based on the details of the exception, that the product needs to be scrapped or that the product needs to be sold at a lower quality or labeling standard.

[0018] The process of reviewing batch log files for exceptions is very tedious and fraught with problems. In particular, most data in a batch log file is not indicative of an exception, so the quality engineer spends a significant (usually most) of the review time looking for data that is not actually associated with any exception. Furthermore, the quality engineer must note all conditions that lead to an exception, including, for example, the desired values ​​or ranges of critical process variables, the expected sequence of batch steps, the expected stop and start times of various different batch steps, etc. Although the presence of batch process alarms and alerts, or notes from an operator, stored in the batch log file may indicate the presence of an exception, this is not necessarily the case, and of course not all exceptions that occur may reach a level where they can be documented with operator notes or where associated alarms or alerts are generated in the control system. As will be appreciated, the actual exceptions that are determined will therefore depend on the skills of the particular quality engineer performing the review and the particular quality standards being met.

[0019] Furthermore, when a quality control engineer finds an exception (e.g., a process value is out of range), the engineer must typically determine the context of the batch at the time of the exception to determine the severity of the exception and how to best respond to or handle the exception. This process may include obtaining additional data about the state of the batch run or batch procedure at the time of the exception, the values ​​of other process variables at the time of the exception, determining whether an alarm or event was generated on the same or other process equipment at the time of the exception, etc. Thus, this process generally requires the quality control engineer to use other available data access systems to determine additional process state information at the time of the exception. This data collection activity can be time consuming and requires additional know-how on the part of the batch quality control engineer.

[0020] For example, because a batch process has a variety of different procedural elements that may run on different equipment in a plant at different times, using different set points, settings, etc., it is not a simple task to take a snapshot of a batch process at a particular time and display that data to a quality control engineer to view the operation of a batch from a batch log file. Instead, to view a batch run, a quality control engineer reviews and analyzes data from the batch at various times related to the batch's procedural events (i.e., sub-procedures and sub-processes associated with the batch), thereby being able to understand the operation of the batch run during exceptions. Although various batch data are typically collected and stored automatically during the operation of a batch run, these different types of data are generally collected by different subsystems and may in fact be stored in different databases. This makes it difficult for a quality control engineer to comprehensively view any particular batch process. For example, data such as alarm data and sensor measurement data obtained from actual field devices such as sensors, valves, etc. in a batch process are typically stored in a data historian as time-stamped data and are available from the data historian generally based on the time the data was collected. However, different databases, such as those associated with a batch executive routine, may store the start and end times of a batch run and various different sub-procedures or procedural elements within the batch run, making it more difficult for a quality control engineer to understand the context of an exception without significant data digging in various other subsystems of the batch process. Summary of the Invention

[0021] A quality review management system (also referred to as a review by exception (RBE) system) may be used to analyze the operation of one or more manufacturing processes as collected by a variety of other process plant data sources, such as process control systems, workflow applications, batch process operator applications, batch executive applications, and other data sources. The quality review management system automatically detects exceptions in these processes and stores data about the detected exceptions in an organized, easily reviewable manner. The quality review management system also enables a quality review administrator or engineer to review and handle (resolve) exceptions associated with the processes in an easy-to-use interface.

[0022] More specifically, the quality review management system includes a configuration system that allows for the creation and storage in a rules database of rules that can be used to automatically identify one or more exceptions in a process, such as a batch process. The rules may identify a set of conditions that must be met to identify an exception, the severity of the identified exception, information about the exception and the process or procedure used to handle, resolve, or close the exception, process data or other data to be stored as part of an exception record to assist a quality review engineer in understanding and resolving the exception, etc. The quality review management system also includes an exception engine that uses the rules in the rules database to process data in a data message, such as data messages provided periodically by a data source, such as a plant or process control system, a batch executive, an operator workflow application, etc., to determine whether the data in the data message contains an exception, as defined by any of the rules. Once the exception engine identifies an exception, it may store information about the exception as an exception record, such as the name, type, severity of the procedure or steps taken to resolve or handle the exception, and process data about the operation of the process at which the exception occurred, the time the exception occurred, etc. The exception engine may store this and / or other data for each identified exception as an exception record for each instruction in an exception file (e.g., an exception database). Additionally, the exception engine may operate in real-time during operation of a process implementing the instructions to create an exception file or database for the instructions and provide live feedback to a process operator that an exception has occurred or is about to occur.

[0023] Thus, in one embodiment, the quality review system provides a configuration environment that allows a user to create configurable exception rules to run in the exception engine to define or detect exceptions. The configuration environment may store a set of rule templates that may process various types of input data to detect exceptions. In the configuration environment, a user may select one of the templates, define the input / output, and define possible expressions to be analyzed for the data set. As data passes through the engine, it analyzes the data against the configured rules, and if any rule criteria are met, an exception is created. The exception may then be checked immediately. A typical known review by exception product requires the exception software provider to hard-code the defined exceptions into the product for the system, and therefore requires software or system updates to create new exceptions. These updates take time for users to obtain and install, and do not allow users to customize their own systems.

[0024] The quality review management system also includes a review interface that allows a quality review engineer or other personnel to review and address exceptions as identified by the exception engine and as stored in the exception database as exception records for an order. In particular, the review interface may access the exception database for a particular order and present information about each identified exception to the quality review engineer in an organized, easy to understand manner. The review interface may provide the quality review engineer with data stored for each exception record, such as the name, type, and severity identification for each exception record. The review interface may provide the reviewer with stored information about the exception as identified by the exception record, such as the type of exception, and data regarding various process or batch variables, states, procedures, etc. that existed at the time the exception occurred. This information allows the reviewer to easily understand the exception, the context of the process at the time the exception occurred, and the severity of the exception. Furthermore, the review interface may enable the reviewer to take various actions with respect to each exception. Such actions may include acknowledging the exception, approving or closing the exception, annotating the exception with further information such as why the exception can be ignored or approved, sending the exception record to another person, etc. The review interface may also provide suggested actions to the reviewer and in some cases enforce specific actions to be taken regarding resolving or closing the exception. Such actions may include, for example, requiring approval by a specific number or type of people (e.g., only the reviewer, the reviewer and management, two reviewers, etc.). Other actions may include requesting that specific information be provided by the reviewer, such as annotations, process information, etc., that are stored with the exception record for later use by the customer, the quality review organization, etc.

[0025] The review interface may store the processed exception records in a database or file and may allow a reviewer to scroll through the exception records in the exception database to determine if and when all exception records for an instruction have been processed or closed, the status of the review (e.g., how many unprocessed exceptions exist in the exception record database), and statistical data about the exception records (e.g., how many exceptions of each type or severity exist in the file). The review interface may also allow the reviewer to group the exception records in various ways, such as by type, by severity, by processing status (e.g., not reviewed, reviewed but not closed, closed, etc.). Furthermore, the review interface may allow the reviewer to take one or more actions on the exception records for an entire group, such as closing all the exception records in the group, annotating all the exception records in the group, etc.

[0026] In this manner, the quality review management system may be set up and run during the operation of a batch or other process to automatically identify exceptions as they occur during a process run, notify a process operator that an exception has occurred or that an action taken by the process operator would result in an exception, and store all exceptions determined for a particular process (e.g., a batch process) in an exception record database. The quality review management system also allows a quality review engineer to quickly determine, view, and handle exceptions in the exception database without having to review large amounts of raw data, as is currently necessary. Similarly, the quality review management system may enforce various rules in the exception handling or resolution process, such as ensuring that exceptions of various different types or severities are handled or handled in a particular manner, thereby providing consistency to the quality review process.

[0027] Furthermore, the quality review management system may be implemented in a plug-in environment that allows the system to be used to interface with third party systems or applications and analyze them for exceptions. In one case, a plug-in may be created or configured to obtain specific data from a third party application or data source and then pass this data to an exception engine for processing by one or more exception rules. As one example, the quality review management system may be used to interface with an event monitoring system, such as one that uses an OPC interface, to obtain and analyze data from a third party process control system or plant.

[0028] In one embodiment, plug-in modules are created to interface the RBE exception engine with external or third-party systems (e.g., control systems, OPC interfaces, maintenance management systems, etc.), thereby allowing exceptions to be generated based in whole or in part on data from third-party or external software systems. Plug-ins can be created to access specific data in or from the third-party or external systems and pass this data to the RBE engine to analyze whether an exception should be created. Plug-ins can run in the third-party server, the RBE server, or in a separate server, and may or may not perform exception detection. Thus, plug-ins can be simple third-party system data collectors, or they may collect data and additionally perform some exception processing and provide exceptions or pre-processed exception data to the RBE engine.

[0029] Known review systems currently cannot interface with or create exceptions based on data provided directly by external software programs, such as control systems, safety systems, maintenance management systems, etc. Plug-ins make RBE systems much more robust in complex process environments that have multiple different software systems operating during runtime.

[0030] Furthermore, in one embodiment, the RBE system may include a live view component that collects a set of metadata (which may be predefined, for example, when creating a plug-in) when collecting RBE input data (i.e., process data used to define or generate an exception). The metadata may be any other process or environmental data and is collected contemporaneously with the exception input data. This metadata is stored as a process snapshot associated with the accessed exception data. When the RBE system detects an exception based on the collected exception data, the RBE system also stores the metadata as part of the exception. The RBE system additionally displays some or all of the metadata when reporting the generated exception, thereby providing the user or reviewer with a live view into the process at the time the exception occurred in the process. This system provides the user with a quick view of the various process states / values, etc. at the time of the exception, allowing the user to more quickly understand why the exception occurred and the severity of the exception, thus allowing the user to more quickly handle the exception.

[0031] Known process review products provide a user or reviewer with a list of generated exceptions, but the reviewer must still analyze each exception to determine whether the exception can be dismissed or must be addressed in some other way. Generally speaking, however, the reviewer must go back to the process system where the data that led to the exception was collected to understand other things about the process at the time of the exception (e.g., was the process online or offline, the state of the batch at the time of the exception, etc.). The live view feature can automatically provide the user with a process snapshot that typically contains the process data that is most useful to the reviewer when performing an exception review, which means that the reviewer does not have to go back to other data collection systems to get the information that the user needs to perform the exception review. This feature also means that because the reviewer does not have to use other process systems where the data is collected to access the process data that the reviewer needs, the reviewer generally does not need to be familiar with those systems.

[0032] In another embodiment, the RBE or quality review system may be tied to a third party or external system and may include an event monitor that generates and sends messages to the RBE system, which can then use these messages to perform exception handling or exception creation. In one case, the event monitor may be tied or coupled to an OPC alert and alarm monitoring interface and may recognize when one or more alerts or alarms are passed to the OPC interface. At this point, the event monitor creates a message with the alert or alarm information and possibly any other desired OPC collected data and delivers it to the RBE system. The RBE system then analyzes the message and creates exceptions based on the alarms and alerts. Typical review systems do not analyze data from third party systems, nor are any of them connected to existing OPC alert and alarm interfaces. As such, these systems cannot create exceptions based on process alarms and alerts, for example.

[0033] Similarly, the quality review management system may use a novel paging algorithm when presenting a list of exception records to a reviewer via an electronic display or user interface. This paging algorithm, which operates in a manner that reduces or eliminates the presentation of missing or duplicate records in the review process, stores one or more anchors for tracking actual records within a current display page of records provided on the interface display. The system then uses the anchor for the currently displayed page to determine the starting location of the next set or record to display as part of the next page, which allows the paging system to operate properly as records are added to or removed from the list of records to be displayed during the review process.

[0034] In one embodiment, the review system implements a novel paging algorithm when presenting the list of generated exceptions to the reviewer. In general, the RBE system creates / detects exceptions and stores these exceptions as records in a structured database, such as an SQL database. Then, when presenting the list of exceptions to the reviewer on the display screen (and there may be a large number of exceptions or records), the RBE system searches the database for all relevant exception records, downloads a page of links to these records, and then presents the records in the portion of the retrieved page in the order downloaded from the database as the user scrolls through the various exception record pages. However, as the reviewer processes the exceptions and scrolls down the exception list as displayed on the user interface, records may be changed in the database and thus the page data may become out of date. In particular, records may be added or deleted from the database. In this case, when the system tries to present the records on the display screen, various records referenced in the page may be missing, causing visible data loss or duplication. In some cases, the user may miss records going from one page to the next due to records on a particular recalled page being deleted. In other cases, the system may become confused about where to start a new display page based on missing records that were in the downloaded page. The new system operates differently in that it downloads the records presented on the display screen starting from the last record displayed on the screen. That is, instead of presenting a new display page associated with the original retrieved record page, the system accesses the database to find the set of records that currently exists immediately after the last record on the displayed page, thereby ensuring that each time a new set of records is displayed on the screen, the first new record displayed is the record immediately after the last record that was displayed immediately before the scroll point.

[0035] This display system is more accurate because it ensures that records are not displayed out of order or missed during a review process where the user scrolls down various pages of records over time. Additionally, the RBE system is more efficient because as the user scrolls through the records, it only needs to access the database for the number of new records that will fit on a new display page, while still ensuring that all of the relevant records are accessed as the user performs the scrolling process. [Brief description of the drawings]

[0036] [Figure 1] FIG. 1 is a block diagram of a typical process or manufacturing plant that includes a process control network, a batch executive, and a workflow application that allows operators to manage the batch process and store batch log files for quality review. [Diagram 2] FIG. 2 is a block diagram of a plant environment similar to FIG. 1 but including a quality review management system having a configuration application, an exception engine, and a quality review interface application for use in performing exception-based detection and quality review within the plant environment. [Diagram 3] 3 is an exemplary screen display produced by a configuration application of the quality review management system of FIG. 2 that enables a user to create one or more exception rules for use by the exception engine. [Figure 4] 4 is a flow chart illustrating operation of the exception engine of the quality review management system of FIG. 2 when analyzing data from multiple data sources for exception handling. [Diagram 5] 1 is an exemplary screen display illustrating live feedback from a quality review management system to an operator of a batch process, notifying the operator in real time of the detection of actual or potential exceptions in the process. [Figure 6]FIG. 2 illustrates the operation of a quality review management system implemented in a plug-in environment. [Figure 7] 1 illustrates an exemplary event monitoring system that performs monitoring of third party applications and systems using a quality review management system in a continuous process environment. [Figure 8A] 10 shows an exemplary screen display produced by a review interface application or configuration application of the quality review management system of FIG. 2 that enables a quality reviewer to perform various tasks related to exception rule configuration and exception record viewing and handling. [Figure 8B] 10 shows an exemplary screen display produced by a review interface application or configuration application of the quality review management system of FIG. 2 that enables a quality reviewer to perform various tasks related to exception rule configuration and exception record viewing and handling. [Figure 8C] 10 shows an exemplary screen display produced by a review interface application or configuration application of the quality review management system of FIG. 2 that enables a quality reviewer to perform various tasks related to exception rule configuration and exception record viewing and handling. [Figure 8D] 10 shows an exemplary screen display produced by a review interface application or configuration application of the quality review management system of FIG. 2 that enables a quality reviewer to perform various tasks related to exception rule configuration and exception record viewing and handling. [Figure 8E] 10 shows an exemplary screen display produced by a review interface application or configuration application of the quality review management system of FIG. 2 that enables a quality reviewer to perform various tasks related to exception rule configuration and exception record viewing and handling. [Figure 8F] 10 shows an exemplary screen display produced by a review interface application or configuration application of the quality review management system of FIG. 2 that enables a quality reviewer to perform various tasks related to exception rule configuration and exception record viewing and handling. [Figure 8G] 10 shows an exemplary screen display produced by a review interface application or configuration application of the quality review management system of FIG. 2 that enables a quality reviewer to perform various tasks related to exception rule configuration and exception record viewing and handling. [Figure 9A] 1 illustrates the operation of a typical paging technique used to present a list of records to a user, for example in a web environment. [Figure 9B] 1 illustrates the operation of a typical paging technique used to present a list of records to a user, for example in a web environment. [Figure 10A] 10 illustrates the operation of a new paging technique that may be implemented by the quality review interface application of FIG. 2 to reduce or eliminate duplicate or missing records when paging through a set of records. [Figure 10B] 10 illustrates the operation of a new paging technique that may be implemented by the quality review interface application of FIG. 2 to reduce or eliminate duplicate or missing records when paging through a set of records. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0037] By way of background, FIG. 1 illustrates a typical plant or process control environment 10 in which typical or existing quality review management actions are performed. The plant environment 10 includes a process control network 20 that may include various process control devices, such as controllers, field devices (e.g., valves, sensors, transmitters, tanks, mixers, etc.), I / O devices, etc., communicatively connected together and all programmed to operate or perform some type of manufacturing process, such as a batch process or a continuous process. Furthermore, the plant environment 10 may include a batch executive 22 (implemented on a processor of a computing device, such as a workstation or server) that interfaces with the process control network 20 to cause the process control network 20 or devices within the process control network 20 to take various actions associated with the manufacturing process, such as performing various instructions or batch runs, including performing different stages of various batches, such as unit procedures, procedures, operations, phases, steps, etc. of a batch process associated with each instruction. Furthermore, both the process control network 20 and the batch executive 22 may be coupled to additional networks 24 that may be located, for example, in a business environment away from the plant floor or manufacturing space. Network 24 may include a communications backbone 25 that communicatively connects various devices, such as computer display devices or workstations 26 and 28, various databases 30, 31 and 32, and, if so desired, other computing devices, such as gateways, servers, wireless or handheld devices to the Internet or other communications network (not shown in FIG. 1). Devices 26, 28, 30, 31, and 32 may be communicatively connected via any desired physical communications network or backbone 25, such as an Ethernet network, the Internet or other local area network (LAN) or wide area network (WAN).Similarly, the process control system 20 and the batch executive 22 may be connected to various devices and databases 26, 28, 30, 31, and 32 via a network backbone 25, either directly, or through other intervening networks if so desired.

[0038] In this prior art system, a workflow application 40 may be stored within an operator interface device (such as the workstation 26) and executed by a processor in the workstation 26 to interface with the batch executive 22 as the batch executive 22 controls the process control network 20 to execute various instructions or batch runs. The workflow application 40, which may be, for example, the Syncade Workflow application sold by Emerson Process Management, may operate to obtain and display data from the batch executive 22. This data may include status data of a batch in progress, parameter data, measurement data, progress data, batch procedure model state data, etc., as obtained by the batch executive 22. This information or data may include indications of the instruction being performed, materials and processes associated with the instruction (e.g., recipes and batch procedure models to be performed), alarm and alert data, etc., from the batch executive 22 and / or the process control network 20. Any or all of this data may be stored as a batch log file 34 in the batch log file database 32, as is typical for a batch executive routine.

[0039] As is generally known, the workflow application 40 may track the operation of the batch executive 22 with respect to each instruction being performed by the batch executive 22 and may enable a batch operator to perform various operations or actions in or with respect to the batch executive 22 or the process control network 20. For example, the workflow application 40 may subscribe to certain types of data from the batch executive 22, such as parameter data, batch state data, batch state change data, batch alarms and / or alerts, and based on this data, may notify an operator of various conditions within the plant 10. The workflow application 40 may, for example, notify an operator of the start and stop of various different batch procedures or state changes of a batch procedure model, notify an operator of various stoppages or other operating conditions of the batch executive engine 22 (which may occur due to unexpected issues such as missing equipment, missing raw materials, etc.), notify an operator of batch parameters that may be out of range based on what the batch executive 22 is expecting, etc. The workflow application 40 may enable the operator to take various actions, as is known, to restart a batch run, to select different equipment for a batch run, to operate with different raw materials, to instruct the batch executive to start, shut down or skip a procedure, or to execute other procedures within the batch procedure model. As one example, the batch executive 22 may attempt to execute a cleaning procedure where the equipment to be cleaned is offline and therefore unavailable for cleaning. In this case, the operator may skip the cleaning procedure, which may not strictly comply with the quality standards in place, but may be necessary to complete the batch in a timely or allotted time frame. In either case, the workflow application 40 may enable the operator to annotate the various actions taken by the operator.Additionally, the workflow application 40 may store annotations or notes provided by the operator via the workflow application 40 (e.g., notes or comments provided by the operator to explain what happened and why the operator took a particular action outside the expected workflow of the batch process) and may store data indicating various actions taken by the operator via the workflow application 40 in the batch log file database 30 as part of the batch log file 34 for the instruction being monitored or controlled. Each batch log file 34 typically lists various data obtained from the batch executive 22, along with actions taken by the operator in response to that data, notes written by the operator in the log file, etc. Additionally, during operation of the batch executive 22, the batch executive 22 sends data packets to the workflow application 40 with current data regarding the batch run or instruction. The workflow application 40 may subscribe to various data from the batch executive 22 (or the process control network 20) ​​and may receive this data periodically, such as when changes occur to the data. Additionally, each data set may have a unique packet identifier that identifies various information about the batch run or instruction associated with the data. In this manner, the workflow application 40 can process the data packets to determine the instructions and therefore the appropriate operator to which to provide the data.

[0040] As is known, a batch log file or batch report 34 for a batch run is generated during the batch run and after the batch run or instruction is completed, the batch log file 34 is completed. At that point, a quality review engineer or other personnel may access the batch log file 34 via some viewing application running on the computer or workstation 28 to, for example, analyze the batch report and view the data and other information in the batch report line by line. The quality control engineer may view this data as it is stored during the operation of the batch process to determine whether any exceptions occurred within the batch run, whether these exceptions need to be addressed, and whether any action needs to be taken based on the presence of these exceptions. As noted above, this review tends to be time consuming, manually intensive, and requires a lot of knowledge on the part of the quality control engineer. Moreover, most of the time the quality control engineer spends is simply looking at data or information from the batch report that is not associated with specific exceptions or deviations from expected actions in the batch run, and therefore this review is time consuming. Furthermore, as noted above, if the quality control engineer identifies an exception based on the data in the batch log file 34, the quality control engineer may need to obtain other information about the batch process (e.g., process variable values, batch procedure model states, recipe information, etc.) that is stored in one of the other databases, such as the batch historian 30, the process control historian 31, etc. This task may require the quality control engineer to access that data using other data access applications, and therefore requires that the engineer have the know-how to efficiently and accurately access and view that data using these other data access applications.

[0041] Figure 2 illustrates a plant environment 110 similar to the plant environment 10 of Figure 1, where like structures, applications, and data have common reference numbers. However, the plant environment 110 of Figure 2 includes a quality review management system 112 that operates to assist a quality control engineer (or other personnel) in identifying and reviewing exceptions associated with an order or batch run (or multiple different orders or batch runs), and in some cases, to assist an operator in performing workflow operations within a batch run in a manner that reduces the number of exceptions or exception records generated during an order.

[0042] In particular, the plant environment 110 of Figure 2 includes a process control network 20 and a batch executive engine or batch executive 22, which operate in a manner similar to that described above with respect to Figure 1. Thus, data from the batch executive engine 22 and / or process control network 20 is provided to various devices via a communications network backbone 25 to which various process control and various different quality review management system 112 computers or devices are connected. In this example, the batch or other process data is provided to a workflow operator interface 26 which executes a workflow application 40 and provides data to a batch log file database 32 which stores a batch log file 34. However, the quality review management system 112 in the plant environment 110 of Figure 2 includes various applications and databases that are located within, stored therein, and executed on computer or processor devices within the plant environment 110. In particular, as shown in Figure 2, the quality review management system 112 includes a configuration application 120 stored in memory of and executing on a processor of a processing device 121, an exception engine 122 stored in memory of and executing on a processor of a server 123, a rules database 124, an exception records database 126, and a quality review interface application 128 stored in memory of and executing on a processing device such as a workstation 129. Although components 120, 122, 124, 126, and 128 are shown as stored and executing on separate computing devices that are different from computing devices 26, 28, 30, 31, and 32 in Figure 2, any subset or all of components 120, 122, 124, 126, and 128 may be stored and executed on the same processing device, which may be the same processing device that stores and executes other process control applications and databases, such as devices 26, 28, 30, 31, and 32.

[0043] Generally speaking, the configuration application 120 may operate or execute to allow a user, such as a configuration engineer, quality control engineer, or the like, to create and store a set of rules (generally referred to herein as exception rules) that may be used by the exception engine 122 to detect exceptions during the operation of a process, such as a batch run of a batch process associated with a particular instruction. The configuration application 120 essentially provides a configuration environment that allows a user to create configurable exception rules that are executed within the exception engine 122 to define or detect exceptions. The configuration application 120 may store a set of rule templates that may process various types of input data to detect exceptions using any desired type of logic or logical expressions, such as Boolean logic. In the configuration environment, a user may select one of the rule templates, define the data inputs / outputs for the rule, and define expressions that will be analyzed against the data set. As data passes through the exception engine 122, the exception engine analyzes the data against the configured rules to determine whether an exception exists. Upon detecting an exception, the exception engine 122 then stores an exception record in the database 126 .

[0044] As an example, FIG. 3 illustrates a screen display 150 that the configuration application 120 may create and provide to a user (e.g., a configuration engineer, a quality review engineer, etc.) via the workstation 28 of FIG. 2 to, for example, enable the user to create one or more exception rules 152 and store the exception rules 152 in the exception rules database 124. In particular, the configuration application 120 may enable the user to create different rule sets to be applied to data from different data sources. As shown in FIG. 2, the exception rules 152 may include different exception rule sets 152A, 152B, 152C, 152D, etc., for each of a number of different data sources. For example, rule 152A may be created and associated to analyze data from the workflow application 40, rule 152B may be created and associated to analyze data from an event monitor application, rule 152C may be created and associated to analyze data from a third party application that performs other services within the plant environment 110, etc. Of course, any number of exception rules 152 can be created and stored for each data source, and these rules can be configured in any number of different ways to analyze data from those data sources. For example, different exception rule sets can be created for different types of runs (e.g., batches making different products) from a single data source, different exception rule sets can be created for different quality specifications, etc. Similarly, the exception rules associated with a particular data source can be ordered to specify which exception rule set is executed or analyzed first, second, third, etc.

[0045] Referring again to FIG. 3, the configuration application 120 may create a screen that includes a number of different sections, including a rule template section 156, a data source section 158, a rule list section 160, and a rule configuration section 162. The rule template section 156 may include a set of icons that represent exception rule templates or previously configured exception rules stored as templates that a user may use as a starting point for creating new rules. These templates may be stored in the rules database 124, or in the same device as the configuration application 120, or in any other database or computer memory. The data source section 158 may include icons that represent a variety of different data sources for which a user may create exception rules. The icons 158A may be accessible to view details about the data source, such as the data available from the data source, the data or communication format used by the data source to communicate the data, information about the data source (e.g., manufacturer, version, etc.), and / or any other information. The rule list section 160 may store a rule list for a particular selected data source and specify the order of execution of the rules when analyzing data from the data source.

[0046] In operation, a user may select a data source 158A from the data source section 158 to specify a data source for which a rule is to be created. The application 120 may access the rules database 124 to find previously stored rules (if any) for that data source and list these rules in the rule list section 160, for example, in order of execution. The user may then create a new rule for the data source by selecting a template data source icon 156A from the template section 156 and dragging and dropping the template icon 156A onto the rule configuration section 162, causing the application 120 to load configuration data for the selected template rule into various portions or fields of the configuration section 162. If desired, the rule configuration section 162 may leave its fields blank, allowing the user to create a new rule without using a template. Furthermore, the user may select one of the rules in the rule list section 160 to edit a previously created rule. Of course, the application 120 may use other methods of selecting or establishing the rules to be created (eg, using drop-down menus, pop-up screens, etc.).

[0047] The configuration application 120 then allows a user, such as a configuration engineer, to specify, set up, or create the details of a rule by providing or editing various rule configuration information in various fields of the rule configuration section 162. Essentially, the application 120 allows a user to specify the rule configuration information necessary to process data from the data sources for the purpose of detecting and handling exceptions in the operation of a process monitored by the data sources. Generally, each rule stores logic, such as Boolean logic, that is used to analyze data from the data sources to detect exceptions, information about how to store exception records, and, if desired, information about how to allow a quality control engineer to process or resolve (e.g., close) exception records created by the application of the rule. Such exception rules may include detecting, for example, whether one or more parameters from a data source (e.g., the workflow application 40, the batch executive 22, the process control system 20, etc.) are out of range or above or below certain pre-established thresholds; whether a note has been entered by an operator (e.g., via the workflow application 40); whether different materials are used in a batch run for an instruction; whether different equipment is used for one or more batch procedures of an instruction; whether the processing time of one or more batch procedures is taking longer or shorter than expected; skipping or adding a particular step or procedure in a batch run for an instruction, such as a cleaning procedure or a rinsing procedure; whether an operator or other user of the process system has taken an unexpected action in the process or entered a note in the data source application, etc. Of course, the exception rules may specify any desired logic that is applied to particular data from a data source to determine whether an exception exists.

[0048] Thus, as shown in the example screen 150 of FIG. 3, the rule configuration section 162 includes a name field 162A that may be used to specify a name for the exception rule, a severity field 162B that may be used to specify a level of severity or importance of the exception detected by the rule, and a logic field 162C that may be entered or used to specify logic to be applied by the exception engine 122 (FIG. 2) to detect if an exception exists. Of course, the logic field 162C may permit or allow a user to enter or specify the logic in any desired manner, such as a set of Boolean logic parameters or strings, coding in a particular language (C+, HTML, etc.), any desired custom expression syntax that applies some logic, If-Then logic statements, etc. Furthermore, the source parameters field may be used to specify any data required from a data source to apply the logic rule or logic as provided in field 162C. This data source data, referred to herein as data source metadata or simply metadata, specifies all data associated with the information, format, and communication parameters of the data to be received from the data source for the rule. The configuration application 120 may allow a user to select one of the icons 158A to obtain configuration information for the particular data source for which the rule is being created to determine what data source metadata (information and / or variables) are available from the data source, the names of these variables, the data format of these variables (e.g., variable types such as 32-bit, 64-bit, integer or Boolean, or string variables), etc. Furthermore, field 162D may allow a user to specify transformations to be performed on the metadata from the data source before the input data from the data source is used in the logic specified in field 162C.Such transformations may be mathematical operators (changing Celsius to Fahrenheit, scaling, limiting, etc.), the transformations may be variable name changes (to match various variable names used in the logic to data source variable names), or these transformations may be any other type of transformation. Additionally, metadata from the data sources may include any desired information, such as process parameter values, instruction names, materials for the instruction, process flows for the instruction, process equipment used in the instruction, workflows applied to the instruction, batch procedure models used in the instruction, etc.

[0049] Furthermore, a configuration engineer may use the configuration application 120 to specify an order or sequence in which each rule of a particular rule set is applied to a particular data set from a data source. In particular, the exception engine 122 may apply multiple rules to each data set from a data source, and may be set up to apply each of the multiple rules in a particular or predetermined order to detect certain types of exceptions (typically more significant or critical exceptions) before other types of exceptions (e.g., less critical exceptions). For example, in many cases, applying different exception rules to a particular data set from a data source may result in detecting multiple different exceptions. However, it may be important or desirable to determine only the most significant exceptions for any particular data set from a data source so as to prevent the creation of multiple exception records associated with the same event or time within a batch run or instruction. Thus, the order of the rules (i.e., the order in which the exception engine 122 applies the exception rules to a particular data set) is used to specify which exception is detected first, such that during operation, the exception engine 122 determines exceptions based on the various rules by executing the rules in a particular order and then saving or creating exception records for only the exceptions detected first. As described above, rules section 160 may store a list of rules for a source in the order in which those rules are executed. Each rule may store or include as its parameter a sequence number or order number indicating this execution order. In either case, a user may change the order of the rules for a data source, for example, by rearranging the order of the rules in the rules list in section 160. A user may, for example, select a rule in rules list 160, drag the rule up or down in list 160, and drop the rule in a new position in list 160 to change the execution order of the rules. Of course, application 120 may allow a user to change the order of the rules in other ways, such as by changing order field 162E in screen section 162.

[0050] Furthermore, if desired, screen section 162 may include a solution field 162F that may enable the configuration engineer to specify one or perhaps more handling or resolution procedures that should or must be applied to close an exception record created by a rule. Generally, each exception type may support a single resolution procedure. In some cases, however, an exception may support or include multiple resolution procedures. Such resolution procedures may include approving the exception, annotating the exception record with various information, sending the exception record to other personnel for review and / or approval, etc. In some cases, each solution may simply be a definition of a set of signatures required to close the exception, or the solution may simply enforce one or more signatures required to close the exception. In these cases, the solution may include a description or set of instructions indicating other actions (steps) to be completed prior to the signature, although in these cases the solution may not monitor or enforce the other actions. The handling procedures specified within the rules may be preset or may be set to default settings, for example based on the severity of the exception as specified in field 162B.

[0051] Furthermore, screen section 162 may include information field 162G for receiving and storing information to be provided to the quality review engineer along with or as part of the exception record created by the application of the rules. This information may be general information about this type of exception, normal handling procedures, instructions or suggestions for other actions to be taken or considered, or other information that may be useful to the quality review engineer when viewing or working with the exception record created by the application of the rules. In many cases, field 162G may also be used to specify data source metadata to be stored as part of the exception record, and the format in which this metadata is displayed. In general, when processing an exception record, it is helpful for the quality review engineer to know the context of the process at the time of the exception, and data source metadata may be provided as information to help the quality review engineer understand this context. Thus, configuration field 162G may indicate what data source metadata should be provided to the quality review engineer as part of the exception record.

[0052] Of course, configuration application 120 may store any or all of the rule configuration information in rules database 124 as part of the exception rules in any desired manner. As will be appreciated, this configuration information may include the identity of needed data from the data sources that can be used to obtain the correct data or information from the data sources during operation of the data sources, as described below.

[0053] Of course, any number of exception rules may be created using the configuration application 120 and the exception rules may be stored in the rules database 124 on the data source by way of the data source, such that different rules or rule sets may be created and stored for different data sources (or for different instructions associated with a single data source). In either case, the configuration application 120 may be used to create rules, and may do so by allowing a user to create new rules (e.g., from a template rule) and may allow the user to specify the name of the rule or the exception to be detected by the rule, the logic to be applied to data from a particular data source to be implemented to detect the presence of an exception or a deviation from a standard based on the data, an identification of the rule or the type of exception the rule detects, a set of information to be provided to a reviewer or other user when the rule detects an exception (a description of the exception, data or instructions useful for analyzing or approving the exception, etc.), an identification of the severity (e.g., importance) of the exception detected by the rule, metadata (e.g., data from the data source) about the state of the process (e.g., batch run) at the time of the exception to be stored as part of the exception record, a process or procedure (e.g., an approval procedure) that can or must be used to handle or resolve the exception, and other data or information to be stored as part of the exception record or used in processing the exception record.

[0054] Importantly, this configuration system or configuration application 120 provides significant advantages over known products that require an exception software provider to hard-code exceptions defined for the system into the product, and therefore require software or system updates to create new exceptions. These updates take time for users to obtain and install, and do not allow users to customize their own systems.

[0055] After a set of exception rules has been created for one or more data sources and these rules are stored in the rules database 124, for example, the quality review management system 112 may then implement the exception engine 122 in real time during operation of the data sources to detect exceptions that may occur as a result of the operation of the underlying process being monitored, controlled, or influenced by the data source application. When set up to run or execute on data from a particular data source, the exception engine 122 periodically or intermittently receives data sets (e.g., metadata) from the data source that indicate various operating parameters of the process and / or application that monitors or controls the process. For each data set, the exception engine 122 retrieves and applies the logic of the exception rules created for the data source, thereby detecting exceptions in the process being implemented, managed, or monitored by the data source. When interfacing or communicating with the data sources, the exception engine 122 may receive data sets from the data source periodically, when some particular action or actions occur within the process or data source, and / or at other set times. The exception engine 122 may subscribe to such data based on data source configuration data in each exception rule for the data source, may poll the data sources for such data at various times, or may implement a combination of these communication techniques. In this manner, when a data source such as the workflow application 40 operates to receive new data and to interface with an operator (e.g., to assist the operator in analyzing batch data, e.g., from the batch executive 22), the workflow application 40 also sends data (periodically or otherwise) to the exception engine 122, which then analyzes the data using the exception rules for the workflow data source application 40 to determine whether one or more exceptions have occurred in the underlying process.

[0056] During this process, the exception engine 122, which is a logic engine, parses the data sent from the data source and applies the logic in the appropriate rule set, such as rule 156A in database 124, thereby analyzing the data according to the rules to detect one or more exceptions. The exception engine 122 may apply the rules to the data one by one in the order specified in the rule set as stored in the rules database 124, and may detect any exceptions as determined by the rules, or may stop processing the data when an exception is detected by any rule in a particular data set. Upon detecting an exception, the exception engine 122 creates an exception record for that data set and stores the exception record in an exception record file 170 (FIG. 2) in database 126. Of course, as each new data set is provided to the exception engine 122 by the workflow application 40 (or other data source), the exception engine 122 processes the data for exceptions, determines whether an exception exists, and then creates and stores an exception in the exception record file 170, as appropriate. The exception engine 122 may store a variety of different types of data associated with an exception record, including, for example, the name of the identified or detected exception, the severity of the exception, the review or resolution procedures applied, any notes entered by the operator as part of the data transmitted from the data source, and general information about the exception. Furthermore, the exception engine 122 may provide metadata as part of the exception record that in some way defines or is associated with the operation of the batch or other process equipment at the time of the exception. This metadata may be provided to the exception engine 122 as part of the data from the data source, or may be obtained by the exception engine 122 from the data source (e.g., workflow application 40) or separately from the data source from a database or other source of that data. The metadata stored in the exception record may be any data that defines some operational parameter, value, state, or other information associated with the process that was being performed at the time the exception was detected.This metadata may be, for example, batch state information, process parameter values ​​as measured or determined from the process, process equipment information, alarm or alert information from the process equipment, or any other information. Additionally, this metadata may be obtained from other sources, such as batch log files 34, process control database or historian 31, process equipment, batch historian 30, or may be provided directly from the data source itself, as part of the initial data processed by the exception engine 122 or in response to a query by the exception engine 122. Generally speaking, the stored metadata provides a snapshot of the process (e.g., process state information, process equipment information, process variable values, batch procedure model state, etc.) at the time the exception was detected. This metadata may be displayed as part of the exception record to enable a quality control engineer to understand the context of the exception (e.g., what was happening in the process at the time of the exception) and thereby better understand the exception and the significance of the exception.

[0057] As will be appreciated, the exception engine 122 operates in real-time, i.e., ongoing in parallel with the data sources, to analyze data from the data sources for exceptions and store exception records for detected exceptions in the exception database 170. The exception engine 122 may operate to receive new sets of data packets from a data source, such as the workflow engine 40, at any time. For example, the exception engine 122 may analyze data from the workflow application 40 as a particular batch process is executed and may stop upon completion of the batch process or instruction. It will be appreciated that the exception engine 122 may operate to simultaneously analyze and detect exceptions for multiple different batch runs from the same data source (e.g., the workflow application 40) and / or may simultaneously analyze data from different data sources. In all these cases, the exception engine 122 may simultaneously create and store exception records for each different batch run of a single data source and / or for each different data source. Thus, the exception engine 122 may understand that different batch runs are occurring at the same time, or that data from different sources is being processed over the same time, and may track these runs and processes separately, creating a different exception database 170 for each batch run, instruction, and / or data source.

[0058] 4 illustrates the operation of the exception engine 122 with multiple different data sources 180, 182, 184, and 186. The data sources 180-186 may be the same type of data source (e.g., different instances of the workflow application 40 running different batches or manufacturing different products) and / or different types of data sources, such as event monitoring applications or systems, third party proprietary systems or applications, etc. In this case, the exception engine 122 and / or the data sources 180-186 are configured to periodically send and receive data packets 188 containing data source metadata to the exception engine 122. These data packets 188 may be formatted to include data from the data sources as specified by metadata configuration information in the rules for the data sources, and these data packets 188 may include an identifier of the data source, instructions to be performed by the data source, metadata of the data source, etc.

[0059] The exception engine 122 receives each data packet 188 from the different data sources 180, 182, 184, and 186 and processes these packets in order as they are received. For each packet 188, the exception engine 122 may determine the identity of the data source and instruction (as specified by the data in the data packet 188), retrieve an appropriate rule set for that data source from the rules database 124, and apply the retrieved rules in a predefined order to the data in the data packet 188 to determine whether an exception exists. If the exception engine 122 has processed all the rules for a data source without detecting an exception, then the exception engine 122 waits for or begins processing the next data packet 188 (from the same or a different data source). On the other hand, if the exception engine 122 detects an exception based on the application of the rule logic to the data source metadata, the exception engine 122 creates an exception record 180 for the instruction and stores the exception record in the exception record database 126 as an exception record file or database 170 for the instruction. That is, all exception records for a particular instruction may be stored as an exception record set for that instruction. In either case, as shown in the diagram of Figure 4, the exception engine 122 may operate simultaneously on data from a variety of different data sources and / or for a variety of different instructions (from the same or different data sources) to create an exception database for each instruction.

[0060] One additional advantage of the exception engine 122 is that it operates in real time, i.e., during the operation of the underlying process, and thus can detect the occurrence of an exception in real time, for example, as the exception occurs. As a result, one feature of the exception engine 122 is that upon detecting the occurrence of an exception, the exception engine 122 can immediately or in real time notify an operator or some other person at or associated with the data source of the existence of the exception, which may enable the operator or other person to take action within the process to mitigate or avoid the exception. In some cases, exception rules may be set to detect exceptions that may occur in the future based on the actions or state of the current process. In this case, the exception engine 122 may detect the occurrence of a possible or likely exception and notify an operator or other user in real time that the exception is likely to occur. This notification gives the operator or other user the ability to undo any action or change any parameter that is the root cause of the future exception before the exception occurs. Thus, using this live feedback, the exception can be avoided or immediately mitigated by enabling the operator or other process monitoring or control person to take action to avoid or reverse the condition that leads to the exception.

[0061] FIG. 5 illustrates a screen display 200 that may be provided, for example, by the workflow application 40 of FIG. 2 to an operator as part of the workflow application 40's normal operation. In this case, the display 200 may provide process information to an operator in the form of a process or workflow diagram 202 and may enable the operator to take one or more certain actions within the process via input fields 204. In this case, the operator may use the input fields 204 in the screen 200 to change the set point of a particular process parameter. However, once the operator enters the new set point, or shortly thereafter, the workflow application 40 sends a data packet to the exception engine 122 with data indicating this change. In this example, the exception engine 122 may be programmed to implement a rule that determines whether the value of the process parameter is within a particular range (as this process parameter may be a critical process parameter for quality purposes). The exception engine 122, upon executing the rule, may detect that if the set point is changed, the critical parameter is set outside of a desired range, thus resulting in an exception. The exception engine 122 may then immediately send a notification to the application 40 via a live feedback message, which may result in a notification or alarm being provided to the operator. For example, as shown in FIG. 5, a pop-up box 206 may be created in the screen 200 based on the live feedback message to inform the operator that the intended or just taken action will (or has) resulted in the creation of an exception record. This message in the pop-up box 206 may instruct the operator to take action to avoid or mitigate the exception (if it has already occurred). Thus, as will be appreciated, rules as created and stored in the rules database 124 for a data source may relate to detecting actual exceptions and / or detecting conditions that may lead to future exceptions.Additionally, the live feedback functionality of the exception engine 122 may be used to enable a user to prevent future exceptions from occurring or to mitigate or reverse the conditions that lead to a currently detected exception. Because this notification is in real-time to the operation of the process, there is a much greater chance of reversing or mitigating the impact of the exception using this live quality feedback technique.

[0062] While Figure 2 illustrates the operation of the quality review management system 112 in a process plant environment 110 where various parts of the system 112 are executed in dedicated servers and databases, the quality review management system 112 may be implemented in a plug-in environment making the system more portable, easier to use on mobile or distributed devices, easier to maintain and implement in a distributed environment, and easier to configure for use with third party systems or applications. In particular, Figure 6 illustrates a quality review management (QRM) system 300 implemented using plug-ins. The quality review management system 300 of Figure 6 includes a quality review service device 302 (which may be stored in and executed on a server or other computing device) communicatively coupled to various data sources 304A, 304B, 304C, etc., a rules database 124, and a configuration application 122. Furthermore, the quality review management service device 302 is coupled to various plug-ins 310, 312, 314, 316, etc., which may be stored and executed in any desired computing device, such as in a workstation, a mobile device such as a laptop, a phone, or any other device, within or outside the plant environment. The plug-ins 312-314 may be created (instantiated and spun off) as needed for any particular instruction or data source. In this case, each plug-in 310-316 may be created for a particular data source and / or a particular instruction within a data source to analyze data from that data source for exception detection. When the instruction or application is completed or terminated, the plug-in may be destroyed.

[0063] Generally speaking, the QRM service device 302 may create specific plug-ins for specific data sources or specific instructions from specific data sources in response to the configuration application 122. Each plug-in 310-316 may include configuration information provided as part of the configuration of the plug-in 310-316 to inform the plug-in 310-316 of the data and data format of the information to be sent to the plug-in 310-316 for evaluation, where to store an exception record file or database for the data source or instruction, and any other desired configuration data required for operation of the plug-in 310-316. Additionally, if desired, the configuration data for the plug-in 310-316 may include one or more rules to apply or analyze based on the received data. Of course, each plug-in 310-316 can be associated with (configured for) the same data source or different data sources, where the configuration information for each plug-in 310-316 can be similar or significantly different depending on the use of the data source or plug-in 310-316. The configuration information for each plug-in 310-316 may specify the data to subscribe to or received from the QRM service device 302, or a third party application or source in operation, and the plug-in 310-316 may register with the QRM service device 302 or other application or source to receive that data. In general, the plug-ins 310-316 may simply operate to obtain specific data from a data source, where they need only be configured to understand what data is coming from the data source and the format of that data. The plug-ins 310-316 may then receive and process the data from the data source, formatting the received data for use in exception rules as created for the data source. In this manner, the plug-ins 310-316 may act as data collection and interpretation applications for any type of data source, even third party or proprietary data sources.

[0064] Additionally, each plug-in 310-316 may include a runtime processing configuration that defines or controls the behavior of the plug-in 310-316 during operation. This runtime section may include a logic parser that uses the rules or logic in the exception rules for the data source to analyze data received from the data source and creates and stores exception records in the exception record database or log 170. In essence, the runtime section of the plug-ins 310-316 implements the exception engine 122 of FIG. 2 on an instance-by-instance basis. Thus, as described above, the plug-in modules 310-316 may be created to interface the exception engine 122 with external or third-party systems (e.g., control systems, OPC interfaces, maintenance management systems, etc.), thereby allowing exceptions to be generated based in whole or in part on data from the third-party or external software systems. In one embodiment, the plug-ins are created to access specific data in or from the third-party or external systems and pass this data to the exception engine 122 to analyze whether an exception should be created. However, the plug-ins 310-316 may be stored and executed within a third party server, within the QRM service device 302, or within another server, mobile device, or other processing device.

[0065] As one example, the configuration application 122 of FIG. 6 may be used to create one or more plug-ins 310-316, including specifying the format of data received from the data source to be analyzed by the plug-in 310-316, how often the plug-in 310-316 should receive data from the data source, the identity of instructions and other information about the data source, the type of application the plug-in 310-316 will be used to process, etc.

[0066] Additionally, the plug-in modules 310-316 may be created with data acquisition and runtime exception handling capabilities, if so desired. Once created, the plug-ins 310-316 may be stored and executed in any convenient location or processing device, such as a device close to the data source or at the data source. Additionally, the plug-ins 310-316 may register with the data service device 302 (or any other server or device) to receive data from an appropriate data source, such as one of the data sources 304. The QRM service device 302 may then subscribe or poll the data source 304 for the appropriate data, and upon receiving a data packet from the data source, may provide the data and one or more exception rules for the data source to the plug-in modules 310-316, which are used to analyze the data. The plug-ins 310-316 may then use one or more rules in their logic engines to analyze the data for exceptions, and upon detecting an exception, may store an exception record for the data source in the exception record database 170. Thus, as can be seen, the QRM service device 302 acts as a data broker for the plug-ins 310-316, which can operate independently of one another on any desired device using any data or data obtained from different sources.

[0067] As will be appreciated, the quality review management system 128 implements the use of plug-ins or plug-in modules for each source to perform the functionality of the exception engine as described herein, allowing the quality review management system to be easily configurable for different data sources, for different quality review criteria, and / or to run in a distributed environment where various different parts of the system run in different computers spread throughout a plant. In this case, a different plug-in can be created for each different type of data source, and each plug-in can have its own set of rules associated with it that are used to perform exception detection from the particular data source.

[0068] Additionally, the plug-in modules 310-316 may or may not perform exception handling and detection in a batch or instruction processing environment. In some cases, for example, one or more plug-ins 310-316 may be created to perform or extend process or event monitoring within a plant, or to perform quality reviews within a plant, such as within a continuous process manufacturing plant. Thus, the plug-ins 310-316 may be simple third-party system data collectors, or may collect data and additionally perform some exception handling, or may provide exception data or pre-processed exception data to a stand-alone exception engine. Using plug-ins to perform quality reviews is advantageous because known quality review products cannot interface with or create exceptions based on data provided directly from external software programs, such as control systems, safety systems, and maintenance management systems. Additionally, the use of a plug-in module environment makes the quality review management system 112 described herein much more robust in complex process environments having multiple different software systems operating during runtime.

[0069] FIG. 7 illustrates one example of a data or event monitoring system that uses the quality review exception handling techniques described herein. In particular, FIG. 7 illustrates a high-level view of a process plant 400 that may execute a continuous process or process equipment. As shown in FIG. 7, the process plant 400 includes process control equipment 402 that may be associated with executing or implementing, for example, a continuous process (such as a crude oil refining process), or a batch process, or both. The process plant 400 may include one or more batch executives 404 connected to the process control equipment 402 and one or more operator interfaces 406 that monitor one or more sections or portions of the process control equipment 402. Furthermore, the batch executives 404 and the operator interfaces 406 may be connected to a master plant control device 410 that may store configuration and control information for the plant 400. Furthermore, the plant 400 may include one or more application servers 411 that may run other applications including, for example, database applications, monitoring applications, plant analysis applications, and the like.

[0070] In many cases, plant assets in the plant 400 run proprietary or third-party control, monitoring, and asset management systems that collect large amounts of data from the plant during operation. Additionally, operator monitoring applications and interfaces 406, batch executives 404, or other control applications may also be inherently prioritized. In the process control arts, it is known to use OPC interfaces to obtain data from various third-party or proprietary applications. Thus, each of the operator interfaces 406 may include an OPC Alarm and Event (OPCae) 412 or an OPC Data Access (OPCda) interface 412, for example, to enable discovery and use of alarm and event data (as generated within the plant 400, such as within the process equipment 402), or other process data used by external systems. Additionally, in some cases, one or more monitoring applications 414 may be stored within one or more plant devices, such as within the application server 411 or a separate event monitor server 416. The event monitoring application 414 may be a known application used to interface with one or more batch executives 404 to obtain process event information (although not necessarily via an OPC interface) and / or may be configured to interface with one or more OPCae or OPCda interfaces 412 to obtain alarm and event data or other data from the process control network 402. The event monitor application 414 is traditionally used to obtain process data, such as event and alarm information, from plant assets and store that data in databases for later review or use in various systems, such as process control analysis systems, maintenance management systems, etc.

[0071] However, the exception handling structure described herein may be used to process alarms and events and other information, such as obtained from the event monitoring application 414, to determine whether a particular plant condition has occurred in or during the operation of the plant equipment 402. Such conditions may include, by way of example only, when a particular event or alarm reaches a critical level, when a particular set or combination of alarms or events occur together, when various process conditions are present, or any other set of conditions that indicate a problem that may need to be brought to the attention of some user, such as a quality review engineer, a safety engineer, etc. To perform this function, the event monitor plug-in 450 of FIG. 7 may be used to access data from one or more event monitoring applications 414 in the plant 400, one or more OPCae and / or OPCda interfaces 412 in the plant 400, etc. The event monitoring plug-in 450 may receive data from the event monitoring applications 414, the OPCae and OPCda interfaces 412 in the plant 400, or other data sources, and may perform exception rule processing to detect the presence of a particular, typically more complex, condition in the plant 400. That is, there may be conditions present in plant 400 that a quality review engineer, safety engineer, maintenance engineer, process control engineer, or others may want to know about, but that are not otherwise detected by the process control or monitoring systems when these systems are set up and operating plant 400. Generally, these conditions may not be determined simply by a single alarm or event notification being generated within plant 400, but may need to be determined by the presence of a more complex set of conditions within plant 400, such as alarms above a particular critical level, a particular number of alarms of any type occurring at or near the same time, alarms of a particular type or severity that are related to one or more other events within plant 400, etc.As will be appreciated, the plug-in module 450 may include or provide access to an exception engine (as otherwise described herein) that operates on rules implementing logic for determining these "exceptions" in the operation of the plant 400. Thus, the event monitor 450 of FIG. 7 may collect data from a third party application (event monitoring application 414) or system (event monitor server 416) or interface (OPCae interface 412) and process this data using a set of pre-configured rules to perform enhanced event detection or process monitoring or exception handling for quality review purposes. In this case, the event monitoring application 450 (which may be located in an environment different from the plant environment, as shown by the dotted lines in FIG. 7) may provide the results of the rules analysis to the monitoring interface 452 and / or a database 454, such as a SQL (Sequel) database, for later review. In essence, the event monitoring plug-in 450 operates to detect "exceptions" in the operation of the plant equipment 402 based on the event monitoring data collected by the plant equipment 402 and provided to a third party application or interface in the plant 400. This type of monitoring is still referred to herein as exception handling, because even if it is not performed as part of a quality review process, this monitoring detects exceptions in the operation of plant 400.

[0072] In either case, the event monitor 450 may be tied to either one or more third party or external systems and may generate and send messages to a rules engine (not shown) which may then use these messages to perform exception handling or exception creation in the form of monitoring messages, notifications, alarms, etc. In one case, the internal event monitor 450 may be tied or coupled to the OPCae interface 412 to recognize when one or more alerts or alarms are passed from the OPCae interface 412. The event monitor application 414 or OPC interface 412 then creates a message with the alert or alarm information and possibly other desired OPC collected data to deliver to the external event monitoring system 450. The system 450 may then analyze the message and generate an exception based on the data in the message. This operation is advantageous because known quality review systems do not analyze data from third party systems and are not connected to existing OPC alert and alarm interfaces. As such, these systems cannot generate exceptions based on process alarms and alerts, for example.

[0073] Generally speaking, the event monitoring system 450 of FIG. 7 can be configured in a number of different ways to collect and process alarm and event data from the process control system 402 and generate an enhanced monitoring system with exception processing. In particular, a user can configure the event monitoring system or module 450, which may be a plug-in as described above, to subscribe to and collect data (e.g., event and alarm data, messages, etc.) as collected by, for example, the OPCae and OPCda interfaces 412 of FIG. 7. The event monitoring server 416 that collects this data can then send this data in a data packet to the event monitoring application 450 along with timing information, process control metadata (obtained from the OPC interface 412, batch executive 404, process computer 410, etc.). The event monitoring system 450 can then apply a set of rules to the data as described above to determine whether an event monitoring exception exists based on the collected event and alarm data and the rule logic. If an exception is determined, the event monitoring system 450 may create a message (based on the rules) and send the message to the monitoring interface 452 for display to the user and / or to a database or message queue 454, for example in the Sequel server. Of course, the rule that generated the exception may specify the content of the message, the format of the message, the information placed in the message, the interface to which the message is sent, etc. Additionally or alternatively, the event monitoring system 450 may create and send an exception record to the monitoring database for storage and later retrieval. This exception record (which is a monitored condition record) may include any desired information based on the rule configuration, such as a description of the event, the severity of the event, instructions for handling the event, process metadata at the time of the event, etc.As will be appreciated, in this case the rule logic for the events is processed within the event monitoring system 450 (or within an exception engine coupled to it) and can be processed within or using a plug-in environment such as in FIG. 6, or within a traditional server environment such as in FIG. 2.

[0074] In another case, the event monitoring system 450 may configure the OPC interface 412 based on its configuration, for example, to detect a particular condition or combination of conditions and then send a message to the event monitoring system 450 when those conditions are met. In this case, the event monitoring system 450 essentially programs the OPCae or OPCda interface 412 to execute the logic of the rules and send a message or data to the event monitoring system 450 only when that logic is met. Upon receiving a message from the OPCae interface 412 with a message indicating that a particular set of conditions or logic has been met, the event monitoring system 450 may simply create and send a communication to the event monitoring interface 452 and database 454 to notify a user of the condition and to store an exception record in the database 454. In this case, the logic of the rules for the event monitoring system is executed in whole or in part within the OPC interface 412 or the external event monitoring application 414, 416, which may be configured using known techniques to send a message only when a particular condition exists within the process plant 400.

[0075] 7, the exception-based processing of the quality review management system described herein may be used to analyze, review, or detect exceptions, for example, in data from a third party system that does not use the same data format as the workflow application 40. Although in the case of FIG. 7, the quality review management system is shown as being used as an event monitoring system interfacing with a batch or continuous process control system via one or more OPC interfaces 412 to determine monitoring-based exceptions based on the presence of various events, alarms, parameter settings, etc., the quality review management system described herein may connect to third party process equipment, servers, applications, etc. via any other desired interface.

[0076] Referring back to FIG. 2 , the quality review interface application 128 may be executed to allow a user, such as a quality review engineer, to access one or more exception record databases 170 for one or more batch runs, instructions, process operations, etc., from a particular data source. The quality review interface application 128 may, for example, allow a user to step through each exception record in the exception database 170 one by one to view the detected exceptions and resolve those exceptions, such as taking any necessary actions to close the exception record. The quality review application 128 may present data or information for each exception record, via an interface screen of the interface device, such as the name of the exception, the type of exception, the severity of the exception, batch metadata or snapshot information stored for the exception record, notes created and stored by an operator associated with or that caused the exception record to be created, and other information provided by the data source. This information allows the quality reviewer to quickly understand the exception and the context of the process (e.g., batch run) at the time the exception occurred to better understand the exception and the significance of the exception. The quality review interface application 128 may also present various other types of information to the user in a structured manner, such as general information about this type of exception, steps that need to be taken to handle or approve an exception of this type or severity, etc. Furthermore, to approve or handle the exception, the quality review interface application 128 may allow the user to take one or more of the various steps necessary to approve or close the exception, such as performing one of a variety of procedures as defined by the original exception rule that detected the exception. The quality review application 128 may, for example, allow the user to acknowledge and approve the exception by clicking a checkbox on a screen, or may require or enforce a process that includes having one or more other people view and approve the exception in order to close the exception.Furthermore, the quality review interface application 128 may send the exception record via email or other network communication to other people to obtain approval of the exception, to ask questions about the exception or to provide data or notes about the exception, to determine more information about the exception, or to take steps necessary to handle or close the exception.

[0077] 8A-8G show various exemplary screen displays that may be created by the quality review interface application 128 to enable a reviewer to view and manipulate exception records, for example, in the process of performing a quality review of an instruction. As one example, FIG. 8A shows a screen display 500 that a reviewer may use to select one of a set of various instructions or exception record files to review. Screen 500 includes a section or field 502 that lists (e.g., in a drop-down menu format) various data sources in which exception record logs 170 exist (e.g., as stored in exception record log database 126 of FIG. 2). Additionally, section 504 may list a set of instructions or exception record files 170 that exist for the data source selected in section 502. Thus, in the exemplary screen 500 of FIG. 8A, field 502 lists the workflow data sources and section 504 lists a number of various exception record files for an instruction or batch run managed by the workflow application. Furthermore, section 506 may list the exception records in a particular file (e.g., instructions) as selected in section 504. The user may scroll down list 506 to select a different one of exception records 506A-506N. Furthermore, section 508 of screen 500 may present information for exception records 506A-N as selected in section 506. In this example, the user selects exception record 506B, and application 128 retrieves information for the selected exception record 506B from exception record log database 126 and displays the information for use and manipulation by the user. Section 508 may include various information for the selected exception record, such as the name, type, severity, information for the exception, and review or handling procedures for the exception.

[0078] Importantly, the information displayed for the exception record may include process or data source metadata 510 as collected from the data source at the time of exception creation. As described above, the quality review management system 112 collects a set of metadata (e.g., may be predefined when creating a plug-in or rule, or may be data known to be provided by a particular data source) when collecting input data from the data source. Generally, the metadata collected is defined by a data transformation configured when creating a rule. The data transformation is applied to the metadata from the data source, and the plug-in outputs this transformed metadata, e.g., in HTML, so that the metadata is viewable in the review application. This data source metadata, which may be any process or environmental data, is generally collected at the same time as the exception input data and stored as part of the exception record created for the exception as a process snapshot associated with the accessed exception data. Thus, when the exception engine 122 detects an exception based on the collected exception data, the exception engine 122 also stores the data source metadata as part of the exception record. The quality review interface application 128 then displays some or all of this metadata, for example, in field 510 of screen 500 reporting the generated exception, thereby providing the reviewer with a live view into the process at the time the exception occurred. This functionality thus provides the reviewer with a quick view of the various process states / values, etc. at the time of the exception, allowing the reviewer to more quickly understand why the exception occurred, the context of the exception, etc., and therefore allowing the reviewer to more quickly handle the exception or know how to resolve it.While this behavior makes quality review easier, known quality review products generally provide the reviewer with a list of exceptions that have been generated, and the reviewer analyzes each exception to determine whether the exception can be dismissed or must be handled in another way; with these known products, the reviewer typically must go back to the process system where the data that led to the exception was collected to obtain process snapshot data at the time of the exception. The live view functionality provided by the metadata field 510 of screen 500 automatically provides the reviewer with a process snapshot that typically contains the process data that is most useful to the reviewer when performing the exception review, meaning that the reviewer does not need to go back to other data collection systems to obtain the information that the user needs to perform the exception review and handling. This functionality also means that the reviewer generally does not need to be familiar with other process data retrieval systems in which process or data source metadata is typically collected, since the reviewer generally does not need to use those data collection systems to access the process data that the reviewer needs to resolve the exception record.

[0079] Furthermore, as shown in FIG. 8A, section 512 may provide the user with a set of options or information regarding how to handle or resolve the exception, such as review steps or procedures, a checklist of actions to take to close the exception, approval fields that need to be filled out or signed by various users to close the exception, etc.

[0080] FIG. 8B illustrates an exemplary screen display 520 showing some of the information for an exception record of type workflow comment. Here, the workflow exception in screen section 506 is the only exception listed for the selected instruction. As shown in section 508 of screen 520, the workflow comment has a status of new, a low severity, does not have or is not associated with a corrective and preventive action (CAPA) identifier (which may be used to define a reference to a third-party system that may also be used to view and / or process the exception), and is not assigned to any group. However, section 508 displays the exception ID (as each exception has a unique ID), a source indicator, and the creation date / time of the exception, all of which data are stored as part of the exception record. Furthermore, section 508 includes a general description of the exception, which may also be information stored as part of the exception record. However, this data may be stored as part of the review application 128 and may be based on the exception type.

[0081] Similarly, the bottom of screen section 508 shows the metadata that has been collected for this particular exception. In this case, the metadata reflects what the user was looking at within the workflow application when the exception was created, and can be used to assist a reviewer in understanding the context of the process when the exception occurred.

[0082] Furthermore, the example screen 530 of FIG. 8C provides a list of solution fields that may be provided to a reviewer in the screen section 508 of FIG. 8B to handle or close the exception record, where the solutions may be configurable as desired (thus, a similar screen may also be used in the configuration application 120 to generate rules for exceptions). In either case, as shown in FIG. 8C, the solution fields may include a name or type of solution 532 (e.g., Standard), a description 534, one or more stage names 536 (e.g., Manufacturing or Manufacturing Supervisor), a severity 538 (e.g., Low), and a signature 539 required by one or more stage personnel to close or resolve the exception. In this case, the solution for the example exception record displayed in FIG. 8C indicates that the exception must be signed by two operators (at the Manufacturing stage) and one supervisor (at the Manufacturing Supervisor stage) in order to close or resolve the exception. These handling procedures may be embodied within sections or fields 512 of Figure 8A in the form of signature boxes, checkboxes, etc. Additionally, the reviewer may be able to change these procedures on an exception by exception basis, or may group exceptions and take action based on the group.

[0083] 8D shows an example screen display 540 including a screen section 508 with a solution field 542 for a selected out-of-range parameter exception as an example. Again, screen 540 includes some information about the selected exception record including the status (active), severity (low), CAPA identifier, and group designation, if any. Solution section 542 includes a field 544 that allows a reviewer to view and attach a file to the exception record (which may be useful when the exception record for the order is later reviewed by a customer, FDA, etc.), and a comment field 546 that allows a reviewer to add a comment or note to the exception record (here, the SA Operations Manager comments that he / she will undertake to close the exception record). Of course, field 546 can be used to add additional comments. Additionally, screen section 508 of screen 540 includes a signature and closure field 548 that may be used by various signatories required to close the exception record. Furthermore, screen section 508 may include a history field 549 that indicates actions taken on the exception record while processing the record, including what action was taken, who took the action, and the time and date of the action. This information may be captured by review interface application 128 and stored as part of the exception record.

[0084] Similarly, various screens presented by quality review interface application 128 may include statistical information about an order or group of orders. For example, section 550 of screen 540 includes an indication 551 of the order being viewed, an indication 552 of the number of exception records associated with the order that have been closed, and an indication 553 of the order's completion status (in this case, the order is not yet completed and is still being processed). Section 550 may also provide links 553 for the reviewer to sign and verify the order or the order's exception records, etc.

[0085] Similarly, screen 560 of FIG. 8E shows additional statistical information that the quality review application 128 may determine and provide to the reviewer on a per-instruction or per-group basis. Screen 560 of FIG. 8E is similar to screen 540 of FIG. 8D, except that section 562 displays various statistical information for the eleven exception records in a selected order. In this case, box 564 shows the number of exception records for the instruction in each status category (new, active, closed). Additionally, bar graph 566 shows the number of exception records for the instruction in each severity category (five low, three medium, two high, and one new). Furthermore, bar graph 568 shows the number of exceptions for the instruction in each exception type (nine out-of-range parameter types and two comment types). Of course, the quality review application 128 may provide other types of statistical information for the exception records, and may provide statistical information in other ways, such as for instruction groups, for a subset of the records in an instruction or group.

[0086] Furthermore, the quality review interface application 128 may allow the reviewer to organize various ones of the exception records into groups and take various actions on the records as a group (comment, change parameters, approve, etc.). As an example, the screens 540 and 560 of Figures 8D and 8E each include three groups of records in the list of exception records: a first group, a second group, and a list of testers 570. The application 128 may allow the reviewer to add exception records to groups, for example, by selecting an exception record in the exception record list 506 and dragging and dropping the selected exception record into a group in the list 570. Of course, the application 128 may allow the reviewer to create new groups, delete groups, etc., in any suitable manner as desired.

[0087] Furthermore, the application 128 may allow the reviewer to take one or more actions on the exception records per group, which saves the reviewer time. FIG. 8F shows an example screen 580 in which the reviewer has selected the group tester for group actions. As a result of this selection, the application displays a pop-up window 582 of possible actions to be taken on the group of exception records in the group tester. Such actions may include changing the severity of the exceptions in the group (via drop-down input box 584), changing the CAPA identifier of the exception records in the group (via drop-down input box 586), adding comments to each exception record in the group (via input box 588), attaching documents to each exception record in the group (via box 590), and signing and closing the exception records in the group via link 592. Of course, the application 128 may allow the reviewer to take any other action or actions on the selected exception record group, and may do so in any other manner via the interface device.

[0088] If desired, the quality review interface application 128 may allow the reviewer to take group actions on exception records that are not actually associated with a group. For example, as shown in the example screen display 592 of FIG. 8G, the reviewer may select the check boxes of various exception records in the list 506 (in the example of FIG. 8G, the first two exception records are so checked). The application 128 may then recognize this as an attempt to take action on both of the checked exception records and may provide a pop-up screen 594 with various edit fields of FIG. 8F. In this case, however, the pop-up box 594 may include grouping actions that can be taken on the selected exception records, such as adding them to an existing group or creating a new group, as shown at the top of the pop-up box 594 of FIG. 8G.

[0089] The quality review interface application 128 as described herein may use advantageous paging algorithms or techniques to allow the reviewer to scroll through various pages of records, such as exception records as provided in the record list 506 of Figures 8A, 8B, and 8D-G, in a manner that reduces or eliminates the presentation of duplicate records in different pages or the missing of records in the display when moving between record pages. Generally, web-based or browser-based display systems that use a browser to display an organized list of records stored in an external structured database, such as an SQL database accessible via a network connection, search for relevant records in the database and then present as many records as will fit on a display page, such as ten records at a time. Thus, these systems typically first display the records in the first ten positions of the returned list. When the user wants to see more records outside of the currently displayed list, the browser contacts the database with the same search to retrieve the next set of records (e.g., the records in the next ten positions) if the user has scrolled down the record list, or the previous set of records (e.g., the records in the previous ten positions) if the user has scrolled up the record list. Of course, there may be many exceptions or records, so when the user scrolls down or up the record list, the interface must scroll through many record pages. Thus, the display system's browser determines all relevant records associated with the query and displays the first page as the first X records in the list (e.g., records 1-10, where X is 10). If the user wants to see records that are not in the first page, the system loads a second page as the second set of X records in the list (e.g., records in positions 11-20 of the list). The system then scrolls the list up or down X positions to present the previous or next page of records.This paging algorithm works well when the record list is static and does not change very often, since the system only loads a set of X contiguous records for each new page.

[0090] However, when the records in the list or search change, such as when some records disappear or fall out of the search because some parameters of the records have changed, or when new records are created in the database, the original list of records found by the search is modified, and these modifications may occur while the reviewer is reviewing one record page and before invoking the next record page. In this situation, as the reviewer processes the records and scrolls down the record list as displayed on the user interface, the records in the database may change, and thus the page data may become out of date. In particular, records may be added to or deleted from the database (or the records may contain parameters that are changed such that the records are no longer returned by a search that follows the search criteria). As a result, when the display system attempts to display the records for the subsequent pages on the display screen, various records referenced in the original search may be missing, causing visible data loss or duplication. In some cases, the user may miss records moving from one page to the next due to the deletion of records on a particular retrieved page. In other cases, the system may become confused about where to start a new display page based on missing records that were in the original returned record list. In yet other cases, the display system may present multiple pages of the same records based on the addition of new records to the database. None of these situations are desirable in a review system where it is important for the reviewer to view and approve each and every record in the list, such as in the case of exception records in an exception record log for an instruction as presented 128 by the application.

[0091] 9A and 9B illustrate the above problems in a typical browser-based display interface that displays records as returned from a search of records stored in a database, where records may be added to or removed from the database or have their parameters changed in the database during the display operation. In particular, FIG. 9A shows a related record list 700 (including records R1-RN) returned from a search of the database at time T1, where records R1-RN may be all records for an order or an ordered list of records based on some other search criteria, such as all open records for an order, all records of a particular severity, etc. In either case, a display system (e.g., a browser in a user interface) may receive list 700 at a first time T1, access the first seven records of list 700, and present these seven records as a first record page in a display screen 704 on the user interface. Thus, display screen 704 includes records R1-R7 as the first record page from the search. At a later time T2, such as when a user requests the next record page, the display system may access the database to obtain the related record list. Assuming no changes have been made to the records in the database, the same record list 700 is returned at time T2 and the display system simply accesses the set of records found in the second set of seven positions on the list (which would be records R8-R14) and displays them as the second page of records in the display 708. This operation, shown in Figure 9A, works well if the ordered record list 700 from the database remains static from time T1 to time T2.

[0092] However, if a record is removed from the related records list (e.g., one or more records have their parameters changed so that the record can no longer be found in a record search) between time T1 when the first page 704 is presented and time T2 when the second page 708 is presented, the display system may inadvertently skip displaying the record. FIG. 9B shows an example in which record R4 is removed (or dropped) from the search list after time T1 when the first page 704 is presented in the display and before time T2 when the second page 708 is presented. In this case, the display system browser retrieves and displays within page 1 704, at time T1, the first seven records R1-R7 based on the list 700 as found in the database of FIG. 9A. However, when the display system browser attempts to access the records for the second page 708 of FIG. 9B, the browser simply accesses and uses the second set of seven records in the returned list 710, i.e., the records at positions 8-14 in list 710 of 9B. At this time, because record R4 has been deleted (possibly closed and removed or dropped from the related records list), record R8, which was originally in the eighth position in list 700 of FIG. 9A when the first page was displayed, is now in the seventh position in list 710 of FIG. 9B due to the deletion of record R4 between time T1 and time T2, so the display system displays records R9-R15 in display 708 as the second page of records. Thus, record R8 is not shown on either the first or second page 704 or 708 of the display of FIG. 9B, and so would be overlooked by the reviewer. Of course, a similar situation occurs when records are added to a list or database during a paging process, but in this case, the addition of records may cause one or more records to be duplicated or presented in consecutive pages, such that a particular record that was originally in a position associated with one page is now in a position associated with a different page at a later time.

[0093] This situation is disadvantageous because when scrolling through pages of exception records that have parameters that can be changed or new records can be added, it results in a situation where related records are skipped in the display or related records are duplicated in different pages of the display.

[0094] However, the quality review application 128 described herein may use a different paging technique for determining which records to present in various pages of the display, which reduces or eliminates duplicate and / or missing records when moving between different pages. In particular, the quality review application 128 does not perform paging using a fixed or preset position or record positions in the record list returned from the database, but instead uses a dynamic paging algorithm that marks one or more records, such as the first record, or the last record, or both the first and last records in the most recently displayed page, and then uses that marker or anchor to find the set of records to display as part of the next page of the display. In this way, if records are added to or removed from the related records list after a page is displayed, the set of records displayed on the next page will be the records in the list adjacent to one of the last displayed records at the time the new page was loaded (e.g., the first or last record on the previous page).

[0095] 10A and 10B illustrate the operation of a new paging algorithm or technique used by the quality review interface application 128. In this case, the related record lists 700 and 710 of FIG. 10A and FIG. 10B, as returned from a database search at time T1 and time T2, respectively, contain the same related record sets as shown in FIG. 9A and FIG. 9B. As shown in FIG. 10A, the interface application 128 presents a first page 704 as the first seven records in the display, but marks the last or bottom record (R7) displayed in the first page 704 with an anchor (referred to as anchor 1 bottom) that indicates the last or bottom record in the currently displayed page. The application 128 may also mark the first or top record (R1) in the display 704 with a top anchor (referred to herein as anchor 1 top) that indicates the top or first record in the currently displayed page. When application 128 then loads the next page of records, page 2, application 128 searches the returned record list for the bottom anchor for page 1 (anchor 1 bottom), regardless of where in the returned list 700 or 710 this record is found. Application 128 then uses the seven records in list 700 immediately following the record marked with the page 1 bottom anchor, anchor 1 bottom, for the record list to display in page 2. Application 128 may then delete the anchor, anchor 1 bottom, but may mark or store additional anchors for the next page of records (i.e., anchor 2 top and anchor 2 bottom) to mark the top and bottom records displayed in page 2 of display 708. Application 128 then uses the record marked with anchor 2 bottom to determine which record to display in the next page (page 3) when the user scrolls down the list on page 2, or uses the record marked with anchor 2 top to determine which record to display in the previous page (e.g., if the user scrolls up the record list on page 2 and returns to page 1).As will be appreciated, this paging technique involves attaching anchors or markers to records or storing anchors or markers that indicate records at various positions on the current display page, and using these anchors to determine which record in the returned record set to use for the first (or last) record on the next page, regardless of the record's actual position in the returned list. Thus, records can move up or down in position within the database or returned list 700 between different page displays without disrupting the paging display in the manner shown in Figures 9A and 9B.

[0096] As an example, FIG. 10A illustrates the operation of the use of anchors when no changes are made to the database between time T1 and time T2, resulting in the presentation of records R1-R7 in a first page 704 and records R8-R14 in a second page 708. FIG. 10B illustrates the operation of the use of anchors in record list 710 when these anchors are used to perform paging between time T1, where the returned record list is list 700 of FIG. 10A, and time T2, where the returned record list is list 710 of FIG. 10B. In particular, display 704 of page 1 includes records R1-R7 based on the state of record list 700 in the database of FIG. 10A at time T1, when page 1 was created. However, when application 128 loaded page 1, it marked record R1 with an anchor named anchor 1 top and marked record R7 with an anchor named anchor 1 bottom. Next, at time T2, when the display application 128 retrieves the record list 710 (now changed since record R4 is no longer in the list) to display page 2, the application 128 searches the returned list 710 for the record marked as the anchor 1 bottom record, and upon finding this record in the list 710, it simply loads and displays the next seven records (in this case records R8-R14) as the display 708 for page 2, even though records R8-R14 are in the seventh through thirteenth positions in the list 710. Of course, the application 128 can mark any number of anchors per page, but generally it has two anchors per page to identify the top and bottom records in the current page, and then loads the records adjacent or adjacent to those anchors when loading subsequent pages. The use of two anchors allows the application 128 to scroll up or down pages in a manner that eliminates or reduces missing records in the display or duplicate records in different pages when the state of records in the list changes (such records are added to or removed from the list).

[0097] The application 128 may use any marking technique, such as storing an index in separate anchor variables of the records at the top and bottom anchor locations (e.g., in a browser or browser device) while a particular page is being displayed, actually storing in a database a marker associated with the record currently at an anchor location in the currently displayed page of records, storing one or more records in the current page as a marker, storing a temporary marker immediately before or after the marked record in the database, etc. Additionally, the marker or anchor may be stored in the application 128, in the browser used by the application 128, in the database in which the records are stored, etc. Furthermore, the application 128 moves or changes the anchor location or marker as new pages are accessed and displayed. Furthermore, the application 128 may use any value as an anchor for a record. For example, the application 128 may use a parameter of the record in which the anchor is located as the anchor, such as the time / date stamp of the record. In some cases, the anchor for a record may be based on or point to some combination of the record's search parameters, or may be some other unique value of the record, such as the record name, an identification number, etc. Similarly, in some cases, the record associated with the marker may be a record that falls off the related searches list. In this case, if the application 128 cannot find the anchor record in the new list (when loading a new page), it changes the anchor to a record in the currently displayed page adjacent to the currently missing anchor record (e.g., the record immediately above or immediately before the bottom anchor in the currently displayed page, or the record immediately below or immediately after the top anchor in the currently displayed page), and then uses the new anchor to determine the set of records in the returned list to present the new display page.

[0098] Thus, the paging algorithm used by the quality review interface application 128 works better than past paging systems in that the new system downloads and presents records on a new display screen starting from the last record displayed on the previous page or screen, regardless of the record's position in the returned list. That is, instead of presenting a new display page associated with the record's position in the original retrieved records list, the system 128 accesses the database (when paging down the list) to find the record in the new list that is currently immediately following the last record on the currently displayed page, so that each time a new set of records is displayed on the screen, the first new record displayed is the record in the new search list (710) that immediately follows the last record displayed in the previous page from the previous search (700). This display system is more accurate as it helps ensure that records are not displayed out of order, that records are not duplicated in multiple display pages, and that records are not missed during a review process in which the user scrolls through various record pages over an extended period of time while changes are made to the records in the database. Furthermore, the review application 128 is more efficient because, as the user scrolls through the records, it only needs to access the database to find as many new records as will fit on a new display page, while still ensuring that all of the relevant records are accessed as the user performs the scrolling operation.

[0099] It should be understood that the quality review management application and batch execution engine, server application, plug-in, etc. described herein can be used and implemented in any desired process plant environment and can be used with any process plant control system using any desired type of process plant control system communication protocol. The applications and routines described herein are preferably implemented in software stored on, for example, a server, workstation, handheld device, or other computer, although the routines may alternatively or additionally be implemented in hardware, firmware, application specific integrated circuits, programmable logic circuitry, etc., as desired. If implemented in software, the routines or applications may be stored in computer readable memory, such as a magnetic disk, laser disk, EPROM or EEPROM, solid state or other storage medium, RAM or ROM of a computer, a handheld device, etc. Similarly, the software may be distributed to users or devices via any known or desired distribution method, including, for example, over a communication channel such as a telephone line, the Internet, on a portable medium such as a computer readable disk, etc.

[0100] Thus, while the invention has been described with reference to specific examples, it will be apparent to those skilled in the art that these examples are illustrative only and are not intended to be limitations of the invention, and that modifications, additions, or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the invention.

Claims

1. 1. A quality review system for use in reviewing the operation of a process, comprising: a rules database storing one or more exception rules, each of the one or more exception rules including logic for identifying a condition associated with one or more exceptions in the process; one or more data sources configured to collect process data within the process during the operation of the process and to transmit the collected process data in one or more data messages; an exception engine that processes the process data in one or more data messages from the data sources using the one or more exception rules in the rule database to determine whether an exception exists based on the process data in the data messages as defined by any of the one or more exception rules, and upon identifying an exception based on one of the one or more exception rules, creates an exception record for the determined exception and stores the exception record in an exception record database; a plug-in module communicatively connected to an external data source and to the exception engine, the plug-in module receiving data from the external data source, analyzing the data from the external data source, and sending external information regarding the external data source to the exception engine, the exception engine detecting one or more further exceptions based on the external information from the plug-in module, and creating and storing one or more further exception records for the one or more further exceptions in the exception record database; a review interface that enables a user to review the exceptions and the further exceptions identified by the exception engine and stored in the exception record database as the exception records and the further exception records.

2. The quality review system of claim 1 , wherein the external data source is a process control system and the plug-in module analyzes process controller data.

3. The quality review system of claim 1 , wherein the external data source is an OPC interface and the plug-in module analyzes OPC data.

4. The quality review system of claim 1 , wherein the external data source receives alarm and event data from the external data source, and the plug-in module analyzes the alarm and event data from the external data source to generate the external information.

5. The quality review system of claim 1 , wherein the exception engine executes within a first server and the plug-in module executes within the first server.

6. The quality review system of claim 1 , wherein the exception engine executes within a first server and the plug-in module executes within a second computing device distinct from the first server.

7. 2. The quality review system of claim 1, wherein the plug-in module performs exception handling on the data from the external data source, the exception handling including obtaining at least one of: (a) event monitoring data; (b) data for exception detection; (c) alarm information; (d) event information; and (e) data for quality review from the external data source.

8. The quality review system of claim 1 , wherein the exception engine analyzes the external information from the plug-in modules using the one or more exception rules in the rules database to detect one or more additional exceptions.

9. The quality review system of claim 1 , wherein the external data source is a safety instrumented system and the plug-in module analyzes safety instrumented data.

10. The quality review system of claim 1 , wherein the external data source is a maintenance management system and the plug-in module analyzes maintenance management data.

Images