Quality review system with metadata collection

Abstract

Provides reviewers with contextual information about detected exceptions, enabling them to better understand and handle the exceptions. A quality review system automatically detects, stores, and displays exceptions in a process for use by a quality review engineer to determine whether the process operation meets specific quality standards. The quality review system includes a configuration application that allows a user to create one or more exception rules, an exception engine that uses the rules to analyze process data and detect one or more exceptions in the process, and a review application that allows a quality reviewer to review each determined exception for resolution purposes. Additionally, the quality review system collects metadata about the process plant to detect the exception or after detecting the exception, and stores the metadata with the exception record for use by the reviewer.

Description

[Technical Field]

[0001] Related Applications This application is a continuation application which claims the benefit of priority from U.S. national stage application No. PCT / US19 / 28138, filed April 18, 2019, entitled "Quality Review Management System," and U.S. patent application Ser. No. 17 / 048,180, filed October 16, 2020, entitled "Quality Review Management System," and which claims the benefit under 35 U.S.C. § 119(e) of U.S. Provisional Patent 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 quality review control systems that enable advanced quality review procedures for the operation of plants, processes, batches, and other operations performed in manufacturing plants. [Background technology]

[0003] Manufacturing plants, such as processing plants, typically produce one or more products from a set of raw or pre-processed materials. Often, the produced products must be of a specific 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. Separate quality reviewers are often tasked with performing various tasks associated with ensuring that the produced products meet a pre-established set of standards or requirements or have been manufactured to specific standards. Such tasks may include reviewing the state or values ​​of various parameters of the manufacturing equipment, materials, or processes used to produce the product to ensure that the proper manufacturing steps were performed, that the product was manufactured under various desired conditions, such as within a specific temperature range, pH range, or pressure range. 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. Therefore, quality review is 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 produce 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 way to ensure the safety of the produced product 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 a product may require or mandate that raw or intermediate materials undergo certain process steps during the manufacturing process, that process equipment undergo certain cleaning procedures within or between manufacturing steps in the manufacturing process, that various parameters, such as temperature, pressure, pH balance, etc., be 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 produced product meets appropriate quality standards, e.g., that the product was produced in accordance with or under pre-established procedures or conditions.

[0005] Process plants used to manufacture various types of products, such as food, oil, and pharmaceuticals, 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.), take measurements within the process plant for use in controlling the operation of the process plant, or 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, for example, carry 4-20 mA (milliamp) signals to or from the field devices. However, over 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 implement communications 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 with the same or similar hardware that performs 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 various 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 to implement the recipe, such as finishing one 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 mixing equipment, then implement a procedure to operate baking equipment on the products produced by the mixing equipment, and then execute a third procedure to control 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 includes procedures to clean, empty, fill, etc., tanks or other vessels 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, a different recipe to be implemented on the raw materials, a different flow or batch procedure, 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 ISAS 88.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 quantity of material by applying a fixed amount of input material to an ordered set of processing operations in a finite amount of time 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 interchangeably herein as equipment, equipment modules, processing devices, and / or physical elements. The procedures that operate 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, "procedure," "unit procedure," "operation," and "phase." 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 element of interest is referred to as a procedure, and a procedure is organized into one or more unit procedures. Each unit procedure is, or can be, in turn organized into one or more operations, each of which can in turn be organized into one or more phases. Furthermore, the S88 procedural model does not preclude the definition and use of other hierarchical levels in particular applications. Rather, the S88 standard and the procedural elements referenced 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 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 directly or indirectly via a local or wide area network. Procedural elements perform assigned or associated tasks by invoking "primitive controls" for at least one physical element. This type of control is typically dedicated to establishing and maintaining a specific desired state of the physical element. Primitive controls include, for example, initiating or maintaining the flow of material in a storage vessel element or heating starting materials in a polyvinyl chloride reactor element. In reality, lower levels (i.e., phases) of a procedural model perform the actual communication with the actual physical elements, thereby invoking or executing the primitive controls. Higher levels of a procedural model are essentially abstractions for refining the organization and structure of the procedural model and 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 multiple process states, along with the actions that cause transitions between those states. The state machine model of a process is said to be in a particular state depending on the previous transition to that state. When a particular event occurs or a particular status is detected, the state machine model transitions to another state corresponding to the particular event or detected status. State machine models are a useful technique for defining and implementing the behavior of procedural elements of a batch process. In particular, procedural elements defined and implemented as state machines initiate actions, for example, when their associated state machine transitions from an old state to a new state.

[0012] Not surprisingly, the S88 standard allows for the definition and implementation of procedural elements according to a standard state machine model. While the S88 standard does not mandate this approach, it has been widely adopted in the process control industry, allowing for a high degree of interoperability among 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, ensuring that 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 initiated by a server program, the phase communicates a start request to a phase logic interface within 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 can be seen 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 the batch run, so that it can be determined whether the batch run to an instruction operated or performed satisfactorily in accordance with applicable quality standards. Such historical data can be useful not only for quality review purposes, but also for determining quality control trends or when equipment used in the 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 within the batch process as the batch is processed. A data point is a single source of such continuous data that reflects some control value or other status or measurement of the batch process. For example, a particular level of material flow rate or material temperature, as measured by a sensor, can be such a data point. Current control valve settings, the time a sample was taken, etc. can be other data points. Each such data point can have a series of continuous data values ​​sensed or controlled over time by its 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 data source.

