Quality Inspection Management System

Abstract

A quality inspection management system can be used to analyze the operation of manufacturing processes within a factory based on data collected by various data sources (e.g., batch executor applications) in the factory to automatically detect, store, and display anomalies in these processes for use by quality inspection engineers to determine whether the process operation meets certain quality standards. The quality inspection management system includes: a configuration application that enables a user to create one or more exception rules; an exception engine that uses the rules to analyze process data to detect one or more anomalies in the process; and a review application that enables quality inspectors to review each determined anomaly for resolution.

Description

[0001] This application is a divisional application of the invention patent application named "Quality Inspection Management System", with an international application date of April 18, 2019, an international application number of PCT / US2019 / 028138, and a national application number of 201980026906.1.

[0002] Related Applications

[0003] This patent application claims the benefit of U.S. Provisional Patent Application No. 62 / 659,325, entitled “Quality Review Management System,” filed on April 18, 2018, under 35 U.S.C. §119(e), the entire disclosure of which is expressly incorporated herein by reference. Technical Field

[0004] The present invention relates generally to manufacturing management systems and, more particularly, to quality inspection management systems that enable advanced quality inspection procedures for plant operations, processes, batches, and other activities performed in a manufacturing plant. Background Art

[0005] A manufacturing plant, such as a process plant, typically produces one or more products from a set of raw or pre-processed materials. In many cases, the products produced must have a certain 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. In many cases, individual quality inspectors are assigned to perform various activities associated with ensuring that the products produced meet a set of pre-established standards or requirements or are manufactured to specific standards. These activities may include checking the status or values ​​of various parameters of the manufacturing equipment, materials, or processes used to manufacture the products to ensure that the appropriate manufacturing steps are implemented and the products are manufactured under various desired conditions, such as within a specific temperature range, pH range, pressure range, etc. Of course, these quality inspection 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 inspection is a highly specialized activity in many manufacturing environments that requires in-depth knowledge of the product, the manufacturing process, and the quality standards.

[0006] For example, batch processes are often used to manufacture various types of food or drug products that are highly regulated by various food and drug industries or organizations (such as the FDA). The specific process steps and conditions for manufacturing these products are often set or regulated in some way to ensure the safety of the product being produced or to ensure that the product meets certain labeling standards (e.g., the product is gluten-free, Kosher, etc.). As an example, the process steps used to manufacture the product may require or require that certain process steps be performed on raw materials or intermediate materials during the manufacturing process, that certain cleaning procedures be performed on process equipment within or between manufacturing steps of 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 during critical times of the process, etc. As a result, in many cases, product manufacturers need to collect and store data about the actual operation of manufacturing equipment during the manufacturing process in order to be able to demonstrate to regulatory authorities or customers that the products being produced meet appropriate quality standards, for example, that the products are produced according to or under pre-established procedures or conditions.

[0007] Process plants used to manufacture various types of products (such as food, petroleum, pharmaceuticals, etc.) are often complex and highly automated. In particular, industrial process plants, such as those used in chemical, petroleum refining, food manufacturing, pharmaceutical manufacturing, or other processes, typically include one or more process control networks having a centralized or distributed process controller communicatively coupled to one or more field devices, which may be, for example, valve positioners, switches, sensors (such as temperature, pressure, and flow rate sensors), tanks, mixers, heaters, etc. These field devices or field devices may perform physical control functions within the process plant (e.g., opening or closing valves, stirring or mixing materials within a tank, heating containers, etc.), may make measurements within the process plant for use in controlling the operation of the processing plant, or may perform any other desired function within the process plant. Historically, process controllers were connected to field devices via one or more analog signal lines or buses, which may carry, for example, 4-20 mA (milliamp) signals to and from the field devices. However, over the past two decades or so, the process control industry has developed a number of standard, open, digital, or combined digital and analog communication protocols, such as the Foundation Communications Communications Protocol (FCP), the Open Communications Protocol (ECP), and the Open Communications Protocol (ECP). TM FIELDBUS (hereinafter referred to as "Fieldbus"), and CAN protocols, which can be used to implement communications between process controllers and field devices. Generally speaking, a process controller receives signals indicative of measurements made by one or more field devices and / or other information about the field devices, uses this information to implement a typically complex control routine, and generates control signals that are sent to the field devices via signal lines or buses to control the operation of the process plant.

[0008] Certain types of process control networks, such as those used in batch processes, typically include multiple groups of repeating equipment, each group of equipment being designed with the same or similar hardware that performs substantially the same basic functions within the process plant. Thus, for example, a cookie manufacturing plant may have multiple groups of mixing equipment, multiple groups of baking equipment, and multiple groups of packaging equipment, with some or all of the individual mixing equipment capable of operating in parallel and capable of being connected to operate in series with some or all of the baking equipment and packaging equipment. In such a system, the same general control algorithm or routine is typically used to control the operation of any particular group of repeating equipment to manufacture the same product (as defined by a particular batch recipe). Thus, any particular batch run defined by an order that specifies or identifies a particular type of product being manufactured in a particular quantity may be implemented on any combination of various different groups of equipment in the plant. Typically, each such batch run or order includes a specific control program that sequentially executes a number of different steps or stages to implement the recipe, completing the first stage before starting the second stage, and so on. Thus, in the biscuit manufacturing plant described above, a batch run or order may implement a batch control program to control the mixing equipment, which may then implement a program to run the baking equipment on the product made by the mixing equipment, and then a third program may be executed that controls the packaging equipment to package the product produced by the baking equipment, each of which takes a finite amount of time. In many cases, the batch run also implements a program as part of each order to clean, empty, fill, etc., the tanks or other containers or equipment in the plant. Of course, each order may have a different set of specifications, which may require a different set of raw materials, a different recipe, a different process or batch procedure to be implemented on the raw materials, and even different quality standards.

[0009] The International Association for Measurement and Control, an international organization concerned with process control issues, has published a batch control standard entitled Batch Control Part 1: Models and Terminology, and is commonly referred to as the ISA S88.01-1995 standard, or one of its updates (referred to herein as the "S88 standard"). The S88 standard defines models of equipment and procedures for automated batch processes, and defines specific terminology for referring to those models and their elements. For example, the S88 standard defines a "batch process" as a process that results in the production of a finite amount of material by subjecting a certain amount of input material to an ordered set of processing activities over a finite period of time using one or more equipment. As another example, a "batch" is defined by the S88 standard as material being produced or material that has been produced by a single execution of a batch process.

[0010] As described above, during a batch process or batch operation, batch processing equipment (e.g., controllable elements such as valves, heaters, mixers, etc.) are operated according to a predetermined program to perform a batch process. All such batch processing equipment are synonymously referred to herein as equipment, equipment modules, processing equipment, and / or physical elements. The programs that operate these physical elements are generally referred to as "program models" by the S88 standard. According to the S88 standard, the program model is constructed as a hierarchical ordering of programs, wherein the highest level contains each lower level, the second highest level contains each level below it, and so on. The levels of the S88 program model of particular interest include "programs", "unit programs", "operations", and "periods" in descending order. The term "program element" or batch subroutine is used herein to refer to any embodiment or implementation of any of these levels of the S88 program model, as well as any other hierarchical definition of a batch program set.

[0011] As mentioned above, the highest level S88 program element of interest is called a program, which is composed of one or more unit programs. Each unit program is in turn or can be composed of one or more operations, and each operation is in turn composed of one or more periods. In addition, the S88 program model does not exclude the definition and use of other hierarchical levels in a specific application. On the contrary, the S88 standard and program elements mentioned in this article are intended to provide a broad, standardized model for describing the procedures followed in automated batch process control, and these elements are not limited to the four program elements defined by the S88 standard.

[0012] The different program elements of a batch are usually implemented as computer programs in practice, which are executed by and in a data processing device, including a personal computer, a workstation and a programmable controller. The execution of a typical program element results in an electrical or optical output from the data processing device, which can be typically used to control the physical element by connecting the output of the data processing device directly or indirectly to the physical element through a local area network or a wide area network. The program element performs a specified or related task by calling a "basic control" about at least one physical element. This type of control is usually dedicated to establishing and maintaining a specific desired state of a physical element. Basic control includes, for example, starting or maintaining a material flow in a silo element, heating the starting material in a polyvinyl chloride reactor element, etc. In fact, the lower level (i.e., period) of the program model performs actual communication with the actual physical element, thereby calling or executing the basic control. The higher level of the program model is essentially abstract, so as to improve the organization and structure of the program model and the physical model.

[0013] In addition, many batch systems use a batch executor to control the operation of one or more batches in a plant according to the procedural model used. A batch executor can be or use a state machine model as a logical structure to describe the state of a batch process or activity. A state machine model describes or defines multiple process states and actions that cause transitions between these states. The state machine model of a process is said to be in a state due to an earlier transition to that state. When a specific event occurs or a specific condition is sensed, the state machine model makes a transition to another state corresponding to the specific event or sensed condition. State machine models are a useful technique for defining and implementing the operation of procedural elements of a batch process. Specifically, a procedural element defined and implemented as a state machine initiates an action, for example, when its associated state machine makes a transition from an old state to a new state.

[0014] Of course, the S88 standard allows for program elements to be defined and implemented according to a standard state machine model. Although this approach is not required by the S88 standard, it has been widely adopted in the process control industry to enable a higher degree of interoperability between products from different vendors. One current commercial application of the S88 standard with program elements defined and implemented according to a state machine model is DeltaV from Emerson Process Management. TM Batch products. TMIn Batch, a server program or batch execution program runs on a data processing device that executes various program elements. The server or batch execution program (referred to as a "batch executor") coordinates the execution of program elements according to one or more state machine models so that the program, the corresponding unit program, the corresponding operation, and the corresponding period are sequenced by the server program through their respective steps. In any case, during the implementation of a specific batch run or a specific batch process associated with an order, such as when a period is started by the server program, the period transmits a start request to the period logic interface within the programmable controller. The programmable controller then executes the actual state logic or control routine of the period and provides the required process control to the process equipment via communication.

[0015] As will be understood from the previous discussion about quality inspection of processes, it is desirable to collect data representing the operation of a batch process, including historical events of the processing that make up the batch run, so as to be able to determine the batch run for an order that is satisfactorily operated or executed according to applicable quality standards. Such historical data is useful not only for quality inspection purposes, but also for determining trends in quality control or for determining when equipment used in a batch process requires service. Many types of data are potentially useful in checking the quality or progress of a batch process. One such data source is continuous data generated by various data points in the batch process during processing of the batch. A data point is a single source of such continuous data that reflects certain control values ​​or other states or measurements of the batch process. For example, a specific level of a material flow or the temperature of a material measured by a sensor may be such a data point. The current setting of a control valve, the sampling time, etc. may be other data points. Each such data point may have a continuous stream of data values ​​sensed or controlled over time by the batch process application associated with it. The collection of all such continuous data generated during processing of a batch is typically recorded by a batch processing system and stored in a batch database as part of a batch log file. These batch log records typically include a timestamp and current value, as well as other identifying information of the data point, such as a tag identifying the data source.

[0016] Another type of data useful in checking the quality or progress of a batch process is batch status and event information, which relates to or includes information describing the batch process according to the execution of the process model (e.g., the state of the batch process, the transitions between the states of the batch model, etc.). For example, batch events, unit procedures of the process model, or program component event information describing the start and end times of a specific period or a specific operation. Event information also includes process events, including information generated by physical elements of the batch process or by an operator. In particular, each equipment module, unit (cell), etc. of the process can generate a process event, which indicates one or more specific activities in the start, stop or run (i.e., the execution of a specific basic control action) of a specific period. Alarm and event conditions recognized by process equipment are further examples of process events. Process events can also include information about changes made to the batch process by an operator during the operation of the batch process.

[0017] Still further, many batch process systems utilize an operator interface program that runs on a dedicated operator interface device (such as a workstation) to enable an operator to view the current status of a batch run, take manual steps within a batch run, such as manually setting various parameters, selecting process equipment to execute various batch procedures, operations, phases, etc., annotate regarding unexpected activities or conditions during a batch run or order, etc. One such operator interface program is referred to as a workflow program (e.g., the SyncadeWorkflow program provided by Emerson Automation Solutions), which intercepts or receives various information from a batch executor or process equipment (e.g., a process controller) that is used to implement a batch run for each order being processed. The workflow program can subscribe to various types of data from the batch executor or process control system and can present the data to the operator to enable the operator to view the current status of a batch run, view transitions between states in a batch model, make changes within a batch run, manually stop and start various batch procedures, operations, phases, or equipment, and handle problems or unexpected events that arise during a batch run. For example, in many cases, unexpected errors or problems may occur during a batch run, such as batch equipment or raw materials unexpectedly being unavailable, process parameters being outside of expected or desired ranges, etc. In these cases, the workflow program enables the operator to make and implement decisions about how to proceed, such as skipping a batch step or procedure, specifying other equipment or materials to be used, changing process plant variables, set points or parameters to handle alarms or events in the process, etc. Generally speaking, the workflow program also stores data indicating the operator's actions in the batch log file along with the raw batch data. In many cases, the workflow program also enables the operator to record or store explanations of what happened in the batch at the time of the action, why the operator took a particular action, etc., and these comments are also stored in the batch log file.

