DE112019002030T5

DE112019002030T5 - Qualitätsüberprüfungs-Verwaltungssystem mit konfigurierbaren Ausnahmeregeln

Info

Publication number: DE112019002030T5
Application number: DE112019002030.7T
Authority: DE
Inventors: Joshua Brian Kidd; Marcus S. Strangeway Orchard; Todd A. Cook
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc Emerson Process Us
Priority date: 2018-04-18
Filing date: 2019-04-18
Publication date: 2021-04-29
Also published as: US11726447B2; GB2597855B; JP2021119516A; JP7447211B2; CN112488512A; JP2022180480A; US20210019686A1; GB2590179B; WO2019204616A1; GB202016643D0; GB202209882D0; GB2609752A; GB2590538B; GB2609752B; GB2590160B; JP2023169228A; GB2590179A; GB202016013D0; JP2022180479A; JP2022188087A

Abstract

Ein Qualitätsprüfungsmanagementsystem kann dazu verwendet werden, den Betrieb von Herstellungsprozessen innerhalb einer Anlage basierend auf Daten zu analysieren, die von verschiedenen Datenquellen in der Anlage, wie z. B. Batch Executive-Anwendungen, gesammelt werden, um Ausnahmen innerhalb dieser Prozesse zur Verwendung durch einen Qualitätsprüfingenieur automatisch zu erkennen, zu speichern und anzuzeigen, um zu bestimmen, ob der Prozessvorgang bestimmten Qualitätsstandards entspricht. Das Qualitätsprüfungsmanagementsystem schließt eine Konfigurationsanwendung ein, mit der ein Benutzer eine oder mehrere Ausnahmeregeln erstellen kann, eine Ausnahme-Engine, die Prozessdaten unter Verwendung der Regeln analysiert, um eine oder mehrere Ausnahmen innerhalb des Prozesses zu erkennen, und eine Überprüfungsanwendung, die es Qualitätsprüfungsmitarbeitern ermöglicht, jede bestimmte Ausnahme zu Zwecken der Auflösung zu überprüfen.

Description

