DE10154534B4

DE10154534B4 - Integrierte Alarmanzeige in einem Prozeßsteuerungsnetzwerk

Info

Publication number: DE10154534B4
Application number: DE10154534.7A
Authority: DE
Inventors: Robert B. Havekost; Trevor D. Schleiss; Michael G. Ott; Cindy Scott; J. Clint Fletcher
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 2000-11-07
Filing date: 2001-11-07
Publication date: 2017-04-13
Anticipated expiration: 2021-11-08
Also published as: US6774786B1; JP2002222012A; GB2372365B; DE10154534A1; US20050012608A1; US7250856B2; GB2372365A; GB0126490D0

Abstract

Alarmanzeigesystem zur Benutzung in einem Prozesssteuerungsnetzwerk, das eine Benutzerschnittstelle mit einem Anzeigemechanismus und eine Vielzahl von kommunikativ miteinander verbundenen Geräten umfasst, die zum Erzeugen und Senden von Alarme verschiedener Kategorien umfassenden Alarmbotschaften an die Benutzerschnittstelle ausgebildet sind, wobei das Alarmanzeigesystem folgendes umfasst: – einen Alarmempfänger, der zum Empfangen der Alarmbotschaften von der Vielzahl von Geräten konfiguriert ist, um eine Vielzahl von Alarmen verschiedener Kategorien zu erhalten, die mindestens zwei Alarme aus den folgenden Kategorien umfassen: – Prozessalarmkategorie mit Alarmen, die sich auf die Funktionalität der Prozesssteuersoftware beziehen, – Hardwarealarmkategorie mit Alarmen, die sich auf die Funktionalität mindestens eines Geräts bezieht, das einen Knoten im Prozesssteuersystem definiert, – Gerätealarmkategorie mit Alarmen, die sich auf mindestens ein Feldgerät beziehen, wobei die Hardware- und Gerätealarmkategorie keine Prozessalarmkategorie sind und nicht von einer Prozesssteuersoftware generiert werden; – eine Alarmverarbeitungseinheit, welche die Vielzahl von Alarmen zum Anzeigen verarbeitet, basierend auf einem vorbestimmten Kriterium zum Ermitteln eines Satzes von Alarmen zum Anzeigen, wobei die Alarmverarbeitungseinheit ausgebildet ist, alle Geräte- und Prozessalarme, die mit einem Hardwarealarm in der Vielzahl von Alarmen verbunden sind, von dem Satz von Alarmen zum Anzeigen zu entfernen; und – eine Alarmanzeigeeinheit, die Hinweise auf den Satz der Alarme zur Anzeige auf dem Anzeigemechanismus darstellt, wobei die Alarmanzeigeeinheit die Hinweise auf die Alarme verschiedener Kategorien auf eine integrierte Art auf dem Anzeigemechanismus darstellt.

Description

Gebiet der Erfindung
Die vorliegende Erfindung betrifft im allgemeinen Prozeßsteuerungssysteme und im spezielleren die Anzeige von Alarmbedingungen innerhalb eines Prozeßsteuerungssystems.
Beschreibung des Standes der Technik
Prozeßsteuerungssysteme, wie die in chemischen, Erdöl- oder anderen Verfahren benutzten, beinhalten typischerweise einen oder mehrere zentralisierte Prozeßcontroller, die kommunikationsmäßig mit wenigstens einer Host- oder Benutzer-Workstation und einem oder mehreren Feldgeräten über analoge, digitale oder kombinierte Analog/Digitalbusse gekoppelt sind. Die Feldgeräte, die beispielsweise Ventile, Ventilsteller, Schalter und Übertrager (beispielsweise Temperatur-, Druck- oder Durchflußratensensoren) sein können, verrichten Funktionen innerhalb des Prozesses wie Öffnen oder Schließen von Ventilen und Messen von Prozeßparametern. Der Prozeßcontroller empfängt Signale, die auf Prozeßmessungen, welche durch die Feldgeräte durchgeführt wurden, und/oder auf andere Informationen, die mit den Feldgeräten zusammenhängen, rückschließen lassen, benutzt diese Informationen, um eine Kontrollroutine zu implementieren und erzeugt dann Kontrollsignale, die über die Busse oder andere Kommunikationsverbindungen zu den Feldgeräten gesendet werden, um den Prozeßbetrieb zu steuern. Die Informationen von den Feldgeräten und den Controllern werden manchmal einer oder mehrerer Anwendungen zur Verfügung gestellt, die durch die Benutzer-Workstation ausgeführt werden, um es einem Bediener zu ermöglichen, gewünschte Funktionen in bezug auf den Prozeß auszuführen, wie Betrachten des aktuellen Zustandes des Prozesses, Modifizieren des Prozeßbetriebs, etc. Eine bekannte Controller/Bedienerschnittstellen-Software wurde entworfen, um Prozeßalarme zu erzeugen und anzuzeigen, die von Prozeßsteuerungs-Arbeitsgängen stammen, die von Software in den Controllern oder anderen Geräten ausgeführt wurden.
Das Delta-V Steuerungssystem, das von der Firma Fisher Rosemount Systems, Inc. vertrieben wird, nutzt Funktionsblöcke, die in Controllern oder verschiedenen Feldgeräten lokalisiert und installiert sind, um Steuerungsvorgänge auszuführen. Die Controller und in einigen Fällen die Feldgeräte sind imstande, einen oder mehrere Funktionsblöcke zu speichern und auszuführen, von denen jeder Eingaben von anderen Funktionsblöcken empfängt und/oder Ausgaben für andere Funktionsblöcke vorsieht (entweder innerhalb desselben Geräts oder innerhalb verschiedener Geräte), und einige Prozeßsteuervorgänge ausführt, solche wie Messen oder Detektieren eines Prozeßparameters, Überwachen eines Gerätes oder Ausführen eines Steuerungsvorgangs, wie die Implementierung einer Proportional-Differential-Integral (PID) Steuerungsroutine. Die verschiedenen Funktionsblöcke innerhalb eines Prozeßsteuerungssystems sind konfiguriert, um mit jedem anderen zu kommunizieren (beispielsweise innerhalb eines einzelnen Gerätes oder über einen Bus), um eine oder mehrere Prozeßsteuerungsschleifen zu bilden, von denen sich die individuellen Betriebsweisen im gesamten Prozeß ausbreiten können.
Typischerweise sind die Funktionsblöcke oder Geräte, in welchen diese Funktionsblöcke implementiert sind, konfiguriert, um Fehler, Ausfälle oder Probleme zu detektieren, die innerhalb der Prozeßsteuerungsschleifen oder Funktionen, die darin ausgeführt werden, auftreten, und um ein Signal zu senden, sowie eine Alarmbotschaft, um einen Bediener an einer Benutzer-Workstation oder einer anderen Benutzerschnittstelle zu benachrichtigen, daß ein unerwünschter Zustand innerhalb des Prozeßsteuerungssystems oder innerhalb einer Steuerungsschleife des Prozeßsteuerungssystems existiert. Solche Alarme können beispielsweise erkennen lassen, daß ein Funktionsblock nicht kommuniziert, eine Eingabe oder Ausgabe außerhalb eines Bereichs empfangen bzw. erzeugt hat, einen Ausfall durchmacht oder andere unerwünschte Zustände, etc. In den derzeitigen Alarmanzeigesystemen ist eine Anwendung, die beispielsweise von einer Benutzer-Schnittstelle/Workstation ausgeführt wird, konfiguriert, um Nachrichten zu empfangen, die Prozeßalarme bezogen auf den Prozeßbetrieb enthalten, und um diese Prozeßalarme in einer zusammenhängenden und überschaubaren Art anzuzeigen, um es dadurch einem Bediener zu ermöglichen, die Alarme in einer organisierten oder logischen Art und Weise zu handhaben. Solch ein Benutzer-Schnittstellensystem ist in dem US-Patent 5,768,119 beschrieben, das den Titel „Process Control System including Alarm Priority Adjustment” hat und hiermit ausdrücklich als Referenz hierin aufgenommen wird.
Bekannte Benutzer-Schnittstellenanwendungen, wie die in der Druckschrift US 5,768,119 A beschriebene, sind typischerweise konfiguriert, um einen Bediener, d. h. die Person, welche die aktuelle tägliche Bedienung eines Prozeßsteuerungssystems überblickt, in die Lage zu versetzen, die kritischsten Prozeßalarme zu betrachten, beispielsweise die Alarme mit den höchsten Prioritäten zuerst. Da diese Anwendungen mit dem Ziel entworfen sind, Informationen für einen Prozeßsteuerungs-Bediener bereitzustellen, zeigen sie lediglich Alarme an, die mit dem Funktionieren des Prozesses selbst in Verbindung stehen. Diese Anwendungen sind nicht konfiguriert, um andere Fehlertypen oder Alarme anzuzeigen, wie Alarme, die mit funktionsgestörten Feldgeräten oder anderer Hardware wie Controller oder Eingabe/Ausgabe (E/A) Geräte in Verbindung stehen. Dadurch zeigt eine Bediener-Anzeigeanwendung einen Bereich eines Prozeßsteuerungssystems an und liefert ein Alarmsymbol am unteren Ende der Anzeige, das den Prozeßalarm der höchsten Priorität andeutet, beispielsweise wie in dem System, das in der Druckschrift US 5,768,119 A beschrieben ist. Die angezeigten Alarme sind Prozeßalarme, da sie durch Funktionsblöcke oder andere Software erzeugt werden, die zum Implementieren eines Prozeßsteuerungs-Schemas oder einer Prozeßsteuerungs-Schleife und zum Anzeigen eines Fehlers in der Funktion einer Prozeßsteuerungs-Schleife benutzt wird. Wenn ein Bediener einen der Prozeßalarme an der Benutzer-Workstation auswählt, liefert die Anwendung dem Bediener mehr Information in bezug auf den ausgewählten Alarm, wie den Funktionsblock oder das Modul, die den Alarm erzeugt haben, die Priorität des Alarms, ob der Alarm bestätigt wurde, etc., und sie kann Informationen über den Prozeß anzeigen, die für den Alarm wichtig sind, wie eine Frontplatte für die Schleife, in welcher der Alarm auftrat, eine primäre Steuerungsanzeige bezogen auf den Teil der Anlage, in dem der Alarm auftrat, etc.
Ein Bediener, der diese bekannten Anzeigen nutzt, kann die Existenz eines Alarmes erkennen und versuchen, das Problem zu beheben, unter Nutzung anderer Softwareanwendungen, die dem Bediener zur Verfügung stehen. In einigen Fällen kann der Bediener bestimmen, basierend auf den gegenwärtigen Prozeßalarmen, daß ein oder mehrere Feldgeräte oder andere Hardwarekomponenten repariert oder ersetzt werden müssen. Wenn dies der Fall ist, kann der Bediener Wartungspersonal anrufen oder auf andere Weise kontaktieren, um das Gerät zum Testen, Reparieren oder Ersetzen aufzulisten. Ebenso kann der Bediener einen Ingenieur anrufen, um den Alarm zu behandeln. Auf diese Art erkennt der Bediener ein Geräte- oder Hardware-Problem, dem empfangene Prozeßalarme zugrunde liegen, und gibt das Problem manuell an Wartungs- oder Ingenieurpersonal weiter, um das Problem zu beheben. Jedoch erfordert es einen erfahrenen und sachkundigen Bediener, um Geräte- oder Hardware-Probleme anhand von Prozeßalarmen zu erkennen.
In der Vergangenheit wurden gewöhnliche Feldgeräte in Prozeßsteuerungssystemen benutzt, um analoge (beispielsweise 4–20 mA) Signale zu dem Prozeßcontroller zu senden und von diesem zu empfangen, über einen analogen Bus oder analoge Verbindungen. Diese 4–20 mA Signale sind jedoch in ihrer Natur darin beschränkt, daß sie auf Prozeßmessungen, die von dem Gerät gemacht wurden, oder auf Prozeßsteuerungssignale schließen lassen, die von dem Controller erzeugt wurden, der zum Überwachen der Arbeitsweise des Gerätes während der Laufzeit erforderlich ist. Infolgedessen sind die konventionellen 4–20 mA Geräte nicht imstande, Alarme zu erzeugen, die mit der Einsatzfähigkeit des Gerätes selbst zusammenhängen. Infolgedessen waren Alarme, die mit diesen Geräten verbunden sind, im allgemeinen nicht innerhalb von Prozeßsteuerungssystemen verfügbar. Etwa im letzten Jahrzehnt wurden jedoch intelligente Feldgeräte (Smart-Feldgeräte) in der Prozeßsteuerungs-Industrie gängig, die einen Microprozessor und einen Speicher beinhalten. Einige Standard- und freie intelligente Feldgeräte-Kommunikationsprotolle wie der Foundation^TM Feldbus (nachfolgend „Feldbus”), HART^®, PROFIBUS^®, WORLD-FIP^®, DEVICE-NET^® und CAN-Protokolle wurden entwickelt, um es zu ermöglichen, daß intelligente Feldgeräte von verschiedenen Herstellern miteinander innerhalb desselben Prozeßsteuerungsnetzwerks benutzt werden können. Zusätzlich zum Ausführen einer primären Funktion innerhalb des Prozesses können intelligente Feldgeräte Daten speichern, die mit dem Gerät verbunden sind, mit dem Controller und/oder anderen Geräten in einem digitalen oder kombinierten digitalen und analogen Format kommunizieren und sekundäre Aufgaben ausführen wie Selbst-Kalibrierung, Identifikation, Diagnosen, etc. Bedeutsamerweise sind die Geräte, die wenigstens einigen dieser Protokolle entsprechen, fähig, Probleme innerhalb des Geräts selbst zu erkennen und Alarme oder Alarmsignale zu erzeugen und zu senden, um erkannte Probleme dem zuständigen Bedienungs-, Wartungs- oder Ingenieur-Personal anzuzeigen, das mit dem Prozeßsteuerungssystem Umgang hat.
Allerdings gab es nur einige, wenn überhaupt Anzeige-Anwendungen, um Nicht-Prozeßalarme anzuzeigen, wie Alarme, die von den Feldgeräten oder Controllern erzeugt werden, die anzeigen, daß ein Problem mit der Hardware aufgetreten ist, die mit diesen Geräten zusammenhängen. Es wird davon ausgegangen, daß es keine bekannten Anzeigen gibt, die es Wartungs- oder Ingenieur-Personal ermöglichen, fehlerhafte Feldgeräte, Controller, E/A-Einrichtungen, etc. auf eine zusammenhängende oder übereinstimmende Art und Weise zu erkennen und zu behandeln, da sie mit Bedienungsanzeigen ausgestattet sind, die Prozeßalarme anzeigen. In der Tat müssen Ingenieure und technisches Personal im allgemeinen zahlreiche Protokoll-Ausdrucke oder gespeicherte Dateien mit Alarmen oder anderen Ereignissen durchsehen, die über oder durch Feldgeräte oder andere Hardware-Geräte detektiert wurden. Dieses Verfahren ist zeitaufwendig und schwierig. Die Möglichkeit, das Ingenieur- oder Wartungs-Personal in die Lage zu versetzen, Geräte und Hardware-Alarme auf eine zusammenhängende Art und Weise zu betrachten, ist sogar noch wünschenswerter seit dem Aufkommen von neueren intelligenten Feldgeräten, Controllern und E/A-Einrichtungen, die wie oben angedeutet mit der Fähigkeit versehen sind, zahlreiche Betriebsprobleme über die Geräte selbst zu erkennen, so wie wenn das Gerät das Kommunizieren stoppt, oder einige andere Probleme, die das Gerät am korrekten Betrieb hindern. Beispielsweise kann ein Ventil eingebaute Sensoren haben, die eine Überdruck- oder eine Unterdruck-Bedingung, einen klemmenden Ventilstöpsel, etc. erkennen und Software in dem Gerät kann einen Alarm erzeugen, der den Typ des erkannten Problems sowie die Schwere des Problems anzeigt. In einigen Fällen kann das Problem kritisch sein und unmittelbare Beachtung erfordern, so wie bei einem klemmenden Ventilstöpsel, wohingegen andere Bedingungen die Planung von Wartung zu einer bestimmten Zeit in der Zukunft erfordern können. Beispielsweise kann ein Ventil die Summe des Ventilwegs seit der letzten Wartung messen und, wenn die Summe des Ventilwegs eine vorgegebene Schwelle erreicht, einen Alarm erzeugen, der Wartung anfordert.
Ferner kann in einigen kleineren Prozeßumgebungen noch eine einzelne Person die Aufgaben eines Benutzers, einer Wartungsperson oder eines Ingenieurs ausführen wollen. Alternativ kann der Benutzer Kenntnis über Probleme wünschen, die in Feldgeräten, Controllern und E/A-Einrichtungen auftreten, da es ihm oder ihr helfen kann, einige der Prozeßalarme zu verstehen, die an der herkömmlichen Benutzerschnittstelle erscheinen. In der Vergangenheit gab es keinen einfachen Weg, eine einzelne Person in den Stand zu versetzen, alle Alarmdaten auf eine organisierte und integrierte Art zu betrachten. Ferner kann ein Benutzer noch wünschen, alle Kategorien von Alarmen zu betrachten, wenn nicht zuviele Informationen an der Schnittstelle angezeigt werden, da zu dieser Zeit der Benutzer wünschen könnte, bestimmte Kategorien von Alarmen ausschalten oder die Verantwortung für bestimmte Alarme an jemand anderen übergeben zu können. Derzeit gibt es kein System, das eine einzelne Person in den Stand versetzt, diese Funktionen durchzuführen.
Neben der zuvor genannten Druckschrift US 5 768 119 A ist folgender Stand der Technik bekannt:
GB 2 083 258 A beschreibt ein Alarmsystem, das einen Computer enthält, der angeordnet ist, um verschiedene Alarmzustände der Vorrichtung (z. B. einer Kernkraftanlage) zu analysieren und um zu bestimmen, welche Alarme sich aus den Hauptursachen einer Anzahl von vorliegenden Alarmen ergeben. Die Hauptursachenalarme werden auf einer Sichtanzeigeeinheit angezeigt, und das Vorhandensein von Nebenalarmen wird durch Gruppenalarmlampe an einer Gruppenalarmtafel angezeigt. Der Bediener kann eine Anzeige aller Alarme, die in einer bestimmten Gruppe vorhanden sind, anfordern.
US 4 644 478 A bezieht sich auf ein Überwachungs- und Alarmsystem, das für die Verwendung mit vielen verschiedenen Anwendungen angepasst werden kann, um anspruchsvolle Alarmierungs- und Steuerfunktionen basierend auf logischen Beziehungen zwischen mehreren erfaßten Variablen bereitzustellen.
EP 0 959 398 A1 beschreibt ein Alarmauswahlverfahren und eine Vorrichtung, die auf einem Computer arbeitet, welche ein Anwendungsfenster umfassen, das eine Hauptalarmliste, eine Auswahleinrichtung zum Auswählen der in der Alarmliste angezeigten Alarmanzeigen und eine Operationseinrichtung, die eine Hauptalarmlistenteilmenge mit Merkmale der ausgewählten Alarmmeldungen erzeugt, aufweist.
Aufgabe der vorliegenden Erfindung ist es daher, ein Alarmanzeigesystem zur Benutzung in einem Prozeßsteuerungsnetzwerk, ein Prozeßsteuerungssystem und ein Verfahren zum Erzeugen und Darstellen von Alarmen in einem Proezeßsteuerungssystem anzugeben, welche insbesondere eine einzelne Person in den Stand versetzen, die Vielzahl der vorgenannten Funktionen durchzuführen, und die Wertung vieler Alarme auf eine einfachere Art ermöglichen.
Diese Aufgabe wird durch ein Alarmanzeigesystem mit den Merkmalen nach Anspruch 1, ein Prozeßsteuerungssystem mit den Merkmalen nach Anspruch 24 und ein Verfahren mit den Merkmalen nach Anspruch 25 gelöst. Bevorzugte Ausgestaltungen der Erfindung sind Gegenstand der abhängigen Ansprüche.
Zusammenfassung der Erfindung
Eine Alarmanzeige und ein Schnittstellen-System zur Benutzung in einem Prozeßsteuerungsnetzwerk empfängt und zeigt verschiedene Kategorien von Alarmen, die beispielsweise Geräte-Alarme und Hardware-Alarme sowie herkömmliche Prozeß-Alarme umfassen, in einer einzelnen Anzeige auf eine integrierte Art an, um es einem Benutzer oder anderen Benutzern zu ermöglichen, die Alarme der verschiedenen Kategorien zu betrachten bzw. zu beurteilen, Zugriff darauf zu haben und sie zu manipulieren. Die Anzeige und das Schnittstellen-System können benutzt werden, um die Alarme zu filtern, die angezeigt werden, gemäß einer Anzahl von Parametern, die Kategorie, Typ, Priorität, Status, Zeit, etc. umfassen, um die Aufgaben zu trennen oder zu kombinieren, die typischerweise mit einem Benutzer, Wartungs- und Ingenieur-Personal zusammenhängen. Die Alarmanzeige und das Schnittstellen-System können auch benutzt werden, um auf jeden der angezeigten Alarme zuzugreifen, um mehr Informationen über einen individuellen Alarm zu erhalten.
Gemäß der Erfindung ist denkbar, dass ein Alarmanzeigesystem in einem Prozeßsteuerungsnetzwerk benutzt werden kann, das eine Benutzerschnittstelle mit einem Anzeigemechanismus und eine Vielfalt von kommunikationsmäßig verbundenen Geräten aufweist, die zum Erzeugen und Senden von Alarmbotschaften, die Alarme verschiedener Kategorien aufweisen, an die Benutzerschnittstelle angepaßt sind. Das Alarmanzeigesystem umfaßt