[0018] In any case, in many industries, after a batch run has occurred and a product or order has been completed, a quality engineer or other quality personnel (generally referred to as a quality engineer in this article) must verify that the product meets the appropriate quality standards. In order to perform this check, the quality engineer accesses and reviews the batch log file of the batch run of the order (usually on an order-by-order basis) to ensure that the batch run is completed according to or within the expected parameters, workflow and range. Typically, in order to perform this check, the quality engineer must scroll through the raw data in the batch data file to find "abnormalities" of the expected operation of the batch run. The term "abnormality" is generally used herein to indicate deviations from the expected procedures, processes, steps, workflows, ranges, values, etc. within a manufacturing process or factory. Anomalies may be, for example, one or more process variables or parameters outside of an expected or desired range, or above or below an expected or desired threshold, a batch procedure, operation or phase being skipped or not performed in the expected sequence, a batch procedure, operation or phase being stopped or started at an unexpected time, or taking longer or shorter than the 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, a change in recipe, comments generated by an operator during a batch run, alarms and events occurring during a batch run, and the like.

[0019] In any case, the quality engineer must identify the anomalies based on the raw data stored in the batch log file, and then must determine the impact or severity of each such anomaly, and what will happen if any procedures are taken to handle or "close" the anomaly. For example, in many cases, the anomaly may only represent a minimal or insignificant deviation in the expected batch run, which will not cause any or any significant quality reduction of the product produced according to the quality standards being implemented. In other cases, the anomaly may need to be documented for later review by the regulatory agency or customer, but the impact of the anomaly may not be severe enough to cause a significant reduction in product quality. In other cases, the anomaly may be significant or important enough that the product needs to undergo one or more additional procedures to ensure the desired quality, or one or more tests need to be performed on the product to ensure the quality of the product. In other cases, the quality engineer may determine based on the details of the anomaly that the product needs to be scrapped, or that the product needs to be sold at a lower quality or labeling standard.

[0020] The process of browsing the batch log file to find anomalies is very tedious and full of problems. In particular, most of the data in the batch log file does not indicate anomalies, so the quality engineer spends a lot of (usually most of) the inspection time to view data that is not actually associated with any anomalies. Further, the quality engineer must remember all the conditions that lead to the anomalies, including, for example, the expected values ​​or ranges of important process variables, the order of the expected batch program, the expected stop and start times of various different batch programs, etc. Although the presence of batch process alarms and warnings stored in the batch log file or comments from the operator can indicate the presence of anomalies, this is not always the case. Of course, not every anomaly that occurs can be recorded with an operator comment, or can rise to the level that causes the generation of relevant alarms or warnings in the control system. As will be understood, the actual anomaly determined therefore depends on the skills of the specific quality engineer performing the inspection and the specific quality standards met.

[0021] Furthermore, when a quality engineer discovers an anomaly (e.g., a process value is out of range, etc.), the engineer must typically determine the context of the batch process at the time of the anomaly in order to determine the severity of the anomaly and how best to respond to or handle the anomaly. This process may include obtaining additional data about the state of the batch run or batch procedure at the time of the anomaly, the values ​​of other process variables at the time of the anomaly, determining whether an alarm or event was generated in the same or other process equipment at the time of the anomaly, etc. The process then typically requires the quality engineer to use other available data access systems to determine additional process status information at the time of the anomaly. Such data collection activities may be time consuming and require additional expertise on the part of the batch quality engineer.

[0022] For example, in order to view the operation of a batch from a batch log file, obtaining a snapshot of the batch process at a specific time and displaying the data to a quality engineer is not a simple task, because the batch process has various different program elements, which can be run on different devices within the factory at different times, using different set points, settings, etc. On the contrary, in order to view the batch operation, the quality engineer may need to examine and analyze the data from the batch at different times related to the program events of the batch (i.e., the subroutines and subprocesses related to the batch), so as to be able to understand the operation of the batch operation at abnormal times. Although various batch data are usually collected and stored automatically during the operation of the batch operation, these different types of data are usually collected by different subsystems and can actually be stored in different databases. This fact makes it difficult for quality engineers to fully understand any specific batch process. For example, data such as alarm data and sensor measurement data obtained from actual field devices such as sensors, valves, etc. within the batch process are usually stored in a data history library as time-stamped data, and are usually obtained from the data history library based on the time when the data was collected. However, different databases, such as databases related to batch actuator routines, can store the start and end times of the batch operation and the various different subroutines or program elements in the batch operation. This all makes it more difficult for quality engineers to understand the context of the anomaly without doing extensive data lookups in various other subsystems of the batch process. Summary of the invention

[0023] A quality inspection management system (also known as a review by exception (RBE) system) can be used to analyze the operation of one or more manufacturing processes collected by various other process plant data sources, such as data sources within a process control system, workflow applications, batch process operator applications, batch executor applications, etc. The quality inspection management system automatically detects anomalies in those processes and stores data related to the detected anomalies in an organized and easy to review manner. The quality inspection management system also enables a quality inspection manager or engineer to review and handle (resolve) anomalies associated with a process with an easy to use interface.

[0024] Specifically, the quality inspection management system includes a configuration system that enables a user to create and store rules in a rule database that can be used to automatically identify one or more exceptions within a process such as a batch process. The rules can identify a set of conditions that must be met in order to identify an exception, the severity of the identified exception, information about the exception, a process or procedure for handling, resolving or closing the exception, process data or other data to be stored as part of an exception record to help quality inspection engineers understand and resolve the exception, etc. The quality inspection management system also includes an exception engine that uses the rules in the rule database to process data within a data message to determine whether the data within the data message includes an exception defined by any rule, the data message is, for example, a data message periodically provided by a data source, such as a plant or process control system, a batch executor, an operator workflow application, etc. After identifying the exception, the exception engine can store information about the exception as an exception record, such as the name, type, severity, procedures or steps taken to resolve or handle the exception, and process data related to the operation of the process in which the exception occurred when the exception occurred. The exception engine can store this data and / or other data for each identified exception as an exception record in an exception file (e.g., an exception database) for each order. Furthermore, the exception engine may operate in real-time during operation of the process fulfilling an order to create an exception file or database for the order and may provide real-time feedback to the process operator that an exception has occurred or is about to occur.

[0025] Therefore, in one example, the quality inspection system provides a configuration environment to enable users to create configurable exception rules to execute 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, the user can select one of the templates, define input / output, and define possible expressions to be analyzed for the data set. When the data flows through the engine, the data is analyzed according to the configured rules; if the criteria of any rule are met, an exception is created. The exception can then be checked immediately. Typical known checks for exception products require that the exception software provider hard-codes the exceptions defined for the system into the product, and therefore requires software or system updates to create new exceptions. These updates cost the user's time to obtain and install, and do not enable users to customize their own systems.

[0026] The quality inspection management system also includes an inspection interface, which enables a quality inspection engineer or other personnel to inspect and process the exceptions identified by the exception engine and stored as exception records in the exception database of the order. In particular, the inspection interface can access the exception database for a specific order, and can present information about each identified exception to the quality inspection engineer in an organized and easy-to-understand manner. The inspection interface can provide the quality inspection engineer with data stored for each exception record, such as the name, type and severity identification of each exception record. The inspection interface can provide the inspector with storage information about the exceptions, exception types, etc. identified by the exception record, and data about various processes or batch variables, states, programs, etc. that exist when the exception occurs. This information will enable the inspector to easily understand the context of the process when the exception occurs and the severity of the exception. In addition, the inspection interface can enable the inspector to take various actions for each exception. This action can include confirming the exception, signing off or closing the exception, annotating the exception with additional information such as why the exception can be ignored or signed off, sending the exception record to another person, etc. The review interface may also provide suggested actions to the reviewer, and in some cases may enforce specific actions to be taken with respect to resolving or closing the exception. Such actions may include, for example, requiring sign-off by a specific number or type of personnel (e.g., reviewer alone, reviewer and manager, two reviewers, etc.). Other actions may include requiring specific information from the reviewer, such as comments, process information, etc., which will be stored with the exception record for later use by the customer, quality review authority, etc.

[0027] The inspection interface may store processed exception records in a database or file, and may enable the inspector to scroll through the exception records in the exception database to determine whether and when all exception records of the order have been processed or closed, the status of the inspection (e.g., how many unprocessed exceptions exist in the exception record database), and statistics related to the exception records (e.g., how many exceptions of each type or severity exist in the file, etc.). The inspection interface may also enable the inspector to group the exception records in various ways, such as by type, severity, processing status (e.g., uninspected, inspected but not closed, closed, etc.). Further, the inspection interface may enable the inspector to take one or more actions on the entire group of exception records, such as closing all exception records in a group, commenting on all exception records in a group, etc.

[0028] In this way, a quality inspection management system can be established (configured) and executed during the operation of a batch process or other process so that anomalies are automatically identified when they occur during process operation, a process operator can be notified that an exception has occurred or that an action taken by the process operator will result in an exception, and all determined exceptions for a particular process (e.g., a batch process) can be stored in an exception record database. The quality inspection management system also enables quality inspection engineers to quickly determine, view, and process anomalies within the exception database without having to review large amounts of raw data as is currently required. Similarly, the quality inspection management system can implement various rules during the exception handling or resolution process, such as ensuring that various exceptions of different types or severities are handled or handled in a specific manner, thereby providing consistency in the quality inspection process.

[0029] Furthermore, the quality inspection management system can be implemented in a plug-in environment to enable the system to interface with third-party systems or applications and be used to analyze exceptions of third-party systems or applications. In one case, a plug-in can be created or configured to obtain certain data from a third-party application or data source, which can then be passed to the exception engine for processing by one or more exception rules. As an example, the quality inspection management system can be used to interface with event monitoring systems, such as those using OPC interfaces, to obtain and analyze data from third-party process control systems or plants.

[0030] In one example, a plug-in module is created to interface the RBE exception engine with an external or third-party system (e.g., a control system, an OPC interface, a maintenance system, etc.), thereby enabling exceptions to be generated based in whole or in part on data from the third-party or external software system. A plug-in can be created to access specific data within or from a third-party or external system and pass that data to the RBE engine to analyze whether an exception should be created. The plug-in can run in a third-party server, the RBE server, or another server, and may or may not perform anomaly detection. Thus, a plug-in can be a simple third-party system data collector, or can collect data and additionally perform some exception processing, providing exceptions or pre-processed exception data to the RBE engine.

[0031] Known inspection systems are currently unable to interface with or create anomalies based on data provided directly from external software programs such as control systems, safety systems, maintenance systems, etc. Plug-ins make RBE systems more robust in complex process environments with multiple different software systems operating during runtime.

[0032] Further, in one example, the RBE system may include a real-time viewing 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. The metadata is stored as a process snapshot associated with the accessed exception data. When the RBE system detects an anomaly based on the collected exception data, the RBE system also stores the metadata as part of the exception. The RBE system additionally displays some or all of the metadata when reporting the generated exception, thereby providing a user or inspector with a real-time view into the process when the exception occurs in the process. The system provides the user with a quick view of various process states / values, etc. at the time of the exception, which enables the user to more quickly understand the cause of the exception and the severity of the exception, thereby enabling the user to more quickly handle the exception.

[0033] Although known process inspection products provide a list of generated anomalies to the user or inspector, the inspector must still analyze each anomaly to determine whether the anomaly can be eliminated or must be handled in some other way. However, in general, the inspector must return to the process system that collected the data that caused the anomaly to understand other things about the process at the time of the anomaly (e.g., whether the process was online or offline, the status of the batch at the time of the anomaly, etc.). Using the real-time viewing feature, a process snapshot can be automatically provided to the user, which process snapshot will generally include the process data that is most useful to the inspector when performing an anomaly inspection, which means that the inspector does not need to return to other data collection systems to obtain the information needed by the user to perform an anomaly inspection. This feature also means that since the inspector will not need to use other process systems to access the process data that the inspector needs, the inspector generally does not need to be familiar with other process systems from which data is collected.