Verwandte Anmeldung
Diese Anmeldung beansprucht den Vorteil gemäß 35 U.S.C. § 119(e) der vorläufigen US-Patentanmeldung mit der Seriennummer 62/659,325 mit dem Titel „Quality Review Management System“, eingereicht am 18. April 2018, auf deren gesamte Offenbarung hiermit hierin ausdrücklich Bezug genommen wird.
Technologiegebiet
Die vorliegende Erfindung betrifft im Allgemeinen Fertigungsmanagementsysteme und insbesondere Qualitätsprüfungsmanagementsysteme, die hochentwickelte Qualitätsprüfungsverfahren in Bezug auf Betriebsvorgänge von Anlagen, Prozessen, Batches (Chargen) und anderen in Fertigungsanlagen implementierten Aktivitäten ermöglichen.
Beschreibung der verwandten Technik
Produktionsanlagen wie Prozessanlagen erzeugen typischerweise ein oder mehrere Produkte aus einer Reihe von Rohstoffen oder vorverarbeiteten Materialien. In vielen Fällen muss das erzeugte Produkt von einer bestimmten Qualität sein oder nach einem von verschiedenen Qualitätsstandards hergestellt werden, um Kundenanforderungen, Industriestandards, Anforderungen der US-Lebensmittelaufsichtsbehörde (Food and Drug Administration - FDA), Sicherheitsanforderungen, Kennzeichnungsanforderungen usw. zu erfüllen. In vielen Fällen ist es die Aufgabe separater Qualitätsprüfungsmitarbeiter, verschiedene Aktivitäten durchzuführen, um sicherzustellen, dass das erzeugte Produkt einer Reihe von zuvor festgelegten Standards oder Anforderungen entspricht oder nach einem bestimmten Standard hergestellt wurde. Solche Aktivitäten können das Überprüfen der Zustände oder der Werte verschiedener Parameter der Herstellungsausrüstung, -materialien oder -prozesse beinhalten, die zum Herstellen des Produkts verwendet werden, um sicherzustellen, dass geeignete Herstellungsschritte durchgeführt wurden, dass das Produkt unter verschiedenen wünschenswerten Bedingungen hergestellt wurde, beispielsweise innerhalb bestimmter Temperaturbereiche, pH-Bereiche, Druckbereiche usw. Natürlich hängen diese Qualitätsprüfungsaufgaben von der Art des hergestellten Produkts, dem Herstellungsprozess oder der zur Herstellung des Produkts verwendeten Ausrüstung, den Qualitätsstandards, die erfüllt werden, usw. ab. Die Qualitätsprüfung als solche ist eine hochspezialisierte Aktivität in vielen Fertigungsumgebungen, die genaue Kenntnisse des Produkts, des Herstellungsprozesses und der Qualitätsstandards erfordert.
Beispielsweise werden Batch-Prozesse typischerweise dazu verwendet, verschiedene Arten von Lebensmitteln oder Arzneimitteln herzustellen, die von verschiedenen Lebensmittel- und Arzneimittelindustrien oder -organisationen wie der FDA stark reguliert werden. Die spezifischen Prozessschritte und -bedingungen, unter denen diese Produkte hergestellt werden, werden typischerweise auf irgendeine Weise festgelegt oder geregelt, um die Sicherheit des erzeugten Produkts zu gewährleisten oder um sicherzustellen, dass das Produkt bestimmte Kennzeichnungskriterien erfüllt (z. B. dass das Produkt glutenfrei, koscher ist, usw.). Beispielsweise können die zur Herstellung eines Produkts verwendeten Prozessschritte erfordern oder vorschreiben, dass bestimmte Prozessschritte an den Rohstoffen oder Zwischenmaterialien während des Herstellungsprozesses implementiert werden, dass bestimmte Reinigungsverfahren an der Prozessausrüstung innerhalb der oder zwischen den Schritte(n) des Herstellungsprozesses implementiert werden, dass verschiedene Parameter wie Temperaturen, Drücke, pH-Ausgewogenheiten usw. während des gesamten Prozesses oder während kritischer Zeiten des Prozesses usw. in bestimmten Bereichen oder über oder unter bestimmten Schwellenwerten gehalten werden. In vielen Fällen muss der Produkthersteller daher Daten über den eigentlichen Betrieb der Fertigungsausrüstungen während des Herstellungsprozesses sammeln und speichern, um einer Regulierungsbehörde oder einem Kunden nachweisen zu können, dass das erzeugte Produkt den entsprechenden Qualitätsstandards entspricht, z. B. dass das Produkt nach zuvor festgelegten Verfahren oder unter solchen Bedingungen hergestellt wurde.
Prozessanlagen, mit denen verschiedene Arten von Produkten wie Lebensmittel, Erdöl, Arzneimittel usw. hergestellt werden, sind im Allgemeinen komplex und hoch automatisiert. Insbesondere beinhalten industrielle Prozessanlagen, wie sie in chemischen, Erdölraffinerie-, Lebensmittelherstellungs-, Arzneimittelherstellungs- oder anderen Prozessen verwendet werden, im Allgemeinen ein oder mehrere Prozesssteuerungsnetzwerke mit zentralisierten oder dezentralen Prozesssteuerungen, die kommunikativ mit einem oder mehreren Feldgeräten gekoppelt sind, wobei es sich beispielsweise um Ventilstellungsregler, Schalter, Sensoren (wie Temperatur-, Druck- und Durchflusssensoren), Tanks, Mischer, Heizungen usw. handeln kann. Diese Feldgeräte oder Feldausrüstungen können physische Steuerfunktionen innerhalb der Prozessanlage ausführen (z. B. das Öffnen oder Schließen eines Ventils, das Rühren oder Mischen von Materialien in einem Tank, das Erwärmen eines Behälters usw.), können Messungen innerhalb der Prozessanlage zum Steuern des Betriebs der Prozessanlage durchführen oder jede andere gewünschte Funktion innerhalb der Prozessanlage ausführen. Prozesssteuerungen wurden in der Vergangenheit über eine oder mehrere analoge Signalleitungen oder Busse mit Feldgeräten verbunden, die beispielsweise 4-20 mA-(Milliampere)-Signale zu und von den Feldgeräten übertragen können. In den letzten Jahrzehnten hat die Prozesssteuerungsbranche jedoch eine Reihe von Standardprotokollen für offene, digitale oder kombinierte digitale und analoge Kommunikation entwickelt, wie z. B. die Foundation™ FIELDBUS- (im Folgenden „Fieldbus“), HART^®-, PROFIBUS®-, WORLDFIP^®-, Device-Net^®- und CAN-Protokolle, mit denen die Kommunikation zwischen Prozesssteuerungen und Feldgeräten implementiert werden kann. Im Allgemeinen empfängt eine Prozesssteuerung Signale, die Messungen angeben, die von einem oder mehreren Feldgeräten durchgeführt wurden, und/oder andere Informationen zu Feldgeräten, verwendet diese Informationen, um eine typischerweise komplexe Steuerroutine zu implementieren, und generiert Steuersignale, die über die Signalleitungen oder -busse an die Feldgeräte gesendet werden, um dadurch den Betrieb der Prozessanlage zu steuern.
Bestimmte Arten von Prozesssteuerungsnetzwerken, wie sie beispielsweise in Batch-Prozessen verwendet werden, beinhalten typischerweise mehrere Sätze replizierter Ausrüstungen, wobei jeder Ausrüstungssatz so ausgelegt ist, dass er dieselbe oder eine ähnliche Hardware aufweist, die im Wesentlichen dieselbe Grundfunktion innerhalb der Prozessanlage ausführt. So kann beispielsweise eine Keksherstellungsanlage mehrere Sätze von Mischausrüstungen, mehrere Sätze von Backausrüstungen und mehrere Sätze von Verpackungsausrüstungen aufweisen, wobei einige oder alle einzelnen Mischausrüstungen parallel arbeiten und so verbunden werden können, dass sie in Reihe mit einigen oder allen Backausrüstungen und Verpackungsausrüstungen arbeiten. In einem solchen System ist es typisch, denselben allgemeinen Steueralgorithmus oder dieselbe Steuerroutine zu verwenden, um den Betrieb eines bestimmten Satzes von replizierten Ausrüstungen zu steuern, um dasselbe Produkt herzustellen (wie durch ein bestimmtes Batch-Rezept definiert). Somit kann jeder bestimmte Batchlauf, der durch einen Auftrag definiert ist, der eine bestimmte Menge eines bestimmten Produkttyps spezifiziert oder identifiziert, auf einer beliebigen Kombination von verschiedenen unterschiedlichen Ausrüstungssätzen in der Anlage implementiert werden. Typischerweise enthält jeder derartige Batchlauf oder Auftrag ein bestimmtes Steuerungsverfahren, das eine Reihe verschiedener Schritte oder Stufen nacheinander ausführt, um ein Rezept zu implementieren, wobei die erste Stufe vor Beginn der zweiten Stufe beendet wird, und so weiter. Somit kann in der vorstehend beschriebenen Keksherstellungsanlage ein Batchlauf oder Auftrag ein Batch-Steuerungsverfahren implementieren, um die Mischausrüstung zu steuern, kann dann ein Verfahren implementieren, um die Backausrüstung mit dem von der Mischausrüstung hergestellten Produkt zu betreiben, und kann dann ein drittes Verfahren ausführen, das die Verpackungsausrüstung steuert, um das von der Backausrüstung erzeugte Produkt zu verpacken, wobei jeder Schritt einen begrenzten Zeitraum in Anspruch nimmt. In vielen Fällen werden bei einem Batchlauf auch Verfahren zum Reinigen, Entleeren, Befüllen usw. von Tanks oder anderen Behältern oder Ausrüstungen in der Anlage als Teil jedes Auftrags implementiert. Natürlich kann jeder Auftrag einen anderen Satz von Spezifikationen aufweisen, was erfordern kann, dass ein anderer Satz von Rohstoffen, ein anderes Rezept, andere Fluss- oder Batchverfahren für die Rohstoffe und sogar verschiedene Qualitätsstandards implementiert werden.
Ein Batch-Steuerstandard, der von der Internationalen Gesellschaft für Mess- und Regeltechnik, einer internationalen Organisation, die sich mit Fragen der Prozesssteuerung befasst, veröffentlicht wurde, trägt den Titel „Batch Control Part 1: Models and Terminology“ und wird häufig als ISA S88.01-1995 Standard oder eine seiner Aktualisierungen bezeichnet (hier als „S88 Standard“ bezeichnet). Der S88-Standard definiert Modelle von Ausrüstungen und Verfahren zur Verwendung in automatisierten Batch-Prozessen und definiert eine bestimmte Terminologie für die Bezeichnung dieser Modelle und deren Elemente. Zum Beispiel definiert der S88-Standard einen „Batch-Prozess“ als einen Prozess, der zur Produktion begrenzter Materialmengen führt, indem Mengen von Eingangsmaterialien einer geordneten Reihe von Verarbeitungsaktivitäten über einen begrenzten Zeitraum unter Verwendung eines oder mehrerer Ausrüstungsteile unterzogen werden. Als weiteres Beispiel wird ein „Batch“ durch den S88-Standard als das Material definiert, das durch eine einzelne Ausführung eines Batch-Prozesses erzeugt wird oder erzeugt wurde.
Wie vorstehend erwähnt, werden Batch-Verarbeitungsausrüstungen (z. B. steuerbare Elemente wie Ventile, Heizungen, Mischer usw.) während eines Batch-Prozesses oder eines Batchlaufs gemäß vordefinierter Verfahren zur Herstellung eines Batches betrieben. Alle derartigen Batch-Verarbeitungsausrüstungen werden hier synonym als Ausrüstungen, Ausrüstungsmodule, Verarbeitungsausrüstungen und/oder physische Elemente bezeichnet.
Die Verfahren zum Betrieb solcher physischen Elemente werden vom S88-Standard häufig als „Verfahrensmodell“ bezeichnet. Gemäß dem S88-Standard ist das Verfahrensmodell als hierarchische Rangfolge von Verfahren strukturiert, wobei die höchste Ebene jede der niedrigeren Ebenen umfasst, die nächsthöhere Ebene jede der darunter liegenden Ebenen umfasst und so weiter. Die Ebenen des S88-Verfahrensmodells von besonderem Interesse beinhalten in absteigender Reihenfolge „Verfahren“, „Teilverfahren“, „Vorgänge“ und „Phasen“. Die Begriffe „Verfahrenselement“ oder Batch-Unterverfahren werden hier verwendet, um sich auf eine Ausführungsform oder Implementierung von einer dieser Ebenen des S88-Verfahrensmodells sowie auf eine andere hierarchische Definition einer Reihe von Batchverfahren zu beziehen.
Wie vorstehend angegeben, wird das interessierende S88-Verfahrenselement der höchsten Ebene als Verfahren bezeichnet, das aus einem oder mehreren Teilverfahren besteht. Jedes Teilverfahren besteht oder kann wiederum bestehen aus einem oder mehreren Vorgängen, die jeweils aus einer oder mehreren Phasen bestehen. Darüber hinaus schließt das S88-Verfahrensmodell die Definition und Verwendung anderer Hierarchieebenen in bestimmten Anwendungen nicht aus. Vielmehr sollen der S88-Standard und die hier genannten Verfahrenselemente ein breites, standardisiertes Modell zur Beschreibung der bei der automatisierten Batch-Prozesssteuerung angewendeten Verfahren bereitstellen, und diese Elemente sind nicht auf die vier durch den S88-Standard definierten Verfahrenselemente beschränkt.
Die verschiedenen Verfahrenselemente eines Batches werden in der Praxis im Allgemeinen als Computerprogramme implementiert, die von und innerhalb von Datenverarbeitungsgeräten einschließlich Personalcomputern, Arbeitsstationen und programmierbaren Steuerungen ausgeführt werden. Die Ausführung eines typischen Verfahrenselements führt zu einem elektrischen oder optischen Ausgang von dem Datenverarbeitungsgerät, der zur Steuerung eines physischen Elements verwendet werden kann, typischerweise durch Verbinden eines Ausgangs des Datenverarbeitungsgeräts mit dem physischen Element direkt, oder indirekt über ein lokales Netzwerk (LAN) und/oder Weitverkehrsnetzwerk (WAN). Ein Verfahrenselement führt eine zugewiesene oder zugeordnete Aufgabe aus, indem es eine „grundlegende Steuerung“ in Bezug auf mindestens ein physisches Element aufruft. Diese Art von Steuerung dient typischerweise dazu, einen bestimmten gewünschten Zustand des physischen Elements herzustellen und aufrechtzuerhalten. Eine grundlegende Steuerung würde zum Beispiel das Starten oder Aufrechterhalten eines Materialflusses in einem Lagerbehälterelement, das Erwärmen der Ausgangsmaterialien in einem Polyvinylchlorid-Reaktorelement usw. beinhalten. In der Praxis führen die niedrigeren Ebenen des Verfahrensmodells (nämlich Phasen) die eigentliche Kommunikation mit den tatsächlichen physischen Elementen aus, wodurch eine grundlegende Steuerung aktiviert oder durchgeführt wird. Die höheren Ebenen des Verfahrensmodells sind im Wesentlichen Abstraktionen zur Verbesserung der Organisation und Struktur des Verfahrensmodells sowie des physischen Modells.
Darüber hinaus verwenden viele Batch-Systeme einen Batch Executive, um den Betrieb eines oder mehrerer Batches in einer Anlage gemäß dem verwendeten Verfahrensmodell zu steuern. Der Batch Executive kann ein Zustandsmaschinenmodell als logisches Konstrukt sein oder verwenden, um den Zustand eines Batch-Prozesses oder einer Batch-Aktivität zu beschreiben. Das Zustandsmaschinenmodell beschreibt oder definiert eine Reihe von Prozesszuständen zusammen mit Aktionen, die Übergänge zwischen diesen Zuständen bewirken. Ein Zustandsmaschinenmodell eines Prozesses soll sich aufgrund eines vorherigen Übergangs in einen bestimmten Zustand in diesem Zustand befinden. Wenn ein bestimmtes Ereignis eintritt oder ein bestimmter Status erfasst wird, wechselt das Zustandsmaschinenmodell in einen anderen Zustand, der dem bestimmten Ereignis oder dem erfassten Status entspricht. Zustandsmaschinenmodelle sind nützliche Techniken zum Definieren und Implementieren des Betriebs von Verfahrenselementen eines Batch-Prozesses. Insbesondere initiiert ein als Zustandsmaschine definiertes und implementiertes Verfahrenselement eine Aktion, beispielsweise wenn die zugeordnete Zustandsmaschine von einem alten Zustand in einen neuen Zustand übergeht.
Natürlich ermöglicht der S88-Standard die Definition und Implementierung von Verfahrenselementen gemäß einem Standard-Zustandsmaschinenmodell. Während der S88-Standard diesen Ansatz nicht vorschreibt, wurde dieser Ansatz in der Prozesssteuerungsbranche weitgehend übernommen, um ein höheres Maß an Interoperabilität zwischen den Produkten verschiedener Anbieter zu ermöglichen. Eine derzeitige kommerzielle Anwendung des S88-Standards mit Verfahrenselementen, die gemäß einem Zustandsmaschinenmodell definiert und implementiert wurden, ist das DeltaV™ Batch-Produkt von Emerson Process Management. Im DeltaV™ Batch wird ein Serverprogramm oder ein Batch Executive-Programm auf dem Datenverarbeitungsgerät ausgeführt, das die verschiedenen Verfahrenselemente ausführt. Das Server- oder Batch Executive-Programm (als „Batch Executive“ bezeichnet) koordiniert die Ausführung von Verfahrenselementen gemäß einem oder mehreren Zustandsmaschinenmodellen, so dass Verfahren, entsprechende Teilverfahren, entsprechende Vorgänge und entsprechende Phasen vom Serverprogramm durch deren jeweilige Schritte hindurch sequenziert werden. In jedem Fall kommuniziert die Phase während der Implementierung eines bestimmten Batchlaufs oder eines bestimmten Batch-Prozesses, der einem Auftrag zugeordnet ist, beispielsweise wenn eine Phase vom Serverprogramm initiiert wird, die Initiierungsanforderung an die Phasenlogikschnittstelle innerhalb einer programmierbaren Steuerung. Die programmierbare Steuerung führt dann die aktuelle Zustandslogik oder Steuerroutine für die Phase aus und stellt die erforderliche Prozesssteuerung über die Kommunikation mit der Prozessausrüstung bereit.
Wie aus der vorherigen Erörterung bezüglich der Qualitätsprüfung von Prozessen hervorgeht, ist es wünschenswert, Daten zu erheben, die für den Betrieb eines Batch-Prozesses repräsentativ sind, einschließlich historischer Ereignisse, aus denen die Verarbeitung eines Batchlaufs bestehen, um bestimmen zu können, ob der Batchlauf für einen Auftrag gemäß den geltenden Qualitätsstandards zufriedenstellend betrieben oder ausgeführt wurde. Solche historischen Daten können nicht nur zur Qualitätsprüfung nützlich sein, sondern auch zum Bestimmen von Trends bei der Qualitätskontrolle oder zum Bestimmen, wann Ausrüstungen, die im Batch-Prozess verwendet werden, gewartet werden müssen. Eine Reihe von Datentypen ist möglicherweise nützlich, um die Qualität oder den Fortschritt eines Batch-Prozesses zu überprüfen. Eine solche Datenquelle sind kontinuierliche Daten, die von den verschiedenen Datenpunkten im Batch-Prozess während der Verarbeitung des Batches generiert werden. Ein Datenpunkt ist eine einzige Quelle für solche kontinuierlichen Daten, die einen Steuerwert oder einen anderen Status oder eine Maßzahl für den Batch-Prozess widerspiegeln. Beispielsweise können eine bestimmte Ebene eines Materialflusses oder eine Temperatur eines Materials, wie sie von einem Sensor gemessen wird, solche Datenpunkte sein. Eine derzeitige Einstellung eines Steuerventils, der Zeitpunkt, zu dem eine Probe entnommen wurde usw. können weitere Datenpunkte sein. Jeder derartige Datenpunkt kann einen kontinuierlichen Strom von Datenwerten aufweisen, die über die Zeit von der ihm zugeordneten Batch-Prozessanwendung erfasst oder gesteuert werden. Die Aggregation all dieser kontinuierlichen Daten, die während der Verarbeitung eines Batches generiert werden, wird häufig von einem Batch-Verarbeitungssystem protokolliert und als Teil einer Batch-Protokolldatei in einer Batch-Datenbank gespeichert. Diese Batch-Protokolldatensätze enthalten normalerweise einen Zeitstempel und einen derzeitigen Wert sowie weitere identifizierende Informationen für den Datenpunkt, wie z. B. ein Tag zum Identifizieren der Datenquelle.
Eine andere Art von Daten, die zum Überprüfen der Qualität oder des Fortschritts eines Batch-Prozesses nützlich sind, sind Batch-Zustands- und Ereignisinformationen, die sich auf Informationen beziehen oder diese enthalten, die den Batch-Prozess im Hinblick auf die Ausführung des Verfahrensmodells beschreiben (z. B. den Zustand des Batch-Prozesses, Übergänge zwischen Zuständen des Batchmodells usw.). Beispielsweise bilden Batch-Ereignisse, die die Start- und Endzeit einer bestimmten Phase oder eines bestimmten Vorgangs, eines Teilverfahrens oder Verfahrens des Verfahrensmodells beschreiben, Ereignisinformationen. Ereignisinformationen beinhalten auch Prozessereignisse, einschließlich Informationen, die von den physischen Elementen des Batch-Prozesses oder von einem Bediener generiert werden. Insbesondere kann jedes Ausrüstungsmodul, jede Zelle usw. eines Prozesses Prozessereignisse generieren, die eine oder mehrere spezifische Aktivitäten beim Starten, Stoppen oder Ausführen einer bestimmten Phase angeben (d. h. Ausführen spezifischer grundlegender Steuerungsaktionen). Von der Prozessausrüstung erkannte Alarm- und Ereignisbedingungen sind weitere Beispiele für Prozessereignisse. Prozessereignisse können auch Informationen zu bedienerseitigen Änderungen am Batch-Prozess enthalten, die während des Betriebs des Batch-Prozesses vorgenommen wurden.
Darüber hinaus verwenden viele Batch-Prozesssysteme ein Bedienerschnittstellenprogramm, das auf einem dedizierten Bedienerschnittstellengerät wie einer Arbeitsstation betrieben wird, damit ein Bediener den aktuellen Zustand eines Batchlaufs anzeigen und manuelle Schritte innerhalb des Batchlaufs ausführen kann, z. B. manuelles Einstellen verschiedener Parameter, Auswählen von Prozessausrüstungen für die Ausführung verschiedener Batchverfahren, Vorgängen, Phasen usw., Hinweise zu unerwarteten Aktivitäten oder Bedingungen während eines Batchlaufs oder Auftrags usw. Ein solches Bedienerschnittstellenprogramm ist als Workflow-Programm bekannt (wie das von Emerson Automation Solutions bereitgestellte Syncade Workflow-Programm), das verschiedene Informationen vom Batch Executive oder der Prozessausrüstung (z. B. Prozesssteuerungen) abfängt oder empfängt, die zum Implementieren eines Batchlaufs für jeden zu verarbeitenden Auftrag verwendet werden. Die Workflow-Programme können verschiedene Arten von Daten vom Batch Executive oder Prozesssteuerungssystem abonnieren und können diese Daten dem Bediener darstellen, damit der Bediener den aktuellen Zustand des Batchlaufs anzeigen, Übergänge zwischen Zuständen im Batch-Modell anzeigen, Änderungen im Batchlauf vornehmen, verschiedene Batchverfahren, Vorgänge, Phasen oder Ausrüstungen manuell stoppen und starten sowie Probleme oder unerwartete Ereignisse beheben kann, die innerhalb eines Batchlaufs auftreten. In vielen Fällen können beispielsweise unerwartete Fehler oder Probleme innerhalb eines Batchlaufs auftreten, z. B. dass Batch-Ausrüstungen oder -Rohstoffe unerwarteter Weise nicht verfügbar sind, Prozessparameter außerhalb eines erwarteten oder gewünschten Bereichs liegen usw. In diesen Fällen ermöglicht es das Workflow-Programm dem Bediener, Entscheidungen über das weitere Vorgehen zu treffen und umzusetzen, z. B. Überspringen eines Batch-Schritts oder -Verfahrens, Vorgeben anderer zu verwendender Ausrüstungen oder Materialien, Ändern von Prozessanlagenvariablen, Sollwerten oder Parametern zum Beheben von Alarmen oder Ereignissen im Prozess usw. Im Allgemeinen speichert das Workflow-Programm auch Daten, die auf Bedieneraktionen hinweisen, in der Batch-Protokolldatei, zusammen mit den Batch-Rohdaten, die in der Batch-Protokolldatei gespeichert werden. In vielen Fällen ermöglicht das Workflow-Programm dem Bediener auch, Hinweise zu geben oder Erläuterungen darüber zu speichern, was zum Zeitpunkt der Aktion im Batch geschehen ist, warum der Bediener die bestimmte Aktion ausgeführt hat usw., und diese Hinweise werden ebenfalls in der Batch-Protokolldatei gespeichert.
In vielen Branchen muss ein Qualitätsingenieur oder anderer Qualitätsmitarbeiter (hier allgemein als Qualitätsingenieure bezeichnet) nach Durchführung eines Batchlaufs und Fertigstellung eines Produkts oder eines Auftrags verifizieren, ob das Produkt den entsprechenden Qualitätsstandards entspricht. Um diese Überprüfung durchzuführen, greift der Qualitätsingenieur auf die Batch-Protokolldatei für den Batchlauf eines Auftrags zu und zeigt diese an (normalerweise auf Auftragsbasis), um sicherzustellen, dass der Batchlauf gemäß oder innerhalb der erwarteten Parameter, Workflows und Bereiche geschlossen wurde. Um diese Überprüfung durchzuführen, muss der Qualitätsingenieur im Allgemeinen durch die Rohdaten in der Batch-Datendatei scrollen und nach „Ausnahmen“ für den erwarteten Betrieb des Batchlaufs suchen. Der Begriff „Ausnahme“ wird hier allgemein verwendet, um eine Abweichung von einem erwarteten Verfahren, Prozess, Schritt, Arbeitsablauf, Bereich, Wert usw. innerhalb eines Herstellungsprozesses oder einer Anlage anzugeben. Ausnahmen können beispielsweise sein, dass eine oder mehrere Prozessvariablen oder -parameter außerhalb eines erwarteten oder gewünschten Bereichs oder über oder unter erwarteten oder gewünschten Schwellenwerten liegen, dass ein Batchverfahren, eine Operation oder Phase übersprungen oder außerhalb einer erwarteten Sequenz ausgeführt wird; eine Operation oder Phase zu unerwarteten Zeiten gestoppt oder gestartet wird oder länger oder weniger lang als eine erwartete Betriebszeit dauert, andere oder unerwartete Materialien in einem Batchverfahren verwendet werden, zusätzliche Schritte oder Aktionen vom Bediener während des Batchlaufs ausgeführt werden, Änderungen an einem Rezept, vom Bediener während eines Batchlaufs generierte Hinweise, Alarme und Ereignisse, die während eines Batchlaufs aufgetreten sind usw.
In jedem Fall muss der Qualitätsingenieur die Ausnahmen anhand der in der Batch-Protokolldatei gespeicherten Rohdaten identifizieren, dann eine Auswirkung oder den Schweregrad jeder dieser Ausnahmen bestimmen, ebenso wie welche - wenn überhaupt - Verfahren zur Behandlung oder zum „Schließen“ der Ausnahme erforderlich sind. Beispielsweise können Ausnahmen in vielen Fällen nur minimale oder unwichtige Abweichungen im erwarteten Batchlauf repräsentieren, die zu keiner oder keiner signifikanten Qualitätsminderung des erzeugten Produkts gemäß den implementierten Qualitätsstandards führen. In anderen Fällen müssen Ausnahmen möglicherweise für eine spätere Überprüfung durch autorisierte Agenturen oder durch den Kunden dokumentiert werden, deren Auswirkungen jedoch möglicherweise nicht schwerwiegend genug sind, um die Qualität des Produkts erheblich zu beeinträchtigen. In noch anderen Fällen kann die Ausnahme signifikant oder wichtig genug sein, dass das Produkt einem oder mehreren zusätzlichen Verfahren unterzogen werden muss, um die gewünschte Qualität sicherzustellen, oder um zu erfordern, dass ein oder mehrere Tests am Produkt durchgeführt werden, um die Qualität des Produkts sicherzustellen. In noch anderen Fällen kann der Qualitätsingenieur aufgrund der Besonderheiten der Ausnahme feststellen, dass das Produkt verschrottet werden muss oder dass das Produkt unter einem niedrigeren Qualitäts- oder Kennzeichnungsstandard vermarktet werden muss.
Der Prozess des Durchsuchens einer Batch-Protokolldatei nach Ausnahmen ist äußerst mühsam und mit Problemen behaftet. Insbesondere weisen die meisten Daten in der Batch-Protokolldatei nicht auf eine Ausnahme hin; daher verbringt der Qualitätsingenieur einen erheblichen Teil (normalerweise den größten Teil) der Überprüfungszeit damit, Daten zu untersuchen, die eigentlich keiner Ausnahme zugeordnet sind. Darüber hinaus muss der Qualitätsingenieur alle Bedingungen berücksichtigen, die zu einer Ausnahme führen, einschließlich beispielsweise gewünschter Werte oder Bereiche wichtiger Prozessvariablen, der erwarteten Reihenfolge von Batchverfahren, der erwarteten Stopp- und Startzeiten für verschiedene Batch-Verfahren usw. Während das Vorhandensein von Batch-Prozessalarmen und -Warnungen oder Bedienerhinweisen, die in der Batch-Protokolldatei gespeichert sind, möglicherweise auf das Vorhandensein einer Ausnahme hinweist, ist dies nicht immer der Fall und natürlich ist unter Umständen nicht jede auftretende Ausnahme mit einem Bedienerhinweis dokumentiert oder steigt auf einen Wert an, der dazu führt, dass im Steuerungssystem ein zugeordneter Alarm oder eine zugeordnete Warnung generiert wird. Es versteht sich daher, dass die tatsächlichen Ausnahmen, die bestimmt werden, von den Fähigkeiten des jeweiligen Qualitätsingenieurs abhängen, der die Überprüfung durchführt, und von der Einhaltung der jeweiligen Qualitätsstandards.
Wenn der Qualitätsingenieur eine Ausnahme findet (z. B. wenn ein Prozesswert außerhalb des zulässigen Bereichs liegt usw.), muss der Ingenieur normalerweise den Kontext des Batches zum Zeitpunkt der Ausnahme bestimmen, um den Schweregrad der Ausnahme zu bestimmen und wie am besten auf die Ausnahme zu reagieren oder diese zu behandeln ist. Dieser Prozess kann das Erhalten zusätzlicher Daten über den Zustand des Batchlaufs oder des Batchverfahrens zum Zeitpunkt der Ausnahme sowie über Werte anderer Prozessvariablen zum Zeitpunkt der Ausnahme beinhalten, wobei bestimmt wird, ob zum Zeitpunkt der Ausnahme Alarme oder Ereignisse in derselben oder einer anderen Prozessausrüstung generiert wurden usw. Bei diesem Prozess muss der Qualitätsingenieur dann im Allgemeinen andere verfügbare Datenzugriffssysteme verwenden, um die zusätzlichen Prozess-Zustandsinformationen zum Zeitpunkt der Ausnahme zu bestimmen. Diese Datenerfassungsaktivität kann zeitaufwändig sein und erfordert zusätzliches Knowhow seitens des Batch-Qualitätsingenieurs.
Um beispielsweise den Betrieb eines Batches aus einer Batch-Protokolldatei anzuzeigen, ist es keine einfache Aufgabe, einen Speicherauszug des Batch-Prozesses zu einem bestimmten Zeitpunkt zu erhalten und diese Daten einem Qualitätsingenieur anzuzeigen, da der Batch-Prozess verschiedene unterschiedliche Verfahrenselemente aufweist, die zu unterschiedlichen Zeiten mit unterschiedlichen Sollwerten, Einstellungen usw. auf unterschiedlichen Ausrüstungen innerhalb der Anlage ausgeführt werden können. Um einen Batchlauf anzuzeigen, muss der Qualitätsingenieur stattdessen möglicherweise zu verschiedenen mit den Verfahrensereignissen des Batches in Zusammenhang stehenden Zeitpunkten (d. h. die dem Batch zugeordneten Unterverfahren und Unterprozesse) Daten aus dem Batch überprüfen und analysieren, um dadurch den Betrieb der Batchlaufs zum Zeitpunkt der Ausnahme verstehen zu können. Während verschiedene Batchdaten normalerweise automatisch während des Betriebs des Batchlaufs gesammelt und gespeichert werden, werden diese verschiedenen Datentypen im Allgemeinen von verschiedenen Subsystemen gesammelt und können tatsächlich in verschiedenen Datenbanken gespeichert werden. Dieser Umstand erschwert es dem Qualitätsingenieur, eine umfassende Ansicht von einem bestimmten Batch-Prozess zu erhalten. Beispielsweise werden Daten wie Alarmdaten und Sensormessdaten, die von tatsächlichen Feldgeräten wie Sensoren, Ventilen usw. innerhalb des Batch-Prozesses erhalten werden, typischerweise in einem Datenhistoriker als Zeitstempeldaten gespeichert und sind vom Datenhistoriker im Allgemeinen basierend auf dem Zeitpunkt verfügbar, zu dem die Daten gesammelt wurden. Eine andere Datenbank, beispielsweise eine, die einer Batch Executive-Routine zugeordnet ist, kann jedoch die Start- und Endzeiten eines Batchlaufs und die verschiedenen Unterverfahren oder Verfahrenselemente innerhalb des Batchlaufs speichern. Dies alles erschwert es dem Qualitätsingenieur, den Kontext einer Ausnahme ohne signifikante Datenrecherche in verschiedenen anderen Subsystemen des Batch-Prozesses zu verstehen.
Kurzdarstell ung
Ein Qualitätsprüfungsmanagementsystem (auch als RBE-(Review by Exception)-System bezeichnet) kann verwendet werden, um den Betrieb eines oder mehrerer Herstellungsprozesse zu analysieren, die von verschiedenen anderen Prozessanlagen-Datenquellen wie Datenquellen innerhalb eines Prozesssteuerungssystems, Workflow-Anwendungen, Batch-Prozess-Bediener-Anwendungen, Batch Executive-Anwendungen usw. gesammelt werden. Das Qualitätsprüfungsmanagement-System erkennt automatisch Ausnahmen innerhalb dieser Prozesse und speichert Daten zu den erkannten Ausnahmen auf organisierte und leicht überprüfbare Weise. Das Qualitätsprüfungsmanagementsystem ermöglicht es einem Qualitätsprüfungsmanager oder -ingenieur auch, dem Prozess zugeordnete Ausnahmen in einer benutzerfreundlichen Schnittstelle zu überprüfen und zu behandeln (aufzulösen).
Insbesondere beinhaltet das Qualitätsprüfungsmanagementsystem ein Konfigurationssystem, mit dem ein Benutzer Regeln in einer Regeldatenbank erstellen und speichern kann, mit denen eine oder mehrere Ausnahmen innerhalb eines Prozesses, z. B. eines Batch-Prozesses, automatisch identifiziert werden können. Die Regeln können eine Reihe von Bedingungen identifizieren, die erfüllt sein müssen, um eine Ausnahme, den Schweregrad der identifizierten Ausnahme, Informationen über die Ausnahme, Prozesse oder Verfahren, die zum Behandeln, Auflösen oder Schließen der Ausnahme dienen, Prozessdaten oder andere zu verwendende Daten, die als Teil eines Ausnahmedatensatzes gespeichert werden müssen, um einen Qualitätsprüfungsingenieur beim Verstehen und Auflösen der Ausnahme usw. zu unterstützen, zu identifizieren. Das Qualitätsprüfungsmanagementsystem enthält auch eine Ausnahme-Engine, die Daten in einer Datennachricht verarbeitet, z. B. eine Datennachricht, die regelmäßig durch eine Datenquelle bereitgestellt wird, wie ein Anlagen- oder Prozesssteuerungssystem, einen Batch Executive, eine Bediener-Workflow-Anwendung usw., die die Regeln in der Regeldatenbank dazu verwendet, zu bestimmen, ob die Daten innerhalb der Datennachricht eine Ausnahme enthalten, wie sie durch eine der Regeln definiert ist. Die Ausnahme-Engine kann dann nach dem Identifizieren einer Ausnahme Informationen über die Ausnahme als Ausnahmedatensatz speichern, wie z. B. einen Namen, einen Typ, einen Schweregrad von Verfahren oder Schritten, die zum Auflösen oder Behandeln der Ausnahme erforderlich sind, und Daten zum Betrieb des Prozesses verarbeiten, in dem die Ausnahme zum Zeitpunkt des Auftretens der Ausnahme aufgetreten ist. Die Ausnahme-Engine kann diese und/oder andere Daten für jede identifizierte Ausnahme als Ausnahmedatensatz in einer Ausnahmedatei (z. B. einer Ausnahmedatenbank) für jeden Auftrag speichern. Darüber hinaus kann die Ausnahme-Engine während des Betriebs des Prozesses in Echtzeit arbeiten, wobei sie einen Auftrag zum Erstellen einer Ausnahmedatei oder -datenbank für den Auftrag implementiert, und kann einem Prozessbediener Live-Feedback geben, dass eine Ausnahme aufgetreten ist oder in Kürze auftreten wird.
In einem Beispiel bietet das Qualitätsprüfungssystem daher eine Konfigurationsumgebung, mit der ein Benutzer konfigurierbare Ausnahmeregeln erstellen kann, die in einer Ausnahme-Engine ausgeführt werden können, um Ausnahmen zu definieren oder zu erkennen. Die Konfigurationsumgebung kann einen Satz von Regelvorlagen speichern, die verschiedene Arten von Eingangsdaten verarbeiten können, um eine Ausnahme zu erkennen. In der Konfigurationsumgebung kann ein Benutzer eine der Vorlagen auswählen, Ein-/Ausgänge definieren und einen möglichen Ausdruck definieren, der für einen Satz von Daten analysiert werden soll. Wenn die Daten durch die Engine fließen, wird diese die Daten anhand der konfigurierten Regeln analysieren; wenn die Kriterien einer Regel erfüllt sind, wird eine Ausnahme erstellt. Die Ausnahme kann dann sofort geprüft werden. Typische bekannte Review-by-Exception-Produkte erfordern, dass der Ausnahme-Softwareanbieter die für das System definierten Ausnahmen fest in das Produkt codiert und daher eine Software- oder Systemaktualisierung benötigt, um neue Ausnahmen zu erstellen. Für das Abrufen und Installieren dieser Aktualisierungen benötigt der Benutzer Zeit, und Benutzer können ihre eigenen Systeme nicht selbst anpassen.
Das Qualitätsprüfungsmanagementsystem enthält auch eine Überprüfungsschnittstelle, über die ein Qualitätsprüfungsingenieur oder andere -mitarbeiter Ausnahmen überprüfen und beheben können, wie sie von der Ausnahme-Engine identifiziert und als Ausnahmedatensätze in einer Ausnahmedatenbank für einen Auftrag gespeichert wurden. Insbesondere kann die Überprüfungsschnittstelle für einen bestimmten Auftrag auf eine Ausnahmedatenbank zugreifen und dem Qualitätsprüfungsingenieur auf organisierte und leicht verständliche Weise Informationen zu jeder identifizierten Ausnahme darstellen. Die Überprüfungsschnittstelle kann dem Qualitätsprüfungsingenieur Daten bereitstellen, die für jeden Ausnahmedatensatz gespeichert sind, wie beispielsweise einen Namen, einen Typ und eine Schweregradidentifikation für jeden Ausnahmedatensatz. Die Überprüfungsschnittstelle kann dem Prüfer gespeicherte Informationen über die Ausnahme bereitstellen, wie sie durch den Ausnahmedatensatz, die Art der Ausnahme usw. identifiziert werden, sowie Daten zu verschiedenen Prozess- oder Batchvariablen, Zuständen, Verfahren usw., die zu dem Zeitpunkt, zu dem die Ausnahme aufgetreten ist, vorhanden waren. Mithilfe dieser Informationen kann der Prüfer die Ausnahme, den Kontext des Prozesses zum Zeitpunkt des Auftretens der Ausnahme und den Schweregrad der Ausnahme leicht verstehen. Darüber hinaus kann es die Überprüfungsschnittstelle dem Prüfer ermöglichen, verschiedene Aktionen in Bezug auf jede Ausnahme auszuführen. Solche Aktionen können das Bestätigen der Ausnahme, das Freigeben oder Schließen der Ausnahme, das Versehen der Ausnahme mit Anmerkungen mit weiteren Informationen, z. B. warum die Ausnahme ignoriert oder freigegeben werden kann, das Senden des Ausnahmedatensatzes an eine andere Person usw. beinhalten. Die Überprüfungsschnittstelle kann auch dem Prüfer vorgeschlagene Aktionen bereitstellen und kann in einigen Fällen bestimmte Aktionen erzwingen, die im Hinblick auf das Auflösen oder Schließen der Ausnahme vorzunehmen sind. Solche Aktionen können beispielsweise u. a. die Freigabe durch eine bestimmte Anzahl oder Art von Personen (z. B. den Prüfer allein, den Prüfer und einen Manager, zwei Prüfer usw.) erfordern. Andere Aktionen können u. a. das Bereitstellen bestimmter Informationen vom Prüfer beinhalten, z. B. Anmerkungen, Prozessinformationen usw., die mit dem Ausnahmedatensatz zur späteren Verwendung durch den Kunden, die Qualitätsprüfungsbehörden usw. gespeichert werden.
Die Überprüfungsschnittstelle kann die verarbeiteten Ausnahmedatensätze in einer Datenbank oder Datei speichern und es dem Prüfer ermöglichen, durch die Ausnahmedatensätze in der Ausnahmedatenbank zu scrollen, um zu bestimmen, ob und wann alle Ausnahmedatensätze für einen Auftrag verarbeitet oder geschlossen wurden, sowie den Status der Überprüfung (z. B. wie viele unverarbeitete Ausnahmen in der Ausnahmedatensatz-Datenbank vorhanden sind), statistische Daten zu den Ausnahmedatensätzen (z. B. wie viele Ausnahmen jedes Typs oder Schweregrads in der Datei vorhanden sein können usw.) zu bestimmen. Die Überprüfungsschnittstelle kann es dem Prüfer auch ermöglichen, Ausnahmedatensätze auf verschiedene Arten, z. B. nach Typ, Schweregrad, Verarbeitungsstatus (z. B. nicht überprüft, überprüft, aber nicht geschlossen, geschlossen usw.) zu gruppieren. Darüber hinaus kann es die Überprüfungsschnittstelle dem Prüfer ermöglichen, eine oder mehrere Aktionen an einer gesamten Gruppe von Ausnahmedatensätzen auszuführen, z. B. das Schließen aller Ausnahmedatensätze in einer Gruppe, das Versehen aller Ausnahmedatensätze in einer Gruppe mit Anmerkungen usw.
Auf diese Weise kann das Qualitätsprüfungsmanagementsystem während des Betriebs eines Batch-Prozesses oder eines anderen Prozesses eingerichtet (konfiguriert) und ausgeführt werden, um Ausnahmen automatisch zu identifizieren, wie sie innerhalb eines Prozesslaufs auftreten, einen Prozessbediener informieren, dass eine Ausnahme aufgetreten ist oder dass eine vom Prozessbediener ausgeführte Aktion zu einer Ausnahme führen wird, und kann alle bestimmten Ausnahmen für einen bestimmten Prozess (z. B. einen Batch-Prozess) in einer Ausnahmedatensatz-Datenbank speichern. Das Qualitätsprüfungsmanagementsystem ermöglicht es einem Qualitätsprüfungsingenieur auch, die Ausnahmen in einer Ausnahmedatenbank schnell zu bestimmen, anzuzeigen und zu beheben, ohne wie derzeit erforderlich eine Menge Rohdaten überprüfen zu müssen. Ebenso kann das Qualitätsprüfungsmanagementsystem verschiedene Regeln im Ausnahmebehandlungs- oder Auflösungsprozess erzwingen, beispielsweise sicherstellen, dass Ausnahmen verschiedener Arten oder Schweregrade auf eine bestimmte Weise verarbeitet oder behoben werden, wodurch Konsistenz im Qualitätsprüfungsprozess gewährleistet wird.
Darüber hinaus kann das Qualitätsprüfungsmanagementsystem in einer Plug-in-Umgebung implementiert werden, damit das System dazu verwendet werden kann, mit Systemen oder Anwendungen von Drittanbietern eine Schnittstelle zu bilden und sie auf Ausnahmen zu analysieren. In einem Fall kann ein Plug-in erstellt oder dazu konfiguriert werden, bestimmte Daten von einer Drittanbieteranwendung oder -datenquelle zu erhalten, und kann diese Daten dann zur Verarbeitung durch eine oder mehrere Ausnahmeregeln an eine Ausnahme-Engine übergeben. Beispielsweise kann das Qualitätsprüfungsmanagementsystem dazu verwendet werden, eine Schnittstelle mit Ereignisüberwachungssystemen zu bilden, wie beispielsweise solchen, die OPC-Schnittstellen dazu verwenden, Daten von Prozesssteuerungssystemen oder -anlagen von Drittanbietern zu erhalten und zu analysieren.
In einem Beispiel werden die Plug-in-Module erstellt, um eine Schnittstelle zwischen der RBE-Ausnahme-Engine und externen Systemen oder Systemen von Drittanbietern (z. B. Steuerungssysteme, OPC-Schnittstellen, Wartungssysteme usw.) zu bilden, wodurch das Generieren von Ausnahmen ganz oder teilweise basierend auf Daten von Drittanbietern oder externen Softwaresystemen ermöglicht wird. Plug-ins können erstellt werden, um auf bestimmte Daten innerhalb eines oder von einem Drittanbieter(s) oder externen System zuzugreifen und diese Daten an die RBE-Engine zu übergeben, um zu analysieren, ob eine Ausnahme erstellt werden sollte oder nicht. Die Plug-ins können auf dem Server eines Drittanbieters, auf dem RBE-Server oder auf einem anderen Server ausgeführt werden und eine Ausnahmeerkennung durchführen oder nicht. Somit können die Plug-ins einfache Systemdatenerhebungen von Drittanbietern sein oder Daten erheben und zusätzlich eine gewisse Ausnahmeverarbeitung durchführen, wobei der RBE-Engine eine Ausnahme oder vorverarbeitete Ausnahmedaten bereitgestellt werden.
Bekannte Überprüfungssysteme können derzeit keine Schnittstelle mit Ausnahmen bilden oder diese erstellen basierend auf Daten, die direkt von externen Softwareprogrammen wie Steuerungssystemen, Sicherheitssystemen, Wartungssystemen usw. bereitgestellt werden. Plug-ins machen das RBE-System in einer komplizierten Prozessumgebung, in der mehrere verschiedene Softwaresysteme zur Laufzeit ausgeführt werden, erheblich robuster.
Darüber hinaus kann ein RBE-System in einem Beispiel eine Live-Ansichtskomponente enthalten, die einen Satz Metadaten (die beispielsweise beim Erstellen eines Plug-ins vordefiniert werden können) beim Sammeln der RBE-Eingangsdaten (d. h. der Prozessdaten, die zum Definieren oder Generieren einer Ausnahme verwendet werden können) sammelt. Die Metadaten können beliebige andere Prozess- oder Umgebungsdaten sein und werden gleichzeitig mit den Ausnahmeeingangsdaten gesammelt. Diese Metadaten werden als Prozessspeicherauszug gespeichert, der den Ausnahmedaten zugeordnet ist, auf die zugegriffen wird. Wenn das RBE-System eine Ausnahme basierend auf den gesammelten Ausnahmedaten erkennt, speichert das RBE-System auch die Metadaten als Teil der Ausnahme. Das RBE-System zeigt beim Melden der generierten Ausnahme zusätzlich einige oder alle Metadaten an, wodurch dem Benutzer oder Prüfer eine Live-Ansicht des Prozesses zum Zeitpunkt des Auftretens der Ausnahme innerhalb des Prozesses bereitgestellt wird.
Dieses System bietet dem Benutzer eine schnelle Ansicht verschiedener Prozesszustände/- werte usw. zum Zeitpunkt der Ausnahme, wodurch der Benutzer den Grund des Auftretens der Ausnahme und den Schweregrad der Ausnahme schneller verstehen kann, wodurch der Benutzer die Ausnahme schneller verarbeiten kann.
Während bekannte Prozessüberprüfungsprodukte dem Benutzer oder Prüfer eine Liste von generierten Ausnahmen bereitstellen, muss der Prüfer dennoch jede Ausnahme analysieren, um festzustellen, ob die Ausnahme abgewiesen werden kann oder auf andere Weise behoben werden muss. Im Allgemeinen muss der Prüfer jedoch zu dem Prozesssystem zurückkehren, in dem die Daten, die zur Ausnahme geführt haben, gesammelt wurden, um andere Dinge über den Prozess zum Zeitpunkt der Ausnahme zu verstehen (z. B., ob der Prozess online oder offline war, den Zustand eines Batches zum Zeitpunkt der Ausnahme usw.). Mit der Live-Ansichtsfunktion kann dem Benutzer automatisch ein Prozess-Speicherauszug bereitgestellt werden, der im Allgemeinen die Prozessdaten enthält, die für den Prüfer bei der Durchführung der Ausnahmeprüfung am nützlichsten sind. Dies bedeutet, dass der Prüfer nicht in andere Datensammelsysteme zurückkehren muss, um die Informationen zu erhalten, die der Benutzer zum Durchführen der Ausnahmeprüfung benötigt. Diese Funktion bedeutet auch, dass der Prüfer im Allgemeinen nicht so gut mit den anderen Prozesssystemen vertraut sein muss, von denen die Daten gesammelt werden, da der Prüfer diese Systeme nicht verwenden muss, um auf die vom Prüfer benötigten Prozessdaten zuzugreifen.
In einem anderen Beispiel enthält ein RBE- oder Qualitätsprüfungssystem einen Ereignismonitor, der an einen Drittanbieter oder ein externes System gebunden sein kann und der Nachrichten generiert und an das RBE-System sendet, das diese Nachrichten dann zum Durchführen der Ausnahmeverarbeitung oder Ausnahmeerstellung verwenden kann. In einem Fall kann der Ereignismonitor an eine OPC-Warn- und Alarmüberwachungsschnittstelle gebunden oder mit dieser gekoppelt sein und erkennen, wenn ein oder mehrere Warnungen oder Alarme an die OPC-Schnittstelle übergeben werden. Zu diesem Zeitpunkt erstellt der Ereignismonitor eine Nachricht mit den Warn- oder Alarminformationen und möglicherweise anderen gewünschten OPC-gesammelten Daten und schickt sie an das RBE-System. Das RBE-System kann dann die Nachrichten analysieren, um Ausnahmen basierend auf den Alarmen und Warnungen zu generieren. Typische Überprüfungssysteme analysieren keine Daten von Systemen von Drittanbietern, und keines von ihnen ist mit den vorhandenen OPC-Warn- und Alarmschnittstellen verbunden. Daher können diese Systeme keine Ausnahmen generieren, die beispielsweise auf Prozessalarmen und -warnungen basieren.
Ebenso kann das Qualitätsprüfungsmanagementsystem einen neuen Paging-Algorithmus verwenden, wenn Listen von Ausnahmedatensätzen einem Prüfer über eine elektronische Anzeige oder eine Benutzerschnittstelle dargestellt werden. Dieser Paging-Algorithmus, der so arbeitet, dass die Darstellung fehlender oder doppelter Datensätze im Überprüfungsprozess reduziert oder eliminiert wird, speichert einen oder mehrere Anker, um die tatsächlichen Datensätze auf der aktuellen Anzeigeseite von Datensätzen zu verfolgen, die in einer Schnittstellenanzeige bereitgestellt werden. Das System verwendet dann die Anker für die Seite, die gerade angezeigt wird, um die Startposition des nächsten Satzes oder der nächsten Datensätze zu bestimmen, die als Teil der nächsten Seite angezeigt werden sollen, wodurch das Paging-System auch dann ordnungsgemäß funktioniert, wenn Datensätze zur Liste hinzugefügt oder aus der Liste von Datensätzen entfernt werden, die während des Überprüfungsprozesses angezeigt werden soll.
In einem Beispiel implementiert das Überprüfungssystem einen neuen Paging-Algorithmus, wenn einem Prüfer Listen mit generierten Ausnahmen dargestellt werden. Im Allgemeinen erstellen/erkennen RBE-Systeme Ausnahmen und speichern diese Ausnahmen als Datensätze in einer strukturierten Datenbank, z. B. einer SQL-Datenbank. Wenn dann die Liste der Ausnahmen einem Prüfer auf einem Anzeigebildschirm dargestellt wird (und es kann eine große Anzahl von Ausnahmen oder Datensätzen geben), durchsucht das RBE-System die Datenbank nach allen relevanten Ausnahmedatensätzen, lädt Seiten mit Links zu diesen Datensätzen herunter und stellt anschließend Datensätze innerhalb von Anteilen der abgerufenen Seiten in der Reihenfolge dar, in der sie aus der Datenbank heruntergeladen wurden, wenn der Benutzer durch die verschiedenen Seiten der Ausnahmedatensätze scrollt. Wenn der Prüfer die Ausnahmen verarbeitet und die an der Benutzerschnittstelle angezeigte Liste von Ausnahmen nach unten scrollt, können sich die Datensätze in der Datenbank ändern, und somit können die Seitendaten veralten. Insbesondere können Datensätze zu der Datenbank hinzugefügt oder aus ihr gelöscht werden. In diesem Fall fehlen möglicherweise verschiedene Datensätze, auf die auf den Seiten verwiesen wird, wenn das System versucht, die Datensätze auf einem Anzeigebildschirm darzustellen, was zu Verlust oder Duplizierung visueller Daten führt. In einigen Fällen kann der Benutzer unter Umständen beim Wechseln von einer Seite zur nächsten einen Datensatz übersehen, wenn ein Datensatz auf einer bestimmten wiederhergestellten Seite gelöscht wird. In anderen Fällen kann das System aufgrund fehlender Datensätze, die sich auf den heruntergeladenen Seiten befanden, verunsichert sein, ob eine neue Anzeigeseite gestartet werden soll. Das neue System funktioniert insofern anders, als es Datensätze, die auf einem Anzeigebildschirm dargestellt werden, beginnend mit dem letzten auf dem Bildschirm angezeigten Datensatz herunterlädt. Das heißt, anstatt eine neue Anzeigeseite darzustellen, die den ursprünglichen Seiten wiederhergestellter Datensätze zugeordnet ist, greift das System auf die Datenbank für einen Satz von Datensätzen zu, die derzeit unmittelbar nach dem letzten Datensatz auf der angezeigten Seite vorhanden sind, wodurch sichergestellt ist, dass jedes Mal ein neuer Satz von Datensätzen auf dem Bildschirm angezeigt wird, wobei der erste neue angezeigte Datensatz der Datensatz ist, der unmittelbar auf den letzten unmittelbar vor dem Zeitpunkt des Scrollens angezeigten Datensatz folgt.
Dieses Anzeigesystem ist genauer, da es sicherstellt, dass Datensätze während des Überprüfungsprozesses, bei dem der Benutzer über einen langen Zeitraum verschiedene Seiten von Datensätzen nach unten scrollt, nicht in der falschen Reihenfolge angezeigt oder übersehen werden. Darüber hinaus ist das RBE-System effizienter, da es auf die Datenbank nur für die Anzahl neuer Datensätze zugreifen muss, die auf eine neue Anzeigeseite passen, während der Benutzer durch Datensätze scrollt, wobei nach wie vor sichergestellt ist, dass auf alle relevanten Datensätze zugegriffen wird, während der Benutzer den Bildlaufprozess durchführt.
Figurenliste

