CN112232718A

CN112232718A - 质量检查管理系统

Info

Publication number: CN112232718A
Application number: CN202011312710.XA
Authority: CN
Inventors: J·B·基德; M·S·斯特兰奇韦奥查德; T·A·库克
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 2018-04-18
Filing date: 2019-04-18
Publication date: 2021-01-15
Also published as: GB2609752A; GB202017156D0; GB2597855A; GB2590538A; GB2586105B; JP7389201B2; GB2590160B; GB2597855B; GB2590179B; GB2590160A; US11442428B2; GB2590538B; GB202209882D0; US20210019685A1; GB202114208D0; US20210034034A1; US20210103874A1; US20210081407A1; GB2586105A; GB202016027D0

Abstract

一种质量检查管理系统可以用于基于由工厂中的各种数据源(例如批次执行器应用)收集的数据来分析工厂内的制造过程的操作，以自动检测、存储和显示这些过程中的异常，以供质量检查工程师使用，从而确定过程操作是否满足某些质量标准。该质量检查管理系统包括：配置应用，使得用户能够创建一个或多个异常规则；异常引擎，使用规则来分析过程数据，以检测过程中的一个或多个异常；以及检查应用，使得质量检查人员能够检查每个确定的异常以便解决。

Description

质量检查管理系统

本申请是名称为“质量检查管理系统”、国际申请日为2019年4月18日、国际申请号为PCT/US2019/028138、国家申请号为201980026906.1的发明专利申请的分案申请。

相关申请

本专利申请根据35U.S.C.§119(e)要求享有于2018年4月18日提交的题为“Quality Review Management System”的美国临时专利申请No.62/659,325的权益，其全部公开内容通过引用的方式明确地并入本文。

技术领域

本发明总体上涉及制造管理系统，具体而言，涉及质量检查管理系统，其能够实现关于制造工厂中实施的工厂操作、过程、批次和其他活动的高级质量检查程序。

背景技术

制造工厂，例如过程工厂，通常从一组原材料或预加工材料生产一种或多种产品。在许多情况下，生产的产品必须具有一定的质量或必须根据各种不同的质量标准之一制造以满足客户要求、工业标准、食品和药品管理局(FDA)要求、安全要求、标签要求等。在许多情况下，单独的质量检查人员被分派任务来实施与确保所生产的产品满足一组预先建立的标准或要求或被制造成特定标准相关联的各种活动。这些活动可以包括检查用于制造产品的制造设备、材料或过程的各种参数的状态或值，以确保实施适当的制造步骤，在各种期望的条件下制造产品，例如在特定温度范围、PH范围、压力范围等内。当然，这些质量检查任务取决于所制造的产品的类型、用于制造产品的制造过程或设备、所满足的质量标准等。因此，质量检查是许多制造环境中的高度专业化活动，需要产品、制造过程和质量标准的深层知识。

例如，批次过程通常用于制造由各种食品和药品行业或组织(如FDA)高度管制的各种类型的食品或药物产品。通常以某种方式设定或调节制造这些产品的具体过程步骤和条件，以确保所生产的产品的安全性或确保产品满足某些标签标准(例如，产品不含麸质、按犹太教食规清洁可食(Kosher)等)，作为一个示例，用于制造产品的过程步骤可能需要或要求在制造过程期间对原材料或中间材料实施某些过程步骤，在制造过程的制造步骤之内或之间对过程设备实施某些清洁程序，在整个过程中或在过程的关键时间期间将各种参数(如温度、压力、pH平衡等)保持在某些范围内或高于或低于某些阈值等。结果，在许多情况下，产品制造商需要收集和存储关于制造过程期间制造设备的实际操作的数据，以能够向管理当局或客户证明所生产的产品满足适当的质量标准，例如，产品是根据预先建立的程序或条件或在预先建立的程序或条件下生产的。

用于制造各种类型的产品(诸如食品、石油、药品等)的过程工厂通常是复杂的和高度自动化的。特别地，工业过程工厂，诸如在化学、石油炼制、食品制造、药品制造或其他过程中使用的那些，通常包括一个或多个过程控制网络，其具有通信地耦合到一个或多个现场设备的集中式或分布式过程控制器，现场设备可以是例如阀定位器、开关、传感器(诸如温度、压力和流速传感器)、罐、混合器、加热器等。这些现场设备或现场装置可以在过程工厂内执行物理控制功能(例如开启或关闭阀、搅拌或混合罐内的材料、加热容器等)，可以在过程工厂内进行测量以用于控制加工厂的操作，或者可以在过程工厂内执行任何其他期望的功能。历史上，过程控制器经由一个或多个模拟信号线或总线连接到现场设备，所述模拟信号线或总线可以承载例如去往和来自现场设备的4-20mA(毫安)信号。然而，在过去的大约二十年中，过程控制工业已经开发了许多标准的、开放的、数字的或组合的数字和模拟通信协议，例如Foundation^TM FIELDBUS(下文中称为“Fieldbus”)、

和CAN协议，其可以用于实现过程控制器和现场设备之间的通信。一般而言，过程控制器接收指示由一个或多个现场设备进行的测量的信号和/或与现场设备有关的其他信息，使用该信息来实现通常复杂的控制例程，并生成控制信号，该控制信号经由信号线或总线被发送到现场设备，从而控制过程工厂的操作。

某些类型的过程控制网络，例如那些在批次过程中使用的过程控制网络，通常包括多组重复设备，每组设备被设计成具有相同或相似的硬件，这些硬件在过程工厂内执行基本相同的基本功能。因此，例如，饼干制造厂可以具有多组混合设备、多组烘焙设备和多组包装设备，其中一些或所有的单独混合设备能够并行操作并且能够连接成与一些或所有的烘焙设备和包装设备串行操作。在这样的系统中，通常使用相同的通用控制算法或例程来控制任何特定的重复设备组的操作，以制造相同的产品(如由特定批次配方所定义的)。因此，由订单定义的、指定或标识正被制造的特定量的特定类型的产品的任何特定批次运行，可以在工厂中的各种不同的设备组的任何组合上实现。通常，每个这样的批次运行或订单包括特定的控制程序，其依序执行多个不同的步骤或阶段(stage)以实施配方，在开始第二阶段之前完成第一阶段，等等。因此，在上述饼干制造厂中，批次运行或订单可以实施批次控制程序以控制混合设备，然后可以实施程序以对由混合设备制造的产品运行烘焙设备，然后可以执行第三程序，该第三程序控制包装设备以包装由烘焙设备生产的产品，其每个步骤花费有限量的时间。在许多情况下，批次运行还实施作为每个订单的一部分的程序，以对工厂中的罐或其他容器或设备进行清洁、清空、填充等。当然，每个订单可以具有不同的规格集合，这可能需要不同的原材料集合、不同的配方、要对原材料实施的不同的流程或批次程序、以及甚至不同的质量标准。

国际测量和控制协会，一个涉及过程控制问题的国际组织，已经发布的一个批次控制标准，其名为批次控制部分1：模型和术语，并且通常被称为ISA S88.01-1995标准，或其更新之一(在本文称为“S88标准”)。S88标准定义了用于自动化批次过程的设备和程序(procedure)的模型，并且定义了用于引用那些模型及其元素的特定术语。例如，S88标准将“批次过程”定义为通过使用一个或多个设备在有限时间段内使一定量的输入材料经受处理活动的有序集合而导致有限量材料的生产的过程。作为另一个示例，“批次”由S88标准定义为正在生产的材料或已经由批次过程的单次执行生产的材料。

如上所述，在批次过程或批次运行期间，根据预定的程序操作批次处理设备(例如，诸如阀、加热器、混合器等的可控制元件)以进行批次过程。所有这样的批次处理设备在本文同义地称为设备、设备模块、处理设备和/或物理元件。操作这些物理元件的程序通常被S88标准称为“程序模型”。根据S88标准，程序模型被构造为程序的层级排序，其中最高级别包含每个较低级别，次最高级别包含其下的每个级别，等等。特别感兴趣的S88程序模型的级别包括，以降序排列的“程序”、“单元程序”、“操作”和“时期”。术语“程序元件”或批次子程序在本文被用来指S88程序模型的任何这些级别的任何实施例或实现，以及指批次程序集合的任何其他层级定义。

如上所述，感兴趣的最高级别S88程序元件被称为程序，其由一个或多个单元程序组成。每个单元程序进而由或可以由一个或多个操作组成，每个操作进而由一个或多个时期组成。此外，S88程序模型不排除在特定应用中定义和使用其他层级级别。相反，在本文提及的S88标准和程序元件旨在提供一个广泛的、标准化的模型，用于描述在自动化批次过程控制中遵循的程序，并且这些元件不限于由S88标准定义的四个程序元件。

批次的不同程序元件在实践中通常被实施为计算机程序，所述计算机程序由数据处理设备并在数据处理设备内执行，所述数据处理设备包括个人计算机、工作站和可编程控制器。典型的程序元件的执行导致来自数据处理设备的电或光输出，可以典型地通过将数据处理设备的输出直接或间接地通过局域网或广域网连接到物理元件，来将所述电或光输出用于控制物理元件。程序元件通过调用关于至少一个物理元件的“基本控制”来执行指定的或相关的任务。这种类型的控制通常专用于建立和维持物理元件的特定期望状态。基本控制包括例如启动或维持料仓元件中的材料流、加热聚氯乙烯反应器元件中的起始材料等。实际上，程序模型的较低级(即时期)执行与实际物理元件的实际通信，从而调用或执行基本控制。程序模型的较高级实质上是抽象，以便改进程序模型以及物理模型的组织和结构。

此外，许多批次系统使用批次执行器来根据所使用的程序模型控制工厂中一个或多个批次的操作。批次执行器可以是或使用状态机模型作为逻辑结构来描述批次过程或活动的状态。状态机模型描述或定义多个过程状态以及引起这些状态之间的转换的动作。由于较早地转换到特定状态，过程的状态机模型被称为处于该状态。当特定事件发生或感测到特定条件时，状态机模型进行到与特定事件或感测到的条件相对应的另一状态的转换。状态机模型是用于定义和实施批次过程的程序元件的操作的有用技术。具体地，被定义和实施为状态机的程序元件启动动作，例如，当其相关的状态机进行从旧状态到新状态的转换时。

当然，S88标准允许根据标准状态机模型来定义和实施程序元件。虽然S88标准没有要求这种方法，但是这种方法已经在过程控制工业中被广泛采用，以使得在不同厂商的产品之间能够有更高程度的互操作性。具有根据状态机模型所定义和实施的程序元件的S88标准的一个当前商业应用是来自Emerson Process Management的DeltaV^TM Batch产品。在DeltaV^TM Batch中，服务器程序或批次执行程序在执行各种程序元件的数据处理设备上运行。服务器或批次执行程序(称为“批次执行器”)根据一个或多个状态机模型来协调程序元件的执行，以便程序、相应的单元程序、相应的操作及相应的时期通过它们各自的步骤由服务器程序排序。在任何情况下，在与订单相关联的特定批次运行或特定批次过程的实施期间，例如当由服务器程序启动时期时，时期将启动请求传送到可编程控制器内的时期逻辑接口。可编程控制器然后执行该时期的实际状态逻辑或控制例程，并经由通信向过程设备提供所需的过程控制。

如根据关于过程的质量检查的先前讨论将理解的，期望收集表示批次过程的操作的数据，包括组成批次运行的处理的历史事件，以便能够确定用于根据适用的质量标准令人满意地操作或执行的订单的批次运行。这种历史数据不仅对于质量检查目的有用，而且对于确定质量控制的趋势或对于确定批次过程中使用的设备何时需要服务有用。许多类型的数据在检查批次过程的质量或进展中潜在地有用。一种这样的数据源是在处理批次期间由批次过程中的各个数据点生成的连续数据。数据点是反映批次过程的某些控制值或其他状态或测量的这种连续数据的单个源。例如，由传感器测量的材料流的特定液位或材料的温度可以是这样的数据点。控制阀的当前设置、取样时间等可以是其他数据点。每个这样的数据点可以具有由与其相关联的批次过程应用随着时间感测或控制的连续数据值流。在处理批次期间生成的所有这种连续数据的集合通常由批次处理系统记录，并作为批次日志文件的一部分存储在批次数据库中。这些批次日志记录通常包括时间戳和当前值，以及数据点的其他标识信息，例如标识数据源的标签。

在检查批次过程的质量或进展中有用的另一类数据是批次状态和事件信息，其涉及或包括根据程序模型的执行来描述批次过程的信息(例如批次过程的状态、批次模型的状态之间的转换等等)。例如，描述特定时期或特定操作的开始和结束时间的批次事件、程序模型的单元程序或程序构成事件信息。事件信息还包括过程事件，包括由批次过程的物理元件或由操作员生成的信息。特别地，过程的每个设备模块、单元(cell)等可以生成过程事件，该过程事件指示在特定时期的开始、停止或运行(即，执行特定的基本控制动作)中的一个或多个特定活动。由过程设备识别的警报和事件条件是过程事件的进一步示例。过程事件还可以包括关于操作员在批次过程的操作期间对批次过程进行的改变的信息。