[0034] In another example, an RBE or quality inspection system includes an event monitor that can be bound to a third party or external system and generates and sends messages to the RBE system, which the RBE system can then use to perform exception handling or exception creation. In one case, the event monitor can be bound or coupled to an OPC warning and alarm monitoring interface and can identify when one or more warnings or alarms are passed to the OPC interface. At this time, the event monitor creates and delivers a message to the RBE system with the warning or alarm information and potentially any other desired OPC collected data. The RBE system can then analyze the message to generate exceptions based on the alarms and warnings. Typical inspection systems do not analyze data from third party systems, and none of them are connected to an existing OPC warning and alarm interface. Therefore, these systems cannot generate exceptions based on, for example, process alarms and warnings.

[0035] Likewise, the quality inspection management system can use a novel paging algorithm when presenting a list of exception records to an inspector via an electronic display or user interface. This paging algorithm operates in a manner that reduces or eliminates the presentation of missed records or duplicate records during the inspection process, storing one or more anchors to track the actual records in the currently displayed page of records provided in the interface display. The system then uses the anchor of the currently displayed page to determine the starting position of the next set or multiple records to be displayed as part of the next page, which enables the paging system to operate appropriately even if records are added or removed from the list of records to be displayed during the inspection process.

[0036] In one example, when presenting the generated exception list to the inspector, the inspection system implements a new paging algorithm. Typically, the RBE system creates / detects exceptions and stores these exceptions as records in a structured database such as a SQL database. Then, when the exception list is presented to the inspector on a display screen (and there may be a large number of exceptions or records), the RBE system searches the database to find all relevant exception records, downloads pages of links to these records, and then when the user scrolls through the various pages of exception records, the records are presented in the order downloaded from the database within the portion of the retrieved page. However, when the inspector processes the exception and scrolls down the exception list displayed on the user interface, the records in the database may change, so the page data may become outdated. In particular, records may be added to 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 lost, resulting in visual data loss or duplication. In some cases, the user may miss records from one page to the next due to deleting records on a specific recovery page. In other cases, the system may become confused about where to start a new display page based on missing records in the downloaded page. The new system operates differently in that it downloads the records presented on the display screen starting with the last record displayed on the screen. That is, instead of presenting a new display page associated with the original page of restored records, the system accesses the database to find the set of records that currently exists immediately after the last record on the displayed page, thereby ensuring that each time a new set of records is displayed on the screen, the first new record displayed is the record that immediately follows the last record that was being displayed prior to the scroll time.

[0037] The display system is more accurate because it ensures that records are not displayed out of order or missed during an inspection process where a user scrolls down pages of records over a long period of time. In addition, the RBE system is more efficient because it only needs to access the database to obtain the number of new records that will fit on a new display page as the user scrolls through the records, while still ensuring that all relevant records are accessed as the user performs the scrolling process. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] FIG. 1 is a block diagram of a typical process or manufacturing plant, including a process control network, a batch executor, and a workflow application that enables operators to manage batch processes and store batch log files for quality inspection.

[0039] Figure 2 is a block diagram of a factory environment similar to that of FIG. 1 , but including a quality inspection management system having a configuration application, an anomaly engine, and a quality inspection interface application for performing anomaly-based detection and quality inspection in the factory environment.

[0040] Figure 3 Is Figure 2 A sample screen created for the QA Management System's Configuration application is shown, enabling a user to create one or more exception rules for use by the exception engine.

[0041] Figure 4 is to show that when analyzing data from multiple data sources for exception handling Figure 2 A flow chart of the operation of the exception engine of the quality inspection management system.

[0042] Figure 5 is an example screen display showing real-time feedback from a quality inspection management system to an operator of a batch process, which notifies the operator in real time of actual or potential anomalies detected within the process.

[0043] Figure 6 is a diagram illustrating the operation of a quality inspection management system implemented in a plug-in environment.

[0044] Figure 7 An example event monitoring system is shown that uses a quality inspection management system to perform monitoring of third-party applications and systems in a continuous process environment.

[0045] Figures 8A-8G Shown by Figure 2 Example screen displays created by an inspection interface application or a configuration application of a quality inspection management system to enable quality inspectors to perform various activities related to exception rule configuration and exception record viewing and processing.

[0046] Fig. 9A and 9B is a diagram illustrating the operation of a typical paging technique for providing a list of records to a user, for example, in a web environment.

[0047] Fig. 10A and 10B is a diagram showing the operation of a new paging technique that can be used by Figure 2The quality checking interface should be implemented to reduce or eliminate duplicate or missing records when paging through a record collection. DETAILED DESCRIPTION

[0048] As background, FIG. 1 shows a typical factory or process control environment 10 in which typical or existing quality inspection management actions are implemented. The factory 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., which are communicatively connected together and are all programmed to operate or implement a manufacturing process of a certain nature, such as a batch process or a continuous process. Further, the factory environment 10 may include a batch executor 22 (implemented on a processor of a computing device, such as a workstation or server), which may interface with the process control network 20 to enable the process control network 20 or devices within the process control network 20 to take various actions related to the manufacturing process, such as implementing various orders or batch runs, including implementing different stages of various batches, such as unit procedures, procedures, operations, phases, steps, etc. of the batch process associated with each order. Further, the process control network 20 and the batch executor 22 may both be coupled to another network 24, which may be located, for example, in a commercial environment away from the factory site or manufacturing space. The 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 other computer devices, such as gateways to the Internet or other communications networks, servers, wireless or handheld devices, etc. (not shown in FIG. 1 ), if desired. The devices 26, 28, 30, 31, and 32 may be communicatively connected via any desired physical communications network or backbone 25, such as Ethernet, the Internet or other local area network (LAN) or wide area network (WAN), etc. Likewise, the process control system 20 and the batch executors 22 may be connected to the various devices and databases 26, 28, 30, 31, and 32 via the network backbone 25 directly or via other intermediate networks, if desired.

[0049] In this prior art system, a workflow (WF) application 40 may be stored in an operator interface device (e.g., a workstation 26), and the workflow application 40 may be executed by a processor of the workstation 26 to interface with the batch executor 22 as the batch executor 22 controls the process control network 20 to implement various orders or batch runs. The workflow application 40 may be, for example, the Syncade Workflow application sold by Emerson Process Management, which may be operable to obtain and display data from the batch executor 22. The data may include ongoing batch status data, parameter data, measurement data, progress data, batch procedure model status data, and the like, as acquired by the batch executor 22. The information or data may include an indication of the order being implemented, the materials and processes associated with the order (e.g., the recipe and batch procedure model to be implemented), alarm and warning data from the batch executor 22 and / or the process control network 20, and the like. Any or all of this data may also be stored as a batch log file 34 in a batch log file database 432, as the batch executor routine typically does.

[0050] As is generally known, the workflow application 40 may track the operation of the batch executor 22 with respect to each order implemented by the batch executor 22, and may allow a batch operator to perform various operations or actions within or with respect to the batch executor 22 or the process control network 20. For example, the workflow application 40 may subscribe to certain types of data from the batch executor 22, such as parameter data, batch status data, batch status change data, batch alarms and / or warnings, etc., and may notify the operator of various conditions in the plant 10 based on the data. The workflow application 40 may, for example, notify the operator of the start and stop of various different batch procedures or changes in the state of the batch procedure model, may notify the operator of various interruptions or other operating conditions of the batch execution engine 22 (which may be caused by unforeseen problems such as lost equipment, lost raw materials, etc.), may notify the operator that the time period is not suitable, that the batch parameters may be outside the range expected based on the batch executor 22, etc. As is known, the workflow application 40 may allow the operator to take various actions to restart the batch run, select different equipment for the batch run, operate on different raw materials, instruct the batch executor to start, shut down or skip a procedure, or execute other procedures in the batch procedure model. As an example, the batch executor 22 may attempt to go through a cleaning procedure where the equipment to be cleaned is offline and therefore cannot be cleaned. In this case, the operator may skip the cleaning procedure, which may not be strictly in compliance with the quality standards being implemented, but may be necessary to complete the batch in a timely manner or within the allocated time frame. In any case, the workflow application 40 may enable the operator to annotate various actions taken by the operator. In addition, the workflow application 40 may store comments or annotations provided by the operator via the workflow application 40 (e.g., comments or annotations provided by the operator to explain what happened and why the operator took certain actions outside the expected workflow of the batch process), and data indicating various actions taken by the operator via the workflow application 40 may be stored in the batch log file database 30 as part of the batch log file 34 for the order being monitored or controlled. Each batch log file 34 generally lists various data obtained from the batch executor 22, as well as the actions taken by the operator in response to the data, the operator's annotations placed in the log file, etc. In addition, during the operation of the batch executor 22, the batch executor 22 sends data packets to the workflow application 40 along with current data about the batch run or order. The workflow application 40 can subscribe to various data from the batch executor 22 (or process control network 20), and can receive the data periodically when changes occur in the data, etc. In addition, each data set can have a unique group identifier that identifies various information about the batch run or sequence associated with the data. In this way, the workflow application 40 can process the data groupings to determine the sequence and, therefore, the appropriate operator to provide the data to.

[0051] As is known, a batch log file or batch report 34 of a batch run is generated during the batch run, and after the batch run or order is completed, the batch log file 34 is completed. At this point, a quality inspection engineer or other personnel can access the batch log file 34 via a certain viewing application executed on a computer or workstation 28, for example, to analyze the batch report and view the data and other information within the batch process report line by line. The quality engineer can view the data stored during the operation of the batch process to determine whether any anomalies occur in the batch run, whether these anomalies need to be resolved, and based on the existence of these anomalies, what happens if any action needs to be taken. As described above, this inspection often takes a lot of time, is labor-intensive, and requires a lot of knowledge on the part of the quality engineer. Further, most of the time spent by the quality engineer is just to view the data or information from the batch report, which is not related to any specific anomaly within the batch run or the deviation from the expected action, so this inspection is time-intensive. Furthermore, as described above, when the quality engineer identifies an anomaly based on the data in the batch log file 34, the quality engineer may need to obtain other information about the batch process (e.g., process variable values, batch procedure model status, recipe information, etc.) that is stored in one of the other databases, such as the batch history library 30, the process control history library 31, etc. Such activities may require the quality engineer to use other data access applications to access the data, and therefore require the engineer to have the technical know-how to use these other data access applications to efficiently and correctly access and view the data.

[0052] Figure 2 A plant environment 110 is shown that is similar to the plant environment 10 of FIG. 1 , where similar structures, applications, and data have common reference numerals. However, Figure 2 The factory environment 110 includes a quality inspection management system 112 that is implemented to help quality engineers (or other personnel) identify and inspect exceptions associated with an order or batch run (or with multiple different orders or batch runs), and in some cases, it helps operators perform workflow operations within a batch run in a manner that reduces the number of exceptions or exception records generated during an order.

[0053] In particular, Figure 2The plant environment 110 includes a process control network 20 and a batch execution engine or batch executor 22, which operate in a manner similar to that described above with respect to FIG. 1. Thus, data from the batch execution engine 22 and / or process control network 20 is provided to various devices via a communication network backbone 25 to which computers or devices of various process controls and various different quality inspection management systems 112 are connected. In this example, batch process 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 that stores batch log files 34. However, Figure 2 The quality inspection management system 112 within the factory environment 110 includes various applications and databases located, stored and executed on computers or processor devices within the factory environment 110. In particular, Figure 2 As shown, the quality inspection management system 112 includes a configuration application 120 stored in the memory of a processing device 121 and executed on its processor, an exception engine 122 stored in the memory of a server 123 and executed on its processor, and a rule database 124, an exception record database 126, and a quality inspection interface application 128 stored in the memory of a processing device such as a workstation 129 and executed thereon. Although the components 120, 122, 124, 126, and 128 are shown as being stored in the same Figure 2 Components 120, 122, 124, 126, and 128 are stored in and executed on different separate computing devices, but any subset or all of components 120, 122, 124, 126, and 128 may be stored in 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.

[0054] In general, the configuration application 120 can be operated or executed to enable users such as configuration engineers, quality management engineers, etc. 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 in process operations, such as exceptions in batch operations of batch processes associated with specific orders. The configuration application 120 essentially provides a configuration environment that enables users to create configurable exception rules to be executed in the exception engine 122 to define or detect exceptions. The configuration application 120 can 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 expressions (e.g., Boolean logic). In the configuration environment, a user can select one of the rule templates, define the data input / output of the rule, and define possible expressions to be analyzed for the data set. When data flows through the exception engine 122, the exception engine analyzes the data against the configured rules to determine whether there is an exception. When an exception is detected, the exception engine 122 stores the exception record in the database 126.

