DE10007971A1

DE10007971A1 - Diagnoseexpertensystem zum Einsatz in der Prozesssteuerung

Info

Publication number: DE10007971A1
Application number: DE10007971A
Authority: DE
Inventors: Trevor D Schleiss; Todd B Brase; Suresh Sai Ganesamoorthi; Mark J Nixon; Terrence L Blevins
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 1999-02-22
Filing date: 2000-02-22
Publication date: 2000-10-26
Also published as: GB2347234A; JP2001022430A; GB2347234B; US6633782B1; GB0004093D0

Abstract

Ein Diagnosesystem zum Einsatz in einem Prozesssteuersystem (10) erfasst Informationen (50), die sich auf den Betrieb des Prozesssteuersystems (10) beziehen, und speichert diese in einer Datenbank (50) ab, und setzt ein Expertensystem (60') zur Anwendung von Regeln für die Analyse der Informationen in der Datenbank (50) zur Festlegung von Lösungen bei Problemen ein. In der Datenbank (50) werden Informationen verschiedener Art abgespeichert, wie beispielsweise Ereignis- und Alarmdaten, Hinweise zu geplanten Wartungsarbeiten und Änderungen bei den Betriebsparametern, sowie Daten zur Vorgeschichte, die sich auf vorherige Änderungen an dem Prozesssteuersystem (10) beziehen und für die Ermittlung der Ursache des in dem Prozesssteuersystem (10) erfassten Problems sowie die Festlegung der Schritte wichtig sind, die entweder für die weitere Analyse oder für die Behebung der erfassten Probleme nötig sind. Das Diagnosesystem identifiziert die Ursache des Probelms und identifiziert die geeigneten Analysewerkzeuge und lässt diese ablaufen, oder veranlasst Maßnahmen zur Behebung auf der Grundlage der Regeln zur Analyse für das Expertensystem (60').

Description

ALLGEMEINES ZUR ERFINDUNG

Die Erfindung bezieht sich ganz allgemein auf Prozesssteuersysteme und insbesondere auf die automatische Erfassung, Analyse und Korrektur von Problemen, die in Funktionsblöcken, Geräten und Regelkreisen in einer Prozesssteuerung.

Für diese Anmeldung wird die Priorität der parallelen vorläufigen US-Anmeldung Ser. No. 60/160,101 vom 18. Oktober 1999 und der am 22. Februar 1999 eingereichten US-Anmeldung Ser. No. 09/256,585 in Anspruch genommen.

STAND DER TECHNIK

Prozesssteuersysteme wie sie beispielsweise zur Steuerung von Prozessabläufen in der chemischen Industrie, der petrochemischen Industrie oder anderen Industriezweigen eingesetzt werden, umfassen einen zentralisierten Prozessrechner, der kommunikativ mit mindestens einem Host- bzw. Bedienerarbeitsplatz und einem oder mehreren Außengeräten über analoge, digitale oder kombinierte Analog- /Digital-Busleitungen verbunden ist. Die Außengeräte bzw. Feldgeräte, bei denen es sich beispielsweise um Ventile, Ventilsteller, Schalter und Geber (z. B. Temperaturfühler, Druckfühler und Durchflussmengengeber) handeln kann, führen Funktionen im Rahmen des jeweiligen Prozesses aus, wie zum Beispiel das Öffnen oder Schließen von Ventilen und die Messung von Prozessparametern. Der Prozessrechner empfängt Signale, welche die von den Außengeräten erfassten Prozessmesswerte und/oder weitere Informationen angeben, die den Außengeräten zuzuordnen sind, verwendet diese Informatio nen zur Realisierung einer Steuerroutine und erzeugt dann Steuersignale, die zur Steuerung des Prozessablaufs über die Busleitungen an die Außengeräte übermittelt werden. Informationen von den Außengeräten und vom Steuerrechner werden dann im typischen Fall einer oder mehrerer Anwendungen zur Verfügung gestellt, welche in dem Bedienerarbeitsplatz ausgeführt werden und einen Bediener in die Lage versetzen, im Zusammenhang mit dem Prozess eine beliebige Funktion auszuführen, wie zum Beispiel die Beobachtung des augen blicklichen Prozessstands, die Abänderung des Prozessablaufs, usw.

In der Vergangenheit wurden herkömmliche Außengeräte zum Übermitteln und Übernehmen analoger Signale (z. B. 4 bis 20 mA) an den bzw. von dem Prozessrechner über eine analoge Busleitung oder analoge Leitungen eingesetzt. Diese Signale von 4-20 mA waren von ihrer Art her insofern eingeschränkt, als sie Messwerte, die von dem Gerät erfasst wurden, oder Steuersignale, die vom Prozessrechner generiert wurden und zur Steuerung des Betriebs des Geräts erforderlich sind, angaben. Im Laufe der rund zehn letzten Jahre setzten sich jedoch im Bereich der Prozesssteuerungen intelligente Außengeräte durch, die einen Mikroprozessor und einen Speicher aufweisen. Neben der Ausführung einer Hauptfunktion im Rahmen des jeweiligen Prozesses speichern intelligente Außengeräte Daten, die dem Gerät zuzuordnen sind, kommunizieren mit dem Steuerrechner und/oder anderen Geräten im digitalen oder kombinierten digitalen und analogen Format, und führen Nebenaufgaben durch wie beispielsweise die Eigenkalibrierung, Identifizierung, Diagnose, usw. Es wurde bisher eine ganze Anzahl standardisierter und offener Kommu nikationsprotokolle für intelligente Geräte wie beispielsweise die Protokolle HART®, PROFIBUS®, Device-Net® und CAN entwickelt, damit intelligente Außengeräte verschiedener Hersteller im Rahmen eines einzigen Prozesssteuernetzwerkes zusammen eingesetzt werden können.

Darüber hinaus gab es innerhalb des Industriezweigs der Prozesssteuerungen eine Bewegung hin zur Dezentralisierung von Prozesssteuerfunktionen. Beispielsweise arbeitet das voll digital aufgebaute, mit Zweidraht-Busleitung funktionierende Protokoll, das unter der Bezeichnung FOUNDATION^TM Fieldbus (nachstehend als "Fieldbus" bezeichnet) bekannt ist und von der Fieldbus Foundation verbreitet wird, mit Funktionsblöcken, die sich in verschiedenen Außengeräten befinden und zur Ausführung von Steuer- und Regelvorgängen vorgesehen sind, die zuvor in einem zentralisierten Steuerrechner ausgeführt wurden. Insbesondere ist jedes Fieldbus-Außengerät in der Lage, einen oder mehrere Funktionsblöcke einzubeziehen und auszuführen, von denen jeder von anderen Funktionsblöcken (die sich entweder im selben Gerät oder in unterschiedlichen Geräten befinden) Eingangsinformationen übernimmt und/oder an diese Ausgangsin formationen abgibt und irgendeinen Arbeitsgang im Rahmen der Prozesssteuerung ausführt, wie zum Beispiel die Messung oder Erfassung eines Prozessparameters, die Regelung bzw. Steuerung eines Geräts oder die Ausführung eines Regelvorgangs wie zum Beispiel die Realisierung einer proportional differenzierenden und integrierenden (PID) Steuerroutine. Die verschiedenen Funktionsblöcke innerhalb eines Prozesssteuersystems sind so ausgelegt, dass sie miteinander kommunizieren (z. B. über eine Busleitung), um so eine oder mehrere Regelkreise zur Prozesssteuerung zu bilden, deren jeweilige Funktionen über den gesamten Prozess verteilt und damit dezentralisiert sind.

Durch die Einführung intelligenter Außengeräte ist es wichtiger als jemals zuvor, dass Probleme, die in einem Prozesssteuersystem auftreten, rasch diagnostiziert und behoben werden können, da ein Fehler oder Ausfall der Funktion zur Erfassung und Korrektur unzulänglich funktionierender Regelschleifen und Geräte, zum Ablauf des Prozesses unter dem optimalen Standard führt, was sowohl hin sichtlich der Qualität als auch im Hinblick auf die Quantität des gerade produzierten Erzeugnisses kostspielig sein kann. Viele intelligente Geräte umfassen derzeit Routinen zur Eigendiagnose und/oder Kalibrierung, die zur Erfassung und Behebung von Problemen in dem Gerät eingesetzt werden können. Beispielsweise besitzen die von Fisher Controls International Inc. hergestellten Geräte FieldVue und ValveLink Möglichkeiten zur Diagnose, die zur Erfassung bestimmter Probleme in diesen Geräten herangezogen werden können, und sind auch mit Prozeduren zur Kalibrierung ausgerüstet, die zur Behebung von Problemen eingesetzt werden können, sobald sie erkannt wurden. Ein Bediener muss jedoch den Verdacht auf Vorliegen eines Problems im Gerät haben, ehe er wahrscheinlich solche Diagnose- oder Kalibriereinrichtungen der Geräte verwenden kann. Es stehen auch andere Werkzeuge zur Prozesssteuerung zur Verfügung wie beispielsweise Autotuner, die zur Korrektur unzulänglich abgestimmter Regelkreise innerhalb eines Prozesssteuernetzwerks verwendet werden können. Auch hierbei ist es allerdings erforderlich, einen unzulänglich funktionierenden Regelkreis zu identifizieren, ehe derartige Autotuner effizient eingesetzt werden können. In gleicher Weise gibt es auch andere, noch kompliziertere Diagnosehilfen wie beispielsweise Expertensysteme, Werkzeuge zur Korrelationsanalyse, Werkzeuge zur Spektrumsanalyse, neuronale Netzwerke, usw., die mit Prozessdaten arbeiten, welche für ein Gerät oder einen Regelkreis zur Erkennung von darin vorliegenden Problemen er fasst wurden. Diese Werkzeuge bzw. Hilfsmittel (Tools) sind leider aber datenintensiv, und es ist praktisch unmöglich, alle Hochgeschwindigkeitsdaten zu erfassen und abzuspeichern, die zur Realisierung derartiger Werkzeuge auf jedem Prozesssteuergerät bzw. in jedem Regelkreis eines Prozesssteuersystems in irgendeiner systematischen Weise benötigt werden. Somit ist es wiederum erforderlich, einen problembehafteten Regelkreis oder ein Gerät zu identi fizieren, ehe diese Werkzeuge effizient eingesetzt werden können.

Darüber hinaus erfasst jedes Gerät bzw. jeder Funktionsblock im Rahmen eines intelligenten Netzwerks zur Prozesssteuerung größere Fehler, die darin auftreten, und sendet ein Signal wie zum Beispiel ein Alarm- oder ein Ereignissignal zur Meldung an eine Steuerung bzw. einen Host-Rechner, dass ein Fehler bzw. ein anderes Problem aufgetreten ist. Das Vorliegen solcher Alarm- bzw. Ereignismeldungen ist nicht unbedingt ein Hinweis auf ein langfristig bestehendes Problem bei dem Gerät bzw. dem Regelkreis, das behoben werden muss, da solche Alarm- bzw. Ereignismeldungen als Reaktion auf andere Faktoren generiert (oder von diesen verursacht) werden, die nicht das Ergebnis einer Fehlleistung in einem Gerät oder einem Regelkreis sind. Somit bedeutet die Tatsache, dass ein Gerät oder ein Funktionsblock innerhalb eines Regelkreises eine Alarm- oder Ereignismeldung generiert, nicht unbedingt, dass in dem Gerät oder dem Regelkreis ein Problem vorliegt, das behoben werden muss. Andererseits kann es bei vielen Geräten Probleme geben, ohne dass das Problem, das ernst wird, als Alarm oder Ereignis erfasst wird.

Zur anfänglichen Erfassung von Problemen im Rahmen des Prozessteuersystems muss ein Prozesssteuerungsingenieur bzw. -techniker im allgemeinen Daten von Hand überprüfen, die in einem Prozesssteuersystem generiert wurden (z. B. in Form von Alarm- und Ereignismeldungen, neben anderen Geräte- und Regelkreisdaten), um die jeweiligen Geräte bzw. Regelkreise zu identifizieren, die nicht optimal arbeiten oder nicht korrekt abgestimmt sind. Für diese manuelle Überprüfung muss der Bediener über ein hohes Maß an Erfahrung bei der Erfassung von Problemen anhand von Rohdaten verfügen, und auch mit solcher Erfahrung kann diese Arbeit im günstigsten Fall zeitraubend und im ungünstigsten Fall überwältigend sein. Beispielsweise kann eine Instrumentierungsabteilung schon bei einem mittelgroßen Werk zwischen 3.000 und 6.000 Außengeräte wie Ventile und Messumformer umfassen. In einem solchen Umfeld hat der Instrumentierungstechniker bzw. der Steuer- und Regeltechniker, der für einen Prozessbereich zuständig ist, einfach nicht die Zeit zur Überprüfung der Funktion aller Regel- und Steuerkreise sowie Instru mentierungsschaltungen für die Außengeräte, um festzustellen, welche Steuerkreise oder Geräte unter Umständen nicht korrekt funktionieren bzw. bei welchen gegebenenfalls ein Problem aufgetreten ist. Wegen der begrenzten Zahl von Mitarbeitern sind in der Tat die einzigen Geräte, die normalerweise zur Wartung anstehen, jene, die schon bis zu einem Punkt an Qualität eingebüßt haben, an dem sich die Qualitätsminderung drastisch auf Quantität oder Qualität des hergestellten Produkts auswirkt. Infolgedessen werde andere Geräte oder Regelkreise, die eingesandt werden müssen oder bei denen ansonsten ein Problem aufgetreten ist, das mit Hilfe der ver fügbaren Tools behoben werden könnte, eben nicht in Ordnung gebracht, was zu einer insgesamt schlechter werdenden Leistung des Prozesssteuersystems führt.

Auch nach der Identifizierung von Geräten und Regelkreisen, die unter dem Standard arbeiten, und obwohl die erforderlichen Hilfsmittel zur Diagnose, Abstimmung und weitere Werkzeuge zur weiteren Analyse und Behebung des Problems zur Verfügung stehen, muss der Benutzer über das notwendige Wissen und die nötige Erfahrung verfügen, um das richtige Werkzeug auszuwählen und dieses korrekt zur Problembehebung einzusetzen. In einigen Fällen besitzt der Benutzer unter Umständen nicht ein ausreichendes Fachwissen oder genügend praktische Erfahrung, um das Problem zu lösen. Obwohl ihm Werkzeuge zur Verfügung stehen, die Probleme im Prozesssteuersystem anzeigen und weitere Diagnosewerkzeuge und Maßnahmen zur Behebung empfehlen, benötigt der Benutzer unter Umständen noch weitere Hilfestellung zur effizienten Überwachung des Prozessablaufs und zur Problembehebung.

Zur effizienten Überwachung des Prozesssteuernetzwerks muss der Benutzer mit dem Prozess selbst, mit den Außengeräten und den zur Diagnose und Problembehebung im Prozesssteuernetzwerk zur Verfügung stehenden Tools vertraut sein. Auch wenn dem Benutzer die Außengeräte und die Werkzeuge vertraut sind, hat er unter Umständen nicht einen leichten Zugang zu allen relevanten Daten, wie beispielsweise Ereignisdaten, Trenddaten, historische Daten über Veränderungen und Wartung für das Gerät und den Prozess, und dergleichen. Außerdem handelt es sich bei dem Benutzer an dem Bedienerarbeitsplatz im typischen Fall nicht um einen Fachmann auf dem Gebiet der Prozesstechnik und der Außengeräte. Infolgedessen kann immer noch eine überwältigende Menge an relevanten Informationen zur Auswertung vorliegen, um so die Quelle der Probleme aufzuspüren und die zur Problembehebung erforderlichen Maßnahmen durchzuführen, auch wenn das System selbst gegebenenfalls gewisse Informationen im Zusammenhang mit der verminderten Leistung von Außengeräten und Regelkreisen liefert und Werkzeuge zur Diagnose und Problembehebung vorschlägt.

SUMMARISCHE DARSTELLUNG DER ERFINDUNG KURZBESCHREIBUNG DER ERFINDUNG

Ein Diagnosesystem zum Einsatz bei einem Prozesssteuersystem erfasst und speichert Daten, die sich auf den Betrieb des Prozesssteuersystems beziehen, in einer Datenbank und setzt ein Expertensystem ein, um Regeln zur Analyse in Verbindung mit den in der Datenbank gespeicherten Informationen anzuwenden, um so Lösungen für Probleme bei dem Prozesssteuersystem zu ermitteln. In der Datenbank sind verschiedene Arten von Informationen abgespeichert, die sowohl für die Ermittlung der Ursache der in dem Prozesssteuersystem erfassten Probleme als auch für die zur weiteren Analyse oder zur Behebung der erfassten Probleme einschlägig sind. Die in der Datenbank vorhandenen Informationen umfassen Daten, die sich speziell auf das erfasste Problem und auf das Außengerät, den Funktionsblock oder den Regelkreis beziehen, in dem das erfasste Problem besteht. In der Datenbank können auch Ereignis- und Alarmdaten abgespeichert sein, beispielsweise Hinweise auf geplante Wartungsarbeiten und Änderungen an den Betriebsparametern, die für die Identifizierung der Problemursache und die Identifizierung der geeigneten Maßnahmen zur Analyse und Problembehebung wichtig sind. Die Datenbank kann auch historische Daten enthalten, die sich auf vorhergehende Änderungen an dem Prozesssteuersystem zur Behebung zuvor erkannter Probleme beziehen.

Wenn ein Problem erfasst ist, wendet das Expertensystem die Regeln zur Analyse bei den entsprechenden Daten in der Datenbank an. Als Teil der Analyse können die Regeln eindeutig voraussetzen, dass das Expertensystem zusätzliche Analyseanwendungen aufruft, die in dem Prozesssteuernetzwerk verfügbar sind. Zu den Analyseanwendungen können Abstimmer, Kalibrierer, Diagnosewerkzeuge oder alle anderen Anwendungen gehören, die unter Umständen bei der Analyse und/oder Behebung des erfassten Problems von Nutzen sind.

Des weiteren kann das Diagnosesystem eine Benutzerschnittstelle aufweisen, an welche das Expertensystem Informationen übermittelt, um den Benutzer über das erfasste Problem zu informieren. Das Expertensystem kann auch weitere Informationen übermitteln, die sich, sofern sie verfügbar sind, empfehlenswerte Vorgehensweisen zur weiteren Analyse und/oder Behebung des erfassten Problems beziehen. Beispielsweise kann das Expertensystem die Verwendung eines weiteren Diagnosewerkzeugs bzw. Prüfgeräts empfehlen, um die Ursache des erfassten Problems exakt aufzuspüren. Alternativ kann das Expertensystem eine Empfehlung zur Modifizierung des Prozesssteuersystems liefern, wie zum Beispiel die Veränderung des Werts eines Parameters oder die Veränderung der Logik in einem Regelkreis. Auf Anforderung kann das Expertensystem auch die empfohlenen Werkzeuge einsetzen oder den Benutzer durch die Schritte führen, die zur Vornahme einer empfohlenen Veränderung erforderlich sind.