1 ist ein Blockdiagramm eines typischen Prozesses oder einer typischen Produktionsanlage, einschließlich eines Prozesssteuerungsnetzwerks, eines Batch Executives und einer Workflow-Anwendung, mit der ein Bediener einen Batch-Prozess verwalten und eine Batch-Protokolldatei zur Qualitätsprüfung speichern kann.
2 ist ein Blockdiagramm einer Anlagenumgebung, die 1 ähnlich ist, jedoch ein Qualitätsprüfungsmanagementsystem mit einer Konfigurationsanwendung, einer Ausnahme-Engine und einer Qualitätsprüfungsschnittstellenanwendung zur Verwendung beim Durchführen einer ausnahmebasierten Erkennung und Qualitätsprüfung innerhalb einer Anlagenumgebung einschließt.
3 ist eine beispielhafte Bildschirmanzeige, die durch die Konfigurationsanwendung des Qualitätsprüfungsmanagementsystems von 2 erstellt wurde, um es einem Benutzer zu ermöglichen, eine oder mehrere Ausnahmeregeln zur Verwendung durch eine Ausnahme-Engine zu erstellen.
4 ist ein Flussdiagramm, das den Betrieb der Ausnahme-Engine des Qualitätsprüfungsmanagementsystems von 2 beim Analysieren von Daten aus mehreren Datenquellen zur Ausnahmeverarbeitung veranschaulicht.
5 ist eine beispielhafte Bildschirmanzeige, die eine Live-Rückmeldung vom Qualitätsprüfungsmanagementsystem an einen Bediener eines Batch-Prozesses veranschaulicht, die den Bediener in Echtzeit über die Erkennung einer tatsächlichen oder potenziellen Ausnahme innerhalb des Prozesses informiert.
6 ist ein Diagramm, das den Betrieb eines Qualitätsprüfungsmanagementsystems veranschaulicht, das in einer Plug-in-Umgebung implementiert ist.
7 zeigt ein beispielhaftes Ereignisüberwachungssystem, das ein Qualitätsprüfungsmanagementsystem in einer kontinuierlichen Prozessumgebung dazu verwendet, das Überwachen von Anwendungen und Systemen von Drittanbietern durchzuführen.
8A-8G zeigen beispielhafte Bildschirmanzeigen, die von einer Überprüfungsschnittstellenanwendung oder einer Konfigurationsanwendung des Qualitätsprüfungsmanagementsystems von 2 erstellt wurden, um es einem Qualitätsprüfer zu ermöglichen, verschiedene Aktivitäten in Bezug auf die Konfiguration von Ausnahmeregeln und das Anzeigen und Behandeln von Ausnahmedatensätzen durchzuführen.
9A und 9B sind Diagramme, die den Betrieb einer typischen Paging-Technik veranschaulichen, die dazu verwendet wird, Listen von Datensätzen für einen Benutzer beispielsweise in einer Web-Umgebung bereitzustellen.
10A und 10B sind Diagramme, die den Betrieb einer neuen Paging-Technik veranschaulichen, die durch die Qualitätsprüfungsschnittstellenanwendung von 2 implementiert werden kann, um doppelte oder fehlende Datensätze zu reduzieren oder zu eliminieren, wenn Paging durch einen Satz von Datensätzen durchgeführt wird.