[0055] As an example, Figure 3 The configuration application 120 can create and Figure 2 The workstation 28 of the configuration application 120 provides a screen display 150 to a user (e.g., a configuration engineer, a quality assurance engineer, etc.), for example, to enable the user to create one or more exception rules 152 and store the exception rules 152 in the exception rules database 124. In particular, the configuration application 120 can enable the user to create different rule sets to be applied to data from different data sources. Figure 2 As shown, the exception rules 152 may include a set of different exception rules 152A, 152B, 152C, 152D, etc. for each of a plurality of different data sources. For example, a rule 152A may be created to analyze and associate data from a workflow application 40, a rule 152B may be created to analyze and associate data from an event monitoring application, a rule 152C may be created to analyze and associate data from a third-party application that performs other services in the factory environment 110, and so on. Of course, any number of exception rules 152 may be created and stored for each data source, and these rules may be configured in any number of different ways to analyze data from those data sources. For example, different sets of exception rules may be created from a single data source for different types of operations (e.g., batches that produce different products), and different sets of exception rules may be created for different quality standards. Similarly, the exception rules associated with a particular data source may be ordered to specify which rule in the set of exception rules should be executed or analyzed first, second, third, etc.

[0056] Reference again Figure 3, the configuration application 120 may create a screen including a plurality of different parts, including a rule template area 156, a data source area 158, a rule list area 160, and a rule configuration area 162. The rule template area 156 may include an icon set indicating an exception rule template stored as a template or a previously configured exception rule, which a user may use as a starting point for creating a new rule. These templates may be stored in the rule database 124, or in the same device as the configuration application 120, or in any other database or computer memory. The data source area 158 may include icons indicating various different data sources for which a user may create an exception rule. Icon 158A may be accessible to view details about the data source, such as data available from the data source, data or communication formats used by the data source to transmit data, information about the data source (e.g., manufacturer, version, etc.), and / or any other information. The rule list area 160 may store a list of rules for a particular selected data source and specify the order in which the rules are to be executed when analyzing data from the data source.

[0057] During operation, a user may select a data source 158A from the data source area 158 to specify a data source for which a rule is to be created. The application 120 may access the rule database 124 and locate previously stored rules for the data source (if any), and list these rules in the rule list area 160, for example, in the order of execution. Next, the user may create a new rule for the data source by selecting a template data source icon 156A from the template portion 156 and dragging and dropping the template icon 156A onto the rule configuration area 162, which will cause the application 120 to load the configuration data for the selected template rule into the various sections or fields of the configuration area 162. If desired, the rule configuration area 162 may have its fields left blank to enable the user to create a new rule without using a template. Further, the user may select one of the rules in the rule list area 160 to edit a previously created rule. Of course, the application 120 may use other ways of selecting or establishing a rule to be created (e.g., using a drop-down menu, a pop-up screen, etc.)

[0058] The configuration application 120 then enables a user, such as a configuration engineer, to specify, set, or create the details of the rule by providing or editing various rule configuration information in various fields of the rule configuration area 162. Basically, the application 120 enables the user to specify any rule configuration information required to process data from a data source in order to detect and handle anomalies within the operation of the process monitored by the data source. Typically, each rule stores logic, such as Boolean logic, for analyzing data from a data source to detect anomalies, information about how to store anomaly records, and, if necessary, information about how to enable a quality engineer to handle or resolve (e.g., close) anomaly records created by the application of the rule. Such anomaly rules may include, for example, detecting whether one or more parameters from a data source (e.g., workflow application 40, batch executor 22, process control system 20, etc.) are out of range or above or below certain pre-established thresholds; whether comments have been entered by an operator (e.g., via workflow application 40); whether different materials are being used in batch runs of an order; whether different equipment is being used for one or more batch procedures of an order; whether processing time for one or more batch procedures is longer or shorter than expected; certain steps or procedures, such as cleaning procedures or flushing procedures, are skipped or added in batch runs of an order; whether an operator or other user of the process system has taken unexpected actions in the process or entered comments in the data source application, etc. Of course, anomaly rules may specify and expect logic to be applied to specific data from a data source to determine whether an anomaly exists.

[0059] Therefore, if Figure 3 As shown in the example screen 150 of FIG. 150 , the rule configuration area 162 includes a name field 162A, which can be used to specify a name for the anomaly rule, a severity field 162B, which can be used to specify a level of severity or importance of anomalies detected by the rule, and a logic field 162C, which can be filled in or used to specify a logic field to be detected by the anomaly engine 122 ( Figure 2) to detect if an anomaly exists. Of course, the logic field 162C can accept or enable the user to enter or specify logic in any desired manner, such as a set of Boolean logic parameters or strings, coded in a specific language (C+, HTML, etc.), any desired custom expression syntax, etc., which applies certain logic, If-Then logic statements, etc. Further, the source parameter field can be used to specify any and all data from the data source required for applying the logic rule or logic provided in field 162C. This data source data is referred to herein as data source metadata or just metadata, which specifies all data associated with the information, format, and communication parameters of the data to be received from the data source for the rule. The configuration application 120 can enable the user to select one of the icons 158A to obtain configuration information for a specific data source, wherein a rule is created for the specific data source to determine what data source metadata (information and / or variables) can be obtained from the data source, the names of these variables, the data format of these variables (e.g., 32-bit, 64-bit, variable types such as integer or Boolean, or string variables), etc. Still further, field 162D may enable a user to specify transformations to be performed on metadata from a 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 (change from Celsius to Fahrenheit, scaling, limiting, etc.), transformations may be variable name changes (to match the various variable names used in the logic with the data source variable names), or these transformations may be any other type of transformation. Furthermore, the metadata from the data source may include any desired information, such as process parameter values, order names, order materials, order process flow, process equipment used in an order, workflow applied to an order, batch process model used in an order, etc.

[0060] Further, the configuration engineer can use the configuration application 120 to specify the order or sequence in which each rule of a particular rule set should be applied to any particular data set from a data source. In particular, the exception engine 122 can apply multiple rules to each data set from a data source, and can be configured to apply each of the multiple rules in a specific or predetermined order so that certain types of anomalies (usually more important or serious anomalies) are detected before other types of anomalies (e.g., less serious anomalies). For example, in many cases, applying different anomaly rules to a particular data set from a data source may result in the detection of multiple different anomalies. However, it may be important or desirable to determine only the most important anomalies for any particular data set from a data source to prevent the creation of multiple anomaly records associated with the same event or time in a batch run or order. The order of the rules (i.e., the order in which the exception engine 122 applies the anomaly rules to a particular data set) is therefore used to specify which anomalies are detected first, so that during operation, the exception engine 122 determines anomalies based on various rules by running the rules in a specific order and then saving or creating anomaly records only for the first detected anomaly. As described above, the rule area 160 can store a list of rules for a source in the order in which these rules will be executed. Each rule may store or include as its parameter a sequence number or order number indicating the execution order. In any case, the user may change the order of the rules of the data source by, for example, rearranging the order of the rules in the rule list in area 160. The user may, for example, select a rule in the rule list 160, drag the rule up or down in the list 160, and place the rule in a new position in the list 160 to change the execution order of the rules. Of course, the application 120 may enable the user to change the order of the rules in other ways, such as by changing the order field 162E in the screen area 162.

[0061] In addition, if necessary, screen area 162 may include a solution field 162F, which enables the configuration engineer to specify one or possibly multiple processing or resolution procedures, which should or must be applied to close the exception record created by the rule. Typically, each type of exception can support a single resolution procedure. However, in some cases, the exception can support or include multiple resolution procedures. Such a resolution procedure may include signing off the exception, annotating the exception record with various information, sending the exception record to other personnel to check and / or sign off, etc. In some cases, each solution may be just the definition of the signature set required to close the exception, or the solution may only enforce one or more signatures required to close the exception. In these cases, the solution may include a description or instruction set indicating other activities (programs) to be completed before signing, but in these cases, the solution may not monitor or enforce other activities. The processing procedure specified in the rule may be preset, or may be set to a default setting based on, for example, the severity of the exception specified in field 162B.

[0062] In addition, screen area 162 may include an information field 162G that accepts and stores information to be provided to the quality inspection engineer along with or as part of the exception record created by the application rule. The information may be general information about this type of exception, normal handling procedures, guidance or suggestions for other actions to be taken or considered, or any other information useful to the quality inspection engineer when viewing or processing the exception record created by the application rule. In many cases, field 162G may also be used to specify data source metadata to be stored as part of the exception record, as well as the format in which the metadata is displayed. Typically, when processing exception records, it is helpful for the quality inspection engineer to know the context of the process at the time of the exception, and the data source metadata may be provided as information to help the quality inspection engineer understand the context. In this way, configuration field 162G may indicate what data source metadata will be provided to the quality inspection engineer as part of the exception record.

[0063] Of course, the configuration application 120 may store any or all of the rule configuration information as part of the exception rules in the rules database 124 in any desired manner. As will be appreciated, this configuration information may include identification of data required from the data source, and as will be described later, this data may be used to obtain the correct data or information from the data source during operation of the data source.

[0064] Of course, the configuration application 120 can be used to create any number of exception rules, and the exception rules can be stored in the rule database 124 on the data source by data source, so that different rules or rule sets can be formulated and stored for different data sources (or for different orders associated with a single data source). In any case, the configuration application 120 can be used to create rules, and can do so by enabling users to create new rules (e.g., from template rules), enabling users to specify the name of the rule or exception to be detected by the rule, the logic to be applied to data from the specific data source to be implemented to detect the presence of an exception or deviation from the specification based on the data, the identification of the type of exception detected by the rule or rule, the information set to be provided to the reviewer or other user when the rule detects an exception (e.g., an explanation of the exception, data or instructions useful for anomaly analysis or sign-off), the identification of the severity (e.g., importance) of the exception detected by the rule, metadata related to the state of the process (e.g., batch run) at the time of the exception that should be stored as part of the exception record (e.g., data from the data source), the process or procedure that can be used or must be used to handle or resolve the exception (e.g., a sign-off procedure), and other data or information to be stored as part of the exception record or to be used to handle the exception record.

[0065] Importantly, the configuration system or configuration application 120 provides significant advantages over known products that require exception software providers to hard code exceptions defined for the system into the product, and therefore require software or system updates to create new exceptions. These updates take the user's time to obtain and install, and do not enable the user to customize their own system.

[0066] After creating a set of exception rules for one or more data sources and storing these rules in the rule database 124, for example, the quality inspection management system 112 can thereafter implement the exception engine 122 in real time during the operation of the data source to detect anomalies that may occur due to the operation of the underlying process that the data source application monitors, controls or affects. When configured to run or execute on data from a particular data source, the exception engine 122 periodically or intermittently receives a data set (e.g., metadata) from the data source, which indicates various operating parameters of the process and / or the application that monitors or controls the process. For each data set, the exception engine 122 obtains and applies the logic of the exception rules created for the data source to detect anomalies in the process implemented, managed or monitored by the data source. When connected or communicating with the data source, the exception engine 122 can receive data sets from the data source periodically, when a specific action or multiple specific actions occur in the process or data source, and / or at other configured times. The exception engine 122 can subscribe to such data based on the data source configuration data within each exception rule for the data source, can poll the data source at different times to obtain such data, or can implement a combination of these communication techniques. In this manner, when a data source such as the workflow application 40 operates to receive new data and interface with an operator (e.g., to help the operator analyze batch process data from the batch executors 22), the workflow application 40 also sends the 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 anomalies have occurred in the underlying process.

