-
Die
Erfindung liegt insbesondere auf dem Gebiet der Medizintechnik und
betrifft insbesondere die Behandlung von Fehlern bzw. Fehlermeldungen von
Peripheriegeräten
innerhalb eines gesamten Systems, die über ein Netzwerk miteinander
verbunden sind.
-
Medizintechnische
Systeme umfassen heutzutage in der Regel eine Vielzahl von angeschlossenen
Geräten,
die jeweils über
ein Netzwerk miteinander in Datenaustausch stehen und beispielsweise Magnetresonanztomographen,
Computertomographen etc. umfassen, mit diesbezüglich angeordneten Peripheriegeräten, wie
beispielweise Injektoren, Laborbefundungsgeräten, Blutdruckmessgeräten oder weiteren
Peripheriegeräten.
Um den Ausfall eines Gerätes
durch das Auftreten von Fehlern möglichst schnell beheben zu
können,
und um weitere Folgefehler in dem Gesamtsystem zu vermeiden, ist
es notwendig, Vorkehrungen zu treffen, wie mit Fehlermeldungen von
technischen Geräten
umzugehen ist. Hierzu muss festgelegt werden, in welchen Fällen eine
Fehlermeldung zu erscheinen hat, in welcher Form sie zu erscheinen
hat, und welche Auswirkungen davon ausgehen bzw. welche weiteren
Instanzen in dem Netzwerk betroffen sind. Dabei ist zu berücksichtigen,
dass Fehlermeldungen in der Regel kontextabhängig interpretiert werden müssen. Dies bedeutet,
dass es wenig zielführend
ist, wenn eine Fehlermeldung lediglich für sich betrachtet wird. Im Gegenteil
ist es wichtig, dass der gesamte Zusammenhang des jeweiligen Gerätes, das
eine Fehlermeldung verursacht hat, betrachtet wird. Dies ist insbesondere
für modular
aufgebaute Systeme, die mehrere Teilkomponenten umfassen, besonders wichtig.
-
Das
Verarbeiten von Fehlermeldungen ist jedoch nicht statisch, sondern
unterliegt in der Regel einem Wandel im Laufe der Zeit. So kommt
es beispielsweise häufig
vor, dass eine ursprünglich
als sehr wichtig angesehene Fehlermeldung zunehmend and Bedeutung
verliert und deshalb nicht mehr an hervorgehobener Position dargestellt
werden soll, sondern eine andere, modifizierte Verarbeitung verlangt.
-
Die
Verarbeitung von Fehlermeldungen, insbesondere das Darstellen der
Fehlermeldung, ist für das
Gesamtsystem deshalb von besonderer Bedeutung, da ein Fehler mit
hoher Priorität
auch als solcher und auf hervorgehobene Art dargestellt werden sollte,
um eine möglichst
schnelle Fehlerbehandlungsroutine zu triggern.
-
Im
Stand der Technik ist es bei den heute in Einsatz befindlichen medizintechnischen
Peripheriegeräten
bekannt, Gerätefehlermeldungen über eine zentrale Überwachungssoftware
zu verarbeiten. Die Überwachungssoftware
ist üblicherweise
Bestandteil einer Systemsoftware und sozusagen als übergreifende
Instanz über
die Peripheriegeräte
bereitgestellt. Durch das Verarbeiten der Fehlermeldungen eines
Peripheriegerätes
auf einer zentralen Ebene wird es möglich, die Auswirkungen der
jeweiligen Fehlermeldung auf das Gesamtsystem zu erfassen. Nachteil
dieses Architekturkonzeptes ist jedoch darin zu sehen, dass jegliche Änderungen
im Hinblick auf das Verarbeiten der Fehlermeldungen immer ein umständliches Ändern der
Systemsoftware nach sich ziehen. Dies hat mit anderen Worten zur
Folge, dass eine Änderung
bei der Verarbeitung einer einzelnen Fehlermeldung eines Peripheriegerätes jedes
Mal die gesamte Systemsoftware angepasst werden muss. Dies führt zu Fehlern
und auch deshalb zu einem unbefriedigenden Zustand, da das Anpassen der
Systemssoftware häufig
unterbleibt, sodass die Fehlermeldungen nicht mehr nach dem neuesten Stand
verarbeitet werden können.
-
Aufgabe
der vorliegenden Erfindung ist es deshalb, einen Weg vorzuschlagen,
mit dem das Verarbeiten von Fehlermeldungen von medizintechnischen
Peripheriegeräten
verbessert und ver einfacht werden kann. Darüber hinaus soll das Verarbeiten von
Fehlermeldungen dieser Geräte
weiter flexibilisiert werden. Diese Aufgabe wird durch ein Verfahren gemäß beiliegendem
Hauptanspruch gelöst.
-
Nachstehend
wird die Lösung
der Aufgabe in Bezug auf das Verfahren beschrieben. Hierbei erwähnte Merkmale,
Vorteile und alternative Ausführungsformen
sind ebenso auch auf die anderen beanspruchten Gegenstände zu übertragen
und umgekehrt. Mit anderen Worten können auch die gegenständlichen
Ansprüche
(die beispielsweise auf ein Computerprogrammprodukt und auf ein
System gerichtet sind) mit den Merkmalen weitergebildet sein, die
in Zusammenhang mit dem Verfahren beschrieben oder beansprucht werden
und umgekehrt. Die entsprechenden funktionalen Merkmale des Verfahrens
werden dann durch entsprechende gegenständliche Module, insbesondere
durch Hardwaremodule des Systems ausgebildet.
-
Die
Aufgabe wird insbesondere durch ein Verfahren zum Verwalten von
Fehlermeldungen gelöst,
die in Zusammenhang mit einem elektronischen Gerät ausgegeben werden, das über einen
adressorientierten Zugriffsmechanismus auf Gerätevariablen verfügt. Mit
dem Gerät
wird eine Gerätekonfigurationsdatei
bereitgestellt, die erfindungsgemäß um ein Meldeobjekt erweitert
wird. Das Verfahren umfasst folgende Verfahrensschritte:
- – Einlesen
des Meldeobjektes mit Meldeobjektparametern aus der erweiterten
Gerätekonfigurationsdatei;
- – Abfangen
einer Fehlermeldung;
- – Parametrisieren
der abgefangenen Fehlermeldung mit den eingelesenen Meldeobjektsparametern
des Meldeobjekts;
- – Verwalten
der parametrisierte Fehlermeldung.
-
Das
vorstehend erwähnte
Verfahren ist computerimplementiert und dient zum Verwalten von
Meldungen.
-
Bei
den Meldungen handelt es sich in der bevorzugten Ausführungsform
um Fehlermeldungen des elektronischen Gerätes, alternativ kann es sich jedoch
um anders geartete Meldungen handeln, die einen anderen Inhalt haben,
beispielsweise um Informationsmeldungen, Statusmeldungen etc.
-
Bei
dem elektronischen Gerät
handelt es sich gemäß einer
bevorzugten Ausführungsform
um medizintechnische Peripheriegeräte, die einen adressorientierten
Zugriffsmechanismus auf Gerätevariablen
haben. Dabei kann es sich beispielsweise um Geräte handeln, die nach einem
sogenannten CANopen-Standard kommunizieren. CANopen ist ein Kommunikationsprotokoll,
das aus der Automatisierungstechnik stammt und zur Vernetzung bzw. Kommunikation
von elektronischen Geräten
eingesetzt wird. Bei Geräten,
die nach dem CANopen-Standard kommunizieren, ist es erforderlich, dass
elektronische Datenblätter,
sogenannte electronic data sheets, verwendet werden. Dabei handelt
es sich um elektronische Dateien, die in einem standardisierten
Format gespeichert sind, um Metainformation in Hinblick auf das
jeweilige Gerät
bereitzustellen. Aus dieser Datei, dem electronic data sheet, wird eine
weitere Konfigurationsdatei generiert, eine sogenanntes device configuration
file. Bei dem device configuration file handelt es sich auch um
eine Konfigurationsdatei, in der ein Hersteller des jeweiligen Gerätes weitere
Informationen zur Benutzung zur Verfügung stellen kann. Erfindungsgemäß wird nun diese
Konfigurationsdatei erweitert, sodass sie ein Meldeobjekt umfasst.
-
Bei
dem Meldeobjekt handelt es sich um eine informationstechnologische
Instanz, in der in der Regel eine Vielzahl von Meldeobjektsparametern
zusammengefasst wird. Unter dem Begriff „Meldeobjektparameter” sollen
solche Parameter verstanden werden, die für das Layout bzw. das Darstellen
der jeweiligen Fehlermeldung, für
die Bewertung, bzw. die Gewichtung der jeweiligen Fehlermeldung
und für
die weitere Behandlung bzw. für
das Verarbeiten der Fehlermeldung relevant sind. Beispielsweise
fallen darunter Parameter, die festlegen, wie die Fehlermeldung
auf einem Monitor dargestellt werden soll (beispielweise als Pop-Up-Fenster)
und wo die Fehlermeldung gespeichert werden soll und unter welchen Bedingungen.
Die Liste von möglichen
Meldeobjektparametern ist dynamisch konfigurierbar und erweiterbar.
-
Unter
dem Begriff „Parametrisieren” der abgefangenen
Fehlermeldung mit den eingelesenen Meldeobjektparametern des Meldeobjekts
ist zu verstehen, dass die abgefangene Fehlermeldung mit dem aktuellen
und jeweils neu eingelesenen Meldeobjektparameter abgeglichen wird.
Mit anderen Worten wird jeweils nach einem Erfassen einer Fehlermeldung
zusätzlich
erfasst, wie diese Fehlermeldung verwaltet bzw. verarbeitet werden
soll. Um das Verarbeiten bzw. Verwalten zu spezifizieren, werden
Meldeobjektparameter definiert.
-
Der
Begriff „Verwalten” umfasst
alle Formen der Verarbeitung von Fehlermeldungen, beginnend von
der Darstellung der jeweiligen Fehlermeldung in der zugeordneten
Form und Art und Weise. Darüber hinaus
kann auch ein Bewerten der Relevanz bzw. der Wichtigkeit der jeweiligen
Fehlermeldung umfasst sein. Dieses Merkmal ist besonders bei komplexen
Systemen wichtig, bei denen die Vielzahl der Fehlermeldungen hinsichtlich
ihrer Relevanz priorisiert werden muß. In komplexeren Ausführungsformen
der Erfindung kann das Verwalten auch ein Speichern der Fehlermeldung
und ein Weiterverarbeiten derselben umfassen. Das Weiterverarbeiten kann
zusätzliche
Recovery-Strategien
umfassen, sowie weitere Maßnahmen
in Bezug auf die Fehlermeldung auslösen. Üblicherweise werden die Konfigurationsdateien
nach dem CANopen-Standard jeweils in einer Datei zur Verfügung gestellt
(electronic data sheet und device configuration file). Es ist jedoch auch
möglich,
die entsprechenden Informationen aus den Konfigurationsdateien nicht
in einer separaten Datei bereitzustellen, sondern über mehrere
Dateien verteilt.
-
Wie
vorstehend bereits erwähnt
bezieht sich die bevorzugte Ausführungsform
der vorliegenden Erfindung auf Geräte, die nach dem CANopen-Standard
kommunizieren. Alternativ sind jedoch hier andere Standards ebenso
möglich
wie, beispielsweise der USB-Standard etc.
-
Gemäß einer
bevorzugten Ausführungsform der
Erfindung umfassen die Meldeobjektparameter Informationen für das Verwalten
der jeweiligen Fehlermeldung. Diese Informationen beziehen sich
insbesondere auf die Art der Darstellung der Fehlermeldung, die
Bewertung der Fehlermeldung anhand von konfigurierbaren Priorisierungskriterien
und Zusatzinformationen bei der Anzeige der Fehlermeldung. Die Meldeobjektparameter
umfassen insbesondere Fehlermeldungskennzeichnungen, Fehlermeldungsquellinformationen,
Triggerinformationen, Layout-Informationen
und/oder Fehlerbewertungsinformationen. Das Verwalten, insbesondere
die Darstellung der Fehlermeldung wird in Abhängigkeit von den Meldeobjektparametern
ausgeführt.
Dies hat den Vorteil, dass auf einer abstrakt höher liegenden Ebene definiert
werden kann, wie bestimmte Fehlermeldungen zu behandeln sind. Damit
wird es möglich
bestimmte Gruppen von Fehlermeldungen generisch und gemeinsam zu
behandeln, ohne die spezifische Fehlermeldung im Einzelfall verarbeiten
zu müssen.
Durch das Bereitstellen des Meldeobjektes mit dem die Konfigurationsdatei
erweitert wird, wird es darüber
hinaus auch möglich,
dass bisherige Meldungen modifiziert behandelt werden können bzw.
dass neue Meldungen eingefügt
werden können,
ohne die Systemsoftware anpassen zu müssen.
-
Gemäß einem
weiteren Aspekt der vorliegenden Erfindung umfasst die Layout-Information Daten
darüber,
in welcher Form die Fehlermeldung auf einen konfigurierbaren Darstellungsort
angezeigt werden soll. Die Layout-Information kann sich auch darauf
beziehen wie Fehlermeldungen in Bezug auf unterschiedliche Darstellungsorte
angezeigt werden sollen. Gemäß einer
bevorzugten Ausführungsform der
Erfindung ist eine Datenbasis mit Regeln vorgesehen, die definieren,
welchen Beziehungen unter den Meldeobjektsparametern bestehen. Beispielsweise
kann eine Regel darauf gerichtet sein, dass alle Fehlermeldungen,
die mit höchster
Priorität
gewertet werden, eine bestimmte Darstellungsform benötigen und
beispielsweise stets als Pop-Up-Fenster dargestellt werden müssen, um
auf die Re levanz der jeweiligen Fehlermeldung hinzuweisen. Andere
weniger wichtige Fehlermeldungen können in Form einer einfachen
Benachrichtigung an den Anwender ausgeführt werden.
-
In
einer bevorzugten Ausführungsform
ist das Verfahren so ausgebildet, dass das Meldeobjekt mit den Meldeobjektparametern
grundsätzlich
bei jedem System-Hochlauf eingelesen wird. Es kann also vorgesehen
sein, dass das Meldeobjekt immer dann eingelesen wird, wenn das
jeweils zugehörige
Gerät gestartet
wird oder, wenn das System, in das das jeweilige Gerät eingebettet
ist, hochgefahren wird. Alternativ hierzu ist es möglich, dass
die Meldeobjektparameter nach konfigurierbaren Ereignissen eingelesen
werden. Beispielsweise ist es möglich,
dass ein User definieren kann, dass immer dann das Meldeobjekt eingelesen
wird, wenn es verändert
worden ist. Ebenso könne
andere Einlesekriterien dynamisch festgelegt werden.
-
In
der bevorzugten Ausführungsform
entspricht ein Format des Meldeobjektes demjenigen des üblichen
CANopen-Standards.
-
Neben
den vorstehend erwähnten
Meldeobjektparametern können
optional noch weitere Meldetexte in das Meldeobjekt integriert werden.
Dabei kann es sich beispielsweise um Meldetexte handeln, die eine
Gruppe von Meldungen zusammenfassend für den User kennzeichnen sollen.
Darüber
hinaus ist es möglich,
Meldetexte in unterschiedlichen Sprachen zur Verfügung zu
stellen. Ebenso kann eine Referenz auf eine andere Meldung vorgesehen
sein.
-
Gemäß einer
bevorzugten Ausführungsform der
Erfindung ist es vorgesehen, dass das Verwalten der jeweiligen Fehlermeldung
kontext-sensitiv erfolgt. Mit anderen Worten wird der Gesamtzustand des
Systems, in dem sich das elektronische Gerät befindet, berücksichtigt.
Beispielsweise werden Fehlermeldungen, die von lebensverlängernden
Geräten ausgegeben
werden mit der höchsten
Relevanz bewertet, als Fehlermeldungen von Laborgeräten, die keine
Relevanz für
das Leben eines Patienten haben. Mit anderen Worten kann auf einer
höheren
Ebene einheitlich festgelegt werden, welche Fehlermeldungen auf
welche Art und Weise zur Darstellung gebracht werden soll. Damit
kann zum Einen das Darstellen von Fehlermeldungen vereinheitlicht
werden und es ist zum Anderen möglich,
bestimmte Gruppen von Fehlermeldungen zu bilden, die denselben oder einen ähnlichen
Situationszusammenhang haben und gleich verwaltet werden sollen.
Alle Fehlermeldungen, die also einen solchen Situationszusammenhang
haben, werden dann einheitlich dargestellt. Dies vereinfacht und
verbessert die Benutzung des Systems deutlich.
-
Im
Unterschied zu bisherigen Fehlermeldungssystemen aus dem Stand der
Technik ist es mit dem erfindungsgemäßen Verfahren möglich, Fehlermeldungsgruppen
zu bilden. Abhängig
von der Zuordnung einer Fehlermeldung zu einer bestimmten Gruppe,
wird die Darstellung derselben gesteuert. In der Regel wird es hier
vorgesehen sein, das alle Fehlermeldungen mit hoher Priorität auch besonders hervorgehoben
dargestellt werden, während
weniger wichtige Fehlermeldungen auch in Form einer einfachen Meldung
zur Darstellung gebracht werden können. Die wählbare Form ist konfigurierbar.
-
Gemäß einem
weiteren Aspekt der vorliegenden Erfindung umfasst das Verwalten
ein Modifizieren und/oder ein Löschen
von bereits bestehenden Fehlermeldungen. Darüber hinaus ist es möglich, dass
neue Fehlermeldungen in das System integriert werden, ohne dass
eine Systemsoftware geändert
werden muss. Mit der erfindungsgemäßen Lösung wird es also möglich, dass
eine Fehlermeldung, die aufgrund eines spezifischen Fehlerfalls
bei einem Gerät
neu aufgenommen wird, jeweils auch bei den anderen Geräten unmittelbar
zur Verfügung
steht. Dies erhöht
die Flexibilität
des Systems deutlich.
-
Auch
das Meldeobjekt ist dynamisch veränderlich. So können die
Meldeobjektparameter immer wieder neu konfiguriert werden. Es ist
vorgesehen, dass jeweils die aktuellste Version des Meldeobjekts verwendet
wird. Gemäß einem
weiteren Aspekt der vorliegenden Erfindung ist es vorgesehen, dass
auch der Darstellungsort für
das Darstellen der Fehlermeldung konfigurierbar ist. Deshalb ist
es möglich,
das beispielsweise wichtige Fehlermeldungen auch an einer relativ
hohen Position im System dargestellt werden (beispielsweise auf
Systemadministratorebene oder beispielsweise auf allen angeschlossenen Geräten, um
die Anzahl der Anwender zu erhöhen, die
diese Fehlermeldung lesen). Ist die Fehlermeldung hingegen von geringerer
Relevanz, so kann auch die Anzahl der Darstellungsorte minimiert
werden. Um die Relevanz der jeweiligen Fehlermeldung ausreichend
detailliert einschätzen
zu können,
sind Regeln vorgesehen, in denen festgelegt wird, wie die Fehlermeldungen
in Abhängigkeit
von ihrer Wichtigkeit (bzw. von Bewertung oder Relevanz) verwaltet werden
sollen.
-
Eine
weitere Aufgabenlösung
besteht in einem Computerprogrammprodukt und in einem System gemäß den beiliegenden
Hauptansprüchen.
Das System umfasst neben dem jeweiligen elektronischen Gerät ein Speichermedium,
auf dem eine Konfigurationsdatei gespeichert ist, die ein Meldeobjekt umfasst,
einen Textstreamer, der das jeweils aktualisierte Meldeobjekt einliest
und eine Event-Handler, der eine Fehlermeldung abfängt und
die Fehlermeldung anhand den aus dem Speichermedium und dem Textstreamer
ausgelesenen Bedingungen verwaltet bzw. insbesondere darstellt.
-
1 eine übersichtsartige
Darstellung von Bestandteilen eines erfindungsgemäßen Systems;
-
2 eine
schematische Darstellung eines Workflows gemäß einer bevorzugten Ausführungsform
der Erfindung und
-
3 ein
Beispiel für
ein Meldeobjekt gemäß einer
bevorzugten Ausführungsform
der Erfindung.
-
Im
Folgenden wird im Zusammenhang mit 1 der grobe
Kontext der vorliegenden Erfindung dargestellt. Die Erfindung schlägt einen
generischen Mechanismus vor, um Fehlermeldungen von elektronischen
CANopen-Geräten 100 auf
zentraler Ebene zu verwalten ohne Eingriff bzw. Änderung der Systemsoftware.
In der Systemsoftware ist üblicherweise eine Überwachungssoft ware
integriert, die dazu dient, Fehlermeldungen von mehreren dezentral
angeordneten elektronischen Geräten
zu verwalten. Eine Modifikation an der Systemsoftware ist mit relativ
hohem Aufwand verbunden, da dafür
in der Regel ein Systemadministrator notwenig ist und da dies nicht
von dezentraler Stelle – sozusagen
vor Ort – an dem
elektronischen Gerät 100 ausgeführt werden kann.
In 1 ist die Überwachungssoftware
innerhalb der Systemsoftware mit dem eckigen Kasten bezeichnet,
der über
einer in der Mitte dargestellten Schnittstelle angeordnet ist. Bei
der Schnittstelle handelt es sich in der bevorzugten Ausführungsform um
einen CANopen-Bus BUS. In anderen Ausführungsformen können jedoch
andere Schnittstellen vorgesehen sein, um die elektronischen Geräte 100 an
eine zentrale Verwaltungsinstanz anzuschließen, beispielsweise über USB-Schnittstellen.
-
Das
erfindungsgemäße System
umfasst also ein Speichermedium 110, auf dem die Gerätekonfigurationsdatei
DCF abgelegt ist. Vorzugsweise ist das Speichermedium 110 auch
in dem elektronischen Gerät 100 angeordnet.
Alternativ kann jedoch das Speichermedium 110 auch auf
einer externen Instanz abgelegt sein, die in Datenaustausch mit
dem elektronischen Gerät 100 steht.
Grundsätzlich
ist es unerheblich, ob das Konfigurationsfile DCF als separate Datei
ausgebildet ist oder ob es über
mehrere Dateien aufgeteilt wird.
-
Darüber hinaus
umfasst das System einen Textstreamer 120, der ein Meldeobjekt
MO aus der erweiterten Gerätekonfigurationsdatei
DCF einliest und eine Event-Handler 130, der die Fehlermeldung abfängt und
parametrisiert. Der Textstreamer 120 und/oder der Event-Handler 130 können in
derselben aber auch in unterschiedlichen Instanzen ausgebildet sein.
Sie können
entweder in dem elektronischen Gerät 100 ausgebildet
sein; alternativ können
sie in dem zentralen Überwachungssystem
ausgebildet sein oder in einer Instanz, die ebenfalls über den
CANopen-Bus BUS an das System angeschlossen ist.
-
Für Geräte, die
nach dem CANopen-Standard konfiguriert sind, ist es vorgesehen,
dass ein elektronisches Datenblatt, ein sogenanntes electronic data
sheet EDS bereitgestellt wird. Das elektronische Datenblatt wird üblicherweise
vom Hersteller zur Verfügung
gestellt und erzeugt seinerseits eine weitere Datei, ein sogenanntes
device configuration file DCF. Bei den beiden Dateien device configuration file
DCF und electronic data sheet EDS handelt es sich um Konfigurationsdateien.
Gemäß einer
bevorzugten Ausführungsform
der vorliegenden Erfindung ist das device configuration file DCF
(im Folgenden auch als Gerätekonfigurationsdatei
DCF bezeichnet) um ein Meldeobjekt MO erweitert. In dem Meldeobjekt
MO sind Informationen bereitgestellt, die im Hinblick auf die Darstellung
und im Hinblick auf die Bewertung bzw. auf die weitere Verarbeitung
der Fehlermeldung relevant sind.
-
In 3 ist
ein Beispiel eines erweiterten Meldeobjektes MO dargestellt.
-
Gemäß einer
bevorzugten Ausführungsform der
Erfindung umfasst das Meldeobjekt MO folgende Angaben:
- – Einen
symbolischen Namen der Meldung. Dieser Name soll die Meldung innerhalb
des Gesamtsystems kennzeichnen und muss eindeutig sein.
- – Gerätedaten,
aus denen die Meldung abgeleitet wird. Dies ist in 3 mit
der Bezeichnung „MsgSourceName” gekennzeichnet.
Hier kann ein Parameter oder mehrere Parameter angegeben werden,
aus denen die Meldung abgeleitet werden soll. Dieser Parameter wird
standardmäßig innerhalb
des Konfigurationsfiles DCF hinsichtlich Adressierung und Zugriffsoption
vollständig
beschrieben.
- – Triggerinformationen,
die eine Meldung auslösen.
Dabei handelt es sich um Informationen bzw. Bedingungen, die festlegen,
wann eine Meldung zu erfolgen hat. Dies ist in 3 mit
der Bezeichnung „MsgTriggerValue” gekenn zeichnet.
Um einzelne Bits bzw. Gruppen von Bits triggern zu können, wird
eine Maske definiert, die über
eine UND-Verknüpfung
mit den zu untersuchenden Parametern verknüpft wird. Die Meldung wird
ausgelöst,
wenn der maskierte Parameter dem Triggerwert entspricht. Alternativ
können
hier neben der vorstehend erwähnten
UND-Verknüpfung auch
andere logischen Operatoren zum Einsatz kommen.
- – Darüber hinaus
kann zwischen unterschiedlichen Trigger-Typen unterschieden werden.
Beispielsweise kann „0” eine steigende
Flanke „1” eine fallende
Flanke und „2” ein Level
kennzeichnen.
- – Weiterhin
kann die Häufigkeit
des Auftretens von Fehlermeldungen gekennzeichnet werden. Darüber hinaus
ist es möglich
das Absetzen von Fehlermeldungen einzuschränken bzw. die Häufigkeit
zu verändern.
Dabei ist es beispielsweise konfigurierbar, ob die Meldung grundsätzlich bei jedem
Auftreten des Fehlers abgesetzt wird oder nur bei dem ersten Auftreten
des Fehlers oder beispielsweise nur dann, falls weitere systemspezifische
Bedingungen erfüllt
sind. Darüber
hinaus ist auch eine Kombination der vorstehenden Bedingungen konfigurierbar.
So könnte
beispielsweise definiert werden, dass eine Meldung grundsätzlich nur
beim ersten Auftreten abgesetzt wird, falls weitere systemspezifische
Bedingungen erfüllt
sind. Auch kann eine Abstandszeit definiert werden, die einen zeitlichen
Abstand zwischen dem Absetzen von zwei aufeinander folgenden Fehlermeldungen
definiert. Hier kann eine Mindestverzögerungszeit konfiguriert werden,
sodass sichergestellt ist, dass Fehlermeldungen nicht unmittelbar
aufeinander folgen, sondern durch eine Mindestverzögerungszeit
voneinander beabstandet sind. Dies ist jedoch optional.
- – Die
Art und Weise der Darstellung der Fehlermeldung im System. Bei diesem
Parameter wird definiert, wie die Fehlermeldung im System dargestellt
werden soll. Der Eintrag wird bitweise interpretiert, dadurch wird
es möglich,
mehrere Dar stellungsformen sozusagen nebeneinander bzw. gleichzeitig
zu erlauben. In einer bevorzugten Ausführungsform der vorliegenden
Erfindung sind folgenden Konfigurationsmöglichkeiten für die Darstellung
vorkonfiguriert: Ein Statusfenster, ein Popup-Fenster, ein zu bestätigendes
Popup-Fenster (Popup confirmed) und ein sogenanntes Logfile. Andere
Ausführungsformen
sehen hier noch weitere Darstellungsarten vor. Es sei an dieser
Stelle darauf hingewiesen, dass der Anwender grundsätzlich noch
weitere Darstellungsmöglichkeiten
konfigurieren kann, um das System an seine spezifischen Anforderungsbedingungen
anpassen zu können.
Bei der Darstellung in Form eines Statusfensters wird die Fehlermeldung
einem Anwender in einem dem Anwender zugänglichen Fenster auf dem Bildschirm
dargestellt. Entsprechendes gilt für das Popup-Fenster, das ebenfalls
auf dem Bildschirm erscheint. Bei einem zu bestätigendem Popup-Fenster muss der
Anwender die jeweilige Meldung in dem Popup-Fenster bestätigen, um
weiter arbeiten zu können.
Bei dem Logfile wird die Meldung in einem systemspezifischen Logfile
abgelegt.
- – Wertigkeit
der Meldungen. Hier wird festgelegt, welche Auswirkungen die Meldung
auf das jeweilige Gesamtsystem hat. Die Art der Wertigkeit kann
konfiguriert werden. Gemäß einer
Voreinstellung bzw. Vorkonfiguration wird zwischen drei Wertigkeiten
unterschieden. In der ersten Stufe handelt es sich lediglich um
Information, während in
einer höheren
und zweiten Stufe Warnungen abgehandelt werden. In einer dritten
und noch höheren
Stufe werden Fehlermeldungen abgehandelt.
- – Weitere
Metainformationen, die über
Textfelder editierbar sind. Hier können Meldungstexte ebenfalls
in den DCF-File
DCF definiert werden. Es wird zwischen unterschiedlichen Textfeldern
unterschieden: Zum einen gibt es ein Textfeld, das eine grobe Zusammenfassung
für den
Nutzer bereitstellt.
-
Weitere
Textfelder können
für einen
Serviceeinsatz vorgesehen sein. Hier sind beispielsweise detaillierter
Erklärungen
im Hinblick auf die Meldung denkbar. Ebenso können weitere auszuführende Schritte
erläutert
werden. Darüber
hinaus können noch
weitere Metainformationen in Bezug auf die Meldung bereitgestellt
werden. Es sei an dieser Stelle angemerkt, dass die Meldungstexte
in unterschiedlichen Sprachen bereitgestellt werden können. Eine
entsprechende Referenz auf die Sprache kann konfiguriert werden.
-
Im
Folgenden soll im Zusammenhang mit 2 ein grundlegender
Ablauf des erfindungsgemäßen Verfahrens
gemäß einer
bevorzugten Ausführungsform
erläutert
werden.
-
In
einem ersten Schritt, der in 2 mit S1 gekennzeichnet
ist, werden Meldeobjektparameter des Meldeobjektes MO aus der erweiterten
Gerätekonfigurationsdatei
DCF eingelesen. In einem nächsten
Schritt wird die Fehlermeldung erfasst bzw. abgefangen. Die ist
in 2 mit dem Schritt S5 gekennzeichnet.
-
In
einem weiteren Schritt wird die erfasste bzw. abgefangene Fehlermeldung
mit den eingelesenen Meldeobjektparametern parametrisiert. Dies
ist mit dem Schritt S10 in 2 gekennzeichnet.
Daran schließt
sich als letzter Schritt S15 das Verwalten der Fehlermeldung in
der parametrisierten Form an. Mit anderen Worten erfolgt das Verwalten
der Fehlermeldung anhand der vorhergehenden Parametrisierung derselben.
-
Durch
die erfindungsgemäße Erweiterung des
Konfigurationsfiles DCF um Meldeobjekte MO können Gerätemeldungen auf einer höher liegenden Ebene – beispielsweise
auch auf Systemebene, ohne jedoch die Systemsoftware zu tangieren – behandelt
werden. Insbesondere können
das Erscheinungsbild, die Auslösung
und das Verarbeiten von Fehlermeldungen einheitlich im Gesamtsystem
konfiguriert und behandelt werden. Dies führt zu dem sich in der Praxis
als sehr wesentlich erweisenden Vorteil, dass ein Anwender des jeweiligen
Gerätes 100 ein
generisches Überwachungsprogramm
implementieren kann, das die benötigten
Informationen in einem Konfigurationsschritt aus der jeweiligen
Gerätebeschreibung
lädt. Vorzugsweise
erfolgt dies vollautomatisch, also ohne weitere Benutzerinteraktion. Dar über hinaus
ist das Ändern
von bestehenden Fehlermeldungen als auch das Einfügen von
neuen Meldungen sehr einfach und vor allem ohne Anpassung der Systemsoftware
möglich.
Vorzugsweise erfolgt das Modifizieren, Löschen und/oder Einbinden von
neuen Fehlermeldungen automatisch.
-
Im
Zusammenhang mit 2 sei darauf hingewiesen, dass
sich das erfindungsgemäße Verfahren
grundsätzlich
in zwei Phasen unterteilen lässt. Zum
einen ist eine Definitionsphase vorgesehen, in die der Schritt S1
einzuteilen ist. Die anderen Schritte S5, S10 und S15 finden in
einer zweiten Phase, in einer sogenannten Laufzeit-Phase statt.
Die beiden Phasen sind zeitlich voneinander entkoppelbar. Mit anderen
Worten kann im Vorfeld in der Definitionsphase festgelegt werden,
welche Behandlung für
die jeweilige Fehlermeldung vorgesehen sein soll. Entsprechend wird
das Meldeobjekt MO konfiguriert, Damit kann eine strukturierte Beschreibung
der Meldungen bereits zu einem sehr frühen Zeitpunkt und möglichst
noch mit dem jeweiligen Komponentenzulieferer getroffen werden.
Dies verbessert den Arbeitseinsatz enorm und kann das Auftreten
von schweren Fehlerzuständen
bereits im Vorfeld vermeiden.
-
Zur
Laufzeit bzw., in der Laufzeitphase werden dann die jeweiligen Fehlermeldungen
erfasst und anhand der Definitionsphase bestimmten Meldeobjektparametern
des Meldeobjektes MO parametrisiert und entsprechend verwaltet.
In einer vorteilhaften Weiterbildung der Erfindung ist es vorgesehen, dass
die Definitionsphase erweitert wird, sodass auch zur Laufzeit Definitionen
bzw. Konfigurationen in Hinblick auf das Meldeobjekt MO ausgeführt werden
können.
Damit wird die Flexibilität
des Systems erweitert.
-
Die
vorstehende detaillierte Beschreibung der Figuren bezog sich auf
die Behandlung von Fehlermeldung. Die Erfindung ist jedoch auch
auf Meldungen anderer Art anzuwenden, beispielsweise auch solche,
die sich auf einen Status des jeweiligen Gerätes, auf die Auslastung oder
auf andere Parameter des Gerätes
beziehen.
-
Mit
dem erfindungsgemäßen Vorschlag
wird es möglich,
dass die Geräte 100 des
Gesamtsystems deshalb deutlich einfacher verwendet werden können, da
sich der Anwender nur an eine (einheitliche) Behandlung von Meldungen
gewöhnen
muss. Das Verwalten der Fehlermeldung umfasst ein Darstellen bzw.
Anzeigen der Fehlermeldung auf einem Monitor, die Art der Darstellung
(Größe, Ort
der Darstellung in Form einer Liste oder in Form eines Fensters
etc.), Darstellungsort innerhalb des Systems (soll die Fehlermeldung
nur auf dem jeweils spezifischen Gerät 100 dargestellt
werden oder soll die Fehlermeldung beispielsweise auch auf Systemebene
dem Administrator zugestellt werden etc. ?), die Dauer der Darstellung
der jeweiligen Fehlermeldung, konfigurierbare Ereignisse, die erfüllt sein
müssen,
damit die Fehlermeldung überhaupt
erst dargestellt wird, Systembedingungen, die erfüllt sein
müssen,
damit die Fehlermeldung in einer bestimmten Form dargestellt wird und/oder
Bedingungen in Bezug auf andere elektronische Geräte 100,
die erfüllt
sein müssen,
damit die Fehlermeldung angezeigt wird. Die vorstehende Aufzählung ist
jedoch nicht abschließend
und kann jederzeit, insbesondere nach jeweiligem Anwender frei konfiguriert
und erweitert werden.