更进一步地，许多批次过程系统利用操作员界面程序，操作员界面程序在专用操作员界面设备(诸如工作站)上运行，以使操作员能够查看批次运行的当前状态，在批次运行内采取手动步骤，诸如手动设置各种参数，选择过程设备以执行各种批次程序、操作、时期等等，在批次运行或订单期间，作有关意外活动或条件的注解等等。一种这样的操作员界面程序被称为工作流程序(例如由Emerson Automation Solutions提供的SyncadeWorkflow程序)，其从用于实施正在处理的每个订单的批次运行的批次执行器或过程设备(例如，过程控制器)截取或接收各种信息。工作流程序可以从批次执行器或过程控制系统订阅各种类型的数据，并且可以将该数据呈现给操作员，以使操作员能够查看批次运行的当前状态、查看批次模型中状态之间的转换、在批次运行中进行改变、手动停止和启动各种批次程序、操作、时期或设备、以及处理在批次运行中出现的问题或意外事件。例如，在许多情况下，在批次运行中可能发生意外的错误或问题，例如，批次设备或原材料意外地不可用，过程参数超出预期或期望的范围等。在这些情况下，工作流程序使操作员能够做出并实施关于如何进行的决定，例如跳过批次步骤或程序、指定要使用的其他设备或材料、改变过程工厂变量、设定点或参数以处理过程中的警报或事件等。一般而言，工作流程序还将指示操作员动作的数据存储在批次日志文件内，连同原始批次数据存储在批次日志文件内。在许多情况下，工作流程序还使操作员能够记录或存储在动作时在批次中发生了什么、操作员为何采取特定动作等的解释，并且这些注释也存储在批次日志文件中。

在任何情况下，在许多行业中，在已经发生批次运行并且已经完成产品或订单之后，质量工程师或其他质量人员(在本文中一般地被称为质量工程师)必须验证产品满足适当的质量标准。为了执行该检查，质量工程师访问并查看订单的批次运行的批次日志文件(通常以逐个订单为基础)，以确保根据预期参数、工作流及范围或在预期参数、工作流及范围内完成批次运行。通常，为了执行该检查，质量工程师必须滚动遍历批次数据文件中的原始数据，以寻找批次运行的预期操作的“异常”。术语“异常”在这本文通常用于指示与制造过程或工厂内的预期程序、过程、步骤、工作流、范围、值等的偏差。异常可以是，例如，一个或多个过程变量或参数超出预期或期望的范围，或者高于或低于预期或期望的阈值，批次程序、操作或时期被跳过或未按预期顺序执行，批次程序、操作或时期在非预期的时间停止或开始，或者花费时间比预期的操作时间更长或更短，在批次程序中使用不同的或非预期的材料，在批次运行期间由操作员实施附加步骤或动作，配方的改变，在批次运行期间由操作员生成的注释，在批次运行期间发生的警报和事件，等等。

在任何情况下，质量工程师必须基于存储在批次日志文件中的原始数据来识别异常，然后必须确定每个这样的异常的影响或严重性，以及如果采取任何程序来处理或“关闭”异常会怎么样。例如，在许多情况下，异常可能仅表示在预期的批次运行中的最小或不重要的偏差，其不会导致根据正在实施的质量标准的所生产的产品的任何或任何显著的质量降低。在其他情况下，可能需要对异常进行文档记录以供管理机构或客户稍后检查，但异常的影响可能不足以严重到导致产品质量的显著降低。在其他情况下，异常可能是显著的或重要的，足以使得产品需要经历一个或多个附加程序以确保期望的质量，或者需要对产品执行一个或多个测试以确保产品的质量。在其他情况下，质量工程师可以基于异常的细节确定产品需要被废弃，或者确定产品需要以较低质量或标签标准销售。

浏览批次日志文件查找异常的过程是非常冗长且充满问题的。特别地，批次日志文件内的大部分数据不指示异常，因此质量工程师花费大量(通常大部分)的检查时间来查看实际上不与任何异常相关联的数据。更进一步地，质量工程师必须记住导致异常的所有条件，包括例如重要过程变量的期望值或范围、预期的批次程序的顺序、预期的各种不同批次程序的停止和开始时间等。虽然存储在批次日志文件中的批次过程警报和警告或来自操作员的注释的存在可以指示异常的存在，但并不总是这种情况，当然，并非所发生的每个异常都可以与操作员注释一起记录，或可以上升到导致在控制系统中生成相关警报或警告的水平。如将理解的，所确定的实际异常因此取决于执行检查的特定质量工程师的技能和所满足的特定质量标准。

更进一步地，当质量工程师发现异常(例如，过程值超出范围等)时，工程师通常必须确定异常时批次过程的情境(context)，以便确定异常的严重性，以及如何最好地响应或处理异常。该过程可以包括获得关于异常时批次运行或批次程序的状态、异常时其他过程变量的值的附加数据，确定异常时警报或事件是否在相同或其他过程设备中生成等。然后，该过程通常要求质量工程师使用其他可用的数据访问系统来确定异常时的附加过程状态信息。这种数据采集活动可能是耗时的，并且需要批次质量工程师方面的额外的专门知识。

例如，为了从批次日志文件查看批次的操作，在特定时间获得批次过程的快照及向质量工程师显示数据不是简单的任务，因为批次过程具有各种不同的程序元件，程序元件可以在不同的时间、使用不同的设定点、设置等等在工厂内的不同设备上运行。相反，为了查看批次运行，质量工程师可能需要在与批次的程序事件(即与批次相关的子程序和子过程)有关的不同时间，检查和分析来自批次的数据，从而能够理解在异常时批次运行的操作。虽然在批次运行的操作期间，通常自动收集和存储各种批次数据，但是这些不同类型的数据通常由不同的子系统收集，并且实际上可以被存储在不同的数据库中。这一事实使得质量工程师难以全面地了解任何特定的批次过程。例如，从批次过程内的诸如传感器、阀等的实际现场设备获得的诸如警报数据和传感器测量数据的数据，通常作为时间打戳的数据存储在数据历史库中，并且通常基于收集数据的时间从数据历史库获得。然而，不同的数据库，例如与批次执行器例程相关的数据库，可以存储批次运行的开始和结束时间及批次运行中的各种不同的子程序或程序元件。这都使得质量工程师在批次过程的各种其他子系统中不进行大量数据查找的情况下更难以理解异常的情境。

发明内容

质量检查管理系统(也称为异常检查(RBE)系统)可以用于分析由各种其他过程工厂数据源收集的一个或多个制造过程的操作，所述过程工厂数据源诸如过程控制系统内的数据源、工作流应用、批次过程操作员应用、批次执行器应用等。质量检查管理系统自动检测那些过程中的异常，并以有组织的和易于检查的方式存储与检测到的异常有关的数据。质量检查管理系统还使得质量检查管理者或工程师能够以易于使用的接口来检查和处理(解决)与过程相关联的异常。

具体而言，质量检查管理系统包括配置系统，该配置系统使用户能够在规则数据库中创建和存储规则，这些规则可以用于自动标识诸如批次过程之类的过程内的一个或多个异常。规则可以标识必须满足的条件集合以便识别异常、所识别的异常的严重性、关于异常的信息、用于处理、解决或关闭异常的过程或程序、要作为异常记录的一部分存储以帮助质量检查工程师理解和解决异常的过程数据或其他数据等。质量检查管理系统还包括异常引擎，其使用规则数据库中的规则来处理数据消息内的数据，以确定数据消息内的数据是否包括由任何规则定义的异常，所述数据消息例如是由数据源周期性提供的数据消息，所述数据源例如是工厂或过程控制系统、批次执行器、操作员工作流应用等。异常引擎在识别出异常后，可以将关于异常的信息存储为异常记录，例如名称、类型、严重性、解决或处理异常所采取的程序或步骤、以及与在发生异常时发生异常的过程的操作有关的过程数据。异常引擎可将用于每个识别的异常的该数据和/或其他数据作为异常记录存储在用于每个订单的异常文件(例如，异常数据库)中。此外，异常引擎可以在实现订单的过程的操作期间实时操作，以创建针对订单的异常文件或数据库，并且可以向过程操作员提供异常已经发生或即将发生的实时反馈。

因此，在一个示例中，质量检查系统提供配置环境以使得用户能够创建可配置的异常规则以在异常引擎中执行来定义或检测异常。配置环境可以存储规则模板集合，其可以处理各种类型的输入数据以检测异常。在配置环境中，用户可以选择模板之一，可以定义输入/输出，并且可以定义要针对数据集合进行分析的可能表达式。当数据流经引擎时，会依据配置的规则分析数据；如果满足任何规则的准则，则创建异常。然后可以立即检查异常。异常产品的典型已知检查要求异常软件提供商将为系统定义的异常硬编码到产品中，并因此要求软件或系统更新以创建新的异常。这些更新花费用户的时间来获取和安装，并且不能使用户定制他们自己的系统。

质量检查管理系统还包括检查接口，其使得质量检查工程师或其他人员能够检查和处理由异常引擎识别的，以及作为异常记录存储在订单的异常数据库中的异常。特别地，检查接口可以访问用于特定订单的异常数据库，并且可以以有组织的且易于理解的方式向质量检查工程师呈现关于每个识别的异常的信息。检查接口可以向质量检查工程师提供针对每个异常记录存储的数据，例如每个异常记录的名称、类型和严重性标识。检查接口可以向检查者提供关于由异常记录识别的异常、异常类型等的存储信息，以及关于在异常发生时存在的各种过程或批次变量、状态、程序等的数据。该信息将使检查者能够容易地理解异常、异常发生时的过程的情境以及异常的严重性。此外，检查接口可以使检查者能够对每个异常采取各种动作。这种动作可以包括确认异常、签核(sign off)或关闭异常、用诸如为什么可以忽略或签核异常的另外信息来注释异常、将异常记录发送给另一个人员等。检查接口还可向检查者提供建议的动作，并且在某些情况下可强制执行关于解决或关闭异常要采取的特定动作。这种动作可包括例如要求由特定数量或类型的人员(例如，检查者独自的、检查者和管理者、两个检查者等)签核。其他动作可包括要求从检查者提供特定信息，例如注释、过程信息等，它们将与异常记录一起存储以便以后由客户、质量检查管理机构等使用。

检查接口可以将经处理的异常记录存储在数据库或文件中，并且可以使检查者能够滚动遍历异常数据库中的异常记录，以确定订单的所有异常记录是否以及何时已被处理或关闭、检查的状态(例如，在异常记录数据库中存在多少未处理的异常)、与异常记录有关的统计数据(例如，在文件中存在有多少每种类型或严重性的异常等)。检查接口还可以使检查者能够以各种方式，诸如通过类型、严重性、处理状态(例如，未检查、已检查但未关闭、关闭等)对异常记录进行分组。更进一步地，检查接口可以使检查者能够对整组异常记录采取一个或多个动作，诸如关闭组中的所有异常记录、注释组中的所有异常记录等。

以这种方式，可以在批次过程或其他过程的操作期间建立(配置)和执行质量检查管理系统，以便在异常在过程运行中发生时自动识别异常，可以通知过程操作员已经发生异常或过程操作员采取的动作将导致异常，并且可以将特定过程(例如，批次过程)的所有确定的异常存储在异常记录数据库中。质量检查管理系统还使质量检查工程师能够快速确定、查看和处理异常数据库内的异常，而不需要作为当前必需的来检查大量原始数据。同样，质量检查管理系统可以在异常处理或解决过程中实施各种规则，例如确保以特定方式处理或处置各种不同类型或严重性的异常，从而提供质量检查过程中的一致性。

更进一步地，质量检查管理系统可以在插件(plug-in)环境中实现，以使系统能够与第三方系统或应用对接并用于分析第三方系统或应用的异常。在一种情况下，插件可被创建或配置为从第三方应用或数据源获得某些数据，然后可将该数据传递到异常引擎以供一个或多个异常规则处理。作为一个示例，质量检查管理系统可以用于与事件监视系统对接，例如使用OPC接口的那些事件监视系统，以获得和分析来自第三方过程控制系统或工厂的数据。

在一个示例中，创建插件模块以将RBE异常引擎与外部或第三方系统(例如，控制系统、OPC接口、维护系统等)对接，从而使得能够完全或部分地基于来自第三方或外部软件系统的数据来生成异常。可以创建插件以访问第三方或外部系统内或来自第三方或外部系统的特定数据，并将该数据传递到RBE引擎以分析是否应该创建异常。插件可以在第三方服务器、RBE服务器或另一服务器中运行，并且可以执行或不执行异常检测。因此，插件可以是简单的第三方系统数据收集器，或者可以收集数据并且另外执行一些异常处理，向RBE引擎提供异常或预处理的异常数据。

已知的检查系统目前不能基于直接从外部软件程序(如控制系统、安全系统、维护系统等)提供的数据来与异常对接或创建异常。插件使得RBE系统在具有在运行时期间操作的多个不同软件系统的复杂过程环境中更加鲁棒。

更进一步地，在一个示例中，RBE系统可以包括在收集RBE输入数据(即，用于定义或生成异常的过程数据)时收集元数据集合(其可以在例如创建插件时被预定义)的实时查看部件。元数据可以是任何其他过程或环境数据，并且与异常输入数据同时被收集。该元数据被存储为与所访问的异常数据相关联的进程快照。当RBE系统基于收集的异常数据检测到异常时，RBE系统还存储元数据作为异常的一部分。RBE系统在报告所生成的异常时额外显示一些或全部元数据，从而在异常在过程中出现时向用户或检查者提供进入该过程的实时视图。该系统向用户提供异常时各种过程状态/值等的快速视图，这使得用户能够更快地理解异常发生的原因和异常的严重性，从而使得用户能够更快地处理异常。

虽然已知的过程检查产品向用户或检查者提供所生成的异常的列表，但是检查者仍然必须分析每个异常，以确定是可以消除异常还是必须以某种其他方式处理异常。然而，一般而言，检查者必须回到收集导致异常的数据的过程系统，以理解关于异常时过程的其他事情(例如，过程在线或离线、异常时批次的状态等)。利用实时查看特征，可以自动地向用户提供过程快照，该过程快照通常将包括在执行异常检查时对检查者最有用的过程数据，这意味着检查者不需要回到其他数据收集系统来获得用户执行异常检查所需的信息。这个特征还意味着，由于检查者将不需要使用其他过程系统来访问检查者需要的过程数据，所以检查者通常不需要熟悉从其收集数据的其他过程系统。

