DE60210448T2

DE60210448T2 - Verbesserter hart-gerätealarm in einem prozesssteuerungssystem

Info

Publication number: DE60210448T2
Application number: DE60210448T
Authority: DE
Inventors: Evren Minneapolis Eryurek; Dale Jon Eagan WESTBROCK; Thomas Craig Bloomington LLEWELLYN
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 2001-05-21
Filing date: 2002-05-20
Publication date: 2006-11-30
Anticipated expiration: 2022-05-21
Also published as: EP1395884A2; CN1522391A; AU2002303810A1; JP2004530983A; US20020147511A1; US6975219B2; WO2002095509A3; DE60210448D1; CN100381957C; WO2002095509A2; JP4436046B2; EP1395884B1

Description

VERWANDTE ANMELDUNGEN
Die vorliegende Anmeldung ist eine Teilfortsetzung der US-Patentanmeldung Nr. 09/861 790 mit dem Titel "Enhanced Fieldbus Device Alerts in a Process Control System", angemeldet 21. Mai 2001, die das Vorrecht des Anmeldedatums der vorläufigen US-Patentanmeldung Nr. 60/273 164 mit dem Titel "Asset Utilization Expert in a Process Control Plant", angemeldet 1. März 2001, in Anspruch nimmt.
GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft allgemein Prozeßsteuerungssysteme und speziell die Erweiterung bzw. Verbesserung von HART^®-Gerätewarnungen oder -alarmen in einem Prozeßsteuerungssystem.
BESCHREIBUNG DES STANDS DER TECHNIK
Prozeßsteuerungssysteme, wie sie in Chemie-, Erdöl- oder anderen Prozessen verwendet werden, haben typischerweise eine oder mehrere zentrale Prozeßsteuereinheiten, die mit wenigstens einem Hauptrechner oder einer Bedienerworkstation und mit einem oder mehreren Feldgeräten über analoge, digitale oder kombinierte Analog-/Digitalbusse kommunikativ gekoppelt sind. Die Feldgeräte, die beispielsweise Ventile, Ventilpositionierer, Schalter und Meßwertgeber (z. B. Temperatur-, Druck- und Durchflußratesensoren) sein können, führen Funktionen innerhalb des Prozesses aus wie etwa das Öffnen oder Schließen von Ventilen und das Messen von Prozeßparametern. Die Prozeßsteuereinheit empfängt Signale, die von den Feldgeräten durchgeführte Prozeßmessungen bezeichnen, und/oder andere Informationen, welche die Feldgeräte betreffen, nutzt diese Informationen zur Implementierung einer Steuerroutine und erzeugt dann Steuersignale, die über die Busse oder andere Nachrichtenleitungen an die Feldgeräte übertragen werden, um den Ablauf des Prozesses zu steuern. Informationen von den Feldgeräten und den Steuereinheiten werden einer oder mehreren Anwendungen zur Verfügung gestellt, die von der Bedienerworkstation ausgeführt werden, um einem Bediener zu erlauben, gewünschte Funktionen in bezug auf den Prozeß, etwa das Betrachten des aktuellen Zustands des Prozesses, Modifizieren des Prozeßbetriebs usw., auszuführen.
Das von Fisher Rosemount Systems, Inc., verkaufte DeltaV-Prozeßsteuerungssystem verwendet Funktionsblöcke, die in Steuereinheiten oder verschiedenen Feldgeräten angeordnet oder eingebaut sind, um Steueroperationen auszuführen. Die Steuereinheiten und in manchen Fällen die Feldgeräte können einen oder mehrere Funktionsblöcke speichern und ausführen, von denen jeder Eingänge von anderen Funktionsblöcken empfängt und/oder Ausgänge an diese liefert (wobei diese anderen Funktionsblöcke entweder innerhalb desselben Geräts oder in anderen Geräten vorhanden sind) und einige Prozeßsteuerungsoperationen ausführt wie Messen oder Detektieren eines Prozeßparameters, Steuern eines Geräts oder Ausführen eines Steuervorgangs wie etwa die Implementierung einer Proportional-Integral-Differential- bzw. PID-Steuerroutine. Die verschiedenen Funktionsblöcke innerhalb eines Prozeßsteuerungssystems sind so konfiguriert, daß sie miteinander (z. B. innerhalb eines einzelnen Geräts oder über einen Bus) kommunizieren, um eine oder mehrere Prozeßsteuerschleifen zu bilden, deren individuelle Operationen im gesamten Prozeßsteuerungssystem verteilt sein können. Wie ferner wohlbekannt ist, können FOUNDATION Fieldbus-Geräte (nachstehend nur Fieldbus) zusätzlich zu Funktionsblöcken jeweils einen oder mehrere zugehörige Ressourcenblöcke und/oder Meßumformerblöcke haben, die verschiedene Fähigkeiten dieses Geräts repräsentieren. Beispielsweise kann ein Fieldbus-Temperaturgeber, der zwei Temperaturerfassungselemente hat, zwei Meßumformerblöcke (d. h. einen für jedes Erfassungselement) und einen Funktionsblock haben, der die Ausgangssignale der beiden Erfassungselemente (über die Meßumformerblöcke) liest, um einen mittleren Temperaturwert zu bilden.
Typischerweise sind die Funktions-, Meßumformer- und Ressourcenblöcke oder die Geräte, in denen diese Blöcke implementiert sind, so konfiguriert, daß sie Fehler, Defekte oder Probleme detektieren, die in den Prozeßsteuerschleifen, den Einheiten, den Geräten usw. auftreten, und ein Signal aussenden (entweder automatisch, was bei Fieldbus-Geräten der Fall ist, oder als Reaktion auf Abfragen, was bei HART^®-Geräten der Fall ist) wie etwa einen Alarm oder eine Warnmeldung, um einen Bediener an einer Bedienerworkstation oder einer anderen Benutzeroberfläche zu informieren, daß innerhalb des Prozeßsteuerungssystems oder einer Steuerschleife des Prozeßsteuerungssystems ein unerwünschter Zustand vorliegt. Solche Alarme oder Warnungen können beispielsweise bedeuten, daß ein Block nicht kommuniziert, daß ein Block einen nicht im Bereich liegenden Eingang bzw. Ausgang empfangen bzw. erzeugt hat, daß ein Block sich soeben in einem fehlerhaften oder anderen unerwünschten Zustand befindet usw. Bei derzeitigen Alarmverarbeitungs- und -anzeigesystemen kann eine Anwendung, die beispielsweise an einer Bedieneroberfläche/-workstation ausgeführt wird, so konfiguriert sein, daß sie Meldungen empfängt, die den Prozeßbetrieb betreffende Prozeßalarme enthalten, und diese Prozeßalarme auf eine verständliche und handhabbare Weise anzeigt, um dadurch einem Bediener zu ermöglichen, Alarme auf organisierte oder logische Weise zu behandeln. Ein solches Bedieneroberflächensystem ist in der US-PS 5 768 119 mit dem Titel "Process Control System Including Alarm Priority Adjustment" beschrieben, die hier summarisch eingeführt wird.
Bisher wurden herkömmliche Feldgeräte in Prozeßsteuerungssystemen verwendet, um Analogsignale wie etwa 4-20-mA-Signale auf einem Analogbus oder auf Analogleitungen an die Prozeßsteuereinheit zu senden und von dieser zu empfangen. Diese 4-20-mA-Signale sind jedoch insofern begrenzt, als sie nur Prozeßmeßwerte bezeichnen, die von dem Gerät erhalten wurden, oder Prozeßsteuersignale bezeichnen, die von der Steuereinheit erzeugt und erforderlich sind, um die Operation des Geräts während der Betriebszeit zu steuern. Infolgedessen sind herkömmliche 4-20-mA-Geräte nicht imstande, auf die Betriebsfähigkeit oder den Status der Geräte bezogene Alarme oder Warnungen zu erzeugen. Somit sind bisher Alarme, die dem Zustand oder Status dieser Geräte zugeordnet sind, im allgemeinen innerhalb von Prozeßsteuerungssystemen nicht verfügbar.
Seit einiger Zeit sind in der Prozeßsteuerungsindustrie intelligente Feldgeräte eingeführt, die einen Mikroprozessor und einen Speicher aufweisen. Eine Reihe von offenen Kommunikationsprotokollen für intelligente Feldgeräte, etwa das Fieldbus-, HART^®-, PROFIBUS^®-, WORLDFIP^®-, DeviceNet^®- und CAN-Protokoll, sind entwickelt worden, um von verschiedenen Herstellern stammende intelligente Feldgeräte innerhalb desselben Prozeßsteuerungsnetzes gemeinschaftlich verwenden zu können. Zusätzlich zum Ausführen einer Primärfunktion innerhalb des Prozesses kann ein intelligentes Feldgerät das Gerät betreffende Daten speichern, mit der Steuereinheit und/oder anderen Geräten in einem digitalen oder einem kombinierten digitalen und analogen Format kommunizieren und Sekundäraufgaben wie etwa Selbstkalibrierung, Identifizierung, Diagnosen usw. ausführen. Dabei ist es wichtig, daß die Geräte, die wenigstens einigen der genannten Protokolle entsprechen (etwa dem HART^®- und dem Fieldbus-Protokoll), imstande sind, Probleme innerhalb des Geräts selbst zu detektieren, und imstande sind, Alarm- oder Warnmeldungen zu erzeugen und zu senden, um die detektierten Probleme für die entsprechenden Bediener, das Wartungspersonal oder das Technikpersonal, die für den Betrieb des Prozeßsteuerungssystems verantwortlich sind, anzuzeigen.
Fieldbus-Geräte übermitteln beispielsweise Alarm- oder Warninformationen unter Verwendung eines wohlbekannten Meldungsformats. Fieldbus-Gerät-Alarmmeldungen umfassen ein Blockidentifikationsfeld, ein relatives Identifikationsfeld, ein Subcodefeld und ein Gleitkommazahlfeld. Allgemein gesagt, bezeichnen die in einer Fieldbus-Gerät-Alarmmeldung vorhandenen Felder in zunehmenden Genauigkeitsstufen die Quelle einer Alarmmeldung und die Art des Alarms oder der Warnung, die dadurch übermittelt wird. Insbesondere bezeichnet das Blockidentifikationsfeld innerhalb einer Fieldbus-Gerät-Alarmmeldung den Block innerhalb des Fieldbus-Geräts, von dem die Alarmmeldung ursprünglich ausgeht. Daher kann eine Steuereinheit, eine Workstation usw. das Blockidentifikationsfeld innerhalb einer Fieldbus-Gerät-Alarmmeldung dazu nutzen zu bestimmen, welcher Block die Alarmmeldung erzeugt hat und ob die Alarmmeldung von einem Funktionsblock, einem Ressourcenblock oder einem Meßumformerblock erzeugt wurde.
Das relative Identifikationsfeld einer Fieldbus-Gerät-Alarmmeldung bezeichnet den Parameter innerhalb eines bestimmten Blocks (z. B. eines Funktionsblocks, Ressourcenblocks oder Meßumformerblocks), der die Erzeugung der Alarmmeldung verursacht hat. Ein gegebener Block kann zwei oder mehr ihm zugeordnete Parameter haben, die dadurch voneinander unterschieden werden können, daß innerhalb des relativen Identifikationsfelds verschiedene Werte verwendet werden. Beispielsweise kann ein Funktionsblock mehrere Eingänge und Ausgänge haben, und jeder davon kann eindeutig einem jeweils verschiedenen relativen Identifikationsfeldwert zugeordnet sein.
Das Subcodefeld liefert im allgemeinen einen Zahlenwert, der die Art der Alarmmeldung bezeichnet, die von einem Gerät übermittelt wird, und vom Gerätehersteller vorher bestimmt wird. Beispielsweise kann das Subcodefeld dazu dienen anzuzeigen, daß ein Sensorwert außerhalb eines normalen Betriebsbereichs liegt, daß ein Sensor vollständig ausgefallen ist oder irgendein anderer Defekt vorliegt, der in einem Fieldbus-Gerät auftreten kann.
In Fieldbus-Geräten ist das Subcodefeld geräte- und herstellerspezifisch, so daß verschiedene Arten von Ausfällen innerhalb eines bestimmten Blocks eines gegebenen Fieldbus-Geräts in unterschiedlichen Subcodefeldwerten resultieren können, und identische Arten von Ausfällen in verschiedenen Geräten und/oder innerhalb von gleichartigen Geräten, die von verschiedenen Herstellern stammen, können ebenfalls dazu führen, daß innerhalb einer Alarmmeldung verschiedene Subcodefeldwerte übermittelt werden. Da das Subcodefeld nicht vom Anwender konfigurierbar ist und die Subcodefeldwerte für bestimmte Arten von Fehlern geräte- und/oder herstellerspezifisch sind, liefern die Hersteller typischerweise eine Liste von Subcodes und entsprechenden Fehlerarten, damit die Subcodewerte in Fehlertypen übersetzt werden können.
Das Gleitkommazahlenfeld enthält typischerweise eine Gleitkommazahl, die dem Subcode zugeordnet ist, der innerhalb der Alarmmeldung übermittelt wird. Wenn also ein Subcodefeld anzeigt, daß ein Sensorwert innerhalb eines bestimmten Meßumformerblocks außerhalb eines normalen Betriebsbereichs liegt, kann das Gleitkommafeld einen Gleitkommawert enthalten, der den tatsächlichen Wert, der außerhalb des Bereichs liegt, darstellt.
Wie allgemein bekannt ist, sind die Blöcke (d. h. die Meßumformer-, Ressourcen- und Funktionsblöcke) innerhalb von Fieldbus-Geräten imstande, eine Alarmmeldung oder einen Meldeparameter BLOCK_ALM und einen Alarmbeschreibungs- oder Zustandsparameter BLOCK_ERR zu liefern. Allgemein gesagt, ermöglicht es BLOCK_ALM einem Fieldbus-Gerät, über eine Steuereinheit und eine Bedienerworkstation einem Systemanwender oder -bediener mitzuteilen, daß innerhalb dieses Fieldbus-Geräts ein Alarmzustand besteht. Dagegen definiert BLOCK_ERR, welcher von sechzehn verschiedenen möglichen Alarm- oder Warnzuständen von dem Fieldbus-Gerät detektiert worden ist, das einen aktiven Alarmzustand über BLOCK_ALM mitteilt. Es ist bekannt, daß BLOCK_ERR sechzehn Bits aufweist, die jeweils einen von sechzehn vorher definierten möglichen Alarm- oder Warnzuständen darstellen, die im Zusammenhang mit einem bestimmten Block eines bestimmten Fieldbus-Geräts auftreten können. Die sechzehn vorher definierten Alarm- oder Warnzustände umfassen einen Gerät-braucht-bald-Wartung-Zustand, einen Gerät-braucht-jetzt-Wartung-Zustand, einen Eingabefehler-Zustand, einen Ausgabefehler-Zustand, einen Speicherausfall-Zustand, einen Verlust-von-statischen-Daten-Zustand, einen Sonstiger-Zustand usw. Zusätzlich zu den sechzehn vorbestimmten detektierbaren Warn- oder Alarmzuständen liefern einige Fieldbus-Gerätehersteller Fieldbus-Geräte, die Diagnosefähigkeiten zum Detektieren anderer Zustände aufweisen. Beispielsweise kann ein Fieldbus-Gerät zugesetzte Ventilleitungen oder einen Ventilantriebsausfall detektieren, einen Weglängenalarm usw. liefern und kann diese anderen Arten von Zuständen melden durch Setzen des "Sonstiger"-Bits des BLOCK_ERR-Parameters und Melden des sonstigen Zustands über den BLOCK_ALM-Parameter. Alternativ oder zusätzlich können manche Fieldbus-Gerätehersteller diese sonstigen Arten von Zuständen (d. h. diejenigen Zustände, die nicht einer der sechzehn vorher definierten Zustände sind) melden unter Verwendung von anbieterspezifischen Alarmen und/oder Parametern, die von einem Gerätehersteller zum nächsten erheblich verschieden sein können.
Leider sind die sechzehn vordefinierten Fieldbus-Alarm- oder Warnzustände unter dem BLOCK_ERR-Parameter gemeinsam gruppiert, und jeder einzelne aktive Zustand (d. h. ein Warn- oder Alarmzustand, der von dem Gerät detektiert worden ist) veranlaßt den BLOCK_ALM-Parameter zu der Meldung, daß das Gerät einen aktiven Alarm oder eine aktive Warnung hat. Wenn daher ein erster Alarm- oder Warnzustand innerhalb eines herkömmlichen Fieldbus-Geräts aktiv wird, meldet der BLOCK_ALM-Parameter diesen ersten Alarm- oder Warnzustand, und Alarm- oder Warnzustände, die nach diesem ersten Alarm aktiv werden, werden erst dann gemeldet, wenn der erste gemeldete Alarm- oder Warnzustand aufgehoben oder quittiert ist. Infolgedessen kann ein Alarm- oder Warnzustand mit relativ niedriger Priorität das Melden eines wichtigeren Zustands maskieren, bis der Systemanwender oder Bediener den zuerst gemeldeten Zustand niedriger Priorität löscht oder quittiert. Beispielsweise kann ein Block in einem Fieldbus-Gerät einen "Gerät-braucht-bald-Wartung"-Zustand unter Verwendung der BLOCK_ERR- und BLOCK_ALM-Parameter detektieren und melden, und wenn das Gerät anschließend einen "Gerät-braucht-jetzt-Wartung"-Zustand detektiert, kann dieser anschließend detektierte Zustand innerhalb des BLOCK_ERR-Parameters reflektiert werden (d. h. durch Setzen des entsprechenden Bits). BLOCK_ALM ist jedoch unfähig, den schwerer wiegenden "Gerät-braucht-jetzt-Wartung"-Zustand zu melden, bis der Alarm- oder Warnzustand, der in Verbindung mit dem "Gerät-braucht-bald-Wartung"-Zustand gemeldet wurde, vom Systemanwender gelöscht oder quittiert ist.
Zusätzlich wird das konsistente Überwachen, Verarbeiten und Melden von Alarmen oder Warnungen intelligenter Feldgeräte weiter kompliziert, wenn eine Vielzahl von Typen von intelligenten Feldgeräten innerhalb eines einzigen Prozeßsteuerungssystems integriert sind. Beispielsweise werden Geräte, die dem HART^®-Protokoll entsprechen (d. h. HART^®-Geräte), häufig in Verbindung mit Fieldbus-Geräten zur Ausführung eines Prozesses eingesetzt.
In jedem Fall sind sämtliche HART^®-Geräte so konfiguriert (in Übereinstimmung mit dem HART^®-Protokoll), daß ein Gerätestatus unter Verwendung von acht Standardzuständen gemeldet wird. Leider sind die acht Standard-Statuszustände, die von dem HART^®-Protokoll definiert sind und von mit HART^® kompatiblen Geräten bereitgestellt werden, typischerweise nicht konsistent mit den Statuszuständen, die von mit Fieldbus kompatiblen Geräten bereitgestellt werden. Infolgedessen ist das konsistente Melden und Organisieren von Alarm- oder Warninformationen, die von Kombinationen aus Fieldbus- und HART^®-Geräten empfangen werden, durch einen Systembediener oder -anwender sehr kompliziert, wenn nicht unmöglich. Wie wohlbekannt ist, weisen außerdem HART^®-Geräte typischerweise einen oder mehrere nicht dem Standard entsprechende bzw. gerätespezifische Statuszustände auf, die vom Gerätehersteller definiert sind. Diese Nichtstandard-Statuszustände können bei den einzelnen Gerätetypen und Geräteherstellern verschieden sein, so daß ein bestimmter Gerätetyp, der von verschiedenen Herstellern stammt, oder verschiedene Gerätetypen, die von einem einzigen Hersteller stammen, unterschiedliche Mengen bzw. Gruppen von gerätespezifischen Statuszuständen bereitstellen können. In jedem dieser Fälle erschweren diese Nichtstandard-Statuszustände von HART^®-Geräten das integrierte Überwachen, Verarbeiten und Anzeigen eines HART^®-Gerätestatus und eines Fieldbus-Gerätestatus noch weiter.
GB 2 347 234 beschreibt ein Diagnosesystem zur Verwendung in einem Prozeßsteuerungssystem. Statusdaten werden von dem System gewonnen und mit einer Datenbank verglichen, um Lösungen für im System auftretende Probleme festzulegen. Eine Expertenmaschine ist gezeigt, um die relevanten Probleme und ihre Lösungen festzulegen.
EP 0 964 325 betrifft ein Feldgeräte-Management in Industrieprozeßsystemen. Ein Wartungs-Managementsystem sammelt Status- und/oder diganostische Daten von Feldgeräten über eine Feldkommunikationsschnittstelle auf eine Weise, die für jede Art von Feldgerät spezifisch ist.
ZUSAMMENFASSUNG DER ERFINDUNG
Die hier beschriebenen verbesserten HART^®-Gerätewarnungen ermöglichen es HART^®-Geräten innerhalb eines Prozeßsteuerungssystems, Alarm- oder Warnzustände, die in den Geräten detektiert werden, an einen Systemanwender oder -bediener unter Verwendung einer Vielzahl von Statuszuständen zu melden, die mit den Alarmarten konsistent sind, die von Fieldbus-Geräten gemeldet werden, und zwar von Fieldbus-Geräten, welche die hier beschriebenen verbesserten Fieldbus-Gerätewarnungen verwenden. Jeder dieser Statuszustände entspricht einem anderen Schweregrad, und jede Art von Statuszustand kann von dem Systemanwender oder Bediener eine andere Art von Reaktion erforderlich machen.
Gemäß der Erfindung weist ein Verfahren zum Erzeugen einer HART^®-Alarmmeldung in einem Prozeßsteuerungssystem die folgenden Schritte auf: spezifisches Zuordnen einer Vielzahl von Gerätezuständen für ein HART^®-Gerät zu einer Vielzahl von Geräte-Statuszuständen, von denen jeder einen anderen Schweregrad bezeichnet. Das Verfahren weist ferner die Schritte auf: Detektieren eines Zustands, der dem HART^®-Gerät zugeordnet ist, und Klassifizieren des Zustands, der dem HART^®-Gerät zugeordnet ist, zu einem der Vielzahl von Gerätestatuszuständen. Zusätzlich weist das Verfahren den folgenden Schritt auf: Erzeugen der HART^®-Alarmmeldung derart, daß sie Informationen umfaßt, die dem Zustand, der dem HART^®-Gerät zugeordnet ist, und dem einen der Vielzahl von Gerätestatuszuständen zugeordnet sind.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Blockbild eines Prozeßsteuerungssystems, in dem Fieldbus-Geräte und HART^®-Geräte verwendet werden können, die verbesserte Warn- oder Alarmfähigkeiten haben;
2 ist ein Blockbild einer Workstation, die ein darin ausgeführtes Alarmdisplay- und Schnittstellensystem hat, das in dem in 1 gezeigten Prozeßsteuerungssystem verwendet werden kann;
3 ist ein beispielhafter Benutzeroberflächenbildschirm, der von dem Alarmdisplay- und Schnittstellensystem generiert werden kann, das in dem Prozeßsteuerungssystem von 1 verwendet wird;
4 ist ein weiterer beispielhafter Benutzeroberflächenbildschirm, der von dem Alarmdisplay- und Schnittstellensystem generiert werden kann, das in dem Prozeßsteuerungssystem von 1 verwendet wird;
5 ist noch ein anderer beispielhafter Benutzeroberflächenbildschirm, der von dem Alarmdisplay- und Schnittstellensystem generiert werden kann, das in dem Prozeßsteuerungssystem von 1 verwendet wird; und
6 ist noch ein anderer beispielhafter Benutzeroberflächenbildschirm, der von dem Alarmdisplay- und Schnittstellensystem generiert werden kann, das in dem Prozeßsteuerungssystem von 1 verwendet wird.
BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
Gemäß 1 umfaßt ein Prozeßsteuerungsnetz oder -system 10 eine oder mehrere Prozeßsteuereinheiten 12, die mit einer oder mehreren Hauptworkstations oder Hauptrechnern 14 (die jede Art von Personalcomputer oder Workstation sein können) verbunden sind, und Reihen von Ein-/Ausgabe- bzw. E/A-Einrichtungen 20, 22, deren jede mit einem oder mehreren Feldgeräten 25 bis 39 verbunden ist. Die Steuereinheiten 12 können beispielsweise DeltaV^TM-Steuereinheiten sein, die von Fisher-Rosemount Systems, Inc., verkauft werden, und sind mit den Hauptrechnern 14 beispielsweise über eine Ethernet-Verbindung 40 oder jede andere geeignete Kommunikationsstrecke kommunikativ verbunden. Ebenso sind die Steuereinheiten 12 mit den Feldgeräten 25 bis 39 kommunikativ verbunden unter Verwendung jeder gewünschten Hardware und Software, die beispielsweise 4-20-mA-Geräten zugeordnet ist, und/oder unter Verwendung jedes intelligenten Kommunikationsprotokolls wie den Fieldbus- oder HART^®-Protokollen. Wie allgemein bekannt ist, implementieren oder überwachen die Steuereinheiten 12 Prozeßsteuerroutinen, die darin gespeichert oder ihnen anderweitig zugeordnet sind, und kommunizieren mit den Feldgeräten 25 bis 39 zur Steuerung eines Prozesses auf jede gewünschte Weise.
Die Feldgeräte 25 bis 39 können jede Art von Geräten wie Sensoren, Ventile, Meßwertgeber, Positionierer usw. sein, während die E/A-Karten in den Reihen 20 und 22 jede Art von E/A-Einrichtungen sein können, die mit einem gewünschten Kommunikations- oder Steuerprotokoll wie HART^®, Fieldbus, Profibus usw. konform sind. Bei der in 1 gezeigten Ausführungsform sind die Feldgeräte 25 bis 27 4-20-mA-Standardgeräte, die über Analogleitungen mit der E/A-Karte 22A kommunizieren, die Feldgeräte 28 bis 31 sind als HART^®-Geräte dargestellt, die mit einer HART^®-kompatiblen E/A-Einrichtung 20A verbunden sind, und die Feldgeräte 32 bis 39 sind Fieldbus-Feldgeräte, die unter Verwendung von Fieldbus-Protokollkommunikationen über einen digitalen Bus 42 oder 44 mit den E/A-Karten 20B oder 22B kommunizieren.
Jede der Steuereinheiten 12 ist so konfiguriert, daß sie eine Steuerungsstrategie unter Verwendung von Funktions-, Meßumformer- und Ressourcenblöcken implementiert. Wie allgemein bekannt ist, ist jeder Block ein Teil (z. B. eine Subroutine) einer Gesamtsteuerungsroutine und ist in Verbindung mit anderen Blöcken (über als Strecken bezeichnete Kommunikationen) wirksam zur Implementierung von Prozeßsteuerschleifen innerhalb des Prozeßsteuerungssystems 10. Funktionsblöcke und Meßumformerblöcke führen typischerweise Funktionen aus wie Eingabefunktionen, die etwa einem Sensor oder einer anderen Einrichtung zur Messung von Prozeßparametern zugeordnet sind, Steuerfunktionen, die etwa einer Steuerroutine zugeordnet sind, die eine PID-Steuerung, eine Fuzzylogiksteuerung usw. ausführt, oder Ausgabefunktionen, die den Betrieb irgendeines Geräts wie etwa eines Ventils zur Durchführung einer physischen Funktion innerhalb des Prozeßsteuerungssystems 10 steuern. Selbstverständlich gibt es auch Hybridblöcke und andere Arten von Blöcken.
Funktionsblöcke können in der Steuereinheit 12 gespeichert sein und von ihr ausgeführt werden, was typischerweise der Fall ist, wenn Funktionsblöcke für 4-20-mA-Standardgeräte und einige Arten von intelligenten Feldgeräten verwendet werden oder diesen zugeordnet sind, oder sie können in den Feldgeräten gespeichert sein und von diesen ausgeführt werden. In der vorliegenden Beschreibung des Steuerungssystems 10 wird eine Steuerungsstrategie mit Funktions-, Meßumformer- und Ressourcenblöcken verwendet, die Steuerungsstrategie könnte aber auch unter Anwendung anderer Techniken implementiert sein, etwa von Leiterlogik, sequentiellen Flußdiagrammen usw. und unter Verwendung jeder gewünschten geschützten oder nichtgeschützten Programmiersprache.
In dem System von 1 wirken eine oder mehrere der Hauptrechnereinrichtungen 14 als Bedienerworkstation und haben darin gespeicherte Alarmverarbeitungssoftware 50. Allgemein gesagt, zeigt die Alarmverarbeitungssoftware 50 Informationen über das Prozeßsteuerungssystem 10 an, die sich auf das Verständnis oder die Fähigkeit des Systembedieners oder Anwenders zum Betrachten des aktuellen Betriebsstatus des Prozesses in bezug auf die im System vorhandenen Alarme beziehen. Beispielsweise kann die Alarmverarbeitungssoftware 50 eine Alarmleiste, die Alarmbezeichnungen enthält, und ein primäres Steuerdisplay anzeigen, das einen Abschnitt des Prozeßsteuerungssystems 10 zeigt einschließlich der Geräte und sonstigen Einrichtungen, die diesem Abschnitt des Prozeßsteuerungssystems 10 zugeordnet sind und für einen oder mehrere der innerhalb der Alarmleiste angezeigten Alarme relevant sind. Das primäre Steuerdisplay kann Informationen über den aktuellen Zustand des Prozeßsteuerungssystems 10 liefern wie etwa über den Pegel eines Fluids in einem Behälter, die Durchflußcharakteristik eines Ventils und anderer Fluidleitungen, die Einstellungen der Einrichtungen, die Meßwerte von den Sensoren, den Status eines Geräts usw. Ein Beispiel eines solchen Displays ist in 3 gezeigt. Ein Bediener kann die Alarmverarbeitungssoftware 50 nutzen, um verschiedene Teile des Prozeßsteuerungssystems 10 oder von Einrichtungen innerhalb des Prozeßsteuerungssystems 10 zu betrachten. Selbstverständlich kommuniziert die Alarmverarbeitungssoftware 50 mit den Steuereinheiten 12 und erforderlichenfalls den Feldgeräten 25 bis 39, mit jeder der Reihen von E/A-Einrichtungen 20, 22 oder allen anderen Einrichtungen, um die relevanten Werte, Einstellungen und Meßwerte zu erhalten, die dem Prozeßsteuerungssystem 10 zugeordnet oder darin gebildet werden, um die Benutzeroberfläche am Bedienerdisplay der Workstation 14 zu erzeugen.
Die Alarmverarbeitungssoftware 50 ist so konfiguriert, daß sie Alarmnachrichten empfängt, die von Alarmerzeugungssoftware in einigen oder sämtlichen der Steuereinheiten 12, der E/A-Einrichtungen 20 und 22 und/oder der Feldgeräte 25 bis 39 erzeugt weiden. Die Alarmverarbeitungssoftware 50 ist nur beispielhaft allgemein als Softwareelemente 51, 52 und 53 in 1 dargestellt. Allgemein gesagt, empfängt die Alarmverarbeitungssoftware 50 verschiedene Kategorien von Alarmmeldungen wie beispielsweise Prozeßalarme (die typischerweise von Prozeßsteuerungssoftwaremodulen erzeugt werden, wie sie etwa aus kommunizierend miteinander verbundenen Funktionsblöcken bestehen, die Prozeßsteuerroutinen bilden, die während der Betriebsdauer des Prozesses verwendet werden), Hardwarealarme, wie sie von den Steuereinheiten 12, den E/A-Einrichtungen 20 und 22 oder anderen Workstations 14 erzeugt werden und den Zustand oder Funktionszustand dieser Einrichtungen betreffen, und Gerätealarme, die von einigen oder sämtlichen der Feldgeräte 25 bis 39 erzeugt werden, um diese Geräte betreffende Probleme oder potentielle Probleme zu bezeichnen. Diese und andere Alarmkategorien können auf jede gewünschte Weise erzeugt werden. Beispielsweise ist es wohlbekannt, daß die Funktionsblöcke oder Softwaremodule, die zur Implementierung von Prozeßsteuerfunktionen genutzt werden, Prozeßalarme erzeugen, und diese Prozeßalarme werden typischerweise in Form von Alarmmeldungen an Bedieneroberflächen zur Anzeige übermittelt. Außerdem können einige intelligente Geräte, Steuereinheiten, E/A-Einrichtungen, Datenbanken, Server, Workstations usw. irgendeine geschützte oder nichtgeschützte Software nutzen, um Probleme, Fehler, Wartungswarnungen usw. zu detektieren, und können Alarme oder Warnungen, welche diese Zustände bezeichnen, an die Bedieneroberfläche in der Workstation 14 senden. Insbesondere weisen viele Einrichtungen wie etwa Steuereinheiten, E/A-Einrichtungen und intelligente Feldgeräte Software und/oder Sensoren auf, die Hardwareprobleme wie etwa einen klemmenden Ventilkegel, gebrochene Teile, Wartungsprobleme usw. detektieren und Signale oder Meldungen erzeugen können, die diese Zustände bezeichnen.
Falls gewünscht, kann die Alarmverarbeitungssoftware 50 Alarme empfangen und auf der Basis einer Reihe von Faktoren filtern. Speziell kann die Alarmverarbeitungssoftware 50 Alarme filtern auf der Basis der Workstation, in der die Software 50 ausgeführt wird, der Identität der Person, die in die Workstation eingeloggt ist, und auf der Basis von vom Bediener konfigurierbaren Einstellungen wie Kategorie, Typ, Priorität, Status, Erzeugungszeit usw. des Alarms. Beispielsweise kann die Alarmverarbeitungssoftware 50 Alarme filtern, um selektiv Alarme aus den Bereichen oder Abschnitten des Betriebs anzuzeigen, für deren Empfang die Workstation, welche die Alarmverarbeitungssoftware 50 ausführt, konfiguriert ist. Anders ausgedrückt, Alarme für bestimmte Bereiche oder Sektionen des Betriebs dürfen nicht an bestimmten Workstations gezeigt werden, sondern statt dessen kann jede Workstation darauf beschränkt sein, Alarme für einen oder mehrere bestimmte Bereiche des Betriebs anzuzeigen. Ebenso können Alarme auf der Basis einer Bedieneridentifikation gefiltert werden, so daß für einzelne Bediener die Beschränkung auf Betrachtung bestimmter Kategorien, Typen, Prioritätsstufen usw. von Alarmen besteht oder die Beschränkung auf Betrachtung von Alarmen von einem Abschnitt oder Unterabschnitt (z. B. einem Bereich) des Betriebs besteht. Die Alarmverarbeitungssoftware 50 kann außerdem zur Anzeige bestimmte Alarme auf der Basis der Berechtigung des Bedieners unter Sicherheitsaspekten filtern. Im allgemeinen werden diese Workstation- und Bediener-Filtereinstellungen als Workstation- und Bediener-Gültigkeitsbeschränkung bezeichnet.
Die Alarmverarbeitungssoftware 50 kann außerdem die zu betrachtenden Alarme (d. h. diejenigen innerhalb der Workstation- und Bediener-Gültigkeitsbeschränkung) auf der Grundlage von vom Bediener konfigurierbaren Einstellungen filtern, die beispielsweise umfassen: die Alarmkategorie (z. B. Prozeß-, Geräte- oder Hardwarealarm), Alarmtyp (z. B. Kommunikation, Ausfall, empfohlene Maßnahme, Wartung usw.), die Alarmpriorität, das Modul, das Gerät, die Hardware, den Knotenpunkt oder Bereich, auf den der Alarm bezogen ist, ob der Alarm quittiert oder unterdrückt wurde, ob der Alarm aktiv ist usw.
Einige oder sämtliche der Fieldbus-Geräte 32 bis 39 können drei jeweils unabhängig meldefähige Gerätealarm- oder Warnkategorien aufweisen, die bisher in Verbindung mit Fieldbus-Geräten nicht verwendet wurden. Allgemein gesagt, kann jede dieser selbständig meldefähigen Alarmkategorien einem anderen Schweregrad entsprechen, und somit können Alarme oder Warnungen innerhalb jeder Kategorie eine jeweils verschiedene Art von Reaktion durch den Systemanwender oder Bediener erfordern.
Insbesondere können die Fieldbus-Geräte 32 bis 39 einen Alarmparameter FAILED_ALM bereitstellen, der allgemein ein Problem innerhalb eines Geräts bezeichnet, das aufgehört hat, ordnungsgemäß zu arbeiten, oder das überhaupt nicht arbeitet, wodurch das Gerät seine normalen Erfassungs- und/oder Steuerfunktionen nicht ausführen kann. Beispielsweise kann ein Speicherausfall in einem Gerät, ein Antriebsausfall in einem Gerät oder irgendein anderer Geräteausfall, der sofortige Aufmerksamkeit erfordert (d. h. Wartung, Reparatur usw.), unter Nutzung des FAILED_ALM-Parameters gemeldet werden. Die Fieldbus-Geräte 32 bis 39 können außerdem einen Alarmparameter MAINT_ALM bereitstellen, der allgemein einen in einem Gerät detektierten Zustand bezeichnet, der einer Anforderung von irgendeiner Art von Gerätewartung zugeordnet ist, jedoch keinen ausreichenden Schweregrad hat, um die Meldung über den FAILED_ALM-Parameter notwendig zu machen. Gerätezustände, die unter Verwendung des MAINT_ALM-Parameters gemeldet werden, sind bevorzugt, jedoch nicht notwendigerweise, Zustände, die von irgendeiner Art von Verschlechterung, Verschleiß, Ermüdung usw. innerhalb eines Geräts herrühren und letztlich in einem Ausfall des Geräts resultieren könnten, jedoch nicht unbedingt die Fähigkeit des Geräts zum Erfassen, Steuern oder Durchführen anderer notwendiger Funktionen beeinträchtigen. Beispielsweise sind klemmende Ventile, sich zusetzende Impulsleitungen usw. Gerätezustände, die zur Meldung eines Alarms oder einer Warnung über den MAINT_ALM-Parameter führen können. Außerdem können die Fieldbus-Geräte 32 bis 39 einen Alarmparameter ADVISE_ALM abgeben, der allgemein einen in einem Gerät detektierten Zustand bezeichnet, der nur eine Warnung oder einen Alarm in Form einer Empfehlung benötigt. Allgemein gesagt, haben Alarme oder Warnungen, die unter Verwendung des ADVISE_ALM-Parameters gemeldet werden, keine Auswirkung auf den Betrieb des Geräts oder des Prozesses, das unter Verwendung des Geräts gesteuert und/oder überwacht wird. Beispielsweise kann ein Erdungsproblem, das von einem Magmeter detektiert wird, eine vorübergehende Übertemperatur oder ein vorübergehender Überdruck, die von einem Sensor detektiert werden, unter Verwendung des ADVISE_ALM-Parameters gemeldet werden.
Im Gegensatz zu den BLOCK_ALM- und BLOCK_ERR-Parametern, die von herkömmlichen Fieldbus-Geräten verwendet werden, erlauben es also die unabhängig meldefähigen Parameter FAILED_ALM, MAINT_ALM und ADVISE_ALM einem Fieldbus-Gerät, eine Vielzahl von Alarmen oder Warnungen, die unterschiedliche Schweregrade haben, gleichzeitig zu melden. Anders ausgedrückt kann ein einziges Fieldbus-Gerät unter Verwendung der hier beschriebenen unabhängig meldefähigen Alarme ein Erdungsproblem, das keine unmittelbare Aktion erfordert, unter Verwendung von ADVISE_ALM melden, und gleichzeitig kann dieses Fieldbus-Gerät einen Zustand mit höherem Schweregrad wie etwa einen Sensorausfall, der sofortiges Handeln erfordert, unter Verwendung des FAILED_ALM-Parameters melden, und zwar ohne Rücksicht darauf, ob FAILED_ALM vom Systembediener quittiert oder gelöscht worden ist.
Bevorzugt, jedoch nicht notwendigerweise, ist jeder der hier beschriebenen Parameter FAILED_ALM, MAINT_ALM und ADVISE_ALM unter Verwendung eines 32-Bitworts auf der Basis jedes gewünschten Datenformats oder Datentyps wie beispielsweise DS-72 oder DS-71 gebildet, die beide wohlbekannte IEEE-Standards sind und deshalb nicht näher beschrieben werden. Jedes Bit innerhalb jedes 32-Bit-Worts kann für einen speziellen Gerätezustand repräsentativ sein, der unter Verwendung des Alarmparameters zu melden ist, der diesem 32-Bit-Wort entspricht. Somit kann jedes Fieldbus-Gerät zweiunddreißig Gerätezustände mit jedem der drei verschiedenen Schweregrade (d. h. FAILED_ALM, MAINT_ALM und ADVISE_ALM) für insgesamt sechsundneunzig spezielle Alarm- oder Warnzustände melden. Falls gewünscht, kann ein Bit in jedem der unabhängig meldefähigen Alarme FAILED_ALM, MAINT_ALM und ADVISE_ALM für "Sonstige"-Zustände genutzt werden, die nicht speziell definiert sind, was es den Geräten ermöglicht, auf die Detektion einer Vielzahl von Gerätezuständen, die bei der Konstruktion des Geräts nicht vorhergesehen wurden und/oder die von einem bestimmten Anwender benötigt werden, flexibler zu reagieren.
Im allgemeinen kann zwar ein Alarm oder eine Warnung unter Verwendung der ADVISE_ALM- oder MAINT_ALM-Parameter gemeldet werden, ohne die Fähigkeit eines Fieldbus-Geräts zum gleichzeitigen Melden eines Alarms mit höherem Schweregrad unter Verwendung des FAILED_ALM-Parameters zu beeinträchtigen, aber vielfache aktive Zustände (d. h. vielfache detektierte Gerätezustände) innerhalb eines bestimmten Alarmparameters resultieren eventuell nicht darin, daß vielfache Alarmereignisse zu der Bedienerworkstation 14 gesendet werden. Wenn beispielsweise eines der Fieldbus-Geräte einen Überdruckzustand und einen Übertemperaturzustand detektiert, werden die diesen Zuständen entsprechenden Bits in dem ADVISE_ALM-Parameter für dieses Gerät gesetzt. Der erste detektierte Zustand bewirkt jedoch, daß ein Alarmereignis erzeugt und zu der Bedienerworkstation 14 gesendet wird, wogegen jeder anschließend detektierte Zustand erst dann zur Erzeugung eines weiteren Alarmereignisses führt und an die Workstation 14 übermittelt wird, nachdem das Alarmereignis, das dem früheren oder zuerst detektierten Zustand zugeordnet ist, vom Systembediener oder Anwender gelöscht oder quittiert worden ist. Wenn daher das Fieldbus-Gerät zuerst den Überdruckzustand detektiert, erzeugt der anschließend detektierte Übertemperaturzustand erst dann ein Alarmereignis, wenn der Systemanwender oder -bediener den Überdruckalarm oder die Überdruckwarnung aufgehoben oder quittiert hat.
Die Parameter FAILED_ALM, MAINT_ALM und ADVISE_ALM können dem Systemanwender oder -bediener unabhängig voneinander gemeldet werden über eine der Workstations 14 unter Verwendung des Fieldbus-Alarmmeldungsformats, das oben beschrieben wird (d. h. des Meldungsformats, das ein Blockidentifikationsfeld, ein Subcodefeld usw. aufweist). Ferner wird jeder von den 32 möglichen Zuständen, die jedem der Parameter FAILED_ALM, MAINT_ALM und ADVISE_ALM zugeordnet sind, bevorzugt, jedoch nicht notwendigerweise dargestellt unter Verwendung eines speziellen Subcodes, wenn diese Alarme an eine Systemworkstation unter Verwendung des Fieldbus-Alarmmeldeformats gesendet werden. Jedes Fieldbus-Gerät weist Definitionen der Subcodes auf, die jedem der möglichen Zustände für jeden der FAILED_ALM-, MAINT_ALM- und ADVISE_ALM-Parameter zugeordnet sind. Außerdem kann jedes Fieldbus-Gerät eine spezielle Textmeldung definieren, die den Zustand beschreibt, der jedem der Subcodes zugeordnet ist. Jeder Subcode entspricht zwar bevorzugt einem speziellen Gerätezustand und damit einer speziellen Textmeldung, es kann aber in manchen Fällen erwünscht sein, eine einzige Textmeldung für mehr als einen Gerätezustand zu verwenden.
Die hier beschriebenen, selbständig meldefähigen Gerätealarmparameter können von jedem Gerät gefiltert werden, um das Melden eines Alarms oder einer Warnung als Reaktion auf einen oder mehrere der möglichen Gerätezustände (d. h. der 96 möglichen Zustände) zu aktivieren oder zu deaktivieren. Jedes der Fieldbus-Geräte 32 bis 39, die imstande sind, Alarme unter Verwendung der hier beschriebenen unabhängig meldefähigen Parameter FAILED_ALM, MAINT_ALM und ADVISE_ALM zu melden, kann außerdem einen aktiven Alarmparameter und einen Maskierungsparameter für jeden der unabhängig meldefähigen Alarmparameter aufweisen. Dabei kann jedes der Fieldbus-Geräte 32 bis 39 aufweisen: FAILED_ACTIVE- und FAILED_MASK-Parameter, die dem meldefähigen FAILED_ALM-Parameter entsprechen, MAINT_ACTIVE- und MAINT_MASK-Parameter, die dem meldefähigen MAINT_ALM-Parameter entsprechen, und ADVISE_ACTIVE- und ADVISE_MASK-Parameter, die dem meldefähigen ADVISE_ALM-Parameter entsprechen. Die Maskierungs- und aktiven Parameter werden bevorzugt, aber nicht notwendigerweise, implementiert unter Verwendung eines vorzeichenlosen 32-Bit-Datenformats oder -typs. Natürlich kann statt dessen jedes andere geeignete Datenformat bzw. jeder Datentyp verwendet werden.
Jedes der 32 Bits in den Maskierungs- und aktiven Parametern entspricht speziell einem Zustand innerhalb seines entsprechenden meldefähigen Alarmparameters (d. h. FAILED_ALM, MAINT_ALM und ADVISE_ALM), die bei der Konfigurierung gesetzt oder rückgesetzt werden, um die Fähigkeit eines Geräts zum Melden von Alarmen als Reaktion auf die Detektion von Zuständen, die den Parametern FAILED_ALM, MAINT_ALM und ADVISE_ALM oder Alarmen für dieses Gerät zugeordnet sind, zu aktivieren oder zu deaktivieren. Auf diese Weise kann ein Systemanwender oder -bediener diejenigen Zustände selektiv aktivieren oder deaktivieren, für die jedes Gerät eine Fieldbus-Warnmeldung oder -Alarmmeldung erzeugt. Natürlich kann ein Systemanwender oder -bediener so viele oder so wenige Gerätezustände wie gewünscht aktivieren oder deaktivieren.
Wenn im Betrieb ein Fieldbus-Gerät einen Zustand detektiert, kann ein diesem detektierten Zustand entsprechendes Bit in einen entsprechenden aktiven Parameter gesetzt werden. Wenn beispielsweise ein Fieldbus-Gerät einen ausgefallenen Sensor detektiert, kann ein Bit, das diesem Zustand innerhalb des FAILED_ACTIVE-Parameters für einen Wandlerblock innerhalb dieses Geräts entspricht, gesetzt oder rückgesetzt werden, um den Sensorausfall zu bezeichnen. Alle zusätzlichen Gerätezustände, die detektiert werden (und die nicht quittiert, aufgehoben oder gelöscht worden sind) oder die zu irgendeinem Zeitpunkt detektiert werden, können ebenfalls zur Folge haben, daß Bits innerhalb des aktiven Parameters gesetzt oder rückgesetzt werden, um das Vorhandensein dieser zusätzlichen Zustände zu bezeichnen. Wie noch im einzelnen erörtert wird, können aber Zustände, die nach einem gemeldeten Zustand (d. h. einem, für den eine Fieldbus-Alarmmeldung an den Systembediener gesendet wurde) detektiert werden, der noch nicht quittiert worden ist, erst dann gemeldet werden, wenn dieser gemeldete Zustand vom Systemanwender oder -bediener quittiert, aufgehoben oder anderweitig gelöscht worden ist. Das Fieldbus-Gerät kann dann den FAILED_MASK-Parameter für den Wandlerblock verwenden, um die diesem Block zugeordneten Gerätezustände zu filtern, für welche der Anwender oder Systembediener keine Alarme oder Warnungen empfangen möchte. Zum Zeitpunkt der Konfigurierung kann der Systemanwender oder -bediener definieren, welche Bits in dem FAILED_MASK-Parameter gesetzt oder rückgesetzt werden, um die gewünschte Filterung zu erzielen. Beispielsweise kann mit dem FAILED_MASK-Parameter und dem FAILED_ACTIVE-Parameter eine logische UND-Verknüpfung durchgeführt werden, um den FAILED_ALM-Parameter so zu generieren, daß er Bits hat, die gesetzt oder rückgesetzt worden sind, um die Anwesenheit von Gerätezuständen zu bezeichnen, die momentan aktiv sind (d. h. detektiert worden sind) und die von dem Maskierungsparameter nicht maskiert worden sind.
Im allgemeinen kann jeder von den unabhängig meldefähigen Alarmparametern FAILED_ALM, MAINT_ALM und ADVISE_ALM Fieldbus-Alarm- oder -warnmeldungen an den Systemanwender oder -bediener melden oder ein Fieldbus-Gerät veranlassen, dies zu tun (für alle detektierten Zustände, die aktiv sind und die nicht maskiert sind), und zwar in der Reihenfolge, in der die Zustände detektiert werden. Mit anderen Worten können detektierte Zustände innerhalb eines bestimmten der unabhängig meldefähigen Alarmparameter für ein bestimmtes Gerät an den Systemanwender oder -bediener in der Reihenfolge gemeldet werden, in der die Zustände detektiert wurden (d. h. auf FIFO-Basis). Selbstverständlich können detektierte Zustände an den Systemanwender oder -bediener unter Verwendung eines anderen Priorisierungs- oder Sequenzierungsmechanismus gesendet werden, falls das gewünscht wird. Beispielsweise können unmaskierte detektierte Zustände in umgekehrter chronologischer Reihenfolge (d. h. auf LIFO-Basis) auf der Grundlage der Art des detektierten Zustands usw. gemeldet werden. Zusätzlich kann ein Fieldbus-Gerät eine Alarmaufhebungsmeldung abgeben, wenn alle einem bestimmten Alarmparameter zugeordneten Alarmmeldungen gelöscht bzw. aufgehoben sind. Wenn ferner ein Maskierungsparameter für einen bestimmten Alarm geändert wird, während ein dem Alarmparameter zugeordneter Zustand aktiv ist, kann das Gerät den Alarm löschen und den Alarm auf der Basis von Änderungen, die an dem Maskierungsparameter vorgenommen wurden, neu bewerten.
Jedes der Fieldbus-Geräte 32 bis 39 kann außerdem Prioritätsparameter FAILED_PRI, MAINT_PRI und ADVISE_PRI für jeden seiner jeweiligen FAILED_ALM-, MAINT_ALM- und ADVISE_ALM-Parameter aufweisen. Diese Prioritätsparameter können implementiert sein unter Verwendung von acht vorzeichenlosen Bitwerten, was 256 mögliche Prioritätsstufen ergibt, und können beispielsweise einen Standardwert von zwei zugeordnet bekommen. Das Setzen der Prioritätsstufe eines Alarms auf null deaktiviert die Meldung dieses Alarms, und das Setzen der Prioritätsstufe auf einen Wert zwischen 1 und 255 erlaubt einem Anwender oder Systembediener die Steuerung der Art und Weise, wie die Alarmverarbeitungssoftware 50 Alarme oder Warnungen auf einer systemweiten Basis managt bzw. verwaltet. Insbesondere können die zahlreichen möglichen Prioritätsstufen genutzt werden, um zu bestimmen, welche Gerätealarme oder -warnungen Vorrecht gegenüber den Alarmen oder Warnungen anderer Geräte haben.
Auf diese Weise kann der Systemanwender oder -bediener vorher definieren, wie das System eine potentiell große Zahl aktiver Alarme managt und verarbeitet.
Jedes der Fieldbus-Geräte 32 bis 39 kann außerdem einen RECOMMENDED_ACTION-Parameter aufweisen, der innerhalb der Gerätebeschreibungsinformation mit Textinformation klassifiziert sein kann, die innerhalb der Workstation 14 gespeichert sein kann. Die Textinformationen, auf die der RECOMMENDED_ACTION-Parameter Bezug nimmt, kann für den Systembediener oder -anwender angezeigt werden, um die Korrektur, Reparatur usw. eines Geräts, das einen Alarm generiert hat, zu unterstützen. In einem Fall, in dem ein gemeldeter Alarm eine Vielzahl von aktiven Zuständen hat, kann die für den Systemanwender oder -bediener angezeigte empfohlene Maßnahme der kritischste oder prioritätshöchste Zustand sein.
Wie oben beschrieben wird, können die verschiedenen Arten von Warnungen und Alarmen, die von den Fieldbus-Geräten 32 bis 39 erzeugt werden, auf der Geräteebene zu einer Vielzahl von unabhängig meldefähigen Alarmparametern (z. B. FAILED_ALM, MAINT_ALM und ADVISE_ALM) klassifiziert werden. Auf diese Weise können Warnungen oder Alarme von einer Vielzahl von Fieldbus-Geräten auf gleichbleibende, logische Weise für einen Systembediener oder -anwender über die Workstation 14 überwacht, verarbeitet und angezeigt werden. Außerdem verhindert innerhalb eines gegebenen Fieldbus-Geräts die unabhängige Natur von unabhängig meldefähigen Alarmparametern, die hier beschrieben werden, daß Warnungen mit minderem Schweregrad die Übermittlung oder Anzeige von Warnungen oder Alarmen mit höherem Schweregrad für den Systembediener oder -anwender maskieren.
Die HART^®-Geräte 28 bis 31 liefern zwar jeweils acht Standard-Statuszustände und eventuell einen oder mehrere gerätespezifische Statuszustände. Aber diese Standard- und gerätespezifischen Statuszustände sind mit den Statuszuständen, die von den Fieldbus-Geräten 32 bis 39 geliefert werden, nicht konform. Insbesondere melden die HART^®-Geräte 28 bis 31 Statuszustände nicht auf eine Weise, die mit den unabhängig meldefähigen Alarmparametern FAILED_ALM, MAINT_ALM und ADVISE_ALM konsistent ist, die hier beschrieben wurden.
Zur Erleichterung der integrierten Überwachung, Verarbeitung und Anzeige von Warnungen oder Alarmen, die den Statuszuständen zugeordnet sind, die von den HART^®-Geräten 28 bis 31 gemeldet werden, und von Warnungen oder Alarmen, die von den Fieldbus-Geräten 32 bis 39 über die hier beschriebenen unabhängig meldefähigen Alarmparameter gemeldet werden, tabellarisiert oder klassifiziert die Alarmverarbeitungssoftware 50 HART^®-konforme Statusinformationen zu Warnungs- oder Alarmkategorien, die mit den unabhängig meldefähigen Alarmparametern FAILED_ALM, MAINT_ALM und ADVISE_ALM konform sind. Nur beispielhaft können die acht HART^®-Geräte-Standardstatuszustände entsprechend der folgenden Tabelle 1 tabellarisiert bzw. klassifiziert werden.
TABELLE 1
Wie die obige Tabelle 1 zeigt, tabellarisiert oder klassifiziert die Alarmverarbeitungssoftware 50 die acht HART^®-Geräte-Standardstatuszustände in die Kategorien FAILED (bzw. Ausfall), MAINTENANCE (bzw. Wartung) und ADVISORY (bzw. empfohlene Maßnahme), was es möglich macht, daß diese HART^®-Standardstatuszustände an den Systembediener oder -anwender gemeinsam mit Fieldbus-Gerätewarnungs- oder -alarminformationen gemeldet und angezeigt werden, und zwar auf eine besser konforme und logische Weise, als das bei bekannten Systemen möglich war.
Es ist allgemein bekannt, daß HART^®-Geräte im Gegensatz zu Fieldbus-Geräten abgefragt werden müssen, um aktuelle Gerätestatuszustände zu gewinnen. Somit können die Alarmverarbeitungssoftware 50, die Steuereinheiten 12 und/oder die E/A-Einrichtung 20A so konfiguriert sein, daß die HART^®-Geräte 28 bis 31 periodisch nach Statusinformationen abgefragt werden. Da jede von einem HART^®-Gerät übermittelte Antwortmeldung die aktuellen Zustände der acht Standardstatuszustände enthält, kann die Alarmverarbeitungssoftware 50 diese Statusinformation auf effiziente Weise gewinnen, indem die Statusinformationen aus Antworten auf Befehle extrahiert werden, die von den Steuereinheiten 12 typischerweise über die E/A-Einrichtung 20A an die HART^®-Geräte 28 bis 31 gesendet werden. Anders ausgedrückt, braucht die Alarmverarbeitungssoftware 50 nur wenige oder keine weiteren Kommunikationszusätze einzuführen, da sie Statusinformationen aus Antworten auf Befehle gewinnt, die im übrigen von den Steuereinheiten 12 periodisch an die HART^®-Geräte 28 bis 31 übermittelt werden, um erforderliche Prozeßsteuerungs- oder -überwachungsaktivitäten auszuführen. Wenn beispielsweise die Steuereinheiten 12 DeltaV-Steuereinheiten sind, werden die HART^®-Befehle #0 und #3 periodisch an die HART^®-Geräte 28 bis 31 übermittelt. Daher kann die Alarmverarbeitungssoftware 50 Standard-HART^®-Statuszustandsinformationen, die den Geräten 28 bis 31 zugeordnet sind, aus den Meldungen extrahieren, die als Antwort auf diese Befehle übermittelt werden. Falls gewünscht, kann natürlich jeder andere Befehl von den Steuereinheiten 12 und der Alarmverarbeitungssoftware 50 verwendet werden, um die HART^®-Geräte 28 bis 31 zu veranlassen, Antwortmeldungen zu senden, welche die Standard-HART^®-Statusinformationen enthalten.
Es ist wohlbekannt, daß Nicht-Standard-HART^®-Statuszustände (d. h. gerätespezifische Statuszustände) erhalten werden können, indem ein HART^®-Befehl #48 an die HART^®-Geräte 28 bis 31 übermittelt wird. Es ist außerdem wohlbekannt, daß das HART^®-Kommunikationsprotokoll angibt, daß gerätespezifische Statusinformationen verfügbar sein können, wenn entweder der Zustand "Gerätefehlfunktion" oder der Zustand "Mehr Zustände verfügbar" wahr ist (d. h. wenn die Bits als logische 1 gesetzt sind). Wenn daher die Alarmverarbeitungssoftware 50 einen wahren Zustand entweder für den "Gerätefehlfunktion"-Statuszustand oder den "Mehr-Zustände-verfügbar"-Zustand für eines der HART^®-Geräte 28 bis 31 detektiert, sendet die Alarmverarbeitungssoftware 50 einen HART^®-Befehl #48 an dieses Gerät. Als Antwort auf den Befehl #48 liefert das abgefragte Gerät genauere Informationen in bezug auf die Art des gerätespezifischen Zustands oder Status. Die Alarmverarbeitungssoftware 50 kann dann alle gerätespezifischen Statuszustände, die als Antwort auf einen Befehl #48 geliefert werden, auf die folgende Weise kategorisieren: (1) Wenn das Bit "Gerätefehlfunktion" gesetzt worden ist, klassifiziert die Alarmverarbeitungssoftware 50 den gerätespezifischen Statuszustand zu der "AUSFALL"-Warnungs- oder -Alarmkategorie, und (2) wenn das Bit "Mehr Zustände verfügbar" gesetzt worden ist, klassifiziert die Alarmverarbeitungssoftware 50 den gerätespezifischen Statuszustand zu der "Empfohlene-Maßnahme"-Warnungs- oder -Alarmkategorie.
Unter Bezugnahme auf 2 wird die Konfiguration einer der Workstations 14, die das Alarmdisplay- und Schnittstellensystem implementiert, im einzelnen erläutert. Wie 2 zeigt, führt die Workstation 14 die Speicherung und Ausführung von Kommunikationssoftware durch, etwa einer Kommunikationsschicht bzw. eines -stapels 62, der mit den Steuereinheiten 12 über die Ethernet-Verbindung 40 kommuniziert, um Signale zu empfangen, die von den Steuereinheiten 12, E/A-Einrichtungen innerhalb der Reihen 20 und 22, den Feldgeräten 25 bis 39 und/oder anderen Workstations übermittelt werden. Die Kommunikationsschicht 62 führt ferner die richtige Formatierung der Meldungen aus, die zu den Steuereinheiten, E/A-Einrichtungen, Feldgeräten 25 bis 39 und anderen Workstations zu senden sind, wie etwa Alarmquittierungsmeldungen oder -signale usw. Die zur Implementierung der Kommunikationsschicht verwendete Kommunikationssoftware kann jede bekannte oder gewünschte Kommunikationssoftware sein, die aktuell beispielsweise mit Ethernet-Kommunikationen verwendet wird. Natürlich ist der Kommunikationsstapel 62 mit anderer Software verbunden, die andere Funktionen ausführt, etwa mit Konfigurationsanwendungen, Diagnose- oder anderen Prozeßanwendungen, Datenbankmanagementanwendungen usw., die in der Workstation 14 ausgeführt werden.
Das Alarmdisplay- und Schnittstellensystem umfaßt eine Alarmverarbeitungseinheit 64, die Alarme und andere Ereignisinformationen von der Kommunikationsschicht 62 in Form von Meldungen empfängt, diese Meldungen, die Alarm- oder andere Ereignisinformationen enthalten, decodiert und die Alarm- oder anderen Ereignisinformationen in einer Datenbank 66 speichern kann. Das Vorderende der Alarmverarbeitungseinheit 64, das als Schnittstelle mit der Kommunikationsschicht 62 und der Datenbank 66 dient, kann ein Alarmempfänger sein. Die Alarmverarbeitungssoftware 50 weist ferner ein Alarmfilter 68 auf, das die Alarmverarbeitungseinheit 64 dazu verwendet zu bestimmen, welche Alarme auf einer Benutzeroberfläche 69 (etwa einer CRT, LCD, LED, einem Plasmadisplay, einem Drucker usw.), die der Workstation 14 zugeordnet ist, angezeigt werden sollen. Die Einstellungen des Filters 68 können in der Datenbank 66 gespeichert sein, und diese Filtereinstellungen können entweder vorkonfiguriert sein und/oder können von einem Anwender auf der Basis der Präferenzen des Anwenders geändert werden. Es versteht sich, daß das Filter 68 und seine Einstellungen von den Maskierungsparametern FAILED_MASK, MAINT_MASK und ADVISE_MASK der Geräteebene, die in Verbindung mit Fieldbus-Geräten gemäß der vorliegenden Beschreibung verwendet werden können, verschieden sind. Das heißt, ein Systemanwender oder -bediener kann spezifische Alarme, die von spezifischen Zuständen in spezifischen Geräten generiert werden, unter Verwendung der Gerätemaskierungsparameter filtern. Alternativ oder zusätzlich kann der Systemanwender oder -bediener gemäß der vorliegenden Beschreibung Arten oder Kategorien von Alarmen, Alarme, die bestimmten Betrieben, Bereichen, Einheiten, Schleifen usw. innerhalb des Prozeßsteuerungssystems zugeordnet sind, unter Verwendung des Filters 68 ausfiltern. Beispielsweise in einem Fall, in dem die Alarmverarbeitungssoftware 50 Warn- oder Alarminformationen verarbeitet, die von einem oder mehreren der HART^®-Geräte 28 bis 31 übermittelt werden, das Alarmfilter 68 verwendet werden, um Warn- oder Alarminformationen auf jede gewünschte Weise selektiv anzuzeigen. Selbstverständlich haben die HART^®-Geräte 28 bis 31 keine internen Alarm- oder Warnungsfiltermechanismen wie etwa die Maskierungsparameter auf Geräteebene, die oben in Verbindung mit den Fieldbus-Geräten 32 bis 39 beschrieben wurden.
Im allgemeinen können die Filtereinstellungen des Alarmfilters 68 die Kategorie und Priorität von Alarmen steuern und können, falls gewünscht, die Reihenfolge der anzuzeigenden Alarme unter Anwendung einer Reihe von verschiedenen Kriterien bestimmen. Die Workstation- und Bediener-Gültigkeitsbeschränkungen haben Einfluß auf das, was ein bestimmter Bediener sehen kann (z. B. welche Alarme an einer bestimmten Workstation angezeigt werden können), und zwar auf der Basis der Bediener-Identifikation und der Workstation, in die der Bediener eingeloggt ist. In diesem Fall kann jeder Workstation eine Operationslizenz zugewiesen sein, und ohne eine Operationslizenz können die Alarminformations- und sämtliche Alarmlisten-/zusammenfassenden Displays leer sein. Das heißt also, die Alarmverarbeitungseinheit 64 zeigt keine aktiven oder unterdrückten Alarme irgendeiner Kategorie (d. h. Prozeß, Hardware oder Gerät). Außerdem sind nur Alarme von einem Betriebsbereich im aktuellen Gültigkeitsumfang (der Bediener erhält gewöhnlich wenigstens einen Sicherheitsschlüssel im Betriebsbereich) verfügbar, um in den Alarmdisplays an dieser Workstation zu erscheinen. Außerdem können nur Alarme von einem Betriebsbereich und einer Betriebseinheit, die bei Verwendung des Betriebsbereichs- oder des (der) Einheitsfilterdisplay(s) (wie noch erläutert wird) nicht abgeschaltet wurde, in dem Alarmdisplay erscheinen. Auf diese Weise verhindert das Filter 68 die Anzeige von Alarmen außerhalb der Workstation- und Bediener-Gültigkeitsbeschränkung und von Alarmen von Betriebsbereichen oder -enheiten, die vom Bediener abgeschaltet worden sind.
Nach Prüfung von Alarmen auf Konformität mit der Workstation- und Bediener-Gültigkeitsbeschränkung filtert das Filter 68 Alarme aus und bestimmt die Anzeigereihenfolge der Alarme, und zwar auf der Basis von Bedienereinstellungen, die beispielsweise folgendes umfassen können: die Alarmkategorie, die Alarmpriorität, den Alarmtyp, den Quittierungsstatus des Alarms, den unterdrückten Status des Alarms, die Alarmzeit, den aktiven Status des Alarms usw. Die empfangenen Alarme, die zu der Alarmverarbeitungssoftware 50 unter Verwendung von Alarmmeldungen (z. B. Fieldbus-Alarmmeldungen) übermittelt werden, können einen Parameter für jeden dieser Werte aufweisen, und das Filter 68 kann Alarme für die Anzeige filtern durch Vergleichen der entsprechenden Parameter der Alarme mit den Filtereinstellungen. Beispielsweise kann der Bediener bezeichnen, welche Kategorien von Alarmen und Alarmprioritätsstufen auf dem Bildschirm angezeigt werden sollen. Falls gewünscht, kann der Bediener eine vorbestimmte Prioritätsstufe für einen Alarm einstellen durch Verschieben der Prioritätsstufe von der vorkonfigurierten Prioritätsstufe für den Alarm, die vom Hersteller vorgegeben wurde. Bei dem DeltaV-System wird für jeden Alarm eine Prioritätsstufe zwischen etwa drei und fünfzehn gewählt, und der Bediener kann diese Prioritätsstufe um jede Anzahl von Stufen verschieben, um eine höhere Priorität zu einer niedrigeren Priorität zu machen oder eine niedrigere Priorität zu einer höheren Priorität zu machen, wenn die Betrachtung durch das Filter 68 erfolgt. Der Bediener kann zwar die Reihenfolge der Anzeige der Alarme, die vom Filter 68 durchgelassen werden, einstellen, die Reihenfolge kann aber auch durch vorkonfigurierte Vorgaben bestimmt werden, um eine gleichbleibende Anzeige unterschiedlicher Arten von Alarmen zu erreichen.
Jedenfalls kann der Bediener die Art und Weise, wie Alarme angezeigt werden, personalisieren auf der Basis der Kategorien oder Arten von Alarmen, die den Anwender am meisten interessieren, wobei es sich sämtlich um eine Kategorie oder eine Art von Alarm wie Prozeßalarme, Gerätealarme, Hardwarealarme oder um eine Kombination von zwei oder mehr Alarmkategorien handeln kann. Ferner kann der Anwender die Anzeige von Alarmen so konfigurieren, daß Alarme oder Warnungen mit unterschiedlichen Schweregraden angezeigt oder nicht angezeigt werden. Beispielsweise möchte der Anwender vielleicht nur Alarme oder Warnungen ansehen, die in FAILED_ALM- und MAINT_ALM-Parametern enthalten sind, und möchte Alarme oder Warnungen, die in ADVISE_ALM-Parametern enthalten sind, nicht betrachten. Allgemein gesagt, kann der Systembediener oder -anwender die Anzeige von Alarmen konfigurieren, um Warnungen oder Alarme zu sehen, die einem Geräteausfall, einem Gerät, das Wartung benötigt, und/oder einer empfohlenen Maßnahme im Zusammenhang mit einem Gerät zugeordnet sind. Der Anwender kann auch darüber bestimmen, wie die Alarme präsentiert und die Informationen in bezug auf die Alarme gezeigt werden. Auf diese Weise ermöglicht es die Alarmverarbeitungssoftware 50 einer einzelnen Person, die Aufgaben eines Bedieners, eines Technikers oder einer Wartungsperson und eines Ingenieurs auszuführen, indem die Person die Alarme auf demselben Bildschirm betrachtet und darauf reagiert, was normalerweise durch verschiedenes Personal an verschiedenen Stellen in einem Betrieb geschehen würde. Alternativ kann zu verschiedenen Zeiten im selben System eine Serviceperson das gleiche System nutzen, um nur Wartungsalarme anzusehen, während gleichzeitig ein Ingenieur andere Arten von Alarmen ansehen kann, welche die Geräte beeinflussen. Auf diese Weise kann die Alarmverarbeitungssoftware 50 von verschiedenen Arten von Menschen gleichzeitig an verschiedene Workstations genutzt werden, um unterschiedliche Aspekte der Alarme zu sehen, welche dem Prozeßsteuerungssystem 10 zugeordnet sind. Ferner ist es bei Verwendung der Alarmverarbeitungssoftware 50 relativ einfach, daß eine Person Alarmfunktionen, die sie betrachtet und quittiert, an eine andere Person übergibt, die möglicherweise dieselbe Software hat. Alternativ oder zusätzlich kann eine Person ihr Filter so einstellen, daß Alarme akzeptiert werden, die normalerweise von einer anderen Person angesehen werden. Auf diese Weise kann eine Person Mittagspause machen und die Alarmbetrachtungsfunktion an andere Personen an verschiedenen Workstations übertragen, indem einige Filtereinstellungen neu eingestellt werden. Nach Rückkehr aus der Mittagspause kann die Person wieder die Kontrolle über diese Funktionen übernehmen. Wenn ferner die Menge an Alarminformationen zu groß wird, um von einer Person gehandhabt zu werden, kann diese Person die Bürde für bestimmte Alarmkategorien wie Prozeßalarme, Gerätealarme oder Hardwarealarme abgeben oder verteilen, so daß diese Alarme von anderen Personen an andern Endgeräten gehandhabt werden können.
Nachdem die Alarmverarbeitungseinheit 64 das Filter 68 verwendet hat, um zu bestimmen, welche Alarme (d. h. nichtmaskierte Zustände) für den Anwender über das Display 69 anzuzeigen sind und in welcher Reihenfolge die Anzeige erfolgen soll, übermittelt die Alarmverarbeitungseinheit 64 diese Informationen an eine Benutzeroberfläche 70, die ein gewünschtes oder ein Standardbetriebssystem verwendet, um Alarminformationen auf dem Alarmdisplay 69 auf jede gewünschte Weise anzuzeigen. Selbstverständlich gewinnt die Benutzeroberfläche 70 andere Informationen, die sie benötigt, wie Informationen über das Layout oder die Konfiguration des Prozeßsteuerungssystems 10, die Werte von Parametern oder Signalen innerhalb dieses Systems usw., von der Datenbank 66 oder aus anderen Kommunikationssignalen, die von dem Prozeßsteuerungssystem 10 über die Kommunikationsschicht 62 empfangen werden. Außerdem empfängt die Benutzeroberfläche 70 Befehle vom Anwender, der beispielsweise mehr Informationen in bezug auf bestimmte Alarme, Änderungen an Alarm- oder Filtereinstellungen, neue Alarmanzeigen usw. anfordert, und liefert diese Informationen an die Alarmverarbeitungseinheit 64, die dann die angeforderten Maßnahmen durchführt, die Datenbank 66 nach der Alarminformation absucht usw., um für den Anwender über das Display 69 eine neue Alarmansicht bereitzustellen.
Allgemein gesagt, gibt es verschiedene Kategorien von Alarmen, die erzeugt und auf dem Display 69 angezeigt werden können, z. B. Prozeßalarme, Gerätealarme und Hardwarealarme. Prozeßalarme, die bekannt sind und typischerweise von Funktionsblöcken oder -modulen innerhalb einer Prozeßsteuerungsroutine erzeugt werden, die an einer Steuereinheit oder einem Feldgerät abläuft, werden bisher an eine Bedieneroberfläche übermittelt und angezeigt. Prozeßalarme bezeichnen im allgemeinen ein Problem in bezug auf die Funktionsweise der Prozeßsteuerungssoftware, d. h. ein Problem mit der Prozeßsteuerungsroutine selbst wie etwa außerhalb eines Bereichs liegende Meßwerte, abnormale Abweichungen zwischen Prozeßparametern und Sollwerten usw. Prozeßalarme sind typischerweise vom Anwender als Komponenten von Prozeßsteuerungsmodulen konfiguriert und können in der Konfigurationsinformation, die auf der Benutzeroberfläche erscheint, als einem Modulnamen zugeordnet auftreten. Manche Arten von Prozeßalarmen umfassen schlechte Ein-/Ausgaben, außerhalb des Bereichs liegende Meßwerte, überschrittene Grenzwerte usw. Da Prozeßalarme auf dem Gebiet wohlbekannt sind, werden sie hier nicht im einzelnen erläutert.
Gerätealarme wie etwa die Alarme, die dem Geräteausfall, der Gerätewartung und/oder einer empfohlenen Maßnahme zugeordnet sind, sind Alarme, die dem Betrieb der Feldgeräte innerhalb des Prozesses zugeordnet sind und von Software (z. B. der Software 53 in 1) innerhalb der Feldgeräte oder anderer Einrichtungen, die mit dem Prozeßsteuerungssystem 10 verbunden sind, detektiert werden, um ein Problem oder einen Fehler beim Betrieb eines Feldgeräts zu bezeichnen. Gerätealarme können in der Benutzeroberfläche des hier beschriebenen Systems in Zuordnung zu einem bestimmten Gerät erscheinen. Gerätealarme können beispielsweise anzeigen, daß der Druck in einem Ventil to hoch oder zu niedrig für einen ordnungsgemäßen Ventilbetrieb ist, daß der Motorstrom in dem Ventil zu hoch oder zu niedrig ist, daß die Spannungspegel eines Geräts nicht synchronisiert sind, daß ein Ventilkegel in einem Ventil klemmt, daß das Gerät nicht richtig kommuniziert, daß das Gerät planmäßige Wartung benötigt, weil beispielsweise ein bestimmter Zeitraum verstrichen ist oder ein Ventilelement des Geräts seit der letzten Wartung eine bestimmte Strecke zurückgelegt hat, usw. Gerätealarme können auf jede gewünschte Weise erzeugt werden einschließlich der Verwendung von geschützter oder nichtgeschützter Software, die sich in einem Gerät selbst oder in anderen Einrichtungen befindet, die mit dem Gerät verbunden sind, für das der Alarm erzeugt wird, um spezifische Probleme in Verbindung mit dem Gerät zu erkennen und zu detektieren und in bezug darauf einen Alarm zu erzeugen.
Wie vorstehend ausgeführt wurde, kann es viele verschiedene Arten von Gerätealarmen geben einschließlich z. B. Ausfallalarme, die anzeigen, daß in einem Gerät ein Ausfallzustand oder ein demnächst zu erwartender Ausfallzustand existiert, Wartungsalarme, die anzeigen, daß irgendeine Wartung durchgeführt werden sollte, Kommunikationsalarme, die anzeigen, daß ein Gerät nicht ordnungsgemäß oder überhaupt nicht kommuniziert, Alarme in bezug auf empfohlene Maßnahmen, usw. Ein Ausfallalarm (z. B. "ausgefallen") bedeutet, daß ein Gerät einen oder mehrere Zustände detektiert hat, die anzeigen, daß es eine kritische Funktion nicht ausführen kann und daher sofort Wartung benötigt. Immer, wenn der Ausfallalarmzustand wahr ist, wird die Integrität des Geräts als schlecht betrachtet, was sich bis zu der Steuereinheit hinaus fortsetzt und bewirkt, daß die Integrität des Steuereinheitsknotens, mit dem das Gerät verbunden ist, schlecht ist. Andererseits bedeutet ein Wartungsalarm, daß ein Gerät zwar imstande ist, kritische Funktionen auszuführen, aber einen oder mehrere detektierte Zustände hat, die zu einem Ausfall führen können, wenn nicht gehandel6t wird, und daß das Gerät deshalb bald einer Wartung unterzogen werden sollte. Ein Kommunikationsalarm (z. B. "kommuniziert nicht") wird aktiv, wenn ein Gerät aufhört zu kommunizieren. Immer, wenn der Kommuniziert-nicht-Alarmzustand wahr ist, wird die Integrität des Geräts als schlecht betrachtet, was sich bis zu der Steuereinheit hinaus fortsetzt und bewirkt, daß die Integrität des Steuereinheitsknotens, mit dem das Gerät verbunden ist, schlecht ist. Ein Alarm bezüglich einer empfohlenen Maßnahme bedeutet, daß ein Gerät Zustände detektiert hat, die nicht in die anderen Alarmkategorien fallen. Gewöhnlich ist ein Empfohlene-Maßnahme-Alarm ein Alarm, der von einzelnen Geräten abgegeben wird und dem Gerätetyp spezifisch zugeordnet ist, etwa einem Strömungsmesser, der die Veränderlichkeit des Durchflußsignals verfolgt. In diesem Fall kann das Gerät erkennen, daß eine Veränderlichkeit in einem dem Gerät zugeordneten Signal zu hoch oder zu niedrig ist, was bedeutet, daß etwas Ungewöhnliches geschehen ist und untersucht werden muß. In Abhängigkeit von dem Gerät können Empfohlene-Maßnahme-Alarme mehr oder weniger dringende Aufmerksamkeit als Wartungsalarme erfordern, und daher können Anwender die Priorität des Empfohlene-Maßnahme-Alarms niedriger als diejenige des Wartungsalarms einstellen. Selbstverständlich können Ausfall-, Wartungs- und Empfohlene-Maßnahme-Alarme nicht von jedem Gerät unterstützt werden, und anstelle der Ausfall-, Wartungs- und Empfohlene-Maßnahme-Alarme kann ein einziger, alle umfassender Alarm wie etwa ein "Abnormal"-Alarm für generische Geräte verwendet werden, was zu insgesamt zwei Gesamtalarmen führt, d. h. "kommuniziert nicht" und "abnormal". Selbstverständlich. könnten andere Arten von Gerätealarmen erschaffen oder verwendet werden anstelle der bzw. zusätzlich zu den vorstehend erläuterten Alarmen.
Bei einer Ausführungsform kann einem Anwender eine integrierte Alarminformation auf einem Display in Form eines Banners bzw. einer Leiste verfügbar gemacht werden, beispielsweise an einem Rand eines Displaybildschirms. Gemäß 3 befindet sich eine Alarmleiste 73 am Fuß eines Bildschirms 71. Die Alarmleiste 73 umfaßt eine erste Zeile, die Bedeutungen von verschiedenen Alarmen zeigt, die von dem Prozeßsteuerungssystem 10 erzeugt worden und durch das Filter 68 auf das Display 69 gelangt sind. Wenigstens einer der Alarme, die in der Alarmleiste 73 angezeigt sind, kann dem Bereich des Prozeßsteuerungssystems 10 zugeordnet sein, das im Hauptteil des Bildschirms 71 abgebildet ist. Die speziellen Alarme, die in der Alarmleiste 73 angezeigt sind, und die Reihenfolge dieser Alarme sind in Übereinstimmung mit der Konfiguration der Maskierungs- und Prioritätsparameter und den Filtereinstellungen des Filters 68 bestimmt. Allgemein gesagt, werden die Alarme mit der höchsten Priorität, die weder quittiert noch unterdrückt noch maskiert sind, zuerst angezeigt, als nächstes werden die Alarme mit der nächstfolgenden höchsten Priorität angezeigt, usw. In dem beispielhaften Bildschirm vo 3 ist der Alarm 74 mit der höchsten Priorität ein Prozeßalarm, der in der Figur einer PID-101-Steuerroutine zugeordnet ist. Der Alarm 74 wird rot angezeigt, um zu veranschaulichen, daß seine Priorität kritisch ist. In der zweiten Zeile der Alarmleiste 73 zeigt ein Alarminformationsfeld 76 Alarminformationen, die dem Alarm in der Alarmleiste 73 zugeordnet sind, der momentan gewählt ist. In dem Beispiel von 3, in dem der Alarm 74 gewählt ist, zeigt das Alarminformationsfeld 76, daß der Alarm 74 am Freitag um 12:52:19 Uhr erzeugt wurde, der "Behälter-16-Pegelsteuerung" zugeordnet ist, eine Bezeichnung bzw. einen Namen PID101/HI_HI_ALM hat, eine hohe Hoch-Priorität hat und ein kritischer Alarm ist. Wenn der Alarm 74 blinkt, ist der Alarm 74 nicht quittiert worden, wogegen eine konstante (nicht-blinkende) Alarmanzeige in der Alarmleiste 73 zeigt, daß der Alarm 74 von einem Bediener oder Anwender quittiert worden ist. Selbstverständlich könnten innerhalb des Alarminformationsfelds 76 andere Arten von Alarminformationen angezeigt werden.
Außerdem können die anderen Alarmanzeigen in der Alarmleiste 73 wie etwa die Alarmanzeige 78 gelb, dunkelrot oder jede andere Farbe sein, um andere Schweregrade oder Prioritäten zu bezeichnen, die dem Alarm zugeordnet sind. Wenn ein anderer Alarm wie etwa der Alarm 78, 80, 81 oder 82 gewählt wird, kann diesen Alarm betreffende Alarminformation in dem Alarminformationsfeld 76 angezeigt werden. Beim Betrachten eines Alarms in der Alarmleiste 73 kann der Anwender die Alarme quittieren und Wartungs- oder Technikpersonal aufrufen, um die geeigneten Maßnahmen zur Korrektur des Zustands, der den Alarm ausgelöst hat, zu ergreifen, oder könnte alternativ andere Schritte unternehmen wie etwa das Neueinstellen bestimmter Sollwerte, um den Alarmzustand zu mildern.
Wie oben gesagt ist, wird durch die Wahl eines der Alarme in der Alarmleiste 73 wie etwa des Alarms 74 eine Primärsteueranzeige für diesen Alarm auf dem Bildschirm 71 präsentiert. Wie 3 zeigt, umfaßt insbesondere der Hauptkörper des Bildschirms 71 eine Primärsteueranzeige oder -abbildung von relevanter Hardware, die einem bestimmten Alarm (einem gewählten Alarm) innerhalb des Prozeßsteuerungssystems 10 zugeordnet ist. In dem Beispiel von 3 umfaßt die Hardware drei Behälter mit verschiedenen daran angebrachten Sensoren, die sämtlich mit verschiedenen Ventilen und Fluidströmungsleitungen miteinander verbunden sind. Diese Darstellung der Hardware ist eine Darstellung der Einrichtungen innerhalb eines Bereichs des Prozeßsteuerungssystems 10 und liefert Informationen über den Betrieb einiger der Einrichtungen wie etwa Werte oder Parameter, die den Behältern, Sensoren usw. zugeordnet sind. Natürlich kann ein Teil dieser Informationen durch Konfigurationsinformationen in der Datenbank 66 und Signale von den Sensoren im Prozeßsteuerungssystem über die Steuereinheiten 12 und die Ethernet-Verbindung 40 geliefert werden. In diesem Fall werden diese Informationen durch die Kommunikationsschicht 62 übermittelt und auf der Anwenderoberfläche 70 über jede bekannte oder gewünschte Software bereitgestellt.
Die 4 bis 6 sind beispielhafte Darstellungen von Grafikdisplays, die zum Gebrauch durch einen Systemanwender oder Bediener über die Alarmdisplay- und Schnittstellensoftware 50 bereitgestellt werden können. 4 zeigt ein beispielhaftes Popup-Fenster 100, das von der Alarmverarbeitungssoftware als Reaktion darauf angezeigt werden kann, daß der Systemanwender oder Bediener einen der Alarme aus der Alarmleiste 73 in 3 wählt. Wenn der Anwender dabei (z. B. durch Doppelklick) den Alarm 80 wählt, der einem Strömungsventil FV 101 zugeordnet ist, kann das Popup-Fenster 100 angezeigt werden. Wie 4 zeigt, umfaßt das Popup-Fenster 100 Alarm- oder Warnleisten 102, von denen eine oder mehrere hervorgehoben sein können, um einen aktiven Zustand innerhalb von einem oder mehreren der unabhängig meldefähigen Alarmparameter (d. h. FAILED_ALM, MAINT_ALM und ADVISE_ALM) für eines oder mehrere der Fieldbus-Geräte 32 bis 39 zu bezeichnen, das in diesem Beispiel das Strömungsventil FV 101 ist. Außerdem können eine oder mehrere der Warnleisten einen aktiven Zustand bezeichnen, der einem Geräteausfall, einer Wartungswarnung oder einer Empfohlene-Maßnahme-Warnung von einem oder mehreren der HART^®-Geräte 28 bis 31 zugeordnet ist. Selbstverständlich kann die "Ausfall"-Alarmleiste infolge eines aktiven Zustands innerhalb des FAILED_ALM-Parameters hervorgehoben sein, die "Benötigtbald-Wartung"-Leiste kann infolge eines aktiven Zustands innerhalb des MAINT_ALM-Parameters hervorgehoben sein, und die "Empfohlene-Maßnahme"-Leiste kann infolge eines aktiven Zustands innerhalb des "ADVISE_ALM"-Parameters hervorgehoben sein. Außerdem können, wie 4 zeigt, die Warn- oder Alarmleisten 102 eine "Kommunikationsausfall"-Leiste umfassen, um das Vorhandensein eines Kommunikationsausfalls in einem der Feldgeräte 25 bis 39 zu bezeichnen.
Der Systemanwender oder Bediener kann eine Quittungstaste 104 wählen, um einen hervorgehobenen Alarm bzw. eine solche Warnung in dem Fenster 100 zu quittieren, oder alternativ kann er eines der Löschkästchen 106 wählen, um einen oder mehrere aktive Alarme oder Warnungen zu löschen. Falls gewünscht, kann der Anwender oder Systembediener ferner eine "Detail"-Taste 108 wählen, um andere Popup-Fenster aufzurufen, wie noch im einzelnen erläutert wird, die zusätzliche Informationen hinsichtlich derjenigen Alarme liefern, die momentan in dem Fenster 100 aktiv sind.
4 zeigt auch ein anderes Popup-Fenster 110 mit stärker detaillierter Statusinformation, die dem Strömungsventil FV 101 zugeordnet ist. Das Statusfenster 110 kann aus dem Fenster 100 aufgerufen werden durch Wählen eines Ikons 112, der Detailtaste 108, eines hervorgehobenen der Alarm- oder Warnfelder 106 oder auf jede andere gewünschte Weise. Jedenfalls kann das Statusfenster 110 Felder 114, 116 und 118 umfassen, die jeweils einem der unabhängig meldefähigen Alarme oder Warnungen entsprechen. Bei diesem Beispiel ist das "Ausfall"-Feld hervorgehoben, weil das Strömungsventil FV 101 momentan einen aktiven Zustand in einem FAILED_ALM-Parameter des Ventils FV 101 hat. Das Statusfenster 110 umfaßt auch eine Liste möglicher Zustände 120, die der Meldung eines Ausfalls innerhalb des Strömungsventils FV 101 zugeordnet sind. Es ist wichtig zu erkennen, daß zwar bei diesem Beispiel nur fünf Zustände gezeigt sind, jedoch nach Wunsch mehr oder weniger als fünf Zustände erhalten werden können. Jeder der in dem Fenster 110 gezeigten möglichen Zustände 120 entspricht speziell den unmaskierten aktiven Zuständen, die von dem FAILED_ALM- oder Geräteausfall-Parameter für dieses Gerät gemeldet werden können. Außerdem zeigt das Fenster 110 ein Empfohlene-Maßnahme-Feld 122, das die Textinformationen zeigt, die dem RECOMMENDED_ACTION-Parameter des Geräts zugeordnet sind und in der Gerätebeschreibung des Geräts gespeichert sein können. Zusätzlich weist das Fenster 110 eine Hilfetaste 124 auf, die bei Wahl durch den Systemanwender oder Bediener ein anderes Popup-Fenster (etwa das Hilfefenster 144 in 6, das nachstehend erörtert wird) aufrufen kann, das Textinformationen enthält, die dem Anwender oder Systembediener das Entstören, die Reparatur usw. des Geräts erleichtern, das den Alarm oder die Warnung erzeugt hat, die gerade angesehen wird.
5 ist eine weitere beispielhafte Darstellung eines Popup-Fensters 130, das Statusinformationen liefert, die einem Druckmeßwertgeber PT 101 zugeordnet sind. Das allgemeine Format des in 5 gezeigten Fensters 130 ist identisch mit dem in 4 gezeigten mit der Ausnahme, daß das Fenster 130 mögliche Zustände 132 aufweist, wobei es sich um Zustände handelt, die den Druckmeßwertgeber PT 101 veranlassen können, eine Wartungswarnung bzw. einen Wartungsalarm zu erzeugen. Es ist zu beachten, daß bei diesem Beispiel die Wartungstaste 116 hervorgehoben oder aktiv ist, was zeigt, daß ein nichtmaskierter Zustand, der dem MAINT_ALM-Parameter oder Gerät-braucht-Wartung-Parameter für den Druckmeßwertgeber PT 101 zugeordnet ist, momentan aktiv ist.
6 ist noch eine weitere beispielhafte Darstellung eines Popup-Fensters 140, das Statusinformationen liefert, die einem Strömungsmeßwertgeber FT 101 zugeordnet sind, und eine Gruppe von möglichen Zuständen 142 umfaßt, die ähnlich oder identisch mit den Zuständen sind, die mittels der MAINT_ALM- oder Gerät-braucht-Wartung-Parameter für den Strömungsmeßwertgeber FT 101 gemeldet werden können. 6 zeigt auch das Popup-Hilfefenster 144, das durch Wählen der Hilfetaste 124 aufgerufen werden kann. Wie 6 zeigt, umfaßt das Hilfefenster 144 detaillierte Textinformationen, die von der Gerätebeschreibung des Strömungsmeßwertgebes FT 101 geliefert und zu der Workstation 14 über die Alarmdisplaysoftware 50 zur Anzeige übermittelt werden kann.
Die Alarmdisplay- und Schnittstellensoftware 50 wurde zwar unter Bezugnahme auf ihre Verwendung im Zusammenhang mit Fieldbus-, HART^®- und Standard-4-20-mA-Geräten beschrieben, sie kann aber unter Verwendung jedes anderen externen Prozeßsteuerungs-Kommunikationsprotokolls implementiert werden und mit jeder anderen Art von Steuereinheits-Software verwendet werden. Die hier beschriebene Alarmdisplay- und Schnittstellensoftware 50 ist zwar bevorzugt als Software implementiert, sie kann aber auch in Hardware, Firmware usw. implementiert sein und sie kann mit jedem anderen Prozessor implementiert sein, der dem Prozeßsteuerungssystem 10 zugeordnet ist. Die hier beschriebene Routine 50 kann also in einem Standard-Universalprozessor oder unter Verwendung von speziell ausgelegter Hardware oder Firmware nach Wunsch implementiert werden. Wenn sie in Software implementiert ist, kann die Softwareroutine in jedem computerlesbaren Speicher wie etwa auf einer Magnetplatte, einer Laserplatte oder einem anderen Speichermedium, in einem RAM oder ROM eines Computers oder Prozessors usw. gespeichert sein. Ebenso kann diese Software an einen Anwender oder ein Prozeßsteuerungssystem mittels jeder bekannten oder gewünschten Liefermethode geliefert werden, beispielsweise auf einer computerlesbaren Platte oder einem anderen transportfähigen Computerspeichermechanismus oder über einen Nachrichtenkanal wie etwa eine Telefonleitung, das Internet usw. (die als gleich oder austauschbar mit der Bereitstellung dieser Software mittels eines transportierbaren Speichermediums angesehen werden).
Die hier beschriebenen unabhängig meldefähigen Alarme wurden zwar als drei Schweregrade oder Alarmarten beschrieben (d. h. Geräteausfall, Gerätewartung und empfohlene Maßnahme), aber selbstverständlich versteht es sich, daß statt dessen zwei Schweregrade oder mehr als drei Schweregrade anwendbar sind, ohne vom Umfang der Erfindung abzuweichen.