Auf diese Weise zieht das Diagnosesystem alle verfügbaren einschlägigen Informationen zur Analyse des erfassten Problems heran, um zu einer empfohlenen Problemlösung zu gelangen. Vorzugsweise läuft das Expertensystem kontinuierlich im Hintergrund, um sich so Problemen schon beim Auftreten zu widmen, doch kann es auch von einem Benutzer, einem auslösenden Ereignis oder einem automatischen Terminplaner initialisiert werden, damit die Probleme effi zient angesprochen werden. Der Betrieb des Expertensystems spart auf Seiten des Benutzers Zeit und setzt nicht voraus, dass der Benutzer über große Erfahrung bei der Lösung von Problemen bei Regelkreisen und Geräten verfügt. Außerdem kann das Diagnosesystem alle Daten sammeln und analysieren, die zur rascheren und effizienteren Lösung des erfassten Problems einschlägig sind. Neben der Zeitersparnis sieht das Diagnosesystem auch eine Verringerung der Belastung auf Seiten des Benutzers vor und trägt dazu bei, die richtigen Diagnosewerkzeuge und Maßnahmen zur Behebung zu gewähr leisten, die in jeder Situation jeweils eingesetzt werden, neben der korrekten Arbeit mit allen diesen Hilfsmitteln.

Eine Aufgabe der vorliegenden Erfindung besteht darin, ein Diagnosesystem der eingangs genannten Art zu schaffen, bei dem Probleme rasch und effizient erfasst und behoben werden und der korrekte Einsatz der verfügbaren Werkzeuge bzw. Hilfsmittel zur Problembehebung gewährleistet ist, was zu Zeitersparnis und Verringerung der Arbeitsbelastung führt. Diese Aufgabe wird erfindungsgemäß mit einem Diagnosesystem der eingangs genannten Art durch die in Anspruch 1 gekennzeichneten Merkmale gelöst.

KURZBESCHREIBUNG DER ZEICHNUNG

In der nachfolgenden Beschreibung wird auf die Zeichnung Bezug genommen, in welcher Ausführungsbeispiele der Erfindung dargestellt sind. Dabei zeigen:

Fig. 1 ein Blockschaltbild eines Prozesssteuersystems, bei dem ein Diagnosewerkzeug eingesetzt werden kann;

Fig. 2 ein Blockschaltbild eines Prozesssteuersystems nach Fig. 1 mit der Darstellung der Auslegung von zwei Prozessregelkreisen, die in Verbindung mit einem Diagnosewerkzeug arbeiten;

Fig. 3 ein Blockschaltbild eines Funktionsblocks mit darin enthaltener Einrichtung zum Generieren einer Angabe zur Variabilität;

Fig. 4 ein Blockschaltbild einer Routine, die von einem Diagnosewerkzeug zur Vornahme einer Diagnose bei dem Prozesssteuersystem gemäß Fig. 1 und 2 realisiert ist;

Fig. 5 einen ersten Beispiels-Bildschirm, der von dem bei dem Prozesssteuersystem gemäß Fig. 1 und 2 eingesetzten Diagnosewerkzeug generiert wird;

Fig. 6 einen zweiten Beispiels-Bildschirm, der von dem bei dem Prozesssteuersystem gemäß Fig. 1 und 2 eingesetzten Diagnosewerkzeug generiert wird;

Fig. 7 einen dritten Beispiels-Bildschirm, der von dem bei dem Prozesssteuersystem gemäß Fig. 1 und 2 eingesetzten Diagnosewerkzeug generiert wird;

Fig. 8 ein Blockschaltbild des Steuerrechners und Bedienerarbeitsplatzes gemäß Fig. 1 und 2 mit der Darstellung von Trendmeldungen in Verbindung mit einem Diagnosewerkzeug;

Fig. 9 ein Blockschaltbild des Prozesssteuersystems nach Fig. 2, das außerdem ein Expertensystem aufweist, das in Verbindung mit dem Diagnosewerkzeug läuft; und

Fig. 10 ein Blockschaltbild des Expertensystems nach Fig. 9.

BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSBEISPIELE

Gemäß Fig. 1 weist ein Prozesssteuersystem 10 einen Prozessrechner 12 auf, der mit einem Zentralarbeitsplatz bzw. Computer 13 verbunden ist (bei dem es sich um einen PC oder einen Arbeitsplatz jedweder Art handeln kann), welcher einen Bildschirm 14 aufweist und über Ein-/Ausgabekarten (E/A- Karten) 26 und 28 mit Außengeräten bzw. Peripheriegeräten 15-22 verbunden ist. Der Prozessrechner 12, der beispielsweise ein von Fisher-Rosemount Systems, Inc. vertriebener Steuerrechner DeltaV^TM sein kann, steht in Kommunikati onsverbindung mit dem Hostrechner 13, zum Beispiel über eine Ethernet-Verbindung, und mit den Außengeräten 15-22, wobei hierzu jede Hardware und Software eingesetzt wird, die beispielsweise in Verbindung mit Standardgeräten von 4-20 mA und/oder einem beliebigen intelligenten Kommunikationsprotokoll wie zum Beispiel ein Fieldbus- Protokoll vorgesehen ist. Der Prozessrechner 12 führt eine darin abgespeicherte oder anderweitig ihm zugeordnete Pro zesssteuerroutine aus oder überwacht diese, und kommuniziert mit den Geräten 15-22 und dem Hostrechner 13 zum Steuern eines Prozesses in jeder gewünschten Form.

Bei den Außengeräten 15-22 kann es sich um Geräte jeglicher Art handeln, wie beispielsweise Sensoren bzw. Fühler, Ventile, Geber, Positionierer, und dergleichen, wohingegen die E/A-Karten 26 und 28 Ein-/Ausgabeeinrichtungen jeglicher Art sein können, die sich für jedes gewünschte Kommunikations- bzw. Rechnerprotokoll eignen. Bei dem in Fig. 1 dargestellten Ausführungsbeispiel handelt es sich bei den Außengeräten 15-18 um standardmäßige Einrichtungen mit 4- 20 mA, die über Analogleitungen mit der E/A-Karate 26 kom munizieren, während die Außengeräte 19-22 intelligente Einrichtungen wie zum Beispiel Fieldbus-Geräte sind, die über eine digitale Busleitung unter Verwendung eines Fieldbus- Protokolls in Kommunikationsverbindung stehen. Ganz allgemein handelt es sich bei dem Fieldbus-Protokoll um ein voll digitalisiertes, serielles Kommunikationsprotokoll zur Zweiweg-Kommunikation, bei dem eine standardmäßige physikalische Schnittstelle mit einem Zweidraht-Regelkreis bzw. einer Zweidraht-Busleitung für die Verbindung der Au ßengeräte untereinander vorgesehen ist. Das Fieldbus- Protokoll bildet tatsächlich ein LAN-Netzwerk für Außengeräte im Rahmen eines Prozesses auf, mit dem diese Außengeräte in die Lage versetzt werden, Prozesssteuerfunktionen (unter Verwendung von Funktionsblöcken) an Punkten auszuführen, die über eine ganze Prozessanlage verteilt sind, und vor und nach der Ausführung dieser Prozesssteuerfunktionen miteinander zu kommunizieren, um so eine globale Regelstrategie zu realisieren. Selbstverständlich ist das Fieldbus-Protokoll auf diesem Gebiet bekannt, auch wenn es sich dabei um ein relativ neues, voll digitales Kommunikationsprotokoll handelt, das zum Einsatz in Prozesssteuernetzwerken entwickelt wurde; dieses Protokoll wird in zahlreichen Artikeln, Broschüren und Spezifikationen im einzelnen beschrieben, die unter anderem von der Fieldbus Foundation, einer gemeinnützigen Organisation mit Hauptsitz in Austin, Texas, veröffentlicht und vertrieben werden und dort zu beziehen sind. Deshalb werden die Einzelheiten des Fieldbus- Kommunikationsprotokolls hier nicht ausführlich beschrieben. Die Außengeräte 15-22 könnten natürlich auch jeder anderen gewünschten Norm bzw. jedem anderen Protokoll als dem Fieldbus-Protokoll entsprechen, zum Beispiel auch irgendwelchen Normen oder Protokollen, die in Zukunft noch entwickelt werden.

Der Prozessrechner 12 ist so ausgelegt, dass er eine Regelstrategie realisiert, bei der das zum Einsatz kommt, was ganz allgemein als Funktionsblöcke bezeichnet wird, wobei jeder Funktionsblock Teil (z. B. eine Subroutine bzw. ein Programmteil) einer globalen Steuerroutine ist und in Verbindung mit anderen Funktionsblöcken (über als Übertragungsverbindung bezeichnete Kommunikationsverbin dungen) zur Realisierung von Prozesssteuerkreisen im Rahmen des Prozesssteuersystems 10 arbeitet. Funktionsblöcke führen im typischen Fall eine Eingabefunktion aus - zum Beispiel eine Funktion, die mit einem Messwertumformer, einem Fühler oder einer anderen Einrichtung zum Messen von Prozessparametern verknüpft ist - oder eine Steuerfunktion - wie zum Beispiel eine Funktion in Verbindung mit einer Steuerroutine, die eine Steuer- und/oder Regelaufgabe in PID- Technik, mit Fuzzy-Logik- usw. ausführt - oder eine Ausgabe funktion, mit der die Betriebsweise irgendeines Geräts, z. B. eines Ventils, zur Ausführung irgendeiner physikalischen Funktion im Rahmen des Prozesssteuersystems 10 geregelt wird. Es sind natürlich auch Hybridblöcke und Funktionsblöcke anderer Art vorhanden. Funktionsblöcke können in dem Prozessrechner 12 abgespeichert sein und von diesem ausgeführt werden, was im typischen Fall dann gegeben ist, wenn diese Funktionsblöcke für oder in Verbindung mit standardmäßigen Einrichtungen mit 4-20 mA und einigen Arten von intelligenten Außengeräten eingesetzt werden, oder sie können in den Außengeräten selbst abgespeichert sein und von diesen realisiert werden, was bei Fieldbus-Einrichtungen der Fall ist. Auch wenn das Steuersystem hier anhand der Verwendung einer Steuer- und Regelstrategie unter Einsatz von Funktionsblöcken beschrieben wird, könnte die Regelstrategie auch unter Heranziehung anderer Konventionen wie beispielsweise einer Leiterlogik realisiert bzw. ausgelegt sein.

Die linke Seite des in Fig. 2 dargestellten Prozessrechners umfasst eine schematische Darstellung miteinander in Verbindung stehender Funktionsblöcke 30, 32 und 34, die zusammen einen Sollwert-Prozesssteuerkreis 36 bilden, der so ausgelegt ist, dass dabei die standardmäßigen Einrichtungen 17 und 18 mit 4-20 mA eingesetzt werden. Da die Funktionsblöcke 30, 32 und 34 auf den Betrieb von 4-20 mA- Einrichtungen bezogen sind, werden sie in dem Prozessrechner 12 abgespeichert und von diesem ausgeführt. Bei einem bevor zugten Ausführungsbeispiel, bei dem eine DeltaV-Steuerung zum Einsatz kommt, sind die Funktionsblöcke 30, 32 und 34 so ausgelegt, dass sie ähnlich wie Fieldbus-Funktionsblöcke aufgebaut sind, also mit demselben oder einem ähnlichen Protokoll wie diese arbeiten. Diese Konvention ist jedoch nicht erforderlich, da stattdessen auch mit anders ausgelegten Funktionsblöcken gearbeitet werden kann. Gemäß der Darstellung in Fig. 2 handelt es sich bei dem Funktionsblock 30 um einen Funktionsblock mit analogem Eingang (AI), der einen Messwert, den beispielsweise der Messwertumformer (Sensoreinrichtung) 17 erfasst hat, an den Funktionsblock 32 weiterleitet. Bei dem Funktionsblock 32 handelt es sich um einen PID-Funktionsblock, der unter Heranziehung jedweder gewünschten PID-Strategie Berechnungen vornimmt und über eine Übertragungsleitung an den Funktionsblock 34 ein Steuersignal abgibt, der vorzugsweise ein Funktionsblock mit analogem Ausgang (AO) ist. Der AO- Funktionsblock 34 kommuniziert beispielsweise mit der Ventileinrichtung 18, um entsprechend dem Steuersignal aus dem PID-Funktionsblock 32 ein Öffnen oder Schließen des Ventils 18 zu veranlassen. Der AO-Funktionsblock 34 gibt auch an den PID-Funktionsblock 32 ein Rückmeldesignal ab, das unter Umständen einen Hinweis auf die Stellung des Ventils 18 liefert, wobei der PID-Funktionsblock 32 dieses Rückmeldesignal zur Erzeugung des Steuersignals heranzieht. Der Prozessrechner 12 weist eine Geräteschnittstelle 38 auf (die unter Umständen im Prozessrechner 12 oder in der Ein- /Ausgabeeinrichtung 26 gemäß Fig. 1 realisiert ist), um mit den Geräten 15-18 zu kommunizieren, um von diesen die erfassten Messwerte zu erhalten und entsprechend dem Regelkreis 36 oder anderen Regelkreisen an diese Steuersignale zu liefern. Die Geräteschnittstelle 38 über nimmt systematisch Signale von den Geräten 15-18 und gibt diese Signale an den eigentlichen Funktionsblock innerhalb des Prozessrechners 12 weiter, der mit der Sendeeinrichtung verbunden ist. In gleicher Weise gibt die Geräteschnittstelle 38 systematisch Steuersignale von den Funktionsblöcken innerhalb des Prozessrechners 12 an die eigentlichen Außengeräte 15-18 weiter.

Die rechte Seite im Prozessrechner 12 gemäß Fig. 2 stellt einen Messwert-Regelkreis 40 dar, der unter Heranziehung von Fieldbus-Funktionsblöcken 42, 44 und 46 realisiert ist, die in den Fieldbus-Außengeräten 19 und 22 nachgeschaltet sind. In diesem Fall sind die tatsächlichen Funktionsblöcke 42, 44 und 46 in den Außengeräten 19 und 22 abgespeichert und werden von diesen ausgeführt, und sie geben kommunikativ die ihnen zugeordneten Attribute an Schatten-Funktionsblöcke 42S, 44S und 46S (als Kästchen mit punktierten Linien dargestellt) innerhalb des Prozessrechners 12 weiter. Die Schatten- Funktionsblöcke 425, 44S und 46S sind entsprechend der vom Prozessrechner 12 verwendeten Konfiguration der Funktionsblöcke aufgebaut, aber spiegeln den Zustand der tatsächlichen Funktionsblöcke 42, 44 bzw. 46, so dass dem Prozessrechner vermittelt wird, dass die tatsächlichen Funktionen, die mit den Funktionsblöcken 42, 44 und 46 verbunden sind, vom Prozessrechner gerade ausgeführt würden. Durch die Verwendung von Schatten-Funktionsblöcken im Prozessrechner hat dieser die Möglichkeit, unter Heranziehung von Funktionsblöcken, die im Prozessrechner 12 sowie in Außengeräten abgespeichert sind und ausgeführt werden, eine Steuer- und Regelstrategie zu realisieren. Der Prozessrechner 12 kann natürlich Regelkreise mit darin vorgesehenen standardisierten Funktionsblöcken (wie die Funktionsblöcke 30, 32 und 34) und Schattenfunktionsblöcken realisieren. Beispielsweise könnte der PID-Schatten-Funktionsblock 44S, der dem eigentlichen Funktionsblock 44 im Ventilsteller 22 zugeordnet ist, mit dem AI-Funktionsblock 30 und dem AO- Funktionsblock 34 zur Bildung eines Prozesssteuerkreises verknüpft sein. Die Bildung und Realisierung von Schatten- Funktionsblöcken ist nicht Gegenstand der vorliegenden Erfindung und wird ausführlicher in der am 10. September 1998 eingereichten US-Patentanmeldung Ser. No. 09/151,084 mit dem Titel "Eine Schnittstelle für Schatten-Funktionsblöcke zum Einsatz bei einem Prozesssteuernetzwerk" beschrieben, die auf den Zessionar der vorliegenden Erfindung übertragen wurde und deren Offenbarung hiermit ausdrücklich durch Querverweis einbezogen wird.

Bei einem Ausführungsbeispiel der Erfindung weist der Prozessrechner eine Einheit 48 zur Diagnosedatenerfassung auf, bei der es sich beispielsweise um einen Kurzzeitspeicher handeln kann, in dem bestimmte Arten von Daten zusammengetragen und abgespeichert werden, die mit jedem der Funktionsblöcke (bzw. Schatten-Funktionsblöcke) des Prozesssteuersystems 10 im Zusammenhang stehen und bei der Erfassung von Problemen mit diesen Funktionsblöcken herangezogen werden, oder auch mit den mit diesen Funktionsblöcken in Verbindung stehenden Geräten oder Regelkreisen. Die Datenerfassungseinheit 48 kann beispielsweise eine Angabe der Variabilität, eine Angabe des Modus, eine Angabe des Zustands und/oder eine Grenzwertangabe für jeden der Funktionsblöcke innerhalb des Prozess steuernetzwerks 10 erfassen. Bei Bedarf kann die Datenerfassungseinheit 48 in der nachstehend noch zu beschreibenden Art und Weise bestimmte Verarbeitungsvorgänge mit den erfassten Daten ausführen. Die Datenerfassungseinheit 48 sendet die erfassten oder verarbeiteten Daten periodisch über die Ethernet-Verbindung an den Bedienerarbeitsplatz 13 zur Abspeicherung in einem Langzeitspeicher bzw. Protokollführungsspeicher 50 und zur Verwendung durch ein Di agnosewerkzeug 52, das sich zumindest teilweise in dem Bedienerarbeitsplatz 13 befindet. Das Diagnosewerkzeug, das vorzugsweise in Form einer Softwareroutine realisiert ist, die in einem Speicher des Bedienerarbeitsplatzes 13 abgespeichert ist und von einem Rechner 54 des Bedienerarbeitsplatzes 13 ausgeführt wird, erkennt Probleme im Prozesssteuersystem 10, meldet diese Probleme und schlägt Werkzeuge bzw. Hilfsmittel vor, die zur weiteren Analyse und Behebung dieser Probleme zu verwenden sind. Bei Bedarf können Teile des als Diagnosewerkzeugs vorgesehenen Programms innerhalb des Prozessrechners 12 oder auch in den Außengeräten ausgeführt werden.