在另一个示例中，RBE或质量检查系统包括事件监视器，该事件监视器可以绑定到第三方或外部系统并且生成消息并将消息发送到RBE系统，RBE系统然后可以使用这些消息来执行异常处理或异常创建。在一种情况下，事件监视器可以被绑定或耦合到OPC警告和警报监视接口，并且可以识别何时将一个或多个警告或警报传递到OPC接口。此时，事件监视器创建消息并将消息投放到RBE系统，该消息具有警告或警报信息以及潜在地任何其他期望的OPC收集的数据。RBE系统然后可以基于警报和警告来分析消息以生成异常。典型的检查系统不分析来自第三方系统的数据，并且它们都不连接到存在的OPC警告和警报接口。因此，这些系统不能基于例如过程警报和警告生成异常。

同样，当通过电子显示器或用户界面向检查者呈现异常记录列表时，质量检查管理系统可以使用新的分页算法。这种分页算法以减少或消除检查过程中遗漏记录或重复记录的呈现的方式操作，存储一个或多个锚以跟踪在界面显示中提供的记录的当前显示页面中的实际记录。然后，系统使用当前正在显示的页面的锚来确定要显示为下一页面的一部分的下一组或多个记录的起始位置，这使得分页系统能够适当地操作，即使在检查过程期间要显示的记录列表中添加或移除了记录。

在一个示例中，当向检查者呈现所生成的异常列表时，检查系统实施新的分页算法。通常，RBE系统创建/检测异常并将这些异常作为记录存储在诸如SQL数据库的结构化数据库中。然后，当在显示屏上向检查者呈现异常列表时(并且可能存在大量异常或记录)，RBE系统搜索数据库以查找所有相关异常记录，下载到这些记录的链接的页面，然后当用户滚动遍历异常记录的各个页面时，按照从数据库下载的顺序在检索的页面的部分内呈现记录。然而，当检查者处理异常并向下滚动在用户界面上显示的异常列表时，数据库中的记录可能改变，因此页面数据可能变得过时。特别地，可以在数据库中添加或从数据库中删除记录。在这种情况下，当系统试图在显示屏上呈现记录时，在页面中引用的各种记录可能丢失，从而导致视觉数据丢失或重复。在一些情况下，用户可能由于删除特定恢复页上的记录而遗漏从一页到下一页的记录。在其他情况下，系统可能对于基于曾在下载的页面中的缺失记录而在哪里开始新的显示页面而变得困惑。新系统操作的不同之处在于，它从屏幕上显示的最后记录开始下载呈现在显示屏上的记录。即，代替呈现与恢复的记录的原始页面相关联的新显示页面，系统访问数据库以查找当前紧接在所显示的页面上的最后一个记录之后存在的记录集合，从而确保每次在屏幕上显示新的记录集合时，所显示的第一个新记录是紧接在滚动时间之前正被显示的最后一个记录之后的记录。

该显示系统更准确，因为它确保记录不会在检查过程中被无序显示或遗漏，在检查过程中用户在长时间段内向下滚动各页记录。此外，RBE系统更高效，因为其仅需要访问数据库以获得当用户滚动遍历记录时将适合新显示页面的数量的新记录，同时仍然确保当用户执行滚动过程时访问所有相关记录。

附图说明

图1是典型过程或制造工厂的框图，包括过程控制网络、批次执行器和工作流应用，其使得操作员能够管理批次过程并存储批次日志文件以供质量检查。

图2是类似于图1的工厂环境的框图，但是包括质量检查管理系统，该质量检查管理系统具有配置应用、异常引擎和质量检查接口应用，以用于在工厂环境中执行基于异常的检测和质量检查。

图3是由图2的质量检查管理系统的配置应用创建的示例屏幕显示，使用户能够创建一个或多个异常规则，以供异常引擎使用。

图4是示出当分析来自多个数据源的数据以进行异常处理时图2的质量检查管理系统的异常引擎的操作的流程图。

图5是示出从质量检查管理系统向批次过程的操作员实时反馈的示例屏幕显示，该实时反馈实时地向操作员通知在过程内检测到实际或潜在异常。

图6是示出在插件环境中实现的质量检查管理系统的操作的图。

图7示出了在连续过程环境中使用质量检查管理系统来执行对第三方应用和系统的监视的示例事件监视系统。

图8A-8G示出了由图2的质量检查管理系统的检查接口应用或配置应用创建的示例屏幕显示，以使质量检查者能够执行与异常规则配置及异常记录查看和处理相关的各种活动。

图9A和9B是示出用于例如在web环境中向用户提供记录列表的典型分页技术的操作的图。

图10A和10B是示出新分页技术的操作的图，该新分页技术可以由图2的质量检查接口应用实现，以在对记录集合执行分页时减少或消除重复或丢失的记录。

具体实施方式

作为背景，图1示出了典型的工厂或过程控制环境10，其中实现了典型的或现有的质量检查管理动作。工厂环境10包括过程控制网络20，其可以包括各种过程控制设备，例如控制器、现场设备(例如，阀、传感器、变送器、罐、混合器等)、I/O设备等，它们通信地连接在一起，并且全部被编程以操作或实现某种性质的制造过程，例如批次过程或连续过程。更进一步地，工厂环境10可以包括批次执行器22(在计算设备的处理器上实现，例如工作站或服务器)，其可以与过程控制网络20对接，以使过程控制网络20或过程控制网络20内的设备采取与制造过程相关的各种动作，例如实现各种订单(order)或批次运行，包括实现各种批次的不同阶段，例如与每个订单相关的批次过程的单元程序、程序、操作、时期(phase)、步骤等。更进一步地，过程控制网络20和批次执行器22都可以耦合到另外的网络24，该网络可以位于例如远离工厂场所或制造空间的商业环境中。网络24可以包括通信干线25，其通信地连接各种设备，诸如计算机显示设备或工作站26和28、各种数据库30、31和32以及其他计算机设备，如果需要的话，诸如到互联网或其他通信网络的网关、服务器、无线或手持设备等(图1中未示出)。设备26、28、30、31和32可以经由任何期望的物理通信网络或干线25，诸如以太网、互联网或其他局域网(LAN)或广域网(WAN)等，通信地连接。同样，过程控制系统20和批次执行器22可以经由网络干线25直接或经由其他中间网络(如果需要的话)连接到各种设备和数据库26、28、30、31和32。

在该现有技术系统中，工作流(Workflow，WF)应用40可以存储在操作员接口设备(例如工作站26)中，并且工作流应用40可以由工作站26的处理器执行，以在批次执行器22控制过程控制网络20来实现各种订单或批次运行时与批次执行器22对接。工作流应用40可以是例如由Emerson Process Management销售的Syncade Workflow应用，它可以操作以从批次执行器22获得并显示数据。该数据可以包括正在进行的批次状态数据、参数数据、测量数据、进展数据、批次程序模型状态数据等等，如由批次执行器22所获取的。该信息或数据可以包括对正在实施的订单、与该订单相关联的材料和过程(例如，要实施的配方和批次程序模型)、来自批次执行器22和/或过程控制网络20的警报和警告数据等的指示。该数据中的任何或全部也可以作为批次日志文件34存储在批次日志文件数据库432中，如批次执行器例程通常进行的。

如通常所知的，工作流应用40可以跟踪批次执行器22关于由批次执行器22实施的每个订单的操作，并且可以允许批次操作员在批次执行器22或过程控制网络20内或关于其执行各种操作或动作。例如，工作流应用40可从批次执行器22订阅某些类型的数据，例如参数数据、批次状态数据、批次状态改变数据、批次警报和/或警告等，并可基于该数据向操作员通知工厂10中的各种状况。工作流应用40可以例如向操作员通知各种不同的批次程序的开始和停止或批次程序模型状态的改变，可以向操作员通知批次执行引擎22的各种中断或其他操作条件(其可能由诸如丢失设备、丢失原材料之类的无法预料的问题引起)，可以向操作员通知时间段不合适、批次参数可能超出基于批次执行器22所期望的范围等等。如所知的，工作流应用40可以允许操作员采取各种动作来重新启动批次运行、选择不同的设备进行批次运行、对不同的原材料进行操作、指示批次执行器启动、关闭或跳过程序、或执行批次程序模型中的其他程序。作为一个示例，批次执行器22可能试图经历清洁程序，其中要进行清洁的设备是离线的，因此不能被清洁。在这种情况下，操作员可以跳过清洁程序，这可能不是严格符合正在实施的质量标准，而可能是以及时的方式或在分配的时间帧内完成该批次所必须的。在任何情况下，工作流应用40可以使操作员能够注释操作员采取的各种动作。此外，工作流应用40可以存储由操作员经由工作流应用40提供的注释或注解(例如，由操作员提供的注解或注释，以解释发生了什么以及操作员为什么采取了批次过程的预期工作流之外的某些动作)，并且可以将指示操作员经由工作流应用40采取的各种动作的数据存储在批次日志文件数据库30中，作为被监视或控制的订单的批次日志文件34的一部分。每个批次日志文件34通常列出从批次执行器22获得的各种数据，以及操作员响应于该数据而采取的动作、操作员放入日志文件的注解等。此外，此外，在批次执行器22的操作期间，批次执行器22将数据分组与关于批次运行或订单的当前数据一起发送到工作流应用40。工作流应用40可以从批次执行器22(或过程控制网络20)订阅各种数据，并且当数据中发生变化时可以周期性地接收该数据，等等。此外，每个数据集合可以具有唯一的分组标识符，其标识关于与数据相关联的批次运行或顺序的各种信息。以这种方式，工作流应用40可以处理数据分组以确定顺序，并因此确定向其提供数据的适当操作员。

如所知的，在批次运行期间生成批次运行的批次日志文件或批次报告34，且在批次运行或订单完成之后，批次日志文件34完成。此时，质量检查工程师或其他人员可以经由在计算机或工作站28上执行的某个查看应用访问批次日志文件34，例如，以分析批次报告并逐行查看批次过程报告内的数据及其他信息。质量工程师可以查看在批次过程的操作期间存储的该数据，以便确定在批次运行中是否发生任何异常、是否需要解决这些异常、以及基于这些异常的存在，如果需要采取任何动作会怎么样。如上所述，这种检查往往花费大量时间，是人工密集的，并且需要质量工程师方的大量知识。更进一步地，质量工程师花费的大部分时间只是查看来自批次报告的数据或信息，所述数据或信息与批次运行内的任何特定异常或与预期动作的偏差无关，因此，这种检查是时间密集型的。更进一步地，如上所述，当质量工程师基于批次日志文件34中的数据识别出异常时，质量工程师可能需要获得关于所述批次过程的其他信息(例如过程变量值、批次程序模型状态、配方信息等等)，所述其他信息存储在其他数据库之一中，例如存储在批次历史库30、过程控制历史库31等等中。这种活动可能要求质量工程师使用其他数据访问应用来访问该数据，并因此要求工程师具有使用这些其他数据访问应用来高效且正确地访问和查看该数据的技术诀窍。

图2示出了与图1的工厂环境10相似的工厂环境110，其中相似的结构、应用和数据具有共同的附图标记。然而，图2的工厂环境110包括质量检查管理系统112，其执行以帮助质量工程师(或其他人员)识别和检查与订单或批次运行(或与多个不同的订单或批次运行)相关联的异常，并且在一些情况下，其帮助操作员以减少在订单期间生成的异常或异常记录的数量的方式在批次运行内执行工作流操作。

特别地，图2的工厂环境110包括过程控制网络20和批次执行引擎或批次执行器22，它们以类似于以上关于图1所描述的方式操作。因此，来自批次执行引擎22和/或过程控制网络20的数据经由通信网络干线25提供给各种设备，各种过程控制和各种不同的质量检查管理系统112的计算机或设备连接到该通信网络干线。在这个示例中，将批次过程或其他过程数据提供给工作流操作员接口26，其执行工作流应用40并将数据提供给存储批次日志文件34的批次日志文件数据库32。然而，图2的工厂环境110内的质量检查管理系统112包括位于、存储在工厂环境110内的计算机或处理器设备中并在其上执行的各种应用和数据库。特别地，如图2所示，质量检查管理系统112包括存储在处理设备121的存储器中并在其处理器上执行的配置应用120、存储在服务器123的存储器中并在其处理器上执行的异常引擎122、及存储在如工作站129之类的处理设备的存储器中并在其上执行的规则数据库124、异常记录数据库126、质量检查接口应用128。虽然将组件120、122、124、126和128示为存储在与图2的计算设备26、28、30、31和32不同的单独计算设备中并在其中执行，但是组件120、122、124、126和128的任何子集或全部可以存储在相同的处理设备中并在其中执行，所述处理设备可以是存储和执行其他过程控制应用和数据库的相同处理设备，诸如设备26、28、30、31和32。

一般而言，可以操作或执行配置应用120，以使诸如配置工程师、质量管理工程师等的用户能够创建和存储规则(在本文通常称为异常规则)集合，异常引擎122可以使用该规则集合来检测过程运行中的异常，例如在与特定订单相关联的批次过程的批次运行中的异常。配置应用120实质上提供了配置环境，该配置环境使用户能够创建可配置的异常规则以在异常引擎122中执行，从而定义或检测异常。配置应用120可以存储规则模板集合，其可以处理各种类型的输入数据以使用任何期望类型的逻辑或逻辑表达式(例如布尔逻辑)来检测异常。在配置环境中，用户可以选择规则模板之一，可以定义规则的数据输入/输出，并且可以定义要针对数据集合进行分析的可能表达式。当数据流经异常引擎122时，异常引擎对照经配置规则分析数据以确定是否存在异常。在检测到异常时，则异常引擎122将异常记录存储在数据库126中。