– einen Alarmempfänger, der konfiguriert ist, um die Alarmbotschaften von der Vielfalt von Geräten zu empfangen, um eine Vielzahl von Alarmen verschiedener Kategorien zu erhalten,
– eine Alarmverarbeitungseinheit, welche die Vielzahl von Alarmen zum Anzeigen verarbeitet, basierend auf einem vorbestimmten Kriterium zum Ermitteln eines Satzes von Alarmen zum Anzeigen, und
– eine Alarmanzeigeeinheit, die Hinweise auf den Satz der Alarme zum Anzeigen auf dem Anzeigemechanismus darstellt, wobei die Alarmanzeigeeinheit die Hinweise auf Alarme verschiedener Kategorien auf eine integrierte Art auf dem Anzeigemechanismus präsentiert. Falls gewünscht, kann die Alarmverarbeitungseinheit einen Alarmfilter aufweisen, der die Vielzahl von Alarmen zum Anzeigen filtert, basierend auf dem vorbestimmten Kriterium, wie die Alarmkategorie oder Alarmpriorität, um den Satz von Alarmen zum Anzeigen zu ermitteln.

Im folgenden werden die Erfindung, ihre Anwendungsmöglichkeiten und Vorteile ausführlich anhand von Ausführungsbeispielen in Verbindung mit den Zeichnungen erläutert.
Kurze Beschreibung der Zeichnungen
1 zeigt ein Blockdiagramm eines Prozeßsteuerungssystems, in dem eine integrierte Alarmanzeige und ein Schnittstellensystem benutzt werden können;
2 zeigt ein Blockdiagramm einer Workstation, die eine integrierte Alarmanzeige und ein Schnittstellensystem aufweist, die darin ausgeführt werden;
3 zeigt ein erstes Ausführungsbeispiel eines Benutzerschnittstellen-Schirms, der von der integrierten Alarmanzeige und dem Schnittstellensystem erzeugt wird, die in dem Prozeßsteuerungssystem von 1 benutzt werden;
4 zeigt ein zweites Ausführungsbeispiel eines Benutzerschnittstellen-Schirms, der von der integrierten Alarmanzeige und dem Schnittstellensystem erzeugt wird, die in dem Prozeßsteuerungssystem von 1 benutzt werden;
5 zeigt ein Ausführungsbeispiel einer Alarmsymbolanzeige für einen Prozeßalarm;
6 zeigt ein Ausführungsbeispiel einer Alarmsymbolanzeige für einen Gerätealarm;
7 zeigt ein Ausführungsbeispiel einer Alarmsymbolanzeige für einen Hardware-Alarm;
8 zeigt ein Ausführungsbeispiel einer Frontplatten-Anzeige für einen Gerätealarm, der mit einem Feldbus-Feldgerät in Verbindung steht;
9 zeigt ein Ausführungsbeispiel einer Frontplatten-Anzeige für einen Gerätealarm, der mit einem generischen Feldgerät in Verbindung steht;
10 zeigt ein Ausführungsbeispiel einer Frontplatten-Anzeige für einen Hardware-Alarm, der mit einem Knoten oder einem Hardware-Element in Verbindung steht;
11 zeigt ein Ausführungsbeispiel einer Schnittstellen-Anzeige, die zum Setzen der Kategorien und Prioritäten von Alarmen benutzt wird und auf einem Benutzerschnittstellen-Schirm angezeigt wird;
12 zeigt ein erstes Ausführungsbeispiel einer Anzeige zusammengefaßter Alarme, die von einem Alarm-Zusammenfassungs-Steuerungsmodul erzeugt wird;
13 zeigt ein zweites Ausführungsbeispiel einer Anzeige zusammengefaßter Alarme, die von einem Alarm-Zusammenfassungs-Steuerungsmodul erzeugt ist;
14 zeigt ein drittes Ausführungsbeispiel einer Anzeige zusammengefaßter Alarme, die von einem Alarm-Zusammenfassungs-Steuerungsmodul erzeugt ist; und
15 zeigt ein Ausführungsbeispiel einer Ereignisaufzeichnung von Prozeß- und Geräte-Alarmen.
Beschreibung der bevorzugten Ausführungsformen
Bezugnehmend auf 1 beinhaltet ein Prozeßsteuerungsnetzwerk oder -System 10 einen oder mehrere Prozeßcontroller 12, die mit einer oder mehreren Host-Workstations oder -Computern 14 (die irgendein Typ eines Personal-Computers oder einer Workstation sein können) und mit einer Gruppe von Eingabe/Ausgabe (E/A)-Einrichtungen oder -Geräten 20, 22 verbunden sind, von denen jedes nacheinander mit einem oder mehreren Feldgeräten 25–39 verbunden ist. Die Controller 12, die nur als Beispiel Delta-V^TM-Controller sein können, die von der Firma Fisher-Rosemount Systems, Inc. vertrieben werden, sind kommunikationsmäßig mit dem Host-Computer 14 über beispielsweise eine Ethernet-Verbindung oder andere Kommunikationsverbindungen verbunden. Ebenso sind die Controller 12 kommunikationsmäßig mit den Feldgeräten 25–39 verbunden, die irgendeine gewünschte Hardware und damit zusammenhängende Software benutzen, beispielsweise standardisierte 4–20 mA Geräte und/oder irgendein intelligentes Kommunikationsprotokoll wie die Feldbus- oder HART-Protokolle. Wie es im allgemeinen bekannt ist, implementieren oder überwachen die Controller 12 Prozeßsteuerungsroutinen, die darin gespeichert sind oder anders damit zusammenhängen, und kommunizieren mit den Geräten 25–39, um einen Prozeß auf eine gewünschte Art und Weise zu steuern.
Die Feldgeräte 25–39 können irgendein Typ von Geräten, wie Sensoren, Ventile, Sender, Positionierer, etc. sein, während die E/A-Karten innerhalb der Gruppen 20 und 22 irgendein Typ von E/A-Geräten sein können, die einem gewünschten Kommunikations- oder Controller-Protokoll wie HART, Feldbus, Profibus, etc. entsprechen. In der in 1 gezeigten Ausführungsform sind die Feldgeräte 25–27 standardisierte 4–20 mA Geräte, die über analoge Verbindungen zu der E/A-Karte 22A kommunizieren. Die Feldgeräte 28–31 sind als HART-Geräte dargestellt, die mit einem HART-kompatiblen E/A-Gerät 20A verbunden sind. Ähnlich sind die Feldgeräte 32–39 intelligente Geräte, wie Feldbus-Feldgeräte, die über einen digitalen Bus 42 oder 44 zu den E/A-Karten 20B oder 22B kommunizieren, unter Benutzung von beispielsweise Feldbus-Protokoll-Kommunikation. Selbstverständlich könnten die Feldgeräte 25–39 und die Gruppen von E/A-Karten 20 und 22 irgendeinem anderen gewünschten Standard oder anderen gewünschten Standards oder Protokollen neben den 4–20 mA, HART oder Feldbus-Protokollen entsprechen, einschließlich Standards oder Protokollen, die in der Zukunft entwickelt werden.
Jeder der Controller 12 ist konfiguriert, um eine Steuerungsstrategie zu implementieren, unter Benutzung von dem, was im allgemeinen als Funktionsblöcke bezeichnet wird, wobei jeder Funktionsblock ein Teil (beispielsweise eine Subroutine) einer Gesamtsteuerungsroutine ist und in Verbindung mit anderen Funktionsblöcken (über als Links bezeichnete Kommunikationen) arbeitet, um Prozeßsteuerungsschleifen innerhalb des Prozeßsteuerungssystems 10 zu implementieren. Funktionsblöcke erfüllen typischerweise

– eine Eingabefunktion, wie die mit einem Sender, einem Sensor oder anderem Gerät zur Messung eines Prozeßparameters zusammenhängende,
– eine Kontrollfunktion, wie die mit einer Kontrollroutine zusammenhängende, die eine PID-, Fuzzy-Logik-, etc. Kontrolle ausführt, oder
– eine Ausgabefunktion, die den Betrieb irgendeines Geräts, wie eines Ventils, steuert, um irgendeine physikalische Funktion innerhalb des Prozeßsteuerungssystems 10 auszuführen.

Natürlich gibt es Hybrid- oder andere Typen von Funktionsblöcken. Gruppen dieser Funktionsblöcke werden Module genannt. Funktionsblöcke und Module können in dem Controller 12 gespeichert sein und von diesem ausgeführt werden, was typischerweise der Fall ist, wenn diese Funktionsblöcke für standardisierte 4–20 mA Geräte und irgendwelche Typen von intelligenten Feldgeräten benutzt werden oder mit diesen in Verbindung stehen, oder sie können in den Feldgeräten selbst gespeichert und von diesen implementiert sein, was bei Feldbus-Geräten der Fall sein kann. Während die Beschreibung des Steuerungssystems hierin unter Nutzung einer Funktionsblock-Steuerungsstrategie vorgesehen ist, könnte die Steuerungsstrategie auch unter Nutzung anderer Konventionen, wie Kettenlogik, sequenzielle Flußdiagramme, etc. und irgendeiner gewünschten proprietären oder nicht-proprietären Programmiersprache implementiert oder entworfen sein.
In dem System von 1 dient eines oder mehrere der Host-Geräte 14 als eine Benutzer-Workstation und hat darin eine Alarmverarbeitungs-Software 50 gespeichert. Allgemein gesprochen zeigt die Alarmverarbeitungs-Software 50 Informationen über das Prozeßsteuerungssystem an, die relevant sind für das Verständnis des Benutzers oder die Fähigkeit zum Betrachten bzw. Beurteilen des aktuellen Betriebsstatus des Prozesses hinsichtlich der Alarme, die im System vorliegen. Beispielsweise kann die Alarmschnittstellen-Software 50 ein Alarmsymbol anzeigen, das darin Alarmhinweise und eine primäre Steuerungsanzeige umfaßt, die einen Bereich des Prozesses 10 darstellt, der die Geräte und andere Ausstattung umfaßt, die mit dem Bereich des Prozesses 10 in Verbindung stehen, der für einen der Alarme relevant ist. Die primäre Steuerungsanzeige kann Information vorsehen über den aktuellen Status des Prozesses 10, wie den Flüssigkeitslevel in Tanks, das Fließverhalten von Ventilen und anderen Strömungsverbindungen, die Einstellungen von Geräten, Ablesewerte von Sensoren, etc. Ein Beispiel einer solchen Anzeige ist in 3 dargestellt. Ein Benutzer kann die Alarmverarbeitungs-Software 50 nutzen, um verschiedene Teile von dem Prozeß oder von Geräten innerhalb des Prozesses 10 zu betrachten bzw. zu überwachen. Selbstverständlich kommuniziert die Alarmverarbeitungs-Software 50 mit den Kontrollern 12 und, falls erforderlich, den Feldgeräten 25–39, irgendeiner der Gruppen von E/A-Geräten 20, 22 oder anderen Geräten, um die relevanten Werte, Einstellungen und Messungen zu erhalten, die mit dem Prozeß zusammenhängen oder in diesem gemacht werden, um den Schnittstellen-Bildschirm auf der Benutzer-Anzeige der Workstation 14 zu erzeugen.
Die Alarmverarbeitungs-Software ist konfiguriert, um Alarme, die von Alarmerzeugungs-Sofware innerhalb einiger oder aller der Controller 12, der E/A-Geräte 20 und 22 oder der Feldgeräte 25–39 erzeugt werden, zu empfangen. Diese Software ist als Softwareelemente 51, 52 und 53 in 1 dargestellt. Allgemein gesprochen, empfängt die Schnittstellensoftware 50 verschiedene Kategorien von Alarmen, die beispielsweise