Das Diagnosewerkzeug 52 erkennt Probleme systematisch, indem es einen oder mehrere Betriebsparameter der Funktionsblöcke bzw. Geräte in dem Prozesssteuersystem heranzieht, zu denen beispielsweise ein Variabilitäts-Parameter, ein Modus- Parameter, ein Zustands-Parameter und ein Grenzwert-Parameter gehören, die jeweils von den entsprechenden Funktionsblöcken oder Geräten in dem Prozesssteuersystem ermittelt werden (oder diesen zugeordnet sind). Eine Angabe des Variabilitäts- Parameters lässt sich für jedes Gerät oder jeden Funktionsblock in dem Prozesssteuersystem berechnen oder anderweitig bestimmen (unabhängig davon, ob diese Funktions blöcke im Prozessrechner 12 angesiedelt oder in einem der Außengeräte 19-22 nachgeschaltet sind), um den Fehler zwischen zwei Parametern des Funktionsblocks anzugeben. Diese beiden Parameter können verschiedene Signale sein, die dem Funktionsblock zugeordnet sind, oder auch zwei verschiedene Messwerte desselben Signals. Beispielsweise kann bei AI- Funktionsblöcken die Angabe der Variabilität den Fehler zwischen einem statistischen Messwert (z. B. Mittelwert, Medianwert, usw.) bei der von einem Fühler über einen vorgegebenen Zeitraum vorgenommenen Messung und dem tatsächlichen bzw. augenblicklichen Wert der Messung angeben. In gleicher Weise kann bei einem AO-Funktionsblock die Variabilitäts-Angabe anhand der Unterschiede zwischen einem historischen statistischen Zustand eines Geräts über einen vorgegebenen Zeitraum (z. B. den Mittelwert des Orts des Ventils bei einer Ventilvorrichtung) und dem aktuellen Zustand des Geräts (z. B. in Form des augenblicklichen Orts des Ventils) bezeichnen. Bei Steuerfunktionsblöcken wie zum Beispiel PID-Funktionsblöcken, Verhältnis-Funktionsblöcken, Funktionsblöcken mit Fuzzy-Logik und dergleichen, kann der Angabe der Variabilität eine Abweichung eines in den Funktionsblock eingegebenen Prozessparameters und einem Sollwert bzw. Zielwert zugrunde liegen, der für diesen Parameter dem Funktionsblock zugeordnet wurde. Bei einem Ausführungsbeispiel kann ein Variabilitäts-Index als integrierter absoluter Fehler (Integrated Absolute Error, IAE) über einen bestimmten Zeitraum ermittelt werden, zum Beispiel während einer Auswertezeit von zehn Minuten. In einem solchen Fall lässt sich der Variabilitäts-Index wie folgt berechnen:

wobei: N = Anzahl der Messungen im Erfassungszeitraum
X(i) = Wert der i-ten Messung des gewünschten Funktionsblock-Parameters wie z. B. der Eingabe wert in den Funktionsblock bei AI-Blöcken und Steuerblöcken; und
S = statistischer oder Soll-Wert des Parameters, mit dem der Funktionsblock-Parameter verglichen wird, z. B. der Sollwert (bei Steuerblöcken), der Durchschnittswert des Funktionsblockparameters über den letzten Erfassungszeitraum (bei AI-Blöcken), usw.

Wenn die Abweichung zwischen den X- und S-Variablen in Gleichung (1) von der Art her eine Gauss'sche Verteilung zeigt, dann ist der IAE-Wert gleich er Standardabweichung, multipliziert mit der Quadratwurzel des Produkts von zwei über π. Natürlich könnte zusätzlich zu oder anstelle der vorstehend beschriebenen IAE-Berechnung auch jede andere Variabilitäts-Angabe herangezogen werden, und damit beschränkt sich die Angabe der Variabilität nicht auf die An gabe nach Gleichung (1).

Vorzugsweise berechnet jeder Funktionsblock automatisch die Variabilitätsangabe über jeden Erfassungszeitraum (z. B. über eine vorgegebene Zeitspanne oder Anzahl von Ausführungszyklen), was ganz besonders für die Blöcke gilt, die sich in den Außengeräten 19-22 befinden, und sendet nach jedem Auswertungszeitraum die berechnete Variabilitätsangabe an die Datenerfassungseinheit 48 in dem Prozessrechner 12 bzw. an die Protokollführungseinheit 50 in dem Bedienerarbeitsplatz 13. Diese Angabe der Abweichung kann beispielsweise der vorstehend genannte Variabilitäts-Index oder einer von dessen Untereinheiten sein, die zur Bestimmung des vorgenannten Variabilitäts-Index herangezogen werden können. Wenn es sich bei den Funktionsblöcken um Fieldbus- Funktionsblöcke handelt, die sich in einem der Außengeräte 19 -22 befinden, dann kann die Variabilitätsangabe an den Prozessrechner 12 mit Hilfe asynchroner Kommunikationsverbindungen übermittelt werden. Während der endgültige Variabilitätsindex für jeden Funktionsblock von dem Prozessrechner 12 oder dem Bedienerarbeitsplatz 13 vollständig berechnet werden könnte, wäre es hierfür erforderlich, dass jeder Funktionsblock nach jedem Ausführungszyklus (im typischen Fall in der Größenordnung von alle 50-100 Millisekunden) Daten an diese Geräte sendet, was eine Menge zusätzlicher Kommunikationsvorgänge über die Busleitungen des Prozesssteuersystems 10 voraussetzte. Um diese zusätzlichen Kommunikationsvorgänge zu vermeiden, sollte jeder Funktionsblock vorzugsweise so ausgelegt werden, dass er hierfür eine Variabilitäts-Angabe berechnet und diese Variabilitätsangabe dann über die Kommunikations-Busleitungen einmal pro Erfassungszeitraum übermittelt, was im typischen Fall in der Größenordnung von einmal in einer Minute, zehn oder mehr Minuten liegt. Derzeit bietet kein bekannter standardmäßiger Funktionsblock diese Möglichkeit und somit sollte diese zusätzlich bei den in dem Prozesssteuersystem 10 verwendeten Funktionsblöcken vorgesehen werden.

Bei einem Ausführungsbeispiel werden die Rechenvorgänge zur Ermittlung eines abschließenden Variabilitäts-Index, der einem Funktionsblock zugeordnet ist, zwischen dem Funktionsblock und dem Diagnosewerkzeug 52 aufgeteilt. Insbesondere werden, da die Berechnung des Variabilitäts- Index Rechenkapazitäten belegt, die meisten Teile dieser Berechnungen, die Rechenzeit benötigen, in dem Bedie nerarbeitsplatz 13 oder in dem Prozessrechner 12 ausgeführt. Bei der vorliegenden Beschreibung wird auf die Berechnungen für einen Variabilitäts-Index bei Eingabe- und Ausgabeblöcke einfach als Variabilitäts-Index (VI) Bezug genommen, während der Variabilitäts-Index bei Steuerfunktionsblöcken als Steuerindex (CI) bezeichnet wird. Der VI-Index (der bei Eingabeblöcken, Ausgabeblöcken und Steuerblöcken im manuellen Betrieb herangezogen wird) und der CI-Index (der bei Steuerblöcken im Automatikbetrieb verwendet wird) können von dem Bedienerarbeitsplatz 13 oder dem Prozessrechner 12 wie folgt berechnet werden:

wobei: S_lq = Mindest-Standardabweichung, die bei Regelung erwartet wird;
S_tot = tatsächlich gemessene Standardabweichung; und
s = Empfindlichkeitsfaktor, der herangezogen wird, um die Berechnungen stabil zu machen.

Dabei kann S_lq wie folgt berechnet werden:

wobei: S_capab = geschätzte Standardabweichung bei der Möglichkeit (Standardabweichung bei idealen Betriebsbedingungen)

Es wird zu den Werten von S_capab und S_tot in Gleichungen (2) und (3) ein kleiner Wert für den systematischen Fehler (Bias) s addiert, da festgestellt wurde, dass wenn, wenn das Verhältnis zwischen Störung und Rauschsignal (d. h. das Verhältnis zwischen der niederfrequenten Störung und der hochfrequenten Störung) zu hoch ist, die Berechnungen von VI und CI zu hohe Werte ergeben. Dieses Problem verschärft sich noch bei rascher Messwerterfassung bei sehr kleinen Differenzen zwischen aufeinanderfolgenden Messungen. Der Bias-Wert s macht, wie sich herausgestellt hat, die Berechnungen stabil. Der empfohlene Bias-Wert s beträgt 0,1% des Messbereichs (in etwa entspricht er also der Messgenauigkeit). Selbstverständlich ist ein Wert von Null bei den Berechnungen von VI bzw. CI nach Gleichungen (2) und (3) der günstigste Fall, während ein Wert von Eins dem ungünstigsten Fall entspricht. Diese oder auch andere Variabilitäts-Indizes könnten so berechnet werden, dass ein Wert von Eins (oder sogar irgendein anderer Wert) den günstigsten Fall wiedergibt.

Bei Bedarf kann für die Steuerblöcke ein Wert für die prozentuale Verbesserung beim 100fachen des CI-Werts für den Steuerblock festgelegt werden.

Zur Vornahme der vorstehenden Berechnungen von VI, CI und PI in einer möglichst effizienten Weise kann jeder Funktionsblock, beispielsweise in einem DeltaV-Umfeld oder einem Fieldbus-Umfeld, die Werte von S_capab und S_tot als Variabilitätsangaben berechnen und diese Werte für den Prozessrechner 12 einsehbar machen, der dann unter Heranziehung der Gleichungen (2) und (3) die Werte von VI und CI berechnen oder die Werte von S_capab und S_tot dem Diagnosewerkzeug 52 im Bedienerarbeitsplatz 13 zur Verfügung stellen kann, wo nun die Werte von VI und CI berechnet werden können. Die zur Ermittlung der Werte von S_capab und S_tot nötigen Zwischenberechnungen werden während jeder Ausführung des Funktionsblocks durchgeführt, und die Werte von S_capab und S_tot werden einmal pro N Durchgängen des Funktionsblocks aktualisiert (d. h. einmal pro Erfassungszeitraum). Bei einer Realisierungsform können die Werte von S_capab und S_tot nach 100 Durchläufen des Funktionsblocks aktualisiert werden.

Die Gesamt-Standardabweichung S_tot lässt sich in dem Funktionsblock unter Heranziehung der sogenannten Berechnungsform mit beweglichem Zeitfenster wie folgt ermitteln:
lässt sich der Variabilitäts-Index wie folgt berechnen:

Stot = 1,25 MAE (5)

wobei MAE den mittleren absoluten Fehler darstellt, der wie folgt berechnet wird:

wobei: N = Anzahl der Durchläufe während eines Erfas sungszeitraums
y(t) = Wert des t-ten augenblicklichen Messwertes des gewünschten Funktionsblock-Parameters wie z. B. der Eingabewert in den Funktionsblock; und
Y_st = statistischer oder Soll-Wert des Parameters, mit dem der Funktionsblock- Parameter verglichen wird, z. B. der Durchschnittswert oder mittlere Wert des Funktionsblock-Parameters während des letzten Bewertungszeitraums.

Ganz allgemein wird bei den E/A-Blöcken der Betriebswert (PV) des Funktionsblocks zur Berechnung von y_st herangezogen. Bei den Steuerblöcken wird je nach Modus des Blocks entweder der Betriebs-Sollwert oder der Ist-Wert (Betriebswert) (PV) als y_st verwendet.

Die Standardabweichung der Möglichkeit, Scapab lässt sich dann wie folgt berechnen:

wobei MR der durchschnittliche Bewegungsbereich ist, der sich wie folgt rechnerisch ermitteln lässt:

Zur Verringerung des Rechenaufwands wird während jedes Ausführungszyklus des Funktionsblocks nur die MAE und MR zugeordnete Summierungskomponente durchgeführt. Die Division der Summe durch N oder N-1 lässt sich als Teil der Berechnungen von S_tot und S_capab einmal pro N Ausführungsgängen (d. h. einmal pro Bewertungszeitraum) vornehmen. Aus der vorstehenden Formel ergibt sich eindeutig, dass:

wobei es sich bei Error_abs und Delta_abs jeweils um die Summierungen in Gleichungen (6) und (8) handelt und diese laufend während jedes Ausführungszyklus des Funktionsblocks berechnet werden.

Die Qualität der Eingabe in den bei diesen Berechnungen verwendeten Funktionsblock spielt natürlich eine große Rolle und deshalb ist es wünschenswert, dass nur Daten herangezogen werden, die in gutem Zustand sind, sowie Daten, die keinen Einschränkungen unterliegen. Bei Einsatz von Fieldbus- oder DeltaV-Funktionsblöcken werden bei der Modus-Variablen der Zustand der Variablen PV, des Sollwerts und der Rück- Kalibrierung berücksichtigt, und damit kann die Modus- Variable dazu herangezogen werden, die korrekten Berechnungen für den Variabilitäts-Index sicherzustellen. Beispielsweise werden im OOS-Modus (Out-of-Service, außer Betrieb) die Variablen S_tot und S_capab nicht ermittelt, sondern werden statt dessen auf den dem günstigsten Fall entsprechenden Wert gesetzt (z. B. Null), um so die Feststellung eines Fehlers zu verhindern. Bei Warmstart, wenn sich die Betriebsart von OOS zu irgendeiner anderen Betriebsart ändert, können die Variablen S_tot und S_capab auf Null gesetzt werden (den Wert entsprechend dem günstigsten Fall), kann der Erfassungszähler rückgesetzt werden und können die Variablen Error_abs und Delta_abs in Gleichungen (9) und (10) auf Null gesetzt werden. Außerdem sollten die vorherigen Werte von y und y_st rückgesetzt werden.

Fig. 3 zeigt einen Funktionsblock 55 mit einem Eingang 56, einem Ausgang 57 und einem mit dem Eingang 56 verbundenen Generator 58 zur Erzeugung von Variabilitäts-Angaben. Bei Bedarf kann der Generator 58 für Variabilitäts-Angaben zusätzlich oder alternativ mit dem Ausgang 57 und/oder anderen Teilen des Funktionsblocks 55 verbunden werden, um weitere Funktionsblock-Parameter oder Signale zu übernehmen (dabei sind diese Verbindungen durch punktierte Linien in Fig. 3 dargestellt). Wenn der Funktionsblock 55 beispielsweise ein Steuerfunktionsblock ist, übernimmt der Rechner 58 zur Berechnung des Variabilitäts-Index den Eingangswert 56 (wobei es sich um den Betriebswert handeln kann, der gerade von dem Regelkreis gesteuert wird, in dem der Steuerblock 55 arbeitet) und vergleicht diesen Eingangswert mit einem Sollwert, der dem Funktionsblock 55 zuvor zugeführt wurde. Der Generator 58 zur Erzeugung der Variabilitäts-Angabe kann den Variabilitäts-Index nach Gleichung (1) ermitteln und diesen Index einem Kommunikator 59 übermitteln, welcher die Variabilitäts-Angabe bei jeder Erfassungsperiode (nach jeweils N Messwerten) an den Prozessrechner 12 übermittelt. Wie vorstehend bereits erläutert wurde, kann jedoch der Generator 58 zur Erzeugung der Variabilitäts-Angabe die Werte S_tot und S_capab in der vorstehend erläuterten Weise ermitteln und diese Werte dann an den Prozessrechner 12 oder den Bedienerarbeitsplatz 13 senden, die nun die Werte von VI und/oder CI daraus berechnen können. Wenn es sich bei dem Funktionsblock 55 um einen gerade im Prozessrechner 12 ausgeführten Funktionsblock handelt, könnte der Prozessrechner eine separate Routine einbeziehen, um die Variabilitäts-Angabe für jeden Funktionsblock zu ermitteln, da nach jedem Erfassungsinter vall keine Kommunikation über Busleitungen stattfinden müsste. Der Kommunikator 59 kann eine beliebige standardmäßige Kommunikationseinheit sein, die einem Funktionsblock oder einem Kommunikationsprotokoll zugeordnet ist.

Ein zweiter Betriebsparameter für einen Funktionsblock, der dazu herangezogen werden kann, Probleme innerhalb des Prozesssteuersystems 10 zu ermitteln, ist eine Angabe der Betriebsart, in welcher jeder der Funktionsblöcke (bzw. Regelkreise oder Geräte) arbeitet. Im Fall von Fieldbus- Funktionsblöcken sowie einigen anderen bekannten Funktionsblöcken besitzt jeder Funktionsblock einen Modus- Parameter, der dem Prozessrechner als Hinweis darauf zur Verfügung steht, in welcher Betriebsart der Funktionsblock gerade arbeitet. Aus dieser Modus-Angabe kann ein Datenanalysierer innerhalb des Diagnosewerkzeugs 52 einen Wert des Modus-Parameters als Angabe dafür ermitteln, ob der Funktionsblock (und damit der Regelkreis, das Modul oder Gerät) in seinem gewünschten und geplanten Modus arbeitet oder alternativ, ob etwas eingetreten ist, wodurch der Funktionsblock (das Gerät oder der Regelkreis) veranlasst wurde, in einem anderen, weniger bevorzugten Modus arbeitet. Fieldbus-Funktionsblöcke arbeiten in einer von vielen Betriebsarten. Beispielsweise arbeiten AI-Funktionsblöcke in einem OOS-Modus (außer Betrieb; wobei ein Bediener gegebenenfalls das Gerät außer Betrieb gesetzt hat, um Wartungsarbeiten vorzunehmen), einem manuellen Modus, bei dem irgendein Signal, zum Beispiel ein Ausgangssignal des Funktionsblocks, gerade von Hand gesetzt wird, statt anhand der geplanten Betriebsweise des Funktionsblocks, und einem Automatikmodus, in dem der Funktionsblock in normaler Weise arbeitet, d. h. in der Weise, die für seinen Betrieb vorgesehen ist. Fieldbus-Steuerblöcke können ebenfalls eine oder mehrere Betriebsarten in Kaskade enthalten, wobei die Betriebsart durch andere Funktionsblöcke oder durch einen Bediener gesteuert wird. Im typischen Fall besitzen Fieldbus- Funktionsblöcke drei Modus-Variablen, die ihnen zu einem gegebenen Zeitpunkt zugeordnet werden, darunter ein Soll- Modus, der die Betriebsart darstellt, in welche der Bediener den Block versetzt hat (und der eine andere Betriebsart als Normalbetrieb oder Automatikbetrieb sein kann), sowie ein aktueller Modus, welcher der Betriebsart entspricht, in welcher der Steuerblock zu einem gegebenen Zeitpunkt gerade arbeitet, und ein Normalmodus, also die Betriebsart, in welcher der Funktionsblock arbeiten soll und die mit dem Normalbetrieb des Funktionsblocks verknüpft ist. Diese oder andere Modus-Angaben können je nach Bedarf verwendet werden.

Die Modus-Angabe kann dem Prozessrechner 12 und/oder dem Bedienerarbeitsplatz 13 periodisch zugeleitet werden. Befindet sich der Funktionsblock innerhalb des Prozessrechners 12, so kann die Modus-Angabe für jeden Funktionsblock zu jedem gewünschten Zeitpunkt oder nach jedem beliebigen Intervall der Datenerfassungseinheit 48 zugeleitet werden. Bei Fieldbus-Funktionsblöcken oder weiteren Funktionsblöcken innerhalb der Außengeräte kann der Prozessrechner periodisch die Modus-Parameter für jeden Funktionsblock unter Zuhilfenahme einer ViewList-Anforderung (im Fieldbus-Protokoll) anfordern. Bei Bedarf kann die Datenerfassungseinheit 48 im Prozessrechner 12 den Modus bei jeder Erfassungsperiode bzw. Auswertungsperiode abspeichern und die gespeicherten Daten der Protokollführungseinheit 50 zur Verfügung stellen. Anschließend kann das Diagnosewerkzeug 52 Modus-Werte ermitteln, die angeben, wann oder wie lange der Funktionsblock in verschiedenen Betriebsarten oder im Normalmodus (bzw. abnormalen Modus) geblieben ist, oder wie hoch der Prozentsatz einer speziellen zeitlichen Periode ist, in welcher sich der Funktionsblock im Normalbetrieb (oder abnormalen Modus) befunden hat. Alternativ könnte die Datenerfassungseinheit 48 oder irgendeine andere speziell dafür konzipierte Einheit im Prozessrechner 12 erfassen, wann sich jeder Funktionsblock außerhalb seines Normalbetriebs befindet (beispielsweise indem der Normalmodus des Funktionsblocks mit dessen tatsächlicher Betriebsart zu einem beliebigen gegebenen Zeitpunkt verglichen wird). In diesem Fall könnte die Datenerfassungseinheit 48 die Betriebsart eines beliebigen Funktionsblocks dadurch mitteilen, dass angegeben wird, wann Änderungen in der Betriebsart stattgefunden haben oder erfasst werden, wodurch der Umfang der zwischen dem Prozessrechner 12 und dem Bedienerarbeitsplatz 13 nötigen Kommunikation verringert wird.