作为示例，图3示出了配置应用120可以创建并经由图2的工作站28提供给用户(例如配置工程师、质量检查工程师等)的屏幕显示150，例如，以便使用户能够创建一个或多个异常规则152并把异常规则152存储在异常规则数据库124中。特别地，配置应用120可以使用户能够创建要应用于来自不同数据源的数据的不同规则集合。如图2所示，异常规则152可以包括用于多个不同数据源中的每一个的不同异常规则152A、152B、152C、152D等的集合。例如，可以创建规则152A以用于分析来自工作流应用40的数据并与之相关联，可以创建规则152B以用于分析来自事件监视应用的数据并与之相关联，可以创建规则152C以用于分析来自在工厂环境110中执行其他服务的第三方应用的数据并与之相关联，等等。当然，可以为每个数据源创建和存储任何数量的异常规则152，并且可以以任何数量的不同方式配置这些规则以分析来自那些数据源的数据。例如，可以从单个数据源为不同类型的运行(例如，产生不同产品的批次)创建不同的异常规则集合，并且可以为不同的质量标准创建不同的异常规则集合。同样地，可以将与特定数据源相关联的异常规则排序以指定应该第一、第二、第三等执行或分析异常规则集合中的哪个规则。

再次参考图3，配置应用120可以创建包括多个不同部分的屏幕，所述多个不同部分包括规则模板区156、数据源区158、规则列表区160和规则配置区162。规则模板区156可以包括指示作为模板存储的异常规则模板或先前配置的异常规则的图标集，用户可以使用该图标集作为创建新规则的起点。这些模板可以存储在规则数据库124中，或者存储在与配置应用120相同的设备中，或者存储在任何其他数据库或计算机存储器中。数据源区158可以包括指示用户可以为其创建异常规则的各种不同数据源的图标。图标158A可以是可访问的，以查看关于数据源的细节，诸如可从数据源获得的数据、由数据源用来传送数据的数据或通信格式、关于数据源的信息(例如，制造商、版本等)和/或任何其他信息。规则列表区160可以存储用于特定的所选数据源的规则列表，并且在分析来自数据源的数据时指定规则的执行顺序。

在操作期间，用户可从数据源区158选择数据源158A以指定要为其创建规则的数据源。应用120可以访问规则数据库124，并且找到针对该数据源的先前存储的规则(如果有的话)，并且例如以执行顺序在规则列表区160中列出这些规则。接下来，用户可以通过从模板部分156选择模板数据源图标156A并将该模板图标156A拖放到规则配置区162上来为数据源创建新规则，这将使得应用120将用于所选模板规则的配置数据加载到配置区162的各个部分或字段中。如果需要，规则配置区162可以使其字段为空，以使用户能够在不使用模板的情况下创建新规则。更进一步地，用户可以选择规则列表区160中的规则之一来编辑先前创建的规则。当然，应用120可以使用选择或建立要创建的规则的其他方式(例如，使用下拉菜单、弹出屏幕等)

然后，配置应用120使诸如配置工程师之类的用户能够通过在规则配置区162的各个字段中提供或编辑各种规则配置信息来指定、设置或创建规则的细节。基本上，应用120使得用户能够指定为了检测和处理由数据源监视的过程的操作内的异常而处理来自数据源的数据所需的任何规则配置信息。通常，每个规则存储逻辑，例如布尔逻辑，以用于分析来自数据源的数据以检测异常，关于如何存储异常记录的信息，以及如果需要，关于如何使质量工程师能够处理或解决(例如关闭)由规则的应用所创建的异常记录的信息。这种异常规则可以包括例如检测来自数据源(例如，工作流应用40、批次执行器22、过程控制系统20等)的一个或多个参数是否超出范围或者高于或低于某些预先建立的阈值；是否已由操作员(例如，经由工作流应用40)输入注释；是否在订单的批次运行中使用不同的材料；是否不同设备正被用于订单的一个或多个批次程序；一个或多个批次程序的处理时间是否比预期的要长或要短；在订单的批次运行中跳过或添加某些步骤或程序，例如清洁程序或冲洗程序；过程系统的操作者或其他用户是否在过程中采取了意外的动作或在数据源应用中输入了注释等。当然，异常规则可以指定和期望要应用于来自数据源的特定数据的逻辑，以确定是否存在异常。

因此，如图3的示例屏幕150所示，规则配置区162包括名称字段162A，其可以用于指定异常规则的名称，严重性字段162B，其可以用于指定规则检测到的异常的严重性或重要性的级别，以及逻辑字段162C，其可以被填充或用于指定要由异常引擎122(图2)应用的逻辑，以检测是否存在异常。当然，逻辑字段162C可以接受或使得用户能够以任何期望的方式输入或指定逻辑，诸如一组布尔逻辑参数或字符串、以特定语言(C+、HTML等)编码、任何期望的自定义表达式语法等，其应用某些逻辑、If-Then逻辑语句等。更进一步地，源参数字段可用于指定来自数据源的、针对应用字段162C中提供的逻辑规则或逻辑所需的任何和所有数据。该数据源数据在本文被称为数据源元数据或就被称为元数据，它指定了与要针对规则从数据源接收的数据的信息、格式和通信参数相关联的所有数据。配置应用120可以使用户能够选择图标158A之一，以获得特定数据源的配置信息，其中为该特定数据源创建规则以确定什么数据源元数据(信息和/或变量)可从数据源获得、这些变量的名称、这些变量的数据格式(例如，32位、64位、诸如整数或布尔的变量类型、或字符串变量)等。更进一步地，字段162D可以使用户能够在来自数据源的输入数据被用于字段162C中指定的逻辑之前指定要对来自数据源的元数据执行的转换。这样的转换可以是数学运算符(从摄氏改变到华氏、缩放、限制等)，转换可以是变量名改变(以将逻辑中使用的各种变量名与数据源变量名匹配)，或者这些转换可以是任何其他类型的转换。此外，来自数据源的元数据可以包括任何期望的信息，例如过程参数值、订单名称、订单材料、订单过程流程、订单中使用的过程设备、应用于订单的工作流、订单中使用的批次程序模型等。

更进一步地，配置工程师可以使用配置应用120来指定特定规则集的每个规则应该被应用于来自数据源的任何特定数据集合的顺序或次序。特别地，异常引擎122可将多个规则应用于来自数据源的每个数据集合，并可被设置成以特定或预定顺序应用多个规则中的每一个，以便在其他类型的异常(例如，不太严重的异常)之前检测到某些类型的异常(通常更重要或严重的异常)。例如，在许多情况下，对来自数据源的特定数据集合应用不同的异常规则可能导致检测到多个不同的异常。然而，可能重要或期望的是，仅确定对于来自数据源的任何特定数据集合最重要的异常，以防止在批次运行或订单中创建与相同事件或时间相关联的多个异常记录。规则的顺序(即，异常引擎122将异常规则应用于特定数据集合的顺序)因此用于指定首先检测哪些异常，使得在操作期间，异常引擎122通过以特定顺序运行规则，然后仅为首先检测到的异常保存或创建异常记录，来基于各种规则确定异常。如上所述，规则区160可以按照将执行这些规则的顺序存储用于源的规则列表。每个规则可以存储或包括指示该执行顺序的序号或顺序号作为其参数。在任何情况下，用户都可以通过例如在区域160中的规则列表中重新排列规则的顺序来改变数据源的规则的顺序。用户可以例如选择规则列表160中的规则，在列表160中向上或向下拖动该规则，并将该规则放置在列表160中的新位置，以改变规则的执行顺序。当然，应用120可以使用户能够以其他方式改变规则的顺序，例如改变屏幕区162中的顺序字段162E。

此外，如果需要，屏幕区162可以包括解决字段162F，其可以使配置工程师能够指定一个或可能多个处理或解决程序，这些处理或解决程序应该或必须被应用以关闭由规则创建的异常记录。通常，每种类型的异常可以支持单个解决程序。然而，在一些情况下，异常可支持或包括多个解决程序。这样的解决程序可以包括签核异常、用各种信息注释异常记录、将异常记录发送给其他人员以检查和/或签核等。在一些情况下，每个解决方案可以仅仅是关闭异常所需的签名集合的定义，或者解决方案可以仅仅强制实施关闭异常所需的一个或多个签名。在这些情况下，解决方案可以包括指示在签名之前要完成的其他活动(程序)的描述或指令集，但是在这些情况下，解决方案可以不监视或强制实施其他活动。规则中指定的处理程序可以被预设，或者可以基于例如字段162B中指定的异常的严重性而被设置为默认设置。

此外，屏幕区162可以包括信息字段162G，其接受和存储要连同通过应用规则创建的异常记录一起或作为其一部分提供给质量检查工程师的信息。该信息可以是关于这种类型的异常、正常处理程序、关于要采取或考虑的其他动作的指导或建议的一般信息，或者是当查看或处理由应用规则创建的异常记录时对质量检查工程师有用的任何其他信息。在许多情况下，字段162G也可以用于指定要作为异常记录的一部分存储的数据源元数据，以及显示该元数据的格式。通常，当处理异常记录时，质量检查工程师知道异常时过程的情境是有帮助的，并且可以作为信息提供数据源元数据以帮助质量检查工程师理解该情境。这样，配置字段162G可以指示什么数据源元数据将作为异常记录的一部分被提供给质量检查工程师。

当然，配置应用120可以以任何期望的方式将任何或全部规则配置信息作为异常规则的一部分存储在规则数据库124中。如将理解的，该配置信息可以包括从数据源需要的数据的标识，并且如稍后将描述的，该数据可以用于在数据源的操作期间从数据源获得正确的数据或信息。

当然，配置应用120可以用于创建任意数量的异常规则，并且可以通过数据源方式将异常规则存储在数据源上的规则数据库124中，从而可以针对不同的数据源(或者针对与单个数据源相关联的不同订单)制定和存储不同的规则或规则集合。在任何情况下，配置应用120可用于创建规则，并且可通过使用户能够创建新规则(例如，从模板规则)来这样做，可使用户能够指定规则要检测的规则或异常的名称、要应用于来自要实施的特定数据源的数据以基于数据来检测异常的存在或与规范的偏差的逻辑、规则或规则检测的异常的类型的标识、在规则检测到异常时要提供给检查者或其他用户的信息集合(例如，异常的解释、对异常分析或签核有用的数据或指令)、规则检测的异常的严重性(例如，重要性)的标识、与应作为异常记录的一部分存储的异常时过程(例如，批次运行)的状态有关的元数据(例如，来自数据源的数据)、可以用于或必须用于处理或解决异常的过程或程序(例如，签核程序)、以及要作为异常记录的一部分存储的或要用于处理异常记录的其他数据或信息。

重要的是，该配置系统或配置应用120提供了优于已知产品的显著优点，已知产品要求异常软件提供商将为系统定义的异常硬编码到产品中，并因此要求软件或系统更新以创建新的异常。这些更新花费用户的时间来获取和安装，并且不能使用户定制他们自己的系统。

在为一个或多个数据源创建异常规则集合并且将这些规则存储在规则数据库124中之后，例如，质量检查管理系统112可以此后在数据源的操作期间实时地实施异常引擎122，以检测可能由于数据源应用监视、控制或影响的底层过程的操作而发生的异常。当被设置为对来自特定数据源的数据运行或执行时，异常引擎122周期性地或间歇地从数据源接收数据集合(例如，元数据)，该数据集合指示过程和/或对过程进行监视或控制的应用的各种操作参数。对于每个数据集合，异常引擎122获得并应用为数据源创建的异常规则的逻辑，从而检测由数据源实施、管理或监视的过程中的异常。当与数据源连接或通信时，异常引擎122可以周期性地、当某一特定动作或多个特定动作在过程或数据源中发生时和/或在其他经配置的时间从数据源接收数据集合。异常引擎122可以基于用于数据源的每个异常规则内的数据源配置数据来订阅这样的数据，可以在不同的时间轮询数据源以获得这样的数据，或者可以实施这些通信技术的组合。以这种方式，当诸如工作流应用40的数据源操作以接收新数据并与操作员对接(例如，以帮助操作员分析来自批次执行器22的批次过程数据)时，工作流应用40还将数据(周期性地或以其他方式)发送到异常引擎122，异常引擎122然后使用用于工作流数据源应用40的异常规则来分析数据，以确定在底层过程中是否已经发生一个或多个异常。

在该过程期间，作为逻辑引擎的异常引擎122解析从数据源发送的数据，并应用适当的规则集合内的逻辑，诸如数据库124中的规则156A，从而根据规则分析数据以检测一个或多个异常。异常引擎122可以按照规则数据库124中存储的规则集合中指定的顺序将规则逐个应用于数据，并且可以检测由规则确定的任何异常，或者可以当任何规则在特定数据集合上检测到异常时停止处理数据。在检测到异常后，异常引擎122为数据集合创建异常记录，并将异常记录存储在数据库126内的异常记录文件170(图2)中。当然，当工作流应用40(或其他数据源)向异常引擎122提供每个新数据集合时，异常引擎122处理该异常数据并确定是否存在任何异常，然后在适当时创建异常记录并将其存储在异常记录文件170中。异常引擎122可以存储与异常记录相关联的各种不同类型的数据，包括例如所识别或检测到的异常的名称、异常的严重性、要应用的检查或解决程序、由操作员作为从数据源发送的数据的一部分而输入的注释、关于异常的一般信息等。更进一步地，异常引擎122可以提供元数据作为异常记录的一部分，该元数据以某种方式定义或涉及在异常时批次或其他过程设备的操作。该元数据可以作为来自数据源的数据的一部分被提供给异常引擎122，或者可以由异常引擎122从数据源(例如，工作流应用40)获得，或者从数据库或与数据源分离的该数据的其他源获得。存储在异常记录中的元数据可以是定义与在检测到异常时正在实现的过程相关联的一些操作参数、值、状态或其他信息的任何数据。该元数据可以是例如批次状态信息、从过程测量或确定的过程参数值、过程设备信息、来自过程设备的警报或警告信息、或任何其他信息。此外，该元数据可以从其他源获得，例如批次日志文件34、过程控制数据库或历史库31、过程设备、批次历史库30等，或者可以直接从数据源本身提供，作为由异常引擎122处理的初始数据的一部分，或者响应于由异常引擎122进行的查询。一般而言，所存储的元数据提供在检测到异常时过程的快照(例如，过程状态信息、过程设备信息、过程变量值、批次程序模型状态等)。可以作为异常记录的一部分被显示该元数据，以使质量工程师能够理解异常的情境(例如，在异常时在过程中发生了什么)，从而更好地理解异常和异常的重要性。

