PatentDe  


Dokumentenidentifikation DE102004050905A1 11.05.2006
Titel Monitoring-Einheit zur Überwachung und zur automatisierten Fehlerbehebung von medizinischen Applikationen
Anmelder Siemens AG, 80333 München, DE
Erfinder Bauer, Sabine, 91056 Erlangen, DE;
Rückschloss, Karol, 91052 Erlangen, DE
DE-Anmeldedatum 19.10.2004
DE-Aktenzeichen 102004050905
Offenlegungstag 11.05.2006
Veröffentlichungstag im Patentblatt 11.05.2006
IPC-Hauptklasse G05B 23/02(2006.01)A, F, I, 20051017, B, H, DE
IPC-Nebenklasse G05B 9/02(2006.01)A, L, I, 20051017, B, H, DE   A61B 19/00(2006.01)A, L, I, 20051017, B, H, DE   
Zusammenfassung Die Erfindung betrifft ein Verfahren, eine Vorrichtung und ein System zum Monitoring von einer Vielzahl von medizintechnischen Applikationen (A), die über ein Netzwerk (18) mit einer zentralen Monitoring-Einheit (10) kommunizieren. Die Monitoring-Einheit (10) fordert in regelmäßigen Zeitabständen einen Statusbericht von den Applikationen (A) an. Falls der Statusbericht einen Fehlerzustand umfasst, wird eine Suche in einer Datenbank (16) angestoßen, um einen Fehlerbehebungs-Mechanismus zu finden. Dieser Fehlerbehebungs-Mechanismus wird in applikations-spezifische Kommandos zur Fehlerbehebung umgesetzt. Daraufhin wird der Fehlerbehebungs-Mechanismus durch Übermitteln der Kommandos an die Applikation (A) ausgeführt.

Beschreibung[de]

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 werden. 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 Monitoring-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 Wissensbasis 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 definieren. 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önnen 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.


