-
Die
Erfindung liegt auf dem Gebiet der Überwachung und der Fehlerbehebung
von Prozessen. Die zu überwachenden
Prozesse sind Bestandteil eines Netzwerkes.
-
Das
hauptsächliche
Anwendungsgebiet der vorliegenden Erfindung und damit auch der Prozesse liegt
auf dem Gebiet der Medizintechnik, insbesondere handelt es sich
um radiologische Systeme.
-
Die
Erfindung bezieht sich insbesondere auf ein Verfahren, eine Vorrichtung
und ein System zum Monitoring von einer Vielzahl von Applikationen,
insbesondere von medizintechnischen Applikationen, in einem Netzwerk,
mit einer Monitoring-Einheit,
der die zentrale Aufgabe bei dem Monitoring zukommt.
-
Die
Architektur eines solchen Netzwerkes ist üblicherweise so ausgebildet,
dass eine Vielzahl der Applikationen bzw. Anwendungen über das
Netzwerk miteinander kommunizieren. Insbesondere auf medizintechnischem
Gebiet ist die hohe Verfügbarkeit
und eine optimale Zuverlässigkeit
des Systems eine notwendige Voraussetzung für deren Einsatz. Somit kommt
der Überwachung,
bzw. dem Monitoring solcher Systeme eine verstärkte Bedeutung zu.
-
Bei
bekannten Überwachungssystemen
aus dem Stand der Technik musste jeder einzelne Prozess separat
und auf der Ebene des Prozesses überwacht
werden. Die Architektur bekannter Systeme basiert auf dem Konzept,
lediglich die Prozesse auf einer Ebene vorzusehen und keine übergreifende, d.h.
hierarchisch übergeordnete
Instanz einzuführen. Dies
führt zu
dem Nachteil, dass keine prozessübergreifende Überwachung
möglich
ist.
-
Bisher
wurden sogenannte „Watch-Dogs" oder Prozessüberwacher
eingesetzt, die überprüfen, ob
der jeweilige Prozess fehlerfrei läuft. Falls ein Fehlerzustand
erfasst wird, kann entweder der Prozess neu gestartet werden oder
es kann der Servicetechniker gerufen werden, um manuell den Fehlerzustand
wieder zu bereinigen. Darüber
hinaus ist es vorgesehen, ein so genanntes Log-File mitzuführen, in
dem alle erfassten Fehler unterschiedlicher Prozesse tabellenartig
gespeichert sind. Das Log-File dient zur Nachvollziehbarkeit bestimmter
Fehlerszenarien und kann gegebenenfalls die Arbeit eines Servicetechnikers
erleichtern.
-
Das
bekannte Vorgehen nach dem Stand der Technik birgt jedoch einige
Nachteile.
-
Aus
einem Kostengesichtspunkt heraus erweist es sich als nachteilig,
dass grundsätzlich
ein Servicetechniker eingesetzt werden muss, um einen Fehler manuell
zu beheben.
-
Des
weiteren erweist es sich als uneffizient, dass die Diagnose bzw.
Fehlersuche lediglich separat, für
jede einzelne Prozesskomponente ausgeführt werden kann – prozessübergreifende
Fehlerzustände
können
nicht erkannt werden.
-
Durch
die Tatsache, dass fehlerbezogene Informationen lediglich in dem
Log-File gespeichert werden, war es bislang nicht möglich, auf
gezielte Anfragen seitens einer Komponente oder seitens eines Servers
zu antworten. Bislang musste der Techniker manuell speziell angepasste
Filterdurchläufe auf
der Log-Datei ausführen,
um relevante Aspekte eines Problems näher eingrenzen zu können.
-
Wie
in 5 zum Stand der Technik gezeigt, wurden in dem
zentralen Log-File zwar alle Aspekte der einzelnen Modalitäten bzw.
Applikationen erfasst; ein applikations- übergreifendes
Fehlerszenario konnte allerdings mit diesem Ansatz nicht erkannt werden.
Soll z.B. eine PACS-Applikation (Picture-Archiving-Communication-System)
mit einer RIS-Applikation
(Radiology-Information-System) kommunizieren, und erfasst der eingesetzte
Watch-Dog, dass kein Bild auf der Arbeitsstation erscheint, so kann
es hierfür
verschiedene Ursachen geben. Die Diagnosemöglichkeiten bisheriger Watch-Dog-Systeme sind sehr
eingeschränkt.
Die Diagnose war dann möglich, wenn
der Fehler durch die jeweilige Applikation selbst verursacht worden
ist. So erkennt beispielsweise ein PACS-System aus sich heraus inkonsistente
Patientendaten. Der Watch-Dog für
das PACS-System kann jedoch nicht entscheiden, ob der Fehler, der
inkonsistenten Patientendaten durch seine prozess-spezifische Fehlerkonfiguration
oder durch eine anderweitige Ursache, beispielsweise durch das RIS-System,
verursacht worden ist.
-
Des
Weiteren sind die Fehlerbehebungsmöglichkeiten bisheriger Systeme
sehr eingeschränkt.
Im Wesentlichen existieren nur zwei Konzepte zur Fehlerbehebung:
Zum einen kann ein Neustarten des Systems initiiert werden und zum
anderen kann ein Servicetechniker benachrichtigt werden.
-
Die
vorliegende Erfindung hat sich deshalb zur Aufgabe gestellt, einen
Weg aufzuzeigen, mit dem prozess- bzw. applikationsübergreifende
Fehlerzustände
automatisch diagnostiziert werden können und der auch eine automatische
Fehlerkorrektur ermöglicht
und der es weiterhin ermöglicht,
dass eine Fehlerkorrektur bereits im Vorfeld erfolgt, d.h. bevor der
Fehler von dem Personal bzw. von dem User erkannt worden ist.
-
Diese
Aufgabe wird durch die beiliegenden, nebengeordneten Hauptansprüche gelöst.
-
Die
Aufgabe wird insbesondere durch Verfahren zum Monitoring und/oder
zur Fehlerbehebung von einer Vielzahl von vorwiegend medizintechnischen
Applikationen, insbesondere Radiologie- Applikationen, gelöst, die über ein Netzwerk miteinander kommunizieren,
und das auf eine Monitoring-Einheit zugreift, wobei alle Applikationen über eine
einheitliche Monitoring-Schnittstelle
kommunizieren, und wobei das Monitoring erfolgt, indem die Monitoring-Einheit
von der jeweils zu überwachenden
Applikation einen Statusbericht anfordert, und falls der Statusbericht
einen Fehlerzustand umfasst, folgende Schritte veranlasst:
- – Suche
in einer Datenbank nach einem dem erfassten Fehlerzustand zugeordneten
Fehlerbehebungs-Mechanismus mit zugeordneten applikations-spezifischen
Kommandos zur Fehlerbehebung und
- – Ausführung des
Fehlerbehebungs-Mechanismus durch übermitteln der Kommandos von
der Monitoring-Einheit über
die Monitoring-Schnittstelle an die Applikation.
-
Das
hauptsächliche
Anwendungsgebiet der vorliegenden Erfindung liegt auf dem Gebiet
der radiologischen Anwendungen. Es ist jedoch alternativ ebenso
möglich,
das vorliegende Monitoring- und Fehlerbehebungssystem auf beliebige
andere technische Gebiete zu übertragen,
bei denen eine Vielzahl von Applikationen über ein Netzwerk kommunizieren
und auf Fehlerfreiheit hin überwacht
werden sollen, wie z.B. Steuerungsanlagen in der Energietechnik,
verfahrenstechnische Anlagen, fertigungstechnische Anlagen, insbesondere
in der Automobil-Industrie
etc.
-
In
einer Vorphase ist es erfindungsgemäß vorgesehen, alle Applikationen
mit einer einheitlichen Monitoring-Schnittstelle auszubilden, über die
die Applikationen miteinander und mit anderen Einheiten über das
Netzwerk kommunizieren. In einer weiteren, ebenfalls zeitlich vorgelagerten
Phase, die allerdings unabhängig
von der ersten Phase sein kann, und vor dem eigentlichen Monitoring-Prozess,
senden die einzelnen, zu überwachenden
Module bzw. Applikationen über
deren Monitoring-Schnittstelle eine Datei mit Prozessdaten, vorzugsweise in
Form einer Tabelle. Diese Prozessdaten umfassen applikations-spezifische
Daten und/oder Daten, die grundsätzlich
von der jeweiligen Monitoring-Schnittstelle an die Monitoring-Einheit gesendet
werden können,
sowie Kommandos, die grundsätzlich
auf der Applikation ausführbar
sind und zur Fehlerbehebung dienen und von der Monitoring-Einheit über die
Monitoring-Schnittstelle initiiert werden können.
-
In
dieser/diesen Vorphase(n) sendet also jedes zu überwachende System seine grundsätzlichen Überwachungsdaten
an die Monitoring-Einheit. Bei der späteren Überwachung weiß die Monitoring-Einheit
deshalb, welche Prozessdaten sie von der jeweiligen Applikation
erwarten kann. Vorteilhafterweise ist es vorgesehen, diese Prozessdaten
einmalig bei der Wartung des Gesamtsystems vorzunehmen. Alternativ
ist es jedoch auch möglich,
dass das Versenden der applikations-spezifischen Prozessdaten bei jedem
Hochfahren der jeweiligen Applikation und/oder des Monitoring-Systems
erfolgt.
-
In
der bevorzugten Ausführungsform
senden alle zu überwachenden
Applikationen diese Prozessdaten. Dies hat den Vorteil, dass die
Monitoring-Einheit grundsätzlich
alle Prozessdaten aller Applikationen gespeichert hat, auch wenn
beispielsweise eine Applikation erst zu einem späteren Zeitpunkt in den Überwachungsprozess
eingeschlossen werden soll. In alternativen Ausführungsformen hat der Anwender bzw.
der System-Administrator
zusätzliche
Steuerungs- und Einflussmöglichkeiten,
indem vorgesehen ist, dass nur einige ausgewählte, relevante Applikationen
die Prozessdaten an die Monitoring-Einheit senden. Dies hat den Vorteil,
dass nicht unnötigerweise
Prozessdaten an die Monitoring-Einheit gesendet werden müssen, wenn
beispielsweise die jeweilige Applikation zu diesem Zeitpunkt nicht überwacht
werden soll.
-
Nach
Abschluss der jeweiligen Vorphasen kann die eigentliche Monitoring-Phase,
d.h. der Überwachungsprozess
gestartet wer den. Dazu fordert die Monitoring-Einheit von der jeweils
zu überwachenden
Applikation einen Statusbericht an.
-
In
einer bevorzugten Ausführungsform
ist es vorgesehen, dass die Monitoring-Einheit den Statusbericht
grundsätzlich
von allen Applikationen anfordert, um ein umfassendes Monitoring-Resultat erzielen
zu können.
In einer alternativen Ausführungsform ist
der Umfang der Überwachungsaktion
des erfindungsgemäßen Verfahrens
eingeschränkt.
Es wird der Statusbericht dann lediglich von ausgewählten und/oder
relevanten Applikationen angefordert. Dies hat den Vorteil, dass
die Monitoring-Einheit nur zu diesem Zeitpunkt relevante Daten verarbeiten
muss.
-
Abhängig von
der nachfolgenden, erfindungsgemäßen Analyse
des Statusberichtes ergeben sich nun grundsätzlich zwei Prozess-Abläufe:
- 1. Falls der Statusbericht keinen Fehlerzustand erkennen
lässt,
werden keine weiteren Fehlerbehebungsmaßnahmen eingeleitet und das
Monitoring kann unmittelbar im Anschluss oder zu einem späteren Zeitpunkt
fortgesetzt werden.
- 2. Ergibt die Analyse des Statusberichtes, dass ein Fehlerzustand
existiert, so wird eine Suche in der Datenbank angestoßen. Insbesondere
wird gesucht, ob zumindest einem der erfassten Fehlerzustände ein
Fehlerbehebungs-Mechanismus zugeordnet ist. Falls ein solcher Fehlerbehebungs-Mechanismus
gefunden werden kann, werden applikations-spezifische Kommandos
zur Fehlerbehebung berechnet. Üblicherweise
handelt es sich hierbei um eine Kommandofolge, d.h. um mehrere Befehle.
Bei einfachen Fehlern ist es jedoch auch möglich, dass lediglich ein Kommando
ausreicht, um den Fehler zu beheben. Daraufhin wird der Fehlerbehebungs-Mechanismus
ausgeführt,
indem die berechneten Kommandos von der Monito ring-Einheit über die
Monitoring-Schnittstelle an die Applikation gesendet werden. In
diesem Fall beinhaltet das erfindungsgemäße Verfahren also eine automatische
Fehler-Recovery.
-
Als
besonders vorteilhaft hat es sich in der Praxis erwiesen, dass zusätzlich zu
der Ebene der Applikationen erfindungsgemäß eine hierarchisch übergeordnete
Ebene vorgesehen ist, in der die Monitoring-Einheit als applikations-übergreifende,
zentrale Instanz wirkt. Somit kommunizieren die Applikationen jeweils über die
Monitoring-Schnittstellen mit der Monitoring-Einheit über das
Netzwerk und die Monitoring-Einheit kann prozess-übergreifend und/oder
applikations-übergreifend
arbeiten. Dieses Vorgehen birgt den Vorteil, dass die Diagnosemöglichkeiten
und zugeordnete Fehlerbehebungs-Maßnahmen deutlich gesteigert
werden können.
Es ist möglich,
auch Fehler zu identifizieren, die nicht an die Applikation gebunden
sind, sondern die beispielsweise im zugrundeliegenden Netzwerk oder
in anderen Bauteilen liegen und somit andere Ursachen haben. Soll
beispielsweise eine RIS-Applikation Bilddaten an eine PACS-Applikation
zur Archivierung senden und erhält
die PACS-Applikation die Bilddaten nicht, so ist es erfindungsgemäß trotzdem
möglich,
den Fehler zu identifizieren, falls dieser beispielsweise in einem gestörten Datenübertragungskanal
liegt. Bei bisherigen Systemen war dies nicht möglich.
-
Grundsätzlich fordert
die Monitoring-Einheit den Statusbericht nach vorbestimmbaren Zeitintervallen,
insbesondere in regelmäßigen Abständen, an.
Dies hat den Vorteil, dass der Anwender keine weiteren Einstellungen
tätigen
muss und der Statusbericht in einem vollautomatisierten Verfahren
angefordert wird. Es ist jedoch auch möglich, hier weitere Steuerungsmöglichkeiten
vorzunehmen, indem der Statusbericht nach Ablauf von einstellbaren
Zeitintervallen angefordert wird und/oder nach Eintreten bestimmter,
semantischer Kontextbedingungen. Hier können beispielsweise Regeln
in einer Wis sensbasis abgelegt sein, die festlegen, in welchen Situationen ein
Statusbericht angefordert werden soll. Beispielsweise kann eingestellt
werden, dass bei hoher Netzauslastung alle Applikationen überwacht
werden sollen, die einen Austausch von großen Datenvolumina erfordern.
Durch diese erfindungsgemäße Steuerungsmöglichkeit
ist das Verfahren dynamisch an verschiedene Monitoring-Szenarien
anpassbar.
-
Vorteilhafterweise
ist es vorgesehen, dass der Fehlerbehebungs-Mechanismus erfindungsgemäß vollautomatisch
durchgeführt
wird. Dies ist möglich,
da in der Datenbank zu einer Vielzahl von Fehlerzuständen jeweils
zumindest ein Fehlerbehebungs-Mechanismus zugeordnet ist. Da es
sich vorzugsweise um ein selbstlernendes System handelt, indem die
Datenbank laufend durch die aktuellen Monitoring-Fälle erweitert
wird, sodass einer wachsenden Zahl von Fehlerzuständen Fehlerbehebungs-Strategien
zugeordnet werden können,
kann das erfindungsgemäße System
für eine
Vielzahl von Fällen
vollautomatisch ausgeführt
werden. In den anderen Fällen
und/oder auf Wunsch des Anwenders kann die Fehlerbehebung jedoch
auch halbautomatisch durchgeführt
werden.
-
Vorteilhafterweise
ist das erfindungsgemäße Verfahren
zweiphasig ausgebildet. In einer Vorphase sendet die jeweilige Applikation über die
Monitoring-Schnittstelle applikations-spezifische Prozessdaten an die Monitoring-Einheit.
Hier werden insbesondere die Kenngrößen des Statusberichtes und weitere
grundsätzlich
ausführbare,
applikations-spezifische Kommandos und/oder Kommandos zur Fehlerbehebung
hinterlegt. Auf Grund der Übermittlung der
Prozessdaten weiß die
Monitoring-Einheit
in der nachfolgenden Phase, der eigentlichen Monitoring-Phase, welche
Daten sie in dem Statusbericht von der Applikation erwarten kann.
Damit ist es vorteilhafterweise möglich, die Übersendung des Statusberichtes
seitens der Monitoring-Einheit auf Fehlerfreiheit zu überwachen.
Sendet die Applikation beispielsweise bei dem Monitoring-Vorgang
lediglich einen Teil des Statusberichtes, so weiß die Monitoring- Einheit, dass es
sich hier um einen Fehler handeln muss, da der Umfang des Statusberichtes
bereits in der Vorphase festgelegt worden ist.
-
Vorzugsweise
ist die Schnittstelle zwischen den Applikationen und der Monitoring-Einheit
standardisiert. Das heißt,
dass die Applikationen mit der Monitoring-Einheit ausschließlich über die
Monitoring-Schnittstelle kommunizieren. Diese Schnittstelle basiert
vorzugsweise auf einem offenen Standard, wie beispielsweise SOAP-XML,
HTTP-basiert oder TCP/IP. Dies ermöglicht es, dass weitere Applikationen
und/oder andere Prozessmodule mit der Monitoring-Einheit und/oder
mit den Applikationen kommunizieren können. Und insbesondere die
Daten des Monitoring-Prozesses für
weitere Zwecke nutzen können.
-
In
einer vorteilhaften Weiterbildung ist die Erfindung so ausgelegt,
dass die Datenbank system- und/oder applikations-übergreifende
Fehlerzustände umfasst.
Damit sind in der Datenbank nicht nur applikations-spezifische Fehler
gespeichert, sondern auch andere mögliche Fehler und Ursachen.
Damit kann der Umfang der Diagnose und der erfindungsgemäßen Fehlerbehebung
deutlich gesteigert werden, da beispielsweise auch Fehler in einem Übertragungsprozess
identifiziert werden können.
-
Die
Suche in der Datenbank erfolgt vorzugsweise automatisch. Zum einen
kann dadurch die Effizienz des Verfahrens gesteigert werden und
zum anderen können
mögliche
Fehlbedienungen verringert werden. Die Datenbank wird ständig und
fortlaufend gepflegt und mit neuen Zuordnungen angereichert. Durch
die Steigerung des Automatisierungs-Grades können vorteilhafterweise die
Personalkosten gesenkt und die Fehlerfreiheit des Überwachungssystems
gesteigert werden.
-
Mit
dem hier vorgeschlagenen Weg ist es möglich, wiederkehrende Probleme
eindeutig zu identifizieren und automatisch eine Problemlösung zu
veranlassen.
-
Durch
die einheitliche Schnittstelle weist das System eine hohe Adaptionsmöglichkeit
auf und es können
ohne Probleme weitere Applikationen zum Überwachungssystem hinzugefügt werden.
Die Erweiterbarkeit und Wiederverwendbarkeit können also deutlich gesteigert
werden.
-
Medizintechnische
Anlagen erfordern im klinischen Alltag in der Regel eine hohe Verfügbarkeit. Deshalb
ist die erfindungsgemäße Lösung vorzugsweise
als Hochverfügbarkeits-System
ausgebildet. Die Monitoring-Einheit ist vorzugsweise so ausgelegt,
dass sie mit Hochverfügbarkeits-Systemen (High
Availability Systems) kommunizieren und somit auf sehr schnell veränderte Systemkonfigurationen reagieren
kann.
-
In
einer vorteilhaften Weiterbildung ist die Erfindung so ausgelegt,
dass sie das bisherige Vorgehen nach dem Stand der Technik umfasst,
und ein aktives Benachrichtigen anderer Service-Systeme und/oder
des Service-Personals über
unterschiedliche Medien (z.B. SMS, Telefon und/oder E-mail oder dgl.)
umfasst.
-
Darüber hinaus
ist die Monitoring-Einheit so an die Applikationen angebunden, dass
ein Ausfall der Monitoring-Einheit die Funktionsfähigkeit
der zu überwachenden
Applikationen, insbesondere der Radiologie-Systeme nicht beeinflusst.
Die einzelnen Prozess-Einheiten können dann, wie bekannt, eine separate Überwachung
und/oder Fehleranalyse durchführen.
Ein wesentlicher Vorteil der erfindungsgemäßen Lösung ist darin zu sehen, dass
die Verfügbarkeit
des Gesamtsystems, insbesondere des Radiologie-Systems, deutlich
gesteigert werden kann, indem das Einsammeln bzw. Erfassen der relevanten Statusinformationen
automatisiert erfolgt und vorzugsweise auf Vollständigkeit überprüft wird.
-
Grundsätzlich ist
das erfindungsgemäße Verfahren
so ausgelegt, dass bei einem erfassten Fehlerzustand des Statusberichtes
eine Datenbankabfrage erfolgt. In dieser Datenbankabfrage wird ermittelt,
ob zu dem erfassten Fehlerzustand ein zugeordneter Fehlerbehebungs-Mechanismus
existiert. Falls ein solcher Fehlerbehebungs-Mechanismus aufgefunden
werden kann, wird weiterhin überprüft, ob in
der Datenbank bereits applikations-spezifische Kommandos zur Fehlerbehebung
ermittelt werden können.
Falls dies der Fall ist, werden diese Kommandos über die Monitoring-Einheit
an die jeweilige Applikation gesendet.
-
Falls
dies jedoch nicht der Fall ist, und die Datenbank also nur einen
allgemeinen Fehlerbehebungs-Mechanismus enthält, so kennzeichnet sich die
Erfindung durch einen zusätzlichen
Verfahrensschritt, nämlich
dahingehend, dass der erfasste Fehlerbehebungs-Mechanismus automatisch
in ein Kommando (oder in eine Kommandofolge) zur Fehlerbehebung
auf der Applikation umgesetzt wird. Bei dieser Transformation des
allgemeinen Fehlerbehebungs-Mechanismus in konkrete, applikations-spezifische Kommandos
ist es erfindungsgemäß vorgesehen,
dass gegebenenfalls weitere zusätzlich
benötigte
Prozessdaten von der Applikation ermittelt werden. Benötigt der
Verfahrensschritt der Umsetzung keine weiteren Prozessdaten, so
wird er unmittelbar ausgeführt.
-
Bei
der eben beschriebenen Ausführungsform
der Erfindung kennzeichnet sich die Vorrichtung durch ein zusätzliches
Bauteil, insbesondere durch ein Umsetzungsmodul, das zum Umsetzen
des erfassten Fehlerbehebungs-Mechanismus in applikations-spezifische
Kommandos zur Fehlerbehebung bestimmt ist.
-
Die
vorstehend beschriebenen, erfindungsgemäßen Ausführungsformen des Verfahren
können auch
als Computerprogrammprodukt ausgebildet sein, mit einem von einem
Computer lesbaren Medium und mit einem Computerprogramm und zugehörigen Programmcode-Mitteln,
wobei der Computer nach Laden des Computerprogramms zur Durchführung des
oben beschriebenen, erfindungsgemäßen Verfahrens veranlaßt wird.
-
Eine
alternative Aufgabenlösung
sieht ein Speichermedium vor, das zur Speicherung des vorstehend
beschriebenen, computerimplementierten Verfahrens bestimmt ist und
von einem Computer lesbar ist.
-
Zusätzliche,
vorteilhafte Ausführungsformen ergeben
sich aus den Unteransprüchen.
-
In
der folgenden detaillierten Figurenbeschreibung werden nicht einschränkend zu
verstehende Ausführungsbeispiele
mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnung
besprochen. In dieser zeigen:
-
1 eine übersichtsartige
Darstellung von wesentlichen Bauteilen gemäß einer bevorzugten Ausführungsform
der vorliegenden Erfindung;
-
2 drei
verschiedene Applikationssysteme, die mit einer Monitoring-Einheit
interagieren;
-
3 eine
beispielhafte Darstellung eines Informationsflusses bei einem von
dem erfindungsgemäßen System
erfassten Fehler auf einer der Applikationen,
-
4 ein
Ablaufdiagramm gemäß einer
bevorzugten Ausführungsform
der Erfindung und
-
5 eine übersichtsartige
Darstellung von wesentlichen Modulen eines bekannten Monitoring-Systems
aus dem Stand der Technik.
-
In 1 ist übersichtsartig
der grundlegende Aufbau der erfindungsgemäßen Anordnung abgebildet. Eine
Vielzahl von im Allgemeinen mit A bezeichneten Applikationen (in
der Zeichnung A1, A2..... Ai) kommunizieren über ein Netzwerk 18.
Vorzugsweise ist die Gattung und die Art des Netzwerkes 18 für die erfindungsgemäße Lösung unbeachtlich,
das heißt, dass
diese Lösung
grundsätzlich
auf alle Netzwerkarten angewendet werden kann. Vorzugsweise handelt
es sich bei den Applikationen A um hard- und/oder software-basierte
Systeme auf dem Gebiet der Radiologie. Jede Applikation A weist
eine Monitoring-Schnittstelle 12 auf (in der Zeichnung
Monitoring-Schnittstellen 12-1, 12-2 ....
12-i). Wesentlich ist, dass es sich hierbei um eine einheitliche
Schnittstelle handelt, sodass also jedes zu überwachende radiologische System über dieselbe
Monitoring-Schnittstelle 12 ansprechbar ist und/oder kommuniziert.
Zentrales Element der erfindungsgemäßen Vorrichtung ist die Monitoring-Einheit 10,
die zum Monitoring und/oder zur Fehlerbehebung in Bezug auf die
Applikationen A ausbildet ist. Die Monitoring-Einheit 10 umfasst
ein Erfassungsmodul 14 und ein Fehlerbehebungs-Modul 22.
Die Monitoring-Einheit 10 steht im Datenaustausch mit einer
Datenbank 16.
-
Das
Erfassungsmodul 14 ist dazu bestimmt, relevante Prozessdaten
von den jeweils zu überwachenden
Applikationen A zu erfragen und an die Monitoring-Einheit 10 zu
senden. Bei den Prozessdaten handelt es sich in der bevorzugten
Ausführungsform um
applikations-spezifische Kenngrößen, für einen sogenannten
Statusbericht. Dieser Statusbericht soll die Grundlage für das Monitoring
und/oder für
die Fehlerbehebung sein. Des Weiteren umfassen die Prozessdaten
eine Liste von Kommandos, die auf der jeweiligen Applikation A ausgeführt und
grundsätzlich
zur Fehlerbehebung eingesetzt werden können. Das Erfassungsmodul 14 dient
also dazu, den Umfang des Statusberichtes in Bezug auf die jeweilige Applikation
A zu de finieren. Dies erfolgt vorzugsweise in einer Vorphase, das
heißt
vor dem eigentlichen Monitoring.
-
In
einer Hauptphase des Verfahrens, das heißt, während des eigentlichen Monitorings,
erfragt die Monitoring-Einheit 10 wesentliche Parameter
der zu überwachenden
Applikationen A, insbesondere den Inhalt des Statusberichtes.
-
In
einer vorteilhaften Weiterbildung erfragt nicht die Monitoring-Einheit 10 den
Statusbericht, sondern das der Monitoring-Einheit 10 zugeordnete Erfassungsmodul 14.
Es ist jedoch auch möglich, dass
der Statusbericht von einem weiteren Bauteil erfragt und erfasst
wird.
-
In
einem nachfolgenden Verfahrensschritt wird der Statusbericht der
jeweiligen Applikation A analysiert. Falls die Analyse auf einen
Fehlerzustand schließen
lässt,
erfolgt ein Zugriff auf die Datenbank 16. Anhand der vorliegenden
Daten (Art und Kenngrößen der
Applikation A, Statusbericht, Zeitpunkt der Abfrage, Netzwerkbelastung
etc.) wird automatisch eine Anfrage für die Datenbank 16 generiert.
Es erfolgt eine Suche nach Einträgen,
die zu dem jeweiligen Fehlerzustand zugeordnete Fehlerbehebungs-Mechanismen
gespeichert haben. Falls zumindest ein solcher Fehlerbehebungs-Mechanismus aufgefunden
werden kann, wird dieser automatisch anhand der erfassten applikations-spezifischen Kenngrößen in zumindest
ein Kommando zur Fehlerbehebung umgesetzt. Dieses applikations-spezifische Kommando
zur Fehlerbehebung wird von dem Fehlerbehebungs-Modul 22 automatisch über die Schnittstelle 12 an
die Applikation A gesendet.
-
Hierbei
kann es sich um ein singuläres
Kommando oder um eine Befehlsfolge, die aus mehreren Kommandos besteht,
handeln. Dieses Kommando ist also speziell auf den jeweiligen Fehlerzustand
der Applikation A und auf mögliche
Fehlerbehebungs-Kommandos
dieser Applikation A zugeschnitten. Liegt beispielsweise auf einer
Applikation A1 ein Fehler X vor, so wird das Kommando k ermittelt
und an die Applikation A1 gesendet. Liegt derselbe Fehler auf der
Applikation A2 vor, so wird es in der Regel nicht dasselbe Kommando
k sein, das den Fehler auf der Applikation A2 zu lösen vermag,
sondern es wird sich um ein Kommando k' handeln, um denselben Fehlerzustand
X auf der Applikation A2 zu lösen.
-
In
der bevorzugten Ausführungsform
sendet das Fehlerbehebungs-Modul 22 das Kommando an die
Applikation A. In alternativen Ausführungsformen ist es jedoch
möglich,
dass ein anderes Bauteil oder die Monitoring-Einheit 10 direkt
dieses Kommando über
die Schnittstelle 12 an die Applikation A sendet. In weiteren
Ausführungsformen
ist es vorgesehen, nicht nur ein Fehlerbehebungs-Modul 22 und
ein Erfassungsmodul 14 vorzusehen, sondern mehrere Module,
um die Rechenlast besser verteilen zu können. Falls der Statusbericht
jedoch keinen Fehlerzustand erkennen lässt, so erfolgt auch kein Zugriff
auf die Datenbank 16 und das Monitoring-Verfahren wird in
der bevorzugten Ausführungsform
folgenlos weitergeführt.
Es ist jedoch auch möglich,
bei Erfassen eines fehlerfreien Monitorings, einen entsprechenden
Bericht und/oder ein entsprechendes Flag zu setzen, das das fehlerfreie
Funktionieren der jeweiligen Applikation A indiziert.
-
In 2 ist
nochmals der grundlegende Aufbau der erfindungsgemäßen Vorrichtung
dargestellt, insbesondere, dass die Applikationen A jeweils über eine
einheitliche Monitoring-Schnittstelle 12 mit
der Monitoring-Einheit 10 kommunizieren. Die Monitoring-Einheit 10 dient
also zum einen zum automatischen Überwachen der Applikationen
A und zum anderen zur automatischen Fehlerbehebung auf den Applikationen
A, falls ein Fehlerzustand erfasst worden ist. Darüber hinaus
ist es möglich,
dass die Monitoring-Einheit 10 eine Benachrichtigungs-Signal an weitere
Systeme und/oder an einen Service-Techniker sendet (dies ist in
der 2 mit dem Begriff „Notify" gekennzeichnet).
-
Die
Monitoring-Einheit 10 sendet insbesondere dann eine solche
Benachrichtigungs-Signal, falls bei einem erfassten Fehlerzustand
kein entsprechender Eintrag in der Datenbank 16 gefunden
werden kann, der auf einen Fehlerbehebungs-Mechanismus hinweist. In Fällen, in
denen es sich um einen noch nicht aufgezeichneten, neuartigen Fehler
handelt, kann auch der Service-Techniker benachrichtigt werden.
-
Im
Zusammenhang mit 3 wird anhand eines Beispiels
demonstriert, wie das erfindungsgemäße Verfahren system-übergreifend und automatisch
ein Monitoring und eine Fehlerbehebung auf einer Applikation A durchführt. Die
fünf oberen
Kästchen
der 3 bezeichnen die miteinander agierenden Module:
Die Monitoring-Einheit 10, eine erste Applikation A, insbesondere
ein PACS-System (Picture-Archiving-Communication-System), das eine spezifische
PACS-Schnittstelle 12 aufweist,
eine weitere Modalität
A, die ebenfalls eine spezifische Schnittstelle 12 aufweist.
Die Monitoring-Einheit 10 führt im Rahmen ihres Monitoring
auf dem PACS-System A eine Anfrage aus und erhält als Ergebnis einen Statusbericht,
der darauf hinweist, dass es sieben fehlerhafte Bildübertragungen
gegeben hat. Anschließend
führt die
Monitoring-Einheit 10 eine Anfrage an die weiteren Modalitäten A durch,
die die Bilder geschickt haben. Die Monitoring-Einheit 10 erhält den Statusbericht
von der Modalität
A, dass das Senden der Bilder erfolgreich abgeschlossen worden ist.
Mit diesen Prozess-Informationen, die einmal die PACS-Applikation A und
zum anderen die weiteren Modalität
A betreffen, wird eine Suche in der semantischen Datenbank ausgeführt. Daraufhin
wird ein Eintrag gefunden, der darauf hinweist, dass es sich bei
einem solchen Fehlerzustand grundsätzlich um eine fehlende Übereinstimmung
bzw. um einen Missmatch zwischen den jeweiligen Übertragungsdaten handeln könnte, insbesondere
um einen Missmatch zwischen sogenannten AET's (Application Entity, basierend auf
dem DICOM-Standard; dabei handelt es sich um Sende- und Empfangs-Daten
in einem spezifischen Format, insbesondere um die Adressen der jeweils kommunizierenden
Applikationen A). Daraufhin wird eine Kommandofolge generiert, die
eine Anfrage an das PACS-System umfasst. Anschließend erfolgt
die Ausführung
dieser Anfrage, nämlich
der Anfrage der Monitoring-Einheit 10 an das PACS-System A, welche
Sendeadresse es erwartet hat. Als Resultat dieser Anfrage erhält die Monitoring-Einheit 10 eine
erwartete Sende-Adresse. Diese erwartete Sende-Adresse wird mit
der realen Sende-Adresse verglichen, die von der weiteren Modalität A geschickt
worden ist. Nach Durchführung
dieser Verarbeitungsschritte liefert die Monitoring-Einheit 10 das
Zwischenergebnis, dass die Modalität A beim Senden der Bilder
falsche Adressdaten verwendet hat. Die Monitoring-Einheit 10 führt eine
Korrektur dieser Daten auf der Modalität A durch und startet diese
Modalität
A neu.
-
Damit
wurde ein im Rahmen eines Monitorings erfasster Fehlerzustand automatisch
und erfolgreich korrigiert und behoben. Im Anschluss an die Bereinigung
des Fehlers kann ein anderes System und/oder ein Service-Techniker
benachrichtigt werden. Dieses in 3 dargestellte
Beispiel zeigt deutlich, dass bestimmte Fehler nur system-übergreifend identifiziert
und/oder diagnostiziert werden können und
dass eine applikations-spezifische Fehleranalyse nicht zielführend sein
kann.
-
Insbesondere
in Fällen,
in denen der Fehler in der Regel nicht bei der einzelnen Applikation
A liegt, sondern in denen mehrere Applikationen A einen Fehler verursachen,
wird das erfindungsgemäße Verfahren
eingesetzt. Dies ist vorwiegend bei solchen Applikationen A der
Fall, die einen Datenaustausch bzw. eine Datenübertragung erfordern.
-
In 4 ist
ein Flow-Chart dargestellt, das den Ablauf gemäß der bevorzugten Ausführungsform der
Erfindung darstellt. Beginnend bei einem fehlerfreien Zustand des
Monitoring-Systems,
führt die
Monitoring-Einheit 10 Statusanfragen durch. Die Statusanfragen
erfolgen jeweils an bzw. über
die Monitoring-Schnittstellen 12 der jeweiligen Applikationen
A (hier eine PACS-Applikation und eine RIS-Applikation). Die gesammelten
Statusberichte werden in der Monitoring-Einheit 10 analysiert.
Insbesondere wird untersucht, ob der Statusbericht Probleme bzw.
Fehlerzustände
umfasst. Falls „Nein", wird zum Startzustand
zurückgekehrt.
-
Anderenfalls
(falls also Probleme aufgetreten sind) wird untersucht, ob die erfasste
Symptome auf ein bekanntes Problem hinweisen. Diese Untersuchung
wird mit Hilfe der Datenbank 16 ausgeführt.
-
Falls
das Problem bisher nicht bekannt ist und kein Fehlerbehebungs-Mechanismus
auf die jeweiligen Symptome gefunden werden konnte, werden andere
Systeme und/oder der Service-Techniker benachrichtigt.
-
Anderenfalls
(falls es sich also um einen bekannten Fehlerzustand handelt) wird überprüft, ob der
erfasste Fehlerbehebungs-Mechanismus ohne weiteres (also ohne weitere
Prozessdaten) in applikations-spezifische Kommandos zur Fehlerbehebung
umgesetzt werden kann. Falls die Informationen im Statusbericht
und der Eintrag in der Datenbank 16 ausreichend ist, um
ein solches Kommando oder eine Kommandofolge abzuleiten, so wird
diese Kommandofolge auf der jeweiligen Applikation A über die
jeweilige Monitoring-Schnittstelle 12 ausgeführt.
-
Anderenfalls
(falls also die Informationen des Statusberichtes nicht ausreichend
sind, um den erfassten Fehlerbehebungs-Mechanismus in ein Kommando zur Fehlerbehebung
umzusetzen), werden weitere benötigte
Informationen ermittelt. Diese weiteren benötigten Prozessdaten werden
dann über
die Monitoring-Schnittstelle 12 erfragt und an die Monitoring-Einheit 10 weitergeleitet.
Daraufhin kann die Monitoring-Einheit 10 aus den vorliegenden
Daten (Statusbericht, erfasster Fehlerbehebungs-Mechanismus, weitere
Prozessdaten) zumindest ein Kommando als Gegenmaßnahme ableiten. Dieses Kommando
wird ausgeführt.
Nach erfolgtem Ausführen
der Kommandos auf der Applikation A wird ein entsprechendes Benachrichtigungs-Signal an vordefinierbare
Systeme und/oder an den Service-Techniker
gesendet. Vorzugsweise ist die Erfindung so ausgelegt, dass der
Anwender im Vorfeld einstellen kann, an welche Systeme die Monitoring-Einheit 10 die
jeweiligen Benachrichtigungs-Signale senden soll. In der bevorzugten
Ausführungsform
ist es beispielsweise voreingestellt, dass die fehlerverursachende
Applikation A über
eine erfolgreiche Fehlerbehebung von der Monitoring-Einheit 10 informiert
wird.
-
Ein
besonderer Vorteil des erfindungsgemäßen Monitoring-Verfahrens ist darin
zu sehen, dass sehr viele Fehlerzustände automatisch behoben werden
können.
Viele Fehler werden durch fehlerhafte Adressierungen verursacht,
z.B. wenn zu einem zu übertragenden
Datensatz eine falsche Zieladresse oder eine falsche Sendeadresse
zugeordnet ist. Durch die system-übergreifende
erfindungsgemäße Lösung können Fehler,
die durch solche Fehlzuweisungen entstehen, im Rahmen des Monitoring
automatisch behoben werden.
-
Die
selbständige
Korrektur bestimmter Fehlerzustände
durch die Monitoring-Einheit 10 wird ermöglicht,
indem applikations-spezifische Kommandos zur Fehlerbehebung berechnet
und auf der Applikation A ausgeführt
werden können.
Die hierfür
notwendigen Prozessdaten werden von der Monitoring-Einheit 10 automatisch
eingesammelt bzw. erfasst.
-
In
der bevorzugten Ausführungsform
der Erfindung ist es vorgesehen, dass alle Monitoring-Prozess-Durchläufe in einem
zentralen Log-File 20 archiviert werden. Dieses Log-File 20 kann
dazu verwendet werden, von der Monitoring-Einheit 10 korrigierte
Prozess-Durchläufe
nachzuvollziehen und kann darüber
hinaus verwendet werden, um die Datenbank 16 mit weiteren
Monitoring-Daten zu füllen.
-
In 5 ist
die grundsätzliche
Struktur bekannter Monitoring-Systeme nach dem Stand der Technik
erläutert.
Hier kön nen
die verschiedenen Applikationen bzw. Modalitäten A und die weiteren Elemente
und Module des Netzwerkes 18 nur separat überwacht
werden. Eine system-übergreifende Überwachung
war bisher nicht möglich.
Darüber
hinaus war es auch nicht möglich,
eine automatische Fehlerbehebung bei radiologischen Systemen durchzuführen, die
auf dem Watch-Dog-Prinzip beruhen. Es war stets erforderlich, einen
Serivce Techniker einzuschalten.
-
Das
hauptsächliche
Anwendungsgebiet der vorliegenden Erfindung liegt auf dem Gebiet
der radiologischen Systeme. Die erfindungsgemäße Vorrichtung, das System
und das Verfahren können
jedoch auch auf alle weiteren Gebiete der Technik angewandt werden,
insbesondere auf Applikationen A, die einen Austausch von Daten
erfordern.
-
Durch
die erfindungsgemäße Kombination von
Monitoring einerseits und automatischer Fehlerbehebung andererseits
ist es möglich,
Rechenzeit einzusparen und eine verbesserte Verfügbarkeit und Ausfallsicherheit
der Applikationen A gewährleisten zu
können.