– Prozeßalarme (welche typischerweise von Prozeßsteuerungs-Softwaremodulen erzeugt werden, wie die, die aus kommunikationsmäßig verbundenen Funktionsblöcken gemacht sind, die Prozeßsteuerungsroutinen bilden, die während der Laufzeit des Prozesses benutzt werden),
– Hardware-Alarme, wie Alarme, die von den Controllern 12, E/A-Geräten 20 und 22 oder anderen Workstations 14 erzeugt werden und mit der Zustands- oder Funktionsbedingung dieser Geräte einhergehen, und
– Gerätealarme, die von einigen oder allen der Feldgeräte 25–39 erzeugt werden, um Probleme anzuzeigen, die mit diesen Geräten verbunden sind.

Diese oder andere Kategorien von Alarmen können auf irgendeine gewünschte Art erzeugt werden. Beispielsweise ist es bereits bekannt, Funktionsblöcke oder Softwaremodule zu haben, die benutzt werden, um Prozeßsteuerungsfunktionen zu implementieren, die Prozeßalarme erzeugen, wobei diese Prozeßalarme typischerweise zu einer Benutzer-Schnittstelle zum Anzeigen gesendet werden. Auch neuere intelligente Geräte, Controller, E/A-Geräte, Datenbanken, Server, Workstations, etc. können irgendeine gewünschte, proprietäre oder nicht-proprietäre Software benutzen zum Erkennen von Problemen, Fehlern, Wartungs-Alarmsignalen, etc. und zum Senden von Alarmen, die diese Bedingungen der Benutzer-Schnittstelle 14 anzeigen. Insbesondere sind viele der Geräte, die nun erhältlich sind, wie die Controller, E/A-Geräte und intelligenten Feldgeräte, mit Software und/oder Sensoren versehen, die Hardware-Probleme erkennen, wie klemmende Ventilstöpsel, gebrochene Teile, Instandhaltungsprobleme, etc., und die Signale oder Botschaften erzeugen, die diese Bedingungen anzeigen. Diese Fähigkeit ist bereits in vielen Geräten vorgesehen, darunter Feldgeräte, E/A-Geräte und Controller und wird daher nicht hierin im Detail beschrieben. Es genügt zu erwähnen, daß irgendeine gewünschte Fehlererkennungs- und Alarmerzeugungs-Software 51, 52 und 53 genutzt werden kann, um Alarme zu der Alarmverarbeitungs-Software 50 zu senden, die konfiguriert ist, um diese Alarme zu empfangen und zu erkennen, unter Nutzung irgendeiner gewünschten Protokoll- oder Kommunikations-Strategie.
Falls gewünscht, kann die Alarmverarbeitungs-Software 50 Alarme basierend auf einer Anzahl von Faktoren empfangen und filtern. Insbesondere kann die Alarmverarbeitungs-Software 50 Alarme filtern, basierend auf der Workstation, auf der die Software 50 ausgeführt wird, auf dem Benutzer oder der Person, die an der Workstation angemeldet ist, und auf durch einen Benutzer konfigurierbaren Einstellungen, wie Kategorie, Typ, Priorität, Status, Zeit der Erzeugung, etc. des Alarms. Beispielsweise kann die Software 50 Alarme filtern, um Alarme nur aus den Bereichen oder Abschnitten der Anlagen anzuzeigen, für welche die Workstation, auf der die Software 50 ausgeführt wird, zum Empfang konfiguriert ist. D. h., Alarme für bestimmte Bereiche oder Abschnitte der Anlage können nicht an bestimmten Workstations angezeigt werden, aber statt dessen kann jede Workstation auf das Anzeigen von Alarmen für eine oder mehrere spezifische Bereiche der Anlage begrenzt werden. Ebenso können Alarme durch eine Benutzer-Identifikation gefiltert werden. Insbesondere können Benutzer darauf beschränkt sein, bestimmte Kategorien, Typen, Prioritäten, etc. von Alarmen zu betrachten oder sie können darauf beschränkt sein, Alarme von einem Abschnitt oder einem Unterabschnitt (beispielsweise, und einem Bereich) der Anlage zu betrachten. Die Verarbeitungssoftware 50 filtert auch Alarme zur Anzeige aus, basierend auf der Beseitigung durch einen Benutzer. Diese Workstation- und Benutzer-Filtereinstellungen werden hierin als die Workstation- und Benutzer-Sichtkontrolle bezeichnet.
Die Alarmverarbeitungs-Software 50 kann auch die sichtbaren Alarme (d. h. die innerhalb der Workstation- und Benutzer-Sichtkontrollen sichtbaren) filtern, basierend auf durch den Benutzer konfigurierbaren Einstellungen, beispielsweise die Kategorie eines Alarms (beispielsweise Prozeß-, Geräte- oder Hardware-Alarm), Typen von Alarmen (Kommunikation, Auswahl, Empfehlung, Instandhaltung, etc.), der Priorität des Alarms, des Moduls, Geräts, der Hardware, des Knotens oder Bereichs, zu dem der Alarm gehört, ob der Alarm bestätigt oder unterdrückt worden ist, ob der Alarm aktiv ist, etc.
Bezugnehmend auf 2 ist die Konfiguration einer der Workstations 14, welche das Alarmanzeige- und Schnittstellensystem implementiert, detaillierter gezeigt. Wie in 2 dargestellt, speichert und führt die Workstation 14 Kommunikationssoftware aus, wie eine Kommunikationsschicht oder einen Kommunikationsstapel 62, der mit den Controllern 12 über die Ethernet-Verbindung 40 kommuniziert, um Signale zu empfangen, die von den Controllern 12, E/A-Geräten innerhalb der Gruppen 20 und 22, Feldgeräte 25–39 und/oder anderen Workstations 14 gesendet wurden. Die Kommunikationsschicht 62 formatiert auch richtig Botschaften, die zu den Controllern, E/A-Geräten, Feldgeräten 25–39 und anderen Workstations 14 gesendet werden sollen, wie Alarmbestätigungs-Signale, etc. Diese Kommunikationssoftware kann irgendeine bekannte oder gewünschte Kommunikationssoftware sein, die beispielsweise aktuell mit Ethernet-Kommunikationen verwendet wird. Selbstverständlich ist der Kommunikationsstapel 62 mit anderer Software gekoppelt, die andere Funktionen ausführt, wie Konfigurationsanwendungen, Diagnose- oder andere Prozeßanwendungen, Datenbankverwaltungsanwendungen, etc., und von der Workstation 14 ausgeführt wird.
Das Alarmanzeige- und Schnittstellensystem beinhaltet eine Alarmverarbeitungseinheit 64, die Alarme von der Kommunikationsschicht 62 empfängt, diese Alarme decodiert und die decodierten Alarme in einer Datenbank 66 speichern kann. Das Front-End der Alarmverarbeitungseinheit, das mit der Kommunikationsschicht 62 oder der Datenbank 66 gekoppelt ist, kann ein Alarmempfänger sein, wie es die Kommunikationsschicht 62 sein kann. Die Alarmanzeige- und Schnittstellen-Software 50 beinhaltet auch einen Filter 68, der die Alarmverarbeitungseinheit 64 benutzt, um zu bestimmen, welche Alarme auf einer Benutzerschnittstelle 69 angezeigt werden (wie eine CRT-, LCD-, LED-, Plasma-Anzeige, ein Drucker, etc.), die mit der Workstation 14 zusammenhängt. Der Filter 68 kann seine Einstellungen in der Datenbank 66 gespeichert haben und diese Filtereinstellungen können voreingestellt und/oder durch einen Nutzer änderbar sein, basierend auf den Vorlieben des Nutzers.
Im allgemeinen können die Filtereinstellungen die Kategorie und Priorität von Alarmen steuern und falls gewünscht die Folge der Alarme, die angezeigt werden, unter Nutzung einer Anzahl verschiedener Kriterien einrichten. Zu allererst bewirken die Workstation- und Benutzer-Sichteinstellungen, was ein bestimmter Benutzer sehen kann (welche Alarme an einer bestimmten Workstation angezeigt werden können), basierend auf der Benutzer-Identifikation und Workstation, an welcher der Benutzer angemeldet ist. In diesem Fall kann eine Betriebslizenz jeder Workstation zugewiesen sein und ohne einer Betriebslizenz wird die Alarminformation und werden alle Alarmlisten/Zusammenfassungs-Anzeigen leer sein, d. h. es werden keine aktiven oder unterdrückten Alarme irgendeiner Kategorie (Prozeß, Hardware oder Gerät), von der Alarmverarbeitungseinheit 54 angezeigt werden. Ferner sind nur noch Alarme von einem Anlagenbereich in der aktuellen Sicht des Benutzers (dem Benutzer wird gewöhnlich wenigstens ein Sicherheitsschlüssel in dem Anlagenbereich gegeben) auswählbar, um in den Alarmanzeigen auf der Workstation zu erscheinen. Es sind auch nur Alarme aus einem Anlagenbereich und einer Einheit wählbar, die nicht durch Nutzung der Anlagenbereich- oder Einheiten-Filteranzeigen (wird unten erläutert) abgestellt worden sind, um auf der Alarmanzeige zu erscheinen. Auf diese Art verhindert der Filter 68 zuerst die Anzeige von Alarmen außerhalb der Workstation- und Benutzer-Sicht und von Alarmen von Anlagenbereichen oder Einheiten, die vom Benutzer abgeschaltet worden sind.
Nach Testen von Alarmen auf Übereinstimmung mit der Workstation- und Benutzer-Sichtkontrolle filtert dann der Filter 68 aus und bestimmt die Anzeigereihenfolge von Alarmen basierend auf Benutzer-Einstellungen, die beispielsweise die Kategorie eines Alarms, die Priorität des Alarms, den Typ eines Alarms, den bestätigten Status des Alarms, den unterdrückten Status des Alarms, die Zeit des Alarms, den aktiven Status des Alarms etc. beinhalten kann. Die empfangenen Alarme, die an die Software 50 unter Nutzung von Alarmbotschaften gesendet worden sind, werden einen Parameter für jeden dieser Werte enthalten und der Filter wird Alarme zum Anzeigen durch Vergleichen der geeigneten Parameter der Alarme mit den Filtereinstellungen filtern. Beispielsweise kann der Benutzer zu verstehen geben, welche Kategorien von Alarmen und Prioritätsstufen eines Alarms auf dem Bildschirm angezeigt werden sollten. Falls gewünscht, kann der Benutzer eine vorbestimmte Prioritätsstufe für einen Alarm einstellen, durch Verschieben der Prioritätsstufe von der vorkonfigurierten Prioritätsstufe für den Alarm, wie sie vom Hersteller gesetzt ist. In dem Delta-V-System ist eine Prioritätsstufe zwischen 15 und 3 für jeden Alarm ausgewählt und der Benutzer kann diese Priorität durch eine Anzahl von Stufen verschieben, um dadurch eine höhere Priorität in eine niedrigere Priorität (oder umgekehrt) zu ändern, wenn sie durch den Filter 68 betrachtet wird. Während der Benutzer die Reihenfolge einer Anzeige der Alarme, die durch den Filter 68 durchgegangen sind, einstellen kann, kann die Reihenfolge auch durch vorkonfigurierte Einstellungen bestimmt sein, was zu einer konsistenteren Anzeige der verschiedenen Alarme führt.
In jedem Fall kann der Benutzer die Art ändern, auf welche Alarme angezeigt werden, basierend auf Kategorien von Alarmen, an denen der Benutzer oder Benutzer am meisten interessiert ist, die alle von einer Kategorie eines Alarms sein könnten wie Prozeßalarme, Gerätealarme oder Hardwarealarme oder eine Kombination von zwei oder mehr Kategorien von Alarmen. Der Benutzer kann auch die Kontrolle darüber haben, wie die Alarme und die Information, die mit den Alarmen vorgesehen ist, dargestellt werden. Auf diese Art kann die Alarmanzeige- und Schnittstellen-Software 50 genutzt werden, um eine einzelne Person in den Stand zu versetzen, die Bedienungen eines Benutzers, eines Technikers oder von Wartungspersonal oder eines Ingenieurs durch Betrachten und Ansprechen der Alarme durchzuführen, die normalerweise von diesem unterschiedlichen Personal an verschiedenen Stellen in einer Anlage angesprochen würden. Alternativ kann das Wartungspersonal zu verschiedenen Zeiten in demselben System dasselbe System dazu benutzen, um gerade die Wartungsalarme zu betrachten, während ein Ingenieur andere Typen von Alarmen betrachtet, welche Auswirkungen auf die Geräte haben. Auf diese Art kann dieselbe Alarmanzeige- und Schnittstellen-Software 50 von verschiedenen Typen von Leuten zur selben Zeit (an verschiedenen Workstations) genutzt werden, um verschiedene Aspekte der Alarme zu betrachten, die mit den Betriebsfunktionen des Prozeßsteuerungssystems 10 zusammenhängen. Außerdem ist es durch Nutzung der Alarmanzeige- und Schnittstellen-Software 50 für bestimmte Einzelne leicht, Alarmfunktionen zu übernehmen, die sie überwachen und anderen Einzelnen zu bestätigen, die dieselbe Software haben können und zur selben Zeit ihr Filter einstellen können, um Alarme anzunehmen, die normalerweise durch die erste Person überwacht wurden. Auf diese Art kann eine Person in die Mittagspause gehen und die Alarmüberwachungsfunktion anderen Personen an einer unterschiedlichen Workstation durch zurücksetzen einiger Filtereinstellungen übergeben. Wenn sie aus der Mittagspause zurückkehrt, kann die Person diese Funktionen noch einmal übernehmen. Auch wenn die Alarminformation für eine Person zum Behandeln zu groß wird, kann sie diese Person abgeben oder die Last von bestimmten Kategorien von Alarmen wie Prozeßalarme, Gerätealarme oder Hardwarealarme abgeben, so daß diese Alarme durch andere Leute an anderen Terminals behandelt werden können.
Nachdem die Alarmverarbeitungseinheit 64 den Filter 68 nutzt, um zu entscheiden, welcher Alarm oder welche Alarme dem Benutzer über die Anzeige 69 gezeigt werden sollte bzw. sollten, und über die Reihenfolge, in welcher die Alarme angezeigt werden sollten, stellt die Alarmverarbeitungseinheit 64 diese Information einer Benutzeranzeigeschnittstelle 70 zur Verfügung, die irgendein standardisiertes oder gewünschtes Betriebssystem zum Anzeigen von Alarminformation auf der Alarmanzeige 69 auf irgendeine gewünschte Art nutzt. Selbstverständlich erhält die Benutzeranzeigeschnittstelle 70 andere Informationen, die sie braucht, wie Informationen über das Layout oder die Konfiguration von dem Prozeßsteuerungssystem 10, die Werte der Parameter oder Signale innerhalb des Systems, etc. von der Datenbank 66 oder von anderen Kommunikationssignalen, die über die Kommunikationsschicht 62 von dem Prozeßsteuerungsnetzwerk 10 empfangen werden. Die Benutzeranzeigeschnittstelle 70 empfängt auch Befehle vom Benutzer, der beispielsweise mehr Information zu bestimmten Alarmen anfordert, sie ändert Alarm oder Filtereinstellungen, neue Alarmanzeigen etc. und stellt diese Information der Verarbeitungseinheit 64 zur Verfügung, die dann die angeforderten Maßnahmen ergreift, die Datenbank nach Alarminformation, etc. durchsucht, um eine neue Alarmsicht dem Benutzer über die Anzeige 69 zur Verfügung zu stellen.
Allgemein gesprochen gibt es verschiedene Kategorien von Alarmen, die erzeugt und auf der Anzeige 69 angezeigt werden können, beispielsweise Prozeßalarme, Gerätealarme und Hardware-Alarme. Prozeßalarme, die bekannt sind und typischerweise von Funktionsblöcken oder Modulen innerhalb einer Prozeßsteuerungsroutine erzeugt werden, die von einem Controller oder einem Feldgerät ausgeführt wird, sind in der Vergangenheit an eine Benutzer-Schnittstelle gesendet und dort angezeigt worden. Prozeßalarme zeigen im allgemeinen ein Problem mit dem funktionalen Betrieb der Prozeßsteuerungssoftware an, d. h. ein Problem mit der Prozeßsteuerungsroutine selbst, wie Messungen außerhalb einer Grenze, abnormale Abweichungen zwischen Prozeßparametern und Einstellpunkten, etc. Prozeßalarme sind typischerweise als Komponenten eines Prozeßsteuerungsmoduls konfiguriert und können in der Konfigurationsinformation, die auf der Benutzerschnittstelle vorgesehen ist, als mit einem Modulnamen verbunden erscheinen. Einige Arten oder Typen von Prozeßalarmen beinhalten fehlerhafte Eingabe/Ausgabe, Messungen außerhalb von Grenzen, überschrittene Schwellen, etc. Da Prozeßalarme aus dem Stand der Technik bekannt sind, werden sie hierin nicht weiter im Detail beschrieben werden.
Gerätealarme sind Alarme, die mit dem Betrieb von Feldgeräten innerhalb des Prozesses zusammenhängen und durch Software (beispielsweise die Software 53 in 1) innerhalb der Feldgeräte oder anderer Geräte erkannt werden können, die innerhalb des Prozesses verbunden sind, um ein Problem oder einen Fehler mit dem Betrieb eines Feldgerätes anzuzeigen. Gerätealarme können in der Benutzerschnittstelle des hierin beschriebenen Systems als mit einem bestimmten Gerät in Verbindung stehend erscheinen. Gerätealarme können beispielsweise anzeigen, daß der Druck in einem Ventil zu groß oder zu klein für einen geeigneten Betrieb des Ventils ist, daß der Motorstrom in dem Ventil zu hoch oder zu niedrig ist, daß die Spannungspegel eines Geräts nicht synchronisiert sind, daß ein Ventilstöpsel innerhalb des Ventils festsitzt, daß das Gerät nicht richtig kommuniziert, daß das Gerät eine vorgesehende Wartung benötigt, da beispielsweise eine bestimmte Zeitdauer abgelaufen ist oder da ein Ventilteil des Gerätes seit der letzten Wartung einen bestimmten Wegbetrag durchgemacht hat, etc. Gerätealarme können auf irgendeine gewünschte Art erzeugt werden, umfassend den Gebrauch von proprietärer oder nicht-proprietärer Software, die im Gerät selbst oder in anderen Geräten, die mit dem Gerät verbunden sind, für welches der Alarm erzeugt wird, lokalisiert ist, um spezifische Probleme mit dem Gerät zu erkennen und detektieren und einen dazu entsprechenden Alarm zu erzeugen. Wie oben angedeutet, werden mittlerweile viele intelligente Geräte hergestellt, um Gerätealarme zu erzeugen und zu kommunizieren.
Selbstverständlich können viele verschiedene spezifische Typen oder Arten von Gerätealarmen existieren, umfassend beispielsweise Ausfallalarme, die anzeigen, daß innerhalb eines Gerätes eine Ausfall- oder Schwächebedingung existiert, Wartungsalarme, die anzeigen, daß eine bestimmte Art von Wartung erfolgen sollte, Kommunikationsalarme, die anzeigen, daß das Gerät gestoppt hat, richtig zu kommunizieren, oder jeder Empfehlungsalarm etc. Ein Störungs-(beispielsweise ein Ausfall-)Alarm zeigt an, daß das Gerät eine Bedingung oder Bedingungen erkannt hat, die anzeigen, daß es nicht eine kritische Funktion ausführen kann und folglich unmittelbare Wartung erfordert. Jedesmal, wenn die Ausfallalarm-Bedingung wahr ist, wird die Integrität des Gerätes als schlecht angenommen (und folglich verursacht dies auch die Annahme, daß die Integrität des Controller-Knotens, mit dem das Gerät verbunden ist, schlecht ist). Ein Wartungsalarm zeigt an, daß das Gerät imstande ist, kritische Funktionen auszuführen, aber eine Bedingung oder Bedingungen erkannt hat, die zu einem Ausfall führen können, falls sie unbeachtet bleiben, und folglich sollte das Gerät bald Wartung erhalten. Ein Kommunikationsalarm (beispielsweise „nicht kommunizierend”) wird aktiv, wenn ein Gerät das Kommunizieren stoppt. Wann immer die Nicht-Kommunizieren-Alarmbedingung wahr wird, wird die Integrität des Gerätes als schlecht angesehen (und führt folglich dazu, daß die Integrität des Controller-Knotens, mit dem das Gerät verbunden ist, schlecht ist). Ein Empfehlungsalarm zeigt an, daß das Gerät Bedingungen erkannt hat, die nicht in andere Kategorien fallen. Gewöhnlich ist ein Empfehlungsalarm ein Alarm, der für einzelne Geräte speziell für den Typ des Gerätes vorgesehen ist, wie ein Durchflußmesser, der die Variabilität des Flußsignals verfolgt. In diesem Fall kann das Gerät erkennen, daß eine Variabilität in einigen Signalen in Verbindung mit dem Gerät zu hoch oder zu niedrig ist, was bedeutet, daß etwas Ungewöhnliches geschehen ist und einiger Untersuchung bedarf. Abhängig von dem Gerät können Empfehlungsalarme mehr oder weniger dringende Aufmerksamkeit erfordern als Wartungsalarme und demzufolge würden Benutzer wahrscheinlich die Priorität des Empfehlungsalarms niedriger setzen als die des Wartungsalarms. Selbstverständlich können Ausfall-, Wartungs- und Empfehlungsalarme nicht von jedem Gerät unterstützt werden und ein einzelner, alle Alarme erfassender Alarm, wie ein „abnormal”-Alarm für generische Geräte kann anstelle der Ausfall-, Wartungs- und Empfehlungsalarme genutzt werden, was in zwei Gesamtalarmen resultiert, d. h. nicht-kommunizierend und abnormal. Selbstverständlich könnten andere Typen von Gerätealarmen anstelle der oder zusätzlich zu den oben diskutierten erzeugt und genutzt werden.
Selbstverständlich kann auch das Problem, das einige der Gerätealarme, wie Kommunikationsalarme und Ausfallalarme, verursacht, einen oder mehr Prozeßalarme verursachen, die von der Prozeßsteuerungs-Software erzeugt werden. Insbesondere zeigt ein Kommunikationsalarm an, daß die Kommunikationsverbindung mit dem Gerät unterbrochen ist und folglich der mit dem Gerät verbundene Prozeßcontroller nicht weiß, was innerhalb des Geräts vor sich geht. Als Resultat kann Prozeßsteuerungs-Software wie Funktionsblöcke, die Information von dem Gerät erwartet, Prozeßalarme erzeugen, die anzeigen, daß die Prozeßschleife fehlerhaft ist.
Allgemein gesprochen sind Hardwarealarme Alarme, die Probleme mit einer Workstation, einer Datenbank, einem Controller, einem E/A-Gerät oder anderem Hardware-Gerät anzeigen, neben einem Feldgerät, das innerhalb eines Prozeßsteuerungssystems genutzt wird. Hardwarealarme können beispielsweise E/A-Nichtverfügbarkeiten oder Geräte anzeigen, die Probleme mit der Kommunikationsintegrität berichten. Insbesondere werden Hardwarealarme genutzt, um Benutzer auf Ausfälle von Hardwarekomponenten des Systems aufmerksam zu machen und sie können an der Benutzerschnittstelle als mit einem Knoten, in welchem der Ausfall erkannt worden ist, zusammenhängend erscheinen. Da Hardware-Alarme benutzt werden können, um Benutzern und Wartungspersonal Hardwareausfälle innerhalb eines Knotens mitzuteilen, verbessern Hardwarealarme bekannte Knotenintegritäts-Mitteilungssysteme. Beispielsweise kann Software (beispielsweise die Software 51 oder 52 in 1) innerhalb des mit dem E/A-Gerät verbundenen Controllers den E/A-Kartenausfall als einen Hardwarealarm berichten, falls eine 8-Kanal-E/A-Karte ausfällt. Dies unterscheidet sich von der Vergangenheit darin, daß der Benutzer einen Ausfall einer E/A-Karte nur auf Grundlage der Erzeugung einer Anzahl von Prozeßalarmen ableiten konnte, die durch die Unterbrechung in den Prozeßsteuerungsroutinen verursacht wurden, die unter Nutzung der fehlerhaften E/A-Karte ausgeführt wurden.
In einer Ausführungsform kann jede Hardwarekomponente zwei Typen von Hardwarealarmen erzeugen, umfassend einen „nicht-kommunizierend”-Alarm und einen „ausgefallen”-Alarm. Der „nicht-kommunizierend”-Alarm wird erzeugt, wenn ein Gerät nicht kommuniziert. Dieser Alarm kann von dem Gerät stammen, das Kommunikationsprobleme hat, oder von einem andern Gerät erzeugt werden, das eine Kommunikation erwartet von dem Gerät, für das der Alarm erzeugt wird, und die Kommunikation nicht nach einer Zeitlimitperiode empfängt, oder von einem Gerät, welches das ausgefallene Gerät für eine Kommunikation anruft, aber keine Antwort empfängt. Andererseits kann der „ausgefallen”-Alarm aktiv werden, wenn die Komponente kommuniziert, aber einen oder mehrere Ausfälle innerhalb der Komponente erkannt hat (beispielsweise einen ausgefallenen Kanal in einer E/A-Karte). „Ausgefallen”-Alarme können sich unterscheiden, basierend auf dem Typ eines Hardwaregerätes, zu dem der Alarm gehört. Beispielsweise kann für Controller eine ausgefallen-Alarmbedingung von einem Controller im standby resultieren, der nicht fähig ist, eine Umschaltung anzunehmen (für eine längere Periode als die normale Synchronisationszeit), oder wenn der Controller keine Konfiguration hat. Für lokale Anwendungsstationen kann sich eine ausgefallen-Alarmbedingung von der Anwendungsstation ergeben, die keine Konfiguration hat. Für konventionelle E/A-Karten kann sich eine ausgefallen-Arlarmbedingung von einem ausgefallenen Kanal, einem Bereitschaftsbetrieb, in dem kein Umschalten akzeptiert wird (für eine längere Periode als die normale Synchronisationszeit), etc. ergeben. Für AS-Schnittstellen-E/A-Karten kann sich ein „Ausgefallen”-Alarm aus einem ausgefallenen Anschluß, einem Anschluß-Gerätekommunikationsausfall, einem Anschluß-Geräteabnormal-Status, einem nicht angenommenen Umschalten (für eine längere Periode als die normale Synchronisationszeit) ergeben. Für Feldbus H1, Profibus E/A und serielle E/A-Karten und dergleichen kann ein „Ausgefallen”-Alarm anzeigen, daß ein bestimmter Anschluß ausgefallen ist, daß ein Anschluß-Gerätekommunikationsausfall existiert, daß ein Anschluß-Geräteabnormalstatus vorliegt, daß eine Bereitschaftsbetrieb-Karte nicht richtig arbeitet, etc.
Da Hardwareausfälle auch in Gerätealarmen oder Prozeßalarmen resultieren können, kann die effiktive Priorität von allen Gerätealarmen für alle Geräte, die über eine Hardwarekomponente kommunizieren, welche einen Ausfall durchmacht, auf eine niedrige Prioritätsstufe wie 3 durch die Alarmverarbeitungseinheit 64 gezwungen werden. Dies wird effektiv alle Geräte und Prozeßalarme von der Benutzeranzeige für Geräte, die von diesem Hardwareausfall betroffen sind (wie einem Anschlußausfall), entfernen, bis die Hardwareeinheit in den Kommunikationsstatus zurückgeht.
Wie verstanden werden wird, werden Geräte- und Hardwarealarme benutzt, um Benutzer auf Ausfälle und andere Bedingungen aufmerksam zu machen, die in mit dem System verbundenen Geräten erkannt wurden, vor allem intelligente Geräte, die mit Controllern über verschiedene Feldbus-Technologien, wie Feldbus, HART, Profibus, etc. und mit anderer Harware, wie E/A-Geräte, Controller, Anwendungs-Workstations, etc. verbunden sind. Während die vorhergehende Diskussion die bevorzugten Benutzerschnittstellenelemente beschreibt, die sich auf Gerätealarme und Hardwaralarme unter Nutzung von Feldbus-Geräte-Alarmen bezieht, wird erwartet, daß Geräte- und Hardware-Alarme von anderen intelligenten E/A- und Steuerungssystemen ebenso benutzt werden könnten.
Wie oben angemerkt, werden die verschiedenen Kategorien von Alarmen, umfassend Prozeßalarme, Gerätealarme und Hardwarealarme, an die Alarmschnittstellen-Software 50 gesandt und von dieser empfangen, um sie potentiell auf dem Anzeigegerät 69 in einem passenden Mitteilungsformat anzuzeigen. Die aktuellen Alarme, die auf dem Anzeigegerät 69 dargestellt sind, sind durch den Bereich des Zugriffs auf die Workstation und Benutzer und durch die Filtereinstellungen des Filters 68 bestimmt, der konfiguriert werden kann, um unter Nutzung einiger gewünschter Kriterien Alarme anzuzeigen, wie die Kategorie eines Alarms (beispielsweise Prozeß, Gerät oder Hardware), der mit dem Alarm verbundenen Priorität, etc. Durch Benutzung dieser Software werden verschiedene Kategorien von Alarmen in derselben Schnittstelle integriert, um einen Benutzer mit mehr Information, welche den fehlerhaften Betrieb des Prozeßsteuerungssystems betrifft, im Gegensatz zu früher zu versorgen, wo ein Benutzer nur Prozeßalarme überwachen konnte und diese Prozeßalarme nutzen mußte, um zu bestimmen, ob Geräte- oder Hardware-Ausfälle aufgetreten sein könnten, welche die Prozeßalarme verursachen. Mit der hierin beschriebenen integrierten Anzeige kann ein Benutzer aktuelle Geräte- und Hardwarealarme auf demselben Bildschirm oder Anzeigegerät wie Prozeßalarme betrachten und er kann jeden der Alarme auf dieselbe Art behandeln, was den Benutzer in den Stand versetzt, schneller und leichter zu bestimmen, ob ein oder mehrere Prozeßalarm(e) tatsächlich gerade ein Resultat eines fehlerhaften Gerätes oder fehlerhafter Hardware, etc. sind. Desgleichen kann der Benutzer auf die Geräte- und Hardwarealarme auf dieselbe Art, auf die der Benutzer sich mit Prozeßalarmen befaßt, einwirken und sich mit diesen befassen, so daß das Reagieren auf jede diese Kategorien von Alarmen dieselben Typen von Benutzertätigkeiten erfordert, was für den Benutzer einfacher ist.
Es gibt selbstverständlich viele Wege, auf welchen die verschiedenen Kategorien von Alarmen auf eine integrierte Art an einer Benutzerschnittstelle angezeigt werden können. Zwei dieser Benutzeranzeigen sind hierin beschrieben. In einer Ausführungsform werden die Prozeß-, Geräte- und Hardwarealarme ähnlich dem Weg behandelt, auf welchem Prozeßalarme traditionell auf einer Anzeige behandelt worden sind. Als Ergebnis kann ein Benutzer Geräte- und Hardwarealarme anerkennen oder unterdrücken, genauso wie Prozeßalarme anerkannt oder unterdrückt werden. Ebenso können Geräte- und Hardwarealarme auf eine Art angezeigt werden, die den Typ, die Priorität, den Namen, den Bereich des Prozesses, den Zustand, etc. des Alarms anzeigen. Es kann auch eine primäre Überwachungsanzeige, die mit einem Alarm zusammenhängt, dem Benutzer präsentiert werden, wobei die primäre Überwachungsanzeige eine Anzeige ist, die geschaffen ist, um dem Benutzer zu helfen, die Quelle des Alarms oder die Funktionalität der Hardware oder eines Softwareelements assoziiert mit dem Alarm zu verstehen oder zu sehen, wie das Modul, eine Prozeßschleife, ein Gerät, ein Knoten, ein Bereich, etc., für welches der Bereich erzeugt worden ist oder mit welchen der Alarm assoziiert ist,. Eine primäre Überwachungsanzeige kann beispielsweise sein ein physikalisches Bild eines Gerätes, ein digitales Bild oder eine digitale Zeichnung des Raumes oder des Bereiches, in welchem ein Gerät sich befindet, andere Information assoziiert mit dem Gerät wie ein Teil einer Anlagenzeichnung, eine Diagramm- oder Konzeptionszeichnung, die die Verbindung zwischen dem Gerät in der Anlage während der Implementierung darstellt, etc. Primäre Überwachungsanzeigen für Alarme können von Benutzern erzeugt und beispielsweise auf Module (für Prozeßalarme), auf Geräte (für Gerätealarme) und auf Knoten (für Hardwarealarme) oder auf Bereiche oder Abschnitte der Anlage, die mit dem Alarm assoziiert sind, ausgerichtet werden. Die primären Überwachungsanzeigen können auch auf verschiedene Funktionen abgestimmt sein. Beispielsweise können primäre Überwachungsanzeigen für Prozeßalarme auf Prozeßbetriebsfunktionen, primäre Überwachungsanzeigen für Gerätealarme auf Feldgeräte-Wartungsfunktionen und primäre Überwachungsanzeigen für Hardware auf Knoten-Wartungsfunktionen ausgerichtet sein. Primäre Überwachungsanzeigen für Hardwarealarme können beispielsweise sein Bilder darüber, wo der Controller sich befindet, Diagramme der E/A-Hardware des Controllers mit allen Hardwarealarm-Zuständen angezeigt, Tasten zum Navigieren zu der Einheitenübersicht oder den primären Überwachungsanzeigen, die ein Controller unterstützt, Wartungsprozedur-Prüflisten, etc. Ebenso können primäre Überwachungsanzeigen für Gerätealarme von Benutzern erzeugt werden und beispielsweise auf Geräte-Wartungsfunktionen ausgerichtet sein. Die primären Überwachungsanzeigen können in der Datenbank 66 (2) gespeichert sein und erreicht und auf der Anzeige 69 dargestellt werden, wenn ein Alarm, der die primäre Kontrollanzeige nutzt, ausgewählt ist. Selbstverständlich können dieselben oder verschiedene primäre Überwachungsanzeigen für verschiedene Alarme und primäre Überwachungsanzeigen genutzt werden.
In einer Ausführungsform ist die integrierte Alarminformation für einen Benutzer auf einer Anzeige in der Form eines Alarmsymbols (eines streifenförmigen Alarmbereichs; alarm banner) an beispielsweise einem Rand eines Anzeigeschirms vorgesehen. Nunmehr bezugnehmend auf 3 ist ein Alarmsymbol 73 an der Unterseite eines Schirms 71 plaziert. Das Alarmsymbol 73 beinhaltet eine erste Zeile, die Anzeigen verschiedener Alarme darstellt, die von dem Prozeßsteuerungssystem 10 erzeugt worden sind und die über das Filter 68 auf die Anzeige gelangt sind. Wenigstens einer der Alarme, die in dem Alarmsymbol 73 angezeigt sind, kann mit dem Bereich des Prozeßsteuerungssystems 10 in Verbindung stehen, der im Hauptteil des Bildschirms 71 dargestellt ist. Die spezifischen Alarme, die in dem Alarmsymbol 73 angezeigt sind, und die Reihenfolge dieser Alarme werden gemäß den Filtereinstellungen des Filters 68 bestimmt. Allgemein gesprochen, werden die Alarme höchster Priorität, welche nicht bestätigt oder unterdrückt worden sind, zuerst angezeigt, mit den Alarmen der nächsthöheren Priorität danach angezeigt, usw. In dem Beispielbildschirm von 3 ist der Alarm 74 höchster Priorität ein Prozeßalarm, der als mit einer PID 101 Kontrollroutine zusammenhängend dargestellt ist. Der Alarm 74 ist in rot dargestellt, um zu zeigen, daß seine Priorität kritisch ist. Auf der zweiten Zeile des Alarmsymbols 73 zeigt ein Alarminformationsfeld 76 eine Alarminformation an, die mit dem Alarm in dem Alarmsymbol in Verbindung steht, das aktuell ausgewählt ist. In dem Beispiel von 3, in dem der Alarm 74 ausgewählt ist, stellt das Alarminformationsfeld 76 dar, daß der Alarm 74 am Freitag um 12.52 Uhr und 19 Sekunden erzeugt worden ist, mit der „Kontrolle des Pegels im Tank 16” zusammenhängt, eine Bezeichnung oder einen Namen PID101/HI_HI_ALM hat, eine sehr hohe Priorität hat und ein kritischer Alarm ist. Wenn der Alarm 74 blinkt, bedeutet dies, daß der Alarm nicht bestätigt ist, während eine konstante (nicht blinkende) Alarmanzeige in dem Alarmsymbol 73 bedeutet, daß der Alarm von irgendeinem Benutzer oder Benutzer bestätigt worden ist.
Selbstverständlich könnten andere Typen von Alarminformation in dem Alarminformationsfeld 76 dargestellt werden.
Die anderen Alarmanzeigen in dem Alarmsymbol 73 wie die Alarmanzeige 78 könnten auch andere Farben wie Gelb, Lila, etc. haben, um andere Stufen von Ernsthaftigkeit oder Priorität assoziiert mit dem Alarm anzuzeigen. Wenn ein anderer Alarm ausgewählt ist, wie der Alarm 78, 80, 81 oder 82, würde Alarminformation, die diesen Alarm betrifft, in dem Alarminformationsfeld 76 angezeigt werden. Der Benutzer kann durch Betrachten eines Alarms in dem Alarmsymbol 73 die Alarme erkennen und das Wartungs- oder Ingenieur-Personal alarmieren, um die geeigneten Handlungen vorzunehmen, um die Bedingung, die zu dem Alarm führte, zu korrigieren, oder alternativ könnte er andere Schritte innerhalb des Prozeßsteuerungssystems unternehmen, wie Zurücksetzen bestimmter Einstellpunkte, um die Alarmbedingung abzuschwächen. Wenn sie nur zum Anzeigen von Prozeßalarmen benutzt wird, ist die Anzeige von 3 ähnlich einer bekannten Benutzeranzeige, die nunmehr in dem Delta-V-Steuerungssystem vorgesehen ist.
Wie oben dargestellt, wird eine primäre Überwachungsanzeige durch Auswahl eines der Alarme in dem Alarmsymbol 73 (wie der Alarm 74) für diesen Alarm auf dem Schirm 71 dargestellt. Insbesondere umfaßt der Hauptteil des Schirms 71, wie in 3 dargestellt, eine primäre Überwachungsanzeige oder Darstellung von relevanter Hardware, die mit einem bestimmten Alarm (ein ausgewählter Alarm) innerhalb des Prozeßsteuerungssystems 10 in Verbindung steht. In dem Beispiel von 3 beinhaltet die Hardware drei Tanks, die über verschiedene Ventile und Flüssigkeitsströmungslinien untereinander verbunden sind mit verschiedenen Sensoren daran angeschlossen. Diese Hardware-Darstellung ist eine Darstellung der Ausstattung innerhalb eines Bereichs des Prozesses 10 und liefert bestimmte Information über den Betrieb von bestimmter Ausstattung, wie bestimmte Ventile oder Parameter assoziiert mit den Tanks, Sensoren, etc. Selbstverständlich können einige dieser Informationen durch eine Konfigurationsinformation in der Datenbank 66 und durch Signale von den Sensoren in dem Prozeßsteuerungssystem über die Controller 12 und die Ethernet-Verbindung 40 vorgesehen werden. In diesem Fall wird eine derartige Information durch die Kommunikationsschicht 62 hochgeschickt und über irgendeine bekannte oder gewünschte Software auf der Benutzeranzeigenschnittstelle 70 vorgesehen.
Wie in 3 dargestellt, ist auch eine Frontplatte 72, die ein „virtuelles Instrument” für eine PID-Steuereinheit (Modul) darstellt, als zusätzliche Information für einen der Alarme (in diesem Fall der Prozeßalarm 74) innerhalb des Alarmsymbols dargestellt. Die Frontplatte 72 stellt weiterhin Information zur Verfügung, die hinsichtlich des ausgewählten Prozeßalarmes relevant ist und den Namen der Steuereinheit (das Modul PID 101) und bestimmte Einstellungen oder Parameter assoziiert mit diesem Modul identifiziert. Die Erzeugung einer derartigen symbolhaften Beschreibung des Prozesses wird nunmehr für Prozeßüberwachungsalarme genutzt und ist aus dem Stand der Technik bekannt und wird demzufolge nicht im Detail beschrieben. Es genügt zu sagen, daß diese oder irgendeine andere gewünschte bildhafte oder nicht-bildhafte Beschreibung eines Teils oder der Gesamtheit des Prozeßsteuerungssystems 10 auf dem Schirm dargestellt werden kann, um einen Benutzer wie einen Benutzer in den Stand zu versetzen, die Betriebsfunktionen oder Hardwarefunktionen von einigen Teilen des Prozeßsteuerungssystems 10 zu betrachten. Die Anzeigen könnten selbstverständlich bildlich oder auf andere Weise individuelle Hardwareeinheiten, in Verbindung stehende Gruppen von Hardware, Blockschaltbilder oder andere Diagramme von Teilen oder Bereichen einer Anlage, etc. darstellen.
Während in der Vergangenheit Anzeigen wie die Anzeige aus 3 imstande gewesen sind, Prozeßalarme darzustellen und durch Benutzer benutzt wurden, um Prozeßalarme zu betrachten, d. h. Alarme assoziiert mit der Software (wie Funktionsblöcke), die den Prozeßbetrieb überwacht, stellt die Alarmanzeige- und Schnittstellen-Software 50 Information über andere Kategorien von Alarmen, umfassend Geräte- und Hardwarealarme in Verbindung mit Prozeßalarmen, zur Verfügung, wenn der Benutzer das Filter 68 zum Betrachten derartiger Alarme eingestellt hat.
Nunmehr bezugnehmend auf 4 wird eine weitere integrierte Alarmanzeige dargestellt, die verschiedene Kategorien von Alarmen dargestellt in dem Alarmsymbol 73 aufweist. Insbesondere ist in 4 der erste Alarm 90 mit höchster Priorität ein Gerätealarm assoziiert mit einem Ventil 101, der Alarm 92 mit zweithöchster Priorität ein Hardwarealarm assoziiert mit einem Controller und der dritte Alarm 94 ein Prozeßalarm assoziiert mit dem Prozeßsteuerungsmodul PID 101. Die Alarminformation für den Gerätealarm 90, der in 4 ausgewählt ist, ist in dem Alarminformationsfeld 76 dargestellt. Die Information für den Gerätealarm 92 beinhaltet Information, die die Zeit, zu der der Alarm erzeugt worden ist, die Priorität und den Namen des Gerätes zusammen mit einer Information über die Gefährlichkeit und Priorität des Alarms betrifft. Ebenso ist die primäre Überwachungsanzeige für das Ventil 101 auf dem Schirm 71 (der übrigens dieselbe primäre Überwachungsanzeige wie der Prozeßalarm 74 in 3 ist) dargestellt. Eine Frontplatte 98 für das Ventil 101 ist auch dargestellt. Die Frontplatte 98 ist einzig für einen Gerätealarm entworfen und wird detaillierter mit Rücksicht auf die 8 und 9 erläutert werden.
Als ein Beispiel ist in 5 eine Alarmsymbolinformationsanzeige für einen Prozeßalarm dargestellt, wobei diese Alarmsymbolinformation ähnlich der ist, die für Prozeßalarme in der Vergangenheit vorgesehen war. Eine beispielhafte Alarmsymbolinformationsanzeige für einen Gerätealarm (FV-101), die das Alarminformationsfeld dafür umfaßt, ist in 6 dargestellt. In dieser Anzeige ist „FV-101” ein Benutzer-konfigurierter Name des Gerätes; „Reaktor 1 inlet valve” ist eine Benutzer-konfigurierte Beschreibung in Verbindung mit dem Gerät und „FAIL_ALM” ist ein nicht-konfigurierbarer Name des Gerätealarm-Parameters. Die Alarmparameter-Namen können beispielsweise COMM_ALM für „nicht-kommunizierend”-Gerätealarme, FAIL_ALM für „ausgefallen”-Gerätealarme, MAINT_ALM für „Wartungs”-Gerätealarme und ADVICE_ALM für „Empfehlungs”-Gerätealarme sein. In 6 ist auch „FAILED” das nicht-konfigurierbare Alarmwort aus einem Satz von potentiellen Alarmwörtern, die COMM, FAILED, MAINT und ADVICE sind. „CRITICAL” ist der Alarmprioritätstext und „I/P FEEDBACK LIMIT: 103.47” ist eine nicht-konfigurierbare Zeichenkette, die basierend auf dem Gerät, der Revision und der von dem Gerät erhältlichen Information bestimmt ist. Für Alarme, die von der Foundation Fieldbus Alarmbenennung erkannt worden sind, würde die Zeichenkette von den Daten der Alarmbotschaft abhängen und optional einen numerischen „Wert” beinhalten, der in die Zeichenkette geeignet eingefügt ist.
Da von Foundation Fieldbus Geräten nicht erwartet wird, daß sie über irgendwelche andere Bedingungen berichten, die zu einem Alarm beitragen, während die erste Bedingung in dem Alarm aktiv ist, beschreibt die Botschaft, die in dem Alarmsymbol erscheint, die erste erkannte Bedingung. Der für den Alarm dargestellte Zeitstempel (und dieser wird beim Sortieren von Alarmen in einem Alarmsymbol und Alarmzusammenfassungs-Anzeigen benutzt) ist die Zeit, zu der der Alarm zuerst in einen aktiven Zustand gegangen ist. Beispiele typischer Arten von Gerätealarmbotschaften sind NVM write count limit: 100001: Output block time-out: Pressure derivative limit: pressure high limit: Pressure low limit: I/P Feedback limit: Temperature high limit: Temperature low limit: Travel daviation: 25.67 servo units: Travel high limit: Travel high-high limit: Travel low limit: Travel low-low limit: Travel accumulation limit: cycle count limit: Drive failure, etc.
Ebenso ist als Beispiel ein Alarmsymbol für einen Hardwarealarm in 7 dargestellt. In dieser Anzeige ist „CTLR 1” ein Benutzer-konfigurierter Name des Knotens; „Room 4, cab, 3, pos 2” ist eine Benutzer-konfigurierte Beschreibung assoziiert mit dem Knoten und „CARD04_FAIL” ist ein nicht-konfigurierbarer Name eines Alarmparameters. Die Alarmparameternamen können beispielsweise NODE_COMM für einen „nicht-kommunizierenden” (standby) Knotenhardwarealarm, NODE_FAIL für einen „ausgefallen” (standby) Knotenhardwarealarm, CARDxx_COMM for I/O-Card „nicht-kommunizierend”-Hardwarealarme, CARDxx_FAIL for I/O-Card „ausgefallen”-Hardwarealarme, etc. sein. Ferner ist in 7 „failed” der nicht-konfigurierbare Alarmtext mit den möglichen Alarmtexten, die beispielsweise COMM für „nicht-kommunizierend” Knoten- oder E/A-Kartenhardware-Alarme und FAILED für „ausgefallen” Knoten- oder E/A-Kartenhardware-Alarme sind. „CRITICAL” ist der Alarmprioritätstext und „CHANNEL 7 FAILED” ist eine Beschreibung bestimmt basierend auf der Bedingung in dem Knoten oder der E/A-Karte, die zu dem Alarm beitragen. Die Botschaft, die in dem Symbol erscheint, beschreibt den letzten Wechsel der Bedingung (die Bedingung wird entweder aktiv oder inaktiv), der erkannt wurde, während der Alarm in einem aktiven Zustand ist. Der für den Alarm dargestellte Zeitstempel (welcher beim Sortieren von Alarmen in einem Alarmsymbol und anderen Alarmanzeigen benutzt werden kann) ist die Zeit, zu der der Alarm zuerst in einen aktiven Zustand gegangen ist.
Anhand der 5 bis 7 kann gesehen werden, daß die Information, die in dem Alarmsymbol-Informationsbereich dargestellt wird, ähnlich für jeden der verschiedenen Kategorien von Alarmen ist, die auf der Benutzerschnittstelle angezeigt oder angedeutet werden. Ebenso teilen sich die Alarmanzeigen dieselben Anzeigemerkmale wie Blinken, Farbe, etc., die auf der Priorität, aktiven, Bestätigungs-Status des Alarms trotz der Kategorie des Alarms basieren. Auf diese Art sind Alarme verschiedener Kategorien auf dem Anzeigeschirm integriert, beispielsweise zusammen dargestellt und ähnlich behandelt basierend auf den wesentlichen Parametern der Alarme.
Nunmehr bezugnehmend auf die 8 bis 10 sind beispielhafte Frontplattenanzeigen für Geräte- und Hardwarealarme dargestellt. Insbesondere stellt 8 bildlich eine Frontplattenanzeige für ein Gerät FV-101 dar, das die verschiedenen Alarmkategorien, die für dieses Gerät zur Verfügung stehen (in diesem Fall NO COMM, FAILED, MAINT und ADVICE Alarme), darstellt. Für jede dieser Kategorien von Alarmen ist eine ACK-Taste (Anerkennungs-Taste) vorgesehen, so wie eine Aktivierungs-Taste (EN) und eine Unterdrückungs-Taste (SUP). Der Benutzer kann durch Benutzung dieser Kontrollen die verschiedenen Arten von Alarmen für dieses Gerät anerkennen, aktivieren (oder deaktivieren) und unterdrücken. Ebenso versetzen Prioritätseinstellungskontrollen einen Benutzer in die Lage, die Priorität von Alarmen für dieses Gerät einzustellen. Die Details-Taste kann benutzt werden, um andere Anwendungen aufzurufen, welche zum Zugriff auf dieses Gerät oder zum Herausfinden anderer Informationen über das Gerät benutzt werden kann. Jede bekannte Anwendung aus dem Stand der Technik kann für diesen Zweck benutzt werden; diese Anwendungen werden hierin nicht beschrieben. Noch weitere aktive Alarme werden angezeigt unter Nutzung konsistenter Farb- und Blinkmerkmale, ähnlich den Alarmanzeigen in dem Alarmsymbol. 9 stellt eine primäre Überwachungsanzeige für ein generisches Gerät dar, die zwei Kategorien von Alarmen hat, nämlich einen NO COMM- und einen ABNORMAL-Alarm.
Falls gewünscht, wird auch durch Nutzung der Alarmsymbol-Tasten zum Aufrufen einer primären Kontrollanzeige für einen Gerätealarm eine Frontplatten-Anzeige aufgebracht wie die der 8 oder 9, die die wichtigsten aktiven Gerätealarme für das Gerät zeigen. Beispielsweise würden bis zu einer bestimmten Anzahl, beispielsweise fünf, wichtigste Gerätealarme in dem Gerät angezeigt, unter Nutzung konsistenter Farbe und Blinkens als Darstellung in dem Alarmsymbol. Es ist auch möglich, unter Nutzung der Anzeigen der 8 und 9 die effektive Priorität aller Gerätealarme in dem Gerät anzuerkennen, zu deaktivieren oder einzustellen. Es ist auch möglich, eine Anzeige zu öffnen, die eine Zusammenfassung aller aktiven Gerätealarme in dem Gerät zeigt (wird im Detail unten diskutiert).
Ebenso stellt 10 eine Beispiel-Frontplatte für ein Hardwaregerät dar, in diesem Fall einen als CTLR1 bezeichneten Controller. Die Frontplatte von 10 stellt die verschiedenen verfügbaren Alarme dar, wie CTRL_FAIL, CARD1_FAIL, etc., die einen Bereich des Knotens und die Alarmkategorie (Ausfall- oder Kommunikations-Alarm) anzeigen. Wiederum kann, falls gewünscht, die Hardware-Frontplatte die wichtigsten aktiven Hardwarealarme für diesen Knoten zeigen. Beispielsweise bis zu einer bestimmten Anzahl, beispielsweise fünf, würden die wichtigsten Hardwarealarme in dem Knoten angezeigt, unter Nutzung konsistenter Farbe und Blinkens als die Darstellung in dem Alarmsymbol. Es ist möglich, unter Nutzung der Frontplatten-Anzeige, die effektive Priorität aller Hardwarealarme in dem Knoten anzuerkennen, zu deaktivieren oder einzustellen. Es ist auch möglich, eine Anzeige zu öffnen, die eine Zusammenfassung aller aktiven Hardwarealarme in den Knoten zeigt, durch Drücken des der Summary-Taste auf der Frontplatten-Anzeige in 10.
Allgemein gesprochen folgt die Reihenfolge in einer Ausführungsform wie der in den 3 und 4 dargestellten, in der die Alarmanzeigen in dem Alarmsymbol 73 erscheinen, einem Satz von Ordnungsregeln, die dynamisch durch einen Nutzer wiederkonfiguriert oder geändert werden können oder auch nicht. Ein Beispiel eines Satzes derartiger Regeln lautet wie folgt: (1) Nicht bestätigte Alarme erscheinen vor bestätigten Alarmen. (2) Für Alarme mit der demselben Bestätigungsstatus erscheinen Alarme, die aktuell aktiv sind, vor denen, die gelöscht worden sind (bevor sie bestätigt wurden). (3) Für Alarme mit demselben Bestätigungs- und Aktivitätsstatus erscheinen Alarme mit höheren Prioriäten vor Alarmen mit niedrigeren Prioritäten. (4) Für Alarme mit demselben Bestätigungs-, Aktivitätsstatus und derselben Priorität erscheinen Alarme, die früher aufgetreten sind, vor denen, die zu längst vergangenen Zeiten aufgetreten sind.
In einer Ausführungsform können verschiedene Arten von Information für eine Anzeige über jeden aktiven Alarm in dem Alarminformationssymbol verfügbar sein, umfassend einen Alarmidentifizierer („<container name>/alarm parameter name”), einen Einheitsnamen, die Zeit des Auftretens, eine mit dem <container name> assoziierte Beschreibung, einen Alarmtext und einen Prioritätstext. Der container name könnte beispielsweise ein Modulname für Prozeßalarme, ein Gerätename für Gerätealarme und ein Knotenname für Hardwarealarme sein.
Vorzugsweise können Benutzer Alarmprioritäten konfigurieren, so daß ein <container name> höchstens einmal in dem Alarmsymbol erscheint, so daß ein Einheitsname (falls einer existiert) in den Alarmsymbol-Tasten anstelle des <container name> erscheint, und so daß der Einheitsname höchstens einmal in dem Alarmsymbol erscheint. Es ist auch möglich, das Alarmsymbol 73 zu konfigurieren, um Alarme über Kategorie, oder über Typ, oder über eine Prioritätsschwelle (Alarme unterhalb der Schwelle werden nicht gezeigt) auszufiltern. Begrifflich könnte die Konfiguration verwirklicht werden unter Nutzung eines Fensters ungefähr wie das in 11 dargestellte, wobei ein Benutzer die Kategorie eines anzuzeigenden Alarmes (beispielsweise eines Prozeß-, Hardware- oder Gerätealarmes) und die Prioritätsstufe für die Alarme dieser Kategorie wählen kann. Diese Einstellungen werden in den Filtereinstellungen gespeichert und von dem Filter 68 genutzt, um einzustellen, welche Alarmanzeigen dem Benutzer über das Alarmsymbol 73 angezeigt werden. Selbstverständlich kann der Benutzer oder Benutzer in der Lage sein, die Filtereinstellungen einzurichten, um einige der Typen, Kategorien, Prioritäten, etc. von Alarmen zu verschiedenen Zeiten auszufiltern, um dadurch das Alarmsymbol an seine oder ihre Bedürfnisse zu dieser Zeit anzupassen.
Mit dem integrierten Alarmanzeigesymbol 73 wie den in 3 und 4 dargestellten, versorgt der Bildschirm 71 einen einzelnen Benutzer mit der Information, die verschiedene Kategorien von Alarmen betrifft, in im wesentlichen demselben Format, welches seinerzeit einem Benutzer erlaubt, leichter die Probleme mit dem Prozeßsteuerungssystem zu verstehen, die aus Prozeßsteuerungs-Fehlern oder -Alarmen resultieren. Dies kann seinerseits dem Benutzer helfen, zu bestimmen, welche Geräte oder Einstellungen geändert, festgestellt, ersetzt oder gewartet werden müssen, um den Prozeß 10 zurück in die gewünschten Betriebsbedingungen zu bringen. Die integrierte Anzeige 71 ist auch sehr nützlich für den Fall, in dem eine einzelne Person wie ein Benutzer die Funktionen von Wartungs- oder Ingenieur-Personal in einem Prozeßsteuerungssystem ausführt, was im allgemeinen bei vielen kleinen Prozeßsteuerungssystemen der Fall ist. Bei diesem Gebrauch muß der Benutzer nicht verschiedene Anzeigen überwachen oder betrachten bei verschiedenen Datenbanken, um verschiedene Typen von Fehlern innerhalb des Systems festzustellen, um ein Problem zu diagnostizieren.
Wenn der Benutzer auswählt, nur Prozeßalarme zu überwachen, wandelt der Benutzer wirksam die Schnittstelle zu dem System um, in dem nur Prozeßsteuerungsalarme für den Benutzer verfügbar sind, und er kann die typischen Funktionen, die mit Bedienungspersonal in Verbindung stehen, durchführen. Trotzdem werden Alarme immer noch empfangen und in der Datenbank 66 gespeichert, für den Fall, daß der Benutzer sich entscheidet, an einem bestimmten Punkt zurückzuschalten, um mehr Kategorien von Alarmen zu überwachen. Ferner ermöglicht der Filter 68 noch einem Benutzer, die verschiedenen Kategorien von Alarmen zu überwachen und demzufolge imstande zu sein, alle Alarme zu überwachen, wenn die Anzahl von ausstehenden Alarmen nicht zu groß ist. Zu dieser Zeit kann der Benutzer versuchen, zu bestimmen, ob die Ursache für einige Prozeßalarme ein Ergebnis eines oder mehrerer Geräte- oder Hardwareausfälle ist, wie durch empfangene Hardware- und Gerätealarme bewiesen ist. Jedoch kann der Benutzer, wenn ein größeres Problem auftritt, was verursacht, daß viele Alarme erscheinen, wählen, nicht bestimmte Kategorien von Alarmen zu überwachen, wie die Geräte- oder Hardwarealarme oder Prioritäten von Alarmen, und demzufolge sich nur auf die Prozeßalarme konzentrieren, für welche er oder sie primäre Verantwortung haben dürfte. Auf diese Art kann er oder sie die Prozeß-, Geräte- oder Hardwarealarme an andere Benutzer weitergeben, die eine Version der Softwareschnittstelle 50 an verschiedenen Workstations benutzen können, um nur diese Alarme anzuzeigen. Als Ergebnis kann ein Benutzer die Alarme überwachen, von denen er oder sie denkt, daß sie hilfreich für seine oder ihre Hauptfunktion sein können, aber, wenn zu viele Alarme angezeigt werden, die Anzahl der Alarme verringern kann durch Ändern der Filtereinstellung. Dies hindert seinerseits den Benutzer daran, von zu vielen Alarmen überhäuft zu werden.
Außerdem oder zusätzlich zu einer Implementierung eines Alarmsymbols kann die Alarmanzeige- und Schnittstellen-Software 50 Software beinhalten, die Alarmzusammenfassungs-Objekte (auch hierin als Fenster, Anzeigen oder Kontrollen bezeichnet) für den Benutzer erzeugt, umfassend beispielsweise eine Zusammenfassung aktiver Alarme und eine Zusammenfassung unterdrückter Alarme. Aktive Alarm-Zusammenfassungsanzeigen können unter Nutzung einer Alarmzusammenfassungs-Kontrolle entworfen sein, die zusätzliches Filtern, Sortieren, Blättern und Kontexthandlungen zum Zusammenfassen der in dem System präsenten Alarme vorsieht. Ein derartiges Zusammenfassungskontroll-Softwaremodul 110 ist in 2 dargestellt. Die Anzeige, die von der Alarmzusammenfassungs-Kontrolle 110 erzeugt wird, kann konfiguriert werden, um verschiedene Stellen und Beträge des Anzeigebereichs besetzen. Beispielsweise können konfigurierbare Weiten von so groß wie die volle Weite des Anzeigebereichs (in den unterstützen Anzeigeauflösungen) bis so schmal wie die Hälfte der vollen Weite reichen. Konfigurierbare Höhen können beispielsweise von so hoch wie die volle Höhe des Anzeigebereichs (ausschließlich dem Framework für Navigations-Tasten und Alarmsymbole) bis so schmal wie die Hälfte der vollen Höhe reichen. Demzufolge können eine „full screen” Alarmzusammenfassung, zwei „half screen” Alarmzusammenfassungen (beide Seite an Seite und übereinander) und vier viertelgroße Alarmzusammenfassungen auf einer Anzeige unterstützt werden. Selbstverständlich können ebenso andere Größen benutzt werden.
Die Alarmzusammenfassungs-Kontrolle 110 kann konfiguriert werden, um eine Anzeige zu erzeugen, die irgendeine der Eigenschaften eines aktiven Alarms anzeigt, umfassend beispielsweise einen Containernamen (Modul/Knoten/Gerät), einen Alarmidentifizierer (Pfad) (<container name>/<alarm parameter name>), eine Beschreibung für <container name>, einen Einheitsnamen (wenn einer existiert), einen Prioritätstext, einen gesperrten Alarmstatustext (Alarmtext oder „OK”), einen aktuellen Alarmstatustext (Alarmtext oder „OK”), einen Kategorietext, die Zeit des Auftretens, die Zeit des letzten Zustands/Prioritäts-Wechsels, eine Alarmbotschaft-Zeichenkette, eine Quellknotenbezeichnung, etc.
Andere für aktive Alarme verfügbare Eigenschaften zum Kontrollieren der Darstellung oder zur Anzeigennavigation umfassend einen Alarm-Kategoriewert (1 = Prozeß, 2 = Hardware, 3 = Gerät), eine Bereichsnummer (0...99), einen numerischen Prioritätswert (4...15), einen Bestätigungszustands-Wert (1 = UNACKED, 0 = ACKED), einen gesperrten Alarmzustandswert (<0 falls aktiv), einen aktuellen Alarmzustandswert (<0 falls aktiv), einen Frontplatten-Anzeigentext für <container name>, einen primären Kontrollanzeigetext für <container name>, einen detaillierten Anzeigetext für <container name>, etc.
Ein Beispiel einer aktiven Alarm-Zusammenfassungsanzeige ist in 12 dargestellt, in der die Alarm-Zusammenfassungsanzeige-Information über die Zeit des Alarms, der Einheit, in welcher der Alarm aufgetreten (falls anwendbar), der Alarmparameter, eine Beschreibung des Alarms, der Alarmtyp, eine mit dem Alarm zusammenhängende Botschaft und die Priorität des Alarms umfaßt. Selbstverständlich kann diese und/oder andere Zusammenfassungsinformation in einem anderen Format vorgesehen sein, falls gewünscht. 13 stellt dieselbe Alarm-Zusammenfassungsinformation dar, die Farben besitzt, die zum Hervorheben der Alarme basierend auf der Priorität benutzt werden. Demzufolge sind (kritische) Alarme hoher Priorität beispielsweise in rot hervorgehoben, mittlere Alarme, wie Empfehlungsalarme, sind in gelb hervorgehoben und andere Alarme sind nicht hervorgehoben. 14 stellt die Benutzung verschiedenfarbig markierter Alarme zum Hervorheben gemäß der Alarmkategorie dar. In 14 sind Gerätealarme hervorgehoben. Selbstverständlich kann die Benutzung einer Hervorhebung oder anderer Indizien benutzt werden, um Alarme innerhalb der Alarm-Zusammenfassungsanzeige gemäß irgendeinem gewünschten Kriterium zu markieren, und das Markieren oder Hervorheben verschiedener Abschnitte der Alarm-Zusammenfassungsanzeige kann gemäß verschiedener Kriterien ausgeführt werden. Demzufolge kann das Prioritätsfeld gemäß der Priorität hervorgehoben werden, die Alarmbeschreibung und Alarmparameter können gemäß einer Alarmkategorie, etc. hervorgehoben werden.
In jedem Fall kann jedes Feld, das in einer Alarm-Zusammenfassungsanzeige angezeigt werden soll und durch die Alarmzusammenfassungskontrolle 110 erzeugt wird, irgendeine Kombination der folgenden konfigurierten Darstellungsattribute haben. Ein Hintergrundblinken basierend auf einem Bestätigungszustand, eine Hintergrundfarbe basierend entweder auf einem Prioritätswert (unter Benutzung derselben Farbregeln wie beim Alarmsymbol) oder einer Alarmkategorie und eine HASH-Überlagerung basierend auf einem aktuellen Alarmstatus. Die Alarm-Zusammenfassungskontrolle kann konfiguriert sein, um Alarme in irgendeiner gewünschten Reihenfolge zu zeigen, wie ack-Status/einen aktuellen Alarmstatus/einer Priorität/der Zeit des Auftretens (Alarmsymbol-Reihenfolge), der Zeit des Auftretens (jüngste bis älteste), der Zeit des letzten Status/Prioritäts-Wechsels (jüngste bis älteste), einem Alarmidentifizierer (<container name>/<alarm parameter name>) (alphabetisch), etc.
Die Alarm-Zusammenfassungskontrolle 110 kann konfiguriert werden, um Alarme mit 0 oder mehr der folgenden Filterkriterien anzuzeigen, (1) aktuelle Alarmsymbol-Filtereinstellung, (2) Alarmkategorie- und Prioritätsschwellen (irgendeine Kombination von Prozeß-, Hardware- und Gerätealarmen und Prioritätsschwellen für jede), (3) Bereichsname, (4) Einheitsname, (5) <container name>, (6) Erkennungsstatus (0 oder 1), (7) aktueller Alarmstatus <0, (8) Zeit des Auftretens> x Tage, y Stunden, z Minuten relativ zu jetzt oder (9) Zeit des Auftretens < x Tage, y Stunden, z Minuten relativ zu jetzt.
Wenn eine Alarmzusammenfassungsanzeige auf der Anzeige 69 dargestellt wird, kann ein aktueller Benutzer, der die geeigneten Sicherheitsschlüssel hält, die Filterkriterien ändern wie Alarmkategorie- und Prioritätsschwellen (beispielsweise irgendeine Kombination von Prozeß-, Hardware- und Gerätealarmen und Prioritätsschwellen für jede), Erkennungsstatus (0 oder 1), aktueller Alarmstatus < 0, Zeit des Auftretens > x Tage, y Stunden, z Minuten relativ zu jetzt oder Zeit des Auftretens < x Tage, y Stunden, z Minuten relativ zu jetzt, etc.
Alarm-Zusammenfassungsanzeigen können offen bleiben oder für irgendeine Zeitdauer erzeugt werden und vorzugsweise, wenn die Darstellungsattribute, Alarmreihenfolge oder Filterkriterien für eine offene Alarm-Zusammenfassungsanzeige dynamisch von einem Benutzer geändert werden, wobei die Konfiguration der Kontrolle 110 nicht geändert wird und die Änderungen fallengelassen werden, wenn die Alarm-Zusammenfassungsanzeige abgeschaltet ist. Selbstverständlich existieren hier keine Grenzen (anders als CPU-Ressourcen) in der Anzahl von Alarmen, die erscheinen können (und angezeigt werden) an einer Alarm-Zusammenfassungskontrolle.
Die Alarm-Zusammenfassungskontrolle 110 kann auch genutzt werden, um Operationen mit Bezug zu einem Alarm auszuführen, wie Bestätigen eines Alarms (normaler Parameter/Feldsicherheitsregeln werden angewandt), Unterdrücken eines Alarms (normaler Parameter/Feldsicherheitsregeln werden angewandt), Aufrufen der Anzeige für den <container name>, der einen Alarm hält, Aufrufen der primären Kontrollanzeige für den <container name>, der einen Alarm hält, Aufrufen der Detailanzeige für den <container name>, der einen Alarm hält, Starten oder Hochbringen einer Diagnoseanwendung mit dem geeigneten Modul, Gerät oder Knoten ausgewählt, d. h. ein Modul für Prozeßalarme, ein Gerät für die Gerätealarme oder einen Knoten (oder eine Karte) für Hardwarealarme.
Falls gewünscht, kann die Alarm-Zusammenfassungsanzeige, die durch die Kontrolle 110 erzeugt wird, eine „ACK_ALL”-Taste haben, die, falls für eine offene Alarm-Zusammenfassung aktiviert, genutzt werden kann, um alle nicht-bestätigten Alarme zu bestätigen, die in dieser Alarm-Zusammenfassung beinhaltet sind (d. h. die, welche die Workstation-Weiten und Benutzer-Weiten Alarmsichtkontrollen passieren und die aktuellen Filterkriterien für diese Alarmzusammenfassung passierten), umfassend nicht-bestätigte Alarme, die es in dieser Zusammenfassung gibt, aber nicht aktuell angezeigt werden. Der Effekt ist derselbe wie individuell Auswählen jedes nicht-bestätigten Alarms in der Alarm-Zusammenfassung und Bestätigen des Alarms.
Ferner kann die Alarmanzeige- und Schnittstellen-Software 50 noch eine unterdrückte-Alarm-Zusammenfassungskontrolle 112 umfassen, die eine unterdrückte-Alarm-Zusammenfassungsanzeige vorsieht. Diese Anzeige kann um eine Zusammenfassungskontrolle konstruiert sein, welche zusätzliches Filtern, Sortieren, Blättern und Kontextaktionen für unterdrückte Alarme vorsieht. Die Charakteristiken von unterdrückte-Alarm-Zusammenfassungskontrollen 112 sind ähnlich denen für aktive-Alarm-Zusammenfassungskontrollen 110 wie oben beschrieben, außer daß die unterdrückte-Alarm-Zusammenfassungskontrolle 110 auch konfiguriert werden kann, um irgendeine der folgenden Eigenschaften eines aktiven Alarms anzuzeigen, umfassend <container name> (Modul/Knoten/Gerät), den Alarmidentifizierer (Pfad) (<container name>/<alarm parameter name>), eine Beschreibung für <container name>, ein Einheitsnamen (falls einer existiert) und eine Zeit der Unterdrückung.
Zusätzlich können Einheits- oder Anlagenbereichsalarmanzeigen erzeugt werden, um alle oder eine Gruppe von Alarmen zu zeigen, die mit einer Einheit oder einer Anlage oder anderen logischen Gruppierungen von Hardware innerhalb des Prozeßsteuerungssystems 10 in Verbindung stehen. Eine Anlagenbereichsanzeige kann eine Liste aller Anlagenbereichsnamen vorsehen und für jeden Anlagenbereich eine Kontrolle vorsehen, die zeigt, wenn der Bereich innerhalb des Sichtbereichs der Workstation und des Benutzers (d. h. falls Alarme an- oder abgeschaltet werden können) ist, wobei der aktuelle Zustand von Alarmen an- oder abgeschaltet sein kann. Diese Kontrollen können auch zum Ändern des Zustands benutzt werden, d. h. zum An- oder Abschalten von Bereichen oder Einheiten. Die Anlagenbereichsanzeige kann auch Alarmzählungen für jeden Bereich zeigen (die Zählungen sind 0, falls der Bereich abgeschaltet ist), wie Zählungen aktiver/nicht-erkannter Prozeß-, Geräte- und Hardwarealarme, aktive Prozeß-, Geräte- und Hardwarealarme und unterdrückte Prozeß-, Geräte- und Hardwarealarme. Die Anzeige kann auch Mittel vorsehen, um eine Alarmzusammenfassungskontrolle für irgendeinen Anlagenbereich zu öffnen. Die Vorgabe-Alarmzusammenfassungskontrolle, die erscheint, kann alle Alarme in dem Bereich anzeigen (Prozeß-, Hardware- und Geräte) in beispielsweise einer ACK-Status/aktueller Alarmstatus/Priorität/Zeit des Auftretens(Alarmsymbol)-Reihenfolge. Ebenfalls, um es Benutzern zu ermöglichen, verschiedene Alarmsymbolanzeigen oder Alarmzusammenfassungsanzeigen für verschiedene Workstations zu konfigurieren, ist es möglich, den Namen der Alarmsymbolanzeige oder der Alarmzusammenfassungsanzeige auf Grundlage pro Workstation zu ändern. Selbstverständlich können alle diese Anzeigen verschiedene Kategorien von Alarmen haben, die darin auf ähnliche Arten angezeigt werden.
Falls gewünscht, hält die Alarmverarbeitungseinheit 64 einen Satz von Alarmzählungen für die Alarme, welche die Workstation-weiten Alarmsichtkontrollen passieren, und stellt diese Zählungen zum Anzeigen zur Verfügung. Alarmzählungen können beispielsweise für die aktiven/nicht-bestätigten Prozeß-, Geräte- und Hardwarealarme, für die aktiven/bestätigten Prozeß-, Geräte- und Hardwarealarme und für die unterdrückten Prozeß-, Geräte- und Hardwarealarme gehalten werden. Diese Zählungen werden vorzugsweise nicht durch die Alarmkategorie- und Prioritätsschwellen-Filtereinstellungen des Alarmsymbols beeinflußt. Beispielsweise können Gerätealarme in dem Alarmsymbol abgeschaltet werden, aber die Zählungen für Gerätealarme würden immer noch genau sein, gegeben durch die Workstationweiten Alarmsichtkontrollen.
Ferner kann die Software 50 noch einen Parameter der Alarme anzeigen, der benutzt wird, um die fünf wichtigsten Alarme in einem Gerät (oder einem Knoten) zu zeigen, die für jedes Gerät oder jeden Knoten, das Geräte- oder Hardwarealarme aktiviert hat, unterstützt werden. Diese Funktionalität ermöglicht es, zu erkennen, zu deaktivieren oder herbeizuführen die Priorität aller Gerätealarme für einen Geräte- oder Hardwarealarm für einen Knoten über einen einzelnen Parameter/ein einzelnes Feld. Ein Browser für das System kann auch durch Gerätealarme und Hardwarealarme blättern. Die Alarm-Schnittstellensoftware 50 kann die Möglichkeit unterstützen, Alarm-Parameterfelder einzelner Gerätealarme von Kontrollmodulen, die in demselben Knoten ausgeführt werden, zu lesen/schreiben.
Wie verstanden werden wird, kombiniert die Alarmanzeige- und Schnittstellensoftware 50 Prozeß-, Geräte- und Hardwarealarme auf eine Art, so daß diese verschiedenen Kategorien von Alarmen dasselbe Verhalten teilen und beispielsweise Alarmprioritätstexte, Farbkodierung, Erkennungsverhalten etc. teilen können. Falls gewünscht, kann eine individuelle Alarm-Bestätigung und -Unterdrückung genauso wie für alle diese Alarme arbeiten. Ein Alarme-Parameter (wie der aktuelle, in jedem Modul für Prozeßalarme vorgesehene) kann auch genutzt werden, um die fünf wichtigsten Alarme in einem Gerät oder Knoten darzustellen. Dieser Parameter kann auch zum Erkennen, Deaktivieren und Einstellen der effektiven Priorität aller Hardwarealarme für einen Knoten oder Gerätealarme für ein Gerät benutzt werden, über einen einzelnen geschriebenen Parameter/ein Feld. Da Gerätealarme und Hardwarealarme zu Anlagenbereichen gehören oder mit diesen in Verbindung stehen, kann das An-/Abschalten von Alarmen für einen Bereich die Geräte- und Hardwarealarme für diesen Bereich beeinflussen.
Wie aktuell bei Prozeßalarmen vorgesehen, werden Benutzer imstande sein, Links auf Felder von Geräte- und Hardwarealarm-Parametern in Anzeigen zu plazieren, wie die Anzeige 71, und ein Browser kann zum Aufbauen von Anzeigen genutzt werden, der das Blättern zu Geräte- und Hardwarealarmen unterstützt. Es ist auch, falls gewünscht, möglich, Alarmparameterfelder von individuellen Geräte- und Hardwarealarmen von Kontrollmodulen zu lesen/schreiben. Der Parameter-Browser, der zum Erzeugen von Modulkonfigurationen genutzt wird, wird das Blättern zu Geräte- und Hardwarealarmen unterstützen.
Selbstverständlich haben Prozeß-, Geräte- und Hardwarealarme einen Kategorieparameter, der sie voneinander unterscheidet, und dieser Parameter ist von der Alarmverarbeitungseinheit 64 lesbar. Als Ergebnis können die Alarmsymbol- und Alarmzusammenfassungs-Anzeigen konfiguriert werden, um irgendeinen der Prozeß-, Geräte-, Hardwarealarme einzuschließen/auszuschließen und sie können konfiguriert werden, um den Prozeß-, Geräte- und Hardwarealarmen unterschiedliche Erscheinungsformen zu geben, um einen Betrachter in den Stand zu versetzen, zwischen diesen verschiedenen Kategorien von Alarmen zu unterscheiden.
Falls gewünscht, kann eine Datenbank mit chronologischer Aufzeichnung von Ereignissen in einer Workstation oder einem anderen Gerät an dem Knoten, der die Software 50 ausführt, oder irgendeinem anderen Knoten gespeichert sein zum Erfassen der Zustandsänderung von Prozeß-, Geräte- und Hardwarealarmen und zum Speichern dieser Änderungen auf eine Art, daß der Werdegang der Änderungen wieder gewonnen werden kann. Die Ereignisaufzeichnung kann beispielsweise den aktuellen Alarmzustand als einen aus SUPPRESSED, DISABLED, INACT/ACK, INACT/UNACK, ACT/UNACK oder ACT/ACK speichern. Ein Vorgabezustand für ein Geräte- und Hardwarealarm ist vorzugsweise INACT/ACK. Wenn ein Download auftritt, das einen Geräte- oder Hardwarealarm erzeugt, wird kein anfänglicher Zustandswechseleintrag erzeugt, um den „anfänglichen” INACT/ACK-Zustand der Alarme aufzuzeichnen. Jedoch würden später erkannte Zustandswechsel die geeignete Alarm-Zustandswechselereignis-Aufzeichnung erzeugen.
Eine Übersicht der Prozeß-Vorgeschichte kann Standard-Filter/Sortiermerkmale benutzen, um schnell alle Prozeß-, Geräte- oder Hardwarealarmzustands-Änderungen, spezifische Kategorien von Alarmen eines einzelnen Knotens, von einem spezifischen Anlagenbereich, etc. zu finden. Beispielhafte Aufzeichnungssequenzen einer Ereignisaufzeichnung von Zustandsänderung für Prozeß- und Gerätealarme könnten wie in 15 abgebildet sein. Hier ist der Kategorietext, der für alle Alarmzustandsänderungs-Aufzeichnungen erscheint, gemäß der Kategorie des Alarms festgelegt. Die in dem Desc2-Feld dargestellte Botschaft beschreibt die Bedingung innerhalb des Alarms, der sich geändert hat. Der Text, der in dem Desc1-Feld erscheint, zeigt den Zustand der in dem Desc2-Feld beschriebenen Bedingung an: den normalen Alarmtext, falls die Bedingung aktiv ist; „OK”, falls die Bedingung inaktiv ist. Selbstverständlich können ähnliche Typen von Einträgen für Hardware und andere Kategorien von Alarmen auch in der Ereignisaufzeichnung vorgesehen werden und andere Typen von Information zum Aufzeichnen von Manipulationen der Alarme könnten auch in irgendeiner gewünschten Art in der Ereignisaufzeichnungs-Datenbank gespeichert werden.
Die Geräte- oder Hardwarealarme sind Teile von Geräten und Hardwareknoten, wie diese in der Konfigurationsdatenbank erzeugt sind. Folglich sind die Alarme als Teil der Konfiguration auf eine Art erzeugt ähnlich der Art, mit welcher andere Aspekte von Geräten und Knoten erzeugt sind. Wenn die Konfiguration in dem System erzeugt ist, können alle Geräte- und Hardwarealarm-Verhaltensweisen für das Gerät und Hardwareknoten auf „aus” durch Vorgabe gestellt werden. Während diese Alarme „aus” sind, sind Alarmparameter für die Geräte- oder Hardwareeinheiten nicht verfügbar, so daß diese Alarme nicht als Teil der Konfiguration für die Geräte oder Hardwareeinheit erscheinen und diese Alarme nicht über Konfigurations-Parameter-Browser zugänglich sind. D. h., die Geräte- und Hardwarealarme erscheinen nicht in dem System-Browser als mit den Feldgeräten und Knoten zusammenhängend. Außerdem existiert keine Laufzeit-Unterstützung für Geräte- und Hardwarealarme, und alle Geräte- und Hardware-Alarm-Kommunikationen sind angehalten, umfassend irgendein Parameter-Abrufen, das zum Aufrechterhalten von Zustandsinformation benutzt wird, die Geräte- und Hardwarealarme unterstützt.
Jedoch kann ein Benutzer Geräte- und Hardwarealarme aktivieren unter Benutzung beispielsweise einer An-/Aus- oder Kontrollkästchen-artigen Eigenschaft des Geräts oder der Hardware. Wenn die Alarme aktiviert sind, muß der Geräte- oder Hardwarename mit den Konfigurations-Systemnamen-Regeln übereinstimmen, so daß diese Namen benutzt werden können, um Alarminformation oder Botschaften von den Benutzer-Schnittstellenanwendungen und anderen Anwendungen ansprechen zu können. Insbesondere muß der Name mit Namensregeln übereinstimmen, die beispielsweise die maximale Zeichenlänge und Zeicheneinschränkungen umfassen können, und er muß den Namensraum mit Modulen, Knoten, Bereichen und DST-Namen oder anderen Namen teilen. Im allgemeinen, falls der Geräte- oder Hardwarename nicht mit den im System benutzten Namensregeln übereinstimmt, können Geräte- und Hardwarealarme nicht aktiviert werden und der Benutzer wird benachrichtigt. Die Beschreibungszeichenkette, die für das Gerät oder die Hardware eingegeben wird, erscheint in der Benutzerschnittstelle, um zu helfen, aktive Alarme zu beschreiben.
Neu konfigurierbare Eigenschaften zum Konfigurieren einer Geräte- oder einer Hardwareeinheit können den Namen der Frontplatten-Anzeige für dieses Gerät oder diesen Knoten umfassen sowie den Namen der primären Kontrollanzeige für dieses Gerät oder diesen Knoten. Wenn Geräte- oder Hardwarealarme für eine Geräte- oder Hardwareeinheit aktiviert sind, erscheint ein Alarmparameter in dem Konfigurationssystem für jeden möglichen Alarm, den das System unterstützt für diese Geräte- oder Hardwareeinheit. Information, die über das Konfigurationssystem vorgesehen ist, kann den Hersteller, den Typ und die Revision der Geräte- oder Hardeinheit umfassen, welche die Anzahl der Alarme bestimmt, die verfügbar sind, deren Namen sowie die Vorgabewerte für die einstellbaren Eigenschaften. Wenn Alarme für eine Geräte- oder eine Harwareeinheit aktiviert sind, ermöglicht das Konfigurationssystem dem Benutzer, den Namen, den Alarmtext, den Typ und die Prioritätseigenschaften jedes Gerätealarms zu erkennen und zu ändern (falls konfigurierbar). Priorität ist im allgemeinen konfigurierbar unter Nutzung der Prioritäten, die aktuell definiert sind unter Nutzung einer ähnlichen Technik, wie sie für Alarme in Modulen unterstützt wird. Beispielsweise können numerische Vorgabewerte für eine Priorität sein COMM_ALM-15 („CRITICAL”), ABNORM_ALM-11 („WARNING”), FAILED_ALM-15 („CRITICAL”), MAINT_ALM-7 („ADVISORY”), ADVICE_ALM-7 („ADVISORY”).
Um Geräte- und Harwarealarme zu unterstützen, wird es möglich sein, eine Verbindung zwischen einem Knoten und einem Anlagenbereich zu konfigurieren. Dies trifft auf alle Knotentypen zu, umfassend Controller und verschiedene Workstations und lokale und Fernknoten. Neue Knoten können mit einem Anlagenbereich 0 in Verbindung gebracht werden. Knoten, die ohne Knoten-Verbindung importiert sind, sind mit dem Anlagenbereich 0 assoziiert. Gerätealarme sind implizit mit dem Anlagenbereich assoziiert, mit dem ihr Knoten assoziiert ist.
Während die Alarmanzeige- und Schnittstellen-Software 50 als in Verbindung mit Feldbus- und Standard 4–20 mA-Geräten genutzt beschrieben worden ist, kann sie unter Nutzung irgendeines anderen externen Prozeßsteuerungs-Kommunikationsprotokolls implementiert und mit irgendwelchen anderen Typen von Controller-Software genutzt werden. Obwohl die Alarmanzeige- und Schnittstellen-Software 50, die hierin beschrieben ist, vorzugsweise als Software implementiert ist, kann sie in Hardware, Firmware, etc. und durch irgendeinen anderen Prozessor, der in Verbindung mit dem Prozeßsteuerungssystem 10 steht, implementiert sein. Folglich kann die hierin beschriebene Routine 50 in einer standardisierten Mehrzweck-CPU oder in einer speziell entworfenen Hardware oder Firmware wie gewünscht implementiert werden. Wenn sie in Software implementiert ist, kann die Software-Routine in irgendeinem Computer-lesbaren Speicher gespeichert werden, wie auf einer magnetischen Platte, einer Laserdisc oder anderem Speichermedium, in einem RAM oder ROM eines Computers oder Prozessors, etc. Ebenso kann diese Software an einen Benutzer oder ein Prozeßsteuerungssystem mittels einer bekannten oder gewünschten Liefermethode übergeben werden, umfassend beispielsweise auf einer Computer-lesbaren Diskette oder einem anderen transportablen Computerspeicher-Mechanismus oder über einen Kommunikationskanal wie eine Telefonverbindung, das Internet, etc. (welche als dasselbe oder austauschbar mit dem Bereitstellen derartiger Software über ein transportierbares Speichermedium betrachtet werden).