Ein Zustandsparameter ist ein weiterer Betriebsparameter für einen Funktionsblock, der gegebenenfalls zur Erfassung von Problemen in Prozesssteuergeräten und Regelkreisen verwendet wird. Eine Zustands-Angabe, die von jedem Funktionsblock geliefert wird, kann den Zustand des mit dem Funktionsblock bzw. Gerät verbundenen Primärwertes (PV) definieren oder identifizieren. Zusätzlich oder alternativ kann einem oder mehreren Eingangs- und Ausgangs-Informationen eines Funktionsblocks eine Zustandsangabe zugeordnet sein. Fieldbus-Funktionsblöcke besitzen einen ihnen zugeordneten Zustands-Parameter, der die Form "gut", "inakzeptabel" oder "ungewiss" annehmen und so den Zustand des PV-Werts, der Eingangs- und/oder Ausgangs-Informationen des Funktionsblocks angeben kann. Eine Zustandsangabe kann auch eine Begrenzungsangabe identifizieren oder beinhalten, wie zum Beispiel die Grenzwerte, die dem PV oder einem anderen Parameter des Funktionsblocks zugeordnet sind. So kann beispielsweise die Grenzwert-Angabe angeben, ob der PV des Funktionsblocks nach oben oder nach unten begrenzt ist. Auch hier kann das Diagnosewerkzeug 52 Zustands- oder Grenzwert- Werte ermitteln, die angeben, wann, wie lange oder zu welchem Prozentsatz eines speziellen Zeitraumes der Status des Funktionsblocks sich im Normalbetrieb (bzw. abnormalen Betrieb) befand und wann, wie lange oder zu welchem Prozentsatz eines speziellen Zeitraums eine Funktionsblock- Variable sich an einem oder mehreren Grenzwerten befand (oder auch nicht an einem oder mehreren Grenzwerten), oder ob ein inakzeptabler Status oder fraglicher Zustand vorliegt.

In ähnlicher Weise wie die Modus-Angabe können die Zustands- Angabe und die Begrenzungs-Angabe periodisch oder auf Anforderung (wozu beispielsweise der ViewList-Befehl im Fieldbus-Protokoll verwendet wird) von jedem Funktionsblock an den Prozessrechner geschickt werden, und dieser kann dann eventuelle Veränderungen feststellen und an den Bedienerarbeitsplatz 13 übermitteln. Alternativ können die Zustands- und Begrenzungs-Angaben auch ohne Verarbeitung an den Bedienerarbeitsplatz 13 übermittelt werden. Bei Bedarf können die Funktionsblöcke so eingerichtet werden, dass sie Modus-, Zustands- und/oder Begrenzungs-Angaben nur dann übermittelt werden, wenn tatsächlich Änderungen in diesen Parametern aufgetreten sind, wodurch der Umfang der Kommunikationsvorgänge zwischen dem Prozessrechner 12 und den Funktionsblöcken innerhalb der Außengeräte noch weiter verringert wird. Wenn aber bei Verwendung dieses Kom munikationssystems der aktuelle Zustand aller erforderlichen Parameter benötigt wird, um eine Basis zu bilden, mit welcher die Änderungen verglichen werden, wenn das Diagnosewerkzeug 52 zum ersten Mal aufgerufen wird. Dieser aktuelle Zustand kann gemessen oder dadurch erfasst werden, dass man den Prozessrechner 12 periodisch Parameterwerte melden lässt (auch wenn sie sich nicht verändert haben) oder dass man das Diagnosewerkzeug 52 den Prozessrechner 12 zum Melden von Parametern veranlassen lässt, die für Ausnahmemeldungen definiert sind. Anhand des Zustands jedes einzelnen Funktionsblocks kann das Diagnosewerkzeug 52 rasch Messungen identifizieren, die inakzeptabel sind und nachgesehen werden müssen (ungewisser Zustand) oder die wegen einer Begrenzung eines Messwertes oder eines PV-Wertes unkorrekt kalibriert wurden. Die Angaben zum Zustand und zur Begrenzung können natürlich einen von unterschiedlich vielen verschiedenen Werten annehmen, je nach Art des Systems, in dem sie gerade verwendet werden.

Außerdem kann für beliebige verschiedene Variablen (außer PV) eines Funktionsblocks, eines Geräts oder eines Regelkreises eine Zustandsangabe verwendet werden. Beispielsweise kann in einem Regelkreis mit Rückmeldung der Zustand der Regelvariablen zur Erfassung von Problemen innerhalb von Funktionsblöcken und Regelkreisen verwendet werden. Der Zustand dieser Regelvariablen (z. B. die Rück-Kalibrierungs- bzw. BackCal-Variable für Steuer- bzw. Steller- Funktionsblöcke beim Fieldbus-Protokoll) oder jeder anderen Variablen kann von dem Diagnosewerkzeug 52 geprüft werden, um festzustellen, wann ein Funktionsblock einen Ausgang aufweist, der beispielsweise durch einen nachgeschalteten Funktionsblock oder eine andere nachfolgende Bedingung begrenzt wird. In ähnlicher Weise wie bei der Modus-Angabe kann der aktuelle Zustandswerte erfassen und abspeichern oder gegebenenfalls Veränderungen bei den Zustandswerten als Zustands-Angabe abspeichern.

Weitere Daten, die einem Prozesssteuer-Funktionsblock, einem Gerät oder einem Regelkreis zugeordnet sind, können ebenfalls zur Erfassung von Problemen verwendet werden. Beispielsweise kann der Bedienerarbeitsplatz 13 (bzw. der Prozessrechner 12) Ereignisse und Alarmmeldungen, die von den Geräten oder Funktionsblöcken innerhalb des Prozesssteuer-Netzwerks 10 erzeugt werden, übernehmen, abspeichern und überprüfen. In einem Fieldbus-Umfeld unterstützen beispielsweise Funktionsblöcke einen Blockfehler-Parameter, der Störungen in den Verarbeitungsbedingungen meldet, die von einem Messumformer oder einem Funktionsblock erfasst werden. Fieldbus-Geräte geben jedes Problem wieder, das von dem Gerät oder Funktionsblock unter Heranziehung von einem von 16 definierten Bits in einem Blockfehler-Datenstrom erfasst wird, der zu dem Prozessrechner 12 fließt. Fieldbus-Geräte melden dem Prozessrechner 12 das erste erfasste Problem als Ereignis oder Alarm, und diese Ereignisse bzw. Alarmmeldungen können dann vom Prozessrechner 12 an ein Ereignisjournal im Bedienerarbeitsplatz 14 weitergeleitet werden. Bei einem Ausführungsbeispiel analysiert bzw. überprüft das Diag nosewerkzeug 52 das sechste Bit des Blockfehler-Parameters (im Fieldbus-Protokoll), um festzustellen, wann bei einem Gerät in naher Zukunft Wartungsarbeiten erforderlich sind, und damit wann eine Bedingung vorliegt, die adressiert werden muss, die aber zum aktuellen Zeitpunkt die Funktion des Geräts nicht einschränkt. In ähnlicher Weise analysiert das Diagnosewerkzeug 52 das dreizehnte Bit des Blockfehler- Parameters (im Fieldbus-Protokoll), um festzustellen, wenn ein fehlerfreier Gerätebetrieb wegen eines vom Gerät erfassten Zustands nicht möglich ist und damit sofort Maßnahmen ergriffen werden müssen. Natürlich können auch andere Ereignisse, Alarmmeldungen, weitere Bits im Rahmen des Blockfehler-Parameters oder Fehlermeldungen anderer Art vom Diagnosewerkzeug 52 herangezogen werden können, um Probleme zu erfassen, die mit dem Betrieb des Prozesssteuer-Netzwerks 10 zusammenhängen, und solche anderen Ereignisse, Alarmmeldungen, usw. können mit dem Fieldbus-Protokoll oder jedem anderen gewünschten Gerät oder Rechnerprotokoll in Ver bindung gebracht werden.

In einigen Fällen können Funktionsblöcke Parameter aufweisen, wie beispielsweise Modus- oder Status-Parameter, die auf andere Werte als Normalbetrieb oder "akzeptabel" aus Gründen gesetzt sind, die nicht mit dem korrekten Ablauf des Prozessablaufs bzw. des Regelkreises in Beziehung stehen, in denen diese Funktionsblöcke arbeiten. Beispielsweise sind bei Abläufen im Stapelbetrieb, bei denen nicht gerade ein Stapel bearbeitet wird, die Betriebsarten der im Rahmen dieses Betriebsablaufs eingeschalteten Funktionsblöcke auf andere als Normalwerte gesetzt. Es wäre jedoch nicht wünschenswert, diese Meldungen über einen abnormalen Modus (bzw. Betriebs zustand) zu erfassen und auf deren Grundlage Probleme mit dem System zu identifizieren, weil der Arbeitsablauf mit Stapelbetrieb so ausgelegt ist, dass es Auszeiten gibt. Deshalb wird vorzugsweise jeder Funktionsblock (bzw. Modul oder Regelkreis, in dem er abläuft) mit einem Parameter für den Anwendungszustand versehen, der anzeigt, ob der Funktionsblock (bzw. das Modul) absichtlich in einen abnormalen Modus versetzt ist oder einen inakzeptablen Zustand aufweist. Mit anderen Worten zeigt der Parameter für den Anwendungszustand an, wann Alarmmeldungen oder die Problemerfassung für den Funktionsblock verhindert werden sollte. Bei Funktionsblöcken, die in Arbeitsgängen im Stapelbetrieb eingesetzt werden, ist beispielsweise der Parameter für den Anwendungszustand auf einen solchen Wert gesetzt, dass er meldet, wenn die Funktionsblöcke in einer Betriebsart arbeiten, in der sie eine Anwendung im Stapelbe trieb ablaufen lassen, und auf einen anderen Wert gesetzt wird, bei dem er meldet, wenn die Funktionsblöcke absichtlich gerade nicht eingesetzt werden, um im Rahmen einer Anwendung mit Stapelbetrieb eine normale Funktion auszuführen, und somit sollte eine Problemerfassung nicht auf dem Betriebszustand dieser Funktionsblöcke zu diesen Zeitpunkten aufbauen. In Fig. 3 ist ein derartiger Anwendungsparameter dargestellt, der über den Kommunikator 59 dem Prozessrechner 12 mitgeteilt werden soll. Der Prozessrechner 12 und/oder der Bedienerarbeitsplatz 13 erfasst gegebenenfalls den Parameter für den Anwendungszustand für jeden Funktionsblock und übergeht Daten (wie beispielsweise die Daten über Variabilität, Modus, Zustand und Beschränkungen), die Funktionsblöcken zugeordnet sind, die in die zweite Kategorie fallen, die beispielsweise absichtlich in einen abnormalen oder inakzeptablen Zustand versetzt sind, um Fehlalarm zu verhindern. Es gibt natürlich auch andere Gründe dafür, dass der Parameter für den Anwendungszustand gegebenenfalls gesetzt wird, um die Erfassung von Problemen neben der mit Stapelprozessen verknüpften Auszeit zu verhindern.

Das Diagnosewerkzeug 52 ist vorzugsweise in Programmform als Software in dem Bedienerarbeitsplatz 14 realisiert, und bei Bedarf können einige Teile im Prozessrechner 12 und sogar in den nachgeschalteten Außengeräten wie beispielsweise den Außengeräten 19-22 implementiert sein. Fig. 4 zeigt ein Blockschaltbild einer Softwareroutine 60, die in dem Bedienerarbeitsplatz 14 ausgeführt werden kann, um Problemstellen in Funktionsblöcken, Geräten, Regelkreisen oder anderen Einheiten innerhalb des Prozesssteuersystems 10 zu erkennen und bei deren Behebung Unterstützung zu geben. Ganz allgemein erfasst die Softwareroutine 60 laufend Daten, die zu jedem der Funktionsblöcke innerhalb eines Prozesses gehören, wie beispielsweise eine Variabilitäts-Angabe, Modus- Angabe, Zustands-Angabe, Grenzwert-Angabe, Alarmmeldungen oder Informationen über Ereignisse, usw., während der Prozess abläuft, und erfasst dabei das Vorliegen von problematischen Messwerten, Berechnungen, Regelkreisen, usw. anhand der erfassten Daten. Die Softwareroutine 60 schickt gegebenenfalls einen Bericht oder erstellt eine Bild schirmauflistung für jedes erfasste Problem und dessen wirtschaftliche Auswirkungen auf den Anlagenbetrieb, wenn dies von der Konfiguration her vorgesehen und eine derartige Meldung angefordert ist. Bei Betrachtung einer Bildschirmdarstellung der erfassten problembehafteten Regelkreise z. B. auf dem Bildschirm 14 des Be dienerarbeitsplatzes 13 kann ein Bediener ein spezielles Problem zur Überprüfung oder Fehlerbehebung auswählen. Dann schlägt ihm die Softwareroutine 60 weitere Diagnosewerkzeuge vor und implementiert diese gegebenenfalls, um das Problem weiter einzukreisen oder um es zu beheben. Auf diese Weise verarbeitet das Diagnosewerkzeug 52 Daten, die von den Funktionsblöcken oder Geräten eines Prozesssteuersystems erzeugt werden, erkennt Probleme automatisch anhand der Daten, und schlägt dann weitere Diagnosewerkzeuge vor und setzt diese ein, um die Problemursache noch weiter einzukrei sen und um das Problem zu beheben. Damit wird dem Bediener erheblich Zeit und Mühe bei der Erfassung und Behebung von Problemen in einem Prozesssteuersystem erspart und er wird auch in seinem Bemühen unterstützt, den Einsatz der passenden Diagnosewerkzeuge zur Behebung eines bestimmten Problems sicherzustellen (mit denen der Bediener selbst unter Umständen nicht vollständig vertraut ist).

Ein Block 62 der Routine 60 übernimmt laufend die Daten zu Variabilität, Modus, Zustand, Beschränkungen, Alarmmeldungen, Ereignissen und weiteren Aspekten, die zur Erfassung von Problemen in Geräten, Blöcken und Regelschleifen des Prozesssteuersystems 10, also sobald der Prozess abläuft. Vorzugsweise werden diese Daten in der Protokolleinheit 50 in dem Bedienerarbeitsplatz 13 abgespeichert. Alternativ könnten jedoch diese Daten auch in jedem anderen gewünschten Speicher abgelegt werden, zum Beispiel einem Speicher, der dem Prozessrechner 12 zugeordnet ist. In gleicher Weise können diese Daten in jedem beliebigen Format an den Bedie nerarbeitsplatz 13 bei Bedarf auch in komprimierter Form übermittelt werden.

Ein Block 63 erfasst bzw. ermittelt, wann eine Analyse der Daten vorgenommen werden muss, weil beispielsweise eine periodische Meldung erstellt werden muss oder ein Benutzer eine solche Analyse angefordert hat. Soll keine Analyse vorgenommen werden, dann arbeitet der Block 62 einfach mit der Datenerfassung weiter und verarbeitet gegebenenfalls diese Daten, um Werte für die Betriebsparameter eines Funktionsblocks zu ermitteln. Soll eine Analyse erfolgen, analysiert ein Block 64 die gespeicherten Daten bzw. die gespeicherten Parameterwerte, um festzustellen, in welchen Funktionsblöcken, Geräten oder Regelkreisen unter Umständen gerade Probleme vorliegen. Ganz allgemein können die Daten anhand der aktuellen bzw. augenblicklichen Werte der Betriebsparameter des Funktionsblocks analysiert werden, oder auch auf der Grundlage der Vorgeschichte, um festzustellen, welche Funktionsblöcke, Geräte oder Regelkreise gerade über einen speziellen Zeitraum hinweg Probleme aufweisen. Die Analyse der Vorgeschichte hilft bei der Erfassung von Problemen, die von ihrer Art her langfristig sind, anhand der Leistung über einen vorgegebenen Zeitraum. Zur Erfassung eines Problems kann der Block 64 bei Bedarf einen Variabilitäts-Index auf der Grundlage der Variabilitäts- Angaben berechnen, die von den Funktionsblöcken zugeliefert werden, und dann den Variabilitäts-Index mit einem speziellen Bereich oder einen Grenzwert vergleichen (den der Bediener gegebenenfalls gesetzt hat), um zu ermitteln, ob der augenblickliche Wert oder irgendein statistischer Messwert des historischen Wertes (zum Beispiel des Durchschnitts- oder Medianwertes) für den Variabilitäts-Index außerhalb des Be reichs oder über bzw. unter dem für einen Grenzwert vorgegebenen Grenzwert liegt. Ist dies der Fall, liegt gegebenenfalls ein Problem vor, und dann wird der betreffende Funktionsblock, das Gerät oder der Regelkreis, zu dem der Variabilitäts-Index außerhalb des Bereichs gehört, als Einheit aufgelistet, in der ein zu behebendes Problem vorliegt.

In gleicher Weise kann der Block 64 den aktuellen Modus eines Funktionsblocks oder Geräts mit dem normalen Modus dieses Funktionsblocks oder Geräts vergleichen, um Übereinstimmung festzustellen. Wie zuvor bereits dargelegt, kann der Prozessrechner 12 diese Funktion ausführen und Angaben zum Ergebnis bzw. zur Nicht-Übereinstimmung an die Protokollierungseinheit 50 senden. Bei Bedarf kann jedoch auch der Bedienerarbeitsplatz 13 diese Vergleiche direkt vornehmen. Unter Verwendung der Daten zur Vorgeschichte kann der Block 64 den Einsatz von Regelkreisen ermitteln, d. h. den prozentualen Anteil der Zeit, während der ein Regelkreis (bzw. Funktionsblock) im vorgesehenen (normalen) Betrieb befand. Bei der augenblicklichen Analyse kann der Funktionsblock, der Regelkreis oder das Gerät als problembehaftet angesehen werden, wenn es zur Zeit nicht im vorgesehenen oder normalen Modus arbeitet.