[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 a process may generate process events indicating one or more specific actions in starting, stopping, or running a particular phase (i.e., the performance of 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 about operator changes to the batch process made during its operation.

[0015] Furthermore, many batch processing systems utilize operator interface programs running on dedicated operator interface devices, such as workstations, to allow operators to view the current state of the 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 the batch run or instruction, etc. One such operator interface program is known as a workflow program (such as the Syncade Workflow program offered 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, allowing 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 can occur during a batch run, such as batch equipment or raw materials being unexpectedly unavailable, or process parameters being outside of expected or desired ranges. 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, workflow programs also allow operators to make notes or store explanations about what was happening in the batch at the time of an 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 for the order's batch run (typically on an order-by-order basis) to ensure that the batch run completed according to or within expected parameters, workflow, 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 refer to a deviation from an expected procedure, process, step, workflow, range, value, etc. in a manufacturing process or plant. Exceptions can 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 the 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 being generated by an operator during a batch run; alarms and events occurring during a batch run;

[0017] In either case, the quality control engineer must identify 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 address or “close” the exception. For example, in many cases, exceptions may represent minimal or insignificant deviations in an 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, exceptions may need to be documented for later review by an authorized agency or by the customer, but their impact may not be significant enough to result in a significant reduction in product quality. In still other cases, exceptions may be significant or severe enough to require one or more additional procedures to be performed on the product to ensure the desired quality or one or more tests to be run on the product to ensure its quality. In still other cases, the quality control engineer may determine, based on the details of the exception, that the product needs to be discarded or sold at a lower quality or labeling standard.

[0018] The process of reviewing batch log files for exceptions is extremely tedious and fraught with problems. In particular, because most data in a batch log file does not indicate an exception, quality control engineers spend a significant amount (usually most) of their review time searching for data that is not actually associated with any exceptions. Furthermore, quality control engineers must note all conditions that could 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. While the presence of batch process alarms and alerts or notes from operators stored in a batch log file may indicate the presence of an exception, this is not always the case, and, of course, not all exceptions that occur may reach a level where they can be documented with operator notes or where an associated alarm or alert is 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 control 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 alarms or events were generated by 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 effort 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 obtain a snapshot of a batch process at a particular time and display that data to a quality control engineer to view the operation of the 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., the subprocedures and subprocesses associated with the batch), thereby understanding 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 actually be stored in different databases. This makes it difficult for a quality control engineer to obtain a comprehensive view of 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 the 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) can be used to analyze the operation of one or more manufacturing processes as collected by various 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 allows a quality review administrator or engineer to review and address (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 enables 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 data messages, such as data messages provided periodically by data sources such as plant or process control systems, batch executives, operator workflow applications, 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, and time of the procedure or steps taken to resolve or handle the exception, and process data related to the operation of the process at which the exception occurred. 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 users to create configurable exception rules to run in the exception engine to define or detect exceptions. The configuration environment can store a set of rule templates that can process various types of input data to detect exceptions. In the configuration environment, users can 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 is analyzed against the configured rules, and if any rule criteria are met, an exception is created. The exception can then be checked immediately. A typical known review by exception product requires exception software providers to hard-code the defined exceptions into the product, thus requiring 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 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 stored in the exception database as exception records for the 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 about 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 process context at the time the exception occurred, and the severity of the exception. Furthermore, the review interface may allow the reviewer to take various actions regarding 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 types of people (e.g., reviewer only, 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., to be stored with the exception record for later use by the customer, quality review organization, etc.

[0025] The review interface may store 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 whether 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, or 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 or annotating all the exception records in the group.

[0026] In this way, a quality review management system can 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 will 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 required. Similarly, the quality review management system can 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 specific ways, 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 the 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 within the third-party server, the RBE server, or 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 exception or preprocessed 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 with 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 simultaneously 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 may additionally display some or all of the metadata when reporting the generated exception, thereby providing a user or reviewer with a live view of the process at the time the exception occurred. The system provides the user with a quick view of 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 return to the process system where the data that resulted in the exception was collected to understand other things about the process at the time of the exception (e.g., whether the process was 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 generally contains the process data that is most useful to the reviewer when performing an exception review, meaning that the reviewer does not have to return to other data collection systems to obtain the information the user needs to perform the exception review. This feature also means that because the reviewer does not need to use other process systems where data is collected to access the process data the reviewer needs, the reviewer generally does not need to be familiar with those systems.

[0032] In another example, an RBE or quality review system can be tied to a third-party or external system and 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 can be tied or coupled to an OPC alert and alarm monitoring interface and can recognize when one or more alerts or alarms are passed to the OPC interface. At this point, the event monitor creates a message using 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 the 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 example, the review system implements a novel paging algorithm when presenting a list of generated exceptions to a reviewer. Generally, the RBE system creates / detects exceptions and stores them as records in a structured database, such as an SQL database. Then, when presenting the list of exceptions to the reviewer on a 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 retrieved page portion in the order downloaded from the database as the user scrolls through the various exception record pages. However, as the reviewer processes exceptions and scrolls down the exception list as displayed on the user interface, records may change in the database, and thus the page data may become outdated. In particular, records may be added or deleted from the database. In this case, when the system attempts 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 moving from one page to the next due to records on a particular retrieved 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 exist 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 in which the user scrolls down various record pages over an extended period of time. Additionally, the RBE system is more efficient because, as the user scrolls through 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 explanation of the drawings]

[0036] [Figure 1] FIG. 1 is a block diagram of a typical process or manufacturing plant including a process control network, a batch executive, and a workflow application that allows operators to manage batch processes and store batch log files for quality review. [Figure 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. [Figure 3] 10 is an exemplary screen display produced by a configuration application of the quality review management system of FIG. 2 that allows a user to create one or more exception rules for use by the exception engine. [Figure 4] 10 is a flowchart illustrating the operation of the exception engine of the quality review management system of FIG. 2 when analyzing data from multiple data sources for exception processing. [Figure 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. 1 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 illustrates 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 illustrates 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 illustrates 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 illustrates 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 illustrates 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 illustrates 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 illustrates 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] FIG. 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] FIG. 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 INVENTION

[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, which 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 implement 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 and may 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 executing 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, which may be located, for example, in a business environment remote 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 networks (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 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 a 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 retrieve and display data from the batch executive 22. This data may include status data for the batch in progress, parameter data, measurement data, progress data, batch procedure model state data, etc., as retrieved by the batch executive 22. This information or data may include indicators such as the instruction being executed, the materials and processes associated with the instruction (e.g., the recipe and batch procedure model to be executed), alarm and alert data from the batch executive 22 and / or the process control network 20, etc. Any or all of this data may be stored as a batch log file 34 in a batch log file database 32, as is typical for a batch executive routine.

[0039] As is commonly 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 within or regarding 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 time discrepancies, batch parameters that may be out of range based on what the batch executive 22 is expecting, etc. The workflow application 40 may allow the operator to take various actions, as is known, to restart a batch run, select different equipment for a batch run, operate with different raw materials, instruct the batch executive to start, shut down, or skip a procedure, or 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 manner or within the allotted time frame. In either case, the workflow application 40 may allow 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 in 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 provide the data to.

[0040] As is known, a batch log file or batch report 34 for a batch run is generated during the batch run, and the batch log file 34 is completed after the batch run or instruction 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 within 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. Furthermore, most of the quality control engineer's time is spent simply looking at data or information from the batch report that is not associated with specific exceptions or deviations from expected actions within 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 the engineer to have the know-how to access and view that data efficiently and accurately using these other data access applications.

[0041] Figure 2 illustrates a plant environment 110 similar to the plant environment 10 of Figure 1, with similar structures, applications, and data having 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. Accordingly, 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 the 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 on, and executed on computer or processor devices within the plant environment 110. 2, the quality review management system 112 includes a configuration application 120 stored in the memory of and executing on a processor of a processing device 121, an exception engine 122 stored in the memory of and executing on a processor of a server 123, a rules database 124, an exception record database 126, and a quality review interface application 128 stored in the 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 different from computing devices 26, 28, 30, 31, and 32 in FIG. 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 enable 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 can 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 enables a user to create configurable exception rules that execute within the exception engine 122 to define or detect exceptions. The configuration application 120 may store a set of rule templates that can process various types of input data to detect exceptions using any desired type of logic or logical expression, 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 the expressions to 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 one example, FIG. 3 illustrates a screen display 150 that configuration application 120 may create and provide to a user (e.g., a configuration engineer, a quality review engineer, etc.) via 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 exception rule database 124. In particular, 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, exception rules 152 may include a different exception rule set 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 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 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, 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 , configuration application 120 may create a screen containing a number of different sections, including rule template section 156, data source section 158, rule list section 160, and rule configuration section 162. Rule template section 156 may include a set of icons representing 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 rules database 124, on the same device as configuration application 120, or in any other database or computer memory. Data source section 158 may include icons representing various different data sources for which a user may create exception rules. Icon 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. Rule list section 160 may store a rule list for a particular selected data source and specify the order of rule execution when analyzing data from the data source.

[0046] In operation, a user may select a data source 158A from data source section 158 to specify a data source for which a rule should 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 rule list section 160, e.g., 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 into rule configuration section 162, causing application 120 to load configuration data for the selected template rule into various portions or fields of configuration section 162. If desired, 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 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] 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 rule configuration section 162. Essentially, application 120 allows a user to specify the rule configuration information needed to process data from the data sources for the purpose of detecting and handling exceptions in the operation of the process monitored by the data sources. Generally, each rule stores logic, such as Boolean logic, 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 enable 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., workflow application 40, batch executive 22, 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 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 within 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, exception rules may specify any desired logic to be applied to particular data from a data source to determine whether an exception exists.

[0048] Thus, as shown in example screen 150 of FIG. 3 , rule configuration section 162 includes a name field 162A that may be used to specify the name of the exception rule, a severity field 162B that may be used to specify the 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 the logic to be applied by exception engine 122 ( FIG. 2 ) to detect whether an exception exists. Naturally, logic field 162C may accept or enable 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 (e.g., C++, HTML), 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 needed 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. Configuration application 120 may allow a user to select one of 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 formats 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.), transformations may be variable name changes (to match various variable names used in the logic with 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 the 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 severe exceptions) before other types of exceptions (e.g., less severe exceptions). For example, in many cases, applying different exception rules to a particular data set from a data source may result in the detection of 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, during operation, the rule order (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, so that 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 noted above, rules section 160 may store a list of rules for a source in the order in which those rules are to be 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 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 within list 160, and drop the rule into a new position within list 160 to change the order of rule execution. Of course, application 120 may allow a user to change the order of 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 resolution field 162F that may enable a 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. However, in some cases, 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 resolution may simply be a definition of a set of signatures required to close the exception, or the resolution may simply execute one or more signatures required to close the exception. In these cases, the resolution may include a description or set of instructions indicating other actions (steps) to be completed prior to signing, although in these cases the resolution may not monitor or execute other actions. The handling procedures specified in the rules may be preset or 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 accepting and storing information to be provided to a quality review engineer along with or as part of an exception record created by the application of a rule. 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 a quality review engineer when viewing or working with an exception record created by the application of a rule. 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 should be displayed. Generally, when processing an exception record, it is helpful for a 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. Therefore, configuration field 162G may indicate what data source metadata should be provided to a 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 any desired manner as part of the exception rules in rules database 124. As will be appreciated, this configuration information may include the identity of needed data from the data sources, which 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, so 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 existence 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 (such as 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., 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 offers significant advantages over known products that require exception software providers to hard-code defined exceptions 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 systems.

[0055] After a set of exception rules has been created for one or more data sources and these rules have been 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 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 periodically receive data sets from the data source when some particular action or actions occur within the process or data source, and / or at other configured 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 source for such data at various times, or may implement a combination of these communication techniques. In this manner, when a data source such as a workflow application 40 operates to receive new data and to interface with an operator (e.g., to assist the operator in analyzing batch data from, for example, 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, exception engine 122, 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 and detecting one or more exceptions. Exception engine 122 may apply the rules to the data one by one in the order specified in the rule set as stored in 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, exception engine 122 creates an exception record for that data set and stores the exception record in exception record file 170 ( FIG. 2 ) in database 126. Of course, as each new data set is provided to exception engine 122 by workflow application 40 (or other data source), exception engine 122 processes the data for exceptions, determines whether any exceptions exist, and then creates and stores exceptions in 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, as part of the exception record, metadata 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 an 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 databases or historians 31, process equipment, batch historians 30, etc., or may be provided directly from the data sources themselves, either 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 its significance.

[0057] As will be appreciated, the exception engine 122 operates in real time, i.e., 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 of 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 period of 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 for the data source, instructions to be performed by the data source, metadata for the data source, etc.

[0059] The exception engine 122 receives each data packet 188 from 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 the 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 applying 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 the 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., while the underlying process is operating, and therefore 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 allow the operator or other person to take action within the process to mitigate or prevent the exception. In some cases, exception rules may be configured to detect exceptions that may occur in the future based on current process actions or states. In this case, the exception engine 122 may detect the occurrence of a possible or impending 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 an operator or other process monitoring or control person to take action to avoid or reverse the conditions leading to the exception.

[0061] FIG. 5 illustrates a screen display 200 that may be provided to an operator by, for example, the workflow application 40 of FIG. 2 as part of the workflow application'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 allow the operator to take one or more actions within the process via input fields 204. In this case, the operator may use the input field 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 (because this process parameter may be a critical process parameter for quality purposes). Upon executing the rule, the exception engine 122 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 data sources may relate to detecting actual exceptions and / or detecting conditions that may lead to future exceptions.Additionally, the live feedback capabilities of the exception engine 122 may be used to enable users to prevent future exceptions from occurring or to mitigate or reverse the conditions that lead to a currently detected exception. Because this notification is real-time relative 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 in which various portions of the system 112 are executed within a dedicated server and database, 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 within 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 or phone, or any other device, inside or outside the plant environment. 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 completes or terminates, 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 plug-in's 310-316 configuration 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, the location to store the exception record file or database for the data source or instruction, and any other desired configuration data required for the plug-in's 310-316 operation. 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 or different data sources, whereby 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 an operating third-party application or source, and the plug-in 310-316 may register with the QRM service device 302 or other application or source to receive that data. Generally, the plug-ins 310-316 may simply operate to obtain specific data from the data source and may be configured to understand which 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, such as those created for the data source. In this manner, the plug-ins 310-316 can 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 create and store exception records in the exception record database or log 170. Essentially, the runtime section of the plug-ins 310-316 implements the exception engine 122 of FIG. 2 on a per-instance basis. Thus, as described above, the plug-in modules 310-316 may be written 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-in is written to access specific data in or from the third-party or external system 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 frequently 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 proximate to the data source or at the data source. Furthermore, 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 to or poll the data source 304 for 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 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 each other 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 on a per-source basis 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 the 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 to be 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 processing, or may provide exception data or preprocessed exception data to a stand-alone exception engine. Performing quality reviews using plug-ins 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. Furthermore, the use of a plug-in module environment makes the quality review management system 112 described herein much more robust in complex process environments with 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 implement 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, for example, running or implementing a continuous process (such as a crude oil refining process), 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, etc.

[0070] Plant assets within the plant 400 often 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 inherently prioritize. In the process control arts, it is known to use OPC interfaces to obtain data from various third-party or proprietary applications. Accordingly, 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 in 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 in 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. Event monitor applications 414 are 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 those obtained from the event monitoring application 414, to determine whether a particular plant condition has occurred within 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 exist, or any other set of conditions that indicate a problem that may require 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 within the plant 400, one or more OPCae and / or OPCda interfaces 412 within 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, or other data sources within the plant 400, and may perform exception rule processing to detect the presence of specific, typically more complex, conditions within the plant 400. That is, conditions may exist 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 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 exceeding a particular criticality level, a particular number of alarms of some 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 with 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 indicated by the dotted line in FIG. 7) may provide the results of the rule analysis to the monitoring interface 452 and / or a database 454, such as an SQL (Sequel) database, for later review. Essentially, 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 within the plant 400. This type of monitoring is still referred to herein as exception handling, because even if 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 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 uses the alert or alarm information, and possibly other desired OPC-collected data, to create a message and deliver it 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 behavior 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 Figure 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 use exception handling to create an enhanced monitoring system. 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 interface 412 of Figure 7. The event monitoring server 416 that collects this data can then send this data in data packets to the event monitoring application 450 along with timing information, process control metadata (obtained from the OPC interface 412, the batch executive 404, the 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, within the Sequel server. Of course, the rule that created 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 monitoring condition record) may contain 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 thereto) 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, to detect, for example, 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 certain conditions exist 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 in data from third-party systems that do not use the same data format as workflow application 40, for example. 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 implemented 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, view detected exceptions, and resolve these exceptions, such as taking any necessary actions to close the exception record. The quality review application 128 may present, via an interface screen of an interface device, data or information for each exception record, 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 causing 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 its significance. 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 exceptions 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 various steps necessary to approve or close the exception, such as performing one of various 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 to close the exception, including having one or more other people view and approve 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 for 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 instruction 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 reside (e.g., as stored in exception record log database 126 of FIG. 2). Additionally, section 504 may list the set of instruction or exception record files 170 that reside for the data source selected in section 502. Thus, in the exemplary screen 500 of FIG. 8A, field 502 lists the workflow data source, and section 504 lists a number of various exception record files for the instruction or batch run managed by the workflow application. Furthermore, section 506 may list the exception records within 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 the exception was created. As described above, the quality review management system 112 collects a set of metadata (e.g., which may be predefined when creating a plug-in or rule, or which may be data known to be provided by a particular data source) when collecting input data from the data source. Generally, the collected metadata 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, for example, 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 contemporaneously with 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 reviews easier, known quality review products generally provide the reviewer with a list of generated exceptions, and the reviewer analyzes each exception to determine whether the exception can be dismissed or handled in other ways. With these known products, the reviewer typically must return 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 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 return to other data collection systems to obtain the information the user needs to review and handle the exception. This functionality also means that the reviewer generally does not need to be familiar with other process data readout systems where process or data source metadata is typically collected, because the reviewer generally does not need to use those data collection systems to access the process data 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 shows an example 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 preventative 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 (since each exception has a unique ID), a source indicator, and the creation date / time of the exception; all of this data is 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 also 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 the reviewer in understanding the context of the process when the exception occurred.

[0082] Furthermore, example screen 530 of FIG. 8C provides a list of solution fields that can be provided to a reviewer in screen section 508 of FIG. 8B to handle or close the exception record. Here, the solutions can be configurable as desired (thus, a similar screen can also be used in configuration application 120 to create rules for exceptions). In either case, as shown in FIG. 8C, the solution fields can include a solution name or type 532 (e.g., Standard), a description 534, one or more stage names 536 (e.g., Manufacturing or Manufacturing Supervisor), a severity level 538 (e.g., Low), and signatures 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) to close or resolve the exception. These handling procedures may be embodied in 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] FIG. 8D shows, as one example, an example screen display 540 including screen section 508 with a resolution field 542 for a selected out-of-range parameter exception. Again, screen 540 includes some information about the selected exception record, including the status (active), severity (low), CAPA identifier, and group designation, if any. Resolution section 542 includes field 544, which allows a reviewer to view and attach files to the exception record (which may be useful when the exception record for the order is later reviewed by a customer, FDA, etc.), and comment field 546, which allows a reviewer to add comments or notes to the exception record (here, the SA Operations Manager comments that he or she will undertake to close the exception record). Naturally, field 546 can be used to add additional comments. Additionally, screen section 508 of screen 540 includes a signature and closure field 548, which 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 indicator 551 of the order being viewed, an indicator 552 of the number of exception records associated with the order that have been closed, and an indicator 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 eleven exception records in a selected order. In this case, box 564 indicates the number of exception records for the instruction in each status category (new, active, closed). Additionally, bar graph 566 indicates 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 indicates 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 exception records, or may provide statistical information in other ways, such as for instruction groups, instructions, or subsets of records within a 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 (e.g., comment, change parameters, approve, etc.). As one example, screens 540 and 560 of FIGS. 8D and 8E each include three groups of records in the list of exception records: a first group, a second group, and a tester list 570. The application 128 may allow the reviewer to add an exception record to a group, 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 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 by group, which saves the reviewer time. FIG. 8F shows an example screen 580 in which the reviewer selects a group tester for a group action. 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 group of exception records, 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 example screen display 592 of FIG. 8G, the reviewer may select the check boxes of various exception records in list 506 (in the example of FIG. 8G, the first two exception records are so checked). 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. However, in this case, 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 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 a reviewer to scroll through various pages of records, such as exception records as provided in the record list 506 of FIGS. 8A, 8B, and 8D-8G, in a manner that reduces or eliminates the presentation of duplicate records in different pages or the loss 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, e.g., 10 records at a time. Thus, these systems typically first display the records in the first 10 positions of the returned list. When the user wants to see more records beyond the currently displayed list, the browser contacts the database with the same search, retrieving the next set of records (e.g., the records in the next 10 positions) if the user scrolls down the record list, or the previous set of records (e.g., the records in the previous 10 positions) if the user scrolls up the record list. Naturally, there may be many exceptions or records, so when a user scrolls down or up the record list, the interface must scroll through many pages of records. 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., if X is 10, then records 1-10). If the user wants to see records that are not on 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 in the list). The system then scrolls up or down the list 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 consecutive records for each new page.