Claims

Alarmanzeigesystem zur Benutzung in einem Prozesssteuerungsnetzwerk, das eine Benutzerschnittstelle mit einem Anzeigemechanismus und eine Vielzahl von kommunikativ miteinander verbundenen Geräten umfasst, die zum Erzeugen und Senden von Alarme verschiedener Kategorien umfassenden Alarmbotschaften an die Benutzerschnittstelle ausgebildet sind, wobei das Alarmanzeigesystem folgendes umfasst: – einen Alarmempfänger, der zum Empfangen der Alarmbotschaften von der Vielzahl von Geräten konfiguriert ist, um eine Vielzahl von Alarmen verschiedener Kategorien zu erhalten, die mindestens zwei Alarme aus den folgenden Kategorien umfassen: – Prozessalarmkategorie mit Alarmen, die sich auf die Funktionalität der Prozesssteuersoftware beziehen, – Hardwarealarmkategorie mit Alarmen, die sich auf die Funktionalität mindestens eines Geräts bezieht, das einen Knoten im Prozesssteuersystem definiert, – Gerätealarmkategorie mit Alarmen, die sich auf mindestens ein Feldgerät beziehen, wobei die Hardware- und Gerätealarmkategorie keine Prozessalarmkategorie sind und nicht von einer Prozesssteuersoftware generiert werden; – eine Alarmverarbeitungseinheit, welche die Vielzahl von Alarmen zum Anzeigen verarbeitet, basierend auf einem vorbestimmten Kriterium zum Ermitteln eines Satzes von Alarmen zum Anzeigen, wobei die Alarmverarbeitungseinheit ausgebildet ist, alle Geräte- und Prozessalarme, die mit einem Hardwarealarm in der Vielzahl von Alarmen verbunden sind, von dem Satz von Alarmen zum Anzeigen zu entfernen; und – eine Alarmanzeigeeinheit, die Hinweise auf den Satz der Alarme zur Anzeige auf dem Anzeigemechanismus darstellt, wobei die Alarmanzeigeeinheit die Hinweise auf die Alarme verschiedener Kategorien auf eine integrierte Art auf dem Anzeigemechanismus darstellt.
Alarmanzeigesystem nach Anspruch 1, wobei die Alarmverarbeitungseinheit einen Alarmfilter umfasst, der die Vielzahl von Alarmen zum Anzeigen filtert, basierend auf dem vorbestimmten Kriterium zum Ermitteln des Satzes von Alarmen zum Anzeigen.
Alarmanzeigesystem nach Anspruch 1 oder 2, wobei die Alarmanzeigeeinheit so ausgebildet ist, dass sie einem Benutzer die Änderung von Alarmfiltereinstellungen des Alarmfilters ermöglicht, um die Alarme durch Alarmkategorien zu filtern.
Alarmanzeigesystem nach Anspruch 2 oder 3, wobei der Alarmfilter die Alarme auf Alarmkategorie-Basis filtert.
Alarmanzeigesystem nach einem der Ansprüche 2 bis 4, wobei die Alarmanzeigeeinheit so ausgebildet ist, dass sie einem Benutzer die Änderung von Alarmfiltereinstellungen des Alarmfilters ermöglicht, um Alarme nach Priorität zu filtern.
Alarmanzeigesystem nach Anspruch 1, wobei einer der Hardwarealarme mit einem Controller zusammenhängt.
Alarmanzeigesystem nach Anspruch 1 oder 6, wobei einer der Hardwarealarme mit einer Eingabe-/Ausgabe-Einrichtung zusammenhängt, die zwischen einen Controller und ein Feldgerät geschaltet ist.
Alarmanzeigesystem nach einem der vorhergehenden Ansprüche, wobei einer der Hardwarealarme mit einer Workstation zusammenhängt.
Alarmanzeigesystem nach einem der vorhergehenden Ansprüche, wobei die Alarmanzeigeeinheit Hinweise auf die Alarme verschiedener Kategorien auf eine integrierte Art unter Nutzung eines Alarmsymbols darstellt.
Alarmanzeigesystem nach Anspruch 9, wobei das Alarmsymbol so ausgebildet ist, dass es Alarmhinweise für die Alarme verschiedener Kategorien und eine Zusammenfassung für einen ausgewählten der Alarmhinweise umfasst.
Alarmanzeigesystem nach Anspruch 9 oder 10, wobei die Alarmanzeigeeinheit so ausgebildet ist, dass eine primäre Steuerungsanzeige für einen ausgewählten der Alarmhinweise in dem Alarmsymbol vorgesehen ist.
Alarmanzeigesystem nach einem der Ansprüche 9 bis 11, wobei die Alarmanzeigeeinheit so ausgebildet ist, dass sie einem Benutzer die Unterdrückung eines oder mehrerer der Alarme, die mit einem oder mehreren der Alarmhinweise in dem Alarmsymbol zusammenhängen, ermöglicht.
Alarmanzeigesystem nach einem der Ansprüche 9 bis 12, wobei die Alarmanzeigeeinheit so ausgebildet ist, dass sie einem Benutzer die Bestätigung eines oder mehrerer der Alarme, die mit einem oder mehreren der Alarmhinweise in dem Alarmsymbol zusammenhängen, ermöglicht.
Alarmanzeigesystem nach einem der Ansprüche 9 bis 13, wobei die Alarmanzeigeeinheit ausgebildet ist, um Hinweise auf die Alarme verschiedener Kategorien in einer auf der Priorität der Alarme basierenden Reihenfolge darzustellen.
Alarmanzeigesystem nach einem der Ansprüche 9 bis 14, wobei die Alarmanzeigeeinheit ausgebildet ist, um Hinweise auf die Alarme verschiedener Kategorien in einer auf dem bestätigten Status der Alarme basierenden Reihenfolge darzustellen.
Alarmanzeigesystem nach einem der vorhergehenden Ansprüche, wobei die Alarmanzeigeeinheit ausgebildet ist, um Hinweise auf die Alarme verschiedener Kategorien auf eine integrierte Art unter Benutzung eines Alarmzusammenfassungs-Fensters darzustellen, das die Alarme verschiedener Kategorien zur Anzeige zusammenfasst.
Alarmanzeigesystem nach Anspruch 16, wobei das Alarmzusammenfassungs-Fenster unterdrückte Alarme zusammenfasst, aber nicht aktive Alarme.
Alarmanzeigesystem nach Anspruch 16, wobei das Alarmzusammenfassungs-Fenster aktive Alarme zusammenfasst, nicht aber unterdrückte Alarme.
Alarmanzeigesystem nach einem der vorhergehenden Ansprüche, wobei die Alarmanzeigeeinheit ausgebildet ist, um Hinweise auf die Alarme verschiedener Kategorien darzustellen, die mit einem bestimmten Knoten in dem Prozesssteuerungssystem in Verbindung stehen.
Alarmanzeigesystem nach einem der vorhergehenden Ansprüche, wobei die Alarmanzeigeeinheit ausgebildet ist, um Hinweise auf die Alarme verschiedener Kategorien darzustellen, die mit einem bestimmten Gerät in dem Prozesssteuerungssystem in Verbindung stehen.
Alarmanzeigesystem nach einem der vorhergehenden Ansprüche, wobei die Alarmanzeigeeinheit ausgebildet ist, um Hinweise auf die Alarme verschiedener Kategorien darzustellen, die mit einer bestimmten Einheit in dem Prozesssteuerungssystem zusammenhängen.
Alarmanzeigesystem nach einem der vorhergehenden Ansprüche, wobei die Alarmanzeigeeinheit ausgebildet ist, um Hinweise auf die Alarme verschiedener Kategorien darzustellen, die mit einem bestimmten Bereich in dem Prozesssteuerungssystem zusammenhängen.
Alarmanzeigesystem nach einem der vorhergehenden Ansprüche, ferner umfassend eine Ereignisaufzeichnungs-Datenbank, die Änderungsinformation speichert, welche die Alarme verschiedener Kategorien betrifft.
Prozesssteuerungssystem, umfassend – eine Benutzerschnittstelle mit einem Anzeigemechanismus; – eine Vielzahl von kommunikativ miteinander verbundenen Geräten, die ausgebildet sind, um Alarme verschiedener Kategorien umfassende Alarmbotschaften zu erzeugen und an die Benutzerschnittstelle zu senden; – Alarmanzeigesystem gemäß einem der vorhergehenden Ansprüche.
Verfahren zum Erzeugen und Darstellen von Alarmen in einem Prozesssteuerungssystem, das eine Vielzahl von Geräten aufweist, die mit einer Benutzerschnittstelle kommunikativ verbunden sind, wobei das Verfahren folgende Schritte umfasst: – Erzeugen verschiedener Kategorien von Alarmen in der Vielzahl von Geräten, wobei die Kategorien mindestens zwei Alarme aus den folgenden Kategorien umfassen: – Prozessalarmkategorie mit Alarmen, die von einer Prozesssteuersoftware erzeugt werden, – Hardwarealarmkategorie mit Alarmen, die von einem Gerät erzeugt werden, das einen Knoten im Prozesssteuersystem definiert, – Gerätealarmkategorie mit Alarmen, die von einem Feldgerät erzeugt werden, wobei die Hardware- und Gerätealarmkategorie keine Prozessalarmkategorie sind und nicht von einer Prozesssteuersoftware generiert werden; – Senden von Botschaften, die Alarme verschiedener Kategorien umfassen, an die Benutzerschnittstelle; – Filtern der Alarme, die von der Benutzerschnittstelle empfangen werden, basierend auf einem vorgegebenen Kriterium; und – Anzeigen der Alarme verschiedener Kategorien, die den Schritt des Filterns an der Benutzerschnittstelle passieren, auf einer integrierten Anzeige, wobei alle Geräte- und Prozessalarme, die mit einem Hardwarealarm in der Vielzahl von Alarmen verbunden sind, von den Alarmen zum Anzeigen entfernt werden.
Verfahren nach Anspruch 25, wobei der Schritt des Anzeigens den Schritt des Anzeigens der Alarme verschiedener Kategorien in einem Alarmsymbol umfasst.
Verfahren nach Anspruch 26, ferner umfassend den Schritt des Befähigens eines Benutzers, einen der Alarme in dem Alarmsymbol auszuwählen und mehr Information über den ausgewählten Alarm anzuzeigen.
Verfahren nach einem der Ansprüche 25 bis 27, wobei der Schritt des Anzeigens den Schritt des Anzeigens einer Alarmzusammenfassung umfasst, die Information über die Alarme verschiedener Kategorien umfasst, die erzeugt worden sind.
Verfahren nach einem der Ansprüche 25 bis 28, ferner umfassend den Schritt des Befähigens eines Benutzers zur Auswahl des Kriteriums, das in dem Schritt des Filterns zur Steuerung der Alarme benutzt wird, die an der Benutzerschnittstelle angezeigt werden.
Verfahren nach Anspruch 29, wobei der Schritt des Filterns den Schritt des Filterns basierend auf einer Alarmkategorie umfasst.
Verfahren nach Anspruch 29 oder 30, wobei der Schritt des Filterns den Schritt des Filterns basierend auf einer Alarmpriorität umfasst.
Verfahren nach einem der Ansprüche 25 bis 31, wobei der Schritt des Erzeugens den Schritt des Versehens jedes Alarms mit einem die Alarmkategorie definierenden Parameter umfasst.