[0067] During this process, the exception engine 122, which is a logic engine, parses the data sent from the data source and applies the logic within the appropriate rule set, such as the rule 156A in the database 124, to analyze the data according to the rules to detect one or more anomalies. The exception engine 122 can apply the rules to the data one by one in the order specified in the rule set stored in the rule database 124, and can detect any anomalies determined by the rules, or can stop processing the data when any rule detects an anomaly on a particular data set. After detecting an anomaly, the exception engine 122 creates an exception record for the data set and stores the exception record in the exception record file 170 ( Figure 2). Of course, as the workflow application 40 (or other data source) provides each new data set to the exception engine 122, the exception engine 122 processes the exception data and determines whether there are any exceptions, and then creates an exception record when appropriate and stores it in the exception record file 170. The exception engine 122 can store a variety of different types of data associated with the exception record, including, for example, the name of the exception identified or detected, the severity of the exception, the inspection or resolution procedures to be applied, comments entered by the operator as part of the data sent from the data source, general information about the exception, etc. Further, the exception engine 122 can provide metadata as part of the exception record, which metadata in some way defines or relates to the operation of the batch or other process equipment at the time of the exception. The metadata can be provided to the exception engine 122 as part of the data from the data source, or can be obtained by the exception engine 122 from the data source (e.g., the workflow application 40), or from a database or other source of such data separate from the data source. The metadata stored in the exception record can be any data that defines some operating parameters, values, states, or other information associated with the process being implemented when the exception is detected. The metadata may be, for example, batch status information, process parameter values ​​measured or determined from the process, process equipment information, alarm or warning information from process equipment, or any other information. In addition, the 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 source itself as part of the initial data processed by the exception engine 122, or in response to a query made by the exception engine 122. In general, the stored metadata provides a snapshot of the process at the time the anomaly was detected (e.g., process status information, process equipment information, process variable values, batch procedure model state, etc.). The metadata may be displayed as part of the anomaly record to enable a quality engineer to understand the context of the anomaly (e.g., what happened in the process at the time of the anomaly), thereby better understanding the anomaly and the significance of the anomaly.

[0068] As will be understood, the exception engine 122 operates in real time, that is, in an ongoing manner in series with the data source to analyze the anomalies of the data from the data source and store the anomaly records of the detected anomalies in the anomaly database 170. The exception engine 122 can be operated to receive a new set of data packets from the data source (e.g., the workflow engine 40) at any time period. For example, the exception engine 122 can analyze the data from the workflow application 40 while running a specific batch process, and can stop when the batch process or order is completed. Of course, the exception engine 122 can operate to analyze and detect anomalies of multiple different batch runs, such as from the same data source (e.g., the workflow application 40), and / or can analyze data from different data sources at the same time. In all these cases, the exception engine 122 can simultaneously run for each different batch of a single data source and / or create and store anomaly records for each different data source. Therefore, the exception engine 122 can understand that different batch runs occur at the same time, or that data from different sources are processed over the same time period, and can track these runs and processes separately so as to create a different anomaly database 170 for each batch run, order and / or data source.

[0069] Figure 4 The operation of the exception engine 122 on multiple different data sources (DS) 180, 182, 184, and 186 is shown. The data sources 180-186 can 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 can be 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 receive and send data packets 188 with data source metadata to the exception engine 122. These data packets 188 can be formatted to include data from the data source, as specified by the metadata configuration information within the rules for the data source, and these data packets 188 can include an identifier of the data source, an order implemented by the data source, the data source metadata, etc.

[0070] The exception engine 122 receives each data packet 188 from different data sources 180, 182, 184 and 186 and processes the data packets in the order in which the data packets are received. For each packet 188, the exception engine 122 can determine the identity and order of the data source (as specified by the data within the data packet 188), can obtain an appropriate set of rules for the data source from the rule database 124, and can apply the obtained rules to the data within the data packet 188 in a predetermined order to determine whether an anomaly exists. If the exception engine 122 processes all rules for the data source without detecting an anomaly, the exception engine 122 waits for or begins processing the next data packet 188 (from the same or different data source). On the other hand, if the exception engine 122 detects an anomaly based on the application of rule logic to the data source metadata, the exception engine 122 creates an exception record 180 for the order and stores the exception record in the exception record database 126 as an exception record file or database 170 for the order. That is, all exception records for a particular order may be stored as a set of exception records for the order. In any case, if Figure 4 As shown in the figure, the exception engine 122 can simultaneously operate on data from various different data sources and / or for various different orders (from the same or different data sources) to generate an exception database for each order.

[0071] An additional benefit of the exception engine 122 is that it operates in real time, that is, during the operation of the underlying process, and thus can detect the occurrence of anomalies in real time, for example, when anomalies occur. As a result, a feature of the exception engine 122 is that when an anomaly is detected to occur, the exception engine 122 can immediately or in real time notify an operator or some other person at or associated with the data source that an anomaly exists, which can enable the operator or other person to take action within the process to mitigate or avoid the anomaly. In some cases, the anomaly rules can be configured to detect the possible occurrence of future anomalies based on the action or state of the current process. In this case, the exception engine 122 can detect that an anomaly may or is likely to occur, and can notify an operator or other user in real time that an anomaly is likely to occur. The notification provides the operator or other user with the ability to reverse an action or change a parameter that is the root cause of a future anomaly before the anomaly occurs. Therefore, by enabling an operator or other process monitoring or control personnel to take action to avoid or reverse the situation that caused the anomaly, this real-time feedback can be used to avoid or immediately mitigate the anomaly.

[0072] Figure 5 It is shown that it can be obtained by, for example Figure 2The workflow application 40 provides a screen display 200 to an operator as part of the normal operation of the workflow application 40. In this case, the display 200 may provide process information to the operator in the form of a process or workflow diagram 202, and may enable the operator to take some action or actions in the process via an input field 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, when the operator enters the new set point, or immediately after entering the new set point, the workflow application 40 sends a data packet with an indication of the change to the exception engine 122. In this example, the exception engine 122 may be programmed to implement a rule to determine whether the value of the process parameter is within a specific range (because the process parameter may be a critical process parameter for quality purposes). The exception engine 122, when running the rule, may detect that the critical parameter is set outside the expected range, and therefore an exception will result if the set point is changed. The exception engine 122 may then immediately send a notification to the application 40 via a real-time feedback message, which may result in a notification or alarm being provided to the operator. For example, if Figure 5 As shown, a pop-up box 206 can be created in screen 200 based on the real-time feedback message, telling the operator that the expected action or the action just taken will (or does) result in the creation of an exception record. The message in the pop-up box 206 can instruct the operator to take action to avoid or mitigate the exception (if it has already occurred). Therefore, as will be understood, the rules created for the data source and stored in the rule database 124 can be related to detecting actual exceptions and / or detecting the possible occurrence of conditions that will cause exceptions in the future. In addition, the real-time feedback feature of the exception engine 122 can be used to enable the user to avoid the occurrence of future exceptions or mitigate or reverse the conditions that caused the currently detected exception. Because the notification is real-time for the operation of the process, it is more likely that the impact of the exception can be reversed or mitigated using this real-time quality feedback technology.

[0073] Although Figure 2 The operation of the quality inspection management system 112 in the process plant environment 110 is shown, wherein various parts of the system 112 are executed in a dedicated server and database, but the quality inspection management system 112 can be implemented in a plug-in environment, making the system more portable, easier to use on mobile or distributed devices, easy to maintain and implement in a distributed environment, and easy to configure for third-party systems or applications. Specifically, Figure 6 A quality assurance management (QRM) system 300 implemented using a plug-in is shown. Figure 6The quality inspection management system 300 includes a quality inspection service device 302 (which can be stored in and executed on a server or other computing device), which is communicatively coupled to various data sources 304A, 304B, 304C, etc., the rule database 124 and the configuration application 122. Further, the quality inspection management service device 302 is coupled to various plug-ins 310, 312, 314, 316, etc., which can be stored and run in any desired computing device, such as a workstation within or outside the factory environment, stored in a mobile device, such as a laptop, a phone, etc., or stored in any other device. The plug-ins 312-314 can be created (instantiated and started) as needed for any particular order or data source. In this case, each plug-in 310-316 can be created for a particular data source and / or for a particular order within a data source to analyze data from the data source for anomaly detection. When the order or application is completed or ended, the plug-in can be deleted (destroyed).

[0074] In general, the QRM service device 302 can create a specific plug-in for a specific data source or a specific order from a specific data source in response to the configuration application 122. Each plug-in 310-316 can include configuration information provided as part of the configuration of the plug-in 310-316, to notify 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 of the abnormal record file or database for storing the data source or order, and any other desired configuration data required for the operation of the plug-in 310-316. In addition, if necessary, the configuration data of 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 the same data source or different data sources (configured for the same data source or different data sources), so, depending on the data source or the use of the plug-in 310-316, the configuration information of each plug-in 310-316 can be similar or very different. The configuration information of each plug-in 310-316 can also specify the data to be subscribed or received from the QRM service device 302 or from a third-party application or source during operation, and the plug-in 310-316 can register with the QRM service device 302 or other application or source to receive the data. Typically, the plug-in 310-316 can simply operate to obtain specific data from a data source, so it only needs to be configured to understand what data comes from the data source and the format of the data. Then, the plug-in 310-316 can receive and process the data from the data source and place the received data in the format used by the exception rules created for the data source. In this way, the plug-in 310-316 can operate as a data collection and interpretation application for any type of data source, even a third-party or proprietary data source.

[0075] In addition, each plug-in 310-316 may include a runtime processing configuration that defines or controls the operation of the plug-in 310-316 during operation. The runtime portion may include a logic parser that analyzes the data received from the data source using the rules or logic within the exception rules for the data source and creates and stores exception records in the exception record database or log 170. In essence, the runtime portion of the plug-in 310-316 is implemented on an instance-by-instance basis. Figure 2 Exception engine 122. Therefore, as described above, plug-in modules 310-316 can be created to dock the exception engine 122 with an external or third-party system (e.g., a control system, an OPC interface, a maintenance system, etc.); thereby enabling exceptions to be generated based entirely or partially on data from a third-party or external software system. In one example, a plug-in is created to access specific data in or from a third-party or external system, and the data is passed to the exception engine 122 to analyze whether an exception should be created. However, the plug-ins 310-316 can be stored in a third-party server, in the QRM service device 302, or in another server, mobile device, or other processing device, and executed therein.

[0076] As an example, Figure 6 The configuration application 122 can be used to create one or more plug-ins 310-316, including specifying the format of data to be received from the data source and to be analyzed by the plug-in 310-316, the frequency with which the plug-in 310-316 should receive data from the data source, the identification of the order and other information about the data source, the type of application that the plug-in 310-316 will be used to process, etc.

[0077] In addition, if necessary, plug-in modules 310-316 with data acquisition functions and runtime exception handling capabilities can be created. Once created, plug-ins 310-316 can be stored in any convenient location or processing device and executed therein, such as a device close to a data source or multiple data sources. In addition, plug-ins 310-316 can register with data service device 302 (or with any other server or device) to receive data from an appropriate data source such as one of data sources 304. QRM service device 302 can then subscribe to or poll appropriate data from data source 304, and when receiving data packets from the data source, plug-in modules 310-316 can be provided with the data and one or more exception rules for the data source for analyzing the data. Then, plug-ins 310-316 can use the rules in its logic engine to analyze the anomalies of the data, and when anomalies are detected, anomaly records can be stored in the anomaly record database 170 of the data source. Thus, as will be appreciated, the QRM service device 302 acts as a data broker for the plug-ins 310 - 316 , which can operate independently of one another on any desired device using any data or data obtained from different sources.

[0078] As will be appreciated, the quality inspection management system 128 can implement the use of plug-ins or plug-in modules on a source-by-source basis to perform the functions of the anomaly engine, as described herein, so that the quality inspection management system can be easily configured for different data sources, for different quality inspection standards, and / or easily run in a distributed environment in which various different parts of the system are executed in different computers throughout the factory. 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 for performing anomaly detection from a specific data source.

[0079] In addition, plug-in modules 310-316 can perform or not perform exception handling and detection in batch or order processing environment.In some cases, for example, one or more of plug-in modules 310-316 can be created to perform or enhance process or event monitoring in the factory, or perform quality inspection in the factory, such as in a continuous process manufacturing plant.Therefore, plug-in modules 310-316 can be simple third-party system data collectors, or data can be collected and some exception handling can be performed in addition, or abnormal or pre-processed abnormal data can be provided to an independent abnormal engine.It is advantageous to use plug-in modules to realize quality inspection, because known quality inspection products can not be docked with data directly provided from external software programs (such as control systems, safety systems, maintenance systems, etc.) or create abnormalities based on data directly provided from external software programs.In addition, the use of plug-in module environment makes the quality inspection management system 112 described herein more robust in a complex process environment with a plurality of different software systems operated during runtime.

[0080] Figure 7 An example of a data or event monitoring system using the quality inspection exception handling techniques described herein is shown. In particular, Figure 7 A high-level diagram of a process plant 400 is shown in which a continuous process or process equipment may be operated. Figure 7 As shown, the process plant 400 includes process control equipment 402, which may be associated with, for example, running or implementing a continuous process (e.g., a crude oil refining process) or a batch process or both. The process plant 400 may include one or more batch executors 404 connected to the process control equipment 402, and one or more operator interfaces 406 that monitor one or more parts or components of the process control equipment 402. Further, the batch executors 404 and the operator interfaces 406 may be connected to a main plant control device 410, which may store configuration and control information for the plant 400. Further, the plant 400 may include one or more application servers (AS) 411, which may run other applications, including, for example, database applications, monitoring applications, plant analysis applications, etc.