Anspruch[de]
  1. Verfahren zum Monitoring von einer Vielzahl von Applikationen (A), insbesondere von medizintechnischen Applikationen, in einem Netzwerk (18), mit einer Monitoring-Einheit (10),

    dadurch gekennzeichnet, dass

    die Applikationen (A) alle über eine einheitliche Monitoring-Schnittstelle (12) kommunizieren und dass die Monitoring-Einheit (10) von der jeweiligen Applikation (A) einen Statusbericht anfordert und falls der Statusbericht einen Fehlerzustand umfasst:

    – Suche in einer Datenbank (16) nach einem dem erfassten Fehlerzustand zugeordneten Fehlerbehebungs-Mechanismus mit zugeordneten applikationsspezifischen Kommandos zur Fehlerbehebung und

    – Ausführen des Fehlerbehebungs-Mechanismus durch Übermitteln der Kommandos von der Monitoring-Einheit (10) über die Monitoring-Schnittstelle (12) an die Applikation (A).
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Monitoring-Einheit (10) über das Netzwerk (18) mit den Applikationen (A) kommuniziert und eine hierarchisch übergeordnete, applikationsübergreifende Instanz ist.
  3. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Monitoring-Einheit (10) den Statusbericht nach vorbestimmbaren Zeitintervallen und/oder nach Erfüllen von vordefinierbaren Voraussetzungen anfordert.
  4. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Ausführen des Fehlerbehebungs-Mechanismus halb-automatisch oder vollautomatisch erfolgt.
  5. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Applikation (A) der Monitoring-Einheit (10) vor Beginn des Monitoring applikations-spezifische Prozessdaten mitteilt, insbesondere relevante Kenngrößen des Statusberichtes und die jeweils möglichen applikationsspezifischen Kommandos zur Fehlerbehebung.
  6. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Applikationen (A) mit der Monitoring-Einheit (10) ausschließlich über die Monitoring-Schnittstelle (12) kommunizieren.
  7. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Datenbank (16) system- und/oder applikationsübergreifende Fehlerzustände umfasst.
  8. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Suche in der Datenbank (16) automatisch erfolgt.
  9. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren zusätzlich einen weiteren Verfahrensschritt umfasst:

    – automatisches Umsetzen des erfassten Fehlerbehebungs-Mechanismus in applikationsspezifischen Kommandos zur Fehlerbehebung.
  10. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Applikation (A), die Monitoring-Einheit (10) und/oder das Verfahren Hochverfügbarkeits-Kriterien erfüllt.
  11. Vorrichtung zum Monitoring von einer Vielzahl von Applikationen (A), insbesondere von medizintechnischen Applikationen, in einem Netzwerk (18), mit einer Monitoring-Einheit (10),

    dadurch gekennzeichnet, dass

    die Applikationen (A) alle über eine einheitliche Monitoring-Schnittstelle (12) kommunizieren und dass

    die Vorrichtung weiterhin umfasst:

    – zumindest ein Erfassungsmodul (14), das dazu bestimmt ist, von der jeweiligen Applikation (A) Kenngrößen für einen Statusbericht und grundsätzlich mögliche applikationsspezifischen Kommandos zur Fehlerbehebung zu erfassen, wobei die Monitoring-Einheit (10) dazu bestimmt ist, den Statusbericht zumindest einer Applikation (A) zu erfassen

    – eine Datenbank (16), in der jeweils einem Fehlerzustand einer Applikation (A) ein Fehlerbehebungs-Mechanismus und applikationsspezifische Kommandos zur Fehlerbehebung zugeordnet sind, und

    – zumindest ein Fehlerbehebungsmodul (22), das dazu ausgelegt ist, einen von der Monitoring-Einheit (10) erfassten Fehlerzustand zu beheben, indem unter Zugriff auf die Datenbank (16) zumindest ein applikationsspezifisches Kommando zur Fehlerbehebung ermittelt und über die Monitoring-Schnittstelle (12) an die Applikation (A) gesendet wird.
  12. Vorrichtung nach Anspruch 11, dadurch gekennzeichnet, dass die Monitoring-Einheit (10) über das Netzwerk (18) mit den Applikationen (A) kommuniziert und eine hierarchisch übergeordnete, applikationsübergreifende Instanz ist.
  13. Vorrichtung nach zumindest einem der vorhergehenden Ansprüche 11 oder 12, dadurch gekennzeichnet, dass die Monitoring-Einheit (10) den Statusbericht nach vorbestimmbaren Zeitintervallen und/oder nach Erfüllen von vordefinierbaren Voraussetzungen anfordert.
  14. Vorrichtung nach zumindest einem der vorhergehenden Ansprüche 11 bis 13, dadurch gekennzeichnet, dass das Fehlerbehebungs-Modul (22) halb-automatisch oder vollautomatisch arbeitet.
  15. Vorrichtung nach zumindest einem der vorhergehenden Ansprüche 11 bis 14, dadurch gekennzeichnet, dass die Applikation (A) der Monitoring-Einheit (10) grundsätzlich mögliche applikationsspezifische Kommandos zur Fehlerbehebung mitteilt, bevor die Monitoring-Einheit (10) ihre Aktivität aufnimmt.
  16. Vorrichtung nach zumindest einem der vorhergehenden Ansprüche 11 bis 15, dadurch gekennzeichnet, dass die Applikationen (A) mit der Monitoring-Einheit (10) ausschließlich über die Monitoring-Schnittstelle (12) kommunizieren.
  17. Vorrichtung nach zumindest einem der vorhergehenden Ansprüche 11 bis 16, dadurch gekennzeichnet, dass die Datenbank (16) system- und/oder applikationsübergreifende Fehlerzustände umfasst.
  18. Vorrichtung nach zumindest einem der vorhergehenden Ansprüche 11 bis 17, dadurch gekennzeichnet, dass das Erfassungsmodul (14) automatisch arbeitet.
  19. Vorrichtung nach zumindest einem der vorhergehenden Ansprüche 11 bis 18, dadurch gekennzeichnet, dass die Vorrichtung ein weiteres Modul umfasst:

    – zumindest ein Umsetzungs-Modul, das zum automatischen Umsetzen des erfassten Fehlerbehebungs-Mechanismus in applikationsspezifischen Kommandos zur Fehlerbehebung bestimmt ist.
  20. Vorrichtung nach zumindest einem der vorhergehenden Ansprüche 11 bis 19, dadurch gekennzeichnet, dass die Applikation (A), die Monitoring-Einheit (10) und/oder die Vorrichtung ein Hochverfügbarkeits-System sind.
  21. System zum Monitoring von einer Vielzahl von Applikationen (A), insbesondere von medizintechnischen Applikationen, in einem Netzwerk (18), mit einer Monitoring-Einheit (10),

    dadurch gekennzeichnet, dass

    die Applikationen (A) alle über eine einheitliche Monitoring-Schnittstelle (12) kommunizieren und dass

    die Vorrichtung weiterhin umfasst:

    – zumindest ein Erfassungsmodul (14), das dazu bestimmt ist, von der jeweiligen Applikation (A) Kenngrößen für einen Statusbericht und grundsätzlich mögliche applikationsspezifischen Kommandos zur Fehlerbehebung zu erfassen, wobei die Monitoring-Einheit (10) dazu bestimmt ist, den Statusbericht zumindest einer Applikation (A) zu erfassen

    – eine Datenbank (16), in der jeweils einem Fehlerzustand einer Applikation (A) ein Fehlerbehebungs-Mechanismus und applikationsspezifische Kommandos zur Fehlerbehebung zugeordnet sind, und

    – zumindest ein Fehlerbehebungsmodul (22), das dazu ausgelegt ist, einen von der Monitoring-Einheit (10) erfassten Fehlerzustand zu beheben, indem unter Zugriff auf die Datenbank (16) zumindest ein applikationsspezifisches Kommando zur Fehlerbehebung ermittelt und über die Monitoring-Schnittstelle (12) an die Applikation (A) gesendet wird.
Es folgen 4 Blatt Zeichnungen






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com