[0090] However, if the list or records being searched change—for example, if some records disappear or are removed from the search because some parameters of the records have changed, or if new records are created in the database—the original list of records found by the search will change, and these changes may occur while the reviewer is reviewing one page of records but before calling up the next page of records. 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 outdated. In particular, records may be added to or deleted from the database (or the records may contain parameters that change such that the records are no longer returned by a search that conforms to the search criteria). As a result, when the display system attempts to display records for 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, users 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 the same record on multiple pages 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 by the application.

[0091] 9A and 9B illustrate the above-described problem 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 deleted from the database or their parameters may be changed within 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. Records R1-RN may be all records for the command, or an ordered list of records based on some other search criteria, such as all open records for the command, 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 the 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 retrieve 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 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's browser retrieves and displays the first seven records R1 through R7 in page 1 704 at time T1 based on the list 700 as found in the database of FIG. 9A. However, when the display system's browser attempts to access the records for the second page 708 in 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 through 14 in list 710 of 9B. At this time, because record R4 has been deleted (perhaps 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, causing the display system to display records R9-R15 as the second page of records in display 708. Therefore, record R8 is not shown on either the first or second page 704 or 708 of the display of FIG. 9B , and thus would be overlooked by the reviewer. Of course, a similar situation occurs when records are added to a list or database during the paging process, but in this case, the addition of records may cause a particular record originally in a position associated with one page to be placed in a position associated with a different page at a later time, resulting in one or more records being duplicated or presented in consecutive pages.

[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 can result in related records being skipped in the display or related records being 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 navigating between different pages. In particular, the quality review application 128 does not perform paging using a fixed or preset position or record locations 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 records last displayed 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 novel paging algorithm or technique used by the quality review interface application 128. In this case, the related record lists 700 and 710 of FIGS. 10A and 10B, as returned from a database search at times T1 and T2, respectively, contain the same related record sets as shown in FIGS. 9A and 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 herein as anchor1bottom) indicating 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 anchor1top) indicating 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 looking for the bottom anchor for page 1 (anchor 1 bottom), regardless of where this record is found in returned list 700 or 710. 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 point to records at various positions on the current display page, and using these anchors to determine which record in the returned record set to use as 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 one example, Figure 10A illustrates the use of anchors in action 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. Figure 10B illustrates the use of anchors in record list 710 in action when these anchors are used to perform paging at time T1, where the returned record list is list 700 of Figure 10A, and at time T2, where the returned record list is list 710 of Figure 10B. In particular, display 704 of page 1 includes records R1-R7 based on the state of record list 700 in the database of Figure 10A at time T1, when page 1 was created. However, when application 128 loaded page 1, it marked record R1 with the anchor named anchor1-top and record R7 with the anchor named anchor1-bottom. Next, at time T2, when display application 128 retrieves record list 710 (now modified because record R4 is no longer in the list) to display page 2, application 128 searches the returned list 710 for the record marked as the anchor 1 bottom record, and upon finding this record in list 710, simply loads and displays the next seven records (in this case, records R8-R14) as display 708 for page 2, even though records R8-R14 are in positions 7 through 13 in list 710. Of course, application 128 can mark any number of anchors per page, but generally has two anchors per page to identify the top and bottom records in the current page, and then loads 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 when the state of a record in the list changes (such as when such a record is added to or removed from the list) in a manner that eliminates or reduces missing records in the display or duplicate records in different pages.