[0081] In many cases, the plant assets within the plant 400 run proprietary or third-party control, monitoring and asset management systems that collect large amounts of data from the plant during operation. In addition, operator monitoring applications and interfaces 406, batch actuators 404, or other control applications may also be priority in nature. It is known in process control technology to use OPC interfaces to obtain data from various third-party or proprietary applications. Therefore, each operator interface 406 may include an OPC alarm and event (OPCae) 412 or an OPC data access (OPCda) interface 412, for example, to enable detection and use of alarm and event data (such as generated in the plant 400, such as in the process device 402) or other process data to be used by an external system. In addition, in some cases, one or more monitoring applications 414 may be stored in one or more plant devices, such as in an application server 411 or a separate event monitoring (EM) server 416. The event monitoring application 414 may be a known application for interfacing with one or more batch executors 404 to obtain process event information (although not necessarily via an OPC interface), and / or may be configured to interface with one or more OPCae or OPCda interfaces 412 to obtain alarm and event data or other data from the process control network 402. The event monitoring application 414 is conventionally used to obtain process data such as event and alarm information from plant assets and store the data in a database for later review or use in various systems such as process control analysis systems, maintenance systems, etc.

[0082] However, the exception handling structure described herein can be used to process alarms and events and other information obtained from the event monitoring application 414 to determine whether certain plant conditions occur within the plant equipment 402 or during the operation of the plant equipment 402. By way of example only, such conditions can include when certain events or alarms reach critical levels, when a certain 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 need to be indicated to a user of some kind, such as a quality inspection engineer, a safety engineer, etc. In order to perform this function, Figure 7The event monitor plug-in 450 can 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, and the like. The event monitoring plug-in 450 can receive data from the event monitoring application 414, the OPCae and OPCda interfaces 412, or other data sources in the plant 400, and can perform exception rule processing to detect the presence of certain, typically more complex conditions in the plant 400. That is, there may be conditions in the plant 400 that a quality inspection engineer, a safety engineer, a maintenance engineer, a process control engineer, or others may want to know about, but which were not detected by these systems when the process control or monitoring system was established and the plant 400 was operated. Typically, these conditions are not simply determined by a single alarm or event notification generated in the plant 400, but may need to be determined by a more complex set of conditions existing in the plant 400, such as alarms exceeding a certain critical level, a certain number of alarms of a certain type occurring simultaneously or nearly simultaneously, alarms of a certain type or severity combined with one or more other events in the plant 400, and the like. As will be appreciated, the plug-in module 450 may include or provide access to an exception engine (as otherwise described herein) that operates using rules implementing logic to determine these "anomalies" in the operation of the plant 400. Thus, Figure 7 The event monitor 450 of the embodiment can collect data from third-party applications (event monitoring application 414) or systems (event monitoring server 416) or interfaces (OPCae interface 412) and can process the data using a pre-configured set of rules to perform enhanced event detection or process monitoring or exception handling for quality inspection purposes. In this case, the event monitoring application 450 (which can be located in an environment different from the factory environment, such as Figure 7 The results of the rule analysis may be provided to a monitoring interface 452 and / or a database 454, such as a SQL (Sequel) database, for later inspection. In essence, the event monitoring plug-in 450 operates to detect "anomalies" in the operation of the factory equipment 402 based on event monitoring data collected by the factory equipment 402 and provided to a third-party application or interface in the factory 400. This type of monitoring is still referred to as exception handling herein because such monitoring detects anomalies in the operation of the factory 400, even if it is not performed as part of a quality inspection process.

[0083] In any case, the event monitor 450 can be bound to any of one or more third-party or external systems and can be used to generate and send messages to a rule engine (not shown), which can 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 can be bound or coupled to the OPCae interface 412 and can identify when one or more alarms or warnings are passed from the OPCae interface 412. At this time, the event monitor application 414 or the OPC interface 412 creates a message with alarm or warning information and potentially any other desired OPC collected data and delivers the message to the external event monitoring system 450. The system 450 can then analyze the message to generate anomalies based on the data in the message. This operation is advantageous because known quality inspection systems do not analyze data from third-party systems and are not connected to existing OPC warning and alarm interfaces. Therefore, these systems cannot generate anomalies based on, for example, process alarms and warnings.

[0084] Generally speaking, Figure 7 The event monitoring system 450 of the embodiment of the present invention can be configured in many different ways to collect and process alarm and event data from the process control system 402 to produce an enhanced monitoring system using exception processing. In particular, a user can configure the event monitoring system or module 450, which can be a plug-in as described above; to subscribe to and collect, for example, alarms and event data generated by the process control system 402. Figure 7The event monitoring server 416 that collects the data (e.g., event and alarm data, messages, etc.) can then send the data in the form of data packets to the event monitoring application 450 along with other information, such as timing information, process control metadata (obtained from the OPC interface 412, the batch executor 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 there are any event monitoring anomalies based on the collected event and alarm data and the rule logic. If an anomaly is determined, the event monitoring system 450 can 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 in, for example, a Sequel server. Of course, the rules that generate the anomaly can specify the content of the message, the format of the message, the information to be placed in the message, the interface to which the message is to be sent, etc. In addition or alternatively, the event monitoring system 450 can create an anomaly record and send it to the monitoring database for storage and later retrieval. The exception record (which is a monitoring condition record) may include any desired information based on the rule configuration, and may include, for example, an explanation of the event, the severity of the event, instructions for handling the event, process metadata at the time the event occurred, etc. As will be appreciated, in this case, the rule logic for the event is processed in the event monitoring system 450 (or in an exception engine coupled thereto) and may be stored in a repository such as a repository. Figure 6 In a plugin environment such as Figure 2 is handled in a traditional server environment.

[0085] In another case, the event monitoring system 450 can configure the OPC interface 412 based on its configuration, for example, to detect certain conditions or combinations of conditions, and then send messages to the event monitoring system 450 when these 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 rule and send messages or data to the event monitoring system 450 only when the logic is met. Upon receiving a message from the OPCae interface 412 with an indication that a specific condition or set of logic is met, the event monitoring system 450 can simply create a communication and send it to the event monitoring interface 452 and the database 454 to notify the user of the condition and store an exception record in the database 454. In this case, the logic of the rules for the event monitoring system is fully or partially executed in the OPC interface 412 or the external event monitoring application 414, 416, which can be configured using known techniques to implement the logic and send messages only when specific conditions exist in the process plant 400.

[0086] Therefore, in Figure 7In the example system of the quality inspection management system described herein, the anomaly-based processing can be used to analyze, inspect or detect anomalies in data from third-party systems that do not use the same data format as, for example, the workflow application 40. Figure 7 In the present case, the quality inspection management system is shown as being used as an event monitoring system to interface with a batch or continuous process control system via one or more OPC interfaces 412 to determine monitoring-based anomalies based on the existence of various events, alarms, parameter settings, etc., but the quality inspection management system described herein can be connected to third-party process equipment, servers, applications, etc. via any other desired interface.

[0087] Return to reference Figure 2 , the quality inspection interface application 128 can be executed to enable a user (e.g., a quality inspection engineer) to access one or more exception record databases 170 for one or more batch runs, orders, process operations, etc. from a specific data source. The quality inspection interface application 128 can, for example, enable the user to step through each exception record in the exception database 170 one by one to view the detected exceptions and resolve them, such as taking any necessary actions to close the exception records. The quality inspection application 128 can present data or information for each exception record via the interface screen of the interface device, such as the name of the exception, the type of exception, the severity of the exception, the batch metadata or snapshot information stored for the exception record, the annotations created and stored by the operator that are associated with the exception record or cause the creation of the exception record, any other information provided by the data source, etc. This information enables the quality inspector to quickly understand the context of the exception and the process (e.g., batch run) when the exception occurs, so as to better understand the exception and the significance of the exception. The quality inspection interface application 128 can also present various other types of information to the user in a structured manner, such as general information about this type of exception, what steps need to be performed to handle or sign off this type of exception, or the severity of the exception. Further, the quality review interface application 128 can enable the user to take one or more of the various steps required to sign off or close the exception, such as implementing one of the various procedures defined by the original exception rule that detected the exception, in order to sign off or handle the exception. The quality review application 128 can, for example, enable the user to click a check box on the screen to confirm and sign off on the exception, can require or enforce a process that includes having one or more other personnel review and sign off on the exception in order to close the exception, etc. Further, the quality review interface application 128 can send the exception record to other personnel via email or other network communication to obtain a sign-off on the exception, ask questions about the exception or provide data or comments about the exception, determine more information about the exception, or implement procedures necessary to handle or close the exception.

[0088] Figures 8A-8GVarious example screen displays that may be created by the quality inspection interface application 128 are shown to enable an inspector to view and manipulate exception records in the process of performing a quality inspection of, for example, an order. As an example, Fig. 8A A screen display 500 is shown that can be used by an inspector to select one of various order or exception record file sets to be inspected. Screen 500 includes a list of the exception record logs 170 (e.g., as stored in Figure 2 126) of the exception log database 126. In addition, area 504 may list the set of order or exception log files 170 that exist for the selected data source in area 502. Fig. 8A In the example screen 500 of FIG. 500 , field 502 lists the workflow data source, and region 504 lists a plurality of various exception record files for an order or batch run managed by the workflow application. Further, region 506 may list exception records within a specific file (e.g., an order) selected in region 504. The user may scroll down list 506 to select different records in exception records 506A-506N. Further, region 508 of screen 500 may present information of exception records 506A-N as selected in region 506. In this example, the user has selected exception record 506B, and application 128 obtains information of the selected exception record 506B from exception record log database 126, and displays the information for user use and manipulation. Region 508 may include various information for the selected exception record, such as name, type, severity, information for the exception, and an inspection or handling process for the exception.

[0089] Importantly, the display information of the exception record can include process or data source metadata 510 collected from the data source when the exception is created. As described above, the quality inspection management system 112 collects a set of metadata when collecting input data from the data source (the metadata set can be predefined when, for example, a plug-in or rule is created, or the metadata set can be data known to be provided by a specific data source). Typically, the metadata to be collected is defined by a data transformation configured when creating a rule. The data transformation is applied to the metadata from the data source, and the plug-in outputs the transformed metadata in, for example, HTML, so that the metadata is visible in the inspection application. This data source metadata can be any process or environment data, which is usually collected at the same time as the exception input data and is stored as a process snapshot associated with the accessed exception data as part of the exception record created for the exception. In this way, 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 inspection interface application 128 then displays some or all of the metadata in a field 510 of a screen 500 that reports the generated exception, for example, thereby providing a real-time view into the process to the inspector when the exception is generated in the process. Therefore, this feature provides the inspector with a quick view of various process states / values, etc. at the time of anomaly, which enables the inspector to more quickly understand why the anomaly is generated, the context of the anomaly, etc., so that the inspector can more quickly handle or know how to solve the anomaly. This operation makes quality inspection easier, because although known quality inspection products usually provide the inspector with a list of generated anomalies, the inspector still has to analyze each anomaly to determine whether the anomaly can be eliminated or must be handled in some other way, and in these known products, the inspector usually has to return to the process system that collects the data that caused the anomaly to obtain the process snapshot data at the time of the anomaly. Utilizing the real-time view feature provided by the metadata field 510 of the screen 500, the inspector is automatically provided with a process snapshot, which will usually include the process data that is most useful to the inspector when performing anomaly inspection, which means that the inspector does not need to return to other data collection systems to obtain the information required by the user to perform anomaly inspection and processing. This feature also means that the inspector generally does not need to be familiar with other process data retrieval systems from which process or data source metadata is usually collected, because the inspector generally does not need to use those data collection systems to access the process data required by the inspector to solve the anomaly record.

[0090] Furthermore, if Fig. 8A As shown, area 512 can 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 list of actions to perform to close the exception, sign-off fields that need to be filled in or signed by various users to close the exception, etc.

[0091] Figure 8B An example screen display 520 of some information of an exception record of an example type workflow note is shown. Here, the workflow exception in screen area 506 is the only exception listed for the selected order. As shown in area 508 of screen 520, the workflow note has a status of NEW, a severity of LOW, does not have a corrective and preventive action (CAPA) identifier (which can be used to define a reference to a third-party system that can also be used to view and / or process the exception) or is not associated with it, and is not assigned to any group. However, area 508 displays the exception ID (because each exception will have a unique ID), the source indication, and the creation date / time of the exception, all of which data are stored as part of the exception record. Further, area 508 includes a general description of the exception, which can also be information stored as part of the exception record. However, this data can be stored as part of the inspection application 128 and can be based on the exception type.

[0092] Likewise, the bottom portion of screen area 508 shows the metadata collected for this particular exception. In this case, the metadata reflects what the user saw in the workflow application when the exception was created, and can be used to help the reviewer understand the context of the process when the exception occurred.

[0093] Furthermore, Figure 8C Example screen 530 provides information about the Figure 8B A list of resolution fields is provided to the reviewer in screen area 508 to perform processing or closing of the exception record. Here, the resolution may be configurable as needed (and thus similar screens may also be used in the configuration application 120 to generate rules for exceptions). In any case, as Figure 8C As shown, the resolution field may include a resolution name or type 532 (e.g., standard), a description 534, one or more phase names 536 (e.g., manufacturing or manufacturing oversight), a severity 538 (e.g., low), and a signature 539 required by a person to close or resolve the anomaly in one or more phases. In this case, Figure 8C The solution to the sample exception record shown in indicates that the exception must be signed by two operators (in the manufacturing phase) and one administrator (in the manufacturing supervision phase) to close or resolve the exception. These handlers can be found in Fig. 8A The procedures may be implemented in the form of a signature box, check box, etc. in the area or field 512. In addition, the inspector can change these procedures on an exception by exception basis, or can group the exceptions and take steps based on the grouping.

[0094] As an example, Fig.8DAn example screen display 540 is shown including a screen area 508 having a resolution field 542 for the selected parameters of the out-of-range exception. Again, here, screen 540 includes some information about the selected exception record, including status (active), severity (low), CAPA identifier, and group name (if any). Resolution area 542 includes a field 544 that enables the inspector to browse to attach files to the exception record (which may be useful later when the customer, FDA, etc. inspects the exception record for the order), and a note field 546 that enables the inspector to add a note or annotation to the exception record (here the SA administrator has noted that she will take care to close the exception record). Of course, additional notes can be added using field 546. In addition, screen area 508 of screen 540 includes a signature and close field 548, which can be used by various required signatories to close the exception record. Further, screen area 508 can include a history field 549, which indicates the actions taken on the exception record when the record was processed, including what action was taken, who took the action, and the time and date of the action. This information may be captured by the inspection interface application 128 and stored as part of the exception record.

[0095] Likewise, various screens presented by the quality check interface application 128 may include statistical information about an order or group of orders. For example, area 550 of screen 540 includes an indication 551 of the order being viewed, an indication 552 of the number of exception records associated with the closed order, and an indication 553 of the completion status of the order (in this case, the order is not yet completed but is still being processed). Area 550 may also provide a link 553 for a checker to sign and verify the order or exception records for the order, etc.

[0096] same, Fig. 8E Screen 560 shows additional statistical information that the quality inspection application 128 can determine and provide to the inspector on an order-by-order or group-by-group basis. Fig. 8E The screen 560 is similar to Fig.8D Screen 540 of the embodiment of the present invention is shown, except that area 562 displays various statistical information about 11 exception records in the selected order. In this case, box 564 indicates the number of exception records for the order in each status category (new, active, closed). In addition, bar chart 566 indicates the number of exception records for the order according to each severity category (5 for low, 3 for medium, 2 for high, and 1 for new). Further, bar chart 568 indicates the number of exceptions for the order in each exception type (9 for out-of-range parameter type and 2 for comment type). Of course, the quality check application 128 can provide other types of statistical information about exception records, and can provide statistical information in other ways, such as for groups of orders, subsets of records within orders or groups, etc.

[0097] Furthermore, the quality inspection interface application 128 may enable the inspector to group various exception records in the exception record together into a group, and take various actions (annotate, change parameters, sign off, etc.) on the records as a group. As an example, Fig.8D and 8E Each of the screens 540 and 560 includes a list 570 of three groups of records within the exception record list, namely, the first group, the second group, and the tester. The application 128 enables the reviewer to add exception records to the groups, for example, by selecting the exception records in the exception record list 506 and dragging and dropping the selected exception records to the groups in the list 570. Of course, the application 128 can enable the annotator to create new groups, delete groups, etc. as needed in any suitable manner.

[0098] Still further, the application 128 may enable the reviewer to take one or more actions on the outlier records on a group basis, which saves time for the reviewer. Fig.8F An example screen 580 is shown where the reviewer has selected a group tester for a group action. As a result of this selection, the application displays a pop-up window 582 of potential 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 a drop-down input box 584), changing the CAPA identifier of the exception records in the group (via a drop-down input box 586), adding a note to each exception record in the group (via an input box 588), attaching documentation 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 enable 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.

[0099] If desired, the quality inspection interface application 128 may enable the inspector to take group actions on outlier records that are not actually associated with a group. Figure 8G As shown in the example screen display 592 of FIG. 500 , the inspector can select check boxes (in the Figure 8G In the example of , the first two exception records are thus selected). The application 128 may then recognize this as an attempt to take action on the two exception records that were checked, and may provide a Fig.8F However, in this case, the pop-up box 594 may include grouping actions to be taken on the selected exception records, such as adding them to an existing group or creating a new group, such as Figure 8G As shown at the top of pop-up box 594.

[0100] The quality inspection interface application 128 described herein may use advantageous paging algorithms or techniques to enable the inspector to scroll through the various record pages, e.g. Fig. 8A , 8B 8D-8G, the exception records provided in the record list 506 are scrolled in a manner that reduces or eliminates the presentation of duplicate records in different pages or missing records in the display when traveling between pages of records. Typically, web-based or browser-based display systems use a browser to display a list of organized records stored in an external structured database (e.g., an SQL database accessible via a network connection), and the display system searches the database for relevant records and then presents multiple records that will fit on the display page, such as 10 records at a time. Therefore, these systems will typically first display the records in the first ten positions of the returned list. When the user wants to see more records outside the currently displayed list, the browser contacts the database using the same search and obtains the next set of records (e.g., the records in the next 10 positions) if the user scrolls down in the record list, or obtains the previous set of records (e.g., the records in the first 10 positions) if the user scrolls up in the record list. Of course, there may be a large number of exceptions or records, so when the user scrolls down or up in the record list, the interface must scroll through many pages of records. Thus, the browser of the display system will determine all relevant records associated with the query and present a first page as the first X records in the list (e.g., records 1-10 if X is 10). When the user wants to view records that are not in the first page, the system loads a second page as the second set of X records in the list (e.g., the records in positions 11-20 of the list). The system then scrolls up or down X positions in the list to present an earlier or next page of records. This paging algorithm works well when the list of records is static and does not change very frequently because the system simply loads a successive set of X records as each new page.

[0101] However, when the records in the list or search change, such as when some records disappear or are discarded from the search due to some parameter changes of the records, or when new records are created in the database, the original list of records found by the search changes, and these changes may occur during the time when the examiner is checking a page of records but before calling the next page of records. In this case, when the examiner processes the records and scrolls down the list of records displayed on the user interface, the records may change in the database, so the page data may become outdated. In particular, records may be added to or deleted from the database (or the records may have changed parameters that make the records no longer returned by the search according to the search criteria). As a result, when the display system attempts to present the records on the display screen for subsequent pages, various records referenced in the original search may be lost, resulting in loss or duplication of visual data. In some cases, the user may miss records from one page to the next page due to deleting records on a specific recovery page. In other cases, the system may become confused about where to start a new display page based on missing records in the original returned list of records. In another case, the display system may present the same record on multiple pages based on adding new records to the database. Neither of these situations is desirable in an inspection system where it is important for the inspector to review and sign off on every record in the list, as is the case with exception records in the exception record log for an order, as provided by application 128 .

[0102] Fig. 9A and 9B The above problem is illustrated in a typical browser-based display interface that displays records returned from a search for records stored in a database, wherein during the display activity, records may be added to or deleted from the database, or parameters of records may be changed in the database. In particular, Fig. 9AA list of related records 700 (including records R1-RN) returned from a search database at time T1 is shown, where records R1-RN may be all records for an order, or may be some ordered list of records based on some other search criteria, such as all open records for an order, all records of a particular severity, etc. In any case, a display system (e.g., a browser at a user interface) may receive list 700 at a first time T1, access the first seven records in list 700, and present these seven records in a display screen 704 on the user interface as first page records. Thus, display screen 704 includes records R1-R7 as first page records from the search. The display system may access the database to obtain a list of related records at a later time T2, such as when a user requests the next page of records. Assuming no changes have been made to the records in the database, the same list of records 700 is returned at time T2, and the display system will only access the set of records found in the second set of seven positions on the list (yielding records R8-R14) and display them in display 708 as second page records. If the ordered list of records 700 from the database remains static from time T1 to time T2, then Fig. 9A This operation shown in works well.

[0103] However, if a record is removed from the list of related records between time T1 when the first page 704 is presented and time T2 when the second page 708 is presented (e.g., one or more parameters of the record are changed so that the record will not be found in a record search), the display system may inadvertently skip display of the record. Fig. 9B An example is shown in which record R4 is removed from the search list (or discarded from the search list) after time T1 when the first page 704 is presented in the display, but before time T2 when the second page 708 is presented. In this case, the browser of the display system obtains and displays the first seven records R1-R7 in the first page 704 based on the list 700, such as at time T1. Fig. 9A However, when the browser of the display system accesses Fig. 9B When the browser accesses the records of the second page 708 in the returned list, the browser only accesses and uses the second set of seven records in the returned list 710, i.e. Fig. 9B Because record R4 has been removed at this point (because it may have been closed and thus removed or discarded from the list of related records), the display system displays records R9-R15 as second page records in display 708 because they were originally in the first page when the first page was displayed. Fig. 9A The record R8 at the eighth position in the list 700 is now in the list due to the removal of the record R4 between time T1 and T2. Fig. 9BThus, record R8 is not in the seventh position of list 710. Fig. 9B Of course, a similar situation occurs when records are added to a list or database during the paging process, but in this case, one or more records may be repeated or presented in consecutive pages due to the addition of records that cause a particular record that was originally in a location associated with one page to be located at a location associated with a different page at a later time.

[0104] This situation is disadvantageous when the reviewer scrolls through pages of unusual records with parameters that may change or where new records may be added, as this leads to situations where related records are skipped in the display, or where related records are repeated in different pages of the display.

[0105] However, the quality check application 128 described herein can use a different paging technique to determine which records to present in the various different pages displayed, and this new paging technique reduces or eliminates the display of duplicate and / or missing records when traveling between different pages. In particular, the quality check application 128 does not use a fixed or preset position or record position in the list of records returned from the database to perform paging, 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 record and the last record in the most recently displayed page, and then uses the marker or anchor to find the set of records to be displayed as part of the next page displayed. In this way, if any records are added to or deleted from the list of related records after the page is displayed, the set of records displayed in the next page will be the records in the list that were adjacent to one of the last displayed records (e.g., the first or last record of the previous page) when the new page was loaded.

[0106] Fig. 10A and 10B 1 shows the operation of the new paging algorithm or technique used by the quality inspection interface application 128. In this case, the data returned from the database search at times T1 and T2 are Fig. 10A and 10B The lists of related records 700 and 710 respectively include Fig. 9A and 9B The same set of related records as shown in Fig. 10A As shown, the interface application 128 presents the first page 704 as the first seven records in the display, but with an anchor (referred to as Anchor1) indicating the last or bottom record in the currently displayed page. bot) to indicate the last or bottom record (R7) displayed in the first page 704. The application 128 may also use a top anchor (herein referred to as Anchor1) to indicate the top or first record in the currently displayed page. top ) to indicate the first or top record (R1) in display 704. Then, when the application 128 loads the next page of records, i.e., page 2, the application 128 searches the returned list of records for the bottom anchor (Anchor1) of page 1. bot ), regardless of where the record is found in the returned list 700 or 710. The application 128 then uses the bottom anchor (Anchor1) of the list 700 immediately following the active page 1. bot ) for the list of records displayed in Page 2. The application 128 may then also remove the anchor Anchor1 bot , but an additional anchor for the next page record can be marked or stored (i.e., Anchor2 top and Anchor2 bot ) to indicate the top and bottom records displayed in Page 2 of display 708. Application 128 then uses Anchor2 bot Anchored records determine which records to display on the next page (page 3) when the user scrolls down the list on page 2, or use Anchor2 top The paging technique uses the marked records to determine which records to display in the previous page (for example, if the user scrolls up in the list of records in page 2 to return to page 1). As will be understood, the paging technique places anchors or markers on the records, or stores anchors or markers indicating the records at various positions of the currently displayed page, and uses these anchors to determine which records in the returned set of records to use as the first (or last) record for the next page, regardless of the actual position of the record in the returned list. In this way, records can be moved up and down in positions within the database or return list 700 between displays of different pages without being moved in different directions. Fig. 9A and 9B The way shown disrupts the paging display.