In gleicher Weise kann der Block 64 auch die Meldung(en) zu Zustand und Begrenzungen für jeden Funktionsblock analysieren, um festzustellen, wenn der Zustand inakzeptabel oder ungewiss ist oder in anderer Hinsicht nicht als vorgesehener oder normaler Modus gilt oder wenn ein Funktionsblocksignal eine Grenze erreicht hat. Bei einer Analyse der Vorgeschichte wird gegebenenfalls berechnet oder bestimmt, ob die Zustandsanzeige für einen bestimmten Funktionsblock für einen bestimmten prozentualen Anteil eines vorgegebenen Zeitraumes auf einen inakzeptablen oder ungewissen Zustand hinweist, wird unter Umständen ermittelt, welche PVs oder anderen Variablen einen Grenzwert erreicht haben oder über einen vorgegebenen prozentualen Anteil an einem vorgegebenen Zeitraum an einer Grenze geblieben sind, und wird gegebenenfalls die Zustandsangabe oder Begrenzungsangabe in irgendeiner anderen Weise analysiert, um festzustellen, ob in dem Funktionsblock oder Gerät bzw. dem Regelkreis, in dem sich ein Funktionsblock befindet, ein Problem vorliegt. In gleicher Weise kann der Block 64 bei einer augenblicklichen Auswertung feststellen, welche Funktionsblöcke, Geräte oder Regelkreise Zustandswerte aufweisen, die sich zum gegenwärtigen Zeitpunkt nicht im planmäßigen oder normalen Zustand befinden und/oder welche Signale oder Variablen einen Grenzwert erreicht haben (also einer Wertebeschränkung unterliegen). Der Block 64 kann die Alarm- und Ereignismeldungen überprüfen, um festzustellen, ob an irgendwelchen Geräten Wartungsarbeiten jetzt oder in Zukunft nötig sind. Die Blöcke, bei denen die Grenzwerte hinsichtlich der Variabilität oder des Steuerindex überschritten werden, und die Blöcke, bei denen eine aktive inakzeptable, begrenzt oder Modusbedingung vorliegt, werden identifiziert und zeitweilig sichergestellt. Diese zusammenfassenden Informationen können Unterstützung bei der Erstellung einer "aktuellen" summarischen Bildschirmanzeige bieten. Die augenblicklichen Werte und Bedingungen können von dem Diagnosewerkzeug 52 beispielsweise stunden-, schicht- und tageweise einbezogen werden, um den Durchschnittswert für den Variabilitätsindex und die prozentuale Verbesserung und den prozentualen Zeitanteil zu ermitteln, über den der inakzep table Zustand, ein begrenztes Signal oder eine abnormale Betriebsbedingung vorlag. Der Block 64 kann natürlich auch eine Verarbeitung in anderer Weise zur Variabilität, zum Betriebszustand, dem Status, den Begrenzungen, zu Ereignissen, Alarmmeldungen und/oder allen anderen Aspekten ausführen, um Probleme zu erfassen. Außerdem kann der Block 64 unter Heranziehung verschiedener Grenzwerte, Bereiche, historischer Zeiten usw. die Analyse ablaufen lassen, die alle gegebenenfalls von einem Benutzer oder Bediener vorgege ben wurden.

Bei Funktionsblöcken, die beispielsweise bei Prozessen im Stapelbetrieb eingesetzt sind, werden Daten im Zusammenhang mit Zeiten, zu denen ein Funktionsblock absichtlich nicht in Betrieb war, verworfen oder bei der Analyse nicht herangezogen, die anhand des Parameters zum Anwendungszustand für den Funktionsblock vorgenommen wird.

Nachdem der Block 64 die Probleme im Prozesssteuer-Netzwerk erfasst hat, ermittelt ein Block 66, ob irgendwelche schriftlichen oder elektronischen Meldungen generiert werden müssten, beispielsweise weil ein Benutzer in regelmäßigen Zeitabständen Berichte angefordert hat. Trifft dies zu, erstellt ein Block 68 eine Meldung bzw. einen Bericht, in dem die problembehafteten Funktionsblöcke, Geräte, Regelkreise usw. zusammen mit ihren wirtschaftlichen Auswirkungen auf das Prozesssteuersystem aufgelistet werden. Eine wirtschaftliche Beeinträchtigung in dieser Art lässt sich dadurch ermitteln, dass das System einen Bediener oder einen anderen Benutzer den Dollarbetrag angeben lässt, der mit jedem Prozentpunkt der Betriebseinschränkung bei dem Prozess oder in einem Regelkreis im Prozess verknüpft ist. Wenn dann ein Regelkreis als problembehaftet erkannt wird, kann die tatsächliche Leistung der jeweiligen Wirkungskette im Prozess mit einem bekannten optimalen Leistungswert verglichen werden, um den prozentualen Unterschied festzustellen. Dieser prozentuale Unterschied wird dann mit dem angegebenen Verhältnis zwischen Dollarbetrag und Prozentpunkt multipliziert, um die wirtschaftliche Auswirkung in einem Geldbetrag auszudrücken. Der Bericht kann auf einem Drucker ausgedruckt, auf einem Computerbildschirm (z. B. dem Bildschirm 14) oder auf andere Weise elektronisch angezeigt werden, über E-Mail, Internet oder ein anderes LAN- oder anderweitiges Netzwerk an einen Benutzer übermittelt oder auch in jeder anderen beliebigen Weise an diesen gesandt werden. Bei Bedarf kann das Diagnosewerkzeug 52 so konfiguriert werden, dass es einen werkseigenen Wartungsdienst automatisch benachrichtigt, sobald ein problembehafteter Regelkreis entdeckt wurde; diese Benachrichtigung kann dem Wartungsdienst unter Nutzung der Möglichkeit zur Ereignis-/Alarmmeldung der bekannten OPC- Schnittstelle zugeleitet werden.

Ein Block 70 ermittelt, ob ein Bediener die Durchführung einer Analyse am Bedienerarbeitsplatz 13 angefordert hat; ist dies der Fall, ruft ein Block 72 eine Routine zur Bildschirmanzeige oder für einen Dialog auf, mit welcher ein Benutzer die Möglichkeit hat, andere Informationen im Zusammenhang mit dem Problem zu finden oder andere Parameter zur Durchführung der Analyse auszuwählen. Bei einem Ausführungsbeispiel wird einem Bediener oder einer anderen Person, die mit dem Diagnosewerkzeug 52 arbeitet, ein Dialog angeboten, wenn auf den Arbeitsplatz 13 eingeloggt wird. In dem Dialog werden die Bedingungen zusammengefasst, die in dem System adressiert werden müssen, ohne dass die Wirkungsketten und Regelkreise identifiziert werden, welche die Ursache für das Problem sind. In dem Dialog können die Informationen in einem grafischen Format wie beispielsweise auf der Bildschirmanzeige 80 übermittelt werden, die in Fig. 5 dargestellt ist. In der Bildschirmanzeige 80 wird ein prozentualer Überblick über alle Eingangs-, Ausgangs- oder Steuerblöcke in dem Prozess bzw. Werk geboten, bei denen zur Zeit die vorbelegten Grenzwerte verletzt werden, die im Hinblick auf Einsatz (Modus), Signalbegrenzung, inakzeptablen Zustand oder hohe Variabilität gesetzt sind. Da in einem einzigen Block mehrfache Bedingungen gegeben sein können, ist eine potentielle Überschreitung der 100%-Marke durch die Gesamtsumme möglich. Übersteigt die Gesamtsumme 100 Prozent, kann der Prozentanteil für jede Kategorie so skaliert werden, dass die Gesamtzahl gleich 100 Prozent ist. Module mit Eingangs-, Ausgangs- und Steuerblöcken, welche die voreingestellten Grenzwerte überschreiten, sind in einer Liste 82 in Tabellenform zusammengefasst. In Fig. 5 weist das Modul FIC101 einen oder mehrere Funktionsblöcke auf, die jeweils in einem nicht geplanten Modus arbeiten, sowie einen oder mehrere Funktionsblöcke mit hoher Variabilität, wohingegen das Modul LIC345 einen oder mehrere Funktionsblöcke mit inakzeptablem Status aufweist.

Weitere Informationen über die Art der Probleme, wie zum Beispiel die Grenzwerte in Verbindung mit den Funktionsblöcken, können in grafischer Darstellung dargestellt werden, beispielsweise durch Anklicken einer Modulbezeichnung in der Liste 82. Außerdem kann dem Benutzer durch Auswahl einer Filterschaltfläche 84 auf dem Bildschirm in Fig. 5 ein Dialog angeboten werden, mit dem er die Möglichkeit hat, einen summarischen Zeitrahmen, die Arten der in der Zusammenfassung einzubeziehenden Blöcke und den Grenzwert für jede Kategorie bzw. jeden Block auszuwählen. Ein derartiger Dialogbildschirm 86 ist in Fig. 6 dargestellt, wo die Grenzen für Modus, Begrenzung und inakzeptablen Zustand der Eingangsblöcke auf 99 Prozent Nutzung eingestellt und die Grenze für den Variabilitätsindex bei den Eingangsblöcken auf 1,3 gesetzt ist. In diesem Fall wird der Prozentsatz der Nutzung eines Blocks als prozentualer Anteil eines speziellen Zeitraums festgelegt, in welchem der Modus bzw. Zustand normal ist und ein Funktionsblocksignal nicht begrenzt wurde. Die Grenzwerte könnten jedoch auch als prozentualer Anteil an der Zeit gesetzt werden, in welcher der Modus bzw. Zustand abnormal war oder eine Funktionsblock- Variable an einer Grenze lag; in diesem Fall könnten die Grenzwerte näher bei Null gesetzt sein. Natürlich werden durch Auswahl aller Regelkreismöglichkeiten auf dem Bildschirm 86 alle Module in den Überblick einbezogen werden, die einen Eingangs-, Ausgangs- oder Steuerblock enthalten.

Auf dem Bildschirm 86 lässt sich eine Schaltfläche "Zeitraum" 88 verstellen, um die Einstellung so zu ändern, dass der erfasste Zeitraum verändert wird, für den die Analyse vorzunehmen ist. Beispielsweise kann in der Schaltfläche "Zeitraum" 88 "Jetzt" gewählt werden, und dann wird der augenblickliche bzw. aktuelle Wert der Blockparameter zur Bestimmung herangezogen, ob jedes Modul als problembehaftet in der Überblicksliste 82 dargestellt wird. Auch wenn jeder Zeitraum vorgegeben werden kann, werden hier beispielhafte Zeiträume genannt, die zur Filterung verwendet werden können, und zwar laufende Stunde oder vergangene Stunde, laufende Schicht oder letzte Schicht, aktueller Tag oder Vortag, usw. Für diese Zeiträume wird in der Überblicksliste nur dann ein Modul einbezogen, wenn für einen erheblichen Teil (d. h. einen vorgegebenen Anteil) in dem gewählten Zeitraum, der durch die Begrenzungsbedingung definiert ist, ein erfasster Zustand vorhanden ist.

Bei Bedarf kann der Benutzer die für den Variabilitätsindex blockweise oder global herangezogenen Grenzwerte verändern. Um das Setzen von Grenzwerten für die Variabilität zu vereinfachen, kann der Benutzer den zu ändernden gewünschten Grenzwert auswählen, woraufhin ihm die Wahl angeboten wird, entweder diesen Grenzwert für einen bestimmten Block zu bearbeiten oder diesen Grenzwert für alle Blöcke gleichzeitig zu setzen. Wenn der Benutzer die Variabilitäts-Grenze für alle Blöcke zusammen setzen möchte, steht ihm ein Dialogfeld zur Verfügung, mit dem er die Variabilitätsgrenze auf den aktuellen Wert einer Variabilität zuzüglich eines speziellen systematischen Fehlers (Bias) setzen kann, den der Benutzer selbst beiträgt. Die Grenzwerte für die Variabilität, den Modus, den Status und begrenzte Variablen können natürlich bei allen Funktionsblöcken innerhalb eines Moduls, eines Bereichs, eines Systems oder jeder anderen logischen Einheit angewendet und alle in gleicher oder ähnlicher Weise verändert werden. Für eine Konfigurierung können standardmäßig gesetzte Grenzwerte gesetzt sein, beispiels weise 1,3 für den Variabilitäts-Index und 99% Auslastung für den Modus, die Begrenztheitsangabe und die Zustandsangabe.

Diese Standardwerte können natürlich über den vorstehend beschriebenen Bildschirm mit Modulübersicht geändert werden. Durch Auswahl einer Modulbezeichnung in dem Überblick 82 in Fig. 5 kann dem Benutzer ein Dialog-Bildschirm mit weiteren Einzelheiten im Zusammenhang mit dem betreffenden Modul angeboten werden. Ein derartiger Dialog-Bildschirm 90 ist in Fig. 7 für das Modul FIC101 dargestellt, für welches als Zeitraum "Letzte Schicht" gewählt ist. Der Bildschirm 90 zeigt die Leistung eines PID1-Blocks und eines AI1-Blocks innerhalb des Moduls FIC101. Die auf dem Bildschirm 90 vorgesehenen Informationen ermöglichen es dem Benutzer, die spezielle Messung 46648 00070 552 001000280000000200012000285914653700040 0002010007971 00004 46529, den Steller oder Steuerblock problemlos zu identifizieren, die bzw. der die Aufnahme des Moduls in die Übersicht verursacht hat, neben dem prozentualen Zeitanteil, über den die Bedingung erfasst wurde. Insbesondere wird in Fig. 7 der prozentuale Anteil der Zeit während der letzten Schicht als Regelkreis- bzw. Wirkungsketten-Belegung dargestellt, während dessen ein Block sich im Normalbetrieb, im Normalzustand befand und keinen Begrenzungen unterlag. Der Bildschirm gemäß Fig. 7 könnte natürlich auch so ausgelegt werden, dass er den prozentualen Anteil der Zeit während der letzten Schicht darstellt, während dessen sich ein Block im abnormalen Betriebszustand befand oder einen abnormalen Status hatte, oder ebenso den prozentualen Anteil der Zeit während der letzten Schicht, während dessen eine Funktions block-Variable bei mehr als einem Grenzwert lag. Ein Maß für die Schwankungen ist für die in Fig. 7 dargestellten Blöcke zusammen mit den zugeordneten Grenzen angegeben. In diesem Fall ist das Maß der Variabilität so berechnet, dass ein Wert von Eins dem günstigsten Fall entspricht und Werte größer als Eins einen immer stärker ausgeprägten Variabilitätsfehler anzeigen. Wenn die CI- und VI-Berechnungen gemäß Gleichungen (2) und (3) für den Variabilitäts-Index verwendet werden, dann führt dies allerdings zu einem Variabilitäts-Index zwischen Null und Eins, wobei Null dem günstigsten Fall entspricht. In diesem Fall sollte die Variabilitätsgrenze auf einen Wert zwischen Null und Eins gesetzt werden. Außerdem ist in Fig. 7 für Steuerblöcke, nämlich den PID1-Block, die prozentuale Verbesserung (PI) dargestellt, die in einem Regelkreis möglich ist. Bei Bedarf können die Werte für die prozentuale Belegung bzw. Nutzung, die unter den jeweiligen Grenzwert abfallen oder darüber liegen) durch Unterlegen oder anderweitig markiert werden, um auf das bzw. die entdeckte(n) Problem(e) hinzuweisen.

Natürlich kann auch jede andere Bildschirmdarstellung für die Darstellung eines Überblicks verwendet werden, in dem darstellt wird, welche Regelkreise, Geräte, Funktionsblöcke oder Messungen einen hohen Variabilitäts-Index aufweisen (zum Beispiel über einem vom Benutzer vorgegebenen Grenzwert liegen), in einem abnormalen Modus arbeiten oder Prozessmesswerte aufweisen, deren Status als inakzeptabel oder ungewiss gilt oder die Beschränkungen unterliegen. Wie vorstehend ausgeführt, kann bei Heranziehung einer Analyse der Vorgeschichte das Diagnosewerkzeug 52 Bildschirmanzeigen für einen bestimmten Zeitrahmen zur Identifizierung von Geräten, Regelkreisen oder Funktionsblöcken anbieten, deren Variabilitäts-Index, Modus, Status oder Grenzvariablen sich gegenüber dem Normalwert erheblich verändert haben. Das Diagnosewerkzeug 52 kann natürlich einen Benutzer in die Lage versetzen, eine Wahl dahingehend zu treffen, wie viele und welche Prüfungen und Tests einbezogen werden sollen (und negative Ergebnisse erbracht haben müssen), ehe eine Prozesssteuerbedingung als ein Zustand identifiziert wird, der mit einem Problem behaftet ist.

Es wird nun wieder auf Fig. 4 Bezug genommen; wenn ein Benutzer einen der Funktionsblöcke zum Beispiel auf dem Bildschirm 90 gemäß Fig. 7 auswählt, erfasst ein Block 93 die Auswahl des problembehafteten Funktionsblocks und zeigt ein Block 94 einen Satz Optionen an, die zur Behebung des Problems im jeweiligen Block bzw. Regelkreis verwendet werden sollen. Beispielsweise kann bei Steuerblöcken das Diagnosewerkzeug 52 den Benutzer unter Umständen in die Lage versetzen, einen Auto-Tuner oder eine andere Abstimmein richtung zum Abstimmen eines Regelkreises einzusetzen oder für diesen Regelkreis eine Trendanalyse vorzunehmen. Wenn die Option "Auto-Tuner" gewählt ist, findet das Diagnosewerkzeug 52 automatisch die Autotuner-Anwendung für den gewählten Steuerblock bzw. Regelkreis automatisch und lässt diese ablaufen. Wenn aber die Option "Trend" gewählt ist, beginnt der Arbeitsplatz 13 mit der Erfassung von Trenddaten in der nachstehend erläuterten Weise.

Bei Eingangs- oder Ausgangs-Funktionsböcken kann der Block 94 den Benutzer in die Lage versetzen, beispielsweise ein weiteres Diagnosewerkzeug für diesen Block einzusetzen oder eine Trendanalyse vorzunehmen. Wenn beispielsweise der gewählte Eingangs- oder Ausgangsblock in ein Fieldbus- oder Hart-Gerät einbezogen ist, dann aktiviert die Auswahl der Diagnoseoption die Diagnoseanwendung für den zugehörigen Messwandlerblock unter Heranziehung von Hilfsmitteln, die auf diesem Gebiet bekannt sind, wie beispielsweise ein beliebiges Tool zur Gerätekalibrierung. In einem DeltaV-Umfeld kann das von Fisher-Rosemount hergestellte und vertriebene Diagno sewerkzeug für Bestandsverwaltungs-Lösungen (Asset Management Solutions, AMS) zu diesem Zweck verwendet werden, um mit einem Gerät zu kommunizieren, um spezielle Informationen darüber zu erhalten und um eine Diagnose im Zusammenhang mit dem Gerät zu realisieren. Natürlich könnten auch andere Werkzeuge oder Empfehlungen vorgesehen werden. Beispielsweise kann bei Problemen mit Messwertwandlern oder mit diesen zusammenhängenden Funktionsblöcken der Block 94 empfehlen, dass zur Kalibrierung des Messwertwandlers mit einer Gerätekalibrierung gearbeitet wird, wohingegen bei einem Ventil eine beliebige von vielen Routinen zur Ventildiagnose zur Erfassung und möglicherweise Behebung des speziellen Problems im Ventil eingesetzt werden kann. Ganz allgemein gesagt können die Empfehlungen des Blocks 94 anhand der Frage ermittelt werden, ob das Problem unter einen von vielen vorgegebenen Problemtypen fällt, oder entsprechend der Art oder Identität der Problemursache (z. B. ob es seinen Ursprung in einem Steuer- oder Eingangs-Funktionsblock, einem Messwertwandler oder einem Ventil, usw. hat), oder gemäß irgendeinem anderen jeweils gewünschten Kriterium. Dabei können natürlich jedwede Diagnosewerkzeuge eingesetzt werden, darunter die derzeit schon bekannten oder auch die erst in Zukunft entwickelten.