如将理解的，异常引擎122实时操作，即，以与数据源串联的进行中的方式操作，以分析来自数据源的数据的异常，并将检测到的异常的异常记录存储在异常数据库170中。异常引擎122可以操作以在任何时间段内从数据源(例如工作流引擎40)接收新的数据分组集合。例如，异常引擎122可以在运行特定批次过程时分析来自工作流应用40的数据，并且可以在完成批次过程或订单时停止。当然，异常引擎122可以运行以同时分析和检测例如来自相同数据源(例如，工作流应用40)的多个不同批次运行的异常，和/或可以同时分析来自不同数据源的数据。在所有这些情况下，异常引擎122可以同时为单个数据源的每个不同的批次运行和/或为每个不同的数据源创建并存储异常记录。因此，异常引擎122可以理解，不同的批次运行同时发生，或来自不同源的数据在相同的时间段上被处理，并且可以分别跟踪这些运行和处理，以便为每个批次运行、订单和/或数据源创建不同的异常数据库170。

图4示出了异常引擎122对多个不同数据源(Data source，DS)180、182、184和186的操作。数据源180-186可以是相同类型的数据源(例如，运行不同批次或制造不同产品的工作流应用40的不同实例)，和/或可以是不同类型的数据源，例如事件监视应用或系统、第三方专有系统或应用等。在该情况下，异常引擎122和/或数据源180-186被配置为周期性地接收具有数据源元数据的数据分组188并将其发送到异常引擎122。这些数据分组188可以被格式化为包括来自数据源的数据，如用于数据源的规则内的元数据配置信息所指定的，并且这些数据分组188可以包括数据源的标识符、由数据源实施的订单、数据源元数据等。

异常引擎122接收来自不同数据源180、182、184和186的每个数据分组188并按照接收到这些数据分组的顺序处理数据分组。对于每个分组188，异常引擎122可以确定数据源的标识(identity)和顺序(如数据分组188内的数据所指定的)，可以从规则数据库124获得用于该数据源的适当的规则集，并且可以以预定顺序将所获得的规则应用于数据分组188内的数据，以确定是否存在异常。如果异常引擎122处理了数据源的所有规则而没有检测到异常，则异常引擎122等待或开始处理下一个数据分组188(来自相同或不同的数据源)。另一方面，如果异常引擎122基于规则逻辑对数据源元数据的应用而检测到异常，则异常引擎122为订单创建异常记录180，并将该异常记录存储在异常记录数据库126中作为订单的异常记录文件或数据库170。即，特定订单的所有异常记录可存储为该订单的异常记录集合。在任何情况下，如图4的图所示，异常引擎122可以同时对来自各种不同数据源和/或针对各种不同订单(来自相同或不同数据源)的数据进行操作，以便为每个订单产生异常数据库。

异常引擎122的一个额外益处是其实时操作，即，在底层过程的操作期间操作，且因此可实时检测异常的发生，例如，在异常发生时。结果，异常引擎122的一个特征是，在检测到异常发生时，异常引擎122可以立即或实时地向数据源处或与数据源相关联的操作员或某些其他人员通知存在异常，这可以使操作员或其他人员能够在过程内采取动作以减轻或避免异常。在一些情况下，异常规则可以被配置为基于当前过程的动作或状态来检测未来异常的可能发生。在这种情况下，异常引擎122可以检测异常可能或很可能发生，并且可以实时地向操作员或其他用户通知异常很可能发生。该通知向操作员或其他用户提供了在异常发生之前逆转某个动作或改变作为未来异常的根本原因的某个参数的能力。因此，通过使操作员或其他过程监视或控制人员能够采取动作以避免或逆转导致异常的情况，这种实时反馈可用于避免或立即减轻异常。

图5示出了可以由例如图2的工作流应用40提供给操作员作为工作流应用40的正常操作的一部分的屏幕显示200。在这种情况下，显示200可以以过程或工作流图202的形式向操作员提供过程信息，并且可以使操作员能够经由输入字段204在过程中采取某个或某些动作。在这种情况下，操作员可以使用屏幕200中的输入字段204来改变特定过程参数的设定点。然而，当操作员输入新的设定点时，或者紧接在输入新的设定点之后，工作流应用40向异常引擎122发送具有指示该改变的数据分组。在该示例中，异常引擎122可被编程为实施规则以确定过程参数的值是否在特定范围内(因为该过程参数可以是用于质量目的关键过程参数)。异常引擎122在运行规则时可以检测到关键参数被设置在期望范围之外，并且因此如果改变设定点则将导致异常。然后，异常引擎122可以立即经由实时反馈消息向应用40发送通知，这可以导致向操作员提供通知或警报。例如，如图5所示，可以基于实时反馈消息在屏幕200中创建弹出框206，告诉操作员预期的动作或刚采取的动作将(或确实)导致异常记录的创建。弹出框206中的该消息可以指示操作员采取动作以避免或减轻异常(如果已经发生的话)。因此，如将理解的，为数据源创建并存储在规则数据库124中的规则可以涉及检测实际异常和/或检测将来导致异常的状况的可能发生。此外，异常引擎122的实时反馈特征可用于使用户能够避免未来异常的发生或减轻或逆转导致当前检测到的异常的状况。因为该通知对于过程的操作是实时的，所以更可能的是，使用该实时质量反馈技术可以逆转或减轻异常的影响。

虽然图2示出了过程工厂环境110中的质量检查管理系统112的操作，其中系统112的各个部分在专用服务器和数据库中执行，但是质量检查管理系统112可以在插件环境中实现，使得系统更具有便携性，能够更容易地在移动或分布式设备上使用，易于在分布式环境中维护和实现，并且易于配置用于第三方系统或应用。具体地，图6示出了使用插件实现的质量检查管理(QRM)系统300。图6的质量检查管理系统300包括质量检查服务设备302(其可以存储在服务器或其他计算设备中并在其上执行)，其通信耦合到各种数据源304A、304B、304C等，规则数据库124和配置应用122。更进一步地，质量检查管理服务设备302耦合到各种插件310、312、314、316等，这些插件可以存储在任何期望的计算设备中并在其中运行，例如存储在工厂环境内或工厂环境外的工作站中，存储在移动设备中，例如存储在笔记本电脑、电话等中，或者存储在任何其他设备中。插件312-314可以根据任何特定订单或数据源的需要而被创建(实例化和启动)。在这种情况下，可以为特定数据源和/或为数据源内的特定订单创建每个插件310-316，以分析来自该数据源的数据进行异常检测。当订单或应用完成或结束时，可以删除(destroy)插件。

一般而言，QRM服务设备302可以响应于配置应用122而为特定数据源或来自特定数据源的特定订单创建特定插件。每个插件310-316可以包括作为插件310-316的配置的一部分而提供的配置信息，以向插件310-316通知将被发送到插件310-316以进行评估的信息的数据和数据格式、存储用于数据源或订单的异常记录文件或数据库的位置、以及插件310-316的操作所需的任何其他期望的配置数据。此外，如果需要，插件310-316的配置数据可以包括一个或多个规则以基于所接收的数据来应用或分析。当然，每个插件310-316可以与相同的数据源或不同的数据源相关联(被配置用于相同的数据源或不同的数据源)，因此，取决于数据源或插件310-316的使用，每个插件310-316的配置信息可以是相似的或非常不同的。每个插件310-316的配置信息还可以指定在操作期间要从QRM服务设备302或从第三方应用或源订阅或接收的数据，并且插件310-316可以向QRM服务设备302或其他应用或源注册以接收该数据。通常，插件310-316可以简单地操作以从数据源获得特定数据，因此仅需要被配置为理解什么数据来自数据源以及该数据的格式。然后，插件310-316可以接收和处理来自数据源的数据，并将所接收的数据置于为数据源创建的异常规则所使用的格式中。以这种方式，插件310-316可以作为用于任何类型的数据源，甚至第三方或专有数据源的数据收集和解释应用来操作。

此外，每个插件310-316可以包括运行时(runtime)处理配置，其定义或控制插件310-316在操作期间的操作。该运行时部分可以包括逻辑解析器，该逻辑解析器使用针对数据源的异常规则内的规则或逻辑来分析从数据源接收的数据，并且创建异常记录并将其存储在异常记录数据库或日志170中。实质上，插件310-316的运行时部分逐个实例地实现图2的异常引擎122。因此，如上所述，可创建插件模块310-316以将异常引擎122与外部或第三方系统(例如，控制系统、OPC接口、维护系统等)对接；从而使得能够完全或部分地基于来自第三方或外部软件系统的数据而生成异常。在一个示例中，创建插件以访问第三方或外部系统内或来自第三方或外部系统的特定数据，并将该数据传递到异常引擎122以分析是否应当创建异常。然而，插件310-316可以存储在第三方服务器中、在QRM服务设备302中、或者在另一服务器、移动设备或其他处理设备中，并在其中执行。

作为示例，图6的配置应用122可以用于创建一个或多个插件310-316，包括指定要从数据源接收的、要由插件310-316分析的数据的格式，插件310-316应当从数据源接收数据的频繁程度，订单的标识和关于数据源的其他信息，插件310-316将用于处理的应用的类型等。

此外，如果需要，可以创建具有数据获取功能和运行时异常处理能力的插件模块310-316。一旦创建，插件310-316可以存储在任何方便的位置或处理设备中并在其中执行，诸如靠近数据源或多个数据源的设备。此外，插件310-316可以向数据服务设备302(或向任何其他服务器或设备)注册，以从诸如数据源304之一的适当数据源接收数据。QRM服务设备302然后可向数据源304订阅或轮询适当的数据，并且在从数据源接收到数据分组时，可向插件模块310-316提供该数据和针对该数据源的一个或多个异常规则，以用于分析该数据。然后，插件310-316可以使用其逻辑引擎中的规则来分析数据的异常，并且在检测到异常时，可以在数据源的异常记录数据库170中存储异常记录。因此，如将理解的，QRM服务设备302充当插件310-316的数据代理(broker)，其可以使用任何数据或从不同源获得的数据在任何期望的设备上彼此独立地操作。

如将理解的，质量检查管理系统128可以在逐个源的基础上实现插件或插件模块的使用，以执行异常引擎的功能，如本文所述，以使得质量检查管理系统能够容易地被配置用于不同的数据源、用于不同的质量检查标准，和/或容易地在分布式环境中运行，在该分布式环境中，系统的各种不同部分在遍布工厂的不同计算机中执行。在这种情况下，可以为每个不同类型的数据源创建不同的插件，并且每个插件可以具有其自己的与之相关联的规则集合，以用于执行来自特定数据源的异常检测。

此外，插件模块310-316可以在批次或订单处理环境中执行或不执行异常处理和检测。在一些情况下，例如，可以创建插件310-316中的一个或多个，以执行或增强工厂内的过程或事件监视，或者执行工厂内的质量检查，诸如在连续过程制造厂内。因此，插件310-316可以是简单的第三方系统数据收集器，或者可以收集数据并且另外执行一些异常处理，或者可以向独立的异常引擎提供异常或预处理的异常数据。使用插件来实现质量检查是有利的，因为已知的质量检查产品不能与从外部软件程序(如控制系统、安全系统、维护系统等)直接提供的数据对接或基于从外部软件程序直接提供的数据来创建异常。此外，插件模块环境的使用使得本文描述的质量检查管理系统112在具有在运行时期间操作的多个不同软件系统的复杂过程环境中更为鲁棒。

图7示出了使用本文描述的质量检查异常处理技术的数据或事件监视系统的示例。特别地，图7示出了可以运行连续过程或过程设备的过程工厂400的高级图。如图7所示，过程工厂400包括过程控制设备402，其可以与例如运行或实施连续过程(例如原油精炼过程)或批次过程或两者相关联。过程工厂400可以包括一个或多个连接到过程控制设备402的批次执行器404，以及一个或多个监视过程控制设备402的一个或多个部分或部件的操作员接口406。更进一步地，批次执行器404和操作员接口406可以连接到主工厂控制设备410，其可以存储工厂400的配置和控制信息。更进一步地，工厂400可包括一个或多个应用服务器(Application server，AS)411，其可运行其他应用，包括例如数据库应用、监视应用、工厂分析应用等。

在许多情况下，工厂400内的工厂资产运行专有的或第三方控制、监视和资产管理系统，其在操作期间从工厂收集大量数据。此外，操作员监视应用和接口406、批次执行器404或其他控制应用本质上也可以是优先的。在过程控制技术中已知使用OPC接口来从各种第三方或专有应用获得数据。因此，每个操作员接口406可以包括OPC警报和事件(OPCae)412或OPC数据访问(OPCda)接口412，例如，以使得能够检测和使用警报和事件数据(如在工厂400中，例如在过程设备402中生成的)或其他将由外部系统使用的过程数据。另外，在一些情况下，一个或多个监视应用414可以存储在一个或多个工厂设备中，诸如存储在应用服务器411或单独的事件监视(Event monitoring，EM)服务器416中。事件监视应用414可以是已知的应用，用于与一个或多个批次执行器404对接以获得过程事件信息(但不必经由OPC接口)，和/或可以配置为与一个或多个OPCae或OPCda接口412对接以从过程控制网络402获得警报和事件数据或其他数据。事件监视器应用414传统上用于从工厂资产获得诸如事件和警报信息之类的过程数据，并将该数据存储在数据库中以供以后在诸如过程控制分析系统、维护系统等的各种系统中检查或使用。