Detaillierte Beschreibung
Als Hintergrund veranschaulicht 1 eine typische Anlagen- oder Prozesssteuerungsumgebung 10, in die typische oder vorhandene Qualitätsprüfungsmanagementmaßnahmen implementiert sind. Die Anlagenumgebung 10 schließt ein Prozesssteuerungsnetzwerk 20 ein, das verschiedene Prozesssteuerungsgeräte wie Steuerungen, Feldgeräte (z. B. Ventile, Sensoren, Sender, Tanks, Mischer usw.), I/O-Geräte usw. beinhalten kann, die kommunikativ miteinander verbunden sind und alle so programmiert sind, dass sie einen Herstellungsprozess irgendeiner Art, wie beispielsweise einen Batch-Prozess oder einen kontinuierlichen Prozess, betreiben oder implementieren. Weiterhin kann die Anlagenumgebung 10 einen Batch Executive 22 (implementiert auf einem Prozessor eines Rechengeräts, wie beispielsweise einer Arbeitsstation oder einem Server) enthalten, der eine Schnittstelle mit dem Prozesssteuerungsnetzwerk 20 bilden kann, um das Prozesssteuerungsnetzwerk 20 oder die Geräte innerhalb des Prozesssteuerungsnetzwerks 20 zum Vornehmen verschiedener Aktionen zu veranlassen, die einem Herstellungsprozess zugeordnet sind, wie zum Beispiel das Implementieren verschiedener Aufträge oder Batchläufe, einschließlich des Implementierens verschiedener Stufen verschiedener Batches, wie beispielsweise Teilverfahren, Verfahren, Operationen, Phasen, Schritte usw. von Batch-Prozessen, die jedem Auftrag zugeordnet sind. Darüber hinaus können sowohl das Prozesssteuerungsnetzwerk 20 als auch der Batch Executive 22 mit einem weiteren Netzwerk 24 gekoppelt sein, das sich beispielsweise in einer Geschäftsumgebung außerhalb des Anlagenbereichs oder des Fertigungsraums befinden kann. Das Netzwerk 24 kann ein Kommunikations-Backbone 25 enthalten, das verschiedene Geräte kommunikativ verbindet, wie beispielsweise Computeranzeigegeräte oder Arbeitsstationen 26 und 28, verschiedene Datenbanken 30, 31 und 32 und andere Computergeräte, falls dies gewünscht wird, wie beispielsweise Gateways zum Internet oder andere Kommunikationsnetzwerke, Server, drahtlose oder Handheld-Geräte usw. (nicht in 1 gezeigt). Die Geräte 26, 28, 30, 31 und 32 können über ein beliebiges gewünschtes physisches Kommunikationsnetzwerk oder Backbone 25, wie ein Ethernet-Netzwerk, ein Internet oder ein anderes lokales Netzwerk (LAN) oder ein Weitverkehrsnetzwerk (WAN) usw., kommunikativ verbunden sein. Ebenso können das Prozesssteuersystem 20 und der Batch Executive 22 über das Netzwerk-Backbone 25 direkt oder auf Wunsch über andere dazwischenliegende Netzwerke mit den verschiedenen Geräten und Datenbanken 26, 28, 30, 31 und 32 verbunden sein.
In diesem System nach dem Stand der Technik kann eine Workflow-Anwendung 40 in einem Bedienerschnittstellengerät (beispielsweise der Arbeitsstation 26) gespeichert sein, und die Workflow-Anwendung 40 kann von einem Prozessor der Arbeitsstation 26 ausgeführt werden, um eine Schnittstelle mit dem Batch Executive 22 zu bilden, wenn der Batch Executive 22 das Prozesssteuerungsnetzwerk 20 steuert, um verschiedene Aufträge oder Batchläufe zu implementieren. Die Workflow-Anwendung 40, die beispielsweise die von Emerson Process Management verkaufte Syncade Workflow-Anwendung sein kann, kann dazu fungieren, Daten vom Batch Executive 22 zu erhalten und anzuzeigen. Diese Daten können laufende Batch-Statusdaten, Parameterdaten, Messdaten, Fortschrittsdaten, Zustandsdaten des Batchverfahrensmodells usw. beinhalten, wie sie vom Batch Executive 22 erfasst wurden. Diese Informationen oder Daten können Informationen zum implementierten Auftrag, zu den dem Auftrag zugeordneten Materialien und Prozessen (z. B. das Rezept und das zu implementierende Batchverfahrensmodell), zu Alarm- und Warndaten vom Batch Executive 22 und/oder dem Prozesssteuerungsnetzwerk 20 usw. enthalten. Einige oder alle dieser Daten können auch in einer Batch-Protokolldateidatenbank 32 als Batch-Protokolldatei 34 gespeichert werden, wie es für Batch Executive-Routinen typisch ist.
Wie im Allgemeinen bekannt ist, kann die Workflow-Anwendung 40 den Betrieb des Batch Executives 22 in Bezug auf jeden Auftrag verfolgen, der vom Batch Executive 22 implementiert wird, und es dem Batch-Bediener ermöglichen, verschiedene Operationen oder Aktionen innerhalb des oder in Bezug auf den Batch Executive 22 oder das Prozesssteuerungsnetzwerk 20 zu implementieren. Beispielsweise kann die Workflow-Anwendung 40 bestimmte Arten von Daten vom Batch Executive 22 abonnieren, wie Parameterdaten, Batch-Zustandsdaten, Batch-Zustandsänderungsdaten, Batch-Alarme und/oder -Warnungen usw., und kann den Bediener basierend auf diesen Daten über verschiedene Bedingungen in der Anlage 10 benachrichtigen. Die Workflow-Anwendung 40 kann beispielsweise den Bediener über das Starten und Stoppen verschiedener unterschiedlicher Batchverfahren oder über Zustandsänderungen des Batchverfahrensmodells benachrichtigen, kann den Bediener über verschiedene Stopps oder andere Betriebsbedingungen der Batch Executive-Engine 22 (die durch unvorhergesehene Probleme wie fehlende Ausrüstungen, fehlende Rohstoffe verursacht werden können) benachrichtigen, kann den Bediener über falsch platzierte Zeiträume, über Batch-Parameter, die möglicherweise basierend auf den Erwartungen des Batch Executives 22 außerhalb des zulässigen Bereichs liegen, usw., informieren. Die Workflow-Anwendung 40 kann es dem Bediener bekanntlich ermöglichen, verschiedene Aktionen vorzunehmen, um einen Batchlauf neu zu starten, verschiedene Ausrüstungen für einen Batchlauf auszuwählen, mit verschiedenen Rohstoffen zu arbeiten und den Batch Executive anzuweisen, Verfahren hochzufahren, herunterzufahren oder zu überspringen, oder andere Verfahren im BatchVerfahrensmodell auszuführen. Beispielsweise kann der Batch Executive 22 versuchen, einen Reinigungsvorgang zu durchlaufen, bei dem die zu reinigende Ausrüstung offline ist und daher zum Reinigen nicht zur Verfügung steht. In diesem Fall kann der Bediener das Reinigungsverfahren überspringen, was möglicherweise den implementierten Qualitätsstandards nicht genau entspricht, was aber unter Umständen erforderlich ist, um den Batch rechtzeitig oder innerhalb eines festgelegten Zeitrahmens fertigzustellen. In jedem Fall kann die Workflow-Anwendung 40 dem Bediener ermöglichen, verschiedene vom Bediener ausgeführte Aktionen mit Anmerkungen zu versehen. Darüber hinaus kann die Workflow-Anwendung 40 die vom Bediener über die Workflow-Anwendung 40 bereitgestellten Anmerkungen oder Hinweise speichern (z. B. Hinweise oder Kommentare des Bedieners, um zu erläutern, was geschehen ist und warum der Bediener bestimmte Aktionen außerhalb des erwarteten Arbeitsablaufs des Batch-Prozesses durchgeführt hat) und kann Daten, die auf verschiedene vom Bediener über die Workflow-Anwendung 40 ausgeführte Aktionen hinweisen, in der Batch-Protokolldateidatenbank 30 als Teil einer Batch-Protokolldatei 34 für den zu überwachenden oder zu steuernden Auftrag speichern. Jede Batch-Protokolldatei 34 listet typischerweise die verschiedenen Daten, die von dem Batch Executive 22 erhalten werden, zusammen mit Aktionen, die vom Bediener als Reaktion auf diese Daten ausgeführt werden, Hinweise, die vom Bediener in die Protokolldatei eingefügt werden usw. auf. Darüber hinaus sendet der Batch Executive 22 während des Betriebs des Batch Executives 22 Datenpakete mit aktuellen Daten zu einem Batchlauf oder Auftrag an die Workflow-Anwendung 40. Die Workflow-Anwendung 40 kann verschiedene Daten von dem Batch Executive 22 (oder dem Prozesssteuerungsnetzwerk 20) abonnieren und diese Daten periodisch empfangen, wenn Änderungen in den Daten auftreten usw. Darüber hinaus kann jeder Satz von Daten eine eindeutige Paketkennung aufweisen, die verschiedene Informationen zu dem den Daten zugeordneten Batchlauf oder Auftrag identifiziert. Auf diese Weise kann die Workflow-Anwendung 40 die Datenpakete verarbeiten, um den Auftrag und damit den richtigen Bediener zu bestimmen, dem die Daten bereitgestellt werden sollen. Bekanntlich wird eine Batch-Protokolldatei oder ein Batchbericht 34 für einen Batchlauf während des Batchlaufs generiert, und nachdem der Batchlauf oder Auftrag geschlossen ist, ist die Batch-Protokolldatei 34 geschlossen. Zu diesem Zeitpunkt kann ein Qualitätsprüfungsingenieur oder ein anderer Mitarbeiter über eine auf dem Computer oder der Arbeitsstation 28 ausgeführte Anzeigeanwendung auf die Batch-Protokolldatei 34 zugreifen, um beispielsweise den Batchbericht zu analysieren und die Daten und andere Informationen in einem Batchbericht Zeile für Zeile anzuzeigen. Der Qualitätsingenieur kann diese Daten so anzeigen, wie sie während des Betriebs des Batch-Prozesses gespeichert wurden, um zu bestimmen, ob innerhalb des Batchlaufs Ausnahmen aufgetreten sind, ob diese Ausnahmen angegangen werden müssen und was zu tun ist, wenn basierend auf der Existenz dieser Ausnahmen Aktionen ergriffen werden müssen. Wie vorstehend erwähnt, nimmt diese Überprüfung in der Regel viel Zeit in Anspruch und erfordert manuellen Aufwand und viel Wissen seitens des Qualitätsingenieurs. Darüber hinaus betrachtet der Qualitätsingenieur die meiste Zeit lediglich Daten oder Informationen aus dem Batchbericht, die nicht einer bestimmten Ausnahme oder Abweichung von den erwarteten Aktionen innerhalb des Batchlaufs zugeordnet sind; daher ist diese Überprüfung zeitintensiv. Wie vorstehend erwähnt, muss ein Qualitätsingenieur, wenn der Qualitätsingenieur eine Ausnahme basierend auf den Daten in der Batch-Protokolldatei 34 identifiziert, unter Umständen andere Informationen über den Batch-Prozess erhalten (z. B. Prozessvariablenwerte, Batch-Verfahrensmodellzustände, Rezeptinformationen usw.), die in einer der anderen Datenbanken gespeichert sind, z. B. in einem Batch-Historiker 30, einem Prozesssteuerungshistoriker 31 usw. Diese Aktivität erfordert möglicherweise, dass der Qualitätsingenieur andere Datenzugriffsanwendungen verwendet, um auf diese Daten zuzugreifen, und erfordert daher, dass der Ingenieur über das Knowhow verfügt, um mittels dieser anderen Datenzugriffsanwendungen effizient und korrekt auf diese Daten zuzugreifen und diese anzuzeigen.
2 veranschaulicht eine Anlagenumgebung 110, die der Anlagenumgebung 10 von 1 ähnlich ist, mit der gleichen Struktur, gleichen Anwendungen und Daten mit gemeinsamen Bezugszahlen. Die Anlagenumgebung 110 von 2 enthält jedoch ein Qualitätsprüfungsmanagementsystem 112, das ausgeführt wird, um Qualitätsingenieure (oder andere Mitarbeiter) beim Identifizieren und Überprüfen von Ausnahmen zu unterstützen, die einem Auftrag oder Batchlauf (oder mehreren verschiedenen Aufträgen oder Batchläufen) zugeordnet sind, und das in einigen Fällen Bediener beim Ausführen von Workflow-Vorgängen innerhalb eines Batchlaufs auf eine Weise unterstützt, die die Anzahl der während des Auftrags generierten Ausnahmen oder Ausnahmedatensätze verringert.
Insbesondere beinhaltet die Anlagenumgebung 110 von 2 ein Prozesssteuerungsnetzwerk 20 und eine Batch Executive-Engine oder einen Batch Executive 22, die auf ähnliche Weise arbeiten wie vorstehend in Bezug auf 1 beschrieben. Somit werden Daten von der Batch Executive-Engine 22 und/oder dem Prozesssteuerungsnetzwerk 20 verschiedenen Geräten über ein Kommunikationsnetzwerk-Backbone 25 bereitgestellt, mit dem verschiedene Prozesssteuerungen und verschiedene Computer oder Geräte des Qualitätsprüfungsmanagementsystems 112 verbunden sind. In diesem Beispiel werden die Batch- oder anderen Prozessdaten einer Workflow-Bedienerschnittstelle 26 bereitgestellt, die eine Workflow-Anwendung 40 ausführt und Daten für eine Batch-Protokolldateidatenbank 32 bereitstellt, in der Batch-Protokolldateien 34 gespeichert sind. Das Qualitätsprüfungsmanagementsystem 112 in der Anlagenumgebung 110 von 2 beinhaltet jedoch verschiedene Anwendungen und Datenbanken, die sich in Computer- oder Prozessorgeräten in der Anlagenumgebung 110 befinden, in diesen gespeichert sind und auf diesen ausgeführt werden. Insbesondere beinhaltet, wie in 2 veranschaulicht, das Qualitätsprüfungsmanagementsystem 112 eine Konfigurationsanwendung 120, die in einem Speicher eines Verarbeitungsgeräts 121 gespeichert ist und auf einem Prozessor von diesem ausgeführt wird, eine Ausnahme-Engine 122, die in einem Speicher eines Servers 123 gespeichert ist und auf einem Prozessor von diesem ausgeführt wird, eine Regeldatenbank 124, eine Ausnahmedatensatzdatenbank 126 und eine QualitätsprüfungsSchnittstellenanwendung 128, die in einem Speicher eines Verarbeitungsgeräts wie einer Arbeitsstation 129 gespeichert ist und auf diesem ausgeführt wird. Während die Komponenten 120, 122, 124, 126 und 128 so veranschaulicht sind, dass sie in getrennten Rechengeräten gespeichert sind und in diesen ausgeführt werden, die sich von den Rechengeräten 26, 28, 30, 31 und 32 von 2 unterscheiden, könnten eine Teilmenge oder alle Komponenten 120, 122, 124, 126 und 128 davon in denselben Verarbeitungsgeräten gespeichert sein und ausgeführt werden, wobei es sich um dieselben Verarbeitungsgeräte handeln kann, die andere Prozesssteuerungsanwendungen und Datenbanken speichern und ausführen, wie beispielsweise die Geräte 26, 28, 30, 31 und 32.
Im Allgemeinen kann die Konfigurationsanwendung 120 so betrieben oder ausgeführt werden, dass sie es einem Benutzer, wie einem Konfigurationsingenieur, einem Qualitätsmanagementingenieur usw., ermöglicht, einen Satz von Regeln (im Allgemeinen hierin als Ausnahmeregeln bezeichnet) zu erstellen und zu speichern, die von der Ausnahme-Engine 122 dazu verwendet werden können, Ausnahmen beim Ausführen eines Prozesses, beispielsweise in einem Batchlauf eines Batch-Prozesses, der einem bestimmten Auftrag zugeordnet ist, zu erkennen. Die Konfigurationsanwendung 120 stellt im Wesentlichen eine Konfigurationsumgebung bereit, die es einem Benutzer ermöglicht, konfigurierbare Ausnahmeregeln zu erstellen, die in der Ausnahme-Engine 122 ausgeführt werden sollen, um Ausnahmen zu definieren oder zu erkennen. Die Konfigurationsanwendung 120 kann einen Satz von Regelvorlagen speichern, die verschiedene Arten von Eingangsdaten verarbeiten können, um eine Ausnahme unter Verwendung eines beliebigen gewünschten Logiktyps oder logischer Ausdrücke, wie beispielsweise von Boolescher Logik, zu erkennen. In der Konfigurationsumgebung kann ein Benutzer eine der Regelvorlagen auswählen, Datenein-/- ausgänge für eine Regel definieren und einen möglichen Ausdruck definieren, der für einen Satz von Daten analysiert werden soll. Wenn die Daten durch die Ausnahme-Engine 122 fließen, analysiert die Ausnahme-Engine die Daten anhand der konfigurierten Regeln, um festzustellen, ob eine Ausnahme vorliegt. Bei Erkennung einer Ausnahme speichert die Ausnahme-Engine 122 dann einen Ausnahmedatensatz in der Datenbank 126.
Als Beispiel veranschaulicht 3 eine Bildschirmanzeige 150, die die Konfigurationsanwendung 120 beispielsweise über die Arbeitsstation 28 von 2 erstellen und einem Benutzer (z. B. einem Konfigurationsingenieur, einem Qualitätsprüfungsingenieur usw.) bereitstellen kann, um es dem Benutzer zu ermöglichen, eine oder mehrere Ausnahmeregeln 152 zu erstellen und die Ausnahmeregeln 152 in der Ausnahmeregeldatenbank 124 zu speichern. Insbesondere kann es die Konfigurationsanwendung 120 dem Benutzer ermöglichen, verschiedene Regelsätze zu erstellen, die auf Daten aus verschiedenen Datenquellen angewendet werden sollen. Wie in 2 veranschaulicht, können die Ausnahmeregeln 152 einen unterschiedlichen Satz von Ausnahmeregeln 152A, 152B, 152C, 152D usw. für jede einer Anzahl verschiedener Datenquellen enthalten. Beispielsweise können die Regeln 152A für das Analysieren von Daten aus der Workflow-Anwendung 40 erstellt und diesem zugeordnet werden, die Regeln 152B können für das Analysieren von Daten aus einer Ereignismonitoranwendung erstellt und diesem zugeordnet werden, die Regeln 152C können für das Analysieren von Daten von einer Drittanbieteranwendung, die andere Dienste in der Anlagenumgebung 110 usw. ausführt, erstellt und diesem zugeordnet werden. Natürlich kann für jede Datenquelle eine beliebige Anzahl von Ausnahmeregeln 152 erstellt und gespeichert werden, und diese Regeln können auf eine beliebige Anzahl von unterschiedlichen Arten zum Analysieren von Daten aus diesen Datenquellen konfiguriert werden. Beispielsweise können unterschiedliche Sätze von Ausnahmeregeln für verschiedene Arten von Ausführungen aus einer einzelnen Datenquelle erstellt werden (z. B. Batches, die unterschiedliche Produkte erstellen), und unterschiedliche Sätze von Ausnahmeregeln können für unterschiedliche Qualitätsstandards erstellt werden. Ebenso können die einer bestimmten Datenquelle zugeordneten Ausnahmeregeln so geordnet werden, dass sie vorgeben, welche aus dem Satz von Ausnahmeregeln als Erstes, Zweites, Drittes usw. ausgeführt oder analysiert werden sollten.
Unter erneuter Bezugnahme auf 3 kann die Konfigurationsanwendung 120 einen Bildschirm erstellen, der eine Anzahl verschiedener Abschnitte enthält, einschließlich eines Regelvorlagenabschnitts 156, eines Datenquellenabschnitts 158, eines Regellistenabschnitts 160 und eines Regelkonfigurationsabschnitts 162. Der Regelvorlagenabschnitt 156 kann eine Reihe von Symbolen enthalten, die Ausnahmeregelvorlagen oder zuvor konfigurierte Ausnahmeregeln angeben, die als Vorlagen gespeichert sind, die ein Benutzer als Ausgangspunkt zum Erstellen einer neuen Regel verwenden kann. Diese Vorlagen können in der Regeldatenbank 124 oder in demselben Gerät wie die Konfigurationsanwendung 120 oder in einer anderen Datenbank oder einem anderen Computerspeicher gespeichert sein. Der Datenquellenabschnitt 158 kann Symbole enthalten, die verschiedene unterschiedliche Datenquellen angeben, für die ein Benutzer Ausnahmeregeln erstellen kann. Auf die Symbole 158A kann zugegriffen werden, um Besonderheiten zu den Datenquellen anzuzeigen, wie beispielsweise Daten, die von den Datenquellen verfügbar sind, Daten oder Kommunikationsformate, die von den Datenquellen verwendet werden, um Daten zu kommunizieren, Informationen über die Datenquellen (z. B. Hersteller, Version usw.) und/oder sonstige Informationen. Der Regellistenabschnitt 160 kann eine Liste von Regeln für eine bestimmte ausgewählte Datenquelle speichern und die Ausführungsreihenfolge der Regeln vorgeben, wenn Daten aus der Datenquelle analysiert werden.
Während des Betriebs kann ein Benutzer eine Datenquelle 158A aus dem Datenquellenabschnitt 158 auswählen, um die Datenquelle vorzugeben, für die eine Regel erstellt werden soll. Die Anwendung 120 kann auf die Regeldatenbank 124 zugreifen und die zuvor gespeicherten Regeln (soweit vorhanden) für diese Datenquelle finden und diese Regeln beispielsweise in der Ausführungsreihenfolge im Regellistenabschnitt 160 auflisten. Als nächstes kann der Benutzer eine neue Regel für die Datenquelle erstellen, indem er ein Vorlagendatenquellensymbol 156A aus dem Vorlagenabschnitt 156 auswählt und dieses Vorlagensymbol 156A auf den Regelkonfigurationsabschnitt 162 zieht und ablegt, wodurch die Anwendung 120 Konfigurationsdaten für die ausgewählte Vorlagenregel in verschiedene Anteile oder Felder des Konfigurationsabschnitts 162 lädt. Falls gewünscht, können die Felder des Regelkonfigurationsabschnitts 162 leer sein, damit ein Benutzer eine neue Regel ohne Verwendung einer Vorlage erstellen kann. Darüber hinaus kann der Benutzer eine der Regeln im Regellistenabschnitt 160 auswählen, um eine zuvor erstellte Regel zu bearbeiten. Natürlich kann die Anwendung 120 andere Arten der Auswahl oder Festlegung von Regeln verwenden, die erstellt werden sollen (z. B. unter Verwendung von Dropdown-Menüs, Popup-Bildschirmen usw.).
Die Konfigurationsanwendung 120 ermöglicht es dann einem Benutzer, wie beispielsweise einem Konfigurationsingenieur, die Besonderheiten der Regel vorzugeben, einzurichten oder zu erstellen, indem verschiedene Regelkonfigurationsinformationen in verschiedenen Feldern des Regelkonfigurationsabschnitts 162 bereitgestellt oder bearbeitet werden. Grundsätzlich ermöglicht es die Anwendung 120 dem Benutzer, alle Regelkonfigurationsinformationen vorzugeben, die zum Verarbeiten von Daten aus der Datenquelle erforderlich sind, um eine Ausnahme innerhalb des Betriebs des von der Datenquelle überwachten Prozesses zu erkennen und zu behandeln. Im Allgemeinen speichert jede Regel Logik, wie z. B. Boolesche Logik, um die Daten aus der Datenquelle zu analysieren, um eine Ausnahme zu erkennen, Informationen zum Speichern eines Ausnahmedatensatzes und, falls gewünscht, Informationen darüber, wie einem Qualitätsingenieur das Verarbeiten oder Auflösen (z. B. Schließen) eines Ausnahmedatensatzes, der durch Anwendung der Regel erstellt wurde, ermöglicht werden kann. Solche Ausnahmeregeln können beispielsweise das Erkennen, ob ein oder mehrere Parameter aus der Datenquelle (z. B. die Workflow-Anwendung 40, der Batch Executive 22, das Prozesssteuerungssystem 20 usw.) außerhalb des zulässigen Bereichs liegen oder über oder unter bestimmten vorab festgelegten Schwellenwerten liegen; ob ein Hinweis von einem Bediener eingegeben wurde (z. B. über die Workflow-Anwendung 40); ob in einem Batchlauf für einen Auftrag anderes Material verwendet wird; ob unterschiedliche Ausrüstungen für ein oder mehrere Batchverfahren eines Auftrags verwendet werden; ob die Verarbeitungszeiten eines oder mehrerer Batchverfahren länger oder weniger lang als erwartet gedauert haben; das Überspringen oder Hinzufügen bestimmter Schritte oder Verfahren innerhalb eines Batchlaufs für einen Auftrag, wie z. B. ein Reinigungsverfahren oder ein Spülverfahren; ob ein Bediener oder ein anderer Benutzer des Prozesssystems eine unerwartete Aktion in dem Prozess ausgeführt oder einen Hinweis in die Datenquellenanwendung usw. eingegeben hat, usw. einschließen. Natürlich können die Ausnahmeregeln eine auf bestimmte Daten von einer Datenquelle anzuwendende gewünschte Logik vorgeben, um zu bestimmen, ob eine Ausnahme vorliegt.
Somit enthält der Regelkonfigurationsabschnitt 162, wie in dem Beispielbildschirm 150 von 3 veranschaulicht, ein Namensfeld 162A, das zum Vorgeben eines Namens der Ausnahmeregel verwendet werden kann, ein Schweregradfeld 162B, das zum Vorgeben einer Stufe des Schweregrads oder der Bedeutung der von der Regel erkannten Ausnahme verwendet werden kann, und ein Logikfeld 162C, das ausgefüllt oder verwendet werden kann, um die von der Ausnahme-Engine 122 (2) anzuwendende Logik vorzugeben, um zu erkennen, ob eine Ausnahme vorliegt. Natürlich kann das Logikfeld 162C den Benutzer akzeptieren oder es ihm ermöglichen, Logik auf irgendeine gewünschte Weise einzugeben oder vorzugeben, wie beispielsweise einen Satz von Booleschen Logikparametern oder - Zeichenfolgen, Codierung in einer bestimmten Sprache (C+, HTML usw.), eine gewünschte benutzerdefinierte Ausdruckssyntax usw., die einige Logik-, Wenn-Dann-Logikanweisungen usw. anwendet. Darüber hinaus kann ein Quellparameterfeld verwendet werden, um alle Daten vorzugeben, die von der Datenquelle für die Anwendung der Logikregel oder der Logik benötigt werden, wie im Feld 162C bereitgestellt. Diese Datenquellendaten, die hier als Datenquellenmetadaten oder nur als Metadaten bezeichnet werden, geben alle Daten vor, die den Informationen, dem Format und den Kommunikationsparametern der Daten zugeordnet sind, die von der Datenquelle für die Regel empfangen werden sollen. Die Konfigurationsanwendung 120 kann es dem Benutzer ermöglichen, eines der Symbole 158A auszuwählen, um Konfigurationsinformationen für die bestimmte Datenquelle, für die eine Regel erstellt wird, um zu bestimmen, welche Datenquellenmetadaten (Informationen und/oder Variablen) aus der Datenquelle verfügbar sind, die Namen dieser Variablen, die Datenformate dieser Variablen (z. B. 32-Bit, 64-Bit, Variablentypen, wie z. B. Ganzzahl- oder Boolesche Variablen oder Zeichenfolgenvariablen) usw. zu erhalten. Darüber hinaus kann das Feld 162D dem Benutzer ermöglichen, die Durchführung einer Konvertierung vorzugeben, die an Metadaten aus einer Datenquelle durchgeführt werden soll, bevor die Eingangsdaten aus der Datenquelle in der im Feld 162C angegebenen Logik verwendet werden. Solche Konvertierungen können mathematische Operatoren sein (Änderung von Celsius in Fahrenheit, Skalierung, Grenzwerte usw.), die Konvertierungen können Änderungen von Variablennamen sein (um die verschiedenen in der Logik verwendeten Variablennamen mit dem Namen der Datenquellenvariablen abzugleichen), oder diese Konvertierungen können jede andere Art von Konvertierungen sein. Darüber hinaus können die Metadaten aus einer Datenquelle beliebige Informationen enthalten, wie z. B. Prozessparameterwerte, einen Auftragsnamen, Materialien für den Auftrag, Prozessabläufe für den Auftrag, Prozessausrüstung, die in dem Auftrag verwendet werden soll, Arbeitsabläufe, die auf den Auftrag anzuwenden sind, das im Auftrag verwendete BatchVerfahrensmodell usw.
Ferner kann der Konfigurationsingenieur die Konfigurationsanwendung 120 dazu verwenden, die Reihenfolge oder Abfolge vorzugeben, in der jede der Regeln eines bestimmten Satzes von Regeln auf einen bestimmten Satz von Daten aus einer Datenquelle angewandt werden sollte. Insbesondere kann die Ausnahme-Engine 122 mehrere Regeln auf jeden Satz von Daten von einer Datenquelle anwenden und kann so eingerichtet sein, dass sie jede der mehreren Regeln in einer spezifischen oder vorgegebenen Reihenfolge anwendet, um bestimmte Arten von Ausnahmen (typischerweise wichtigere oder schwerwiegende Ausnahmen) vor anderen Arten von Ausnahmen (z. B. weniger schwerwiegende Ausnahmen) zu erkennen. In vielen Fällen kann beispielsweise die Anwendung unterschiedlicher Ausnahmeregeln auf einen bestimmten Satz von Daten aus einer Datenquelle dazu führen, dass mehrere unterschiedliche Ausnahmen erkannt werden. Es kann jedoch wichtig oder wünschenswert sein, nur die signifikanteste Ausnahme für einen bestimmten Datensatz aus einer Datenquelle zu bestimmen, um die Erstellung mehrerer Ausnahmedatensätze zu verhindern, die demselben Ereignis oder Zeitpunkt in einem Batchlauf oder Auftrag zugeordnet sind. Die Reihenfolge der Regeln (d. h. die Reihenfolge, in der die Ausnahme-Engine 122 die Ausnahmeregeln auf einen bestimmten Satz von Daten anwendet) wird somit dazu verwendet, vorzugeben, welche Ausnahmen zuerst erkannt werden, so dass die Ausnahme-Engine 122 die Ausnahmen während des Betriebs basierend auf den verschiedenen Regeln bestimmt, indem sie die Regeln in einer bestimmten Reihenfolge ausführt und dann einen Ausnahmedatensatz nur für die erste erkannte Ausnahme speichert oder erstellt. Wie vorstehend angegeben, kann der Regelabschnitt 160 die Liste der Regeln für die Quelle in der Reihenfolge speichern, in der diese Regeln ausgeführt werden. Jede Regel kann als Parameter davon eine Sequenznummer oder Auftragsnummer speichern oder enthalten, die diese Ausführungsreihenfolge angibt. In jedem Fall kann der Benutzer die Reihenfolge der Regeln für eine Datenquelle ändern, indem er beispielsweise die Reihenfolge der Regeln in der Liste der Regeln in Abschnitt 160 neu anordnet. Der Benutzer kann beispielsweise eine Regel in der Regelliste 160 auswählen, diese Regel in der Liste 160 nach oben oder unten ziehen und die Regel an einer neuen Stelle in der Liste 160 ablegen, um die Ausführungsreihenfolge der Regeln zu ändern. Natürlich kann es die Anwendung 120 dem Benutzer ermöglichen, die Reihenfolge von Regeln auf andere Weise zu ändern, beispielsweise durch Ändern eines Auftragsfelds 162E in dem Bildschirmabschnitt 162.
Falls gewünscht, kann der Bildschirmabschnitt 162 darüber hinaus ein Auflösungsfeld 162F enthalten, das es dem Konfigurationsingenieur ermöglichen kann, ein oder möglicherweise mehrere Handhabungs- oder Auflösungsverfahren vorzugeben, die angewendet werden sollten oder müssen, um einen durch die Regel erstellten Ausnahmedatensatz zu schließen. Im Allgemeinen kann jeder Ausnahmetyp ein einzelnes Auflösungsverfahren unterstützen. In einigen Fällen können Ausnahmen jedoch mehrere Auflösungsverfahren unterstützen oder einschließen. Solche Auflösungsverfahren können das Freigeben der Ausnahme, das Versehen des Ausnahmedatensatzes mit Anmerkungen mit verschiedenen Informationen, das Senden des Ausnahmedatensatzes an andere Mitarbeiter zur Überprüfung und/oder Freigabe usw. einschließen. In einigen Fällen kann jede Auflösung einfach eine Definition eines Satzes von Signaturen sein, die zum Schließen der Ausnahme erforderlich sind, oder die Auflösung kann einfach eine oder mehrere Signaturen erzwingen, die zum Schließen der Ausnahme erforderlich sind. In diesen Fällen kann die Auflösung eine Beschreibung oder einen Satz von Anweisungen enthalten, die andere Aktivitäten (Verfahren) angeben, die vor der (den) Signatur(en) ausgeführt werden müssen; in diesen Fällen kann jedoch die Auflösung die anderen Aktivitäten möglicherweise nicht überwachen oder erzwingen. Die in der Regel angegebenen Behandlungsverfahren können voreingestellt sein oder auf Standardeinstellungen eingestellt werden, beispielsweise basierend auf dem Schweregrad der Ausnahme, wie im Feld 162B vorgegeben.
Ferner kann der Bildschirmabschnitt 162 ein Informationsfeld 162G enthalten, das Informationen akzeptiert und speichert, die dem Qualitätsprüfungsingenieur zusammen mit oder als Teil von dem durch Anwendung der Regel erstellten Ausnahmedatensatz bereitgestellt werden sollen. Diese Informationen können allgemeine Informationen über diese Art von Ausnahme, normale Behandlungsverfahren, Anweisungen oder Vorschläge zu anderen vorzunehmenden oder zu berücksichtigenden Aktionen oder andere Informationen sein, die für den Qualitätsprüfungsingenieur beim Anzeigen oder Behandeln des durch Anwendung der Regel erstellten Ausnahmedatensatzes nützlich sein können. In vielen Fällen kann das Feld 162G auch dazu verwendet werden, Datenquellenmetadaten, die als Teil des Ausnahmedatensatzes gespeichert werden sollen, sowie das Format der Anzeige dieser Metadaten vorzugeben. Im Allgemeinen ist es bei der Verarbeitung eines Ausnahmedatensatzes für den Qualitätsprüfungsingenieur hilfreich, den Kontext des Prozesses zum Zeitpunkt der Ausnahme zu kennen, und die Datenquellenmetadaten können als Informationen bereitgestellt werden, um dem Qualitätsprüfungsingenieur beim Verstehen dieses Kontexts zu helfen. Als solches kann das Konfigurationsfeld 162G angeben, welche Datenquellenmetadaten dem Qualitätsprüfungsingenieur als Teil des Ausnahmedatensatzes zur Verfügung gestellt werden sollen.
Natürlich kann die Konfigurationsanwendung 120 eine oder alle Regelkonfigurationsinformationen als Teil der Ausnahmeregel in der Regeldatenbank 124 auf irgendeine gewünschte Weise speichern. Es versteht sich, dass diese Konfigurationsinformationen die Identität von Daten enthalten können, die von einer Datenquelle benötigt werden, und diese Daten können, wie später beschrieben wird, dazu verwendet werden, die korrekten Daten oder Informationen von einer Datenquelle während des Betriebs der Datenquelle zu erhalten.
Natürlich kann die Konfigurationsanwendung 120 dazu verwendet werden, eine beliebige Anzahl von Ausnahmeregeln zu erstellen, und die Ausnahmeregeln können in der Regeldatenbank 124 auf einer Datenquelle nach Datenquellenart gespeichert werden, so dass unterschiedliche Regeln oder Regelsätze erstellt und für verschiedene Datenquellen (oder für verschiedene Aufträge, die einer einzelnen Datenquelle zugeordnet sind) gespeichert werden können. In jedem Fall kann die Konfigurationsanwendung 120 dazu verwendet werden, Regeln zu erstellen, und kann dies dadurch bewirken, dass sie es einem Benutzer ermöglicht, eine neue Regel zu erstellen (z. B. aus einer Vorlagenregel); kann es dem Benutzer ermöglichen, einen Namen für die durch die Regel zu erkennende Regel oder Ausnahme; Logik, die auf Daten aus einer bestimmten Datenquelle anzuwenden ist, die zu implementieren ist, um das Vorhandensein einer Ausnahme oder eine Abweichung von einer Norm basierend auf den Daten zu erkennen; eine Identifizierung eines Regel- oder Ausnahmetyps, den die Regel erkennt; einen Satz von Informationen, die einem Prüfer oder einem anderen Benutzer nach Erkennen einer Ausnahme durch die Regel zur Verfügung gestellt werden müssen (z. B. eine Erläuterung der Ausnahme, Daten oder Anweisungen, die zum Analysieren oder Freigeben der Ausnahme nützlich sind); eine Identifizierung eines Schweregrads (z. B. Bedeutung) der von der Regel erkannten Ausnahme; Metadaten (z. B. Daten aus der Datenquelle) zum Zustand des Prozesses (z. B. Batchlauf) zum Zeitpunkt der Ausnahme, die als Teil des Ausnahmedatensatzes gespeichert werden sollten; Prozesse oder Verfahren, die verwendet werden können oder verwendet werden müssen, um die Ausnahme zu beheben oder aufzulösen (z. B. Freigabeverfahren), und andere Daten oder Informationen, die als Teil eines Ausnahmedatensatzes gespeichert oder zur Verarbeitung eines Ausnahmedatensatzes verwendet werden sollten, vorzugeben.
Wichtig ist, dass dieses Konfigurationssystem oder diese Konfigurationsanwendung 120 einen signifikanten Vorteil gegenüber bekannten Produkten bietet, bei denen der Anbieter der Ausnahmesoftware die für das System definierten Ausnahmen in das Produkt fest codieren muss und die daher eine Software- oder Systemaktualisierung erfordern, um neue Ausnahmen zu erstellen. Für das Abrufen und Installieren dieser Aktualisierungen benötigt der Benutzer Zeit, und Benutzer können ihre eigenen Systeme nicht selbst anpassen.
Nachdem ein Satz von Ausnahmeregeln für eine oder mehrere Datenquellen erstellt wurde und diese Regeln beispielsweise in der Regeldatenbank 124 gespeichert sind, kann das Qualitätsprüfungsmanagementsystem 112 danach die Ausnahme-Engine 122 während des Betriebs einer Datenquelle in Echtzeit implementieren, um Ausnahmen zu erkennen, die auftreten können, wenn der zugrunde liegende Prozess von der Datenquellenanwendung überwacht, gesteuert oder ausgeführt wird. Wenn die Ausnahme-Engine 122 eingerichtet ist, um Daten aus einer bestimmten Datenquelle ablaufen zu lassen oder auszuführen, empfängt sie periodisch oder intermittierend Datensätze (z. B. Metadaten) von der Datenquelle, die verschiedene Betriebsparameter des Prozesses und/oder der Anwendung angeben, die den Prozess überwachen oder steuern. Für jeden Satz von Daten erhält und wendet die Ausnahme-Engine 122 die Logik der Ausnahmeregeln an, die für die Datenquelle erstellt wurden, um dadurch Ausnahmen in dem Prozess zu erkennen, der von der Datenquelle implementiert, verwaltet oder überwacht wird. Beim Bilden einer Schnittstelle oder Kommunizieren mit der Datenquelle kann die Ausnahme-Engine 122 periodisch Datensätze von der Datenquelle empfangen, wenn eine bestimmte Aktion oder bestimmte Aktionen im Prozess oder in der Datenquelle und/oder zu anderen konfigurierten Zeiten auftreten. Die Ausnahme-Engine 122 kann solche Daten basierend auf den Datenquellenkonfigurationsdaten innerhalb jeder der Ausnahmeregeln für die Datenquelle abonnieren, kann die Datenquelle zu verschiedenen Zeiten nach solchen Daten abfragen oder kann eine Kombination dieser Kommunikationstechniken implementieren. Auf diese Weise sendet die Workflow-Anwendung 40, wenn die Datenquelle, wie beispielsweise die Workflow-Anwendung 40, dazu fungiert, neue Daten zu empfangen und eine Schnittstelle mit einem Bediener zu bilden (z. B. um den Bediener beim Analysieren von Batchdaten vom Batch Executive 22 zu unterstützen), auch Daten (periodisch oder auf andere Weise) an die Ausnahme-Engine 122, die dann die Daten unter Verwendung der Ausnahmeregeln für die Workflow-Datenquellenanwendung 40 analysiert, um zu bestimmen, ob eine oder mehrere Ausnahmen in dem zugrunde liegenden Prozess aufgetreten sind.
Während dieses Prozesses zergliedert die Ausnahme-Engine 122, die eine Logik-Engine ist, die von der Datenquelle gesendeten Daten und wendet die Logik innerhalb des geeigneten Satzes von Regeln an, wie beispielsweise die Regeln 156A in der Datenbank 124, um dadurch die Daten gemäß den Regeln zu analysieren, um eine oder mehrere Ausnahmen zu erkennen. Die Ausnahme-Engine 122 kann die Regeln einzeln auf die Daten in der Reihenfolge anwenden, die in dem Satz von Regeln angegeben ist, der in der Regeldatenbank 124 gespeichert ist, und kann Ausnahmen erkennen, die durch die Regeln bestimmt sind, oder kann die Verarbeitung der Daten stoppen, wenn eine Ausnahme durch eine der Regeln für einen bestimmten Satz von Daten erkannt wird. Beim Erkennen einer Ausnahme erstellt die Ausnahme-Engine 122 einen Ausnahmedatensatz für diesen Satz von Daten und speichert den Ausnahmedatensatz in einer Ausnahmedatensatzdatei 170 (2) in der Datenbank 126. Da jeder neue Satz von Daten von der Workflow-Anwendung 40 (oder einer anderen Datenquelle) für die Ausnahme-Engine 122 bereitgestellt wird, verarbeitet natürlich die Ausnahme-Engine 122 diese Daten für Ausnahmen und bestimmt, ob Ausnahmen vorhanden sind, und erstellt und speichert dann Ausnahmedatensätze entsprechend in Ausnahmedatensatzdateien 170. Die Ausnahme-Engine 122 kann verschiedene unterschiedliche Arten von Daten speichern, die einem Ausnahmedatensatz zugeordnet sind, einschließlich beispielsweise eines Namens der identifizierten oder erkannten Ausnahme, eines Schweregrads der Ausnahme, der anzuwendenden Überprüfungs- oder Auflösungsverfahren und der vom Bediener eingegebenen Hinweise als Teil der von der Datenquelle gesendeten Daten, allgemeine Informationen über die Ausnahme usw. Ferner kann die Ausnahme-Engine 122 als Teil eines Ausnahmedatensatzes Metadaten bereitstellen, die auf irgendeine Weise den Betrieb des Batches oder anderer Prozessausrüstungen zum Zeitpunkt der Ausnahme definieren oder damit zusammenhängen. Diese Metadaten können der Ausnahme-Engine 122 als Teil der Daten aus der Datenquelle bereitgestellt werden oder können von der Ausnahme-Engine 122 aus der Datenquelle (z. B. der Workflow-Anwendung 40) oder aus einer Datenbank oder einer anderen Quelle dieser Daten getrennt von der Datenquelle erhalten werden. Die im Ausnahmedatensatz gespeicherten Metadaten können beliebige Daten sein, die einige Betriebsparameter, Werte, Zustände oder andere Informationen definieren, die dem Prozess zugeordnet sind, der zum Zeitpunkt des Erkennens der Ausnahme implementiert wird. Diese Metadaten können beispielsweise Batch-Zustandsinformationen, Prozessparameterwerte, wie sie vom Prozess gemessen oder bestimmt werden, Prozessausrüstungsinformationen, Alarm- oder Warninformationen aus der Prozessausrüstung oder andere Informationen sein. Darüber hinaus können diese Metadaten aus anderen Quellen wie Batch-Protokolldateien 34, Prozesssteuerungsdatenbanken oder - Historikern 31, Prozessausrüstungen, Batch-Historikern 30 usw. erhalten werden oder als Teil der anfänglichen von der Ausnahme-Engine 122 oder als Antwort auf eine Anfrage von der Ausnahme-Engine 122 verarbeiteten Daten direkt aus der Datenquelle selbst bereitgestellt werden. Im Allgemeinen stellen die gespeicherten Metadaten einen Speicherauszug des Prozesses (z. B. Prozesszustandsinformationen, Prozessausrüstungsinformationen, Prozessvariablenwerte, Batch-Verfahrensmodellzustände usw.) zum Zeitpunkt des Erkennens der Ausnahme bereit. Diese Metadaten können als Teil des Ausnahmedatensatzes angezeigt werden, damit ein Qualitätsingenieur den Kontext der Ausnahme verstehen kann (z. B. was zum Zeitpunkt der Ausnahme im Prozess geschehen ist), um dadurch die Ausnahme und die Bedeutung der Ausnahme besser zu verstehen.
Es versteht sich, dass die Ausnahme-Engine 122 in Echtzeit arbeitet, d. h. fortlaufend zusammen mit der Datenquelle, um die Daten aus der Datenquelle auf Ausnahmen zu analysieren und Ausnahmedatensätze für erkannte Ausnahmen in einer Ausnahmedatenbank 170 zu speichern. Die Ausnahme-Engine 122 kann dazu fungieren, neue Sätze von Datenpaketen von der Datenquelle, wie beispielsweise einer Workflow-Engine 40, für einen beliebigen Zeitraum zu empfangen. Beispielsweise kann die Ausnahme-Engine 122 Daten aus der Workflow-Anwendung 40 analysieren, während ein bestimmter Batch-Prozess ausgeführt wird, und kann nach Abschluss des Batch-Prozesses oder des Auftrags anhalten. Natürlich kann die Ausnahme-Engine 122 dazu fungieren, Ausnahmen für mehrere verschiedene Batchläufe gleichzeitig zu analysieren und zu erkennen, beispielsweise von derselben Datenquelle (z. B. der Workflow-Anwendung 40), und/oder kann Daten von verschiedenen Datenquellen gleichzeitig analysieren. In all diesen Fällen kann die Ausnahme-Engine 122 Ausnahmedatensätze für jeden unterschiedlichen Batchlauf einer einzelnen Datenquelle und/oder für jede unterschiedliche Datenquelle gleichzeitig erstellen und speichern. Somit kann die Ausnahme-Engine 122 verstehen, dass verschiedene Batchläufe zur gleichen Zeit auftreten oder dass Daten aus verschiedenen Quellen über den gleichen Zeitraum verarbeitet werden, und kann diese Läufe und Prozesse separat verfolgen, um unterschiedliche Ausnahmedatenbanken 170 für jeden Batchlauf, Auftrag und/oder jede Datenquelle zu erstellen.
4 veranschaulicht den Betrieb der Ausnahme-Engine 122 an mehreren verschiedenen Datenquellen 180, 182, 184 und 186. Die Datenquellen 180-186 können die gleichen Arten von Datenquellen sein (z. B. verschiedene Instanzen von Workflow-Anwendungen 40, die unterschiedliche Batches ausführen oder unterschiedliche Produkte herstellen), und/oder können verschiedene Arten von Datenquellen sein, wie beispielsweise Ereignisüberwachungsanwendungen oder -systeme, proprietäre Systeme oder Anwendungen von Drittanbietern, usw. In diesem Fall sind die Ausnahme-Engine 122 und/oder die Datenquellen 180-186 so konfiguriert, dass sie periodisch Datenpakete 188 mit Datenquellen-Metadaten von der Ausnahme-Engine 122 empfangen und an sie senden. Diese Datenpakete 188 können so formatiert sein, dass sie Daten aus der Datenquelle enthalten, wie durch die Metadatenkonfigurationsinformationen in den Regeln für die Datenquelle vorgegeben, und diese Datenpakete 188 können eine Kennung der Datenquelle enthalten, wobei die Reihenfolge von der Datenquelle, den Datenquellen-Metadaten usw. implementiert wird.
Die Ausnahme-Engine 122 empfängt und verarbeitet jedes der Datenpakete 188 aus verschiedenen Datenquellen 180, 182, 184 und 186, wenn diese Pakete empfangen werden. Für jedes Paket 188 kann die Ausnahme-Engine 122 die Identität der Datenquelle und Reihenfolge bestimmen (wie durch Daten innerhalb des Datenpakets 188 angegeben), den geeigneten Satz von Regeln aus der Regeldatenbank 124 für diese Datenquelle erhalten und die erhaltenen Regeln in einer vordefinierten Reihenfolge auf die Daten innerhalb des Datenpakets 188 anwenden, um zu bestimmen, ob eine Ausnahme vorliegt. Wenn die Ausnahme-Engine 122 alle Regeln für eine Datenquelle verarbeitet, ohne eine Ausnahme zu erkennen, wartet die Ausnahme-Engine 122 auf das nächste Datenpaket 188 (von derselben oder einer anderen Datenquelle) oder beginnt mit der Verarbeitung. Wenn andererseits die Ausnahme-Engine 122 eine Ausnahme basierend auf der Anwendung der Regellogik auf die Datenquellenmetadaten erkennt, erstellt die Ausnahme-Engine 122 einen Ausnahmedatensatz 180 für den Auftrag und speichert diesen Ausnahmedatensatz in einer Ausnahmedatensatzdatenbank 126 als Ausnahmedatensatzdatei oder -datenbank 170 für einen Auftrag. Das heißt, alle Ausnahmedatensätze für einen bestimmten Auftrag können als Satz von Ausnahmedatensätzen für diesen Auftrag gespeichert werden. In jedem Fall kann die Ausnahme-Engine 122, wie durch das Diagramm von 4 angegeben, gleichzeitig mit Daten aus verschiedenen unterschiedlichen Datenquellen und/oder für verschiedene unterschiedliche Aufträge (aus derselben oder verschiedenen Datenquellen) arbeiten, um Ausnahmedatenbanken für jeden Auftrag zu erzeugen.
Ein zusätzlicher Vorteil der Ausnahme-Engine 122 besteht darin, dass sie in Echtzeit arbeitet, d. h. während des Betriebs des zugrunde liegenden Prozesses, und so das Auftreten einer Ausnahme in Echtzeit erkennen kann, z. B. wenn die Ausnahme auftritt. Infolgedessen besteht ein Merkmal der Ausnahme-Engine 122 darin, dass die Ausnahme-Engine 122 beim Erkennen des Auftretens einer Ausnahme den Bediener oder einen anderen Mitarbeiter an der Datenquelle sofort oder in Echtzeit über das Vorhandensein der Ausnahme informieren kann, was es dem Bediener oder einer anderen Person ermöglichen kann, innerhalb des Prozesses Aktionen vorzunehmen, um die Ausnahme abzuschwächen oder zu vermeiden. In einigen Fällen können Ausnahmeregeln dazu konfiguriert werden, das mögliche Auftreten einer zukünftigen Ausnahme basierend auf Aktionen oder Zuständen des aktuellen Prozesses zu erkennen. In diesem Fall kann die Ausnahme-Engine 122 das mögliche oder wahrscheinliche Auftreten einer Ausnahme erkennen und den Bediener oder einen anderen Benutzer in Echtzeit darüber informieren, dass wahrscheinlich eine Ausnahme auftritt. Diese Benachrichtigung bietet dem Bediener oder einem anderen Benutzer die Möglichkeit, eine Aktion rückgängig zu machen oder einen Parameter zu ändern, der die Hauptursache für die künftige Ausnahme ist, bevor die Ausnahme auftritt. Dieses Live-Feedback kann daher dazu verwendet werden, Ausnahmen zu vermeiden oder sofort abzuschwächen, indem es dem Bediener oder anderen Prozessüberwachungs- oder Steuerungsmitarbeitern ermöglicht, Aktionen vorzunehmen, um die Bedingungen, die zur Ausnahme führen, zu vermeiden oder rückgängig zu machen.
5 veranschaulicht eine Bildschirmanzeige 200, die beispielsweise von der Workflow-Anwendung 40 von 2 einem Bediener als Teil des normalen Betriebs der Workflow-Anwendung 40 bereitgestellt werden kann. In diesem Fall kann die Anzeige 200 dem Bediener Prozessinformationen in Form eines Prozess- oder Workflow-Diagramms 202 bereitstellen und es dem Bediener ermöglichen, über Eingabefelder 204 eine Aktion oder Aktionen im Prozess vorzunehmen. In diesem Fall kann der Bediener einen Sollwert eines bestimmten Prozessparameters unter Verwendung des Eingabefeldes 204 auf dem Bildschirm 200 ändern. Wenn der Bediener jedoch einen neuen Sollwert eingibt oder unmittelbar danach, sendet die Workflow-Anwendung 40 ein Datenpaket an die Ausnahme-Engine 122 mit Daten, die diese Änderung anzeigen. In diesem Beispiel kann die Ausnahme-Engine 122 so programmiert werden, dass sie eine Regel implementiert, um zu bestimmen, ob der Wert des Prozessparameters innerhalb eines bestimmten Bereichs liegt (da dieser Prozessparameter ein für Qualitätszwecke kritischer Prozessparameter sein kann). Die Ausnahme-Engine 122 kann beim Ausführen der Regel erkennen, dass der kritische Parameter außerhalb des gewünschten Bereichs eingestellt wird, und führt daher zu einer Ausnahme, wenn der Sollwert geändert wird. Die Ausnahme-Engine 122 kann dann sofort eine Benachrichtigung über eine Live-Rückmeldungsnachricht an die Anwendung 40 senden, was dazu führen kann, dass dem Bediener eine Mitteilung oder ein Alarm bereitgestellt wird. Zum Beispiel kann, wie in 5 veranschaulicht, ein Popup-Fenster 206 auf dem Bildschirm 200 basierend auf der Live-Rückmeldungsnachricht erstellt werden, das dem Bediener mitteilt, dass die beabsichtigte Aktion oder die gerade vorgenommene Aktion zur Erstellung eines Ausnahmedatensatzes führt (oder führte). Diese Nachricht in dem Popup-Fenster 206 kann den Bediener anweisen, eine Aktion vorzunehmen, um die Ausnahme zu vermeiden oder (falls sie bereits aufgetreten ist) abzuschwächen. Es versteht sich daher, dass Regeln, wie sie in der Regeldatenbank 124 für eine Datenquelle erstellt und gespeichert werden, das Erkennen tatsächlicher Ausnahmen und/oder das Erkennen des wahrscheinlichen Auftretens einer Bedingung, die in Zukunft zu einer Ausnahme führt, betreffen können. Darüber hinaus kann das Live-Feedback-Merkmal der Ausnahme-Engine 122 dazu verwendet werden, es einem Benutzer zu ermöglichen, das Auftreten einer Ausnahme in Zukunft zu vermeiden oder die Bedingungen abzuschwächen oder rückgängig zu machen, die zu einer derzeit erkannten Ausnahme führen. Da diese Mitteilung in Echtzeit bezogen auf den Prozessbetrieb erfolgt, ist es viel wahrscheinlicher, dass die Auswirkung der Ausnahme mit Hilfe dieser Live-Qualitäts-Feedback-Technik rückgängig gemacht oder abgeschwächt werden kann.
Während 2 den Betrieb eines Qualitätsprüfungsmanagementsystems 112 in einer Prozessanlagenumgebung 110 veranschaulicht, in der verschiedene Anteile des Systems 112 in dedizierten Servern und Datenbanken ausgeführt werden, kann das Qualitätsprüfungsmanagementsystem 112 in einer Plug-in-Umgebung implementiert werden, wodurch das System erheblich portabler wird, einfacher auf mobilen oder dezentralen Geräten verwendet werden kann, einfach zu warten und in einer dezentralen Umgebung zu implementieren ist und einfach für die Verwendung mit Systemen oder Anwendungen von Drittanbietern konfiguriert werden kann. Insbesondere veranschaulicht 6 das QRM-(Quality Review Management - Qualitätsprüfungsmanagement)-System 300, das unter Verwendung von Plug-ins implementiert ist. Das Qualitätsprüfungsmanagementsystem 300 von 6 schließt ein Qualitätsprüfungsdienstgerät 302 (das auf einem Server oder einem anderen Rechengerät gespeichert und ausgeführt werden kann), das kommunikativ mit verschiedenen Datenquellen 304A, 304B, 304C usw. gekoppelt ist, eine Regeldatenbank 124 und eine Konfigurationsanwendung 122 ein. Darüber hinaus ist das Qualitätsprüfungsmanagement-Dienstgerät 302 mit verschiedenen Plug-ins 310, 312, 314, 316 usw. gekoppelt, die in jedem gewünschten Rechengerät gespeichert und ausgeführt werden können, beispielsweise auf Arbeitsstationen innerhalb oder außerhalb der Anlagenumgebung, in mobilen Geräten wie Laptops, Telefonen usw. oder in anderen Geräten. Die Plug-ins 312-314 können nach Bedarf für einen bestimmten Auftrag oder eine bestimmte Datenquelle erstellt (instanziiert und ausgegliedert) werden. In diesem Fall kann jedes Plug-in 310-316 für eine bestimmte Datenquelle und/oder für einen bestimmten Auftrag innerhalb einer Datenquelle erstellt werden, um die Daten aus dieser Datenquelle zur Erkennung von Ausnahmen zu analysieren. Plug-ins können zerstört werden, wenn der Auftrag oder die Anwendung geschlossen oder beendet wird.
Im Allgemeinen kann das QRM-Dienstgerät 302 als Reaktion auf eine Konfigurationsanwendung 122 ein bestimmtes Plug-in für eine bestimmte Datenquelle oder einen bestimmten Auftrag aus einer bestimmten Datenquelle erstellen. Jedes Plug-in 310-316 kann Konfigurationsinformationen enthalten, die als Teil der Konfiguration des Plug-ins 310-316 bereitgestellt werden, um das Plug-in 310-316 über die Daten und das Datenformat der Informationen, die an das Plug-in 310-316 zur Auswertung gesendet werden, die Stelle, an der eine Ausnahmedatensatzdatei oder -datenbank für die Datenquelle oder den Auftrag gespeichert werden soll, sowie andere gewünschte Konfigurationsdaten, die für den Betrieb des Plug-ins 310-316 benötigt werden, zu informieren. Darüber hinaus können die Konfigurationsdaten für das Plug-in 310-316, falls gewünscht, eine oder mehrere Regeln enthalten, die basierend auf den empfangenen Daten anzuwenden oder zu analysieren sind. Natürlich kann jedes Plug-in 310-316 derselben Datenquelle oder verschiedenen Datenquellen zugeordnet oder für diese konfiguriert werden, sodass die Konfigurationsinformationen für jedes Plug-in 310-316 je nach Datenquelle oder Verwendung des Plug-ins 310-316 ähnlich oder sehr unterschiedlich sein können. Die Konfigurationsinformationen jedes Plug-ins 310-316 können auch die Daten vorgeben, die während des Betriebs vom QRM-Dienstgerät 302 oder von einer Drittanbieteranwendung oder -quelle abonniert oder empfangen werden sollen, und die Plug-ins 310-316 können sich beim QRM-Dienstgerät 302 oder anderen Anwendungen oder Quellen registrieren, um diese Daten zu empfangen. Im Allgemeinen können die Plug-ins 310-316 einfach dazu fungieren, bestimmte Daten von einer Datenquelle zu erhalten, und müssen daher nur dazu konfiguriert werden, zu verstehen, welche Daten von der Datenquelle kommen und welches Format diese Daten haben. Die Plug-ins 310-316 können dann die Daten von der Datenquelle empfangen und verarbeiten und die empfangenen Daten in ein Format bringen, das von den für die Datenquelle erstellten Ausnahmeregeln verwendet wird. Auf diese Weise können die Plug-ins 310-316 als Datenerhebungs- und -interpretationsanwendungen für alle Arten von Datenquellen fungieren, selbst für Datenquellen von Drittanbietern oder proprietären Datenquellen.
Darüber hinaus kann jedes Plug-in 310-316 eine Laufzeitverarbeitungskonfiguration enthalten, die den Betrieb des Plug-ins 310-316 während des Betriebs definiert oder steuert. Dieser Laufzeitabschnitt kann einen Logikparser enthalten, der Regeln oder Logik innerhalb der Ausnahmeregeln für eine Datenquelle verwendet, um empfangene Daten von einer Datenquelle zu analysieren und Ausnahmedatensätze in einer Ausnahmedatensatzdatenbank oder einem -protokoll 170 zu erstellen und zu speichern. Im Wesentlichen implementiert der Laufzeitabschnitt eines Plug-ins 310-316 die Ausnahme-Engine 122 von 2 auf der Basis von einzelnen Instanzen. Somit können, wie vorstehend erwähnt, die Plug-in-Module 310-316 erstellt werden, um eine Schnittstelle der Ausnahme-Engine 122 mit externen Systemen oder Systemen von Drittanbietern (z. B. Steuerungssysteme, OPC-Schnittstellen, Wartungssysteme usw.) zu bilden, wodurch das Generieren von Ausnahmen ganz oder teilweise basierend auf Daten von Drittanbietern oder externen Softwaresystemen ermöglicht wird. In einem Beispiel werden Plug-ins erstellt, um auf bestimmte Daten innerhalb eines oder von einem Drittanbieter(s) oder externen System zuzugreifen und diese Daten an die Ausnahme-Engine 122 zu übergeben, um zu analysieren, ob eine Ausnahme erstellt werden sollte oder nicht. Die Plug-ins 310-316 können jedoch auf einem Server eines Drittanbieters, auf dem QRM-Dienstgerät 302 oder auf einem anderen Server, Mobilgerät oder einem anderen Verarbeitungsgerät gespeichert und ausgeführt werden.
Beispielsweise kann die Konfigurationsanwendung 122 von 6 dazu verwendet werden, ein oder mehrere Plug-ins 310-316 zu erstellen, einschließlich des Vorgebens des Formats von Daten, die von der Datenquelle empfangen werden sollen, die vom Plug-in 310-316 analysiert werden sollte, wie oft das Plug-in 310-316 Daten von der Datenquelle empfangen sollte, der Identität eines Auftrags und anderer Informationen über die Datenquelle, der Art der Anwendung, für deren Verarbeitung das Plug-in 310-316 verwendet wird, usw.
Darüber hinaus können die Plug-in-Module 310-316 mit Datenerfassungsfunktionalität und auf Wunsch mit Laufzeitausnahmeverarbeitungsfunktionen erstellt werden. Nach dem Erstellen können die Plug-ins 310-316 an einer beliebigen geeigneten Stelle oder einem Verarbeitungsgerät gespeichert und darin ausgeführt werden, beispielsweise einem Gerät in der Nähe der Datenquelle oder der Datenquellen. Darüber hinaus können sich die Plug-ins 310-316 beim Datendienstgerät 302 (oder bei jedem anderen Server oder Gerät) registrieren, um Daten von der geeigneten Datenquelle, wie beispielsweise einer der Datenquellen 304, zu empfangen. Das QRM-Dienstgerät 302 kann dann die Datenquellen 304 abonnieren oder nach den geeigneten Daten abfragen und nach dem Empfang eines Datenpakets von einer Datenquelle die Daten und eine oder mehrere Ausnahmeregeln für die Datenquelle für das Plug-in-Modul 310-316 bereitstellen, das zum Analysieren dieser Daten genutzt wird. Das Plug-in 310-316 kann dann die Regel oder Regeln in seiner Logik-Engine dazu verwenden, die Daten auf Ausnahmen zu analysieren, und kann beim Erkennen einer Ausnahme einen Ausnahmedatensatz in einer Ausnahmedatensatzdatenbank 170 für die Datenquelle speichern. Somit versteht sich, dass das QRM-Dienstgerät 302 als Datenbroker für die Plug-ins 310-316 agiert, die unabhängig voneinander auf jedem gewünschten Gerät unter Verwendung von beliebigen Daten oder Daten, die aus verschiedenen Quellen erhalten wurden, arbeiten können.
Es versteht sich, dass das Qualitätsprüfungsmanagementsystem 128 die Verwendung von Plug-ins oder Plug-in-Modulen auf der Basis von Einzelquellen implementieren kann, um die hier beschriebene Funktionalität der Ausnahme-Engine auszuführen, um die einfache Konfigurierbarkeit des Qualitätsprüfungsmanagementsystems für verschiedene Datenquellen, für verschiedene Qualitätsprüfungsstandards und/oder das einfache Ausführen in einer dezentralen Umgebung zu ermöglichen, in der verschiedene Teile des Systems auf verschiedenen Computern ausgeführt werden, die in einer Anlage verteilt sind. In diesem Fall kann für jeden Datenquellentyp ein anderes Plug-in erstellt werden, und jedem Plug-in kann ein eigener Satz von Regeln zugeordnet sein, die zur Durchführung der Ausnahmeerkennung aus einer bestimmten Datenquelle verwendet werden.
Darüber hinaus können die Plug-in-Module 310-316 eine Ausnahmeverarbeitung und - erkennung in einer Batch- oder Auftragsverarbeitungsumgebung durchführen oder nicht. In einigen Fällen können beispielsweise eines oder mehrere der Plug-ins 310-316 erstellt werden, um eine Prozess- oder Ereignisüberwachung innerhalb einer Anlage durchzuführen oder zu verbessern, oder um eine Qualitätsprüfung innerhalb einer Anlage durchzuführen, beispielsweise innerhalb einer kontinuierlichen Prozessfertigungsanlage. Somit können die Plug-ins 310-316 einfache Systemdatenerhebungsprogramme von Drittanbietern sein oder Daten erheben und zusätzlich eine Ausnahmeverarbeitung durchführen oder eine Ausnahme oder vorverarbeitete Ausnahmedaten für eine eigenständige Ausnahme-Engine bereitstellen. Die Verwendung von Plug-ins zur Implementierung der Qualitätsprüfung ist vorteilhaft, da bekannte Qualitätsprüfungsprodukte nicht in der Lage sind, Schnittstellen mit Ausnahmen zu bilden oder Ausnahmen zu erstellen, die auf Daten basieren, die direkt von externen Softwareprogrammen wie Steuerungssystemen, Sicherheitssystemen, Wartungssystemen usw. bereitgestellt werden. Weiterhin macht die Verwendung einer Plug-in-Modulumgebung das hier beschriebene Qualitätsprüfungsmanagementsystem 112 in einer komplizierten Prozessumgebung mit mehreren verschiedenen Softwaresystemen, die zur Laufzeit arbeiten, wesentlich robuster.
7 veranschaulicht ein Beispiel eines Daten- oder Ereignisüberwachungssystems unter Verwendung der hierin beschriebenen Verarbeitungstechniken für Qualitätsprüfungsausnahmen. Insbesondere zeigt 7 ein High-Level-Diagramm einer Prozessanlage 400, die kontinuierliche Prozesse oder Prozessanlagen ausführen kann. Wie in 7 veranschaulicht, schließt die Prozessanlage 400 eine Prozesssteuerungsausrüstung 402 ein, die beispielsweise dem Ausführen oder Implementieren eines kontinuierlichen Prozesses (wie eines Rohölraffinerieprozesses) oder eines Batch-Prozesses oder beidem zugeordnet sein kann. Die Prozessanlage 400 kann einen oder mehrere Batch Executives 404 einschließen, die mit der Prozesssteuerungsausrüstung 402 verbunden sind, und eine oder mehrere Bedienerschnittstellen 406, die einen oder mehrere Abschnitte oder Teile der Prozesssteuerungsausrüstung 402 überwachen. Ferner können die Batch Executives 404 und die Bedienerschnittstellen 406 mit einem Hauptanlagensteuergerät 410 verbunden sein, das Konfigurations- und Steuerungsinformationen für die Anlage 400 speichern kann. Darüber hinaus kann die Anlage 400 einen oder mehrere Anwendungsserver 411 enthalten, auf denen andere Anwendungen ausgeführt werden können, einschließlich beispielsweise Datenbankanwendungen, Überwachungsanwendungen, Anlagenanalyseanwendungen usw.
In vielen Fällen werden in den Anlagen-Assets der Anlage 400 proprietäre oder Drittanbieter-Kontroll-, Überwachungs- und Asset-Verwaltungssysteme ausgeführt, die während des Betriebs eine große Datenmenge aus der Anlage sammeln. Darüber hinaus können die Bedienerüberwachungsanwendungen und -schnittstellen 406, die Batch Executive 404 oder andere Steuerungsanwendungen ebenfalls prioritär sein. In der Prozesssteuerungstechnologie ist die Verwendung von OPC-Schnittstellen bekannt, um Daten von verschiedenen Anwendungen von Drittanbietern oder proprietären Anwendungen zu erhalten. Somit kann jede der Bedienerschnittstellen 406 beispielsweise eine OPC-Alarm- und Ereignis-(OPCae) 412 -Schnittstelle oder eine OPC-Datenzugriffs-(OPCda) 412 -Schnittstelle enthalten, um die Erkennung und Verwendung von Alarm- und Ereignisdaten (wie in der Anlage 400 beispielsweise in der Prozessausrüstung 402 generiert) oder anderen Prozessdaten, die von externen Systemen verwendet werden sollen, zu ermöglichen. Zusätzlich können in einigen Fällen eine oder mehrere Überwachungsanwendungen 414 in einem oder mehreren der Anlagengeräte gespeichert sein, beispielsweise auf dem Anwendungsserver 411 oder einem separaten Ereignismonitorserver 416. Die Ereignisüberwachungsanwendungen 414 können bekannte Anwendungen sein, die verwendet werden, um mit einem oder mehreren der Batch Executives 404 eine Schnittstelle zu bilden, um Prozessereignisinformationen zu erhalten (jedoch nicht notwendigerweise über eine OPC-Schnittstelle), und/oder können dazu konfiguriert sein, mit einer oder mehreren der OPCae- oder OPCda-Schnittstellen 412 zum Erhalten von Alarm- und Ereignisdaten oder anderen Daten vom Prozesssteuerungsnetzwerk 402 zu kommunizieren. Die Ereignismonitoranwendungen 414 werden traditionell dazu verwendet, Prozessdaten wie Ereignis- und Alarminformationen aus den Anlagen-Assets zu erhalten und diese Daten in einer Datenbank zur späteren Überprüfung oder Verwendung in verschiedenen Systemen wie Prozesssteuerungsanalysesystemen, Wartungssystemen, usw. zu speichern.
Die hier beschriebene Ausnahmeverarbeitungsstruktur kann jedoch verwendet werden, um Alarm- und Ereignis- und andere Informationen zu verarbeiten, wie sie aus den Ereignisüberwachungsanwendungen 414 erhalten wurden, um zu bestimmen, ob bestimmte Anlagenzustände innerhalb oder während des Betriebs der Anlagenausrüstung 402 auftreten. Zu solchen Bedingungen kann - nur beispielsweise - gehören, wenn bestimmte Ereignisse oder Alarme ein kritisches Niveau erreichen, wenn ein bestimmter Satz oder eine bestimmte Kombination von Alarmen oder Ereignissen zusammen auftreten, wenn verschiedene Prozessbedingungen vorliegen, oder es kann ein anderer Satz von Bedingungen zu diesen gehören, der auf ein Problem hinweist, das möglicherweise einem Benutzer irgendeiner Art, wie einem Qualitätsprüfungsingenieur, einem Sicherheitsingenieur usw., mitgeteilt werden muss. Um diese Funktion auszuführen, kann ein Ereignismonitor-Plug-in 450 von 7 dazu verwendet werden, auf Daten von einem oder mehreren der Ereignisüberwachungsanwendungen 414 innerhalb der Anlage 400, einer oder mehreren der OPCae- und/oder OPCda-Schnittstellen 412 innerhalb der Anlage 400 usw. zuzugreifen. Das Ereignisüberwachungs-Plug-in 450 kann Daten von den Ereignisüberwachungsanwendungen 414, OPCae und OPCda-Schnittstellen 412 oder anderen Datenquellen in der Anlage 400 empfangen und kann eine Ausnahmeregelverarbeitung durchführen, um das Vorliegen bestimmter, typischerweise komplexerer Bedingungen in der Anlage 400 zu erkennen. Das heißt, es können in der Anlage 400 Bedingungen vorliegen, über die ein Qualitätsprüfungsingenieur, ein Sicherheitsingenieur, ein Wartungsingenieur, ein Prozesssteuerungsingenieur oder eine andere Person unter Umständen Bescheid wissen möchte, die jedoch von den Prozesssteuerungs- oder -überwachungssystemen nicht anderweitig erkannt werden, wenn diese Systeme eingerichtet sind und die Anlage 400 führen. Im Allgemeinen können diese Bedingungen nicht einfach durch einen einzelnen Alarm oder eine Ereignisbenachrichtigung bestimmt werden, der bzw. die in der Anlage 400 generiert wird, sondern müssen stattdessen unter Umständen durch das Vorhandensein eines komplexeren Satzes von Bedingungen in der Anlage 400 bestimmt werden, wie beispielsweise eines Alarms wegen Überschreitung eines bestimmten kritischen Niveaus, einer bestimmten Anzahl von Alarmen eines Typs, die zur gleichen oder ungefähr zur gleichen Zeit auftreten, eines Alarms eines bestimmten Typs oder Schweregrads in Verbindung mit einem oder mehreren anderen Ereignissen in der Anlage 400 usw. Es versteht sich, dass das Plug-in-Modul 450 eine Ausnahme-Engine (wie hierin anderweitig beschrieben) enthalten oder Zugriff darauf bereitstellen kann, die mit Regeln arbeitet, die Logik implementieren, um diese „Ausnahmen“ beim Betrieb der Anlage 400 zu bestimmen. Somit kann der Ereignismonitor 450 von 7 Daten von Anwendungen von Drittanbietern (Ereignisüberwachungsanwendungen 414) oder Systemen (Ereignismonitor-Servern 416) oder Schnittstellen (OPCae-Schnittstellen 412) sammeln und diese Daten unter Verwendung eines Satzes vorkonfigurierter Regeln zum Durchführen verbesserter Ereigniserkennung oder Prozessüberwachung oder Ausnahmeverarbeitung zu Qualitätsprüfungszwecken verwenden. In diesem Fall kann die Ereignisüberwachungsanwendung 450 (die sich in einer anderen Umgebung als der Anlagenumgebung befinden kann, wie durch die gestrichelte Linie von 7 angegeben) die Ergebnisse der Regelanalysen an eine Überwachungsschnittstelle 452 und/oder eine Datenbank 454, wie beispielsweise eine SQL-(Sequel)-Datenbank, zur späteren Überprüfung bereitstellen. Im Wesentlichen arbeitet das Ereignisüberwachungs-Plug-in 450 so, dass es „Ausnahmen“ beim Betrieb der Anlagenausrüstung 402 auf der Basis von Ereignisüberwachungsdaten erkennt, die von der Anlagenausrüstung 402 gesammelt und für Anwendungen oder Schnittstellen von Drittanbietern in der Anlage 400 bereitgestellt werden. Diese Art von Überwachung wird hier nach wie vor als Ausnahmeverarbeitung bezeichnet, da diese Überwachung Ausnahmen im Betrieb der Anlage 400 erkennt, selbst wenn sie nicht als Teil eines Qualitätsprüfungsprozesses durchgeführt wird.
In jedem Fall kann der Ereignismonitor 450 an eines oder mehrere Drittanbieter- oder externe Systeme gebunden sein und kann dazu verwendet werden, Nachrichten zu generieren und an eine Regel-Engine (nicht dargestellt) zu senden, die diese Nachrichten dann verwenden kann, um eine Ausnahmeverarbeitung oder Ausnahmeerstellung in Form von Überwachungsnachrichten, Benachrichtigungen, Alarmen usw. durchzuführen. In einem Fall kann der interne Ereignismonitor 450 an eine OPCae-Schnittstelle 412 gebunden oder mit dieser gekoppelt sein und kann erkennen, wenn eine oder mehrere Warnungen oder Alarme von der OPCae-Schnittstelle 412 übergeben werden. Zu diesem Zeitpunkt erstellt die Ereignismonitoranwendung 414 oder die OPC-Schnittstelle 412 eine Nachricht mit den Warn- oder Alarminformationen und möglicherweise allen anderen gewünschten von OPC gesammelten Daten und schickt sie an das externe Ereignisüberwachungssystem 450. Das System 450 kann dann die Nachrichten analysieren, um Ausnahmen basierend auf den Daten in den Nachrichten zu generieren. Dieser Vorgang ist vorteilhaft, da bekannte Qualitätsprüfungssysteme Daten von Systemen von Drittanbietern nicht analysieren und nicht mit den vorhandenen OPC-Warn- und Alarmschnittstellen verbunden sind. Daher können diese Systeme keine Ausnahmen generieren, die beispielsweise auf Prozessalarmen und - warnungen basieren.
Im Allgemeinen kann das Ereignisüberwachungssystem 450 von 7 auf verschiedene Arten konfiguriert werden, um Alarm- und Ereignisdaten von dem Prozesssteuersystem 402 zu sammeln und zu verarbeiten, um ein erweitertes Überwachungssystem unter Verwendung einer Ausnahmeverarbeitung zu erzeugen. Insbesondere kann ein Benutzer das Ereignisüberwachungssystem oder -modul 450, das ein Plug-in sein kann, wie vorstehend beschrieben, zum Abonnieren und Sammeln von Daten (z. B. Ereignis- und Alarmdaten, Nachrichten usw.) konfigurieren, wie sie beispielsweise von den OPCae- und OPCda-Schnittstellen 412 von 7 gesammelt werden. Der Ereignisüberwachungsserver 416, der diese Daten sammelt, kann diese Daten dann in Datenpaketen zusammen mit anderen Informationen, wie z. B. Zeitinformationen, Prozesssteuerungsmetadaten (die von den OPC-Schnittstellen 412, dem Batch Executive 404, dem Prozesscomputer 410 usw. erhalten wurden), an die Ereignisüberwachungsanwendung 450 senden. Das Ereignisüberwachungssystem 450 kann dann einen Satz von Regeln auf die Daten anwenden, wie vorstehend beschrieben, um zu bestimmen, ob auf der Basis der gesammelten Ereignisse und Alarmdaten und der Regellogik Ereignisüberwachungsausnahmen existieren. Wenn eine Ausnahme bestimmt wird, kann das Ereignisüberwachungssystem 450 eine Nachricht (basierend auf der Regel) erstellen und diese Nachricht an die Überwachungsschnittstelle 452 senden, um sie einem Benutzer anzuzeigen, und/oder an eine Datenbank oder Nachrichtenwarteschlange 454, beispielsweise in einem Sequel-Server. Die Regel, die die Ausnahme generiert hat, kann natürlich den Inhalt der Nachricht, das Format der Nachricht, die Informationen, die in der Nachricht platziert werden sollen, die Schnittstelle(n), an die die Nachricht gesendet werden soll, usw. vorgeben. Darüber hinaus oder stattdessen kann das Ereignisüberwachungssystem 450 einen Ausnahmedatensatz erstellen und an eine Überwachungsdatenbank zum Speichern und späteren Abrufen senden. Dieser Ausnahmedatensatz (der ein Überwachungsbedingungsdatensatz ist) kann beliebige Informationen basierend auf der Regelkonfiguration enthalten und kann beispielsweise eine Erläuterung des Ereignisses, den Schweregrad des Ereignisses, Anweisungen zum Beheben des Ereignisses, Prozessmetadaten zum Zeitpunkt des Ereignisses usw. enthalten. Es versteht sich, dass in diesem Fall die Regellogik für das Ereignis in dem Ereignisüberwachungssystem 450 (oder in einer damit gekoppelten Ausnahme-Engine) verarbeitet wird und in oder unter Verwendung einer Plug-in-Umgebung, wie der von 6, oder in einer herkömmlichen Serverumgebung, wie der von 2, verarbeitet werden kann.
In einem anderen Fall kann das Ereignisüberwachungssystem 450 basierend auf seiner Konfiguration die OPC-Schnittstellen 412 dazu konfigurieren, beispielsweise bestimmte Bedingungen oder Kombinationen von Bedingungen zu erkennen und dem Ereignisüberwachungssystem 450 dann eine Nachricht zu senden, wenn diese Bedingungen erfüllt sind. In diesem Fall programmiert das Ereignisüberwachungssystem 450 im Wesentlichen die OPCae- oder OPCda-Schnittstellen 412, um die Logik der Regel durchzuführen und nur dann Nachrichten oder Daten an das Ereignisüberwachungssystem 450 zu senden, wenn diese Logik erfüllt ist. Beim Empfangen einer Nachricht von der OPCae-Schnittstelle 412 mit einer Nachricht, die angibt, dass ein bestimmter Satz von Bedingungen oder Logik erfüllt ist, kann das Ereignisüberwachungssystem 450 einfach eine Kommunikation erstellen und an die Ereignisüberwachungsschnittstelle 452 und die Datenbank 454 senden, um einen Benutzer über die Bedingung zu benachrichtigen und einen Ausnahmedatensatz in der Datenbank 454 zu speichern. In diesem Fall wird die Logik der Regeln für das Ereignisüberwachungssystem ganz oder teilweise in den OPC-Schnittstellen 412 oder externen Ereignisüberwachungsanwendungen 414, 416 ausgeführt, die unter Verwendung bekannter Techniken dazu konfiguriert sein können, diese Logik zu implementieren und nur dann Nachrichten zu senden, wenn in der Prozessanlage 400 bestimmte Bedingungen vorliegen.
Somit kann in dem Beispielsystem von 7 die ausnahmebasierte Verarbeitung des hierin beschriebenen Qualitätsprüfungsmanagementsystems dazu verwendet werden, Ausnahmen in Daten von Systemen von Drittanbietern zu analysieren, zu überprüfen oder zu erkennen, die nicht das gleiche Datenformat wie z. B. die Workflow-Anwendung 40 verwenden. Während im Fall von 7 das Qualitätsprüfungsmanagementsystem in seiner Verwendung als Ereignisüberwachungssystem veranschaulicht wird, um über eine oder mehrere OPC-Schnittstellen 412 eine Schnittstelle mit einem Batch- oder kontinuierlichen Prozesssteuerungssystem herzustellen, um auf Überwachung basierende Ausnahmen basierend auf dem Vorhandensein von verschiedenen Ereignissen, Alarmen, Parametereinstellungen usw. zu bestimmen, könnte das hier beschriebene Qualitätsprüfungsmanagementsystem über andere gewünschte Schnittstellen mit Prozessgeräten, Servern, Anwendungen usw. von Drittanbietern verbunden werden.
Unter erneuter Bezugnahme auf 2 kann die Qualitätsprüfungsschnittstellenanwendung 128 dazu ausgeführt werden, einem Benutzer, wie beispielsweise einem Qualitätsprüfungsingenieur, den Zugriff auf eine oder mehrere Ausnahmedatensatzdatenbanken 170 für einen oder mehrere Batchläufe, Aufträge, Prozessvorgänge usw. aus einer bestimmten Datenquelle zu ermöglichen. Die Qualitätsprüfungsschnittstellenanwendung 128 kann es beispielsweise einem Benutzer ermöglichen, jeden der Ausnahmedatensätze in einer Ausnahmedatenbank 170 einzeln zu durchlaufen, um die erkannten Ausnahmen anzuzeigen und diese Ausnahmen aufzulösen, wobei alle erforderlichen Aktionen zum Schließen des Ausnahmedatensatzes vorgenommen werden. Die Qualitätsprüfungsanwendung 128 kann über einen Schnittstellenbildschirm eines Schnittstellengeräts Daten oder Informationen für jeden Ausnahmedatensatz darstellen, wie beispielsweise den Namen der Ausnahme, den Ausnahmetyp, den Schweregrad der Ausnahme, die Batch-Metadaten oder die für den Ausnahmedatensatz gespeicherten Speicherauszug-Informationen, Hinweise, die von einem Bediener erstellt und gespeichert wurden, die dem Ausnahmedatensatz zugeordnet sind oder zu dessen Erstellung geführt haben, sonstige von der Datenquelle bereitgestellte Informationen usw. Diese Informationen ermöglichen es dem Qualitätsprüfer, die Ausnahme und den Kontext des Prozesses (z. B. den Batchlauf) zum Zeitpunkt des Auftretens der Ausnahme schnell zu verstehen, um die Ausnahme und die Bedeutung der Ausnahme besser verstehen zu können. Die Qualitätsprüfungsschnittstellenanwendung 128 kann dem Benutzer auch verschiedene andere Arten von Informationen auf strukturierte Weise darstellen, wie beispielsweise allgemeine Informationen über diese Art von Ausnahme, welche Schritte durchgeführt werden müssen, um diese Art oder diesen Schweregrad der Ausnahme zu behandeln oder freizugeben, usw. Darüber hinaus kann es die Qualitätsprüfungsschnittstellenanwendung 128 dem Benutzer ermöglichen, einen oder mehrere der verschiedenen Schritte auszuführen, die zum Freigeben oder Schließen der Ausnahme erforderlich sind, beispielsweise das Implementieren eines der verschiedenen Verfahren, wie sie durch die ursprüngliche Ausnahmeregel definiert sind, die die Ausnahme erkannt hat, um die Ausnahme freizugeben oder zu behandeln. Die Qualitätsprüfungsanwendung 128 kann es dem Benutzer beispielsweise ermöglichen, auf ein Kontrollkästchen auf dem Bildschirm zu klicken, um die Ausnahme zu bestätigen und freizugeben, kann einen Prozess erfordern oder erzwingen, der beinhaltet, dass eine oder mehrere andere Personen die Ausnahme anzeigen und freigeben, um sie abzuschließen, usw. Darüber hinaus kann die Qualitätsprüfungsschnittstellenanwendung 128 in der Lage sein, den Ausnahmedatensatz per E-Mail oder anderer Netzwerkkommunikation an andere Personen zu senden, um eine Freigabe der Ausnahme zu erhalten, Fragen zu stellen oder Daten oder Hinweise zur Ausnahme bereitzustellen, um weitere Informationen über die Ausnahme zu bestimmen oder um Verfahren zu implementieren, die zum Behandeln oder Schließen der Ausnahme erforderlich sind.
Die 8A-8G zeigen verschiedene beispielhafte Bildschirmanzeigen, die von der Qualitätsprüfungsschnittstellenanwendung 128 erstellt werden können, damit ein Prüfer Ausnahmedatensätze sehen und verändern kann, während eine Qualitätsprüfung, beispielsweise eines Auftrags, durchgeführt wird. Als Beispiel zeigt 8A eine Bildschirmanzeige 500, die von einem Prüfer verwendet werden kann, um einen von einem Satz verschiedener Aufträge oder Ausnahmedatensätze zur Überprüfung auszuwählen. Der Bildschirm 500 enthält einen Abschnitt oder ein Feld 502, in dem verschiedene Datenquellen aufgelistet sind (z. B. in einem Dropdown-Menüformat), für die Ausnahmedatensatzprotokolle 170 existieren (wie sie beispielsweise in der Ausnahmedatensatzprotokolldatenbank 126 von 2 gespeichert sind). Darüber hinaus kann ein Abschnitt 504 einen Satz von Aufträgen oder Ausnahmedatensatzdateien 170 auflisten, die für die ausgewählte Datenquelle in Abschnitt 502 existieren. Somit listet in dem Beispielbildschirm 500 von 8A das Feld 502 die Workflow-Datenquelle auf und im Abschnitt 504 ist eine Anzahl verschiedener Ausnahmedatensatzdateien für Aufträge oder Batchläufe aufgelistet, die von der Workflow-Anwendung verwaltet werden. Ferner kann ein Abschnitt 506 die Ausnahmedatensätze in einer bestimmten Datei (z. B. Reihenfolge) auflisten, wie in Abschnitt 504 ausgewählt. Der Benutzer kann durch die Liste 506 nach unten scrollen, um verschiedene der Ausnahmedatensätze 506A-506N auszuwählen. Weiterhin kann ein Abschnitt 508 des Bildschirms 500 Informationen für den Ausnahmedatensatz 506A-N darstellen, wie in dem Abschnitt 506 ausgewählt. In diesem Beispiel hat der Benutzer den Ausnahmedatensatz 506B ausgewählt, und die Anwendung 128 erhält Informationen für den ausgewählten Ausnahmedatensatz 506B aus der Ausnahmedatensatzprotokolldatenbank 126 und zeigt diese Informationen zur Verwendung und Veränderung durch den Benutzer an. Der Abschnitt 508 kann verschiedene Informationen für den ausgewählten Ausnahmedatensatz enthalten, wie z. B. den Namen, den Typ, den Schweregrad, Informationen für und Überprüfungs- oder Behandlungsverfahren für die Ausnahme.
Wichtig ist, dass die angezeigten Informationen für den Ausnahmedatensatz Prozess- oder Datenquellenmetadaten 510 enthalten können, die zum Zeitpunkt der Erstellung der Ausnahme aus der Datenquelle gesammelt wurden. Wie vorstehend beschrieben, sammelt das Qualitätsprüfungsmanagementsystem 112 beim Sammeln von Eingangsdaten aus einer Datenquelle einen Satz von Metadaten (die vordefiniert werden können, beispielsweise wenn ein Plug-in oder eine Regel erstellt wird, oder die Daten sein können, von denen bekannt ist, dass sie von einer bestimmten Datenquelle bereitgestellt werden). Im Allgemeinen werden die zu sammelnden Metadaten durch eine Datentransformation definiert, die beim Erstellen einer Regel konfiguriert wird. Die Datentransformation wird auf die Metadaten aus der Datenquelle angewendet und das Plug-in gibt diese transformierten Metadaten beispielsweise in HTML aus, so dass die Metadaten in der Überprüfungsanwendung angezeigt werden können. Diese Datenquellen-Metadaten, bei denen es sich um Prozess- oder Umgebungsdaten handeln kann, werden im Allgemeinen gleichzeitig mit den Ausnahmeeingangsdaten gesammelt und als Prozess-Speicherauszug gespeichert, der den aufgerufenen Ausnahmedaten als Teil des für die Ausnahme erstellten Ausnahmedatensatzes zugeordnet ist. Wenn die Ausnahme-Engine 122 als solche eine Ausnahme basierend auf den gesammelten Ausnahmedaten erkennt, speichert die Ausnahme-Engine 122 auch die Datenquellenmetadaten als Teil des Ausnahmedatensatzes. Die Qualitätsprüfungsschnittstellenanwendung 128 zeigt dann einige oder alle dieser Metadaten beispielsweise in dem Feld 510 des Bildschirms 500 an, wobei die generierte Ausnahme gemeldet wird, wodurch dem Prüfer eine Live-Ansicht des Prozesses zum Zeitpunkt des Auftretens der Ausnahme innerhalb des Prozesses bereitgestellt wird. Dieses Merkmal bietet dem Prüfer somit eine schnelle Ansicht von verschiedenen Prozesszuständen/-werten usw. zum Zeitpunkt der Ausnahme, wodurch der Prüfer den Grund für das Auftreten der Ausnahme, den Kontext der Ausnahme, usw. schneller verstehen kann, und ermöglicht dem Prüfer somit, die Ausnahme schneller zu verarbeiten oder zu verstehen, wie sie aufzulösen ist. Dieser Vorgang erleichtert die Qualitätsprüfung, da bekannte Qualitätsprüfungsprodukte einem Prüfer im Allgemeinen eine Liste der generierten Ausnahmen zur Verfügung stellen; der Prüfer muss nach wie vor jede Ausnahme analysieren, um zu bestimmen, ob die Ausnahme abgewiesen werden kann oder auf andere Weise behoben werden muss. Bei diesen bekannten Produkten muss der Prüfer normalerweise zu dem Prozesssystem zurückkehren, in dem die Daten, die zur Ausnahme geführt haben, gesammelt wurden, um zum Zeitpunkt der Ausnahme Prozess-Speicherauszugsdaten abzurufen. Mit der Live-Ansichtsfunktion, die durch das Metadatenfeld 510 des Bildschirms 500 bereitgestellt wird, wird dem Prüfer automatisch ein Prozess-Speicherauszug bereitgestellt, der im Allgemeinen die Prozessdaten enthält, die für den Prüfer beim Durchführen der Ausnahmeprüfung am nützlichsten sind, was bedeutet, dass der Prüfer nicht zu anderen Datensammelsystemen zurückkehren muss, um die Informationen zu erhalten, die der Benutzer benötigt, um Überprüfung und Behandlung von Ausnahmen durchzuführen. Diese Funktion bedeutet auch, dass der Prüfer im Allgemeinen nicht ebenso mit anderen Prozessdatenabrufsystemen vertraut sein muss, von denen die Prozess- oder Datenquellenmetadaten normalerweise gesammelt werden, da der Prüfer diese Datensammelsysteme im Allgemeinen nicht verwenden muss, um auf die Prozessdaten zuzugreifen, die der Prüfer benötigt, um Ausnahmedatensätze aufzulösen.
Darüber hinaus kann ein Abschnitt 512, wie in 8A veranschaulicht, dem Benutzer einen Satz von Optionen oder Informationen in Bezug auf die Art der Behandlung oder Auflösung der Ausnahme bereitstellen, z. B. Überprüfungsschritte oder -verfahren, Checklisten von Aktionen, die zum Schließen der Ausnahme durchgeführt werden müssen, Freigabefelder, die von verschiedenen Benutzern ausgefüllt oder signiert werden müssen, um die Ausnahme zu schließen usw.
8B zeigt eine beispielhafte Bildschirmanzeige 520, die einige der Informationen für einen Ausnahmedatensatz vom Typ Workflow-Kommentar veranschaulicht. Hier ist die Workflow-Ausnahme im Bildschirmabschnitt 506 die einzige Ausnahme, die für den ausgewählten Auftrag aufgelistet ist. Wie in Abschnitt 508 des Bildschirms 520 veranschaulicht, hat der Workflow-Kommentar den Status „NEU“, einen Schweregrad „NIEDRIG“, hat keine Kennung für oder Zuordnung zu Korrektur- und Vorbeugungsmaßnahmen (CAPA) (die zum Definieren eines Verweises auf ein Drittanbietersystem verwendet werden kann, das auch zum Anzeigen und/oder Verarbeiten der Ausnahme verwendet werden kann) und ist auch keiner Gruppe zugewiesen. Der Abschnitt 508 zeigt jedoch eine Ausnahme-ID (da jede Ausnahme eine eindeutige ID hat), eine Quellenangabe und ein Datum / eine Zeit der Erstellung für die Ausnahme an, wobei alle diese Daten als Teil des Ausnahmedatensatzes gespeichert werden. Ferner enthält der Abschnitt 508 eine allgemeine Beschreibung der Ausnahme, wobei es sich auch um Informationen handeln kann, die als Teil des Ausnahmedatensatzes gespeichert sind. Diese Daten können jedoch als Teil der Überprüfungsanwendung 128 gespeichert werden und können auf dem Ausnahmetyp basieren.
Ebenso zeigt der untere Anteil des Bildschirmabschnitts 508 die für diese bestimmte Ausnahme gesammelten Metadaten. In diesem Fall spiegeln die Metadaten wider, was ein Benutzer in der Workflow-Anwendung gesehen hat, als die Ausnahme erstellt wurde, und können dazu verwendet werden, den Prüfer beim Verstehen des Prozesskontexts bei Auftreten der Ausnahme zu unterstützen.
Ferner stellt ein Beispielbildschirm 530 von 8C eine Liste von Auflösungsfeldern bereit, die einem Prüfer innerhalb des Bildschirmabschnitts 508 von 8B bereitgestellt werden können, um die Behandlung oder das Schließen eines Ausnahmedatensatzes durchzuführen. Hier können die Auflösungen nach Wunsch konfigurierbar sein (und somit kann ein ähnlicher Bildschirm auch in der Konfigurationsanwendung 120 verwendet werden, um eine Regel für eine Ausnahme zu generieren). In jedem Fall können, wie in 8C angegeben, die Auflösungsfelder einen Auflösungsnamen oder -typ 532 (z. B. Standard), eine Beschreibung 534, einen oder mehrere Phasenbezeichnungen 536 (z. B. Fertigung oder Fertigungsvorgesetzter), einen Schweregrad 538 (z. B. Niedrig) und Signaturen 539 enthalten, die von den Mitarbeitern in einer oder mehreren Phasen benötigt werden, um die Ausnahme zu schließen oder aufzulösen. In diesem Fall gibt die Auflösung des in 8C gezeigten Beispielausnahmedatensatzes an, dass die Ausnahme von zwei Bedienern (in der Fertigungsphase) und einem Vorgesetzten (in der Fertigungsüberwachungsphase) signiert werden muss, um die Ausnahme zu schließen oder aufzulösen. Diese Handhabungsverfahren können in dem Abschnitt oder Feld 512 von 8A in Form von Signaturfeldern, Kontrollkästchen usw. implementiert sein. Darüber hinaus kann der Prüfer über die Möglichkeit verfügen, diese Verfahren von Ausnahme zu Ausnahme zu ändern oder Ausnahmen zu gruppieren und Schritte auf Gruppenbasis zu unternehmen.
8D veranschaulicht als Beispiel eine beispielhafte Bildschirmanzeige 540, die einen Bildschirmabschnitt 508 mit einem Auflösungsfeld 542 für eine ausgewählte Ausnahme „Parameter außerhalb des zulässigen Bereichs“ enthält. Auch hier enthält der Bildschirm 540 einige Informationen über den ausgewählten Ausnahmedatensatz, einschließlich eines Status (Aktiv), eines Schweregrads (Niedrig), einer CAPA-Kennung und einer Gruppenbezeichnung, soweit vorhanden. Der Auflösungsabschnitt 542 enthält Felder 544, die dem Prüfer das Durchsuchen ermöglichen, um eine Datei an den Ausnahmedatensatz anzuhängen (was später nützlich sein kann, wenn die Ausnahmedatensätze für den Auftrag von einem Kunden, der FDA usw. geprüft werden), und ein Kommentarfeld 546, in dem Prüfer Kommentare oder Hinweise zum Ausnahmedatensatz hinzufügen können (hier hat eine SA-Administratorin kommentiert, dass sie sich um das Schließen des Ausnahmedatensatzes kümmert). Natürlich können über das Feld 546 zusätzliche Kommentare hinzugefügt werden. Zusätzlich enthält der Bildschirmabschnitt 508 des Bildschirms 540 ein Feld zum Signieren und Schließen 548, das von den verschiedenen erforderlichen Unterzeichnern dazu verwendet werden kann, den Ausnahmedatensatz zu schließen. Ferner kann der Bildschirmabschnitt 508 ein Verlaufsfeld 549 enthalten, das Aktionen angibt, die während der Verarbeitung des Datensatzes an dem Ausnahmedatensatz ausgeführt wurden, einschließlich der Art der durchgeführten Aktion, der die Aktion durchführenden Person und Uhrzeit und Datum der Aktion. Diese Informationen können von der Überprüfungsschnittstellenanwendung 128 erfasst und als Teil des Ausnahmedatensatzes gespeichert werden.
Ebenso können die verschiedenen Bildschirme, die von der Qualitätsprüfungsschnittstellenanwendung 128 dargestellt werden, statistische Informationen über einen Auftrag oder eine Gruppe von Aufträgen enthalten. Beispielsweise enthält ein Abschnitt 550 des Bildschirms 540 eine Angabe 551 des angezeigten Auftrags, eine Angabe 552 der Anzahl von dem Auftrag zugeordneten Ausnahmedatensätzen, die geschlossen werden, und eine Angabe 553 des Abschlussstatus des Auftrags (in diesem Fall ist der Auftrag noch nicht vollständig, sondern wird noch verarbeitet). Der Abschnitt 550 kann auch Links 553 bereitstellen, über die Prüfer den Auftrag oder Ausnahmedatensätze des Auftrags usw. signieren und verifzieren können.
Ebenso veranschaulicht ein Bildschirm 560 von 8E zusätzliche statistische Informationen, die die Qualitätsprüfungsanwendung 128 bestimmen und einem Prüfer von Auftrag zu Auftrag oder Gruppe zu Gruppe zur Verfügung stellen kann. Der Bildschirm 560 von 8E ist dem von 540 von 8D ähnlich, außer dass ein Abschnitt 562 verschiedene statistische Informationen über die 11 Ausnahmedatensätze in der ausgewählten Reihenfolge anzeigt. In diesem Fall geben die Felder 564 die Anzahl der Ausnahmedatensätze für den Auftrag an, die sich in jeder Statuskategorie befinden (Neu, Aktiv, Geschlossen). Darüber hinaus geben Balkendiagramme 566 die Anzahl von Ausnahmedatensätzen für den Auftrag nach jeder Schweregradkategorie an (fünf ist „niedrig“, drei ist „mittel“, zwei ist „hoch“ und eins ist „neu“). Weiterhin geben Balkendiagramme 568 die Anzahl der Ausnahmen des Auftrags in jedem Ausnahmetyp an (neun ist der Typ „Parameter außerhalb des zulässigen Bereichs“ und zwei ist „Kommentartyp“). Natürlich kann die Qualitätsprüfungsanwendung 128 andere Arten statistischer Informationen über Ausnahmedatensätze bereitstellen und statistische Informationen auf andere Weise bereitstellen, beispielsweise für Gruppen von Aufträgen, Teilmengen von Datensätzen innerhalb eines Auftrags oder einer Gruppe usw.
Darüber hinaus kann der Prüfer mit der Qualitätsprüfungsschnittstellenanwendung 128 verschiedene der Ausnahmedatensätze zu einer Gruppe zusammenfassen und verschiedene Aktionen (Kommentieren, Ändern von Parametern, Freigeben usw.) mit den Datensätzen als Gruppe vornehmen. Als Beispiel enthält jeder der Bildschirme 540 und 560 der 8D und 8E eine Auflistung 570, innerhalb der Liste von Ausnahmedatensätzen, von drei Gruppen von Datensätzen, nämlich Erste Gruppe, Zweite Gruppe und Tester. Mit der Anwendung 128 kann ein Prüfer Ausnahmedatensätze zu einer Gruppe hinzufügen, indem er beispielsweise einen Ausnahmedatensatz in der Ausnahmedatensatzliste 506 auswählt und den ausgewählten Ausnahmedatensatz in eine Gruppe in der Liste 570 zieht und dort ablegt. Natürlich kann ein Prüfer mit der Anwendung 128 auf geeignete Weise nach Bedarf neue Gruppen erstellen, Gruppen löschen usw.
Darüber hinaus kann ein Prüfer mit der Anwendung 128 eine oder mehrere Aktionen für Ausnahmedatensätze auf Gruppenbasis ausführen, was dem Prüfer Zeit spart. 8F zeigt einen Beispielbildschirm 580, in dem ein Prüfer die Gruppe Tester für eine Gruppenaktion ausgewählt hat. Als Ergebnis dieser Auswahl zeigt die Anwendung ein Popup-Fenster 582 mit möglichen Aktionen an, die für die Gruppe von Ausnahmedatensätzen in der Gruppe Tester vorgenommen werden können. Solche Aktionen können das Ändern des Schweregrads der Ausnahmen in der Gruppe (über ein Dropdown-Eingabefeld 584), das Ändern der CAPA-Kennung für die Ausnahmedatensätze in der Gruppe (über ein Dropdown-Eingabefeld 586), das Hinzufügen eines Kommentars zu jedem der Ausnahmedatensätze in der Gruppe (über ein Eingabefeld 588), das Anhängen eines Dokuments an jeden Ausnahmedatensatz in der Gruppe (über ein Feld 590) und das Signieren und Schließen der Ausnahmedatensätze in der Gruppe über einen Link 592 einschließen. Natürlich kann der Prüfer mit der Anwendung 128 eine jede andere Aktion oder Aktionen für eine ausgewählte Gruppe von Ausnahmedatensätzen vornehmen und dies auf eine beliebige andere Weise über ein Schnittstellengerät ausführen.
Falls gewünscht, kann es die Qualitätsprüfungsschnittstellenanwendung 128 einem Prüfer ermöglichen, Gruppenaktionen für Ausnahmedatensätze durchzuführen, die keiner Gruppe tatsächlich zugeordnet sind. Zum Beispiel kann der Prüfer, wie in einer beispielhaften Bildschirmanzeige 592 von 8G veranschaulicht, ein Kontrollkästchen für verschiedene Ausnahmedatensätze in der Liste 506 aktivieren (die ersten beiden Ausnahmedatensätze in dem Beispiel von 8G sind entsprechend angekreuzt). Die Anwendung 128 kann dies dann als einen Versuch erkennen, Aktionen für beide der geprüften Ausnahmedatensätze vorzunehmen, und kann einen Popup-Bildschirm 594 bereitstellen, der die verschiedenen Bearbeitungsfelder von 8F enthält. In diesem Fall kann das Popup-Fenster 594 jedoch Gruppierungsaktionen enthalten, die für die ausgewählten Ausnahmedatensätze vorgenommen werden können, z. B. das Hinzufügen von diesen zu einer vorhandenen Gruppe oder das Erstellen einer neuen Gruppe, wie oben im Popup-Fenster 594 von 8G gezeigt.
Die hier beschriebene Qualitätsprüfungsschnittstellenanwendung 128 kann einen vorteilhaften Paging-Algorithmus oder eine vorteilhafte Paging-Technik verwenden, mit dem bzw. der ein Prüfer durch verschiedene Seiten von Datensätzen scrollen kann, wie beispielsweise Ausnahmedatensätze, wie sie in den Datensatzlisten 506 der 8A, 8B und 8D-8G bereitgestellt sind, auf eine Weise, die das Darstellen doppelter Datensätze auf verschiedenen Seiten oder in fehlenden Datensätzen in der Anzeige beim Wechseln von Datensatzseiten reduziert oder eliminiert. Im Allgemeinen suchen webbasierte oder browserbasierte Anzeigesysteme, die einen Browser verwenden, um Listen von organisierten Datensätzen anzuzeigen, die in einer externen strukturierten Datenbank gespeichert sind, z. B. einer SQL-Datenbank, auf die beispielsweise über eine Netzwerkverbindung zugegriffen werden kann, nach den relevanten Datensätzen in der Datenbank und stellen dann eine Reihe der Datensätze dar, die auf eine Anzeigeseite passen, z. B. 10 Datensätze gleichzeitig. Daher zeigen diese Systeme normalerweise zuerst die Datensätze in den ersten zehn Positionen der zurückgegebenen Liste an. Wenn der Benutzer mehr Datensätze außerhalb der aktuell angezeigten Liste sehen möchte, kontaktiert der Browser die Datenbank mit derselben Suche und erhält den nächsten Satz von Datensätzen (z. B. die nächsten 10 Positionen von Datensätzen), wenn der Benutzer in der Liste von Datensätzen nach unten scrollt, oder den vorherigen Satz von Datensätzen (z. B. die vorherigen 10 Positionen von Datensätzen), wenn der Benutzer in der Liste von Datensätzen nach oben scrollt. Natürlich kann es eine große Anzahl von Ausnahmen oder Datensätzen geben, und somit muss die Schnittstelle durch zahlreiche Seiten mit Datensätzen scrollen, wenn der Benutzer die Liste von Datensätzen nach unten oder oben scrollt. Somit bestimmt der Browser des Anzeigesystems alle relevanten Datensätze, die der Abfrage zugeordnet sind, und stellt eine erste Seite als die erste X Anzahl von Datensätzen in der Liste dar (z. B. wenn X 10 ist, die Datensätze 1-10). Wenn der Benutzer Datensätze sehen möchte, die nicht auf der ersten Seite enthalten sind, lädt das System eine zweite Seite als zweiten Satz von X Datensätzen in die Liste (z. B. Datensätze in den Positionen 11-20 der Liste). Das System scrollt dann in der Liste um X Positionen nach oben oder unten, um eine vorherige oder die nächste Seite von Datensätzen darzustellen. Wenn die Liste der Datensätze statisch ist und sich nicht sehr oft ändert, funktioniert dieser Paging-Algorithmus gut, da das System einfach aufeinanderfolgende Sätze von X Datensätzen als jeweils neue Seite lädt.
Wenn sich jedoch die Datensätze in der Liste oder in der Suche ändern, z. B. wenn einige der Datensätze verschwinden oder aus der Suche herausfallen, weil ein Parameter des Datensatzes geändert wurde, oder wenn neue Datensätze in der Datenbank angelegt werden, ändert sich die ursprüngliche Liste von durch die Suche gefundenen Datensätzen, und diese Änderungen können während der Zeit auftreten, in der der Prüfer eine Seite von Datensätzen überprüft, aber bevor er die nächste Seite von Datensätzen aufruft. In dieser Situation können sich die Datensätze in der Datenbank ändern, wenn der Prüfer die Datensätze verarbeitet und die Liste der Datensätze, wie sie auf der Benutzerschnittstelle angezeigt werden, nach unten scrollt, und somit können die Seitendaten veralten. Insbesondere können Datensätze hinzugefügt oder aus der Datenbank gelöscht werden (oder Datensätze können Parameter aufweisen, die sich ändern und dazu führen, dass die Datensätze von der Suche gemäß den Suchkriterien nicht mehr zurückgegeben werden). Wenn folglich das Anzeigesystem versucht, die Datensätze für nachfolgende Seiten auf einem Anzeigebildschirm darzustellen, fehlen möglicherweise verschiedene Datensätze, auf die in der ursprünglichen Suche verwiesen wird, was zu Verlust oder Duplizierung visueller Daten führt. In einigen Fällen kann der Benutzer unter Umständen beim Wechseln von einer Seite zur nächsten einen Datensatz übersehen, wenn ein Datensatz auf einer bestimmten wiederhergestellten Seite gelöscht wird. In anderen Fällen kann das System aufgrund fehlender Datensätze, die in der ursprünglich zurückgegebenen Liste von Datensätzen enthalten waren, verunsichert sein, wo eine neue Anzeigeseite gestartet werden soll. In noch einem weiteren Fall kann das Anzeigesystem denselben Datensatz auf mehreren Seiten darstellen, basierend auf dem Hinzufügen neuer Datensätze zur Datenbank. Keine dieser Situationen ist in einem Überprüfungssystem wünschenswert, in dem es für den Prüfer wichtig ist, jeden einzelnen Datensatz in der Liste anzuzeigen und freizugeben, wie dies bei Ausnahmedatensätzen in einem Ausnahmedatensatzprotokoll für einen Auftrag der Fall ist, wie durch die Anwendung 128 dargestellt.
9A und 9B veranschaulichen das vorstehend erörterte Problem in einer typischen browserbasierten Anzeigeschnittstelle, die Datensätze anzeigt, wie sie von einer Suche nach in einer Datenbank gespeicherten Datensätzen zurückgegeben werden, wobei Datensätze während der Anzeigeaktivitäten zu der Datenbank hinzugefügt oder daraus entfernt werden oder Parameter davon in der Datenbank geändert werden können. Insbesondere veranschaulicht 9A eine Liste relevanter Datensätze 700, die von einer Suche in einer Datenbank zu einem Zeitpunkt T1 zurückgegeben wurden (einschließlich der Datensätze R1-RN), wobei die Datensätze R1-RN alle Datensätze für einen Auftrag sein können oder eine geordnete Liste von Datensätzen basierend auf anderen Suchkriterien sein können, wie z. B. alle offenen Datensätze für einen Auftrag, alle Datensätze eines bestimmten Schweregrads usw. In jedem Fall kann das Anzeigesystem (z. B. der Browser an der Benutzerschnittstelle) zu einem ersten Zeitpunkt T₁ die Liste 700 empfangen, Zugriff auf die ersten sieben Datensätze in der Liste 700 erhalten und diese sieben Datensätze auf einem Anzeigebildschirm 704 auf der Benutzerschnittstelle als erste Seite von Datensätzen darstellen. Somit enthält der Anzeigebildschirm 704 die Datensätze R1-R7 als erste Seite von Datensätzen von der Suche. Das Anzeigesystem kann zu einem späteren Zeitpunkt T₂, beispielsweise wenn der Benutzer nach der nächsten Seite von Datensätzen fragt, auf die Datenbank zugreifen, um eine Liste der relevanten Datensätze zu erhalten. Vorausgesetzt, dass keine Änderungen an den Datensätzen in der Datenbank vorgenommen wurden, wird dieselbe Datensatzliste 700 zum Zeitpunkt T₂ zurückgegeben und das Anzeigesystem greift einfach auf den Satz von Datensätzen zu, der in dem zweiten Satz von sieben Positionen auf der Liste (was die Datensätze R8-R14 ergibt) gefunden wurde, und zeigt ihn als zweite Seite von Datensätzen in der Anzeige 708 an. Dieser Vorgang, der in 9A veranschaulicht ist, funktioniert gut, wenn die geordnete Liste von Datensätzen 700 aus der Datenbank vom Zeitpunkt T₁ bis zum Zeitpunkt T₂ statisch bleibt.
Wenn jedoch ein Datensatz aus der Liste von relevanten Datensätzen zwischen dem Zeitpunkt T₁, zu dem die erste Seite 704 dargestellt wird, und dem Zeitpunkt T₂, zu dem die zweite Seite 708 dargestellt wird, entfernt wird (z. B. wenn sich in einem oder mehreren Datensätzen ein Parameter davon geändert hat, wodurch verhindert wird, dass der Datensatz bei der Suche nach Datensätzen gefunden wird), dann kann das Anzeigesystem unbeabsichtigt die Anzeige eines Datensatzes überspringen. 9B veranschaulicht ein Beispiel, bei dem der Datensatz R4 nach dem Zeitpunkt T₁, zu dem die erste Seite 704 in der Anzeige dargestellt wurde, aber vor dem Zeitpunkt T₂, zu dem die zweite Seite 708 dargestellt wird, aus die Suchliste entfernt wird (oder aus ihr herausfällt). In diesem Fall erhält der Browser des Anzeigesystems die ersten sieben Datensätze R1-R7 auf Seite eins 704 und zeigt sie an, basierend auf der Liste 700, wie sie in der Datenbank von 9A zum Zeitpunkt T₁ gefunden wird. Wenn jedoch der Browser des Anzeigesystems auf die Datensätze für die zweite Seite 708 in 9B zugreift, greift der Browser einfach auf den zweiten Satz von sieben Datensätzen in der zurückgegebenen Liste 710, d. h. die Datensätze in den Positionen 8-14 in der Liste 710 von 9B, zu und verwendet ihn. Da zu diesem Zeitpunkt der Datensatz R4 entfernt wurde (da er möglicherweise geschlossen und somit entfernt wurde oder aus der Liste der relevanten Datensätze herausgefallen ist), zeigt das Anzeigesystem die Datensätze R9-R15 als zweite Seite von Datensätzen in der Anzeige 708 an, da der Datensatz R8, der sich ursprünglich in der achten Position in der Liste 700 von 9A befand, als die erste Seite angezeigt wurde, sich jetzt in der siebten Position in der Liste 710 von 9B befindet, da der Datensatz R4 zwischen den Zeitpunkten T₁ und T₂ entfernt wurde. Als solches wird der Datensatz R8 weder auf der ersten noch auf der zweiten Seite 704 oder 708 der Anzeige von 9B gezeigt und wird daher vom Prüfer übersehen. Eine ähnliche Situation tritt natürlich auf, wenn während des Paging-Prozesses ein Datensatz zur Liste oder Datenbank hinzugefügt wird; in diesem Fall können jedoch ein oder mehrere Datensätze dupliziert oder auf aufeinanderfolgenden Seiten dargestellt werden, da das Hinzufügen eines Datensatzes bewirkt, dass ein bestimmter Datensatz, der sich ursprünglich in einer Position befand, die einer Seite zugeordnet war, sich zu einem späteren Zeitpunkt in einer Position befindet, die einer anderen Seite zugeordnet ist.
Diese Situation ist nachteilig, wenn ein Prüfer durch Seiten mit Ausnahmedatensätzen mit Parametern scrollt, die sich ändern können oder in denen neue Datensätze hinzugefügt werden können, da dies zu Situationen führt, in denen relevante Datensätze in der Anzeige übersprungen oder relevante Datensätze auf den verschiedenen Seiten der Anzeige dupliziert werden.
Die hier beschriebene Qualitätsprüfungsanwendung 128 kann jedoch eine andere Paging-Technik verwenden, um zu bestimmen, welche Datensätze auf verschiedenen unterschiedlichen Seiten von Anzeigen dargestellt werden sollen, und diese neue Paging-Technik reduziert oder eliminiert die Anzeige von doppelten und/oder fehlenden Datensätzen beim Wechsel zwischen verschiedenen Seiten. Insbesondere verwendet die Qualitätsprüfungsanwendung 128 keine festen oder voreingestellten Stellen oder Datensatzpositionen in der Liste der von der Datenbank zurückgegebenen Datensätze, um ein Paging durchzuführen, sondern verwendet stattdessen einen dynamischen Paging-Algorithmus, der einen oder mehrere Datensätze markiert, wie beispielsweise einen ersten Datensatz oder einen letzten Datensatz oder sowohl einen ersten als auch einen letzten Datensatz auf der zuletzt angezeigten Seite, und verwendet dann diese Markierung oder diesen Anker, um den Satz von Datensätzen zu finden, der als Teil der nächsten Seite der Anzeige angezeigt werden soll. Auf diese Weise, wenn zum Zeitpunkt des Ladens der neuen Seite Datensätze zu der relevanten Liste von Datensätzen hinzugefügt oder daraus gelöscht werden, handelt es sich bei dem auf der nächsten Seite angezeigten Satz von Datensätzen um die Datensätze in der Liste, die an einen der zuletzt angezeigten Datensätze angrenzen (z. B. den ersten oder den letzten Datensatz der vorherigen Seite).
10A und 10B veranschaulichen den Vorgang des neuen Paging-Algorithmus oder der neuen Paging-Technik, der bzw. die von der Qualitätsprüfungsschnittstellenanwendung 128 verwendet wird. In diesem Fall enthalten die Listen von relevanten Datensätzen 700 und 710 der 10A und 10B, wie sie von den Datenbanksuchen zu den Zeitpunkten T₁ und T₂ zurückgegeben wurden, die gleichen Sätze von relevanten Datensätzen wie in den 9A bzw. 9B veranschaulicht. Wie in 10A veranschaulicht, stellt die Schnittstellenanwendung 128 eine erste Seite 704 als die ersten sieben Datensätze in der Anzeige dar, markiert jedoch den letzten oder unteren Datensatz (R7), der auf der ersten Seite 704 angezeigt wird, mit einem Anker (als Anker1_unt bezeichnet), der den letzten oder untersten Datensatz auf der aktuell angezeigten Seite angibt. Die Anwendung 128 kann auch den ersten oder obersten Datensatz (R1) in der Anzeige 704 mit einem oberen Anker (hier als Anker1_oben bezeichnet) markieren, der den oberen oder ersten Datensatz auf der aktuell angezeigten Seite angibt. Wenn die Anwendung 128 dann die nächste Seite von Datensätzen, Seite 2, lädt, durchsucht die Anwendung 128 die zurückgegebene Liste von Datensätzen nach dem unteren Anker für Seite 1 (Anker1_unt), ungeachtet der Position in der zurückgegebenen Liste 700 oder 710, in der dieser Datensatz gefunden wurde. Die Anwendung 128 verwendet dann die nächsten sieben Datensätze in der Liste 700 unmittelbar nach dem Datensatz, der mit dem unteren Anker von Seite 1, Anker1_unt, markiert ist, für die auf Seite 2 anzuzeigende Liste von Datensätzen. Die Anwendung 128 kann dann auch den Anker Anker1_unt entfernen, aber zusätzliche Anker für die nächste Seite von Datensätzen (d. h. Anker2_oben und Anker2_unt) markieren oder speichern, um die oberen und unteren Datensätze zu markieren, die auf Seite 2 der Anzeige 708 angezeigt werden. Die Anwendung 128 verwendet dann den mit Anker2_unt markierten Datensatz, um zu bestimmen, welche Datensätze auf der nächsten Seite (Seite 3) angezeigt werden sollen, wenn der Benutzer in der Liste von Seite 2 nach unten scrollt, oder verwendet den mit Anker2_oben gekennzeichneten Datensatz, um zu bestimmen, welche Datensätze auf einer vorherigen Seite angezeigt werden sollen (z. B. wenn der Benutzer in der Liste der Datensätze auf Seite 2 nach oben scrollt, um zu Seite 1 zurückzukehren). Wie sich versteht, platziert diese Paging-Technik Anker oder Markierungen in Datensätzen oder speichert Anker oder Markierungen, die Datensätze anzeigen, an verschiedenen Positionen der aktuellen Anzeigeseite und verwendet diese Anker, um zu bestimmen, welche Datensätze in dem zurückgegebenen Satz von Datensätzen für den ersten (oder letzten) Datensatz der nächsten Seite verwendet werden sollen, ungeachtet der tatsächlichen Position der Datensätze in der zurückgegebenen Liste. Als solche können sich Datensätze in Positionen innerhalb der Datenbank oder der zurückgegebenen Liste 700 zwischen der Anzeige verschiedener Seiten auf und ab bewegen, ohne die Paging-Anzeige in der in den 9A und 9B veranschaulichten Weise zu stören.
Als Beispiel veranschaulicht 10A den Vorgang der Verwendung von Ankern, wenn keine Änderungen an der Datenbank zwischen den Zeitpunkten T₁ und T₂ vorgenommen werden, was zur Darstellung der Datensätze R1-R7 auf der ersten Seite 704 und der Datensätze R8-R14 auf der zweiten Seite 708 führt. 10B veranschaulicht den Vorgang der Verwendung der Anker innerhalb der Liste von Datensätzen 710, wenn diese Anker dazu verwendet werden, Paging zu einem Zeitpunkt T₁ durchzuführen, zu dem die zurückgegebene Datensatzliste die Liste 700 von 10A ist, und zu einem Zeitpunkt T₂, zu dem die zurückgegebene Datensatzliste die Liste 710 von 10B ist. Insbesondere enthält die Anzeige 704 für Seite 1 die Datensätze R1-R7 basierend auf dem Zustand der Datensatzliste 700 in der Datenbank von 10A zum Zeitpunkt T₁, als Seite 1 erstellt wurde. Die Anwendung 128 markierte jedoch beim Laden von Seite 1 die Datensätze R1 mit dem Anker Anker1_oben und den Datensatz R7 mit dem Anker Anker1_unt. Als nächstes durchsucht die Anwendung 128 zum Zeitpunkt T₂, wenn die Anzeigeanwendung 128 die Liste von Datensätzen 710 erhält (die sich jetzt geändert hat, da der Datensatz R4 nicht mehr in der Liste enthalten ist), um Seite 2 anzuzeigen, die zurückgegebene Liste 710 nach dem Datensatz, der als Anker1_unt-Datensatz markiert wurde, und nachdem sie diesen Datensatz in der Liste 710 gefunden hat, lädt sie einfach die nächsten sieben Datensätze (in diesem Fall die Datensätze R8-R14) und zeigt sie als Seite 2 der Anzeige 708 an, obwohl die Datensätze R8-R14 sich in der Liste 710 in der siebten bis dreizehnten Position befinden. Natürlich kann die Anwendung 128 eine beliebige Anzahl von Ankern pro Seite markieren, hat jedoch im Allgemeinen zwei Anker pro Seite, um die oberen und unteren Datensätze auf der aktuellen Seite zu identifizieren, und lädt dann die Datensätze beim Laden der nachfolgenden Seiten angrenzend an oder neben diese Anker. Die Verwendung von zwei Ankern ermöglicht es der Anwendung 128, auf Seiten in einer Weise nach oben und unten zu scrollen, die fehlende Datensätze in der Anzeige oder das Duplizieren von Datensätzen auf verschiedenen Seiten eliminiert oder reduziert, wenn sich die Zustände der Datensätze in der Liste ändern (wobei ein solcher Datensatz zu der Liste hinzugefügt oder aus ihr entfernt wird).
Die Anwendung 128 kann jede Markierungstechnik verwenden, beispielsweise das Speichern einer Angabe des (der) Datensatzes (-sätze), der (die) sich in der oberen und unteren Ankerposition in einer separaten Ankervariablen (wie im Browser oder Browsergerät) befindet (befinden), während eine bestimmte Seite angezeigt wird, wobei tatsächlich eine Markierung in der Datenbank gespeichert wird, die einem Datensatz zugeordnet ist, der sich derzeit in einer Ankerposition auf der aktuell angezeigten Seite von Datensätzen befindet, wobei einer oder mehrere der Datensätze auf der aktuellen Seite als Markierung gespeichert werden, wobei eine temporäre Markierung in der Datenbank unmittelbar vor oder nach einem markierten Datensatz platziert wird, usw. Zusätzlich kann die Markierung oder der Anker in der Anwendung 128, einem von der Anwendung 128 verwendeten Browser, der Datenbank, in der die Datensätze gespeichert sind, usw. gespeichert werden. Außerdem verschiebt oder ändert die Anwendung 128 die Ankerpositionen oder Markierungen, wenn auf neue Seiten zugegriffen wird und diese angezeigt werden. Darüber hinaus kann die Anwendung 128 einen beliebigen Wert als Anker für einen Datensatz verwenden. Beispielsweise kann die Anwendung 128 einen Parameter des Datensatzes, an dem sich der Anker befindet, als Anker verwenden, wie beispielsweise den Zeit-/Datumsstempel des Datensatzes usw. In einigen Fällen kann der Anker für einen Datensatz auf einem Suchparameter des Datensatzes oder einer Kombination von Suchparametern basieren oder diese angeben, oder kann ein anderer eindeutiger Wert des Datensatzes sein, z. B. ein Datensatzname, eine Identifikationsnummer usw. Ebenso kann in einigen Fällen der der Markierung zugeordnete Datensatz ein Datensatz sein, der aus der entsprechenden Suchliste entfällt. In diesem Fall kann die Anwendung 128, wenn sie den Ankerdatensatz (beim Laden einer neuen Seite) nicht in der neuen Liste findet, den Anker in den Datensatz auf der aktuell angezeigten Seite, die an den jetzt fehlenden Ankerdatensatz angrenzt (z. B. der Datensatz auf der aktuell angezeigten Seite unmittelbar über oder vor dem unteren Anker oder der Datensatz auf der aktuell angezeigten Seite unmittelbar unter oder nach dem oberen Anker), ändern und dann den neuen Anker verwenden, um den Satz von Datensätzen in der zurückgegebenen Liste zu bestimmen, der auf der neuen Anzeigeseite dargestellt werden soll.
Somit arbeitet der von der Qualitätsprüfungsschnittstellenanwendung 128 verwendete Paging-Algorithmus besser als frühere Paging-Systeme, da dieses neue System Datensätze auf einen neuen Anzeigebildschirm herunterlädt und darstellt, beginnend mit dem letzten auf der vorherigen Seite oder dem vorherigen Bildschirm angezeigten Datensatz, unabhängig von den Positionen der Datensätze in der zurückgegebenen Liste. Das heißt, anstatt eine neue Anzeigeseite darzustellen, die der Position von Datensätzen in der ursprünglichen Liste von wiederhergestellten Datensätzen zugeordnet ist, greift das System 128 unmittelbar nach dem letzten Datensatz auf der aktuell angezeigten Seite (beim Blättern der Liste nach unten) auf die Datenbank für die Datensätze zu, die derzeit in der neuen Liste vorliegen, wodurch sichergestellt wird, dass jedes Mal, wenn ein neuer Satz von Datensätzen auf dem Bildschirm angezeigt wird, der erste neue angezeigte Datensatz der Datensatz in der neuen Suchliste (710) ist, der unmittelbar auf den letzten Datensatz folgt, der auf der vorherigen Seite von der vorherigen Suche (700) angezeigt wurde. Dieses Anzeigesystem ist genauer, da es dazu beiträgt, sicherzustellen, dass Datensätze nicht in der falschen Reihenfolge angezeigt werden, dass Datensätze nicht auf mehreren Anzeigeseiten dupliziert werden und dass bei dem Überprüfungsprozess, bei dem der Benutzer über einen langen Zeitraum, in dem Änderungen an den Datensätzen in der Datenbank vorgenommen werden, durch verschiedene Seiten von Datensätzen scrollt, Datensätze nicht übersehen werden. Darüber hinaus ist die Überprüfungsanwendung 128 effizienter, da sie auf die Datenbank nur für die Anzahl neuer Datensätze zugreifen muss, die auf eine neue Anzeigeseite passen, während der Benutzer durch Datensätze scrollt, während nach wie vor sichergestellt ist, dass auf alle relevanten Datensätze zugegriffen wird, wenn der Benutzer den Bildlaufprozess ausführt.
Es versteht sich, dass die hier beschriebenen Qualitätsprüfungsmanagementanwendungen und die Batch-Ausführungs-Engines, Serveranwendungen, Plug-ins usw. in jeder gewünschten Prozessanlagenumgebung verwendet und implementiert werden können und in jedem Prozessanlagensteuerungssystem verwendet werden können, das jede gewünschte Art von Kommunikationsprotokoll zur Prozessanlagensteuerung verwendet. Während die hier beschriebenen Anwendungen und Routinen vorzugsweise in Software implementiert sind, die z. B. in einem Server, einer Arbeitsstation, einem Handheld-Gerät oder einem anderen Computer gespeichert ist, können diese Routinen alternativ oder zusätzlich je nach Wunsch in Hardware, Firmware, anwendungsspezifischen integrierten Schaltungen, programmierbaren Logikschaltungen usw. implementiert sein. Wenn die Routinen oder Anwendungen in Software implementiert sind, können sie in jedem computerlesbaren Speicher gespeichert werden, z. B. auf einer Magnetplatte, einer Laserplatte, einem EPROM oder EEPROM, einem Festkörper- oder anderen Speichermedium, in einem RAM oder ROM eines Computers, einem Handheld-Gerät, einer Steuerung, einem Feldgerät usw. Ebenso kann diese Software an einen Benutzer oder ein Gerät über jede bekannte oder gewünschte Übertragungsart geliefert werden, z. B. über einen Kommunikationskanal wie eine Telefonleitung, das Internet, auf einem transportablen Medium wie einer computerlesbaren Platte usw.
Obwohl die vorliegende Erfindung unter Bezugnahme auf spezifische Beispiele beschrieben wurde, die nur veranschaulichend sein und die Erfindung nicht einschränken sollen, ist es für den Durchschnittsfachmann offensichtlich, dass Änderungen, Ergänzungen oder Streichungen an den offenbarten Ausführungsformen vorgenommen werden können, ohne vom Geist und Umfang der Erfindung abzuweichen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 62/659325 [0001]