Wenn sich die spezielle Art des Problems nicht einfach anhand der Daten zur Variabilität, zum Status, zum Modus, zu Begrenzungen oder anderen Kriterien erkennen lässt, die auf das Vorhandensein eines Problems hinweisen, kann der Block 94 den Einsatz weiterer, komplexerer Diagnosewerkzeuge wie beispielsweise Kurvenschreiber-Routinen, Korrelations- Routinen (z. B. Auto-Korrelation und Quer-Korrelation), Routinen für eine Spektralanalyse, Routinen für eine Expertenanalyse oder jeder anderen gewünschten Routine oder auch von Werkzeugen empfehlen, die für das Prozesssteuersystem 10 vorgesehen sind. Das Diagnosewerkzeug 52 kann natürlich den Einsatz von mehreren Werkzeugen empfehlen oder anregen und dem Bediener die Wahl des jeweiligen Werkzeugs einräumen, das in irgendeiner Situation einzusetzen ist. Darüber hinaus kann der Block 94 seine Anregungen zu Werkzeugen einschränken, die innerhalb des Prozesssteuer-Netzwerks 10 tatsächlich verfügbar sind, z. B. auf die in dem Bedienerarbeitsplatz 13 geladenen Tools, oder er kann Werkzeuge vorschlagen, die vor ihrem Einsatz erst noch gekauft oder in das Prozesssteuersystem 10 geladen werden müssen. Der Block 94 kann natürlich auch den Einsatz manueller Werkzeuge vorschlagen, also Werkzeuge, die nicht auf dem Bedienerarbeitsplatz 13, dem Prozessrechner 12 oder einem der Geräte 15-28 ablaufen.

Nachdem der Block 94 ein oder mehrere weitere(s) Diagnosewerkzeug(e) empfohlen hat, erwartet ein Block 96 die Wahl eines Werkzeugs durch den Benutzer zur Implementierung, und nach Erhalt eines entsprechenden Befehls vom Bediener findet ein Block 98 das gewählte Werkzeug und führt es aus, um den Bediener in die Lage zu versetzen, eine weitere Analyse und Eingrenzung der Problemursache vorzunehmen oder das Problem zu beheben. Nach Implementierung des Diagnosewerkzeugs ermöglicht ein Block 100 dem Bediener die Auswahl eines anderen Werkzeugs für das angesteuerte Problem und ein Block 102 ermöglicht dem Bediener die Auswahl bzw. Ansteuerung eines anderen Problems.

Bei einem Ausführungsbeispiel kann der Block 94 Analysewerkzeuge empfehlen, die im typischen Fall als Anwendungen zur Trendermittlung bezeichnet werden und die Erfassung einer vergleichsweise großen Datenmenge und/oder den Abgriff von vielen Daten voraussetzen, ehe sie ablaufen können. Als Beispiele für derartige Anwendungen zur Trendermittlung seien hier unter anderem eine Korrelations- Analyse, ein neuronales Netzwerk, eine Steuerprozedur mit Fuzzy-Logik, eine Abstimmprozedur zur adaptiven Abstimmung, eine Routine zur Spektralanalyse, und dergleichen genannt. Wenn das Diagnosewerkzeug 52 Probleme erkennt, stehen im typischen Fall die für das Trendermittlungs-Werkzeug benötigten Daten leider nicht zur Verfügung, da diese Daten zuvor nicht erfasst wurden. Diese Daten müssen gegebenenfalls erst noch mit einer so hohen Frequenz und so hoher Datenrate erfasst werden, die bei Verwendung einfacher Kommunikationsverbindungen zwischen dem Prozessrechner 12 und dem Arbeitsplatz 13 praktisch nicht erreicht werden können. Wenn nun der Bediener ein Werkzeug auswählt, das die Erfassung dieser Daten (schnelle Daten) voraussetzt, so konfiguriert infolgedessen der Block 98 unter Umständen den Prozessrechner 12 automatisch so um, dass die benötigten Daten vom Prozesssteuersystem 10 aus erfasst werden.