然而，本文描述的异常处理结构可以用于处理从事件监视应用414获得的警报和事件以及其他信息，以确定在工厂设备402内或工厂设备402的操作期间是否发生某些工厂条件。仅作为示例，这样的条件可以包括当某些事件或警报达到临界水平时、当警报或事件的某个集合或组合一起发生时、当存在各种过程条件时、或指示可能需要向诸如质量检查工程师、安全工程师等的某种用户指明的问题的任何其他条件集合。为了执行该功能，图7的事件监视器插件450可以用于从工厂400内的一个或多个事件监视应用414、工厂400内的一个或多个OPCae和/或OPCda接口412等访问数据。事件监视插件450可以从事件监视应用414、OPCae和OPCda接口412或工厂400中的其他数据源接收数据，并且可以执行异常规则处理以检测工厂400中某些通常更复杂的条件的存在。即，在工厂400中可能存在质量检查工程师、安全工程师、维护工程师、过程控制工程师或其他人可能想要知道但在建立过程控制或监视系统和运行工厂400时未被这些系统检测到的条件。通常，这些条件不是简单地由在工厂400中生成的单个警报或事件通知来确定，而是可能需要通过工厂400中存在的更复杂的条件集合来确定，诸如超过某个临界水平的警报、同时或几乎同时发生的某个类型的某个数量的警报、与工厂400中的一个或多个其他事件相结合的某个类型或严重性的警报等。如将理解的，插件模块450可以包括异常引擎(如本文另外描述的)或提供对其的访问，该异常引擎利用实现逻辑的规则进行操作以确定工厂400的操作中的这些“异常”。因此，图7的事件监视器450可以从第三方应用(事件监视应用414)或系统(事件监视服务器416)或接口(OPCae接口412)收集数据，并且可以使用预先配置的规则集合来处理该数据，以执行增强的事件检测或过程监视或异常处理，以用于质量检查目的。在这种情况下，事件监视应用450(其可以位于与工厂环境不同的环境中，如图7的虚线所示)可以将规则分析的结果提供给监视接口452和/或数据库454，诸如SQL(Sequel)数据库，以供稍后检查。实质上，事件监视插件450操作以基于由工厂设备402收集并提供给工厂400中的第三方应用或接口的事件监视数据来检测工厂设备402的操作中的“异常”。这种类型的监视在本文仍然被称为异常处理，因为这种监视检测工厂400的操作中的异常，即使它不是作为质量检查过程的一部分来执行的。

在任何情况下，事件监视器450可以被绑定到一个或多个第三方或外部系统中的任何一个，并且可以被用于生成消息并将消息发送到规则引擎(未示出)，规则引擎然后可以使用这些消息来以监视消息、通知、警报等的形式执行异常处理或异常创建。在一种情况下，内部事件监视器450可以被绑定或耦合到OPCae接口412，并且可以识别何时从OPCae接口412传递一个或多个警报或警告。此时，事件监视器应用414或OPC接口412创建具有警报或警告信息以及潜在的任何其他期望的OPC收集的数据的消息并将该消息投放到外部事件监视系统450。系统450然后可以分析消息以基于消息中的数据生成异常。这种操作是有利的，因为已知的质量检查系统不分析来自第三方系统的数据，并且不连接到存在的OPC警告和警报接口。因此，这些系统不能基于例如过程警报和警告生成异常。

一般而言，图7的事件监视系统450可以以许多不同的方式配置，以收集和处理来自过程控制系统402的警报和事件数据，以使用异常处理产生增强的监视系统。特别地，用户可以配置事件监视系统或模块450，其可以是如上所述的插件；以订阅和收集例如由图7的OPCae和OPCda接口412收集的数据(例如，事件和警报数据、消息等)。收集该数据的事件监视服务器416然后可以将该数据以数据分组的形式与其他信息一起发送到事件监视应用450，所述其他信息诸如定时信息、过程控制元数据(从OPC接口412、批次执行器404、过程计算机410等获得的)。事件监视系统450然后可以如上所述地将规则集合应用于数据，以基于收集的事件和警报数据以及规则逻辑来确定是否存在任何事件监视异常。如果确定异常，则事件监视系统450可以创建消息(基于规则)并将该消息发送到监视接口452以显示给用户和/或显示给例如Sequel服务器中的数据库或消息队列454。当然，生成异常的规则可以指定消息的内容、消息的格式、要放置到消息中的信息、要将消息发送到的接口等。另外或替代地，事件监视系统450可以创建异常记录并将其发送到监视数据库以供存储和稍后检索。该异常记录(其是监视条件记录)可以包括基于规则配置的任何期望的信息，并且可以包括例如事件的解释、事件的严重性、用于处理事件的指令、在事件发生时的过程元数据等。如将理解的，在这种情况下，用于事件的规则逻辑在事件监视系统450中(或在耦合到其的异常引擎中)被处理，并且可以在诸如图6的插件环境中或在诸如图2的传统服务器环境中被处理。

在另一种情况下，事件监视系统450可以基于其配置来配置OPC接口412，例如，以检测某些条件或条件的组合，然后当满足这些条件时向事件监视系统450发送消息。在这种情况下，事件监视系统450实质上对OPCae或OPCda接口412编程以执行规则的逻辑，并仅在满足该逻辑时向事件监视系统450发送消息或数据。在从OPCae接口412接收到具有指示满足特定条件或逻辑集合的消息时，事件监视系统450可以简单地创建通信并将其发送到事件监视接口452和数据库454，以向用户通知该条件并将异常记录存储在数据库454中。在这种情况下，用于事件监视系统的规则的逻辑完全或部分地在OPC接口412或外部事件监视应用414、416中执行，其可以使用已知技术来配置以实现该逻辑，并且仅在过程工厂400中存在特定条件时发送消息。

因此，在图7的示例系统中，本文描述的质量检查管理系统的基于异常的处理可以用于分析、检查或检测来自不使用与例如工作流应用40相同的数据格式的第三方系统的数据中的异常。虽然在图7的情况下，将质量检查管理系统示为用作事件监视系统，以经由一个或多个OPC接口412与批次或连续过程控制系统对接，以基于各种事件、警报、参数设置等的存在来确定基于监视的异常，但是本文描述的质量检查管理系统可以经由任何其他期望的接口连接到第三方过程设备、服务器、应用等。

返回参考图2，可以执行质量检查接口应用128，以使用户(例如质量检查工程师)能够从特定数据源访问针对一个或多个批次运行、订单、过程操作等的一个或多个异常记录数据库170。质量检查接口应用128例如可以使用户能够逐个步进遍历异常数据库170中的每个异常记录，以查看检测到的异常并解决这些异常，诸如采取任何必要的动作来关闭异常记录。质量检查应用128可以经由接口设备的接口屏幕呈现针对每个异常记录的数据或信息，诸如异常的名称、异常的类型、异常的严重性、针对异常记录存储的批次元数据或快照信息、由操作员创建和存储的与异常记录相关联或导致创建异常记录的注释、由数据源提供的任何其他信息等。该信息使得质量检查者能够在异常发生时快速理解异常和过程(例如批次运行)的情境，以便能够更好地理解异常和异常的重要性。质量检查接口应用128还可以以结构化方式向用户呈现各种其他类型的信息，诸如关于这种类型的异常、需要执行什么步骤来处理或签核这种类型的异常或异常的严重性等的一般信息。更进一步地，质量审查接口应用128可以使用户能够采取签核或关闭异常所需的各种步骤中的一个或多个，诸如实施由检测到异常的原始异常规则定义的各种程序中的一个，以便签核或处理异常。质量检查应用128可以例如使得用户能够点击屏幕上的复选框来确认和签核异常，可以要求或强制实施包括使一个或多个其他人员查看和签核异常以便关闭异常的过程等。更进一步地，质量审查接口应用128能够经由电子邮件或其他网络通信将异常记录发送给其他人员，以便获得对异常的签核，询问关于异常的问题或提供关于异常的数据或注释，确定关于异常的更多信息，或实施处理或关闭异常所必需的程序。

图8A-8G示出了可以由质量检查接口应用128创建的各种示例屏幕显示，以便使检查者能够在执行例如订单的质量检查的过程中查看和操纵异常记录。作为示例，图8A示出了可以由检查者用来选择要检查的各种订单或异常记录文件集合中的一个的屏幕显示500。屏幕500包括列出存在异常记录日志170(例如，如存储在图2的异常记录日志数据库126中)的各种数据源(例如，以下拉菜单格式)的区域或字段502。此外，区域504可以列出对于区域502中的所选数据源存在的订单或异常记录文件170的集合。因此，在图8A的示例屏幕500中，字段502列出工作流数据源，并且区域504列出用于由工作流应用管理的订单或批次运行的多个各种异常记录文件。更进一步地，区域506可以列出在区域504中选择的特定文件(例如，订单)内的异常记录。用户可以向下滚动列表506以选择异常记录506A-506N中的不同记录。更进一步地，屏幕500的区域508可以呈现如在区域506中选择的异常记录506A-N的信息。在该示例中，用户已经选择了异常记录506B，并且应用128从异常记录日志数据库126中获得所选择的异常记录506B的信息，并且显示该信息以供用户使用和操纵。区域508可以包括用于所选择的异常记录的各种信息，诸如名称、类型、严重性、用于异常的信息以及用于异常的检查或处理过程。

重要的是，异常记录的显示信息可以包括在创建异常时从数据源收集的过程或数据源元数据510。如上所述，质量检查管理系统112在从数据源收集输入数据时收集元数据集合(当例如创建插件或规则时可以预定义该元数据集合，或者该元数据集合可以是已知由特定数据源提供的数据)。通常，要收集的元数据由在创建规则时配置的数据变换来定义。将数据变换应用于来自数据源的元数据，并且插件以例如HTML输出该变换的元数据，使得元数据在检查应用中是可见的。这个数据源元数据可以是任何过程或环境数据，通常与异常输入数据同时被收集，并且被存储为与所访问的异常数据相关联的过程快照，作为为异常创建的异常记录的一部分。这样，当异常引擎122基于收集的异常数据检测到异常时，异常引擎122还存储数据源元数据作为异常记录的一部分。质量检查接口应用128然后在例如报告所生成的异常的屏幕500的字段510中显示该元数据中的一些或全部，从而在异常在过程中产生时向检查者提供到过程中的实时视图。因此，该特征为检查者提供了在异常时各种过程状态/值等的快速视图，这使得检查者能够更快地理解异常为何产生、异常的情境等，从而使得检查者能够更快地处理或知道如何解决异常。该操作使得质量检查更容易，因为虽然已知质量检查产品通常向检查者提供所生成异常的列表，但是检查者仍然必须分析每个异常以确定是否可以消除异常或者必须以某种其他方式处理异常，并且在这些已知产品中，检查者通常必须返回到收集导致异常的数据的过程系统以在异常时获得过程快照数据。利用由屏幕500的元数据字段510提供的实时视图特征，自动向检查者提供过程快照，该过程快照通常将包括在执行异常检查时对检查者最有用的过程数据，这意味着检查者不需要返回到其他数据收集系统来获得用户执行异常检查和处理所需的信息。该特征还意味着，检查者一般不需要熟悉通常从其收集过程或数据源元数据的其他过程数据检索系统，因为检查者一般不需要使用那些数据收集系统来访问检查者解决异常记录所需的过程数据。

更进一步地，如图8A所示，区域512可以向用户提供关于处理或解决异常的方式的一组选项或信息，例如，检查步骤或程序、执行以关闭异常的动作的清单、需要由各种用户填充或签名以关闭异常的签核字段等。

图8B示出了例示类型工作流注释的异常记录的一些信息的示例屏幕显示520。此处，屏幕区506中的工作流异常是针对所选订单列出的唯一异常。如屏幕520的区域508所示，工作流注释具有状态NEW(新)、严重性LOW(低)，不具有校正和预防性动作(CAPA)标识符(其可以用于定义对第三方系统的引用，该第三方系统还可以用于查看和/或处理异常)或者不与之相关联，并且也未被分配给任何组。然而，区域508显示异常ID(因为每个异常将具有唯一ID)、源指示和异常的创建日期/时间，所有这些数据都被存储为异常记录的一部分。更进一步地，区域508包括异常的一般描述，其还可以是作为异常记录的一部分存储的信息。然而，该数据可以作为检查应用128的一部分存储，并且可以基于异常类型。

同样，屏幕区508的底部部分示出了为该特定异常收集的元数据。在这种情况下，元数据反映了当创建异常时用户在工作流应用中所看到的内容，并且可以用于帮助检查者理解当异常发生时过程的情境。

更进一步地，图8C的示例屏幕530提供了可以在图8B的屏幕区508内提供给检查者以执行异常记录的处理或关闭的解决字段的列表。此处，解决方案可以是根据需要可配置的(并且因此类似的屏幕也可以在配置应用120中用于生成针对异常的规则)。在任何情况下，如图8C所示，解决字段可包括解决名称或类型532(例如标准)、描述534、一个或多个阶段名称536(例如制造或制造监督)、严重性538(例如低)以及人员在一个或多个阶段中关闭或解决异常所需的签名539。在这种情况下，图8C中显示的示例异常记录的解决方案指示该异常必须由两个操作员(在制造阶段)和一个管理员(在制造监督阶段)签署以关闭或解决该异常。这些处理程序可以在图8A的区域或字段512中以签名框、复选框等的形式实现。此外，检查者能够逐个异常地改变这些程序，或者能够对异常进行分组并基于该分组采取步骤。