Claims

Verfahren zum Erzeugen einer HART®-Alarmmeldung in einem Prozesssteuerungssystem (10), wobei das Verfahren die folgenden Schritte aufweist: Spezifisches Zuordnen einer Vielzahl von Gerätezuständen für ein HART®-Gerät (28–31) zu einer Vielzahl von Geräte-(28–31)-Statuszuständen, von denen jeder einen anderen Schweregrad bezeichnet; Detektieren eines Zustands, welcher dem HART^®-Gerät (28–31) zugeordnet ist; Klassifizieren des Zustands, welcher dem HART^®-Gerät (28–31) zugeordnet ist, zu einem der Vielzahl von Gerätestatuszuständen; und Erzeugen der HART^®-Alarmmeldung derart, dass diese Informationen umfasst, die dem Zustand, welcher dem HART^®-Gerät (28–31) zugeordnet ist, und dem einen der Vielzahl von Gerätestatuszuständen zugeordnet sind.
Verfahren nach Anspruch 1, wobei der Schritt des spezifischen Zuordnens der Vielzahl von Gerätezuständen für das HART^®-Gerät (28–31) zu der Vielzahl von Gerätestatuszuständen den folgenden Schritt aufweist: Spezifisches Zuordnen der Vielzahl von Geräteszuständen für das HART^®-Gerät (28–31) entweder zu einem Statuszustand, der einem Ausfall des HART^®-Gerätes (28–31) zugeordnet ist, das einem Statuszustand, welcher der Wartung des HART^®-Gerätes (28–31) zugeordnet ist, oder einem Statuszustand, der einer empfehlenswerten Maßnahme in Verbindung mit dem HART^®-Gerät (28–31) zugeordnet ist.
Verfahren nach Anspruch 1 oder 2, wobei der Schritt des Detektierens des Zustands, welcher dem HART^®-Gerät (28–31) zugeordnet ist, den folgenden Schritt aufweist: Detektieren entweder eines Zustands, der einem Ausfall des HART^®-Gerätes (28–31) zugeordnet ist, oder eines Zustands, welcher der Wartung des HART^®-Gerätes (28–31) zugeordnet ist, oder eines Zustands, der einer empfehlenswerten Maßnahme in Verbindung mit dem HART^®-Gerät (28–31) zugeordnet ist.
Verfahren nach den Ansprüchen 1 bis 3, wobei der Schritt des Klassifizierens des des HART^®-Gerätes (28–31) zugeordneten Zustands zu einem der Vielzahl von Gerätestatuszuständen den folgenden Schritt aufweist: Verwenden einer Tabelle, die HART^®-Standardstatuszustände zu mindestens zwei Statuszuständen spezifisch klassifiziert, die aus der Gruppe ausgewählt sind, die aus Ausfall-, Wartungs- und Empfehlenswerte-Maßnahme-Statuszuständen besteht.
Verfahren nach Anspruch 4, das ferner den folgenden Schritt aufweist: Verwenden einer Tabelle, um einen gerätespezifischen Zustand zu einem von einem Ausfall-Statuszustand, einem Wartungs-Statuszustand und einem Empfehlenswerte-Maßnahme-Statuszustand zu klassifizieren.
Verfahren nach einem der Ansprüche 1 bis 5, wobei der Schritt des Klassifizierens des dem HART^®-Gerät (28–31) zugeordneten Zustands zu dem einen von der Vielzahl von Gerätestatuszuständen den folgenden Schritt aufweist: Zuordnen eines "Mehr Zustände verfügbar"-Zustands zu einem Empfehlenswerte-Maßnahme-Statuszustand.
Verfahren nach einem der Ansprüche 1 bis 6, das ferner den folgenden Schritt aufweist: Anzeigen des detektierten Zustands gemeinsam mit einer Bezeichnung des einen der Vielzahl von Gerätestatuszuständen.
System zur Verwendung in einem Prozesssteuerungssystem (10), das einen Prozessor aufweist, der eine HART^®-Alarmmeldung erzeugt, wobei das System Folgendes umfasst: einen computerlesbaren Datenträger; eine erste Routine, die auf dem computerlesbaren Datenträger gespeichert und ausgebildet ist, um von dem Prozessor ausgeführt zu werden, und die eine Vielzahl von Gerätezuständen für ein HART^®-Gerät (28–31) einer Vielzahl von Gerätestatuszuständen spezifisch zuordnet, von denen jeder einen anderen Schweregrad bezeichnet; eine zweite Routine, die auf dem computerlesbaren Datenträger gespeichert und ausgebildet ist, um von dem Prozessor ausgeführt zu werden, und die einen dem HART^®-Gerät (28–31) zugeordneten Zustand detektiert; eine dritte Routine, die auf dem computerlesbaren Datenträger gespeichert und ausgebildet ist, um von dem Prozessor ausgeführt zu werden, und die den dem HART^®-Gerät (28–31) zugeordneten Zustand zu einem von der Vielzahl von Gerätestatuszuständen klassifiziert; und eine vierte Routine, die auf dem computerlesbaren Datenträger gespeichert und ausgebildet ist, um von dem Prozessor ausgeführt zu werden, und welche die HART^®-Alarmmeldung derart erzeugt, dass diese Informationen umfasst, die dem Zustand, welcher dem HART^®-Gerät (28–31) zugeordnet ist, und dem einen der Vielzahl von Gerätestatuszuständen zugeordnet sind.
System nach Anspruch 8, wobei die erste Routine ferner ausgebildet ist, um die Vielzahl von Gerätezuständen für das HART^®-Gerät (28–31) spezifisch zuzuordnen: entweder einem Statuszustand, der einem Ausfall des HART^®-Gerätes (28–31) zugeordnet ist, oder einem Statuszustand, welcher der Wartung des HART^®-Gerätes (28–31) zugeordnet ist, oder einem Status-zustand, der einer empfehlenswerten Maßnahme in Verbindung mit dem HART^®-Gerät (28–31) zugeordnet ist.
System nach Anspruch 8 oder 9, wobei die zweite Routine ferner ausgebildet ist, um zu detektieren: entweder einen Zustand, der einem Ausfall des HART^®-Gerätes (28–31) zugeordnet ist, oder einen Zustand, welcher der Wartung des HART^®-Gerätes (28–31) zugeordnet ist, oder einen Zustand, der einer empfehlenswerten Maßnahme in Verbindung mit dem HART^®-Gerät (28–31) zugeordnet ist.
System nach einem der Ansprüche 8 bis 10, wobei die dritte Routine ferner ausgebildet ist, um eine Tabelle zu verwenden, die HART^®-Standardstatus-zustände zu mindestens zwei Statuszuständen spezifisch klassifiziert, die aus der Gruppe ausgewählt sind, die aus Ausfall-, Wartungs- und Empfehlenswerte-Maßnahme-Statuszuständen besteht.
System nach Anspruch 11, wobei die dritte Routine ferner ausgebildet ist, um die Tabelle zu verwenden, um einen für das Gerät (28–31) spezifischen Zustand zu einem Ausfall-Statuszustand, einem Wartungs-Statuszustand und einem Empfehlenswerte-Maßnahme-Statuszustand zu klassifizieren.
System nach einem der Ansprüche 8 bis 12, wobei die dritte Routine ferner ausgebildet ist, um einen "Mehr Zustände verfügbar"-Zustand einem Empfehlenswerte-Maßnahme-Statuszustand zuzuordnen.
Verfahren nach Anspruch 1, das ferner den folgenden Schritt aufweist: Melden des detektierten Zustands über ein Benutzeroberflächendisplay unter Verwendung entweder eines Geräteausfall-, oder eines Gerätewartungs- oder eines Empfehlenswerte-Maßnahme-Statuszustandes.
Verfahren nach Anspruch 1, wobei der Schritt des Detektierens des dem HART^®-Gerät (28–31) zugeordneten Zustands den folgenden Schritt aufweist: Detektieren des Zustands in dem HART^®-Gerät (28–31).
Verfahren nach Anspruch 2, wobei der Schritt des spezifischen Zuordnens der Vielzahl von Geräte-(28–31)-Zuständen entweder zu dem Ausfall des HART^®-Gerätes (28–31), oder der Wartung des HART^®-Gerätes (28–31) oder der empfehlenswerten Maßnahme in Verbindung mit dem HART^®-Gerät (28–31) den folgenden Schritt aufweist: Verwenden einer Tabelle, um den detektierten Zustand entweder zu dem Ausfall des HART^®-Gerätes (28–31), oder der Wartung des HART^®-Gerätes (28–31) oder der empfehlenswerten Maßnahme in Verbindung mit dem HART^®-Gerät (28–31) zu klassifizieren.
Verfahren nach Anspruch 16, wobei der Schritt des Verwendens der Tabelle, um den detektierten Zustand entweder zu dem Ausfall des HART^®-Gerätes (28–31), oder der Wartung des HART^®-Gerätes (28–31) oder der empfehlenswerten Maßnahme in Verbindung mit dem HART^®-Gerät (28–31) zu klassifizieren, den folgenden Schritt aufweist: Verwenden einer Tabelle, die entweder in dem Gerät oder in einem Computer gespeichert ist, der mit dem Prozesssteuerungssystem (10) kommunikativ gekoppelt ist.