Müssen solche Daten von Fieldbus-Funktionsblöcken oder Geräten aus erfasst werden, d. h. von den Geräten über die Fieldbus-Busleitung, so kann der Prozessrechner 12 gegebenenfalls eines oder mehrere Trendobjekte im Fieldbus- Verbund einsetzen, um die Daten zu erfassen, die so erfassten Daten zu Datenpaketen zusammenfassen und abspeichern und diese Datenpakete dann zu jedem gewünschten Zeitpunkt an den Bedienerarbeitsplatz 13 übermitteln, so dass die schnellen Daten in einer Weise an den Bedienerarbeitsplatz zugeliefert werden, die hinsichtlich der Zeit nicht kritisch ist. Durch diese Betriebsweise wird die Kommunikationsbelastung zwischen dem Prozessrechner 12 und dem Bedienerarbeitsplatz 13 bei der Erfassung solcher Daten gesenkt. Im typischen Fall wird ein Trendobjekt zur Erfassung einer vorgegebenen Anzahl von Messwerten (z. B. 16) für alle jeweils gewünschten Daten eingerichtet, die sich auf einen Funktionsblock beziehen, und wenn die vorgegebene Anzahl Messwerte erfasst wurde, so werden diese unter Einsatz asynchroner Kommunikationsformen an den Rechner 12 übermittelt. Die Verwendung von einem oder mehreren Trendobjekten 110 für die Fieldbus-Funktionsblöcke ist in Fig. 8 dargestellt. Dabei wird bzw. werden das bzw. die Trendobjekt(e) 110 eingesetzt, um die gewünschten Daten zu erfassen und an die Datenerfassungseinheit 48 im Prozessrechner 12 zu senden, welche ihren Ursprung in den nachgeschalteten Fieldbus-Geräten im Rahmen der aktuellen Funktionsblöcke haben. Diese Trendobjekte 110 können von einem Fieldbus-Gerät oder von den Schatten-Funktionsblöcken kommen (die ganz allgemein als Schatten-Funktionsblöcke 112S im Prozessrechner 12 in Fig. 8 dargestellt sind. In ähnlicher Weise könnten bei Funktionsblöcken, die sich im Prozessrechner 12 befinden und von diesem ausgeführt werden (ganz allgemein als Funktionsblöcke 113 in Fig. 8 dargestellt) virtuelle Trendobjekte 114 im Prozessrechner 12 eingerichtet werden, um die von den 4-20 mA-Geräten (oder anderen Geräten) gelieferten gewünschten Daten zu erfassen. Messwerte für derartige virtuelle Trendobjekte 114 können mit jeder gewünschten Geschwindigkeit erfasst werden, beispielsweise alle 50 Millisekunden. Die virtuellen Trendobjekte 114 können so konfiguriert werden, dass sie den tatsächlichen Trendobjekten im Fieldbus-Protokoll ähnlich sind und der Datenerfassungseinheit 48 zugeliefert werden. Die Datenerfassungseinheit 48 liefert die gesammelten Daten in der vorstehend beschriebenen Weise an die Protokollfüh rungseinheit 50 in dem Bedienerarbeitsplatz 13.

Die Trendobjekte 110 und 114 werden so lange erfasst, bis genügend Daten abgespeichert sind, damit das gewünschte Diagnosewerkzeug ablaufen kann. Nachdem genügend schnelle Daten erfasst wurden, führt der Block 98 in Fig. 4 das weitere Diagnosewerkzeug unter Verwendung der erfassten Daten aus oder implementiert es in anderer Weise, um so eine Verarbeitung und Regelkreisanalyse auf hohem Niveau durchzuführen.

Das Diagnosewerkzeug 52 zeigt, wie vorstehend bereits ausgeführt, einen Satz Optionen an, die zur Behebung eines Problems in einem Regelkreis oder Block verwendet werden sollen, beispielsweise der Einsatz eines Auto-Tuners, die Durchführung einer Trendanalyse, der Einsatz eines weiteren Diagnosewerkzeugs, und dergleichen. In vielen Fällen genügt es, eine Liste von Optionen anzubieten, damit das Diagnosewerkzeug 52 dem Benutzer die Behebung des Problems möglich macht. Um die richtige Auswahl zu treffen, muss der Benutzer mit dem Prozesssteuernetzwerk und den vom Diagnosewerkzeug 52 vorgeschlagenen Werkzeugen vertraut sein. Im typischen Fall ist der Benutzer leider ab kein Fachmann, weder im Hinblick auf das Prozesssteuer-Netzwerk noch auf die Diagnosewerkzeuge, oder gar auf beides. Auch wenn sich der Benutzer in bestimmten Teilen des Prozesssteuer-Netzwerks unter Umständen gut auskennt, ist es nicht praxisbezogen, vom Benutzer zu erwarten, dass er alle Aspekte eines Prozesssteuer-Netzwerks versteht, das über Tausende von Außengeräten implementiert ist. Darüber hinaus wertet weder das Diagnosewerkzeug 52 noch der Benutzer alle relevanten Daten aus, die zur Ermittlung der angemessenen Korrekturmaßnahmen zur Verfügung stehen. Beispielsweise sind Daten zur Vorgeschichte im Zusammenhang mit der Erfassung und Korrektur früher aufgetretener Probleme für die Ermittlung relevant, ob alternative Korrekturmaßnahmen anstelle der zuvor versuchten Maßnahmen, die sich als nicht effektiv erwiesen haben, nun versucht werden sollten. Außerdem sind historische Daten, die sich auf Ereignisse und Alarmmeldungen beziehen, für die Ermittlung relevant, ob andere Umstände außer Funktionsstörungen in den Außengeräten und Funktionsblöcke die Ursache für die Minderleistung eines Regelkreises sind. Diese weiteren Daten können mit der nötigen Erfahrung dadurch ausgewertet werden, dass ein Expertensystem eingerichtet wird, das laufend alle relevanten Daten auswertet und anhand aller zur Verfügung stehenden relevanten Informationen Korrekturmaßnahmen vorschlägt.

Fig. 9 zeigt das Prozesssteuersystem 10 aus Fig. 2, das außerdem ein Expertensystem 60' aufweist, das in dem zentralen Arbeitsplatz 13 implementiert ist. Das Expertensystem 60' ist vorzugsweise als Software im Speicher des Arbeitsplatzes 13 implementiert und wird vom Rechner 54 ausgeführt. Das Expertensystem 60' könnte aber genau so gut in Form einer Firmware oder Hardware realisiert sein, wenn dies gewünscht wird. Bei dem Expertensystem 60' handelt es sich, wie dargestellt und hier beschrieben, um eine separate Anwendung in dem Arbeitsplatz 13 und erhält Eingangsinformationen vom Diagnosewerkzeug 52, das in der vorstehend beschriebenen Weise Diagnosedaten entwickelt. Das Diagnosewerkzeug 52 kann als separates Softwareteil in das Expertensystem 60' einbezogen sein, oder umgekehrt. Außerdem kann das Expertensystem 60' teilweise oder insgesamt in separaten Arbeitsplätzen mit eigenen Prozessoren und Rechnern implementiert sein.

Bei dem Expertensystem 60' kann es sich um eine standardmäßige Experten-Software handeln, wie beispielsweise das G2-System, das von Gensym Corp. mit Sitz in Cambridge, Massachusetts vertrieben wird. Das Expertensystem 60' kann auch jedes andere, bis heute bekannte oder in Zukunft erst noch entwickelte Expertensystem sein. Während der Installation wird das Expertensystem 60' mit Regeln für die Analyse konfiguriert, die bei der Auswertung von Daten anzuwenden sind, welche für Probleme relevant sind, die in den Außengeräten, Funktionsblöcken, Regelkreisen, oder anderen Steuer- und Regelteilen des Prozesssteuersystems 10 auftreten. Beispielsweise könnte das Expertensystem 60' mit einer Regel für einen Regelkreis konfiguriert werden, die besagt, dass dann, wenn der Regelkreis im Automatikmodus arbeitet und die Variabilität für diesen Kreis hoch ist, das Expertensystem 60' eine Benutzerschnittstelle aufrufen soll, um den Benutzer darauf hinzuweisen, dass der Regelkreis neu eingestellt werden muss. Die Analyseregeln werden natürlich durch die jeweiligen Voraussetzungen und Anforderungen des Prozesssteuersystems 10 diktiert, in dem das Expertensystem 60' implementiert ist.

Fig. 9 zeigt auch ein Ereignisjournal bzw. Ereignisprotokoll 62', in dem Ereignis- und Alarmdaten abgespeichert sind. Das Ereignisprotokoll 62' enthält beispielsweise Informationen im Zusammenhang mit Vorkommnissen wie z. B. alle Schritte eines Bedieners zum Verändern von Sollwerten, Betriebsarten und weitere System- und Geräteparameter, Hinweise auf die. Notwendigkeit der Durchführung von Wartungsarbeiten bei Außengeräten, und ähnliches. Ereignis- und Alarmdaten werden in das Expertensystem 60' eingegeben und dort verwendet, wenn festgelegt wird, welche Schritte gegebenenfalls erforderlich sind, um Außengeräte, Funktionsblöcke und Regelkreise, die mit verminderter Leistung arbeiten, zu korrigieren. Das Ereignisprotokoll 62' ist gegebenenfalls in einem separaten Speichergerät oder einem eigenen Arbeitsplatz angesiedelt, oder es kann Teil der Informationen sein, die im Langzeitspeicher 50 des Bedienerarbeitsplatzes 13 abgespeichert sind, in dem das Expertensystem 60' implementiert ist.

Das Prozesssteuersystem 10 weist gemäß Fig. 9 auch einen Protokollführer 64' zur Aufzeichnung der Vorgeschichte auf, in dem historische Informationen abgespeichert werden, die sich beispielsweise auf Probleme beziehen, die zuvor schon von dem Diagnosewerkzeug 52 identifiziert wurden, neben Maßnahmen zur Problembehebung, die daraufhin eingeleitet wurden. Zum Beispiel können in dem Protokollführer 64' Informationen im Hinblick auf die Abstimmung von Steuerfunktionsblöcken, die Neukalibrierung von Messinstrumenten, Einstellungen von Sollwerten für Ventilsteller, und dergleichen abgelegt werden. Wie das Ereignisprotokoll 62' kann auch der Protokollführer 64' in einem separaten Speichergerät oder einem eigenen Arbeitsplatz angesiedelt werden oder Teil der Informationen sein, die im Langzeitspeicher 50 abgespeichert sind.

Das Expertensystem 60' zieht die Informationen vom Diagnosewerkzeug 52, vom Ereignisprotokoll 62' und vom Protokollführer 64' heran, neben den zusätzlichen Analyse- Anwendungen, die am Arbeitsplatz 13 zur Verfügung stehen oder in anderen Arbeitsstationen zugreifbar sind, um Probleme zu erfassen. Fig. 10 zeigt eine Konfiguration, bei welcher das Expertensystem 60' mit anderen Bestandteilen des Prozesssteuersystems 10 zusammenwirkt. Das Expertensystem 60' übernimmt Eingangsinformationen vom Diagnosewerkzeug 52, nachdem das Werkzeug 52 die übernommenen Fehlerdaten analysiert hat und anhand der Fehlerdaten in den Blöcken 63 und 64 gemäß Fig. 4 Probleme erkannt hat. Das Diagnosewerkzeug 52 übermittelt dann an das Expertensystem 60' zumindest die Informationen über das erkannte Problem, die für das Expertensystem 60' nötig sind, um festzulegen, ob eine weitere Problemanalyse und/oder Maßnahmen zur Behebung dieses Problems erforderlich sind. Nach Erhalt der Infor mationen vom Diagnosewerkzeug 62 wendet das Expertensystem 60' die geeigneten Regeln für die Analyse bei dem Außengerät, Funktionsblock oder Regelkreis, dessen Leistung vermindert ist, auf der Grundlage des Regelsatzes des Expertensystems 60' an.

Unter Anwendung der geeigneten Analyseregeln auf das vom Diagnosewerkzeug 52 identifizierte Problem legt das Expertensystem 60' die geeigneten Maßnahmen fest, die zur Problembehandlung zu treffen sind. Das Expertensystem 60' kann festlegen, dass zusätzliche Schritte nicht erforderlich sind. Beispielsweise kann das Expertensystem 60' mit einer Regel zur Analyse eines Ventilstellers konfiguriert sein, nach welcher der Parameterwert für die Variabilität mit der Dauer der Abweichung in der Form vergleicht, dass große Variabilitäten mit höherer Priorität bearbeitet werden als kleinere Variabilitäten. Das Expertensystem 60' kann anhand der vom Diagnosewerkzeug 52 gelieferten Informationen festlegen, dass die Variabilität für den jeweiligen Messzeitraum klein genug ist, so dass der Steller zum aktuellen Zeitpunkt keine weitere Analyse erfordert. Es ist auch möglich, dass das Expertensystem 60' noch mehr Informationen benötigt, zum Beispiel Daten über einen länge ren Zeitraum (z. B. über die gesamte Schicht, die vorherige Schicht, den Vortag), um zu ermitteln, ob weitere Schritte unernommen werden müssen. Die zusätzlichen Daten können durch Abfrage des Diagnosewerkzeugs 52 oder des Langzeitspeichers 50 oder unter Implementierung des vorstehend beschriebenen Vorgangs zur Datenerfassung erhalten werden.

Wenn das Expertensystem 60' feststellt, dass eine weitere Analyse oder Malnahmen zur Problembehebung tatsächlich oder gegebenenfalls notwendig ist, so kann das Expertensystem 60' nach den Analyseregeln angewiesen werden, weitere einschlägige Informationen auszuwerten, um die geeigneten Maßnahmen zur Problembehebung zu ermitteln. Eine Ressource, auf die das Expertensystem 60' gegebenenfalls zurückgreift, ist das Ereignisprotokoll 62'. Das Ereignisprotokoll 62' kann Informationen zu früheren Ereignissen oder Alarmmeldungen enthalten, welche unter Umständen das erfasste Problem verursacht haben. Beispielsweise können in dem Ereignis protokoll 62' Informationen hinsichtlich einer Notabschaltung des Prozesssteuersystems 10 aufgezeichnet sein, die erklären könnten, weshalb ein Ventilsteller oder Durchflussmengenmesser in einem Modus "außer Betrieb" arbeitet. Das Ereignisprotokoll 62' könnte auch Informationen enthalten, die darauf hinweisen, dass ein Außengerät zu Wartungszwecken oder für einen Teilewechsel außer Betrieb genommen wurde. Diese Informationen können beispielsweise erklären, warum der Betrieb des Geräts beschränkt zu sein scheint, und darauf hinweisen, dass das Gerät gegebenenfalls wieder in Betrieb genommen wurde, ohne kalibriert oder neu kalibriert zu werden. Infolgedessen können die im Ereignisprotokoll 62' enthaltenen Informationen einen alternativen Ablauf der Schritte zur Problembehebung diktieren, oder auch erkennen lassen, dass Maßnahmen zur Fehlerkorrektur unnötig sind.

Die Analyseregeln können auch das Expertensystem 60' anweisen, Informationen aus der Protokollführereinheit 64' abzurufen. Wie zuvor schon erläutert, enthält die Protokollierungseinheit 64' Informationen im Zusammenhang mit der Vorgeschichte von Problemen, die vom Diagnosewerkzeug 52 identifiziert wurden, neben der ergänzenden Analyse und Parameterveränderungen, die bei einem Außengerät, Funktionsblock oder einem Regelkreis vorgenommen wurden, das bzw. der mit verringerter Leistung arbeitet. Wenn die Protokollierungseinheit 64' keine Informationen zur Vorgeschichte im Zusammenhang mit dem erkannten Problem enthält, kann das Expertensystem 60' gegebenenfalls das Problem als neu behandeln, die Analyseregeln darauf anwenden, und anhand der Daten aus dem Diagnosewerkzeug 52 die Maßnahmen zur Problembehebung implementieren oder vor schlagen. Alternativ können die Informationen zur Vorgeschichte darauf hinweisen, dass zuvor eine Analyse oder Korrekturmaßnahmen ohne Erfolg eingesetzt wurden, wodurch das Expertensystem 60' dazu veranlasst wird, alternative Maßnahmen zu implementieren. Darüber hinaus kann aus den Informationen zur Vorgeschichte erkennbar sein, dass alle Behebungs- und Korrekturmaßnahmen erschöpft sind und das Problem immer noch besteht. In diesem Fall schlägt das Ex pertensystem 60' unter Umständen dem Benutzer vor, Schritte jenseits der Einflusssphäre des Prozesssteuersystems 10 zu veranlassen, um das Problem zu beheben.

Sobald das Expertensystem 60' alle einschlägigen Daten aus dem Diagnosewerkzeug 52, dem Langzeitspeicher 50, dem Ereignisprotokoll 62' und der Protokollierungseinheit 64' zusammengetragen hat, wendet es die Analyseregeln an, um die geeigneten Schritte festzulegen, entweder zur Identifizierung der Problemursache oder zur Problembehebung. Die Daten und Analyseregeln können zwingend den Einsatz weiterer Analysewerkzeuge fordern, um die Problemursache weiter einzukreisen. Zu den weiteren Analysewerkzeugen können bei spielsweise ein Auto-Tuner zur Abstimmung eines Regelkreises, ein Werkzeug zur Vornahme einer Trendanalyse, Kalibrierwerkzeuge, Routinen zur Ventildiagnose, Korrelationsroutinen, Routinen für eine Spektralanalyse oder alle anderen Diagnosewerkzeuge gehören, wie sie vorstehend schon angesprochen wurden, sowie weitere Werkzeuge, die bis heute bekannt sind oder künftig noch entwickelt werden. Die von dem Expertensystem 60' identifizierten weiteren Diagnose werkzeuge sind gegebenenfalls im Prozesssteuersystem 10 als Analyseanwendungen 66' implementiert, die von dem Expertensystem 10 zum Ablauf gebracht werden können. Die Analyseanwendungen 66' können im Arbeitsplatz 13 oder jedem anderen Arbeitsplatz, in einem oder mehrere Prozessrechnern 12 oder in den Außengeräten selbst als Quellprogramm implementiert sein. Das Expertensystem 60' ruft die erforderliche(n) Analyseanwendung(en) 66' auf und liefert die nötigen Informationen. Bei Bedarf könnte das Expertensystem 60' abfragen, ob der Benutzer den Einsatz des ermittelten Diagnosewerkzeugs zulässt. Sobald die Analyseanwendung(en) 66' die Analyse vorgenommen hat bzw. haben, werden die Analyseergebnisse zurück an das Expertensystem 60' gemeldet.

Weitere Analyseanwendungen 66' setzen gegebenenfalls zusätzliche Eingaben durch den Benutzer voraus und können von dem Expertensystem 60' allein nicht ausgeführt werden. Für diese Analyseanwendungen 66' fordert das Expertensystem 60' den Benutzer auf, die benötigten Informationen über eine Benutzerschnittstelle 68' zur Ausführung der Analyseanwendung 66' einzugeben. Nachdem der Benutzer die benötigten Informationen eingegeben hat, wird die Analyseanwendung 66' entweder direkt über die Benutzerschnittstelle 68' oder über das Expertensystem 60' aufgerufen und übermittelt die Ergebnisse dann nach Vornahme der Analyse an das Expertensystem 60' zurück. Je nach der Komplexität der Analyseanwendung 66' und dem Kenntnisstand des Benutzers können das Expertensystem 60' und die Benutzerschnittstelle 68' auf Wunsch den Benutzer durch die Schritte führen, die nötig sind, um die Analyseanwendung 66' einzurichten und auszuführen. Bei einigen Problemen stellt das Expertensystem 60' unter Umständen fest, dass die richtigen Analysewerkzeuge nicht zur Verfügung stehen und vor dem Einsatz erst noch erworben oder in das Prozesssteuersystem 10 geladen werden müssen. Bei wieder anderen Problemen legt das Expertensystem 60' gegebenenfalls fest, dass manuelle Werkzeuge zur weiteren Analyse und Behebung des Problems eingesetzt werden sollten. In diesen Fällen schlägt das Expertensystem 60' dem Benutzer über die Benutzerschnittstelle 68' vor, die nicht zur Verfügung stehenden und/oder manuellen Werkzeuge zu implementieren, und führt, sofern die Informationen zur Verfügung stehen, den Benutzer durch die nötigen Schritte zur Implementierung der vorgeschlagenen Werkzeuge.

Sobald das Expertensystem 60' und/oder der Benutzer die identifizierten Analyseanwendungen 66', nicht verfügbare oder externe Werkzeuge einsetzt und/oder Maßnahmen zur Problembehebung trifft, aktualisiert das Expertensystem 60' die Protokollierungseinheit 64' mit Informationen im Zusammenhang mit dem erfassten Problem und der weiteren Analyse und den vom Expertensystem 60' oder dem Benutzer veranlassten Maßnahmen zur Problembehebung. Bei Korrek turmaßnahmen, die nicht vom Expertensystem 60' gesteuert werden, z. B. Parameteränderungen, die der Benutzer über die Benutzerschnittstelle 68' eingegeben hat, können die einschlägigen Informationen an die Protokollierungseinheit 68' von einer anderen, von der Änderung betroffenen Systemkomponente des Prozesssteuersystems 10 übermittelt werden, wie beispielsweise der Benutzerschnittstelle 68', einem anderen Arbeitsplatz oder Prozessrechner oder einem Außengerät, Funktionsblock oder Regelkreis, die mit dem ge änderten Parameter zu tun haben. Die aktualisierten Informationen in der Protokollierungseinheit 64' werden von dem Expertensystem 60' bei der Analysierung von Problemen herangezogen, die zu irgendeinem Zeitpunkt in der Zukunft noch immer bestehen oder wieder auftreten.

Die Analyseanwendung 66', Werkzeuge und Korrekturmaßnahmen, die von dem Expertensystem 60' identifiziert werden, sind gegebenenfalls in der Lage - oder auch nicht - das Problem zu beheben. Infolgedessen überwachen das Diagnosewerkzeug 52 und das Expertensystem das mit verminderter Leistung arbeitende Außengerät bzw. den Funktionsblock oder Regelkreis weiterhin. Die Analyseregeln können das Expertensystem 60' anweisen, Informationen, die von einer Analyseanwendung 66' zurückfließen, auszuwerten, um zu ermitteln, ob die Problemursache identifiziert wurde, ob das Problem behoben ist, oder ob zusätzliche Analyse und Korrekturmaßnahmen erforderlich sind. Besteht das Problem nach wie vor und ist die Problemursache immer noch unbekannt, so kann das Expertensystem 60' nach den Analyseregeln angewiesen werden, zusätzliche Analyseanwendungen 66' und Maßnahmen zur Problembehebung zu implementieren. Auf diese Weise kann der Benutzer das Expertensystem 60' in der Form konfigurieren, dass das Problem schrittweise bzw. iterativ analysiert wird, bis es gelöst oder die Problemursache eingekreist ist.

Weitere Probleme bedürfen gegebenenfalls nicht einer Lösung durch einen iterativen Ansatz, der in dem Expertensystem 60' allein entwickelt wird. Beispielsweise erhält das Expertensystem 60' unter Umständen keine direkten Rückmeldungen von den nicht verfügbaren oder manuellen Werkzeugen. Für diese Probleme wird die laufende Problemüberwachung über den normalen Betrieb des Diagnosewerkzeugs 52 erreicht. Wenn das Problem behoben ist, erfasst das Diagnosewerkzeug 52 kein Problem und teilt infolgedessen dem Expertensystem 60' ein erfasstes Problem nicht. Besteht dagegen das Problem weiter, wird es vom Diagnosewerkzeug 52 erfasst und zur Analyse an das Expertensystem 60' übergeben. Anhand der Informationen aus dem Diagnosewerkzeug 52 und in der Protokollierung 64' wendet das Expertensystem 60' die Analyseregeln an, um den geeigneten nächsten Schritt im Hinblick darauf zu ermitteln, dass frühere Maßnahmen bei der Behebung des Problems keinen Erfolg erbracht haben.

Nachdem das Expertensystem 60' eine oder mehrere Analyseanwendungen 66' und/oder Maßnahmen zur Problembehebung identifiziert und implementiert hat, ist es gegebenenfalls in der Lage, die Problemursache mit hoher Wahrscheinlichkeit zu identifizieren. Sobald die Ursache lokalisiert wurde, informiert das Expertensystem 60' den Benutzer über das Problem und dessen Ursache über die Benutzerschnittstelle 68'. Wenn der Benutzer die Empfehlung oder Identifizierung der Problemursache durch das Expertensystem 60' annimmt, kann der Benutzer die entsprechenden Korrekturmaßnahmen einleiten, um das Problem zu beheben. Das Expertensystem 60' kann auch so programmiert werden, dass es den Benutzer durch die zur Problemlösung nötigen Schritte führt. Wenn beispielsweise ein unkorrekter Abstimmungsparameter für die Filterung, eine Ablaufzeit oder dergleichen als Problemursache identifiziert wurden, kann das Expertensystem 60' dem Benutzer einen Wert für den Parameter empfehlen. Bei anderen Problemen kann die empfohlene Lösung unter anderem eine Veränderung der Konfiguration bei einem Regelkreis vorsehen, beispielsweise für den Austausch eines PID-Elements oder einer Steuerlogik mit Vorauskopplung gegen eine Fuzzy-Logik. In diesen Fällen kann das Expertensystem 60' den Benutzer durch die Schritte zum Auswechseln der vorhandenen Regelkreislogik gegen die vorgeschlagene Logik und zum Prüfen des neu aufgebauten Regelkreises führen, um sicherzustellen, dass dieser nun korrekt konfiguriert ist.

Unweigerlich entstehen auch Probleme, für die mit den Analyseregeln in dem Expertensystem 60' keine Lösung geboten wird. Diese Probleme treten unter Umständen dort auf, wo neue Außengeräte installiert werden und zur Ansteuerung von Problemen bei diesem neuen Gerät in dem Expertensystem 60' keine Analyseregeln vorgesehen sind, oder es tritt ein Problem bei einem vorhandenen Gerät oder Regelkreis auf, das bei der Entwicklung der Analyseregeln für das Expertensystem 60' nicht vorhergesehen wurde. In solchen Fällen teilt das Expertensystem 60' dem Benutzer über die Benutzer schnittstelle 68' mit, dass dieses Problem vorliegt, dass das Expertensystem 60' keine Empfehlung für den Ablauf von Maßnahmen zur Behebung besitzt, und dass ein Eingreifen durch den Benutzer oder irgend einen anderen Dritten nötig wird, der mit dem Prozesssteuersystem 10 vertraut ist. Genau kann das Expertensystem 60' mit Selbstlernfähigkeiten ausgestattet sein und auf der Grundlage von Schritten, die ein Benutzer unternimmt, neue Regeln zusätzlich aufnimmt. Bei Bedarf können auch zusätzliche neue Regeln in das Expertensystem 60' eingegeben werden, die dann zur Ermittlung und Behebung von Problemen in einem Prozesssteuersystem anzuwenden sind. Vorzugsweise läuft das Expertensystem 60' laufend im Hintergrund ab und wertet Problempunkte aus, die von dem Diagnosewerkzeug 52 erfasst werden. Wenn das Expertensystem 60' im Hintergrund arbeitet, können die Probleme schon dann von diesem System 60' angesprochen werden, wenn sie im Prozesssteuersystem 10 auftreten, so dass sie so rasch wie möglich behoben werden können. Allerdings ist es bei einigen Implementierungen des Expertensystems 60' unter Umständen nicht möglich, dass damit alle Probleme ausgewertet werden, während das System im Hintergrund arbeitet. Beispielsweise verhindern der große Umfang an Informationen im Prozesssteuersystem 10 und Beschränkungen bei den Verarbeitungsmöglichkeiten am Bedienerarbeitsplatz 13, dass das Expertensystem 60' sich mit allen Problemen befasst, die während der Spitzenbetriebszeiten auftauchen. In solchen Situationen können einige oder alle Probleme dann in einer Warteschlange zur Bearbeitung durch das Expertensystem 60' geparkt werden, bis sie dann außerhalb der Spitzenzeiten in asynchronem Betrieb oder Stapelbetrieb abgearbeitet werden; oder die Analyse durch das Expertensystem 60' wird gegebenenfalls nach dem Auftreten eines auslösenden Ereignisses, zum Beispiel dem Abschalten einer Pumpe, eingeleitet. Außerdem können die Analyseregeln in dem Expertensystem 60' so aufgebaut werden, dass sie die im Prozesssteuersystem 10 auftauchenden Probleme nach Prioritäten sortieren, damit das Expertensystem 60' vordringliche Probleme oder solche hoher Priorität bei ihrer Entstehung analysieren und die Analyse weniger kritischer Probleme auf einen Zeitpunkt verschieben kann, zu dem sie effizienter behandelt werden können. Das Expertensystem 60' kann selbstverständlich auch auf einem eigenen Rechner ablaufen, damit sichergestellt ist, dass es ausreichend Verarbeitungsleistung zum Ablaufen im Hintergrund hat. In anderen Fällen kann der Benutzer das Expertensystem 60' so ablaufen lassen, dass es zu jeder gewünschten Zeit aktiv ist.

Die Implementierung des Expertensystems 60' in einem Prozesssteuersystem bietet eine effizientere und potentiell zuverlässigere Möglichkeit zur Lösung von Problemen, die in dem Prozesssteuer-Netzwerk 10 auftreten. Auf diese Weise zieht das Expertensystem 60' alle verfügbaren einschlägigen Informationen heran, um das erkannte Problem zu analysieren und zu einer Empfehlung für die Problemlösung zu kommen. Das Expertensystem 60' läuft vorzugsweise kontinuierlich im Hintergrund ab und befasst sich mit Problemen schon bei deren Entstehung; es kann aber auch durch ein auslösendes Ereignis oder einen automatischen Terminplaner initialisiert werden, so dass die Probleme effizient behandelt werden. Dies spart auf Seiten des Benutzers Zeit und setzt bei diesem kein hohes Maß an Erfahrung mit der Problembehebung in Regelkreisen und Geräten voraus. Außerdem ist das Expertensystem 60' in der Lage, alle für die Behebung des erkannten Problems einschlägigen Daten noch rascher und effizienter zusammenzutragen und zu analysieren. Neben der Zeitersparnis verringert das Expertensystem 60' auch die Belastung des Benutzers und unterstützt ihn dabei, unter allen Umständen den Einsatz der richtigen Diagnosewerkzeuge und Maßnahmen zur Problembehebung sowie deren korrekte Implementierung sicherzustellen.

Auch wenn das Diagnosewerkzeug 52 und das Expertensystem 60' in der Form beschrieben wurden, dass sie in Verbindung mit Fieldbus-Geräten und standardmäßigen 4-20 mA-Geräten eingesetzt werden, ist es auch möglich, sie bei Einsatz jedes anderen externen Kommunikationsprotokolls in einer Prozesssteuerung zu implementieren und bei Funktionsblöcken oder Geräten mit darin integrierten Funktionsblöcken jedweder anderen Art einzusetzen. Außerdem ist festzustellen, dass sich der Gebrauch des Begriffs "Funktionsblock" hier nicht auf das beschränkt, was beim Fieldbus-Protokoll oder dem Protokoll für eine DeltaV-Steuerung als Funktionsblock definiert ist, sondern er umfasst vielmehr auch jede andere Art von Block, Programm, Hardware, Firmware, usw. in Verbindung mit einem Steuer- und Regelsystem und/oder Kommunikationsprotokoll jedweder Art, das bei der Implementierung irgendeiner Prozesssteuerfunktion herange zogen werden kann. Auch wenn Funktionsblöcke im typischen Fall die Form von Objekten im Rahmen eines objektorientierten Programmierungsumfelds aufweisen, muss dies nicht immer zutreffen.

Obgleich das Diagnosewerkzeug 52 und das Expertensystem 60' in der hier beschriebenen Form vorzugsweise durch Software implementiert sind, können sie auch in Form von Hardware, Firmware usw. installiert sein und von jedem anderen Prozessor oder Rechner implementiert werden, der mit dem Prozesssteuersystem 10 in Zusammenhang steht. So können die hier beschriebenen Routinen 52 und 60 gegebenenfalls in einer standardmäßigen Vielzweck-Zentraleinheit oder auf einer speziell hierfür entwickelten Hardware oder Firmware implementiert sein, beispielsweise je nach Bedarf auf einer anwendungsspezifischen integrierten Schaltung (ASIC) oder einem anderen festverdrahteten Bauteil. Bei softwaremäßiger Implementierung kann die Software-Routine in jedem computer lesbaren Speicher abgespeichert werden, zum Beispiel auf einer Magnetplatte, einer Laserplatte, oder jedem anderen Speichermedium, in einem RAM- oder ROM-Speicher eines Rechners oder Prozessors, usw. Ebenso kann diese Software an den Benutzer oder ein Prozesssteuersystem über jeden bekannten oder gewünschten Lieferweg ausgeliefert werden, beispielsweise auf einer computerlesbaren Platte oder einem anderen transportablen Computerspeichermedium oder auch über einen Kommunikationsweg wie zum Beispiel eine Telefonleitung, das Internet, usw. (die hier als gleichwertiger oder austauschbarer Weg zur Auslieferung derartiger Software über ein transportables Speichermedium angesehen werden). Hier wurde zwar das Expertensystem als regelabhängiges System beschrieben, doch könnten genauso gut auch Expertensysteme anderer Art hierfür eingesetzt werden, unter anderem Datengewinnungssysteme etc. zum Beispiel.

Zwar wurde die vorliegende Erfindung unter Bezugnahme auf spezielle Beispiele beschrieben, doch sind diese hier nur als Beispiele zur Verdeutlichung und nicht als Einschränkung der Erfindung anzusehen; somit liegt es für den Durchschnittsfachmann auf der Hand, dass an den offenbarten Ausführungsbeispielen Veränderungen, Ergänzungen oder Weglassungen möglich sind, ohne vom Erfindungsgedanken und Umfang der Erfindung abzuweichen.

Bezugszeichenliste

10

Prozesssteuersystem

12

Prozessrechner

13

Zentral-Arbeitsplatz (Rechner) Bedienerarbeitsplatz

14

Bildschirm

15 - 22

Außengeräte (Peripherie)

17

Gebergerät (Sensor)

18

Ventilvorrichtung

22

Ventilsteller

26

Ein-/Ausgabekarten (E/A-Karten)

30

Funktionsblock - analoger Eingang

32

Funktionsblock - analoger Ausgang

34

Funktionsblock

36

Regelkreis für die Sollsteuerwerte

38

Geräteschnittstelle

40

Regelkreis für die Ist-Steuerwerte

42

Funktionsblock

42

S Schatten-Funktionsblock

44

Funktionsblock

44

S Schatten-Funktionsblock

46

Funktionsblock

46

S Schatten-Funktionsblock

48

Diagnosedatenerfasser

50

Langzeitspeicher (Protokolliereinheit)

52

Diagnosewerkzeug

54

Rechner

55

Funktionsblock

56

Eingang

57

Ausgang

58

Generator für Variabilitätsangaben

58

Rechner zur Berechnung des Variabilitätsindex

59

Systemkommunikator

60

Softwareroutine

Fig. 9: (wegen doppelter Belegung der Bezugszeichen in der Zeichnung abgeändert)

60

' Expertensystem

62

' Ereignisprotokoll

64

' Protokolliereinheit

66

' Analyseanwendungen

68

' Benutzerschnittstelle

62

Block: Variabilität etc. übernehmen/speichern

63

Block: Datenanalyse durchzuführen?

64

Block: gespeicherte Daten analysieren

66

Block: Listen erstellen?

68

Block: Problemlistenerstellung

70

Block: Analyse angefordert?

72

Block: Anzeige-/Dialogprogramm aufrufen

80

Bildschirmanzeige

82

Liste in Tabellenform

84

Filterschaltfläche

86

Dialogbildschirm

88

Zeitrahmen-Feld

90

Dialogbildschirm

93

Block: Auswahl des Problemfunktionsblocks

94

Block: Satz Optionen anzeigen

96

Block: Werkzeugwahl abwarten

98

Block: gewähltes Werkzeug finden/benutzen

100

Block: anderes Werkzeug wählen

102

Block: anderes Problem wählen

110

Trendobjekt(e)

112

Schattenfunktionsblöcke

114

Trendobjekt

Claims

1. Diagnosesystem zum Einsatz in einem Prozesssteuersystem (10) mit einer Vielzahl verschiedener Außengeräte (15- 22), dadurch gekennzeichnet, dass es eine Datenbank (50) zum Abspeichern von Informationen aufweist, welche zum Betrieb des Prozesssteuersystems (10) gehören, sowie ein Expertensystem (60'), welches anhand der Informationen in der Datenbank (50) eine Lösung für ein Problem im Prozesssteuersystem festlegt.

2. Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass das Expertensystem (60') einen Satz Analyseregeln zur Anwendung bei Verwendung der Informationen in der Datenbank (50) enthält.

3. Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass die Informationen in der Datenbank (50) Ereignisinforma tionen umfassen.

4. Diagnosesystem nach Anspruch 3, dadurch gekennzeichnet, dass die Ereignisinformationen Informationen umfassen, die sich auf die Notwendigkeit der Vornahme von Wartungsmaßnahmen an mindestens einem der Außengeräte (15-22) beziehen.

5. Diagnosesystem nach Anspruch 3, dadurch gekennzeichnet, dass das Prozesssteuersystem (10) Funktionsblöcke umfasst, und dass die Ereignisinformationen Informationen umfassen, die sich auf Änderungen bei den Betriebsparametern für die Funktionsblöcke beziehen.

6. Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass die Informationen in der Datenbank (50) Alarminformatio nen enthalten.

7. Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass das Prozesssteuersystem (10) Funktionsblöcke aufweist, und dass die Informationen in der Datenbank (50) Daten beinhalten, die sich auf Betriebsparameter der Funktionsblöcke für jeden der Funktionsblöcke beziehen.

8. Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass die Informationen in der Datenbank (50) Daten beinhal ten, welche sich auf erfasste Probleme in dem Prozesssteuersystem (10) beziehen.

9. Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass die Informationen in der Datenbank (50) Daten beinhal ten, welche sich auf Änderungen beziehen, die zuvor in dem Prozesssteuersystem (10) vorgenommen wurden.

10. Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass das Expertensystem (60') Analyseregeln aufweist und die Analyseregeln bei den Informationen in der Datenbank (50) anwendet.

11. Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass es des weiteren eine Analyseanwendung (66') umfasst, welches von mindestens einem der Geräte Informationen erhält und dass das Expertensystem (60') die Analyseanwendung (66') zum Erhalten von Informationen über den Betrieb des Prozesssteuersystems (10) ausführt.

12. Diagnosesystem nach Anspruch 11, dadurch gekennzeichnet, dass die Analyseanwendung (66') eine Abstimmeinrichtung ist.

13. Diagnosesystem nach Anspruch 11, dadurch gekennzeichnet, dass die Analyseanwendung (66') eine Kalibriereinrichtung ist.

14. Diagnosesystem nach Anspruch 11, dadurch gekennzeichnet, dass die Analyseanwendung (66') ein Diagnosewerkzeug ist.

15. Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass das Prozesssteuersystem (10) eine Benutzerschnittstelle (68') aufweist, und dass das Expertensystem (60') Informationen über das Problem in dem Prozesssteuersystem (10) an die Benutzerschnittstelle (68') zum Informieren des Benutzers über das Problem übermittelt.

16. Diagnosesystem nach Anspruch 15, dadurch gekennzeichnet, dass die vom Expertensystem (60') an die Benutzerschnitt stelle (68') übermittelten Informationen sich auf die wahrscheinliche Ursache des Problems beziehen.

17. Diagnosesystem nach Anspruch 15, dadurch gekennzeichnet, dass die vom Expertensystem (60') an die Benutzerschnitt stelle (68') übermittelten Informationen sich auf ein empfohlenes weiteres Werkzeug zum Einsatz bei der Behebung des Problems beziehen.

18. Diagnosesystem nach Anspruch 17, dadurch gekennzeichnet, dass die vom Expertensystem (60') an die Benutzerschnitt stelle (68') übermittelten Informationen sich auf Schritte beziehen, die für den Einsatz des empfohlenen weiteren Werkzeugs notwendig sind.

19. Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass das Prozesssteuersystem (10) Funktionsblöcke umfasst, und dass das Diagnosesystem außerdem ein Diagnosewerkzeug (52) umfasst, das zur Erfassung von Daten geeignet ist, die sich auf einen Betriebsparameter der Funktionsblöcke für jeden aus der Vielzahl verschiedener Funktionsblöcke beziehen, und damit einen Wert für einen Betriebsparameter der Funktionsblöcke für jeden aus einer Vielzahl von Zeitpunkten während des Betriebs des Prozesssteuersystems (10) auf der Grundlage der empfangenen Daten zu den Betriebsparametern für die Funktionsblöcke festlegt, ein Problem in dem Prozesssteuersystem (10) auf der Grundlage der ermittelten Werte der Betriebsparameter für die Funktionsblöcke ermittelt, und das erfasste Problem an das Expertensystem (60') übermittelt.

20. Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass das Expertensystem (60') die Lösung des Problems automa tisch festlegt.

21. Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass das Expertensystem (60') laufend im Hintergrund des Pro zesssteuersystems (10) läuft.

22. Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass das Expertensystem (60') die Lösung des Problems im An sprechen auf ein auslösendes Ereignis festlegt.

23. Diagnosesystem zum Einsatz in einem Prozesssteuersystem (10) mit einem Prozessrechner (12) und einer Vielzahl verschiedener Außengeräte (15-22), dadurch gekennzeichnet, dass es folgendes aufweist:
einen vom Computer lesbaren Speicher, und
eine in dem vom Computer lesbaren Speicher gespeicherte Routine (60), welche auf dem Prozessrechner (12) implementiert ist,
wobei die Routine (60) Informationen erfasst, die sich auf den Betrieb des Prozesssteuersystems (10) beziehen, und
eine Lösung für ein Problem in dem Prozesssteuersystem (10) anhand der erfassten Informationen festlegt.

24. Diagnosesystem nach Anspruch 23, dadurch gekennzeichnet, dass die Routine (60) Analyseregeln zur Anwendung bei den er fassten Informationen beinhaltet.

25. Diagnosesystem nach Anspruch 23, dadurch gekennzeichnet, dass die von der Routine (60) erfassten Informationen Ereignisinformationen umfassen.

26. Diagnosesystem nach Anspruch 25, dadurch gekennzeichnet, dass die Ereignisinformationen Informationen beinhalten, die sich auf die Notwendigkeit der Durchführung von Wartungsmaßnahmen bei mindestens einem der Außengeräte (15-22) beziehen.

27. Diagnosesystem nach Anspruch 25, dadurch gekennzeichnet, dass das Prozesssteuersystem (10) Funktionsblöcke aufweist, und dass die Ereignisinformationen Informationen umfassen, die sich auf Änderungen bei den Betriebsparametern für die Funktionsblöcke beziehen.

28. Diagnosesystem nach Anspruch 23, dadurch gekennzeichnet, dass die von der Routine (60) erfassten Informationen Alarminformationen beinhalten.

29. Diagnosesystem nach Anspruch 23, dadurch gekennzeichnet, dass das Prozesssteuersystem (10) Funktionsblöcke aufweist, und dass die von der Routine (60) erfassten Informationen sich auf Betriebsparameter der Funktionsblöcke für jeden der Funktionsblöcke beziehen.

30. Diagnosesystem nach Anspruch 23, dadurch gekennzeichnet, dass die von der Routine (60) erfassten Informationen Daten umfassen, die sich auf erfasste Probleme in dem Prozesssteuersystem (10) beziehen.

31. Diagnosesystem nach Anspruch 23, dadurch gekennzeichnet, dass die von der Routine (60) erfassten Informationen Daten umfassen, die sich auf Änderungen beziehen, die zuvor bei dem Prozesssteuersystem (10) vorgenommen wurden.

32. Diagnosesystem nach Anspruch 23, dadurch gekennzeichnet, dass die Routine (60) Analyseregeln aufweist und die Analyseregeln bei den von der Routine (60) erfassten Informationen anwendet.

33. Diagnosesystem nach Anspruch 23, dadurch gekennzeichnet, dass die Routine (60) eine Analyseanwendung (66') ausführt, welche zusätzliche Informationen über den Betrieb des Prozesssteuersystem (10) von mindestens einem der Außengeräte (15-22) erhält.

34. Diagnosesystem nach Anspruch 33, dadurch gekennzeichnet, dass die Analyseanwendung (66') eine Abstimmeinrichtung ist.

35. Diagnosesystem nach Anspruch 33, dadurch gekennzeichnet, dass die Analyseanwendung (66') eine Kalibriereinrichtung ist.

36. Diagnosesystem nach Anspruch 33, dadurch gekennzeichnet, dass die Analyseanwendung (66') ein Diagnosewerkzeug ist.

37. Diagnosesystem nach Anspruch 23, dadurch gekennzeichnet, dass das Prozesssteuersystem (10) eine Benutzerschnittstelle (68') aufweist, und dass die Routine (60) Informationen über das Problem in dem Prozesssteuersystem (10) an die Benutzerschnittstelle (68') zum Informieren des Benutzers über das Problem übermittelt.

38. Diagnosesystem nach Anspruch 37, dadurch gekennzeichnet, dass die von der Routine 60) an die Benutzerschnittstelle (68') übermittelten Informationen sich auf die wahrscheinliche Ursache des Problems beziehen.

39. Diagnosesystem nach Anspruch 37, dadurch gekennzeichnet, dass die von der Routine (60) an die Benutzerschnittstelle (68') übermittelten Informationen sich auf ein empfohlenes weiteres Werkzeug zum Einsatz bei der Behebung des Problems beziehen.

40. Diagnosesystem nach Anspruch 39, dadurch gekennzeichnet, dass die von der Routine (60) an die Benutzerschnittstelle (68') übermittelten Informationen sich auf Schritte beziehen, die für den Einsatz des empfohlenen weiteren Werkzeugs notwendig sind.

41. Diagnosesystem nach Anspruch 23, dadurch gekennzeichnet, dass
das Prozesssteuersystem (10) Funktionsblöcke aufweist und
dass die Routine (60) Daten erfasst, die sich auf einen Betriebsparameter der Funktionsblöcke für jeden aus der Vielzahl verschiedener Funktionsblöcke beziehen, und damit einen Wert für einen Betriebsparameter der Funktionsblöcke für jeden aus einer Vielzahl von Zeitpunkten während des Betriebs des Prozesssteuersystems (10) auf der Grundlage der empfangenen Daten zu den Betriebsparametern für die Funktionsblöcke festlegt, und ein Problem in dem Prozesssteuersystem (10) auf der Grundlage der ermittelten Werte der Betriebsparameter für die Funktionsblöcke ermittelt.

42. Diagnosesystem nach Anspruch 23, dadurch gekennzeichnet, dass die Routine (60) eine Lösung des Problems automatisch festlegt.

43. Diagnosesystem nach Anspruch 23, dadurch gekennzeichnet, dass die Routine (60) laufend im Hintergrund des Prozesssteuersystems (10) läuft.

44. Diagnosesystem nach Anspruch 23, dadurch gekennzeichnet, dass die Routine (60) die Lösung für das Problem im Anspre chen auf ein auslösendes Ereignis festlegt.

45. Verfahren zur Diagnose bei einem Prozesssteuersystem (10), welches den Ablauf eines Prozesses steuert, dadurch gekennzeichnet, dass es die folgenden Schritte aufweist:
Erfassen von Informationen, die sich auf den Betrieb des Prozesssteuersystems beziehen,
und Festlegen von Lösungen für Probleme in dem Prozesssteuersystem anhand der erfassten Informationen.

46. Verfahren nach Anspruch 45, dadurch gekennzeichnet, dass der Schritt zur Festlegung den Teilschritt mit Anwendung von Analyseregeln bei den erfassten Informationen umfasst.

47. Verfahren nach Anspruch 45, dadurch gekennzeichnet, dass die erfassten Informationen Ereignisinformationen umfas sen.

48. Verfahren nach Anspruch 47, dadurch gekennzeichnet, dass
das Prozesssteuersystem Außengeräte aufweist und dass
die Ereignisinformationen Informationen beinhalten, die sich auf die Notwendigkeit der Vornahme von Wartungsmaßnahmen bei mindestens einem der Außengeräte beziehen.

49. Verfahren nach Anspruch 47, dadurch gekennzeichnet, dass
das Prozesssteuersystem Funktionsblöcke aufweist und
dass die Ereignisinformationen Informationen umfassen, die sich auf Änderungen bei den Betriebsparametern für die Funktionsblöcke beziehen.

50. Verfahren nach Anspruch 45, dadurch gekennzeichnet, dass die erfassten Informationen Alarminformationen beinhal ten.

51. Verfahren nach Anspruch 45, dadurch gekennzeichnet, dass
das Prozesssteuersystem Funktionsblöcke aufweist und
dass die erfassten Informationen Daten beinhalten, die sich auf Parameter der Funktionsblöcke für jeden der Funktionsblöcke beziehen.

52. Verfahren nach Anspruch 45, dadurch gekennzeichnet, dass die erfassten Informationen Daten umfassen, die sich auf erfasste Probleme im Prozesssteuersystem beziehen.

53. Verfahren nach Anspruch 45, dadurch gekennzeichnet, dass die erfassten Informationen Daten umfassen, die sich auf Änderungen beziehen, die zuvor an dem Prozesssteuersystem vorgenommen wurden.

54. Verfahren nach Anspruch 45, dadurch gekennzeichnet, dass
das Prozesssteuersystem Funktionsblöcke aufweist, und
dass der Schritt zur Festlegung den Teilschritt zur Erfassung von Informationen von mindestens einem der Funktionsblöcke aufweist, der sich auf ein in dem Prozesssteuersystem erfasstes Problem bezieht.

55. Verfahren nach Anspruch 45, dadurch gekennzeichnet, dass der Schritt zur Festlegung den Teilschritt zur Empfeh lung der Verwendung eines Werkzeugs zur Behebung eines erfassten Problems aufweist.

56. Verfahren nach Anspruch 55, dadurch gekennzeichnet, dass das Werkzeug eine Abstimmeinrichtung ist.

57. Verfahren nach Anspruch 55, dadurch gekennzeichnet, dass das Werkzeug eine Kalibriereinrichtung ist.

58. Verfahren nach Anspruch 55, dadurch gekennzeichnet, dass das Werkzeug ein Diagnosewerkzeug ist.

59. Verfahren nach Anspruch 55, dadurch gekennzeichnet, dass der Schritt zur Festlegung des weiteren den Teilschritt zur Implementierung des Werkzeugs umfasst.

60. Verfahren nach Anspruch 45, dadurch gekennzeichnet, dass es des weiteren den Teilschritt zur Mitteilung eines er fassten Problems in dem Prozesssteuersystem an den Benutzer umfasst.

61. Verfahren nach Anspruch 60, dadurch gekennzeichnet, dass der Teilschritt zur Mitteilung den Teilschritt zur Über mittlung von Informationen umfasst, die sich auf die wahrscheinliche Ursache des erfassten Problems beziehen.

62. Verfahren nach Anspruch 60, dadurch gekennzeichnet, dass der Teilschritt zur Mitteilung den Teilschritt zur Über mittlung von Informationen umfasst, die sich auf ein empfohlenes weiteres Werkzeug zur Verwendung bei der Behebung des erfassten Problems beziehen.

63. Verfahren nach Anspruch 62, dadurch gekennzeichnet, dass die übermittelten Informationen sich auf Schritte bezie hen, die zur Benutzung des empfohlenen weiteren Werkzeugs notwendig sind.

64. Verfahren nach Anspruch 45, dadurch gekennzeichnet, dass das Prozesssteuersystem Funktionsblöcke aufweist, und dass das Verfahren des weiteren die folgenden Schritte umfasst:
Erfassen von Daten, die sich auf einen Betriebsparameter von Funktionsblöcken für jeden der Funktionsblöcke beziehen,
Bestimmen eines Werts für den Betriebsparameter von Funktionsblöcken für jeden aus einer Reihe von Zeitpunkten während des Betriebs des Prozesssteuersystems auf der Grundlage der empfangenen Daten zu dem Betriebsparameter von Funktionsblöcken, und
Erfassen eines Problems in dem Prozesssteuersystem auf der Grundlage der ermittelten Werte des Betriebsparameters von Funktionsblöcken.

65. Verfahren nach Anspruch 45, dadurch gekennzeichnet, dass der Schritt zur Bestimmung automatisch ausgeführt wird.

66. Verfahren nach Anspruch 45, dadurch gekennzeichnet, dass der Schritt zur Bestimmung laufend im Hintergrund des Prozesssteuersystems ausgeführt wird.

67. Verfahren nach Anspruch 45, dadurch gekennzeichnet, dass der Schritt zur Bestimmung im Ansprechen auf ein auslösendes Ereignis ausgeführt wird.