作为示例，图8D示出了包括屏幕区508的示例屏幕显示540，该屏幕区508具有针对范围外异常的所选参数的解决字段542。再次，此处，屏幕540包括关于所选择的异常记录的一些信息，包括状态(活动)、严重性(低)、CAPA标识符和组名称(如果有的话)。解决区542包括使检查者能够浏览以将文件附加到异常记录(这在以后当客户、FDA等检查订单的异常记录时可能是有用的)的字段544，以及使检查者能够将注释或注解添加到异常记录(此处SA管理员已经注释她将注意关闭异常记录)的注释字段546。当然，可以使用字段546添加附加注释。另外，屏幕540的屏幕区508包括签名和关闭字段548，其可以由各种所需的签名者使用以关闭异常记录。更进一步地，屏幕区508可以包括历史字段549，其指示在处理记录时对异常记录采取的动作，包括采取了什么动作、谁采取了该动作以及该动作的时间和日期。该信息可以由检查接口应用128捕获，并存储为异常记录的一部分。

同样，质量检查接口应用128呈现的各种屏幕可以包括关于订单或订单组的统计信息。例如，屏幕540的区域550包括正在查看的订单的指示551、与关闭的订单相关联的异常记录的数量的指示552、以及订单的完成状态的指示553(在这种情况下，尚未完成但仍在处理订单)。区域550还可以提供链接553，以供检查者签署和验证订单或订单的异常记录等。

同样，图8E的屏幕560示出了质量检查应用128可以逐个订单或逐个组地确定并提供给检查者的附加统计信息。图8E的屏幕560类似于图8D的屏幕540，除了区域562显示关于所选订单中的11个异常记录的各种统计信息。在这种情况下，框564指示每个状态类别(新的、活动的、关闭的)中的订单的异常记录的数量。此外，条形图566按照每个严重性类别(5为低，3为中，2为高，1为新)指示订单的异常记录的数量。更进一步地，条形图568指示每个异常类型中的订单的异常的数量(9为范围外参数类型，2为注释类型)。当然，质量检查应用128可以提供关于异常记录的其他类型的统计信息，并且可以以其他方式提供统计信息，诸如针对订单组、订单或组内的记录子集等。

更进一步地，质量检查接口应用128可以使检查者能够将异常记录中的各种异常记录分组在一起成为组，并且对作为组的记录采取各种动作(注释、改变参数、签核等)。作为示例，图8D和8E的屏幕540和560中的每一个都包括在异常记录列表内的三组记录的列表570，即第一组、第二组和测试者。应用128可以使检查者能够例如通过选择异常记录列表506中的异常记录并将所选择的异常记录拖放到列表570中的组，来将异常记录添加到组。当然，应用128可以使注释者能够以任何合适的方式根据需要创建新的组、删除组等。

更进一步地，应用128可以使检查者能够在组的基础上对异常记录采取一个或多个动作，这为检查者节省了时间。图8F示出了检查者已为组动作(group action)选择了组测试者的示例屏幕580。作为该选择的结果，该应用显示要对组测试者中的异常记录组采取的潜在动作的弹出窗口582。这种动作可以包括改变组中异常的严重性(经由下拉输入框584)，改变组中异常记录的CAPA标识符(经由下拉输入框586)，向组中每个异常记录添加注释(经由输入框588)，向组中每个异常记录附加文档(经由框590)，以及经由链接592签署和关闭组中的异常记录。当然，应用128可以使检查者能够对选择的异常记录组采取任何其他一个或多个动作，并且可以经由接口设备以任何其他方式这样做。

如果需要，质量检查接口应用128可以使检查者能够对实际上不与组相关联的异常记录采取组动作。例如，如图8G的示例屏幕显示592所示，检查者可为列表506中的各种异常记录选择复选框(在图8G的示例中如此选中前两个异常记录)。应用128然后可以将此识别为尝试对所勾选的两个异常记录采取动作，并且可以提供包括图8F的各种编辑字段的弹出屏幕594。然而，在这种情况下，弹出框594可以包括对所选择的异常记录采取的分组动作，例如将它们添加到现有组或创建新组，如图8G的弹出框594的顶部所示。

本文描述的质量检查接口应用128可以使用有利的分页算法或技术，以使检查者能够滚动遍历各个记录页面，例如图8A、8B和8D-8G的记录列表506中提供的异常记录，其滚动方式是当在记录的页面之间行进时，减少或消除在显示中的不同页面中或遗漏记录中呈现重复记录。通常，基于web或基于浏览器的显示系统使用浏览器来显示存储在外部结构化数据库(例如经由网络连接可访问的SQL数据库)中的有组织的记录的列表，该显示系统搜索数据库中的相关记录，然后呈现将适合显示页面的多个记录，例如一次10个记录。因此，这些系统通常将首先显示处于返回列表的前十个位置的记录。当用户希望看到当前显示的列表之外的更多记录时，浏览器利用相同的搜索联系数据库，并且如果用户在记录列表中向下滚动则获得下一记录集合(例如，下10个位置的记录)，或者如果用户在记录列表中向上滚动则获得前一记录集合(例如，前10个位置的记录)。当然，可能存在大量异常或记录，因此当用户向下或向上滚动记录列表时，界面必须滚动遍历记录的许多页面。因此，显示系统的浏览器将确定与查询相关联的所有相关记录，并将第一页面呈现为列表中的前X个记录(例如，如果X为10，则为记录1-10)。当用户想要查看不在第一页面中的记录时，系统加载第二页面作为列表中的第二X个记录集合(例如，列表的位置11-20中的记录)。然后，系统在列表中向上或向下滚动X个位置，以呈现记录的较早或下一页面。当记录列表是静态的并且改变不是非常频繁时，这个分页算法工作良好，因为系统仅仅加载X个记录的连续集合作为每个新页面。

然而，当列表或搜索中的记录改变时，诸如当一些记录由于记录的一些参数改变而消失或从搜索中丢弃时，或者当在数据库中创建新记录时，通过搜索找到的记录的原始列表改变，并且这些改变可能在检查者正在检查一页面记录但在调用下一页面记录之前的时间期间发生。在这种情况下，当检查者处理记录并向下滚动在用户界面上显示的记录列表时，记录可能在数据库中改变，因此页面数据可能变得过时。特别地，可以在数据库中添加或从数据库中删除记录(或者记录可以具有改变的参数，该参数使得记录根据搜索标准不再通过搜索返回)。结果，当显示系统试图在显示屏上针对后续页面呈现记录时，在原始搜索中引用的各种记录可能丢失，从而导致可视数据丢失或重复。在一些情况下，用户可能由于删除特定恢复页面上的记录而遗漏从一页面到下一页面的记录。在其他情况下，系统可能对于基于在原始返回的记录列表中的缺失记录而在哪里开始新的显示页面而变得困惑。在又一种情况下，显示系统可以基于向数据库添加新记录而在多个页面上呈现相同记录。在检查系统中，这些情况都不是希望出现的，在该检查系统中，对于检查者来说，查看和签核列表中的每个记录都是重要的，如应用128所提供的，对于订单的异常记录日志中的异常记录就是这种情况。

图9A和9B示出了在典型的基于浏览器的显示界面中的上述问题，该显示界面显示从搜索存储在数据库中的记录返回的记录，其中在显示活动期间，可以向数据库中添加记录或从中删除记录，或者在数据库中改变记录的参数。特别地，图9A示出了在时间T1从搜索数据库返回的相关记录700的列表(包括记录R1-RN)，其中记录R1-RN可以是针对订单的所有记录，或者可以是基于一些其他搜索标准的一些有序记录列表，例如针对订单的所有打开记录、特定严重性的所有记录等。在任何情况下，显示系统(例如，用户界面处的浏览器)可以在第一时间T₁接收列表700，访问列表700中的前七个记录，并将这七个记录作为第一页面记录呈现在用户界面上的显示屏幕704中。因此，显示屏幕704包括记录R1-R7作为来自搜索的第一页面记录。显示系统可以在稍后的时间T₂，例如当用户请求下一页面记录时，访问数据库以获得相关记录的列表。假定没有对数据库中的记录做出改变，则在时间T₂返回相同的记录列表700，并且显示系统将仅仅访问在列表上的第二组七个位置中找到的记录集合(产生记录R8-R14)并将其作为第二页记录显示在显示708中。如果来自数据库的记录700的有序列表从时间T₁到时间T₂保持静态，则图9A中所示的该操作工作良好。

然而，如果在呈现第一页面704的时间T₁和呈现第二页面708的时间T₂之间从相关记录列表中移除了记录(例如，一个或多个记录的参数发生了改变，这使得在记录搜索中不会找到该记录)，则显示系统可能无意中跳过记录的显示。图9B示出了在显示中呈现第一页面704的时间T₁之后但在呈现第二页面708的时间T₂之前从搜索列表中移除(或从搜索列表中丢弃)记录R4的示例。在这种情况下，显示系统的浏览器基于列表700获得并在第一页面704中显示前七个记录R1-R7，如在时间T₁在图9A的数据库中所发现的。然而，当显示系统的浏览器访问图9B中的第二页面708的记录时，浏览器仅仅访问并使用返回列表710中的第二组七个记录，即图9B的列表710中的位置8-14中的记录。因为此时已经移除记录R4(因为它可能已被关闭，并因此从相关记录列表中移除或丢弃)，所以显示系统将记录R9-R15作为第二页面记录显示在显示708中，因为当显示第一页面时最初在图9A的列表700中的第八位置的记录R8现在由于在时间T₁和T₂之间移除记录R4而处于图9B的列表710中的第七位置。这样，记录R8未在图9B的显示的第一页面704或第二页面708中的任何一页面中示出，因此被检查者遗漏。当然，当在分页过程期间将记录添加到列表或数据库时，会发生类似的情况，但是在这种情况下，由于添加了使得最初在与一页面相关联的位置的特定记录在稍后的时间变为位于与不同页面相关联的位置的记录，一个或多个记录可能在连续页面中重复或呈现。

当检查者滚动遍历具有可以改变的参数或者其中可以添加新记录的异常记录的页面时，这种情况是不利的，因为这导致了在显示中跳过相关记录的情况，或者其中在显示的不同页面中重复相关记录的情况。

然而，本文描述的质量检查应用128可以使用不同的分页技术来确定在显示的各种不同页面中呈现哪些记录，并且这种新的分页技术减少或消除了当在不同页面之间行进时重复和/或丢失记录的显示。特别地，质量检查应用128不使用从数据库返回的记录列表中的固定或预设位置或记录位置来执行分页，而是使用标示(mark)一个或多个记录的动态分页算法，诸如最近显示的页面中的第一个记录或最后一个记录或者第一个记录和最后一个记录两者，并且然后使用该标记(marker)或锚(anchor)来找到要作为显示的下一页面的一部分显示的记录集合。以这种方式，如果在显示页面之后，向相关记录列表添加任何记录或从相关记录列表删除任何记录，则在下一页面中显示的记录集合将是在加载新页面时与最后显示的记录之一(例如，前一页面的第一个或最后一个记录)相邻的列表中的记录。

图10A和10B示出了质量检查接口应用128所使用的新分页算法或技术的操作。在这种情况下，在时间T₁和T₂从数据库搜索返回的图10A和10B的相关记录700和710的列表分别包括与图9A和9B所示的相同的相关记录集合。如图10A所示，接口应用128呈现第一页面704作为显示中的前七个记录，但是用指示当前显示的页面中的最后或底部记录的锚(称为Anchor1_bot)来标示第一页面704中显示的最后或底部记录(R7)。应用128还可以用指示当前显示的页面中的顶部或第一记录的顶部锚(本文称为Anchor1_top)来标示显示704中的第一或顶部记录(R1)。然后，当应用128加载下一页面记录，即页面2时，应用128在返回的记录列表中搜索页面1的底部锚(Anchor1_bot)，而不考虑在返回的列表700或710中找到该记录的位置。然后，应用128使用列表700中紧接在用页面1的底部锚(Anchor1_bot)标示的记录之后的下七个记录，以用于在页面2中显示的记录的列表。应用128然后还可以移除锚Anchor1_bot，但是可以标示或存储用于下一页面记录的附加锚(即，Anchor2_top和Anchor2_bot)，以标示在显示708的页面2中显示的顶部和底部记录。应用128然后使用用Anchor2_bot标示的记录来确定当用户在页面2的列表中向下滚动时哪些记录要在下一页面(页面3)中显示，或者使用用Anchor2_top标示的记录来确定哪些记录要在前一页面中显示(例如，如果用户在页面2中的记录列表中向上滚动以返回到页面1)。如将理解的，该分页技术将锚或标记置于记录上，或者存储指示当前显示页面的各个位置的记录的锚或标记，并使用这些锚来确定所返回的记录集合中的哪些记录用于下一页面的第一(或最后)记录，而不考虑所返回的列表中记录的实际位置。这样，记录可以在不同页面的显示之间在数据库或返回列表700内的位置中上下移动，而不会以图9A和9B所示的方式扰乱分页显示。

