DE10154534A1 - Integrierte Alarmanzeige in einem Prozeßsteuerungsnetzwerk - Google Patents
Integrierte Alarmanzeige in einem ProzeßsteuerungsnetzwerkInfo
- Publication number
- DE10154534A1 DE10154534A1 DE10154534A DE10154534A DE10154534A1 DE 10154534 A1 DE10154534 A1 DE 10154534A1 DE 10154534 A DE10154534 A DE 10154534A DE 10154534 A DE10154534 A DE 10154534A DE 10154534 A1 DE10154534 A1 DE 10154534A1
- Authority
- DE
- Germany
- Prior art keywords
- alarm
- alarms
- display
- process control
- hardware
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B23/00—Testing or monitoring of control systems or parts thereof
- G05B23/02—Electric testing or monitoring
- G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
- G05B23/0259—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the response to fault detection
- G05B23/0267—Fault communication, e.g. human machine interface [HMI]
- G05B23/0272—Presentation of monitored results, e.g. selection of status reports to be displayed; Filtering information to the user
Abstract
Ein Alarmanzeige- und Schnittstellen-Werkzeug zum Gebrauch in einem Prozeßsteuerungssystem empfängt und zeigt verschiedene Kategorien von Alarmen an, umfassend beispielsweise Gerätealarme und Hardwarealarme sowie herkömmliche Prozeßalarme auf einer einzelnen Anzeige, um es einem Operator oder anderen Benutzern zu ermöglichen, diese verschiedenen Kategorien von Alarmen zu betrachten und darauf Zugriff zu haben. Das Anzeige- und Schnittstellen-Werkzeug kann genutzt werden, um die Alarme zu filtern, die gemäß einer Anzahl von Kategorien dargestellt werden, umfassend die Kategorie des Alarms, die Priorität des Alarms, den Status des Alarms, etc., um so die typischerweise mit Operator-, Wartungs- und Ingenieur-Personal verbundenen Aufgaben alternativ zu trennen oder zu kombinieren. Das Werkzeug kann auch zum Zugriff auf jeden der angezeigten Alarme genutzt werden, um mehr Information über einen individuellen Alarm zu erhalten.
Description
Die vorliegende Erfindung betrifft im allgemeinen
Prozeßsteuerungssysteme und im spezielleren die Anzeige von
Alarmbedingungen innerhalb eines Prozeßsteuerungssystems.
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 dem
US-Patent 5,768,119 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 dem US-Patent
5,768,119 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™ 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 allgemeiner
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 zu viele 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.
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 38 und ein Verfahren mit den
Merkmalen nach Anspruch 47 gelöst. Bevorzugte Ausgestaltungen
der Erfindung sind Gegenstand der abhängigen Ansprüche.
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äß einem Aspekt der vorliegenden Erfindung kann ein
Alarmanzeigesystem in einem Prozeßsteuerungsnetzwerk benutzt
werden, 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.
Fig. 1 zeigt ein Blockdiagramm eines Prozeßsteuerungssystems,
in dem eine integrierte Alarmanzeige und ein
Schnittstellensystem benutzt werden können;
Fig. 2 zeigt ein Blockdiagramm einer Workstation, die eine
integrierte Alarmanzeige und ein Schnittstellensystem
aufweist, die darin ausgeführt werden;
Fig. 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 Fig. 1 benutzt werden;
Fig. 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 Fig. 1 benutzt werden;
Fig. 5 zeigt ein Ausführungsbeispiel einer Alarmsymbolanzeige
für einen Prozeßalarm;
Fig. 6 zeigt ein Ausführungsbeispiel einer Alarmsymbolanzeige
für einen Gerätealarm;
Fig. 7 zeigt ein Ausführungsbeispiel einer Alarmsymbolanzeige
für einen Hardware-Alarm;
Fig. 8 zeigt ein Ausführungsbeispiel einer Frontplatten-
Anzeige für einen Gerätealarm, der mit einem Feldbus-
Feldgerät in Verbindung steht;
Fig. 9 zeigt ein Ausführungsbeispiel einer Frontplatten-
Anzeige für einen Gerätealarm, der mit einem generischen
Feldgerät in Verbindung steht;
Fig. 10 zeigt ein Ausführungsbeispiel einer Frontplatten-
Anzeige für einen Hardware-Alarm, der mit einem Knoten oder
einem Hardware-Element in Verbindung steht;
Fig. 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;
Fig. 12 zeigt ein erstes Ausführungsbeispiel einer Anzeige
zusammengefaßter Alarme, die von einem Alarm-
Zusammenfassungs-Steuerungsmodul erzeugt wird;
Fig. 13 zeigt ein zweites Ausführungsbeispiel einer Anzeige
zusammengefaßter Alarme, die von einem Alarm-
Zusammenfassungs-Steuerungsmodul erzeugt ist;
Fig. 14 zeigt ein drittes Ausführungsbeispiel einer Anzeige
zusammengefaßter Alarme, die von einem Alarm-
Zusammenfassungs-Steuerungsmodul erzeugt ist; und
Fig. 15 zeigt ein Ausführungsbeispiel einer
Ereignisaufzeichnung von Prozeß- und Geräte-Alarmen.
Bezugnehmend auf Fig. 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™-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 Fig. 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 17 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 Fig. 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 Fig. 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 Fig. 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 Fig. 2 ist die Konfiguration einer der
Workstations 14, welche das Alarmanzeige- und
Schnittstellensystem implementiert, detaillierter gezeigt.
Wie in Fig. 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 Fig. 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
vorgesehene 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 Fig. 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 stannen,
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 kanh 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 (Fig. 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 Fig. 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 Fig. 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 Fig. 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 Fig. 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 Fig.
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 Fig. 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 Fig. 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
Fig. 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 Fig. 4 wird eine weitere integrierte
Alarmanzeige dargestellt, die verschiedene Kategorien von
Alarmen dargestellt in dem Alarmsymbol 73 aufweist.
Insbesondere ist in Fig. 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 Fig. 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 Fig. 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 Fig. 8 und 9 erläutert
werden.
Als ein Beispiel ist in Fig. 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 Fig. 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 "FAlL_ALM" ist
ein nicht-konfigurierbarer Name des Gerätealarm-Parameters.
Die Alarmparameter-Namen können beispielsweise COMM_ALM für
"nicht-kommunizierend"-Gerätealarme, FAlL_ALM für
"ausgefallen"-Gerätealarme, MAINT_ALM für "Wartungs"-
Gerätealarme und ADVICE_ALM für "Empfehlungs"-Gerätealarme
sein. In Fig. 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 Fig. 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 FAlL" 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_FAlL for I/O-Card.
"ausgefallen"-Hardwarealarme, etc. sein. Ferner ist in Fig. 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 Fig. 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 Fig. 8 bis 10 sind
beispielhafte Frontplattenanzeigen für Geräte- und
Hardwarealarme dargestellt. Insbesondere stellt Fig. 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. Fig. 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
Fig. 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 Fig. 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 Fig. 10 eine Beispiel-Frontplatte für ein
Hardwaregerät dar, in diesem Fall einen als CTLR1
bezeichneten Controller. Die Frontplatte von Fig. 10 stellt
die verschiedenen verfügbaren Alarme dar, wie CTRL_FAlL,
CARD1_FAlL, 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 Fig. 10.
Allgemein gesprochen folgt die Reihenfolge in einer
Ausführungsform wie der in den Fig. 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 Prioritä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 Fig. 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 Fig. 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 Fig. 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 25673 00070 552 001000280000000200012000285912556200040 0002010154534 00004 25554 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 "halfscreen"
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
Kohtrollieren 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 Fig. 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. Fig. 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.
Fig. 14 stellt die Benutzung verschiedenfarbig markierter
Alarme zum Hervorheben gemäß der Alarmkategorie dar. In Fig.
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 Kontextakt; ionen
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-Statusaktueller
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
Workstationweiten 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
aktivenbestä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 Workstation
weiten 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, Alärm-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
Fig. 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-Mechanismua
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).
Folglich, obwohl die vorliegende Erfindung bezogen auf
spezielle Beispiele beschrieben worden ist, die nur als
erläuternd betrachtet werden und nicht die Erfindung
einschränken, wird es für diejenigen mit durchschnittlichem
Fachwissen offensichtlich sein, daß Änderungen, Zusätze oder
Streichungen an den offenbarten Ausführungsformen gemacht
werden können, ohne vom Sinn und Bereich der Erfindung
abzuweichen.
10
Prozeßsteuerungsnetzwerk/System
12
Prozeßcontroller
14
Workstation/Computer/Host-Gerät/
Benutzerschnittstelle
20
,
22
Eingabe/Ausgabe-Einrichtung/Gruppen
25-39
Feldgeräte
40
Ethernet-Verbindung
20
A,
22
A E/A-Karte
42
,
44
digitaler Bus
20
B,
22
B E/A-Karte
50
Routine/Alarmanzeige- und Schnittstellen-
Software/((Alarm-)verarbeitungs/
Schnittstellen-)Software
51
,
52
,
53
Software (Elemente)/Alarmerzeugungs-Software
62
Kommunikationsschicht/Stapel
64
(Alarm-)Verarbeitungseinheit
66
Datenbank
68
Filter
69
Benutzerschnittstelle/-anzeige(gerät)
70
Benutzeranzeigeschnittstelle
71
Schirm/Anzeige
73
Alarmsymbol
74
Alarm (höchster Priorität)
101
PID-Ventil
76
Alarminformationsfeld
16
Tank
78
Alarmhinweis
80
,
81
,
82
Alarm
72
Frontplatte
90
erster Alarm höchster Priorität/Gerätealarm
92
Alarm mit zweithöchster Priorität
202
Controller
94
dritter Alarm
98
Frontplatte
110
Zusammenfassungskontroll-Softwaremodul/aktive
(Alarmzusammenfassungs)kontrolle
112
unterdrückter-Alarm-Zusammenfassungskontrolle
Claims (55)
1. Alarmanzeigesystem zur Benutzung in einem
Prozeßsteuerungsnetzwerk, das eine Benutzerschnittstelle
mit einem Anzeigemechanismus und eine Vielzahl von
kommunikationsmäßig verbundenen Geräten umfaßt, die zum
Erzeugen und Senden von Alarme verschiedener Kategorien
umfassenden Alarmbotschaften an die Benutzerschnittstelle
ausgebildet sind, wobei das Alarmanzeigesystem folgendes
umfaßt:
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;
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 zur Anzeige auf dem Anzeigemechanismus darstellt, wobei die Alarmanzeigeeinheit die Hinweise auf die Alarme verschiedener Kategorien auf eine integrierte Art auf dem Anzeigemechanismus darstellt.
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;
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 zur Anzeige auf dem Anzeigemechanismus darstellt, wobei die Alarmanzeigeeinheit die Hinweise auf die Alarme verschiedener Kategorien auf eine integrierte Art auf dem Anzeigemechanismus darstellt.
2. Alarmanzeigesystem nach Anspruch 1, wobei die
Alarmverarbeitungseinheit einen Alarmfilter umfaßt, der
die Vielzahl von Alarmen zum Anzeigen filtert, basierend
auf dem vorbestimmten Kriterium zum Ermitteln des Satzes
von Alarmen zum Anzeigen.
3. Alarmanzeigesystem nach Anspruch 1 oder 2, wobei die
Alarmanzeigeeinheit so ausgebildet ist, daß sie einem
Benutzer die Änderung von Alarmfiltereinstellungen des
Alarmfilters ermöglicht, um die Alarme durch
Alarmkategorien zu filtern.
4. Alarmanzeigesystem nach Anspruch 2 oder 3, wobei der
Alarmfilter die Alarme auf Alarmkategorie-Basis filtert.
5. Alarmanzeigesystem nach einem der Ansprüche 2 bis 4,
wobei die Alarmanzeigeeinheit so ausgebildet ist, daß sie
einem Benutzer die Änderung von Alarmfiltereinstellungen
des Alarmfilters ermöglicht, um Alarme nach Priorität zu
filtern.
6. Alarmanzeigesystem nach einem der vorhergehenden
Ansprüche, wobei die Alarme verschiedener Kategorien
einen Prozeßalarm, der mit der Funktionalität einer
Prozeßsteuerungs-Software zusammenhängt, und einen
Hardwarealarm umfassen, der mit der Funktionalität eines
Gerätes zusammenhängt, das einen Knoten in dem
Prozeßsteuerungssystem definiert.
7. Alarmanzeigesystem nach Anspruch 6, wobei einer der
Hardwarealarme mit einem Controller zusammenhängt.
8. Alarmanzeigesystem nach Anspruch 6 oder 7, wobei einer
der Hardwarealarme mit einer Eingabe-/Ausgabe-Einrichtung
zusammenhängt, die zwischen einen Controller und ein
Feldgerät geschaltet ist.
9. Alarmanzeigesystem nach einem der Ansprüche 6 bis 8,
wobei einer der Hardwarealarme mit einer Workstation
zusammenhängt.
10. Alarmanzeigesystem nach einem der vorhergehenden
Ansprüche, wobei die Alarme verschiedener Kategorien
einen Gerätealarm, der mit der Funktionalität eines
Feldgerätes zusammenhängt, und einen Hardwarealarm
umfassen, der mit der Funktionalität eines Gerätes
zusammenhängt, das einen Knoten in dem
Prozeßsteuerungssystem definiert.
11. Alarmanzeigesystem nach einem der vorhergehenden
Ansprüche, wobei die Alarme verschiedener Kategorien
Prozeßalarme, die mit der Funktionalität einer
Prozeßsteuerungs-Software zusammenhängen, Gerätealarme,
die mit der Funktionalität von Feldgeräten
zusammenhängen, und Hardwarealarme umfassen, die mit der
Funktionalität von Geräten zusammenhängen, die einen
Knoten in dem Prozeßsteuerungssystem definieren.
12. 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.
13. Alarmanzeigesystem nach Anspruch 12, wobei das
Alarmsymbol so ausgebildet ist, daß es Alarmhinweise für
die Alarme verschiedener Kategorien und eine
Zusammenfassung für einen ausgewählten der Alarmhinweise
umfaßt.
14. Alarmanzeigesystem nach Anspruch 12 oder 13, wobei die
Alarmanzeigeeinheit so ausgebildet ist, daß eine primäre
Steuerungsanzeige für einen ausgewählten der
Alarmhinweise in dem Alarmsymbol vorgesehen ist.
15. Alarmanzeigesystem nach einem der Ansprüche 12 bis 14,
wobei die Alarmanzeigeeinheit so ausgebildet ist, daß 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.
16. Alarmanzeigesystem nach einem der Ansprüche 12 bis 15,
wobei die Alarmanzeigeeinheit so ausgebildet ist, daß 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.
17. Alarmanzeigesystem nach einem der Ansprüche 12 bis 16,
wobei die Alarmanzeigeeinheit ausgebildet ist, um
Hinweise auf die Alarme verschiedener Kategorien in einer
auf der Priorität der Alarme basierenden Reihenfolge
darzustellen.
18. Alarmanzeigesystem nach einem der Ansprüche 12 bis 17,
wobei die Alarmanzeigeeinheit ausgebildet ist, um
Hinweise auf die Alarme verschiedener Kategorien in einer
auf dem bestätigten Status der Alarme basierenden
Reihenfolge darzustellen.
19. 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.
20. Alarmanzeigesystem nach Anspruch 19, wobei das
Alarmzusammenfassungs-Fenster unterdrückte Alarme
zusammenfaßt, aber nicht aktive Alarme.
21. Alarmanzeigesystem nach Anspruch 19, wobei das
Alarmzusammenfassungs-Fenster aktive Alarme zusammenfaßt,
nicht aber unterdrückte Alarme.
22. 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
Prozeßsteuerungssystem in Verbindung stehen.
23. 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
Prozeßsteuerungssystem in Verbindung stehen.
24. 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
Prozeßsteuerungssystem zusammenhängen.
25. 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 denn
Prozeßsteuerungssystem zusammenhängen.
26. Alarmanzeigesystem nach einem der vorhergehenden
Ansprüche, wobei die Alarme verschiedener Kategorien
einen Prozeßalarm, der mit der Funktionalität einer
Prozeßsteuerungs-Software zusammenhängt, und einen
Gerätealarm umfassen, der mit der Funktionalität eines
Feldgerätes zusammenhängt.
27. Alarmanzeigesystem nach einem der vorhergehenden
Ansprüche, ferner umfassend eine Ereignisaufzeichnungs-
Datenbank, die Änderungsinformation speichert, welche die
Alarme verschiedener Kategorien betrifft.
28. Alarmanzeigesystem zur Benutzung in einem
Prozeßsteuerungsnetzwerk, das eine Benutzerschnittstelle
umfaßt, die einen Prozessor und einen mit dem Prozessor
gekoppelten Anzeigemechanismus und eine Vielzahl von
kommunikationsmäßig verbundenen Geräten umfaßt, die zum
Erzeugen und Senden von Alarme verschiedener Kategorien
umfassenden Alarmbotschaften an die Benutzerschnittstelle
angepaßt sind, wobei das Alarmanzeigesystem folgendes
umfaßt:
einen computer-lesbaren Speicher; und
eine in dem computer-lesbaren Speicher gespeicherte Routine, die zur Ausführung durch den Prozessor ausgebildet ist, wobei die Routine die Alarmbotschaften von der Vielzahl von Geräten empfängt, um eine Vielzahl von Alarmen verschiedener Kategorien zu erhalten;
die Vielzahl von Alarmen zur Anzeige verarbeitet, basierend auf einem vorbestimmten Kriterium, um einen Satz von Alarmen zur Anzeige zu ermitteln; und
Hinweise auf den Satz der Alarme zur Anzeige auf dem Anzeigemechanismus darstellt, wobei der Satz von Alarmen zur Anzeige Alarme verschiedener Kategorien umfaßt, die auf eine integrierte Art auf dem Anzeigemechanismus der Benutzerschnittstelle dargestellt werden.
einen computer-lesbaren Speicher; und
eine in dem computer-lesbaren Speicher gespeicherte Routine, die zur Ausführung durch den Prozessor ausgebildet ist, wobei die Routine die Alarmbotschaften von der Vielzahl von Geräten empfängt, um eine Vielzahl von Alarmen verschiedener Kategorien zu erhalten;
die Vielzahl von Alarmen zur Anzeige verarbeitet, basierend auf einem vorbestimmten Kriterium, um einen Satz von Alarmen zur Anzeige zu ermitteln; und
Hinweise auf den Satz der Alarme zur Anzeige auf dem Anzeigemechanismus darstellt, wobei der Satz von Alarmen zur Anzeige Alarme verschiedener Kategorien umfaßt, die auf eine integrierte Art auf dem Anzeigemechanismus der Benutzerschnittstelle dargestellt werden.
29. Alarmanzeigesystem nach Anspruch 28, wobei die Routine
die Vielzahl von Alarmen durch Filterung der Alarme auf
Alarmkategorie-Basis verarbeitet.
30. Alarmanzeigesystem nach Anspruch 29, wobei die Routine so
ausgebildet ist, daß sie einem Benutzer die Änderung von
Filtereinstellungen ermöglicht, welche die Art bewirken,
auf welche die Routine die Alarme filtert.
31. Alarmanzeigesystem nach einem der Ansprüche 28 bis 30,
wobei die Routine die Vielzahl von Alarmen durch
Filterung der Alarme basierend auf einer Alarmpriorität
durchführt.
32. Alarmanzeigesystem nach einem der Ansprüche 28 bis 31,
wobei die Alarme verschiedener Kategorien zwei oder mehr
Prozeßalarme, die mit der Funktionalität einer
Prozeßsteuerungs-Software zusammenhängen, einen
Gerätealarm, der mit der Funktionalität eines Feldgerätes
zusammenhängt, und einen Hardwarealarm umfassen, der mit
der Funktionalität eines Gerätes zusammenhängt, das einen
Knoten in dem Prozeßsteuerungssystems definiert.
33. Alarmanzeigesystem nach einem der Ansprüche 28 bis 32,
wobei die Routine die Hinweise auf die Alarme zur Anzeige
auf eine integrierte Art unter Nutzung eines Alarmsymbols
darstellt.
34. Alarmanzeigesystem Anspruch 33, wobei das Alarmsymbol
ausgebildet ist, um Alarmhinweise auf die Alarme
verschiedener Kategorien und eine Zusammenfassung für
einen ausgewählten der Alarmhinweise zu umfassen.
35. Alarmanzeigesystem nach Anspruch 33 oder 34, wobei die
Routine ausgebildet ist, um eine primäre Kontrollanzeige
für einen ausgewählten der Alarmhinweise in dem
Alarmsymbol vorzusehen.
36. Alarmanzeigesystem nach einem der Ansprüche 28 bis 35,
wobei die Routine ausbildet ist, um Hinweise auf die
Alarme verschiedener Kategorien in einer Reihenfolge
basierend auf einem anderen Parameter als der
Alarmkategorie darzustellen, der mit den verschiedenen
Kategorien von Alarmen assoziiert ist.
37. Alarmanzeigesystem nach einem der Ansprüche 28 bis 36,
wobei die Routine ausgebildet ist, um Hinweise auf Alarme
verschiedener Kategorien darzustellen, die mit einem
bestimmten Gerät in dem Prozeßsteuerungssystem in
Verbindung stehen.
38. Prozeßsteuerungssystem, umfassend
eine Benutzerschnittstelle mit einem Anzeigemechanismus;
eine Vielzahl von kommunikationsmäßig verbundenen Geräten, die ausgebildet sind, um Alarme verschiedener Kategorien umfassende Alarmbotschaften zu erzeugen und an die Benutzerschnittstelle zu senden;
einen Alarmempfänger, der konfiguriert ist, um die Alarmbotschaften von der Vielzahl von Geräten zu empfangen, um eine Vielzahl von Alarmen verschiedener Kategorien zu erhalten;
einen Alarmfilter, der die Vielzahl von Alarmen zur Anzeige basierend auf einem vorbestimmten Kriterium filtert, um einen Satz von Alarmen zur Anzeige zu ermitteln; und
eine Alarmanzeigeeinheit, die Hinweise auf den Satz der Alarme zur Anzeige auf dem Anzeigemechanismus darstellt, wobei die Alarmanzeigeeinheit die Hinweise auf Alarme verschiedener Kategorien auf eine integrierte Art auf dem Anzeigemechanismus darstellt.
eine Benutzerschnittstelle mit einem Anzeigemechanismus;
eine Vielzahl von kommunikationsmäßig verbundenen Geräten, die ausgebildet sind, um Alarme verschiedener Kategorien umfassende Alarmbotschaften zu erzeugen und an die Benutzerschnittstelle zu senden;
einen Alarmempfänger, der konfiguriert ist, um die Alarmbotschaften von der Vielzahl von Geräten zu empfangen, um eine Vielzahl von Alarmen verschiedener Kategorien zu erhalten;
einen Alarmfilter, der die Vielzahl von Alarmen zur Anzeige basierend auf einem vorbestimmten Kriterium filtert, um einen Satz von Alarmen zur Anzeige zu ermitteln; und
eine Alarmanzeigeeinheit, die Hinweise auf den Satz der Alarme zur Anzeige auf dem Anzeigemechanismus darstellt, wobei die Alarmanzeigeeinheit die Hinweise auf Alarme verschiedener Kategorien auf eine integrierte Art auf dem Anzeigemechanismus darstellt.
39. Prozeßsteuerungssystem nach Anspruch 38, wobei der
Alarmfilter die Alarme basierend auf einer Alarmkategorie
filtert.
40. Prozeßsteuerungssystem nach Anspruch 38 oder 39, wobei
eines der Geräte Software umfaßt, die einen Prozeßalarm,
einen Gerätealarm oder einen Hardwarealarm erzeugt und
sendet, und wobei ein anderes der Geräte weitere Software
umfaßt, die einen anderen Prozeßalarm, Gerätealarm oder
Hardwarealarm erzeugt und sendet, wobei ein Prozeßalarm
mit der Funktionalität einer Prozeßsteuerungs-Software,
ein Gerätealarm mit der Funktionalität eines Feldgerätes
und ein Hardwarealarm mit der Funktionalität eines einen
Knoten definierenden Gerätes zusammenhängt.
41. Prozeßsteuerungssystem nach einem der Ansprüche 38 bis
40, wobei die Alarmanzeigeeinheit Hinweise auf die Alarme
verschiedener Kategorien auf eine integrierte Art unter
Nutzung eines Alarmsymbols darstellt.
42. Prozeßsteuerungssystem nach Anspruch 41, wobei das
Alarmsymbol ausgebildet ist, um die Alarmhinweise für die
Alarme verschiedener Kategorien und eine Zusammenfassung
für einen ausgewählten der Alarmhinweise zu umfassen.
43. Prozeßsteuerungssystem nach Anspruch 41 oder 42, wobei
die Alarmanzeigeeinheit ausgebildet ist, um eine primäre
Kontrollanzeige für einen ausgewählten Alarmhinweis in
dem Alarmsymbol vorzusehen.
44. Prozeßsteuerungssystem nach einem der Ansprüche 41 bis
43, wobei die Alarmanzeigeeinheit so ausgebildet ist, daß
sie einem Benutzer die Unterdrückung eines oder mehrerer
der mit einem oder mehreren der Alarmhinweise in dem
Alarmsymbol verbundenen Alarme ermöglicht.
45. Prozeßsteuerungssystem nach einem der Ansprüche 41 bis
44, wobei die Alarmanzeigeeinheit so ausgebildet ist, daß
sie einem Benutzer die Bestätigung eines oder mehrerer
der mit einem oder mehreren der Alarmhinweise in dem
Alarmsymbol zusammenhängenden Alarme ermöglicht.
46. Prozeßsteuerungssystem nach einem der Ansprüche 41 bis
45, wobei die Alarmanzeigeeinheit ausgebildet ist, um
Hinweise auf die Alarme verschiedener Kategorien in einer
Reihenfolge darzustellen, die auf einem anderen Parameter
als der Alarmkategorie basiert, der mit den verschiedenen
Kategorien von Alarmen zusammenhängt.
47. Verfahren zum Erzeugen und Darstellen von Alarmen in
einem Prozeßsteuerungssystem, das eine Vielzahl von
Geräten aufweist, die mit einer Benutzerschnittstelle
kommunikationsmäßig verbunden sind, wobei das Verfahren
folgende Schritte umfaßt:
- - Erzeugen verschiedener Kategorien von Alarmen in der Vielzahl von Geräten;
- - 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.
48. Verfahren nach Anspruch 47, wobei der Schritt des
Erzeugens der Alarme verschiedener Kategorien das
Erzeugen eines oder mehrerer Prozeßalarme, Gerätealarme
und Hardwarealarme in zwei oder mehr der Geräte umfaßt,
wobei die Prozeßalarme mit der Funktionalität einer
Prozeßsteuerungs-Software, die Gerätealarme mit der
Funktionalität von Feldgeräten und die Hardwarealarme mit
der Funktionalität von einen Knoten innerhalb des
Prozeßsteuerungssystems definierenden Geräten
zusammenhängt.
49. Verfahren nach Anspruch 47 oder 48, wobei der Schritt des
Anzeigens den Schritt des Anzeigens der Alarme
verschiedener Kategorien in einem Alarmsymbol umfaßt.
50. Verfahren nach Anspruch 49, 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.
51. Verfahren nach einem der Ansprüche 47 bis 50, wobei der
Schritt des Anzeigens den Schritt des Anzeigens einer
Alarmzusammenfassung umfaßt, die Information über die
Alarme verschiedener Kategorien umfaßt, die erzeugt
worden sind.
52. Verfahren nach einem der Ansprüche 47 bis 51, 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.
53. Verfahren nach Anspruch 52, wobei der Schritt des
Filterns den Schritt des Filterns basierend auf einer
Alarmkategorie umfaßt.
54. Verfahren nach Anspruch 52 oder 53, wobei der Schritt des
Filterns den Schritt des Filterns basierend auf einer
Alarmpriorität umfaßt.
55. Verfahren nach einem der Ansprüche 47 bis 54, wobei der
Schritt des Erzeugens den Schritt des Versehens jedes
Alarms mit einem die Alarmkategorie definierenden
Parameter umfaßt.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/707,580 | 2000-11-07 | ||
US09/707,580 US6774786B1 (en) | 2000-11-07 | 2000-11-07 | Integrated alarm display in a process control network |
Publications (2)
Publication Number | Publication Date |
---|---|
DE10154534A1 true DE10154534A1 (de) | 2002-06-27 |
DE10154534B4 DE10154534B4 (de) | 2017-04-13 |
Family
ID=24842266
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE10154534.7A Expired - Lifetime DE10154534B4 (de) | 2000-11-07 | 2001-11-07 | Integrierte Alarmanzeige in einem Prozeßsteuerungsnetzwerk |
Country Status (4)
Country | Link |
---|---|
US (2) | US6774786B1 (de) |
JP (1) | JP2002222012A (de) |
DE (1) | DE10154534B4 (de) |
GB (1) | GB2372365B (de) |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2004025383A2 (de) * | 2002-08-29 | 2004-03-25 | Krones Ag | Verfahren, vorrichtung und system zum anzeigen von daten eines maschinensteuerungssystems |
WO2004107069A1 (de) * | 2003-06-03 | 2004-12-09 | Endress + Hauser Flowtec Ag | Variables feldgerät für die prozessautomatisierungstechnik |
EP1708063A1 (de) * | 2005-04-01 | 2006-10-04 | Fanuc Ltd | Anzeigesystem für eine Steuerung |
DE10249423B4 (de) * | 2001-11-09 | 2007-12-06 | Siemens Ag | Bussystem |
DE102009020151A1 (de) * | 2009-05-06 | 2010-11-11 | Siemens Aktiengesellschaft | Verfahren zur Ermittlung und Bewertung von Kenngrößen einer elektrischen Energieversorgung |
DE10217107B4 (de) * | 2001-04-19 | 2013-02-07 | Fisher-Rosemount Systems, Inc. | Erweiterte Gerätealarme in einem Prozesssteuersystem |
DE102004003605B4 (de) * | 2003-01-28 | 2016-05-19 | Fisher-Rosemount Systems, Inc. | Integriertes Diagnosesystem in einer Prozessanlage mit einem Prozesssteuerungssystem und einem Sicherheitssystem |
US9471052B2 (en) | 2011-08-11 | 2016-10-18 | Abb Research Ltd. | Alarm visualization |
DE102005060696B4 (de) * | 2004-12-20 | 2016-10-27 | Abb Ab | Verfahren und System zur automatischen Entscheidung, welcher Alarm, der in einer industriellen Fabrik generiert wird, einem Benutzer verborgen oder vorgelegt werden soll |
EP3270248A1 (de) * | 2016-07-13 | 2018-01-17 | Siemens Aktiengesellschaft | Verwaltung von systemalarmen auf bedien- und/oder beobachtungsgeräten |
DE102013109823B4 (de) | 2012-09-07 | 2019-10-02 | Fanuc Robotics America Corp. | System zur Überwachung/Analyse von in Zusammenhang mit Robotern stehenden Informationen und deren Darstellung auf einem Smart-Gerät |
DE102021212607A1 (de) | 2021-11-09 | 2023-05-11 | Siemens Healthcare Gmbh | Verfahren zum Bereitstellen eines Trigger-Tokens |
DE102018111892B4 (de) | 2017-05-22 | 2023-06-29 | Okuma Corporation | Betriebsüberwachungsvorrichtung und Steuerprogramm dafür |
Families Citing this family (219)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8044793B2 (en) | 2001-03-01 | 2011-10-25 | Fisher-Rosemount Systems, Inc. | Integrated device alerts in a process control system |
US6774786B1 (en) * | 2000-11-07 | 2004-08-10 | Fisher-Rosemount Systems, Inc. | Integrated alarm display in a process control network |
US7720727B2 (en) * | 2001-03-01 | 2010-05-18 | Fisher-Rosemount Systems, Inc. | Economic calculations in process control system |
US8073967B2 (en) | 2002-04-15 | 2011-12-06 | Fisher-Rosemount Systems, Inc. | Web services-based communications for use with process control systems |
US20030009711A1 (en) * | 2001-06-28 | 2003-01-09 | Kuhn Gerald M. | Alarm management system |
WO2003012560A2 (en) * | 2001-07-31 | 2003-02-13 | Endress + Hauser Gmbh + Co. Kg | Supervisory control and data acquisition interface for tank or process monitor |
US7568000B2 (en) * | 2001-08-21 | 2009-07-28 | Rosemount Analytical | Shared-use data processing for process control systems |
US7091846B2 (en) * | 2002-03-18 | 2006-08-15 | Siemens Communications, Inc. | Methods and apparatus for handling information regarding an alarm for a communication network |
US7319921B2 (en) * | 2002-05-22 | 2008-01-15 | Underwood Fred R | Water treatment control system |
US20030236876A1 (en) * | 2002-06-20 | 2003-12-25 | Adc Dsl Systems, Inc. | User selectable default alarm severity levels |
US7289861B2 (en) * | 2003-01-28 | 2007-10-30 | Fisher-Rosemount Systems, Inc. | Process control system with an embedded safety system |
JP4097485B2 (ja) * | 2002-08-28 | 2008-06-11 | 独立行政法人科学技術振興機構 | 酸化還元酵素と基質との反応中間体を捕捉する方法 |
US7392165B2 (en) * | 2002-10-21 | 2008-06-24 | Fisher-Rosemount Systems, Inc. | Simulation system for multi-node process control systems |
DE10313389A1 (de) * | 2003-03-25 | 2004-10-07 | Endress + Hauser Process Solutions Ag | Verfahren zur Übertragung von Softwarecode von einer Steuereinheit zu einem Feldgerät der Prozessautomatisierungstechnik |
US7272456B2 (en) * | 2003-01-24 | 2007-09-18 | Rockwell Automation Technologies, Inc. | Position based machine control in an industrial automation environment |
US6898468B2 (en) * | 2003-03-28 | 2005-05-24 | Fisher-Rosemount Systems, Inc. | Function block implementation of a cause and effect matrix for use in a process safety system |
US6898542B2 (en) * | 2003-04-01 | 2005-05-24 | Fisher-Rosemount Systems, Inc. | On-line device testing block integrated into a process control/safety system |
US7130703B2 (en) * | 2003-04-08 | 2006-10-31 | Fisher-Rosemount Systems, Inc. | Voter logic block including operational and maintenance overrides in a process control system |
DE10326665A1 (de) * | 2003-06-11 | 2005-01-20 | Endress + Hauser Process Solutions Ag | Verfahren zum Überwachen eines Feldgerätes |
US9123077B2 (en) | 2003-10-07 | 2015-09-01 | Hospira, Inc. | Medication management system |
US8065161B2 (en) | 2003-11-13 | 2011-11-22 | Hospira, Inc. | System for maintaining drug information and communicating with medication delivery devices |
US20050125079A1 (en) * | 2003-12-08 | 2005-06-09 | Schreder James M. | Interactive instructions in sequential control modules in controllers |
US7030747B2 (en) * | 2004-02-26 | 2006-04-18 | Fisher-Rosemount Systems, Inc. | Method and system for integrated alarms in a process control system |
US8645569B2 (en) | 2004-03-12 | 2014-02-04 | Rockwell Automation Technologies, Inc. | Juxtaposition based machine addressing |
US8234414B2 (en) * | 2004-03-31 | 2012-07-31 | Qurio Holdings, Inc. | Proxy caching in a photosharing peer-to-peer network to improve guest image viewing performance |
JP2007536634A (ja) | 2004-05-04 | 2007-12-13 | フィッシャー−ローズマウント・システムズ・インコーポレーテッド | プロセス制御システムのためのサービス指向型アーキテクチャ |
US7729789B2 (en) | 2004-05-04 | 2010-06-01 | Fisher-Rosemount Systems, Inc. | Process plant monitoring based on multivariate statistical analysis and on-line process simulation |
US8132225B2 (en) * | 2004-09-30 | 2012-03-06 | Rockwell Automation Technologies, Inc. | Scalable and flexible information security for industrial automation |
US20110178963A1 (en) * | 2004-10-28 | 2011-07-21 | Insyst Ltd. | system for the detection of rare data situations in processes |
GB2422236A (en) * | 2005-01-12 | 2006-07-19 | Siemens Ag | Remote fault acknowledgement system |
US7352279B2 (en) * | 2005-03-02 | 2008-04-01 | Matsushita Electric Industrial Co., Ltd. | Rule based intelligent alarm management system for digital surveillance system |
US9201420B2 (en) | 2005-04-08 | 2015-12-01 | Rosemount, Inc. | Method and apparatus for performing a function in a process plant using monitoring data with criticality evaluation data |
US8005647B2 (en) | 2005-04-08 | 2011-08-23 | Rosemount, Inc. | Method and apparatus for monitoring and performing corrective measures in a process plant using monitoring data with corrective measures data |
US7525422B2 (en) * | 2005-04-14 | 2009-04-28 | Verizon Business Global Llc | Method and system for providing alarm reporting in a managed network services environment |
US8099178B2 (en) * | 2005-08-22 | 2012-01-17 | Trane International Inc. | Building automation system facilitating user customization |
US8055387B2 (en) * | 2005-08-22 | 2011-11-08 | Trane International Inc. | Building automation system data management |
US8024054B2 (en) * | 2005-08-22 | 2011-09-20 | Trane International, Inc. | Building automation system facilitating user customization |
US7870090B2 (en) * | 2005-08-22 | 2011-01-11 | Trane International Inc. | Building automation system date management |
US7917232B2 (en) * | 2005-08-22 | 2011-03-29 | Trane International Inc. | Building automation system data management |
US8055386B2 (en) * | 2005-08-22 | 2011-11-08 | Trane International Inc. | Building automation system data management |
US8050801B2 (en) * | 2005-08-22 | 2011-11-01 | Trane International Inc. | Dynamically extensible and automatically configurable building automation system and architecture |
US7904186B2 (en) | 2005-08-22 | 2011-03-08 | Trane International, Inc. | Building automation system facilitating user customization |
KR20070044321A (ko) * | 2005-10-24 | 2007-04-27 | 삼성전자주식회사 | 디스플레이장치 및 이를 포함하는 네트워크 시스템 |
DE102005063053A1 (de) * | 2005-12-29 | 2007-07-05 | Endress + Hauser Process Solutions Ag | Verfahren zur Anlagenüberwachung mit einem Feldbus der Prozessautomatisierungstechnik |
US7565340B2 (en) * | 2006-01-09 | 2009-07-21 | The State Of Oregon Acting By And Through The State Board Of Higher Education On Behalf Of Oregon State University | Methods for assisting computer users performing multiple tasks |
JP4645907B2 (ja) * | 2006-01-24 | 2011-03-09 | 横河電機株式会社 | アラーム情報処理装置およびアラーム情報処理方法 |
US20070260982A1 (en) * | 2006-04-11 | 2007-11-08 | Invensys Systems, Inc. | Runtime human-machine interface for process control having enhanced graphical views of detailed control information |
US8185618B2 (en) * | 2006-06-06 | 2012-05-22 | Cisco Technology, Inc. | Dynamically responding to non-network events at a network device in a computer network |
US7427914B2 (en) * | 2006-09-21 | 2008-09-23 | Komatsu America Corp. | Operator alerting system using a vehicle fault condition prioritization method |
US7538664B2 (en) * | 2006-09-29 | 2009-05-26 | Rockwell Automation Technologies, Inc. | Customized industrial alarms |
US7612661B1 (en) * | 2006-09-29 | 2009-11-03 | Rockwell Automation Technologies, Inc. | Dynamic messages |
EP2092470A2 (de) | 2006-10-16 | 2009-08-26 | Hospira, Inc. | System und verfahren für den vergleich und die verwendung von aktivitätsinformationen und konfigurationsinformationen aus verwaltungssystemen mit mehreren geräten |
WO2008050323A2 (en) * | 2006-10-23 | 2008-05-02 | Dorron Levy | Method for measuring health status of complex systems |
US20080130509A1 (en) * | 2006-11-30 | 2008-06-05 | Network Equipment Technologies, Inc. | Leased Line Emulation for PSTN Alarms Over IP |
JP2008176706A (ja) * | 2007-01-22 | 2008-07-31 | Yokogawa Electric Corp | アラーム情報処理装置およびアラーム情報処理方法 |
JP4765948B2 (ja) * | 2007-01-25 | 2011-09-07 | 船井電機株式会社 | テレビジョンおよび電気電子機器 |
US8588078B1 (en) * | 2007-02-22 | 2013-11-19 | Sprint Communications Company L.P. | Network event tracking |
US10410145B2 (en) | 2007-05-15 | 2019-09-10 | Fisher-Rosemount Systems, Inc. | Automatic maintenance estimation in a plant environment |
US8407716B2 (en) | 2007-05-31 | 2013-03-26 | Fisher-Rosemount Systems, Inc. | Apparatus and methods to access information associated with a process control system |
EP2028572B1 (de) * | 2007-08-22 | 2010-04-14 | Siemens Aktiengesellschaft | Betriebsverfahren für eine Steuereinrichtung einer sicherheitsgerichteten Automatisierungseinrichtung zum Überprüfen der Zuverlässigkeit eines Automatisierungssystems |
US8301676B2 (en) | 2007-08-23 | 2012-10-30 | Fisher-Rosemount Systems, Inc. | Field device with capability of calculating digital filter coefficients |
US7702401B2 (en) | 2007-09-05 | 2010-04-20 | Fisher-Rosemount Systems, Inc. | System for preserving and displaying process control data associated with an abnormal situation |
US9323247B2 (en) | 2007-09-14 | 2016-04-26 | Fisher-Rosemount Systems, Inc. | Personalized plant asset data representation and search system |
US8055479B2 (en) | 2007-10-10 | 2011-11-08 | Fisher-Rosemount Systems, Inc. | Simplified algorithm for abnormal situation prevention in load following applications including plugged line diagnostics in a dynamic process |
JP4396779B2 (ja) * | 2008-01-24 | 2010-01-13 | ダイキン工業株式会社 | 空調機管理装置 |
US8527096B2 (en) * | 2008-10-24 | 2013-09-03 | Lennox Industries Inc. | Programmable controller and a user interface for same |
US8452906B2 (en) | 2008-10-27 | 2013-05-28 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US9261888B2 (en) | 2008-10-27 | 2016-02-16 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8994539B2 (en) | 2008-10-27 | 2015-03-31 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8762666B2 (en) | 2008-10-27 | 2014-06-24 | Lennox Industries, Inc. | Backup and restoration of operation control data in a heating, ventilation and air conditioning network |
US9377768B2 (en) | 2008-10-27 | 2016-06-28 | Lennox Industries Inc. | Memory recovery scheme and data structure in a heating, ventilation and air conditioning network |
US8774210B2 (en) | 2008-10-27 | 2014-07-08 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US9325517B2 (en) | 2008-10-27 | 2016-04-26 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
US8661165B2 (en) | 2008-10-27 | 2014-02-25 | Lennox Industries, Inc. | Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system |
US8874815B2 (en) | 2008-10-27 | 2014-10-28 | Lennox Industries, Inc. | Communication protocol system and method for a distributed architecture heating, ventilation and air conditioning network |
US8463443B2 (en) | 2008-10-27 | 2013-06-11 | Lennox Industries, Inc. | Memory recovery scheme and data structure in a heating, ventilation and air conditioning network |
US8615326B2 (en) | 2008-10-27 | 2013-12-24 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8655491B2 (en) | 2008-10-27 | 2014-02-18 | Lennox Industries Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network |
US8437877B2 (en) | 2008-10-27 | 2013-05-07 | Lennox Industries Inc. | System recovery in a heating, ventilation and air conditioning network |
US8295981B2 (en) | 2008-10-27 | 2012-10-23 | Lennox Industries Inc. | Device commissioning in a heating, ventilation and air conditioning network |
US8437878B2 (en) | 2008-10-27 | 2013-05-07 | Lennox Industries Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network |
US9268345B2 (en) | 2008-10-27 | 2016-02-23 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8548630B2 (en) | 2008-10-27 | 2013-10-01 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8239066B2 (en) | 2008-10-27 | 2012-08-07 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8600558B2 (en) | 2008-10-27 | 2013-12-03 | Lennox Industries Inc. | System recovery in a heating, ventilation and air conditioning network |
US8352081B2 (en) | 2008-10-27 | 2013-01-08 | Lennox Industries Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US9678486B2 (en) | 2008-10-27 | 2017-06-13 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
US8463442B2 (en) | 2008-10-27 | 2013-06-11 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network |
US8655490B2 (en) | 2008-10-27 | 2014-02-18 | Lennox Industries, Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8788100B2 (en) | 2008-10-27 | 2014-07-22 | Lennox Industries Inc. | System and method for zoning a distributed-architecture heating, ventilation and air conditioning network |
US8564400B2 (en) | 2008-10-27 | 2013-10-22 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8725298B2 (en) | 2008-10-27 | 2014-05-13 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and conditioning network |
US8798796B2 (en) | 2008-10-27 | 2014-08-05 | Lennox Industries Inc. | General control techniques in a heating, ventilation and air conditioning network |
US8802981B2 (en) | 2008-10-27 | 2014-08-12 | Lennox Industries Inc. | Flush wall mount thermostat and in-set mounting plate for a heating, ventilation and air conditioning system |
US8600559B2 (en) | 2008-10-27 | 2013-12-03 | Lennox Industries Inc. | Method of controlling equipment in a heating, ventilation and air conditioning network |
US8977794B2 (en) | 2008-10-27 | 2015-03-10 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US9632490B2 (en) | 2008-10-27 | 2017-04-25 | Lennox Industries Inc. | System and method for zoning a distributed architecture heating, ventilation and air conditioning network |
US8855825B2 (en) | 2008-10-27 | 2014-10-07 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
US9651925B2 (en) | 2008-10-27 | 2017-05-16 | Lennox Industries Inc. | System and method for zoning a distributed-architecture heating, ventilation and air conditioning network |
US9152155B2 (en) | 2008-10-27 | 2015-10-06 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
US8694164B2 (en) | 2008-10-27 | 2014-04-08 | Lennox Industries, Inc. | Interactive user guidance interface for a heating, ventilation and air conditioning system |
US8352080B2 (en) | 2008-10-27 | 2013-01-08 | Lennox Industries Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8442693B2 (en) | 2008-10-27 | 2013-05-14 | Lennox Industries, Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8543243B2 (en) | 2008-10-27 | 2013-09-24 | Lennox Industries, Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8433446B2 (en) | 2008-10-27 | 2013-04-30 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8452456B2 (en) | 2008-10-27 | 2013-05-28 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8892797B2 (en) | 2008-10-27 | 2014-11-18 | Lennox Industries Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8744629B2 (en) | 2008-10-27 | 2014-06-03 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US9432208B2 (en) | 2008-10-27 | 2016-08-30 | Lennox Industries Inc. | Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system |
US8560125B2 (en) | 2008-10-27 | 2013-10-15 | Lennox Industries | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8255086B2 (en) | 2008-10-27 | 2012-08-28 | Lennox Industries Inc. | System recovery in a heating, ventilation and air conditioning network |
US20110093493A1 (en) * | 2008-10-28 | 2011-04-21 | Honeywell International Inc. | Building management system site categories |
US8819562B2 (en) | 2010-09-30 | 2014-08-26 | Honeywell International Inc. | Quick connect and disconnect, base line configuration, and style configurator |
US20100106543A1 (en) * | 2008-10-28 | 2010-04-29 | Honeywell International Inc. | Building management configuration system |
US8850347B2 (en) | 2010-09-30 | 2014-09-30 | Honeywell International Inc. | User interface list control system |
US8719385B2 (en) * | 2008-10-28 | 2014-05-06 | Honeywell International Inc. | Site controller discovery and import system |
US9471202B2 (en) * | 2008-11-21 | 2016-10-18 | Honeywell International Inc. | Building control system user interface with pinned display feature |
US8572502B2 (en) * | 2008-11-21 | 2013-10-29 | Honeywell International Inc. | Building control system user interface with docking feature |
US8269620B2 (en) * | 2008-12-19 | 2012-09-18 | Honeywell Internatonal Inc. | Alarm trend summary display system and method |
US20100156655A1 (en) * | 2008-12-19 | 2010-06-24 | Honeywell International Inc. | Equipment area alarm summary display system and method |
US20100211192A1 (en) * | 2009-02-17 | 2010-08-19 | Honeywell International Inc. | Apparatus and method for automated analysis of alarm data to support alarm rationalization |
US8180824B2 (en) * | 2009-02-23 | 2012-05-15 | Trane International, Inc. | Log collection data harvester for use in a building automation system |
US8881039B2 (en) | 2009-03-13 | 2014-11-04 | Fisher-Rosemount Systems, Inc. | Scaling composite shapes for a graphical human-machine interface |
US8271106B2 (en) | 2009-04-17 | 2012-09-18 | Hospira, Inc. | System and method for configuring a rule set for medical event management and responses |
US8224763B2 (en) | 2009-05-11 | 2012-07-17 | Honeywell International Inc. | Signal management system for building systems |
US8554714B2 (en) * | 2009-05-11 | 2013-10-08 | Honeywell International Inc. | High volume alarm management system |
USD648642S1 (en) | 2009-10-21 | 2011-11-15 | Lennox Industries Inc. | Thin cover plate for an electronic system controller |
USD648641S1 (en) | 2009-10-21 | 2011-11-15 | Lennox Industries Inc. | Thin cover plate for an electronic system controller |
US8335989B2 (en) * | 2009-10-26 | 2012-12-18 | Nokia Corporation | Method and apparatus for presenting polymorphic notes in a graphical user interface |
US9557735B2 (en) * | 2009-12-10 | 2017-01-31 | Fisher-Rosemount Systems, Inc. | Methods and apparatus to manage process control status rollups |
US8352047B2 (en) | 2009-12-21 | 2013-01-08 | Honeywell International Inc. | Approaches for shifting a schedule |
US20110196539A1 (en) * | 2010-02-10 | 2011-08-11 | Honeywell International Inc. | Multi-site controller batch update system |
US8260444B2 (en) | 2010-02-17 | 2012-09-04 | Lennox Industries Inc. | Auxiliary controller of a HVAC system |
US9258201B2 (en) * | 2010-02-23 | 2016-02-09 | Trane International Inc. | Active device management for use in a building automation system |
US8793022B2 (en) | 2010-02-26 | 2014-07-29 | Trane International, Inc. | Automated air source and VAV box association |
US8219660B2 (en) * | 2010-02-26 | 2012-07-10 | Trane International Inc. | Simultaneous connectivity and management across multiple building automation system networks |
US8640098B2 (en) * | 2010-03-11 | 2014-01-28 | Honeywell International Inc. | Offline configuration and download approach |
US8825183B2 (en) | 2010-03-22 | 2014-09-02 | Fisher-Rosemount Systems, Inc. | Methods for a data driven interface based on relationships between process control tags |
EP2558917A1 (de) * | 2010-04-14 | 2013-02-20 | Yokogawa Electric Corporation | Verfahren und system zur anzeige von priorisierten live-miniaturbildern von grafischen prozessansichten |
US8890675B2 (en) | 2010-06-02 | 2014-11-18 | Honeywell International Inc. | Site and alarm prioritization system |
US8648706B2 (en) | 2010-06-24 | 2014-02-11 | Honeywell International Inc. | Alarm management system having an escalation strategy |
US10083249B2 (en) * | 2010-09-23 | 2018-09-25 | Fisher-Rosemount Systems, Inc. | Systems, methods and articles of manufacture to provide a search service to a process control system |
US9213539B2 (en) | 2010-12-23 | 2015-12-15 | Honeywell International Inc. | System having a building control device with on-demand outside server functionality |
JP4948679B1 (ja) * | 2011-03-29 | 2012-06-06 | 三菱電機株式会社 | サーボ制御装置の異常診断装置および異常診断システム |
US9927788B2 (en) | 2011-05-19 | 2018-03-27 | Fisher-Rosemount Systems, Inc. | Software lockout coordination between a process control system and an asset management system |
US8730054B2 (en) * | 2011-05-31 | 2014-05-20 | General Electric Company | Systems and methods to customize alert presentation |
US8937555B2 (en) * | 2011-05-31 | 2015-01-20 | General Electric Company | Systems and methods to overlay behaviors on foundation fieldbus alerts |
US20120306648A1 (en) * | 2011-05-31 | 2012-12-06 | General Electric Company | Systems and methods to configure alerts for fieldbus foundation devices |
US9355477B2 (en) | 2011-06-28 | 2016-05-31 | Honeywell International Inc. | Historical alarm analysis apparatus and method |
US20130014058A1 (en) * | 2011-07-07 | 2013-01-10 | Gallagher Group Limited | Security System |
EP2560062A1 (de) * | 2011-08-16 | 2013-02-20 | ABB Research Ltd. | Verfahren und Steuersysteme zur Steuerung eines Industriesystems |
EP2570876B1 (de) * | 2011-09-14 | 2014-12-03 | ABB Research Ltd. | Verfahren und System zum Steuern eines Betriebsablaufs |
ES2959510T3 (es) | 2011-10-21 | 2024-02-26 | Icu Medical Inc | Sistema de actualización de dispositivos médicos |
US20130100136A1 (en) * | 2011-10-24 | 2013-04-25 | Kim Ordean Van Camp | Sparkline presentations of process control system alarms |
JP5522149B2 (ja) * | 2011-11-09 | 2014-06-18 | 横河電機株式会社 | 運転監視画面表示装置および運転監視画面表示方法 |
US9529348B2 (en) | 2012-01-24 | 2016-12-27 | Emerson Process Management Power & Water Solutions, Inc. | Method and apparatus for deploying industrial plant simulators using cloud computing technologies |
US9223839B2 (en) | 2012-02-22 | 2015-12-29 | Honeywell International Inc. | Supervisor history view wizard |
US9625349B2 (en) * | 2012-02-29 | 2017-04-18 | Fisher Controls International Llc | Time-stamped emissions data collection for process control devices |
JP5244990B1 (ja) * | 2012-03-01 | 2013-07-24 | 株式会社東芝 | 不良検出装置 |
WO2013144706A2 (en) * | 2012-03-30 | 2013-10-03 | Abb Research Ltd. | A method and an apparatus for event management in a plant automation system |
CN104303120B (zh) * | 2012-05-16 | 2017-06-09 | 利乐拉瓦尔集团及财务有限公司 | 用于包装机的监测系统 |
EP2862033B1 (de) | 2012-06-19 | 2019-07-24 | GKN Aerospace Sweden AB | Verfahren und system zur bestimmung des lebensverbrauchs eines mechanischen teils |
JP6379089B2 (ja) | 2012-06-19 | 2018-08-22 | ゲーコーエヌ エアロスペース スウェーデン アーベー | 機械状態の決定方法 |
US10025893B2 (en) * | 2012-06-19 | 2018-07-17 | Gkn Aerospace Sweden Ab | Prediction of life consumption of a machine component |
US9529349B2 (en) | 2012-10-22 | 2016-12-27 | Honeywell International Inc. | Supervisor user management system |
CN103064777B (zh) * | 2012-12-24 | 2016-03-02 | 华为技术有限公司 | 磁盘阵列告警显示方法和装置 |
US9869997B2 (en) * | 2013-02-15 | 2018-01-16 | General Electric Company | Protection monitoring system with fault indicators |
WO2014129983A1 (en) | 2013-02-21 | 2014-08-28 | Thai Oil Public Company Limited | Methods, systems, and devices for managing a plurality of alarms |
AU2014225658B2 (en) | 2013-03-06 | 2018-05-31 | Icu Medical, Inc. | Medical device communication method |
US10120350B2 (en) * | 2013-03-11 | 2018-11-06 | Fisher-Rosemount Systems, Inc. | Background collection of diagnostic data from field instrumentation devices |
DE102013105994A1 (de) * | 2013-06-10 | 2014-12-11 | Endress + Hauser Conducta Gesellschaft für Mess- und Regeltechnik mbH + Co. KG | Messsystem mit zumindest einem Feldgerät mit zumindest einer Anzeigevorrichtung sowie Verfahren zum Betreiben desselben |
US9086688B2 (en) | 2013-07-09 | 2015-07-21 | Fisher-Rosemount Systems, Inc. | State machine function block with user-definable actions on a transition between states |
US9863854B2 (en) * | 2013-08-02 | 2018-01-09 | General Electric Company | System and method for presenting information in an industrial monitoring system |
US9262055B2 (en) * | 2013-08-19 | 2016-02-16 | Raytheon Company | Heat map carousel for displaying health and status information for an electro-mechanical system |
JP6621748B2 (ja) | 2013-08-30 | 2019-12-18 | アイシーユー・メディカル・インコーポレーテッド | 遠隔輸液レジメンを監視および管理するシステムならびに方法 |
US9662436B2 (en) | 2013-09-20 | 2017-05-30 | Icu Medical, Inc. | Fail-safe drug infusion therapy system |
CN104462150A (zh) * | 2013-09-25 | 2015-03-25 | 中兴通讯股份有限公司 | 一种网元管理系统中告警过滤方法及装置 |
EP2853969B1 (de) * | 2013-09-27 | 2020-06-17 | Siemens Aktiengesellschaft | Alarmverwaltungssystem und Verfahren dafür |
US9971977B2 (en) | 2013-10-21 | 2018-05-15 | Honeywell International Inc. | Opus enterprise report system |
US10311972B2 (en) | 2013-11-11 | 2019-06-04 | Icu Medical, Inc. | Medical device system performance index |
US9734470B2 (en) * | 2013-11-14 | 2017-08-15 | Honeywell International Inc. | Apparatus and method for providing customized viewing and control of field devices through custom groups and actions in a process control system |
WO2015077320A1 (en) | 2013-11-19 | 2015-05-28 | Hospira, Inc. | Infusion pump automation system and method |
BR112016014922A2 (pt) * | 2013-12-25 | 2017-08-08 | Tlv Co Ltd | Sistema de gerenciamento de sistema de processo, dispositivo de servidor, programa de gerenciamento e método de gerenciamento |
US9311810B2 (en) * | 2014-01-23 | 2016-04-12 | General Electric Company | Implementing standardized behaviors in a hosting device |
US20150277675A1 (en) * | 2014-04-01 | 2015-10-01 | Ca, Inc. | Analytics that recommend windows actions in a multi-windowed operator environment |
JP6853669B2 (ja) | 2014-04-30 | 2021-03-31 | アイシーユー・メディカル・インコーポレーテッド | 条件付きの警報転送を用いた患者治療システム |
US9724470B2 (en) | 2014-06-16 | 2017-08-08 | Icu Medical, Inc. | System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy |
US9933762B2 (en) | 2014-07-09 | 2018-04-03 | Honeywell International Inc. | Multisite version and upgrade management system |
US9539383B2 (en) | 2014-09-15 | 2017-01-10 | Hospira, Inc. | System and method that matches delayed infusion auto-programs with manually entered infusion programs and analyzes differences therein |
WO2016189417A1 (en) | 2015-05-26 | 2016-12-01 | Hospira, Inc. | Infusion pump system and method with multiple drug library editor source capability |
US9445395B1 (en) * | 2015-06-16 | 2016-09-13 | Motorola Mobility Llc | Suppressing alert messages based on microphone states of connected devices |
US9646487B2 (en) * | 2015-08-17 | 2017-05-09 | Fisher-Rosemount Systems, Inc. | Process control alarm auditing |
US10209689B2 (en) | 2015-09-23 | 2019-02-19 | Honeywell International Inc. | Supervisor history service import manager |
US10362104B2 (en) | 2015-09-23 | 2019-07-23 | Honeywell International Inc. | Data manager |
US9865156B2 (en) * | 2015-09-23 | 2018-01-09 | Schneider Electric Systems Usa, Inc. | System for contextualizing and resolving alerts |
FR3045179B1 (fr) | 2015-12-15 | 2018-01-26 | Areva Np | Dispositif electronique et procede de gestion de l'affichage de donnees pour le pilotage d'une centrale nucleaire, systeme de pilotage et produit programme d'ordinateur associes |
JP6648641B2 (ja) | 2016-06-06 | 2020-02-14 | 株式会社Ihi | 歪み推定装置、診断装置、及び歪み推定方法 |
US10235853B2 (en) * | 2016-06-20 | 2019-03-19 | General Electric Company | Interface method and apparatus for alarms |
EP3484541A4 (de) | 2016-07-14 | 2020-03-25 | ICU Medical, Inc. | Auswahl mehrerer kommunikationspfade und sicherheitssystem für eine medizinische vorrichtung |
US10671038B2 (en) | 2016-07-15 | 2020-06-02 | Fisher-Rosemount Systems, Inc. | Architecture-independent process control |
US10269235B2 (en) | 2016-08-26 | 2019-04-23 | Trane International Inc. | System and method to assist building automation system end user based on alarm parameters |
JP6694783B2 (ja) | 2016-08-30 | 2020-05-20 | アズビル株式会社 | アラーム表示装置および方法 |
US10657776B2 (en) | 2016-10-24 | 2020-05-19 | Fisher-Rosemount Systems, Inc. | Alarm handling and viewing support in a process plant |
DE102016121623A1 (de) * | 2016-11-11 | 2018-05-17 | Endress+Hauser Process Solutions Ag | Verfahren zur Analyse von Fehlfunktionen in einer Anlage der Prozessautomatisierung |
US10967303B2 (en) | 2018-03-08 | 2021-04-06 | Mark W. Romers | Filter backwash control system for a water or wastewater treatment system to conserve water during the filter backwash process |
US10635096B2 (en) * | 2017-05-05 | 2020-04-28 | Honeywell International Inc. | Methods for analytics-driven alarm rationalization, assessment of operator response, and incident diagnosis and related systems |
GB2568785B (en) * | 2017-10-02 | 2023-02-15 | Fisher Rosemount Systems Inc | Systems and methods for configuring and presenting a display navigation hierarchy in a process plant |
US10788972B2 (en) | 2017-10-02 | 2020-09-29 | Fisher-Rosemount Systems, Inc. | Systems and methods for automatically populating a display area with historized process parameters |
US10747207B2 (en) | 2018-06-15 | 2020-08-18 | Honeywell International Inc. | System and method for accurate automatic determination of “alarm-operator action” linkage for operator assessment and alarm guidance using custom graphics and control charts |
NZ771914A (en) | 2018-07-17 | 2023-04-28 | Icu Medical Inc | Updating infusion pump drug libraries and operational software in a networked environment |
US11139058B2 (en) | 2018-07-17 | 2021-10-05 | Icu Medical, Inc. | Reducing file transfer between cloud environment and infusion pumps |
EP3824383B1 (de) | 2018-07-17 | 2023-10-11 | ICU Medical, Inc. | Systeme und verfahren zur klinischen nachrichtenübermittlung in einer netzwerkumgebung |
US10950339B2 (en) | 2018-07-17 | 2021-03-16 | Icu Medical, Inc. | Converting pump messages in new pump protocol to standardized dataset messages |
AU2019309766A1 (en) | 2018-07-26 | 2021-03-18 | Icu Medical, Inc. | Drug library management system |
US10692595B2 (en) | 2018-07-26 | 2020-06-23 | Icu Medical, Inc. | Drug library dynamic version management |
JP7344041B2 (ja) * | 2019-08-08 | 2023-09-13 | 横河電機株式会社 | アラーム管理装置、アラーム管理システム、およびアラーム管理方法 |
US20210240179A1 (en) * | 2020-01-31 | 2021-08-05 | Saudi Arabian Oil Company | Automated maintenance method and system for plant assets |
CN111930063B (zh) * | 2020-08-11 | 2021-08-31 | 佛山市天禄智能装备科技有限公司 | 一种回转窑安全生产保护系统 |
EP3968107B1 (de) * | 2020-09-09 | 2022-12-14 | Siemens Aktiengesellschaft | Prozessüberwachungssystem und verfahren zum betrieb eines prozessüberwachungssystems |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2083258B (en) | 1980-09-03 | 1984-07-25 | Nuclear Power Co Ltd | Alarm systems |
US4644478A (en) | 1983-09-13 | 1987-02-17 | International Business Machines Corp. | Monitoring and alarm system for custom applications |
US4853175A (en) | 1988-03-10 | 1989-08-01 | The Babcock & Wilcox Company | Power plant interactive display |
US5267277A (en) * | 1989-11-02 | 1993-11-30 | Combustion Engineering, Inc. | Indicator system for advanced nuclear plant control complex |
JP2952124B2 (ja) | 1992-11-25 | 1999-09-20 | 富士写真フイルム株式会社 | 写真処理機の故障診断システム |
ZA947893B (en) | 1993-09-05 | 1995-05-24 | George Hans Lowe | An indicating system |
US5631825A (en) * | 1993-09-29 | 1997-05-20 | Dow Benelux N.V. | Operator station for manufacturing process control system |
JPH08129415A (ja) | 1994-10-31 | 1996-05-21 | Hitachi Ltd | プラントの故障解析支援システム |
US5768119A (en) | 1996-04-12 | 1998-06-16 | Fisher-Rosemount Systems, Inc. | Process control system including alarm priority adjustment |
CA2267502C (en) | 1996-10-04 | 2007-03-20 | Fisher Controls International, Inc. | A network accessible interface for a process control network |
EP0959398A1 (de) | 1998-05-01 | 1999-11-24 | The Foxboro Company | Verfahren und Gerät zur Analyse von Alarmmitteln |
US6774786B1 (en) | 2000-11-07 | 2004-08-10 | Fisher-Rosemount Systems, Inc. | Integrated alarm display in a process control network |
WO2000072285A1 (en) | 1999-05-24 | 2000-11-30 | Heat-Timer Corporation | Electronic message delivery system utilizable in the monitoring oe remote equipment and method of same |
-
2000
- 2000-11-07 US US09/707,580 patent/US6774786B1/en not_active Expired - Lifetime
-
2001
- 2001-11-05 GB GB0126490A patent/GB2372365B/en not_active Expired - Lifetime
- 2001-11-07 JP JP2001342162A patent/JP2002222012A/ja active Pending
- 2001-11-07 DE DE10154534.7A patent/DE10154534B4/de not_active Expired - Lifetime
-
2004
- 2004-08-10 US US10/915,629 patent/US7250856B2/en not_active Expired - Lifetime
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE10217107B4 (de) * | 2001-04-19 | 2013-02-07 | Fisher-Rosemount Systems, Inc. | Erweiterte Gerätealarme in einem Prozesssteuersystem |
DE10249423B4 (de) * | 2001-11-09 | 2007-12-06 | Siemens Ag | Bussystem |
WO2004025383A3 (de) * | 2002-08-29 | 2004-12-23 | Krones Ag | Verfahren, vorrichtung und system zum anzeigen von daten eines maschinensteuerungssystems |
WO2004025383A2 (de) * | 2002-08-29 | 2004-03-25 | Krones Ag | Verfahren, vorrichtung und system zum anzeigen von daten eines maschinensteuerungssystems |
US7761271B2 (en) | 2002-08-29 | 2010-07-20 | Krones Ag | Method, device and system for displaying data of a machine control system |
DE102004003605B4 (de) * | 2003-01-28 | 2016-05-19 | Fisher-Rosemount Systems, Inc. | Integriertes Diagnosesystem in einer Prozessanlage mit einem Prozesssteuerungssystem und einem Sicherheitssystem |
WO2004107069A1 (de) * | 2003-06-03 | 2004-12-09 | Endress + Hauser Flowtec Ag | Variables feldgerät für die prozessautomatisierungstechnik |
DE102005060696B4 (de) * | 2004-12-20 | 2016-10-27 | Abb Ab | Verfahren und System zur automatischen Entscheidung, welcher Alarm, der in einer industriellen Fabrik generiert wird, einem Benutzer verborgen oder vorgelegt werden soll |
US7389150B2 (en) | 2005-04-01 | 2008-06-17 | Fanuc Ltd | Display system for controller |
EP1708063A1 (de) * | 2005-04-01 | 2006-10-04 | Fanuc Ltd | Anzeigesystem für eine Steuerung |
DE102009020151A1 (de) * | 2009-05-06 | 2010-11-11 | Siemens Aktiengesellschaft | Verfahren zur Ermittlung und Bewertung von Kenngrößen einer elektrischen Energieversorgung |
US9471052B2 (en) | 2011-08-11 | 2016-10-18 | Abb Research Ltd. | Alarm visualization |
DE102013109823B4 (de) | 2012-09-07 | 2019-10-02 | Fanuc Robotics America Corp. | System zur Überwachung/Analyse von in Zusammenhang mit Robotern stehenden Informationen und deren Darstellung auf einem Smart-Gerät |
EP3270248A1 (de) * | 2016-07-13 | 2018-01-17 | Siemens Aktiengesellschaft | Verwaltung von systemalarmen auf bedien- und/oder beobachtungsgeräten |
DE102018111892B4 (de) | 2017-05-22 | 2023-06-29 | Okuma Corporation | Betriebsüberwachungsvorrichtung und Steuerprogramm dafür |
DE102021212607A1 (de) | 2021-11-09 | 2023-05-11 | Siemens Healthcare Gmbh | Verfahren zum Bereitstellen eines Trigger-Tokens |
Also Published As
Publication number | Publication date |
---|---|
DE10154534B4 (de) | 2017-04-13 |
GB2372365B (en) | 2004-10-27 |
JP2002222012A (ja) | 2002-08-09 |
US20050012608A1 (en) | 2005-01-20 |
US7250856B2 (en) | 2007-07-31 |
GB2372365A (en) | 2002-08-21 |
US6774786B1 (en) | 2004-08-10 |
GB0126490D0 (en) | 2002-01-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE10154534B4 (de) | Integrierte Alarmanzeige in einem Prozeßsteuerungsnetzwerk | |
DE10217107B4 (de) | Erweiterte Gerätealarme in einem Prozesssteuersystem | |
DE60210448T2 (de) | Verbesserter hart-gerätealarm in einem prozesssteuerungssystem | |
DE102004015617B4 (de) | Online-Geräteprüfblock, der in ein Prozeßsteuerungs-/Sicherheitssystem integriert ist | |
DE69925069T2 (de) | Managementsystem für Feldgeräte | |
EP2353052B1 (de) | Sicherheitssteuerung und verfahren zum steuern einer automatisierten anlage | |
EP2356526B1 (de) | Sicherheitssteuerung und verfahren zum steuern einer automatisierten anlage | |
DE102010061132A1 (de) | Verfahren und Geräte zum Verwalten von Prozesssteuerungs-Status-Rollups | |
DE112004000362T5 (de) | Ausgabe von Benachrichtigungen einer Prozessanlage | |
DE102015116823A1 (de) | Verfahren und Vorrichtung zum Filtern von Prozesssteuerungssystemalarmen basierend auf dem Alarmquellentyp und/oder Alarmzweck | |
EP3953774B1 (de) | Vorrichtung zum auffinden von alarmursachen | |
EP2430504B1 (de) | Alarmverwaltungssystem | |
DE102008060005A1 (de) | Sicherheitssteuerung und Verfahren zum Steuern einer automatisierten Anlage mit einer Vielzahl von Anlagenhardwarekomponenten | |
WO2006092382A2 (de) | Engineeringsystem | |
DE102007029321A1 (de) | Verfahren zum Betreiben eines Feldgerätes in einem benutzerfreundlichen Modus | |
WO2019068435A1 (de) | Smartwatch und verfahren instandhaltung einer anlage der automatisierungstechnik | |
EP2188688B1 (de) | Verfahren zur überwachung einer technischen anlage und überwachungssystem zur durchführung des verfahrens | |
EP4047433A1 (de) | Konfigurierbare notifikationen über zustandsänderungen von technischen objekten | |
EP4030252B1 (de) | Lastmanagement bei der darstellung einer alarmmeldungsanzeige | |
EP4354233A1 (de) | Leitsystem für eine technische anlage und betriebsverfahren | |
EP3855266A1 (de) | Verfahren zum verarbeiten von alarmen in einem leitsystem einer technischen anlage | |
EP4290326A1 (de) | Leitsystem für eine technische anlage und betriebsverfahren | |
EP4137900A1 (de) | Alarmassoziierte container in anlagenbildern technischer anlagen | |
EP4261629A1 (de) | Leitsystem für eine technische anlage und betriebsverfahren | |
EP4123401A1 (de) | Granulare darstellung eines ladezustands webbasierter elemente eines leitsystems für eine technische anlage |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8110 | Request for examination paragraph 44 | ||
R016 | Response to examination communication | ||
R018 | Grant decision by examination section/examining division | ||
R020 | Patent grant now final | ||
R071 | Expiry of right |