Claims

Qualitätsprüfungsmanagementsystem zur Verwendung für das Überprüfen des Betriebs eines Prozesses, der von einer Prozessausrüstung implementiert wird, umfassend: eine Regeldatenbank; ein Konfigurationssystem, das kommunikativ mit einer Benutzerschnittstelle und der Regeldatenbank gekoppelt ist und es einem Benutzer ermöglicht, eine oder mehrere Regeln über die Benutzerschnittstelle zu erstellen, wobei jede der Regeln eine oder mehrere Ausnahmen innerhalb eines Prozesses identifiziert, und das die eine oder mehreren Regeln in der Regeldatenbank speichert, und eine Ausnahme-Engine, die Daten in einer Datennachricht von der Prozessausrüstung unter Verwendung der Regeln in der Regeldatenbank verarbeitet, um zu bestimmen, ob die Daten in der Datennachricht eine Ausnahme enthalten, wie sie durch eine der Regeln definiert ist, wobei die Ausnahme-Engine bei Identifizieren einer Ausnahme basierend auf einer der Regeln Informationen über die Ausnahme als Ausnahmedatensatz speichert.
Qualitätsprüfungsmanagementsystem nach Anspruch 1, wobei das Konfigurationssystem eine Vielzahl von Regeln generiert, wobei jede der Vielzahl von Regeln einen Satz von Bedingungen identifiziert, die erfüllt sein müssen, um eine Ausnahme zu identifizieren.
Qualitätsprüfungsmanagementsystem nach Anspruch 2, wobei jede der Vielzahl von Regeln ferner einen Schweregrad der identifizierten Ausnahme identifiziert.
Qualitätsprüfungsmanagementsystem nach Anspruch 2, wobei jede der Vielzahl von Regeln ferner Informationen über die Ausnahme identifiziert.
Qualitätsprüfungsmanagementsystem nach Anspruch 2, wobei jede der Vielzahl von Regeln ferner Prozesse oder Verfahren identifiziert, die zum Behandeln, Auflösen oder Schließen der Ausnahme verwendet werden.
Qualitätsprüfungsmanagementsystem nach Anspruch 2, wobei jede der Vielzahl von Regeln ferner Prozessdaten oder andere Daten identifiziert, die als Teil eines Ausnahmedatensatzes gespeichert werden sollen, um einen Qualitätsprüfungsingenieur beim Verstehen und Auflösen der Ausnahme zu unterstützen.
Qualitätsprüfungsmanagementsystem nach Anspruch 1, wobei die Ausnahme-Engine Datennachrichten empfängt, die periodisch von einer Datenquelle innerhalb der Prozessausrüstung bereitgestellt werden.
Qualitätsprüfungsmanagementsystem nach Anspruch 7, wobei die Datenquelle eines von einem Prozesssteuerungssystem, einem Batch Executive oder einer Bediener-Workflow-Anwendung ist.
Qualitätsprüfungsmanagementsystem nach Anspruch 1, wobei das Konfigurationssystem eine oder mehrere Regeln generiert, wobei jede Regel einen Regelnamen, einen Regeltyp, einen Regelschweregrad, ein oder mehrere Verfahren oder Schritte enthält, die zum Auflösen oder Behandeln der der Regel zugeordneten Ausnahme vorgenommen werden müssen, und Prozessdaten zum Betrieb des Prozesses, in dem die Ausnahme, die die Regel betrifft, zu dem Zeitpunkt des Auftretens der Ausnahme aufgetreten ist.
Qualitätsprüfungsmanagementsystem nach Anspruch 1, wobei die Ausnahme-Engine Daten für jede identifizierte Ausnahme als Ausnahmedatensatz in einer Ausnahmedatei speichert, die einem Auftrag zugeordnet ist.
Qualitätsprüfungsmanagementsystem nach Anspruch 1, wobei die Ausnahme-Engine während des Betriebs des Prozesses zum Implementieren eines Auftrags, eine Ausnahmedatei oder Datenbank für den Auftrag zu erstellen, in Echtzeit arbeitet.
Qualitätsprüfungsmanagementsystem nach Anspruch 11, wobei die Ausnahme-Engine einem Prozessbediener eine Live-Rückmeldung liefert, dass eine Ausnahme aufgetreten ist oder in Kürze auftreten wird, basierend auf der Erkennung einer Ausnahme durch eine oder mehrere der Regeln.
Qualitätsprüfungsmanagementsystem nach Anspruch 1, wobei das Konfigurationssystem einen Satz von Regelvorlagen enthält, die verschiedenen Arten von Eingangsdaten zugeordnet sind, um eine Ausnahme zu erkennen, und das Konfigurationssystem es dem Benutzer ermöglicht, über die Benutzerschnittstelle einen der Sätze von Regelvorlagen auszuwählen, und es dem Benutzer ermöglicht, über die Benutzerschnittstelle Regelparameter und Regeleingänge/-ausgänge für die zu erstellende Regel zu definieren.
Qualitätsprüfungsmanagementsystem nach Anspruch 13, wobei das Konfigurationssystem es dem Benutzer ermöglicht, über die Benutzerschnittstelle einen logischen Ausdruck zu definieren, der für einen Satz von Eingabedaten und Regelparametern analysiert werden soll, die in dem logischen Ausdruck zum Erkennen einer Ausnahme verwendet werden sollen.
Qualitätsprüfungsmanagementsystem, umfassend: eine Regeldatenbank, die eine Vielzahl von Regeln speichert, wobei jede der Vielzahl von Regeln eine Logik enthält, die Bedingungen identifiziert, die einer oder mehreren Ausnahmen innerhalb eines Prozesses zugeordnet sind; eine Ausnahme-Engine, die Daten innerhalb einer Datennachricht von einer Prozessausrüstung unter Verwendung der Regeln in der Regeldatenbank verarbeitet, um zu bestimmen, ob eine Ausnahme existiert, wie sie durch eine der Vielzahl von Regeln definiert ist, wobei die Ausnahme-Engine beim Identifizieren einer Ausnahme basierend auf einer der Regeln Informationen über die Ausnahme als Ausnahmedatensatz speichert; und eine Überprüfungsschnittstelle, die es einem Benutzer ermöglicht, Ausnahmen zu behandeln, wie sie von der Ausnahme-Engine identifiziert und als die Ausnahmedatensätze in einer Ausnahmedatensatzdatenbank gespeichert sind, wobei die Überprüfungsschnittstelle auf die Ausnahmedatenbank zugreift, einem Benutzer Informationen zu einer oder mehreren identifizierten Ausnahmen über die Benutzerschnittstelle darstellt und dem Benutzer Daten bereitstellt, die für jeden Ausnahmedatensatz gespeichert sind und die es dem Benutzer ermöglichen, eine Aktion in Bezug auf jeden Ausnahmedatensatz auszuführen.
Qualitätsprüfungsmanagementsystem nach Anspruch 15, wobei die Überprüfungsschnittstelle dem Benutzer für jeden Ausnahmedatensatz einen Ausnahmetyp oder einen Schweregrad einer Ausnahme bereitstellt.
Qualitätsprüfungsmanagementsystem nach Anspruch 15, wobei die Überprüfungsschnittstelle dem Benutzer für jeden Ausnahmedatensatz Daten zu einer oder mehreren Prozessvariablen, Zuständen oder Verfahren bereitstellt, die zum Zeitpunkt des Auftretens der Ausnahme vorlagen.
Qualitätsprüfungsmanagementsystem nach Anspruch 15, wobei die Ausnahme-Engine für jede Ausnahme einen Auftrag speichert, der zum Zeitpunkt der Ausnahme verarbeitet wurde, und wobei die Überprüfungsschnittstelle dem Benutzer eine Gruppe von Ausnahmen für einen bestimmten Auftrag bereitstellt.
Qualitätsprüfungsmanagementsystem nach Anspruch 15, wobei die Überprüfungsschnittstelle es dem Benutzer ermöglicht, eine Ausnahme zu bestätigen.
Qualitätsprüfungsmanagementsystem nach Anspruch 15, wobei die Überprüfungsschnittstelle es dem Benutzer ermöglicht, eine Ausnahme freizugeben oder zu schließen.
Qualitätsprüfungsmanagementsystem nach Anspruch 15, wobei die Überprüfungsschnittstelle es dem Benutzer ermöglicht, einen Ausnahmedatensatz mit Anmerkungen mit weiteren Informationen zu versehen.
Qualitätsprüfungsmanagementsystem nach Anspruch 15, wobei die Überprüfungsschnittstelle es dem Benutzer ermöglicht, einen Ausnahmedatensatz an eine andere Person zu senden.
Qualitätsprüfungsmanagementsystem nach Anspruch 15, wobei die Überprüfungsschnittstelle dem Prüfer eine oder mehrere vorgeschlagene oder obligatorische Aktionen bereitstellt, die basierend auf der Ausnahme durchzuführen sind.
Qualitätsprüfungsmanagementsystem nach Anspruch 23, wobei die Überprüfungsschnittstelle den Benutzer zwingt, eine Freigabe durch eine bestimmte Anzahl oder einen bestimmten Typ von Personen zu erhalten, oder erfordert, dass bestimmte Informationen vom Prüfer bereitgestellt werden, die mit dem Ausnahmedatensatz zur späteren Verwendung gespeichert werden.
Qualitätsprüfungsmanagementsystem nach Anspruch 15, wobei die Überprüfungsschnittstelle die verarbeiteten Ausnahmedatensätze in einer Datenbank speichert und es dem Benutzer ermöglicht, durch die Ausnahmedatensätze in der Ausnahmedatenbank zu scrollen, um zu bestimmen, ob und wann alle der Ausnahmedatensätze für einen Auftrag verarbeitet oder geschlossen wurden, einen Status der Überprüfung oder statistische Daten zu den Ausnahmedatensätzen zu bestimmen.
Qualitätsprüfungsmanagementsystem nach Anspruch 15, wobei die Überprüfungsschnittstelle es dem Benutzer ermöglicht, Ausnahmedatensätze auf eine oder mehrere verschiedene Arten zu gruppieren.
Qualitätsprüfungsmanagementsystem nach Anspruch 15, wobei die Überprüfungsschnittstelle es dem Benutzer ermöglicht, eine oder mehrere Aktionen für eine ganze Gruppe von Ausnahmedatensätzen vorzunehmen.
Qualitätsprüfungsmanagementsystem zur Verwendung beim Überprüfen des Betriebs eines Prozesses, umfassend: eine Regeldatenbank, die eine Vielzahl von Regeln speichert, wobei jede der Vielzahl von Regeln eine Logik enthält, die Bedingungen identifiziert, die einer oder mehreren Ausnahmen innerhalb eines Prozesses zugeordnet sind; eine oder mehrere Datenquellen, die dazu konfiguriert sind, Prozessdaten innerhalb des Prozesses während des Betriebs des Prozesses zu sammeln, und dazu konfiguriert sind, die gesammelten Prozessdaten in einer oder mehreren Datennachrichten zu senden, wobei die Prozessdaten Prozessdaten enthalten, die in einer oder mehreren Regeln verwendet werden, um eine Ausnahme zu analysieren, und Prozessmetadaten enthalten; eine Ausnahme-Engine, die die Prozessdaten in einer oder mehreren Datennachrichten aus den Datenquellen unter Verwendung der Regeln in der Regeldatenbank verarbeitet, um zu bestimmen, ob eine Ausnahme vorliegt, wie sie durch eine der Vielzahl von Regeln basierend auf den Prozessdaten in den Datennachrichten definiert ist, wobei die Ausnahme-Engine bei Identifizieren einer Ausnahme basierend auf einer der Regeln einen Ausnahmedatensatz für die bestimmte Ausnahme erstellt und den Ausnahmedatensatz in einer Ausnahmedatensatzdatenbank speichert, und wobei die Ausnahme-Engine die Prozessmetadaten für die Ausnahme als Teil des Ausnahmedatensatzes speichert; und eine Überprüfungsschnittstelle, die es einem Benutzer ermöglicht, Ausnahmen zu überprüfen, wie sie von der Ausnahme-Engine identifiziert und als die Ausnahmedatensätze in einer Ausnahmedatensatzdatenbank gespeichert sind, wobei die Überprüfungsschnittstelle auf die Ausnahmedatensatzdatenbank zugreift, einem Benutzer Informationen zu einer oder mehreren identifizierten Ausnahmen über die Benutzerschnittstelle darstellt und dem Benutzer die für jeden Ausnahmedatensatz gespeicherten Metadaten bereitstellt.
Qualitätsprüfungsmanagementsystem nach Anspruch 28, wobei die Datenquellen die Prozessmetadaten gleichzeitig mit den Prozessdaten sammeln.
Qualitätsprüfungsmanagementsystem nach Anspruch 28, wobei die Ausnahme-Engine eine Anweisung an eine der Datenquellen sendet, um die Prozessmetadaten zu sammeln, wenn die Ausnahme-Engine eine Ausnahme in Prozessdaten erkennt, die von der einen der Datenquellen gesendet werden.
Qualitätsprüfungsmanagementsystem nach Anspruch 28, wobei die Prozessmetadaten Prozessumgebungsdaten umfassen.
Qualitätsprüfungsmanagementsystem nach Anspruch 28, wobei die Prozessmetadaten einen oder mehrere Prozessvariablenwerte oder Prozesszustände umfassen.
Qualitätsprüfungsmanagementsystem nach Anspruch 28, wobei die Prozessmetadaten einen Prozess-Speicherauszug umfassen, der Prozessdaten enthält, die für einen Prüfer bei der Durchführung einer Ausnahmeprüfung nützlich sind.
Qualitätsprüfungsmanagementsystem zur Verwendung beim Überprüfen des Vorgangs eines Prozesses, umfassend: eine Regeldatenbank, die eine Vielzahl von Regeln speichert, wobei jede der Vielzahl von Regeln eine Logik enthält, die Bedingungen identifiziert, die einer oder mehreren Ausnahmen innerhalb eines Prozesses zugeordnet sind; eine oder mehrere Datenquellen, die dazu konfiguriert sind, Prozessdaten innerhalb des Prozesses während des Betriebs des Prozesses zu sammeln und die gesammelten Prozessdaten in einer oder mehreren Datennachrichten zu senden; eine Ausnahme-Engine, die die Prozessdaten in einer oder mehreren Datennachrichten aus den Datenquellen unter Verwendung der Regeln in der Regeldatenbank verarbeitet, um zu bestimmen, ob eine Ausnahme vorliegt, wie durch eine der Vielzahl von Regeln basierend auf den Prozessdaten in den Datennachrichten definiert, wobei die Ausnahme-Engine bei Identifizieren einer Ausnahme basierend auf einer der Regeln einen Ausnahmedatensatz für die bestimmte Ausnahme erstellt und den Ausnahmedatensatz in einer Ausnahmedatensatzdatenbank speichert; ein Plug-in-Modul, das kommunikativ mit einer externen Datenquelle und der Ausnahme-Engine verbunden ist, wobei das Plug-in-Modul Daten von der externen Datenquelle empfängt, die Daten von der externen Datenquelle analysiert und externe Informationen bezüglich der externen Datenquelle an die Ausnahme-Engine sendet, und wobei die Ausnahme-Engine eine oder mehrere weitere Ausnahmen basierend auf den externen Informationen aus dem Plug-in-Modul erkennt und einen oder mehrere weitere Ausnahmedatensätze in der Ausnahmedatensatzdatenbank für die eine oder mehreren weiteren Ausnahmen erstellt und speichert; und eine Überprüfungsschnittstelle, die es einem Benutzer ermöglicht, die Ausnahmen und die weiteren Ausnahmen, wenn sie von der Ausnahme-Engine identifiziert werden und wenn sie als die Ausnahmedatensätze gespeichert werden, und die weiteren Ausnahmedatensätze in der Ausnahmedatensatzdatenbank zu überprüfen.
Qualitätsprüfungsmanagementsystem nach Anspruch 34, wobei die externe Datenquelle ein Prozesssteuerungssystem ist und das Plug-in-Modul Prozesssteuerungsdaten analysiert.
Qualitätsprüfungsmanagementsystem nach Anspruch 34, wobei die externe Datenquelle eine OPC-Schnittstelle ist und das Plug-in-Modul OPC-Daten analysiert.
Qualitätsprüfungsmanagementsystem nach Anspruch 34, wobei die externe Datenquelle Alarme und Ereignisdaten von dem externen System empfängt und das Plug-in-Modul die Alarm- und Ereignisdaten von dem externen System analysiert, um die externen Informationen zu generieren.
Qualitätsprüfungsmanagementsystem nach Anspruch 34, wobei die Ausnahme-Engine in einem ersten Server ausgeführt wird und wobei das Plug-in-Modul in dem ersten Server ausgeführt wird.
Qualitätsprüfungsmanagementsystem nach Anspruch 34, wobei die Ausnahme-Engine in einem ersten Server ausgeführt wird und wobei das Plug-in-Modul in dem zweiten Server ausgeführt wird, der sich von dem ersten Server unterscheidet.
Qualitätsprüfungsmanagementsystem nach Anspruch 34, wobei das Plug-in-Modul eine Ausnahmeverarbeitung für die Daten von der externen Datenquelle durchführt.
Qualitätsprüfungsmanagementsystem nach Anspruch 34, wobei die Ausnahme-Engine eine oder mehrere Regeln innerhalb der Regeldatenbank verwendet, um die externen Informationen von dem Plug-in-Modul zu analysieren, um eine oder mehrere Ausnahmen zu erkennen.
Qualitätsprüfungsmanagementsystem nach Anspruch 34, wobei die externe Datenquelle ein Sicherheitsinstrumentierungssystem ist und das Plug-in-Modul Sicherheitsinstrumentierungsdaten analysiert.
Qualitätsprüfungsmanagementsystem nach Anspruch 34, wobei die externe Datenquelle ein Wartungssystem ist und das Plug-in-Modul Wartungsdaten analysiert.
Qualitätsprüfungsmanagementsystem zur Verwendung beim Überprüfen des Betriebs eines Prozesses, umfassend: eine Regeldatenbank, die eine Vielzahl von Regeln speichert, wobei jede der Vielzahl von Regeln eine Logik enthält, die Bedingungen identifiziert, die einer oder mehreren Ausnahmen innerhalb eines Prozesses zugeordnet sind; eine oder mehrere Datenquellen, die dazu konfiguriert sind, Prozessdaten innerhalb des Prozesses während des Betriebs des Prozesses zu sammeln und die gesammelten Prozessdaten in einer oder mehreren Datennachrichten zu senden; eine Ausnahme-Engine, die die Prozessdaten in einer oder mehreren Datennachrichten aus den Datenquellen unter Verwendung der Regeln in der Regeldatenbank verarbeitet, um zu bestimmen, ob eine Ausnahme vorliegt, wie durch eine der Vielzahl von Regeln basierend auf den Prozessdaten in den Datennachrichten definiert, wobei die Ausnahme-Engine bei Identifizieren einer Ausnahme basierend auf einer der Regeln einen Ausnahmedatensatz für die bestimmte Ausnahme erstellt und den Ausnahmedatensatz in einer Ausnahmedatensatzdatenbank speichert; einen Ereignismonitor, der kommunikativ mit einem externen System und der Ausnahme-Engine verbunden ist, wobei der Ereignismonitor dazu konfiguriert ist, im externen System generierte Ereignisse und Alarme zu erkennen und externe Informationen bezüglich der Ereignisse und Alarme innerhalb des externen Systems an die Ausnahme-Engine zu senden; und wobei die Ausnahme-Engine eine oder mehrere weitere Ausnahmen basierend auf den externen Informationen vom Ereignismonitor erkennt und einen oder mehrere weitere Ausnahmedatensätze in der Ausnahmedatensatzdatenbank für die eine oder mehreren weiteren Ausnahmen erstellt und speichert; und eine Überprüfungsschnittstelle, die es einem Benutzer ermöglicht, die Ausnahmen und die weiteren Ausnahmen, wie von der Ausnahme-Engine identifiziert und als die Ausnahmedatensätze gespeichert, und die weiteren Ausnahmedatensätze in einer Ausnahmedatensatzdatenbank zu überprüfen.
Qualitätsprüfungsmanagementsystem nach Anspruch 34, wobei das externe System ein Prozesssteuersystem ist und der Ereignismonitor Ereignisse innerhalb des Prozesssteuersystems erkennt.
Überprüfungssystem, umfassend: eine Datensatzdatenbank, in der eine Vielzahl von Datensätzen zur Überprüfung gespeichert sind; und eine Überprüfungsanwendung, die auf einem Computerverarbeitungsgerät ausgeführt wird, das es einem Benutzer ermöglicht, die in der Datenbank gespeicherten Datensätze über eine Benutzerschnittstelle anzuzeigen, wobei die Überprüfungsanwendung enthält: eine Suchroutine, die einen oder mehrere Suchparameter von einem Benutzer über die Benutzerschnittstelle akzeptiert, die sich auf eine Suche nach einem Satz von Datensätzen in der Datensatzdatenbank bezieht, ein Zugriffsmodul, das relevante Datensätze aus der Datensatzdatenbank abruft, wie durch die Suchparameter als Teil einer Suche definiert, und ein Darstellungsmodul, das dem Benutzer die relevanten Datensätze im Zusammenhang mit der Suche über mehrere verschiedene Bildschirme auf der Benutzerschnittstelle darstellt, wobei die Überprüfungsanwendung aufeinanderfolgende Sätze von Datensätzen zu unterschiedlichen Zeiten erhält, um sie dem Benutzer über die Benutzerschnittstelle für eine bestimmte Suche anzuzeigen, einschließlich eines ersten Satzes von Datensätzen, die dem Benutzer zu einem ersten Zeitpunkt angezeigt werden, und eines zweiten Satzes von Datensätzen, die dem Benutzer zu einem zweiten und nachfolgenden Zeitpunkten angezeigt werden, und wobei die Überprüfungsanwendung eine Markierung speichert, die einen oder mehrere der Datensätze für den ersten Satz von Datensätzen markiert, die dem Benutzer angezeigt werden, und die Markierung verwendet, um den zweiten Satz von Datensätzen zu erhalten, der über die Benutzerschnittstelle zum zweiten Zeitpunkt angezeigt werden soll.
Überprüfungssystem nach Anspruch 46, wobei die Markierung den letzten Datensatz in dem ersten Satz von Datensätzen markiert, wie er dem Benutzer angezeigt wird.
Überprüfungssystem nach Anspruch 47, wobei die Überprüfungsanwendung die Markierung verwendet, um den zweiten Satz von Datensätzen zu bestimmen, indem sie die bestimmte Suche erneut durchführt und den zweiten Satz von Datensätzen als den Satz von Datensätzen unmittelbar nach dem Datensatz bestimmt, auf den sich die Markierung in dem zurückgegebenen Satz von Datensätzen entsprechend der erneut durchgeführten bestimmten Suche bezieht.
Überprüfungssystem nach Anspruch 46, wobei die Markierung den nächsten Datensatz nach dem letzten Datensatz in dem ersten Satz von Datensätzen markiert, wie sie dem Benutzer angezeigt werden.
Überprüfungssystem nach Anspruch 46, wobei die Überprüfungsanwendung die Markierung verwendet, um den zweiten Satz von Datensätzen zu erhalten, indem sie nach einem Satz von Datensätzen unmittelbar nach dem durch die Markierung markierten Datensatz sucht.
Überprüfungssystem nach Anspruch 46, wobei die Markierung den ersten Datensatz in dem ersten Satz von Datensätzen markiert, wie er dem Benutzer angezeigt wird.
Überprüfungssystem nach Anspruch 51, wobei die Überprüfungsanwendung die Markierung verwendet, um den zweiten Satz von Datensätzen zu bestimmen, indem sie die bestimmte Suche erneut durchführt und den zweiten Satz von Datensätzen als den Satz von Datensätzen unmittelbar vor dem Datensatz bestimmt, auf den sich die Markierung in dem zurückgegebenen Satz von Datensätzen gemäß der erneut durchgeführten bestimmten Suche bezieht.
Überprüfungssystem nach Anspruch 46, wobei die Markierung den ersten und den letzten Datensatz in dem ersten Satz von Datensätzen markiert, wie er dem Benutzer angezeigt wird.
Überprüfungssystem nach Anspruch 46, wobei die Überprüfungsanwendung beim Laden des zweiten Satzes von Datensätzen die Markierung entfernt, die einem Datensatz in dem ersten Satz von Datensätzen zugeordnet ist.
Überprüfungssystem nach Anspruch 46, wobei die Überprüfungsanwendung beim Laden des zweiten Satzes von Datensätzen eine neue Markierung hinzufügt, die einem Datensatz in dem zweiten Satz von Datensätzen zugeordnet ist.
Überprüfungssystem nach Anspruch 46, wobei die Markierung, die einem vom ersten Satz von Datensätzen zugeordnet ist, als Teil des einen vom ersten Satz von Datensätzen gespeichert wird.
Überprüfungssystem nach Anspruch 46, wobei die Markierung eine separate Variable ist, die den Datensatz in dem ersten Satz von Datensätzen angibt.
Überprüfungssystem nach Anspruch 46, wobei die Markierung als separate Variable in der Datensatzdatenbank gespeichert ist.
Überprüfungssystem nach Anspruch 46, wobei die Markierung als separate Variable in dem Gerät gespeichert ist, das die Überprüfungsanwendung ausführt.
Überprüfungssystem nach Anspruch 46, wobei die Markierung ein variabler Wert ist, der einem Datensatz in der Datensatzdatenbank zugeordnet ist.
Überprüfungssystem nach Anspruch 60, wobei die Markierung eines von einem Zeitstempel des Datensatzes, einem Datensatznamen oder einer Datensatzidentifikationsnummer ist.
Überprüfungssystem nach Anspruch 46, wobei die Überprüfungsanwendung die Markierung dazu verwendet, den zweiten Satz von Datensätzen zu bestimmen, indem sie die bestimmte Suche erneut als zweite Suche basierend auf den Suchparametern durchführt, und wobei, wenn der der Markierung zugeordnete Datensatz in der zweiten Suche nicht gefunden wird, die Überprüfungsanwendung einen Datensatz in dem zweiten Satz von Datensätzen bestimmt, der an den Datensatz in der Suche angrenzte, und den bestimmten Datensatz verwendet, um den zweiten Satz von Datensätzen zu identifizieren, der dem Benutzer angezeigt werden soll.