[0107] As an example, Fig. 10A The operation of using anchors is shown when no changes are made to the database between time T1 and T2 , resulting in records R1 - R7 being presented in a first page 704 and records R8 - R14 being presented in a second page 708 . Fig. 10B shows that when these anchors are used at time T1 (where the list of records returned is Fig. 10A 700) and time T2 (where the returned list of records is Fig. 10B When performing paging in the list 710 of records, operations of anchors in the list 710 of records are used. In particular, the display 704 of page 1 includes Fig. 10A The record list 700 in the database contains records R1-R7 of the state at time T1 when page 1 was created. However, application 128 uses anchor Anchor1 when loading page 1. top Label the record R1 and use anchor Anchor1 bot Next, at time T2, when the display application 128 obtains the record list 710 (which has now changed because record R4 is no longer in the list) to display page 2, the application 128 searches the returned list 710 for a record that has been marked as Anchor1. bot The application 128 then loads and displays the next seven records (in this case, records R8-R14) as Page 2 display 708, regardless of the fact that records R8-R14 are in the seventh through thirteenth positions in the list 710. Of course, the application 128 may indicate any number of anchors per page, but typically has two anchors per page to identify the top and bottom records in the current page, and then will load the records adjacent to or immediately following these anchors when loading subsequent pages. Using two anchors enables the application 128 to scroll up and down the pages in a manner that eliminates or reduces missing records in the display or duplication of records in different pages when the state of records in the list changes (such records are added or removed from the list).

[0108] The application 128 may use any marking technique, such as storing indications of the records located at the top and bottom anchor positions when a particular page is being displayed in separate anchor variables (such as in a browser or browser device), actually storing markers in a database associated with the records currently located at the anchor position in the currently displayed record page, storing one or more of the records in the current page as markers, placing temporary markers in a database immediately before or after the marked record, and the like. In addition, the markers or anchors may be stored in the application 128, the browser used by the application 128, the database storing the records, and the like. In addition, the application 128 moves or changes the anchor position or marker when a new page is accessed and displayed. Further, 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 where the anchor is located as an anchor, such as a time / date stamp of the record, and the like. In some cases, the anchor for a record may be based on or indicate a search parameter or some combination of search parameters for the record, or may be some other unique value for the record, such as a record name, identification number, and the like. Likewise, in some cases, the record associated with the marker may be a record that was discarded from a list of related searches. In this case, when the anchor record is not found in the new list (when loading a new page), the application 128 can change the anchor to a record in the currently displayed page that is adjacent to the now missing anchor record (e.g., a record immediately above or before the bottom anchor in the currently displayed page, or a record immediately below or after the top anchor in the currently displayed page), and then use the new anchor to determine the set of records in the return list to present in the newly displayed page.

[0109] Thus, the paging algorithm used by the quality inspection interface application 128 operates better than past paging systems because this new system downloads and presents records on a new display screen starting with 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 list of restored records, the system 128 accesses the database to find the record currently present in the new list that is immediately after the last record on the current display page (when paging down the list), thereby ensuring 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 is immediately after 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, records are not repeated in multiple display pages, and records are not missed during the inspection process when a user scrolls through pages of records over a long period of time when changes are made to 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 obtain the number of new records that will fit on the newly displayed page, while still ensuring that all related records are accessed as the user performs the scrolling process.

[0110] It will be appreciated that the quality inspection 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 in any process plant control system using any desired type of process plant control communication protocol. Although the applications and routines described herein are preferably implemented in software stored in, for example, a server, workstation, handheld device, or other computer, these routines may be implemented alternatively or additionally in hardware, firmware, application specific integrated circuits, programmable logic circuits, etc. as desired. If implemented in software, the routines or applications may be stored in any computer readable memory, such as a magnetic disk, laser disk, EPROM or EEPROM, solid state or other storage medium, in RAM or ROM of a computer, handheld device, controller, field device, etc. Likewise, the software may be delivered to a user or device via any known or desired delivery method, including, for example, over a communication channel such as a telephone line, the Internet, on a portable medium such as a computer readable disk, and the like.

[0111] Although the present invention has been described with reference to specific examples, which are intended to illustrate rather than limit the present invention, those skilled in the art will appreciate that changes, additions or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the present invention.

Claims

1. A quality inspection system for use in the operation of an inspection process, comprising: A rule database storing a plurality of rules, wherein each of the plurality of rules includes logic for identifying conditions associated with one or more exceptions within a process; one or more data sources configured to collect process data within the process during operation of the process and to send the collected process data in one or more data messages; an exception engine using the rules in the rule database to process the process data within one or more data messages from the data sources to determine whether an exception defined by any of the plurality of rules exists based on the process data within the data messages, wherein the exception engine, when identifying an exception based on one of the rules, creates an exception record for the determined exception and stores the exception record in an exception record an exception engine, wherein the event monitor is configured to detect a condition within the external system and send external information about the condition within the external system to the exception engine, and wherein the exception engine detects one or more additional exceptions based on the external information from the event monitor, creates one or more additional exception records for the one or more additional exceptions, and stores the one or more additional exception records in the exception record database; and an inspection interface that enables a user to inspect the exception and the additional exceptions identified by the exception engine and stored as the exception record and the additional exception record in the exception record database.

2. The quality inspection system according to claim 1, wherein: The external system is a process control system, and the event monitor detects events within the process control system.

3. The quality inspection system according to claim 1, wherein: The event monitor is communicatively connected to the external system via an OPC interface, and receives OPC data regarding the external system via the OPC interface.

4. The quality inspection system according to claim 3, wherein: The event monitor receives OPC alarm and event data from the external system via the OPC interface.

5. The quality inspection system according to claim 1, wherein: The exception engine executes in a first server, and wherein the event monitor executes in the first server.

6. The quality inspection system according to claim 1, wherein: The exception engine executes in a first server, and wherein the event monitor executes in a second computing device different from the first server.

7. The quality inspection system according to claim 1, wherein: The event monitor receives external system data from the external system and performs processing on the external system data from the external system to determine one or more conditions associated with the external system.

8. The quality inspection system according to claim 1, wherein: The exception engine analyzes the external information from the event monitor regarding the condition within the process using one or more rules within the rules database to detect the one or more additional anomalies.

9. The quality inspection system according to claim 1, wherein: The external system is a safety instrumented system, and the event monitor analyzes safety instrumented data.

10. The quality inspection system according to claim 1, wherein: The external system is a maintenance system, and the event monitor analyzes maintenance data from the maintenance system.

11. A monitoring system for use in the operation of a monitoring process, comprising: A runtime monitoring application, stored in a memory and adapted to be executed on a processor, the runtime monitoring application comprising: a configuration memory storing a configuration, the configuration comprising a plurality of rules, wherein each of the plurality of rules comprises a logic definition defining one or more predefined events to be detected within the process; a communication interface adapted to be communicatively connected to receive the configuration comprising the plurality of rules and adapted to be communicatively connected to an external data source to receive data messages from the external data source, and a logic engine operative during runtime of the process to process process data within one or more data messages from the external data source using the plurality of rules to determine whether a predetermined condition defined by any of the plurality of rules exists, wherein the logic engine, upon identifying the existence of a predetermined condition defined by one of the plurality of rules, creates a message identifying the predetermined condition and sends the message to an external recipient, and a configuration application, stored in the memory and adapted to be executed on the processor, to enable a user to create the configuration, including enabling the user to create each of the plurality of rules to be implemented in the logic engine and provide the configuration to the runtime monitoring application via the communication interface.

12. The monitoring system according to claim 11, further comprising an OPC interface, wherein: The runtime monitoring application is communicatively coupled to the OPC interface to receive data messages using an OPC protocol, and wherein a rules engine processes data within the OPC data messages using the plurality of rules.

13. The monitoring system according to claim 12, wherein: The multiple rules within the configuration specify a combination of data or events to be detected by the OPC interface, and wherein the runtime monitoring application configures the OPC interface to send a data message indicating a predetermined condition to the runtime monitoring application when the OPC interface detects the combination of data or events.

14. The monitoring system according to claim 11, further comprising a workflow monitoring system, the workflow monitoring system comprising a rule database storing a plurality of rules, wherein: Each rule of the plurality of rules includes logic that identifies conditions associated with one or more anomalies within a process; and an exception engine that uses the rules in the rule database to process data within a data message from a process device to determine whether an exception defined by any of the plurality of rules exists, wherein the exception engine, when identifying an exception based on one of the rules, stores information about the exception as an exception record in an exception record database; wherein the workflow monitoring system is an external recipient, and wherein the exception engine also processes the message from the runtime monitoring application that identifies a predetermined condition.

15. The monitoring system according to claim 14, wherein: The exception engine processes the message identifying a predetermined condition using the rules in the rules database to determine an exception based on the message identifying the predetermined condition.

16. The monitoring system according to claim 14, wherein: The exception engine processes the message identifying the predetermined condition by storing the message identifying the predetermined condition in the exception record database.

17. The monitoring system of claim 11, further comprising an event database, wherein: The event database is an external recipient, and the event database stores the message identifying a predetermined condition.

18. The monitoring system of claim 11, further comprising a monitoring user interface, wherein: The monitoring user interface is an external recipient, and the monitoring user interface displays the message identifying a predetermined condition to a user.

19. A method of monitoring a process, comprising: enabling a user, via a computer processor-based interface device, to create a monitoring application configuration by specifying a plurality of logic rules defining one or more predetermined conditions to be detected in a process; providing the monitoring application configuration including the plurality of rules to a runtime monitoring application; communicatively coupling the runtime monitoring application to one or more data sources associated with the process, the runtime monitoring application adapted to execute on a processor during operation of the process; receiving, at the runtime monitoring application, data messages from the one or more data sources associated with the process during operation of the process; processing, on a computer processor, data within the data message from the one or more data sources using the plurality of rules to determine whether a predetermined condition defined by any of the plurality of rules exists, and upon identifying the existence of a predetermined condition defined by any of the plurality of rules, creating a message identifying the predetermined condition; and sending the message identifying the predetermined condition to an external recipient.

20. The method of monitoring a process according to claim 19, wherein: Communicatively coupling the runtime monitoring application to one or more data sources associated with the process includes communicatively coupling the runtime monitoring application to the one or more data sources via an OPC interface communicatively coupled to the process, and wherein processing the data within the data message includes processing OPC data.

21. The method of monitoring a process according to claim 20, wherein: Enabling a user to create a monitoring application configuration by specifying a plurality of logic rules that define one or more predetermined conditions to be detected in a process includes enabling the user to specify a combination of data or events to be detected by the OPC interface.

22. The method for monitoring a process according to claim 21 further includes using the runtime monitoring application to configure the OPC interface to: when the OPC interface detects a combination of data or events specified by one of the multiple rules, send a data message indicating a predetermined condition to the runtime monitoring application.

23. The method of monitoring a process according to claim 19, further comprising implementing a workflow monitoring system on a processor, the workflow monitoring system comprising a rule database storing a plurality of rules, wherein Each of the plurality of rules includes logic for identifying a condition associated with one or more exceptions within a process, and an exception engine that uses the rules in the rules database to process data within a data message from a workflow control application to determine whether an exception defined by any of the plurality of rules exists, wherein the exception engine, when an exception is identified based on one of the rules, stores information about the exception as an exception record in an exception record database; and wherein sending the message identifying the predetermined condition to an external recipient includes sending the message to the workflow monitoring system.

24. The method of monitoring a process of claim 23, further comprising processing the message identifying the predetermined condition in the anomaly engine using the rules in the rules database to identify an anomaly based on one or more of the plurality of rules.

25. The method of monitoring a process of claim 23, further comprising storing a message identifying a predetermined condition detected by the runtime monitoring application in the anomaly logging database.

26. The method of monitoring a process according to claim 19, wherein: Sending the message identifying the predetermined condition to an external recipient includes sending the message to an event database and storing the message in the event database.

27. The method of monitoring a process according to claim 19, wherein: Sending the message identifying the predetermined condition to an external recipient includes sending the message to a monitoring user interface, and displaying the message identifying the predetermined condition to a user via the monitoring user interface.

Images