作为示例，图10A示出了当在时间T₁和T₂之间没有对数据库做出改变时使用锚的操作，导致在第一页面704中呈现记录R1-R7，在第二页面708中呈现记录R8-R14。图10B示出了当这些锚用于在时间T₁(其中返回的记录列表是图10A的列表700)和时间T₂(其中返回的记录列表是图10B的列表710)执行分页时，使用记录列表710内的锚的操作。特别地，页面1的显示704包括基于图10A的数据库中的记录列表700在创建页面1的时间T₁的状态的记录R1-R7。然而，应用128在加载页面1时用锚Anchor1_top标示记录R1，并且用锚Anchor1_bot标示记录R7。接下来，在时间T₂，当显示应用128获得记录列表710(其现在已经改变，因为记录R4不再在列表中)以显示页面2时，应用128在返回列表710中搜索已经被标示为Anchor1_bot记录的记录，并且在列表710中找到该记录时，简单地加载并显示接下来的七个记录(在这种情况下是记录R8-R14)作为页面2显示708，而不管实际上记录R8-R14在列表710中的第七到第十三位置。当然，应用128可以每页面标示任意数量的锚，但是通常每页面具有两个锚，以标识当前页面中的顶部和底部记录，并且然后在加载后续页面时将加载与这些锚相邻或紧接着的记录。使用两个锚使得应用128能够以当列表中的记录的状态改变(在列表中添加或移除这样的记录)时消除或减少显示中的丢失记录或在不同页面中重复记录的方式在页面中上下滚动。

应用128可以使用任何标示技术，诸如在正显示特定页面时将位于顶部和底部锚位置的记录的指示存储在单独的锚变量中(诸如在浏览器或浏览器设备中)，实际上将标记存储在与当前处于当前显示的记录页面中的锚位置中的记录相关联的数据库中，将记录中的一个或多个存储在当前页面中作为标记，将临时标记紧接在被标示的记录之前或之后放置在数据库中，等等。另外，标记或锚可以存储在应用128、应用128所使用的浏览器、存储记录的数据库等中。此外，当访问和显示新的页面时，应用128移动或改变锚位置或标记。更进一步地，应用128可以使用任何值作为记录的锚。例如，应用128可以使用锚所在的记录的参数作为锚，例如记录的时间/日期戳等。在一些情况下，记录的锚可以基于或指示记录的搜索参数或搜索参数的某种组合，或者可以是记录的某个其他唯一值，诸如记录名称、标识号等。同样，在一些情况下，与标记相关联的记录可以是从相关搜索列表中丢弃的记录。在这种情况下，在没有在新列表中找到锚记录时(当加载新页面时)，应用128可以将锚改变为当前显示的页面中与现在缺失的锚记录相邻的记录(例如，当前显示页面中紧接在底部锚之上或之前的记录，或者当前显示页面中紧接在顶部锚之下或之后的记录)，然后使用新锚来确定返回列表中的记录集合以在新显示页面中呈现。

因此，质量检查接口应用128所使用的分页算法比过去的分页系统更好地操作，因为这个新系统从显示在前一页面或屏幕上的最后记录开始在新显示屏幕上下载和呈现记录，而不管记录在返回列表中的位置。即，代替呈现与恢复的记录的原始列表中的记录的位置相关联的新显示页面，系统128访问数据库以查找紧接在当前显示页面上的最后记录之后(当向下翻页列表时)的当前存在于新列表中的记录，从而确保每次在屏幕上显示新的记录集合时，所显示的第一新记录是新搜索列表(710)中的记录，该记录紧接在来自前一次搜索(700)的前一页面中显示的最后记录之后。该显示系统更准确，因为它有助于确保记录不会无序显示，记录不会在多个显示页面中重复，并且在用户在对数据库中的记录进行改变的长时间段内滚动遍历各个记录页面的检查过程中不会遗漏记录。此外，检查应用128更为高效，因为当用户滚动遍历记录时，它仅需要访问数据库以获得将适合新显示页面的数量的新记录，同时仍确保当用户执行滚动过程时访问所有相关记录。

可以理解，本文描述的质量检查管理应用和批次执行引擎、服务器应用、插件等可以在任何期望的过程工厂环境中使用和实现，并且可以在使用任何期望类型的过程工厂控制通信协议的任何过程工厂控制系统中使用。虽然本文描述的应用和例程优选地以存储在例如服务器、工作站、手持设备或其他计算机中的软件来实现，但是这些例程可以根据需要替代地或另外地以硬件、固件、专用集成电路、可编程逻辑电路等来实现。如果以软件实现，则例程或应用可以存储在任何计算机可读存储器中，例如磁盘、激光盘、EPROM或EEPROM、固态或其他存储介质，存储在计算机、手持设备、控制器、现场设备等的RAM或ROM中。同样，该软件可以经由任何已知或期望的传递方法被传递给用户或设备，所述传送方法包括例如通过诸如电话线、互联网之类的通信信道、在诸如计算机可读盘之类的便携式介质上等等。

尽管已经参考特定示例描述了本发明，这些示例仅旨在说明而非限制本发明，但是本领域的普通技术人员将清楚，在不脱离本发明的精神和范围的情况下，可以对所公开的实施例进行改变、添加或删除。

Claims

1.一种在检查过程的操作中使用的质量检查系统，包括：

规则数据库，存储多个规则，其中，所述多个规则中的每个规则包括标识与过程内的一个或多个异常相关联的条件的逻辑；

一个或多个数据源，被配置为在所述过程的操作期间收集所述过程内的过程数据，并且在一个或多个数据消息中发送所收集的过程数据；

异常引擎，使用所述规则数据库中的所述规则来处理来自所述数据源的一个或多个数据消息内的过程数据，以基于所述数据消息内的所述过程数据确定是否存在由所述多个规则中的任何规则定义的异常，其中，所述异常引擎在基于所述规则中的一个规则识别出异常时，针对所确定的异常创建异常记录，并且将所述异常记录存储在异常记录数据库中；

事件监视器，通信地连接到外部系统和所述异常引擎，其中，所述事件监视器被配置为检测所述外部系统内的条件，并且将关于所述外部系统内的所述条件的外部信息发送到所述异常引擎，并且其中，所述异常引擎基于来自所述事件监视器的所述外部信息检测一个或多个另外的异常，并且针对所述一个或多个另外的异常创建一个或多个另外的异常记录，并将所述一个或多个另外的异常记录存储在所述异常记录数据库中；以及

检查接口，使得用户能够检查由所述异常引擎识别的并且作为所述异常记录和所述另外的异常记录存储在所述异常记录数据库中的所述异常和所述另外的异常。

2.根据权利要求1所述的质量检查系统，其中，所述外部系统是过程控制系统，并且所述事件监视器检测所述过程控制系统内的事件。

3.根据权利要求1所述的质量检查系统，其中，所述事件监视器经由OPC接口通信地连接到所述外部系统，并且经由所述OPC接口接收关于所述外部系统的OPC数据。

4.根据权利要求3所述的质量检查系统，其中，所述事件监视器经由所述OPC接口从所述外部系统接收OPC警报和事件数据。

5.根据权利要求1所述的质量检查系统，其中，所述异常引擎在第一服务器中执行，并且其中，所述事件监视器在所述第一服务器中执行。

6.根据权利要求1所述的质量检查系统，其中，所述异常引擎在第一服务器中执行，并且其中，所述事件监视器在不同于所述第一服务器的第二服务器中执行。

7.根据权利要求1所述的质量检查系统，其中，所述事件监视器从所述外部系统接收外部系统数据，并且对来自所述外部系统的所述外部数据执行处理以确定与所述外部系统相关联的一个或多个条件。

8.根据权利要求1所述的质量检查系统，其中，所述异常引擎使用所述规则数据库内的一个或多个规则来分析来自所述事件监视器的、关于所述过程内的所述条件的所述外部信息，以检测所述一个或多个另外的异常。

9.根据权利要求1所述的质量检查系统，其中，所述外部系统是安全仪表系统，并且所述事件监视器分析安全仪表数据。

10.根据权利要求1所述的质量检查系统，其中，所述外部系统是维护系统，并且所述事件监视器分析来自所述维护系统的维护数据。

11.一种在监视过程的操作中使用的监视系统，包括：

运行时监视应用，存储在存储器中并且适于在处理器上执行，所述运行时应用包括：

存储配置的配置存储器，所述配置包括多个规则，其中，所述多个规则中的每个规则包括对要在所述过程内检测的一个或多个预定义事件进行定义的逻辑定义；

通信接口，适于被通信地连接以接收包括所述多个规则的配置，并且适于通信地连接到外部数据源以从所述外部数据源接收数据消息，以及

逻辑引擎，在所述过程的运行时期间操作以使用所述多个规则来处理来自所述外部数据源的一个或多个数据消息内的过程数据，以便确定是否存在由所述多个规则中的任何规则定义的预定条件，其中，所述逻辑引擎在识别出由所述多个规则中的一个规则定义的预定条件的存在时，创建标识所述预定条件的消息，并且将所述消息发送到外部接收方，以及

配置应用，存储在存储器中并且适于在处理器上执行，用以使得用户能够创建所述配置，包括使得所述用户能够创建要在所述逻辑引擎中实现的所述多个规则中的每个规则，并经由所述通信接口将所述配置提供给所述运行时应用。

12.根据权利要求11所述的监视系统，还包括OPC接口，其中，所述运行时监视应用通信地耦合到所述OPC接口以使用OPC协议接收数据消息，并且其中，所述规则引擎使用所述多个规则来处理OPC数据消息内的数据。

13.根据权利要求12所述的监视系统，其中，所述配置内的所述多个规则指定要由所述OPC接口检测的数据或事件的组合，并且其中，所述运行时应用将所述OPC接口配置为：当所述OPC检测到数据或事件的组合时，将指示预定条件的数据消息发送到所述运行时应用。

14.根据权利要求11所述的监视系统，还包括工作流监视系统，所述工作流监视系统包括存储多个规则的规则数据库，其中，所述多个规则中的每个规则包括标识与过程内的一个或多个异常相关联的条件的逻辑；以及

异常引擎，使用所述规则数据库中的所述规则来处理来自过程设备的数据消息内的数据，以确定是否存在由所述多个规则中的任何规则定义的异常，其中，所述异常引擎在基于所述规则中的一个规则识别出异常时将关于所述异常的信息作为异常记录存储在异常记录数据库中；

其中，所述工作流监视系统是外部接收方，并且其中，所述异常引擎还处理来自所述监视系统应用的、标识预定条件的所述消息。

15.根据权利要求14所述的监视系统，其中，所述异常引擎使用所述规则数据库中的所述规则来处理标识预定条件的所述消息，以基于标识预定条件的所述消息来确定异常。

16.根据权利要求14所述的监视系统，其中，所述异常引擎通过将标识预定条件的所述消息存储在所述异常记录数据库中来处理标识预定条件的所述消息。

17.根据权利要求11所述的监视系统，还包括事件数据库，其中，所述事件数据库是外部接收方，并且所述事件数据库存储标识预定条件的所述消息。

18.根据权利要求11所述的监视系统，还包括监视用户接口，其中，所述监视用户接口是外部接收方，并且所述监视用户接口向用户显示标识预定条件的所述消息。

19.一种监视过程的方法，包括：

经由基于计算机处理器的接口设备，使用户能够通过指定多个逻辑规则来创建监视应用配置，所述多个逻辑规则定义要在过程中检测的一个或多个预定条件；

向运行时监视应用提供包括所述多个规则的所述监视应用配置；

将所述运行时监视应用通信地耦合到与所述过程相关联的一个或多个数据源，所述运行时应用适于在所述过程的操作期间在处理器上执行；

在所述运行时应用处，在所述过程的操作期间从与所述过程相关联的所述一个或多个数据源接收数据消息；

在计算机处理器上使用所述多个规则来处理来自所述一个或多个数据源的所述数据消息内的数据，以确定是否存在由所述多个规则中的任何规则定义的预定条件，并且在识别出由所述多个规则中的任何规则定义的预定条件的存在时，创建标识所述预定条件的消息；以及

将标识所述预定条件的所述消息发送到外部接收方。

20.根据权利要求19所述的监视过程的方法，其中，将所述运行时监视应用通信地耦合到与所述过程相关联的一个或多个数据源包括：经由与所述过程通信地耦合的OPC接口将所述运行时监视应用通信地耦合到所述一个或多个数据源，并且其中，处理所述数据消息内的数据包括处理OPC数据。

21.根据权利要求20所述的监视过程的方法，其中，使用户能够通过指定多个逻辑规则来创建监视应用配置，所述多个逻辑规则定义要在过程中检测的一个或多个预定条件包括：使所述用户能够指定要由所述OPC接口检测的数据或事件的组合。

22.根据权利要求21所述的监视过程的方法，还包括使用所述运行时监视应用将所述OPC接口配置为：当所述OPC检测到由所述多个规则中的一个规则指定的数据或事件的组合时，将指示预定条件的数据消息发送到所述运行时应用。

23.根据权利要求19所述的监视过程的方法，还包括在处理器上实现工作流监视系统，所述工作流监视系统包括存储多个规则的规则数据库，其中，所述多个规则中的每个规则包括标识与过程内的一个或多个异常相关联的条件的逻辑，以及异常引擎，所述异常引擎使用所述规则数据库中的所述规则来处理来自工作流控制应用的数据消息内的数据，以确定是否存在由所述多个规则中的任何规则定义的异常，其中，所述异常引擎在基于所述规则中的一个规则识别出异常时将关于所述异常的信息作为异常记录存储在异常记录数据库中；以及

其中，将标识所述预定条件的所述消息发送到外部接收方包括将所述消息发送到所述工作流监视系统。

24.根据权利要求23所述的监视过程的方法，还包括使用所述规则数据库中的所述规则在所述异常引擎中处理标识所述预定条件的所述消息，以基于所述多个规则中的一个或多个规则来识别异常。

25.根据权利要求23所述的监视过程的方法，还包括将标识由所述运行时监视应用检测到的预定条件的消息存储在所述异常记录数据库中。

26.根据权利要求19所述的监视过程的方法，其中，将标识所述预定条件的所述消息发送到外部接收方包括：将所述消息发送到事件数据库，并且将所述消息存储在所述事件数据库中。

27.根据权利要求19所述的监视过程的方法，其中，将标识所述预定条件的所述消息发送到外部接收方包括：将所述消息发送到监视用户接口，并且经由所述监视用户接口向用户显示标识所述预定条件的所述消息。