[0097] The application 128 may use any marking technique, such as storing indicators in separate anchor variables of records at top and bottom anchor locations (e.g., within a browser or browser device) while a particular page is displayed, actually storing a marker in a database associated with a record currently at an anchor location within the currently displayed page of records, storing one or more records within the current page as markers, or storing a temporary marker immediately before or after the marked record in a database. Additionally, the marker or anchor may be stored within the application 128, the browser used by the application 128, the database in which the records are stored, etc. Furthermore, the application 128 may move or change 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 on which the anchor is located, such as the time / date stamp of the record. In some cases, the anchor for a record may be based on or indicate the record's search parameters or some combination of 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 a 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 performs 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 record list, the system 128 accesses the database (when paging down the list) to find the record in the new list that currently resides immediately after 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 because 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 process.

[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 can be distributed to users or devices via any known or desired distribution method, including, for example, via a communications channel such as a telephone line, the Internet, etc., on a portable medium such as a computer-readable disk, etc.

[0100] Thus, while the present 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 monitoring the operation of a process, comprising: a rules database storing a plurality of rules, each of the plurality of rules (i) including logic that identifies a set of conditions that indicate an exception has occurred in a process, and (ii) identifying a data source, the logic being applied to data from the data source to determine whether the set of conditions exists in the data from the data source, wherein each rule of the plurality of rules is created for a specific product type and is configurable for different quality standards, and each rule is configurable to be executed in a predetermined order based on the exception type; one or more data sources configured to collect process operational data from the process during the operation of the process and to transmit the collected process operational data in one or more data messages, the process operational data including process data and process metadata identifying one or more process operating conditions at the time of collection; an exception engine stored on a memory of a computing device and executed by a processor, the plurality of rules configuring the exception engine for detecting exceptions that occur during execution of a process by process equipment of a process plant; The exception engine further comprises: determining whether an exception has occurred in the process according to each rule of the plurality of rules based on applying the logic of the plurality of rules to the process data in the one or more data messages; and identifying the exception based on the each rule. creating an exception record for the identified exception, the exception record having the collected process metadata associated with the process operational data, the process data including the process data indicative of the exception; an exception engine configured to store the exception records in an exception record database; a review interface that accesses the exception record database and presents, via a user interface, information about one or more identified exceptions in the exception records of the exception record database, the information being generated based on the process metadata stored for the exception records, and the information including one or more handling procedures for resolving the exceptions that have already occurred according to the respective rules. Quality review system.

2. 2. The quality review system of claim 1, wherein the one or more data sources collect the process metadata for a set of process data simultaneously with collecting the process data.

3. 3. The quality review system of claim 1, wherein when the exception engine detects an exception in process data sent from one of the data sources, the exception engine sends an instruction to the one of the data sources to collect the process metadata.

4. 4. The quality review system according to claim 1, wherein the process metadata includes process environment data.

5. 4. The quality review system of claim 1, wherein the process metadata includes one or more process variable values ​​or process states.

6. 4. The quality review system of claim 1, wherein the process metadata includes a process snapshot that includes predetermined process operation data that is useful to a reviewer when performing an exception review.

7. 7. The quality review system of claim 1, wherein the one or more data sources include a workflow application that controls the operation of the process and executes different stages of the process.

8. 7. The quality review system of claim 1, wherein the one or more data sources include a batch executive application that controls the operation of a batch process and executes different batch stages of the batch process.

9. 7. The quality review system of claim 1, wherein the one or more data sources include a batch historian or a process historian connected to the process.

10. 10. The quality review system of claim 1, wherein the process data includes one or more of batch state data, batch parameter data, batch process measurement data, batch progress data, and batch procedure model state data.

11. 10. The quality review system of claim 1, wherein the process data includes one or more of the following: batch instructions to be executed, materials and processes associated with the batch instructions, and instructions for a batch recipe or batch procedural model to be implemented.

12. 10. The quality review system of claim 1, wherein the process data includes one or more of process parameter data, batch status data, batch status change data, batch alarms, or batch alerts.

13. 10. The quality review system of claim 1, wherein the process data includes one or more indications of batch procedure start and stop times, or events, or batch procedure model state changes.

14. 14. The quality review system of claim 1, wherein the process metadata includes process data sent to other process databases including one or more of a batch log file, a process control historian, a process equipment historian, or a batch historian.

15. 14. The quality review system of claim 1, wherein the process metadata includes one or more of: process variable values; batch procedure model states; recipe information; instruction names; materials for instructions; process flows for instructions; process equipment used in instructions; workflows applied to instructions; or batch procedure models used in instructions.

16. 14. The quality review system of claim 1, wherein the process metadata includes data indicating the behavior of the process at the time of an exception.

17. 14. The quality review system of claim 1, wherein the process metadata includes data batch status information, process parameter values ​​measured or determined from the process, process equipment information, or alarm or alert information from process equipment.

18. 1. A quality review system for use in monitoring the operation of a process, comprising: one or more data sources configured to collect process operation data within the process during operation of the process; an exception detection system coupled to the one or more data sources, a rules database storing a plurality of rules, each of the plurality of rules including: (i) one or more exceptions, logic defining instructions for the process data that is applied to logic to determine whether the one or more exceptions exist based on the process data, and a set of process metadata associated with the one or more exceptions; and (ii) identifying a data source, and the logic is applied to data from the data source to determine whether the one or more exceptions exist; wherein each rule of the plurality of rules is created for a specific product type and is configurable for different quality standards, and each rule is configurable to be executed in a predetermined order based on the exception type; a communication interface communicatively coupled to the one or more data sources and configured to receive process data from the one or more data sources at different times during operation of the process and configured to retrieve the process metadata associated with the one or more exceptions; an exception engine stored on a memory of a computing device and executed by a processor, the plurality of rules configuring the exception engine for detecting exceptions that occur during execution of a process by process equipment of a process plant; The exception engine further comprises: determining whether an exception exists as defined by any of the plurality of rules based on applying the logic to a set of process data; identifying an exception based on each rule of the plurality of rules; creating an exception record for the identified exception, the exception record having the process metadata for the identified exception; an exception engine configured to store the exception records in an exception record database; and a review interface that accesses the exception record database and presents, via a user interface, information about one or more identified exceptions in the exception record database, the information being generated based on the process metadata stored for the exception record of each of the one or more identified exceptions, the information including one or more handling procedures for resolving the exceptions that have already occurred in accordance with the respective rules. Quality review system.

19. 20. The quality review system of claim 18, wherein the exception engine obtains the process metadata from the same data source as the process data.

20. 20. The quality review system of claim 19, wherein the communication interface is configured to simultaneously receive the process metadata as the process data.

21. 20. The quality review system of claim 19, wherein the exception engine identifies a determined exception based on received process data and then requests the process metadata for the determined exception.

22. 20. The quality review system of claim 18, wherein the exception engine obtains the process metadata as the process data from different data sources.

23. 23. The quality review system of claim 22, wherein the exception engine, after identifying a determined exception based on received process data, requests the process metadata for the determined exception via the communication interface.

24. 23. The quality review system of claim 22, wherein the exception engine receives the process metadata along with a set of process data before analyzing the process data with one of the rules.

25. 25. A quality review system according to any of claims 18 to 24, wherein the one or more data sources comprise a workflow application that controls the operation of the process and executes different stages of the process.

26. 25. The quality review system of any of claims 18 to 24, wherein the one or more data sources comprises a batch executive application that controls the operation of a batch process and executes different batch stages of the batch process.

27. 25. The quality review system of claim 18, wherein the one or more data sources comprises a batch historian or a process historian connected to the process.

28. 28. The quality review system of claim 18, wherein the process data includes one or more of batch state data, batch parameter data, batch process measurement data, batch progress data, and batch procedure model state data.

29. 28. The quality review system of claim 18, wherein the process data includes one or more of process parameter data, batch status data, batch status change data, batch alarms, and batch alerts.

30. 30. The quality review system of any of claims 18 to 29, wherein the process metadata includes process data stored in other process storage devices including one or more of a batch log file, a process control historian, process equipment, or a batch historian.

31. 30. The quality review system of claim 18, wherein the process metadata includes one or more of process variable values, batch procedure model states, recipe information, an instruction name, a material for the instruction, a process flow for the instruction, process equipment used in the instruction, a workflow applied to the instruction, or a batch procedure model used for the instruction.

32. 30. The quality review system of claim 18, wherein the process metadata includes data indicative of the behavior of the process at the time of an exception.

33. 33. The quality review system of any of claims 18 to 32, wherein the communication interface is configured to receive the process metadata along with the process data from a data source.

34. 33. The quality review system of any of claims 18 to 32, wherein the communication interface is configured to receive the process metadata separately from the process data.

35. 35. The quality review system of any of claims 18 to 34, wherein the exception engine processes the process metadata before storing the process metadata.

36. 36. The quality review system of claim 35, wherein the exception engine processes the process metadata by reformatting the process metadata or by converting the process metadata into a different unit.

37. 37. The quality review system of claim 18, wherein different ones of the rules specify different process metadata for the exceptions defined by the different rules.

38. 1. A method for monitoring a process, comprising: storing a plurality of rules, each of which (i) includes logic defining one or more exceptions related to operation of a process and instructions for the process data that are applied to the logic to determine whether the one or more exceptions exist based on the process data, and a definition of a set of process metadata associated with the one or more exceptions; and (ii) identifies a data source, and the logic is applied to data from the data source to determine whether the one or more exceptions exist; each rule of the plurality of rules is created for a specific product type and is configurable for different quality standards, and each rule is configurable to be executed in a predetermined order based on the exception type; acquiring process data from one or more data sources within the process via a communications network at different times during operation of the process; obtaining, via a communications network, process metadata associated with the one or more exceptions; an exception engine configured to process the process data from the one or more data sources using the logic associated with the plurality of rules in the rules database, the plurality of rules configuring the exception engine to detect exceptions that occur during execution of a process by process equipment of a process plant; determining, by the exception engine, based on the process data, whether an exception exists as defined by any of the plurality of rules; upon identifying an exception based on each rule of the plurality of rules, creating an exception record for the identified exception, storing the exception record in an exception record database, and storing the process metadata for the identified exception as associated with the exception record in the exception record database; generating a user interface based on accessing the exception records in the exception record database via a communications network, the user interface including information for one or more accessed exception records, the information being generated in accordance with the process metadata stored for each accessed exception; providing the user interface including the information via a user interface device, the user interface further including one or more handling procedures for resolving each of the accessed exceptions that have already occurred in accordance with each of the rules; How to monitor the process.

39. 39. The method of claim 38, wherein obtaining the process data comprises obtaining the process data from a first data source, and wherein obtaining the process metadata comprises obtaining the process metadata from a second data source different from the first data source.

40. 39. The method of claim 38, wherein acquiring the process metadata comprises acquiring the process metadata simultaneously with acquiring the process data.

41. 39. The method of claim 38, wherein obtaining the process metadata for an exception comprises obtaining the process metadata for the exception after determining the existence of the exception.

42. 39. The method of claim 38, wherein obtaining the process metadata for an exception comprises obtaining the process metadata for the exception before determining the existence of the exception.

43. 39. The method of claim 38, wherein obtaining the process metadata for an exception comprises requesting the process metadata from a data source after determining the existence of the exception based on a set of process data sets.

44. 44. The method of any of claims 38 to 43, wherein obtaining the process data comprises obtaining the process data from a workflow application that controls the operation of the process and executes different stages of the process, or from a batch executive application that controls the operation of a batch process and executes different batch stages of the batch process.

45. 44. The method of any of claims 38 to 43, wherein obtaining the process metadata comprises obtaining the process metadata from one or more batch historians connected to the process, from a process control historian connected to the process, or from a control system connected to the process.

46. 44. The method of any of claims 38 to 43, wherein acquiring the process data comprises acquiring one or more of batch state data, batch parameter data, batch process measurement data, batch progress data, batch procedure model state data, batch status data, batch state change data, batch alarms, or batch alerts.

47. 47. The method of any of claims 38 to 46, wherein obtaining process metadata comprises obtaining process behavior data indicative of the behavior of the process at the time of the exception.

48. 48. The method of any of claims 38 to 47, further comprising processing the process metadata before storing it by reformatting the process metadata or by converting the process metadata into a different unit.

Images