DE102008004658B4

DE102008004658B4 - Verfahren zur zentralen Steuerung von Prozessen in erweiterbaren medizinischen Plattformen

Info

Publication number: DE102008004658B4
Application number: DE102008004658A
Authority: DE
Inventors: Detlef Becker; Karlheinz Dorn; Sten Dr. Löcher; Artur Pusztai
Original assignee: Siemens AG
Current assignee: Siemens Healthineers Ag De
Priority date: 2008-01-16
Filing date: 2008-01-16
Publication date: 2010-03-25
Anticipated expiration: 2028-01-17
Also published as: DE102008004658A1; US20090182879A1; US8117310B2

Abstract

Verfahren zum Steuern von Zuweisungen von Ressourcen (20) an Prozesse (4) in erweiterbaren medizinischen Plattformen mit einer zentralen Instanz (5) und einer Meta-Schnittstelle (30) zur Verwaltung von Ressourcen (20) eines Typs, wobei das Verfahren folgende Schritte umfasst:
– Empfangen eines Auftrags (1) für einen Prozess (4) durch eine zentrale Instanz (5), wobei der Auftrag (1) gekennzeichnet ist durch einen Auftragstyp (1a);
– Zuordnen (7) des Auftrags (1) zu einem Warteschlangenzuweiser (10) in Abhängigkeit des Auftragstyps,
– Ermitteln einer Vielzahl von Prozessressourcen (25), die zur Ausführung des Auftrags (1) benötigt werden aus innerhalb der Plattform vorhandenen Ressourcen (20) und Ermitteln eines Warteschlangennamens (17) durch den Warteschlangenzuweiser (10);
– Anfragen der Prozessressourcen (25) durch die zentrale Instanz (5) bei der Meta-Schnittstelle (30);
– Zuweisen der Prozessressourcen (25) zu dem Auftrag (1), soweit die Prozessressourcen (25) zur Ausführung des Prozesses (4) zur Verfügung stehen,
– Ausführen des...

Description

Gegenstand der Erfindung
Die Erfindung bezieht sich auf ein Verfahren zur zentralen Kontrolle von Ressourcen in erweiterbaren medizinischen Plattformen.
Medizinische erweiterbare Plattformen umfassen in der Regel komplexe Hardware zur Untersuchung von Patienten, zentrale und verteilte Festplatten zur Speicherung von großen Datenmengen. Erweiterbare medizinische Plattformen können sowohl der Verwaltung von medizinischen Patientendaten dienen, wie auch der Organisation von Klinikabläufen, der Therapieplanung, der Klinikverwaltung und der gleichen, wie sie dem Fachmann bekannt sind. Medizinische erweiterbare Plattformen umfassen ferner eine Vielzahl von Knoten bzw. Clients, die auf gespeicherte Daten zugreifen können, Prozesse anstoßen können, und evtl. Zugriff auf komplexe Hardware einer medizinischen Modalität haben.
Moderne medizinische Modalitäten, wie z. B. die Magnetresonanz-Tomographie (MR-Tomographie) ist gekennzeichnet durch die Verwendung komplexer Hardware-Geräte, z. B. eines MR-Scanners sowie zahlreiche aufwendige Prozesse, die z. B. von der Erfassung der Rohdaten über die Rekonstruktion von Bildern des Inneren des Körpers eines Patienten bis hin zu Methoden zur Diagnose-Erstellung bzw. Diagnose-Unterstützung reichen.
In einer modernen medizinischen Modalität verfügt der Scanner über ein Echtzeit-Betriebssystem. Ein solches Echtzeit-Betriebssystem stellt sicher, dass zu jedem Zeitpunkt der Zustand des Scanners determiniert ist. Das bedeutet, das Verhalten der Prozesse in einem Echtzeitbetriebssystem, so ge nannter Echtzeitprozesse, ist zu jedem Zeitpunkt bekannt. Neben Echtzeitprozessen, wie z. B. die Erfassung von Rohdaten bei der Untersuchung eines Patienten, gibt es eine Vielzahl von Prozessen im Zusammenhang mit einer medizinischen Modalität, die nicht durch ein Echtzeitbetriebssystem gesteuert werden und gewissermaßen im Hintergrund laufen. Das bedeutet, sie werden im Idealfall vom Benutzer nicht bemerkt. Zu diesen Prozessen gehört die Rekonstruktion von Bildern aus einem 3D-Datensatz oder beispielsweise die Berechnung von Mikrokalzifikationen der weiblichen Brust zur Diagnose-Unterstützung bzw. der Therapieplanung.
Im Gegensatz zu den Echtzeitprozessen, die etwa auf einem Scanner ablaufen, sind Prozesse bisher dadurch gekennzeichnet, dass das Verhalten der Prozesse nicht deterministisch ist. Das bedeutet in einer erweiterbaren medizinischen Plattform laufen eine Vielzahl von Prozessen gleichzeitig ab. Es kann deshalb vorkommen, dass z. B. das Schreiben von Rohdaten auf die Festplatte eines Scanners erheblich verlangsamt wird oder schlimmstenfalls gar nicht mehr möglich ist, wenn zu viele Prozesse parallel laufen, die gleichzeitig auf die Festplatte des Scanners zugreifen. Das bedeutet eine hohe Zahl von I/O-Operationen auf die Festplatte eines Scanners kann die Performance des Scanners, z. B. beim Scannen eines Patienten einschränken.
Durch eine verlangsamte Response des Scanners wird wertvolle Zeit verloren, z. B. bei der Untersuchung eines Schlaganfall-Patienten. Durch das geringe Zeitfenster, das zur erfolgreichen Therapie eines solchen Patienten bleibt, ist es erforderlich, für Prozesse innerhalb der medizinischen Plattform ein deterministisches Verhalten zu haben, um auch im Falle eines medizinischen Notfalls eine gesicherte Qualität der innerhalb der erweiterbaren medizinischen Plattform verfügbaren Dienste zu gewährleisten.
Aus dem Stand der Technik ist es bekannt, ein Ressourcenmanagement zu betreiben, das nach bestimmten Qualitätsstandards für verteilte Multimedia Anwendungen ausgerichtet ist. So zeigt die Druckschrift „QoS-aware resource management for distributed multimedia applications”, K. Nahrstedt et al., Journal of High Speed Networks 7 (1998), 229–257 insbesondere in der Beschreibung in Zusammenhang mit 3 und 6, dass es bekannt ist, Verhandlungen bei der Verwaltung von Ressourcen in Hinblick auf einen einzuhaltenden Qualitätsstandard auf einer zwischengelagerten Middleware-Schicht auszuführen, um Dead-Locks zu vermeiden. Notfallsituationen können mit diesem Modell jedoch nicht abgebildet werden.
Mögliche Lösungen dieses Problems können mitunter separate Notfallsysteme sein, etwa zur Diagnose-Erstellung, die ausschließlich für den Notfall verwendet werden. Ein solches Vorgehen ist teuer, da separate Notfallsysteme in der Regel unbenutzt vorrätig gehalten werden müssen. Die hohen Kosten eines zusätzlichen, separaten Notfallsystems sind also nicht gerechtfertigt.
Ferner wäre es möglich, keine der Prozesse auf Clients zuzulassen, die im Falle eines Notfalls benötigt werden. Ein solches Vorgehen ist ebenfalls teuer, da weitere Clients notwendig werden, die ausschließlich die innerhalb der erweiterbaren medizinischen Plattform anfallenden Prozesse erledigen. Darüber hinaus macht es die zunehmende Vernetzung aller Clients bzw. Knoten innerhalb einer erweiterbaren medizinischen Plattform (kurz Plattform) erforderlich, dass von allen Clients aus Daten empfangen und gesendet werden können. Für einen Client der Plattform, auf dem keine Prozesse zulässig sind, wäre insbesondere kein Netzwerkzugriff auf diesen Client oder von diesem Client auf andere möglich.
Um das vorstehend beschriebene Problem zu lösen, wäre es weiterhin denkbar, Spezialbetriebssysteme für Clients einzusetzen, auf denen Prozesse laufen. Dabei müssten die Spezialbetriebssysteme eine gleich bleibende Quality of Service gewährleisten. Derlei Spezialbetriebssysteme sind dem Fachmann bekannt. Allerdings ist der Programmieraufwand für solche Quality of Service-Systeme hoch und das bedeutet einen zusätzlich Wartungsaufwand, Trainingszeiten für die Programmierer, sowie zusätzliche Programmübersetzungsläufe für Zielsysteme, also Clients, die unter dem Spezialbetriebssystem laufen. Ferner erhöht sich der Testaufwand für die Clients, auf denen Prozesse unter dem Spezialbetriebssystem laufen.
Weiter wäre es denkbar, Prozesse an ausgewählte dezidierte CPUs zu binden. Dadurch ließe sich zwar die Verfügbarkeit der CPU-Ressource steuern, allerdings ergibt sich daraus noch kein Einfluss auf stattfindende I/O-Aktivitäten, die von Prozessen angestoßen wurden. Das heißt, das gewünschte deterministische Verhalten für ein Notfallsystem wäre immer noch nicht gewährleistet.
Ferner wäre es möglich, die Prioritäten für Prozesse herabzusetzen. Solche Verfahren werden in der Regel durch Betriebssysteme zur Verfügung gestellt und sind dem Fachmann bekannt. Möglicherweise beeinträchtigt ein Herabsetzten der Prioritäten für Prozesse das Scheduling-Verhalten des gesamten vom Betriebssystem gesteuerten Client bzw. der gesamten Plattform. Solch ein Ansatz setzt allerdings voraus, dass jeder einzelne Prozess als Prozess auf Betriebssystemebene realisiert ist. Bei der hohen Zahl von Prozessen, die innerhalb einer Plattform laufen, ist dieser Ansatz wenig effektiv. Darüber hinaus bedeutet ein solches Ändern der Betriebssystem-Prioritäten für Prozesse noch kein deterministisches Verhalten in Notfallsituationen.
Aufgabe der Erfindung ist es, die zuverlässige Verfügbarkeit von Ressourcen der Plattform in Notfallsituationen zu gewährleisten. Darüber hinaus ist es Aufgabe der Erfindung, auch im regulären Betrieb der Plattform ein deterministisches Verhalten der Prozesse unter Einhaltung der erforderlichen Quality of Service sicherzustellen.
Diese Aufgabe wird durch ein Verfahren, eine Vorrichtung und ein Computerprogramm gemäß den beiliegenden nebengeordneten Patentansprüchen gelöst.
Nachstehend wird die Lösung der Aufgabe gemäß dem Verfahren beschrieben. Hierbei erwähnte Merkmale, alternative Ausführungsformen und/oder Vorteile sind ebenso auch auf die anderen beanspruchten Gegenstände zu übertragen und umgekehrt. Mit anderen Worten können auch die gegenständlichen Ansprüche mit den Merkmalen, die in Zusammenhang mit dem Verfahren beschrieben oder beansprucht sind, weitergebildet sein. Die entsprechenden funktionalen Merkmale des Verfahrens werden dabei durch entsprechende gegenständliche Module, insbesondere durch Hardware-Module und/oder Softwaremodule des Systems ausgebildet.
Die Aufgabe wird insbesondere gelöst durch ein computerimplementiertes Verfahren zum Steuern von Zuweisungen von Ressourcen an Prozesse in erweiterbaren medizinischen Plattformen mit einer zentralen Instanz und einer Meta-Schnittstelle zur Verwaltung von Ressourcen eines Typs, wobei das Verfahren folgende Schritte umfasst:

– Empfangen eines Auftrags für einen Prozess durch eine zentrale Instanz, wobei der Auftrag gekennzeichnet ist durch einen Auftragstyp;
– Zuordnen des Auftrags zu einem Warteschlangenzuweiser in Abhängigkeit des Auftragstyps,
– Ermitteln einer Vielzahl von Prozessressourcen, die zur Ausführung des Auftrags benötigt werden aus innerhalb der Plattform vorhandenen Ressourcen und Ermitteln eines Warteschlangennamens durch den Warteschlangenzuweiser;
– Anfragen der Prozessressourcen durch die zentrale Instanz bei der Meta-Schnittstelle;
– Zuweisen der Prozessressourcen zu dem Auftrag, soweit die Prozessressourcen zur Ausführung des Prozesses zur Verfügung stehen,
– Ausführen des Auftrags für einen Prozess, sofern alle der Prozessressourcen zur Verfügung stehen, wobei die Prozessres sourcen nach Abschluss des Prozesses freigegeben werden und die Meta-Schnittstelle informiert wird, so dass ein dead-lock freies Verhalten der Prozesse innerhalb der Plattform gewährleistet wird, wobei im Falle eines Notfallereignisses ein Unterbrechen mindestens eines Auftrages durch das Empfangen einer Benachrichtigung an der zentralen Instanz ausgelöst wird und mindestens ein Prozess angehalten wird bis ausreichend Prozessressourcen zur Notfallbearbeitung verfügbar sind.

Ein Auftragstyp im Sinne dieser Erfindung ist eine konzeptionelle Entität, mit anderen Worten eine „Formularvorlage”, die beschreibt, welche Informationen ein Client, der einen Auftrag absendet, angeben muss, um einen Auftrag hinreichend zu spezifizieren. Zum Beispiel gibt ein Druck-Auftragstyp an, dass der Client einen Druckernamen, einen Dokumentennamen und einen Druckmodus angeben muss.
Ein Auftrag im Sinne der vorliegenden Erfindung ist eine konkrete (dingliche) Instanz eines Auftragstyps. Das heißt eine konkrete Anweisung, was genau zu tun ist. Im Falle eines Druckauftrags zum Beispiel: Druckername = ”MyPrinter”, Dokumentenname = ”Fischer.dcm” und Druckmodus = ”600 dpi”.
Ein Prozessbearbeiter oder ein Auftragsbearbeiter im Sinne der vorliegenden Erfindung ist die Implementierung eines Services, der einen Auftrag ausführen kann. Die Begriffe Auftragsbearbeiter und Prozessbearbeiter werden im Rahmen dieser Beschreibung synonym verwendet.
Der Prozessbearbeiter wird in einem Prozess zur Ausführung gebracht. Das heißt der Prozess stellt einen Ablaufcontainer für den Prozessbearbeiter dar. Der Prozessbearbeiter kann immer nur genau einen Auftrag zu einer Zeit ausführen. Der Prozessbearbeiter kann so umgesetzt werden, dass er auch Aufträge unterschiedlicher Auftragstypen ausführen kann; aber immer nur streng sequentiell, einen Auftragstyp nach dem anderen. Darüber hinaus verfügt der Prozessbearbeiter über eine Vielzahl von Schnittstellen, welche die zentrale Instanz benö tigt, um ein Abarbeiten der Aufträge durch Prozessbearbeiter anzuhalten, fortzusetzen oder abzubrechen. Der Prozessbearbeiter kennt mindestens einen Auftragstyp, kann aber auch mehrere Auftragstypen verstehen.
In einem Prozess können ein oder mehrere Prozessbearbeiter zur Ausführung gebracht werden. Dabei ist die Zahl der Prozessbearbeiter innerhalb eines Prozesses konfigurierbar. Mit anderen Worten, ein Prozess im Sinne der Erfindung ist eine Instanziierung eines oder mehrerer Prozessbearbeiter.
Prozesse bzw. Hintergrundprozesse im Sinne dieser Erfindung sind solche computer-bezogenen Aktivitäten, die in der Regel unbemerkt vom Benutzer ablaufen. Darüber hinaus handelt es sich bei den Prozessen um solche Prozesse, die nicht durch ein Echtzeitbetriebssystem gesteuert sind, wie etwa Prozesse auf einem Scanner, was bereits eingangs erwähnt wurde.
Die Prozesse können auf Betriebssystem-Ebene laufen und die Funktionsweise eines Computersystems steuern. Ein Client im Zusammenhang mit der vorliegenden Erfindung ist z. B. ein solches Computersystem.
Vorzugsweise ist unter einem Prozess im Sinne dieser Erfindung eine Instanz einer ausführbaren Einheit, ein Executable, das heißt ausführbarer Programmcode gemeint. Der Prozessbearbeiter ist solch ein ausführbarer Programmcode, der als Instanziierung eines Prozessbearbeiters in einem Prozess zur Ausführung kommt.
Die Prozesse laufen innerhalb der medizinischen Plattform und steuern die Funktionsweise der medizinischen Plattform. Ein Prozess kann z. B. die Anzeige von MR-Bildern sein. Weitere Beispiele für Prozesse im Sinne der Erfindung können das Drucken von Bilddaten, sowie das Laden von Bilddaten aus dem Plattenspeicher der Plattform sein.
Prozesse werden durch Aufträge für Prozesse angestoßen, die in der Regel von einem Benutzer eines Clients ausgelöst wer den. Prozesse sind ferner eine Instanziierung eines Prozessbearbeiters für einen Auftragstyp, wie bereits erwähnt.
Ein Beispiel für einen Auftrag ist „Zeige die MR-Daten des Patienten Fischer”. Aufträge können von ganz unterschiedlichen Typen sein und sind jeweils durch einen Auftragstyp gekennzeichnet. So ist zum Beispiel „Berechne die Mikrokalzifikation der Patientin Müller” ein weiterer Auftrag, dessen Auftragstyp sich vom vorangehenden Beispiel unterscheidet.
Ein Auftrag für einen Prozess wird von der zentralen Instanz empfangen und ist ferner durch einen Auftragstyp gekennzeichnet.
Das bedeutet, die zentrale Instanz muss nicht mehr als den Auftragstyp eines eingehenden Auftrags kennen. Abhängig von dem Auftragstyp des Auftrags wird dieser durch die zentrale Instanz einem Warteschlangenzuweiser zugeordnet.
Der Warteschlangenzuweiser analysiert den Auftrag und ermittelt für den Auftrag eine Vielzahl von Prozessressourcen aus allen im System verfügbaren Ressourcen, die zur Ausführung des Auftrags notwendig sind. Ferner ermittelt der Warteschlangenzuweiser die Warteschlange in welcher der Auftrag abzulegen ist.
Daraufhin fragt die zentrale Instanz die Prozessressourcen wie von dem Warteschlangenzuweiser ermittelt an. Diese Anfrage durch die zentrale Instanz erfolgt bei einer Vielzahl von Meta-Schnittstellen, welche jeweils Ressourcen eines Typs verwalten.
Falls es der zentralen Instanz gelingt, alle Prozessressourcen für den Prozess zu belegen, kommt der Prozess zur Ausführung. Nach Abschluss des Prozesses werden die Prozessressourcen freigegeben und die Meta-Schnittstellen über das Freiwerden der Prozessressourcen informiert. Dabei ist ein deterministisches Verhalten der Prozesse innerhalb der Plattform gewährleistet.
Unter Ressourcen sollen im Rahmen dieser Beschreibung verstanden werden: Geräte, Gerätekomponenten und Betriebsmittel. Ressourcen können zum Beispiel sein: ein Drucker, eine dezidierte Graphik-Hardware zur Rekonstruktion von Bilddaten einer modernen medizinischen Modalität, Zugriff auf das Netzwerk oder Zugriffe auf Plattenspeicher. Weitere Ressourcen innerhalb der Plattform sind für den Fachmann offensichtlich.
Die zentrale Instanz im Sinne der Erfindung koordiniert die Abarbeitung der eingehenden Aufträge für Prozesse und stellt die dead-lock freie Ausführung der Aufträge unter Verwendung der innerhalb der Plattform verfügbaren Ressourcen sicher. Die Ausführung der Aufträge erfolgt dabei durch Prozesse. Die Prozesse sind die Instanziierung des jeweiligen Prozessbearbeiters, wie bereits erwähnt.
Im Rahmen dieser Erfindung wird ein explizites Protokoll zur Verwaltung von Prozessen vorgeschlagen. Die zentrale Instanz beeinflusst die Abarbeitung von Aufträgen mittels Kontrollnachrichten an die Prozessbearbeiter, d. h. sie hält die Prozessbearbeiter an oder lässt sie mit der Abarbeitung weiter fortfahren. Das heißt, die zentrale Instanz hält nicht unbedingt einen ganzen Prozess an, in dem ja mehrere unterschiedliche Prozessbearbeiter laufen können. Insbesondere erfolgt die Verwaltung von Prozessen gemäß der vorliegenden Erfindung über die zentrale Instanz. Damit ist die Gesamtheit aller innerhalb der Plattform laufenden Prozesse bekannt.
Beide Eigenschaften der Erfindung, also das Protokoll zum Anhalten von Prozessen sowie die zentrale Instanz zur Steuerung der Prozesse erlauben es, eine Vielzahl von in der Plattform vorhandenen Prozessen gewissermaßen „auf Zuruf” anzuhalten, sofern sich eine Notfallsituation einstellt.
Die Steuerung von Prozessen in einer erweiterbaren medizinischen Plattform übernimmt also die zentrale Instanz. Die zentrale Instanz registriert alle Aufträge für Prozesse, eine Vielzahl von Warteschlangen und Warteschlangenzuweiser, die durch die zentrale Instanz verwaltet werden. Dabei können die Warteschlangen – abhängig vom Auftragstyp – unterschiedlich sein.
Ferner umfasst das erfindungsgemäße Verfahren eine Meta-Schnittstelle zur Verwaltung aller in der Plattform verfügbaren Ressourcen. Das erfindungsgemäße Verfahren stellt ein deterministisches Verhalten für alle Prozesse innerhalb der Plattform sicher. Die Erfindung erlaubt es, einen oder alle Prozess/e innerhalb des Systems anzuhalten, und so ausreichend Ressourcen für die sofortige Reaktion auf eine Notfallsituation zu gewährleisten. Eine solche Notfallsituation kann z. B. die Untersuchung eines Schlaganfall- oder Trauma-Patienten ergeben.
Mit dem erfindungsgemäßen Verfahren ist es möglich gleichzeitig mehrere Aufträge für Prozesse an der zentralen Instanz zu empfangen. Ebenso kann die zentrale Instanz mehrere Prozessbearbeiter parallel ausführen, vorausgesetzt, die Prozessressourcen für die mehreren Prozessbearbeiter konnten erfolgreich den mehreren Prozessbearbeitern zugewiesen werden.
Das System kann mehrere Warteschlangen für Aufträge unterschiedlichen Typs umfassen. Vorzugsweise wird jedem Auftragstyp eine eigene Warteschlange zugewiesen.
Warteschlangen im Sinne der Erfindung können als Hardwaremodul und oder Softwaremodul realisiert sein.
Es ist vorteilhaft für unterschiedliche Auftragstypen unterschiedliche Warteschlangen zu verwenden. Bei gesonderten Warteschlangen für verschiedene Auftragstypen können einzelne Warteschlangen bedarfsgerecht und ressourcen-schonend implementiert werden.
Selbstverständlich ist es nach einer weiteren Ausführungsform der Erfindung möglich, eine einzige Warteschlange für alle Auftragstypen zu verwenden. Allerdings wäre die Verwaltung einer solchen einzigen Warteschlange deutlich komplizierter in der Verwaltung. Außerdem wäre dann die Modularität des Verfahrens reduziert.
Die Ausführung der Aufträge eines Auftragstyps wird durch mindestens einen Prozessbearbeiter ausgeführt. Der mindestens eine Prozessbearbeiter wird durch die zentrale Instanz gestartet. Welcher Prozessbearbeiter zum Einsatz kommt, ist durch den Auftragstyp des Auftrags festgelegt.
Das Verfahren erlaubt es, einen laufenden Prozessbearbeiter anzuhalten, wodurch ein deterministisches Unterbrechen der Prozesse sicher gestellt ist.
So kann jeder der Prozesse innerhalb der Plattform angehalten werden, und wieder gestartet werden, so dass die weitere Bearbeitung durch den jeweiligen Prozessbearbeiter nach einer Unterbrechung möglich ist.
Darüber hinaus kann die zentrale Instanz eine Warnung empfangen, die anzeigt, dass in Kürze ein kritischer Zustand erreicht wird. Daraufhin startet die zentrale Instanz keine weiteren Prozessbearbeiter, lässt die aktiven Prozessbearbeiter jedoch weiter arbeiten.
Es ist außerdem vorgesehen, dass jeder der, innerhalb der Plattform aktiven Prozessbearbeiter angehalten werden kann und zum weiteren Bearbeiten wieder freigegeben werden kann. Dadurch werden Ressourcen z. B. für einen Notfall kontrolliert und zuverlässig frei. Das Anhalten und Freigeben erfolgt erfindungsgemäß durch die zentrale Instanz.
Außerdem kann das Unterbrechen mindestens eines Auftrags durch das Empfangen einer Benachrichtigung an der zentralen Instanz (z. B. auf ein medizinisches Notfallereignis hin) ausgelöst werden. Daraufhin wird automatisch mindestens ein Prozess angehalten, bis ausreichend Ressourcen (zur Notfallbearbeitung) verfügbar sind.
Darüber hinaus erlaubt es die Erfindung, neue Auftragstypen, die neue Prozesstypen anstoßen, zum System hinzuzufügen. Insbesondere erlaubt es die Erfindung, die neuen Prozesstypen zur Laufzeit hinzuzufügen. Das ist für den Anwender äußerst komfortabel, da Service-Techniker oder Drittanbieter weitere Auftragstypen bzw. neue Funktionalitäten im Zusammenhang mit neuen Auftragstypen gewissermaßen per Knopfdruck hinzufügen können.
Ferner wird die Bereitstellung neuer Funktionalitäten zur Plattform in Form von neuen Prozesstypen erleichtert, da ein Drittanbieter sich nicht mehr um die Verwaltung von Warteschlangen für seinen neuen Prozess kümmern muss.
Aufgabe der Meta-Schnittstelle ist es dabei, die für einen Prozess benötigten Ressourcen, zu verteilen.
Wenn Ressourcen für einen Prozess verfügbar sind, werden Sie von der Meta-Schnittstelle als so genannte Prozessressourcen belegt. Vorzugsweise belegt jede der Meta-Schnittstellen Prozessressourcen für einen Auftragstyp und gibt die Prozessressourcen nach erfolgter Erledigung des Auftrags wieder frei. Sind die Prozessressourcen nicht verfügbar, so verbleibt der Auftrag in der Warteschlange und es erfolgt keine sofortige Ausführung des Auftrags. Die zentrale Instanz kümmert sich in diesem Fall um eine Ausführung des Auftrags zu einem späteren Zeitpunkt.
Die einzelnen Komponenten der Erfindung sind modular realisiert, so dass die Warteschlangen und/oder die Warteschlangenzuweiser, der Prozessbearbeiter und die Meta-Schnittstelle zu einem Auftragstyp jeweils unabhängig voneinander geändert werden können. Dadurch wird die Erweiterung und Programmierung einzelner Prozesstypen vereinfacht.
Ein Auftrag ist gekennzeichnet durch seinen Auftragstyp und kann darüber hinaus eine Vielzahl von Parametern umfassen. Solche Parameter können z. B. in der Auflösung, in der die Bilddaten eines Druckauftrags gedruckt werden, bestehen. Weitere Auftragsparameter sind für den Fachmann offensichtlich.
Die zentrale Instanz, die Warteschlangen, die Warteschlangenzuweiser, die Meta-Schnittstellen und die Prozessbearbeiter im Sinne der Erfindung können jeweils als Hardwaremodule und/oder als Softwaremodule implementiert sein.
Die Erfindung kann weiterhin durch eine Vorrichtung realisiert sein, welche die Steuerung von Zuweisungen von Ressourcen an Prozesse in erweiterbaren medizinischen Plattformen erledigt. Die Vorrichtung umfasst eine zentrale Instanz zum Empfang eines Auftrags für einen Prozess. Der Auftrag ist gekennzeichnet durch seinen Auftragstyp und kann außerdem weitere Auftragsparameter umfassen.
Die in einem Empfangsmodul eingegangenen Aufträge werden, abhängig vom Auftragstyp durch einen Warteschlangenzuweiser analysiert und einer Warteschlange zugewiesen. Ferner ermittelt der Warteschlangenzuweiser die Prozessressourcen aus allen in der Plattform verfügbaren Ressourcen und teilt die Prozessressourcen der zentralen Instanz mit. Daraufhin fragt die zentrale Instanz die Prozessressourcen bei den Meta-Schnittstellen der Prozessressourcen an. Die Prozessressourcen werden dem Auftrag zugewiesen, sofern sie verfügbar sind. Der Auftrag wird ausgeführt, sofern die Verfügbarkeit aller Prozessressourcen gegeben ist. Nach Abschluss des Prozesses werden die Prozessressourcen freigegeben und die jeweiligen Metaschnittstellen über das frei werden der Ressourcen informiert. Auf diese Weise wird ein deterministisches Verhalten der Prozesse innerhalb der Plattform gewährleistet.
Eine weitere Aufgabenlösung ist auch als Computerprogrammprodukt möglich, das ladbar in den Speicher eines Computers ist. Das erfindungsgemäße Verfahren wird durch Computerprogrammcode realisiert, der die einzelnen Schritte des Verfahrens abbildet.
Eine alternative Aufgabenlösung sieht ein Speichermedium vor, das zur Speicherung des vorstehend beschriebenen, computerimplementierten Verfahrens bestimmt ist und von einem Computer lesbar ist.
Darüber hinaus ist es möglich, dass einzelne Komponenten des vorstehend beschriebenen Verfahrens in einer verkaufsfähigen Einheit und die restlichen Komponenten in einer anderen verkaufsfähigen Einheit – sozusagen als verteiltes System – ausgeführt werden können.
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
2 einen Datenfluss gemäß einer bevorzugten Ausführungsform der Erfindung.
1 zeigt die einzelnen Komponenten der Erfindung. Die Erfindung umfasst eine zentrale Instanz 5, einen Warteschlangenzuweiser 10, einen Auftrag 1 eines Auftragstyps 1a für einen Prozess 4 (nicht gezeigt), der auf einem Client 3 (nicht gezeigt) angestoßen wird, eine Meta-Schnittstelle 30 und einen Prozessbearbeiter 40 zur Ausführung des Auftrags 1. Dabei ist der Client 3 ein beliebiger Knoten innerhalb der Plattform.
Prozesse 4 im Sinne dieser Erfindung können solche computer-bezogenen, betriebssystem-interne Aktivitäten sein, die in der Regel unbemerkt vom Benutzer ablaufen. Darüber hinaus handelt es sich bei den Prozessen 4 um solche Prozesse, die nicht durch ein Echtzeitbetriebssystem gesteuert sind, wie etwa Prozesse auf einem Scanner.
Vorzugsweise ist unter einem Prozess im Sinne dieser Erfindung eine Instanz einer ausführbaren Einheit, ein Executable, das heißt ausführbarer Programmcode gemeint. Der Prozessbearbeiter umfasst zum Beispiel ausführbaren Programmcode, der als Instanziierung eines Prozessbearbeiters zu einem Prozess wird. Die bevorzugte Ausführungsform eines Prozesses ist daher nicht notwendig ein Betriebssystemprozess, wie weiter oben erwähnt.
Selbstverständlich kann die Erfindung auch auf medizinischen Plattformen zum Einsatz kommen, die nicht notwendig einen Scanner umfassen, wenngleich die Erfindung im Folgenden anhand einer solchen modernen medizinischen Modalität beschrieben wird.
Der Benutzer eines Clients 3 kann Prozesse 4 im Sinne der Erfindung durch Aufträge 1 anstoßen. Es existiert innerhalb der Plattform eine Vielzahl der Prozesse 4. Unterschiedliche Prozesse 4 sind durch einen Auftragstypen 1a gekennzeichnet. Beispiele für Auftragstypen sind: ein Druck-Auftragstyp, ein DICOM-Transfer Auftragstyp, Auftragstyp für computer aided diagnosis, und der gleichen.
Das Drucken der Bilddaten einer Bilderserie des Patienten „Fischer” auf dem Drucker MyPrinter ist ein Beispiel für einen Prozess 4 im Sinne der Erfindung. Der Client 3 würde also z. B. den Auftrag ”Ausdruck der Bilderserie des Patienten Fischer in 600 dpi auf Myprinter auf Papierformat A3 mit 4 × 4 Bildern pro Seite in 32 Graustufen” anstoßen. Dabei bezeichnet der Druckauftrag den Auftragstyp 1a, während alle übrigen Parameter etwa die Anzahl der dpi bzw. der spezielle Drucker oder die Auflösung der Bilder so genannte Auftragsparameter 2 sind.
Anhand eines Beispiels soll im Folgenden das Verfahren zur Verwaltung einer Vielzahl von Prozessen 4 innerhalb der erweiterbaren medizinischen Plattform dargestellt werden. Die Ausdehnung der Erfindung auf weitere Auftragstypen 1a ist für den Fachmann offensichtlich und stellt keine Einschränkung der vorliegenden Erfindung dar.
2 zeigt zu einem Prozess 4 die Aktivitäten und das Zusammenspiel einzelner Komponenten der erfindungsgemäßen Vorrichtung zur Ausführung des erfindungsgemäßen Verfahrens.
Der von einem Client 3 angestoßene Auftrag 1 wird von einer zentralen Instanz 5 empfangen. Der Auftrag 1 ist durch den Auftragstyp 1a gekennzeichnet. Aufgabe der zentralen Instanz 5 ist erfindungsgemäß das Empfangen einer Vielzahl von Aufträgen 1 unterschiedlichen Auftragstyps 1a von unterschiedlicher Clients 3 innerhalb der Plattform.
Für jeden der Auftragstypen 1a existiert ein Warteschlangenzuweiser 10. Der Warteschlangenzuweiser 10 ermittelt für einen konkreten Auftrag 1 von dem Auftragstyp 1a einen Warteschlangen-Namen 17, den er an die zentrale Instanz 5 zurückliefert. Das heißt mit anderen Worten, die zentrale Instanz 5 hat für einen eingehenden Auftrag 1, durch Kenntnis des Auftragstyp 1a, alle Information, um über die Zuordnung 7 den Wartenschlangen-Zuweiser 10 zu ermitteln, der zu dem gegebenen Auftragstyp 1a passt.
Die Vielzahl von Warteschlangenzuweisern 10 ist als eigenständiges Modul realisiert, vorzugsweise als ein Softwaremodul.
Der Auftrag 1 wird nun von der zentralen Instanz 5 in einer Warteschlange 15 abgelegt, bis der Auftrag 1 bearbeitet werden kann. Die Warteschlangen 15 werden dynamisch durch die zentrale Instanz 5 erzeugt und vernichtet.
Neben dem Warteschlangen-Namen 17 ermittelt der Warteschlangenzuweiser 10 noch die für die Ausführung eines Auftrags 1 erforderlichen Ressourcen 20. Die für einen Auftrag erforderlichen Ressourcen werden im Folgenden als Prozessressourcen 25 bezeichnet. Die Prozessressourcen 25 sind dadurch gekennzeichnet, dass die Prozessressourcen 25 verfügbar sein müssen für den Auftrag 1, da ohne die Verfügbarkeit der Prozessres sourcen 25 der Auftrag 1 nicht zur Ausführung durch einen Prozessbearbeiter 40 kommen kann. Der Warteschlangenzuweiser 10 teilt den Warteschlangen-Namen 17, die Prozessressourcen 25 und den Prozessbearbeiter 40 zu einem Auftrag 1 der zentralen Instanz 5 mit.
Sofern die Warteschlange 15 mit dem Warteschlangen-Name 17 noch nicht existiert, wird die Warteschlange 15 von der zentralen Instanz angelegt und der Auftrag 1 von der zentralen Instanz 5 in der Warteschlange 15 abgelegt. Die Erzeugung und Verwaltung der Warteschlangen 15 über die zentrale Instanz 5 befreit den Prozessbearbeiter 40 zur Ausführung von Aufträgen 1 des Auftragstyps 1a von der Pflicht, eingehende Aufträge 1 vom Typ 1a selbst in Warteschlangen 15 zu verwalten.
Die Vergabe der Prozessressourcen 25 an den Auftrag 1 vom Auftragstyp 1a wird über eine Vielzahl von Meta-Schnittstellen 30 koordiniert. Einzelne der Meta-Schnittstellen 30 verwalten Prozessressourcen eines Typs. Solche Prozessressourcen eines Typs können z. B. sein: Der Zugriff auf einen Drucker, die Bereitstellung von Arbeitsspeicher und CPU-Rechenleistung auf dezidierter Grafik-Hardware zur Rekonstruktion von Bilddaten. Weitere Typen von Prozessressourcen sind für den Fachmann offensichtlich.
Die zentrale Instanz 5 versucht nun, die Prozessressourcen 25 für den Auftrag 1 in einer der Warteschlangen 15 bei den, zu den Prozessressourcen 35 passenden Meta-Schnittstellen 30 zu reservieren. Immer dann, wenn es der zentralen Instanz 5 gelingt, alle der Prozessressourcen 25 eines Auftrags 1 erfolgreich bei den Meta-Schnittstellen 30 anzufordern, startet die zentrale Instanz 5 den Prozessbearbeiter 40.
Zu jedem Auftragstyp 1a gehört ein Prozessbearbeiter 40. Der Prozessbearbeiter 40 erbringt als Antwort auf einen Auftrag 1 eine technische Dienstleistung. Vorzugsweise ist der Prozessbearbeiter 40 als Softwaremodul realisiert, das den Auftrag 1 ausführt. Zum Beispiel könnte ein Prozessbearbeiter 40 die Auflösung von Patientendaten (MR-Tomographie Daten des Patienten Fischer) zum Drucken vorbereiten. Das heißt z. B., die Graustufen entsprechend verteilen, festlegen, wie viele einzelne Bilder pro DINA4-Seite gedruckt werden, in welcher Auflösung und Größe.
Wesentliches Merkmal der Prozessbearbeiter 40 gemäß der vorliegenden Erfindung ist, dass sie von der zentralen Instanz 5 unterbrochen werden können. Die Prozessbearbeiter 40 weisen die dafür erforderlichen Schnittstellen auf. Mittels des Anhaltens oder eines Abbrechens von Prozessbearbeitern 40 werden Ressourcen 25 innerhalb der Plattform frei, die z. B. für eine Notfallsituation benötigt werden. Darüber hinaus können Prozessbearbeiter 40, die durch die zentrale Instanz 5 angehalten wurden, von dieser mit der Wiederaufnahme der Ausführung des Auftrags 1 beauftragt werden. Das heißt zuvor durch die zentrale Instanz 5 angehaltene Prozessbearbeiter 40 können durch die zentrale Instanz 5 zur Fortsetzung der Durchführung des Auftrags 1 beauftragt werden. Selbstverständlich müssen vor der Fortsetzung die Prozessressourcen 25 verfügbar sein.
Darüber hinaus ist es möglich, dass die zentrale Instanz 5 mehrere Prozessbearbeiter 40 gleichzeitig mit der Ausführung mehrerer Aufträge 1 beauftragt, sofern die Prozessressourcen 25 für jeden der aktiven Prozessbearbeiter 40 und damit für die mehreren Aufträge 1 reserviert sind.
Die, zu den Prozessressourcen 25 eines Auftrags 1 (z. B. einem Druckauftrag) passenden, Meta-Schnittstellen 30 verwalteten Ressourcen im System. Die Meta-Schnittstellen 30 können Prozessressourcen 25, welche die zentrale Instanz 5 bei den Meta-Schnittstellen 30 anfordert, der zentralen Instanz 5 zur Verfügung stellen.
Insbesondere belegt die Meta-Schnittstelle 30 die Ressource 20 als die Prozessressource 25 für den Auftrag 1. Nach erfolgter Ausführung des Auftrags 1 durch den Prozessbearbeiter 40, der von der zentralen Instanz 5 mit der Ausführung des Prozesses 4 beauftragt wurde, gibt der Prozessbearbeiter 40 die verwendeten Prozessressourcen 25 an die zentrale Instanz 5 zurück.
Die zentrale Instanz 5 entscheidet daraufhin, ob die Prozessressourcen 25 als freie Ressourcen 20 an die Meta-Schnittstelle zurückgegeben werden oder gleich für einen weiteren Auftrag 1 verwendet werden.
Meta-Schnittstellen 30 verwalten die parallele Verwendung einer Klasse von im System vorhandenen Ressourcen 20 durch mehrere Aufträge 1. So könnten beispielsweise alle im System verfügbaren Drucker über eine Meta-Schnittstelle 30 verwaltet werden. Die Meta-Schnittstelle 30 kennt insbesondere Randbedingungen für die gleichzeitige Verwendung von Ressourcen 30 gleichen Typs.
So könnte etwa für die Meta-Schnittstelle zur Verwaltung von Netzwerkschnittstellen 31 festgelegt sein, dass immer nur drei abgehende Netzwerkverbindungen von einem Client 3 abgehen können. Das bedeutet für einen Client 3, auf dem Prozesse 1 laufen, dass maximal drei Netzwerkverbindungen gleichzeitig von diesem Client 3 abgehen können.
Sofern der Benutzer des Clients 3 einen weiteren Prozess 1 anstößt, der eine abgehende Netzwerkverbindung aufbauen möchte, wird dies durch die Meta-Schnittstelle zur Verwaltung von Netzwerkschnittstellen 31 nur dann dem Prozess 1 zugewiesen, wenn bereits maximal zwei abgehende Netzwerkverbindungen offen sind. Sind hingegen bereits drei Netzwerkverbindungen offen, so wird die vierte Anfrage zum Öffnen einer abgehenden Netzwerkverbindung durch die Meta-Schnittstelle zur Verwaltung von Netzwerkschnittstellen 31 verhindert. Damit wird das Maß an Netzwerk-Traffic, der von einem Client 3 abgeht, begrenzt.
Eine andere Ressource 20 könnte Rechenzeit auf einem Computersystem sein, um dort komplexe Rekonstruktionen von Rohdaten zu berechnen.
So ist es etwa denkbar, dass der Benutzer eines Clients 3 einen Auftrag 1 zur Rekonstruktion eines 3D-Datensatzes des Patienten Fischer anstößt, z. B. aus MR-Tomographie Daten. Das bedeutet, die zentrale Instanz 5 würde bei den entsprechenden Meta-Schnittstellen für Rekonstruktions- bzw. Graphik-Workstations 33 die Prozessressourcen 25 anfragen. Die Meta-Schnittstelle zur Vergabe von Graphik-Workstation-Ressourcen 33 könnte beispielsweise festlegen, dass maximal ein Prozess 1 zur Rekonstruktion auf einer solchen Graphik-CPU mit zugeordnetem Hauptspeicher laufen kann.
Erfolgt für dieselbe Workstation eine zweite Anfrage von der zentralen Instanz 5, so wird die Zuteilung der Prozessressourcen 25 für Rekonstruktions- bzw. Graphik-Workstations durch die entsprechenden Meta-Schnittstellen für Rekonstruktions- bzw. Graphik-Workstations 33 abgewiesen. Das bedeutet, der zweite eingehende Auftrag 1 zur Rekonstruktion eines Datensatzes wird verwehrt. Damit ist beispielsweise sichergestellt, dass ein Auftrag 1 zur Rekonstruktion von Bilddaten innerhalb eines vorgegebenen zeitlichen Rahmens ausgeführt werden kann.
Die Meta-Schnittstelle 30 fungiert damit im Sinne eines Semaphors, ein Modell zur Modellierung der gleichzeitigen Verwendung von Ressourcen, das dem Fachmann auf dem Gebiet hinreichend bekannt ist. Die Dead-lock Freiheit wird im Rahmen der Erfindung durch entsprechende Scheduling und Allocation Algorithmen in der zentralen Instanz 5 beim Anfordern von Prozessressourcen 25 erreicht.
Das erfindungsgemäße Verfahren erlaubt die Erweiterung der Plattform um neue Auftragstypen 1b für Prozesse 1 im laufenden Betrieb, das heißt zur Laufzeit der Plattform. Dies ergibt sich insbesondere aus der verteilten ”Intelligenz” des Verfahrens auf eine einfache zentrale Instanz 5, einen Warteschlangenzuweiser 10 zur Koordination mehrerer Warteschlangen 15, die der zentralen Instanz 5 bekannt sind, sowie die Meta-Schnittstellen 30 zu der Vielzahl von in der Plattform vorhandenen Ressourcen 20.
Um einen neuen Auftragstyp 1b für einen neuen Prozesstyp 4a zur Plattform hinzuzufügen, genügt es, zur Plattform einen neuen Warteschlangenzuweiser 10a, sowie einen neuen Prozessbearbeiter 40a im System zu hinterlegen, sowie gegebenenfalls neue Meta-Schnittstellen 30a. Es genügt, dass die zentrale Instanz 5 den neuen Warteschlangenzuweiser 10a des neuen Auftragstyps 1b kennt.
Dies kann z. B. realisiert werden über die Zuordnung 7 von Auftragstyp 1a und Warteschlangenzuweiser 10, die für einen neuen Auftragstyp 1b um einen weiteren Eintrag ergänzt wird. Dem neuen Warteschlangenzuweiser 10a wiederum ist neben dem Namen der neuen Warteschlange 15a auch der Name des neuen Prozessbearbeiters 40a bekannt. Es genügt also zur Erweiterung der Plattform um einen neuen Auftragstyp 1b, die Zuordnung 7 um einen neuen Eintrag zu erweitern, den neuen Warteschlangenzuweiser 10a und den neuen Prozessbearbeiter 40a, sowie gegebenenfalls eine neue Meta-Schnittstelle 30a an geeigneter Stelle innerhalb der Plattform zu hinterlegen. Nach erfolgter Hinterlegung genügt die Aktualisierung der Zuordnung 7, z. B. als Konfigurationsdatei, um der zentralen Instanz 5 diesen neuen Auftragstyp 1b bekannt zu machen. So würde insbesondere die Erweiterung des Systems zur Laufzeit möglich. Ferner können einzelne Module unabhängig voneinander getauscht oder erweitert werden.
Darüber hinaus erlaubt die verteilte Erledigung der zu einem angestoßenen Auftrag 1 gehörenden Prozessschritte mittels der zentralen Instanz 5, die dead-lock freie Abarbeitung der in der Plattform anfallenden Aufträge 1 für Prozesse 40. Drittanbietern, die Erweiterungen der Plattform zur Verfügung stellen, wird damit die Arbeit erheblich erleichtert. Der Drittanbieter muss die neuen Warteschlangen 10a nicht implementieren oder sich um die dead-lock freie Ressourcenanforderung und priorisierte Abarbeitung der Aufträge 1 kümmern.
Im Folgenden wird der dynamische Ablauf des erfindungsgemäßen Verfahrens gezeigt. Ein Client 3 erzeugt einen Auftrag 1 und gibt diesen an die zentrale Instanz 5. Die zentrale Instanz findet, abhängig vom Auftragstyp den zugehörigen Warteschlangenzuweiser 10. Der Warteschlangenzuweiser 10 analysiert daraufhin den bei der zentralen Instanz 5 eingegangenen Auftrag und gibt der zentralen Instanz 5 daraufhin den Warteschlangen-Namen 17, sowie möglicherweise eine Vielzahl von Prozessressourcen 25 und daraufhin optional eine Liste von Prozessparametern zurück. Mit dieser Information weiß die zentrale Instanz 5 in welcher Warteschlange 15 der Auftrag 1 abgelegt werden muss.
Darüber hinaus sind nun die Prozessressourcen 25 zur Ausführung des Auftrags 1 bekannt. Der Warteschlangenzuweiser 10 liefert ferner den Namen des für den Auftrag geeigneten Prozessbearbeiters 40 an die zentrale Instanz 5 zurück. Mit diesen Informationen kann die zentrale Instanz 5 den Auftrag 1 in einer bestimmten Warteschlange 15 ablegen, eventuell unter Berücksichtigung von Auftragsprioritäten. Existiert eine Warteschlange 15 mit diesem Namen noch nicht, dann erzeugt die zentrale Instanz 5 diese neue Warteschlange 15a.
Ferner kann die zentrale Instanz 5 nun, basierend auf dem zur Ausführung des Auftrags 1 erforderlichen Prozessressourcen 25, versuchen, diese für einen in der Vielzahl von Warteschlangen 15 gespeicherten Aufträge 1 zu reservieren. Zur Reservierung der Prozessressourcen 25 wendet sich die zentrale Instanz 5 an die entsprechenden der Meta-Schnittstelle 30, welche die innerhalb der Plattform vorhandenen Ressourcen 20 geeigneten Typs für den Auftrag 1 verwalten.
Wie bereits erwähnt, können Ressourcen 20 und damit auch Prozessressourcen 25 die Verwendung von Geräten umfassen oder CPU-Rechenzeit bzw. Arbeitsspeicher beinhalten. Selbstverständlich sind auch andere Ressourcen 20 in solch einer Plattform ohne Einschränkung der Erfindung denkbar. Soweit alle Prozessressourcen 25 für einen Auftrag 1 verfügbar sind, kann die zentrale Instanz 5 den Prozessbearbeiter 40 für einen Auftrag 1 mit der Bearbeitung des Auftrags 1 beauftragen und den Prozessbearbeiter 40 starten.
In einem Prozess können ein oder auch mehrere Prozessbearbeiter 40 zur Ausführung gebracht werden. Für solch eine Ausführungsform müsste der Warteschlangenzuweiser 10 die Prozessressourcen 25 des ersten Prozessbearbeiters und ferner die Prozessressourcen der weiteren Prozessbearbeiters an die zentrale Instanz 5 zurückmelden. Nachdem alle Prozessbearbeiter ihren Auftrag erledigt haben, werden die Prozessressourcen 25 des ersten Prozessbearbeiters 40 und die Prozessressourcen 25 der weiteren Prozessbearbeiter an die jeweiligen Meta-Schnittstellen zurückgegeben. Damit stehen sie der Plattform als Ressourcen 20 erneut zur Verfügung.
Die Flexibilität und Erweiterbarkeit der erfindungsgemäßen Lösung ist gegeben. Neue Auftragstypen können zu beliebigen Zeiten hinzugefügt werden. Die konkrete Realisierung von Warteschlangenzuweiser 10, Meta-Schnittstelle 30 und Prozessbearbeiter 40 zu einem gegebenen Auftrag 1 können immer dann unabhängig voneinander variiert werden. Die Warteschlangen-Anzahl wird durch die Warteschlangenzuweiser 10 kontrolliert. Es ist Aufgabe der zentralen Instanz 5, alle Warteschlangen 15 zu verwalten und zu kennen. Allerdings erzeugt die zentrale Instanz 5 die Warteschlangen 15 nicht auf Vorrat, sondern nur aufgrund von Informationen, welche die Warteschlangenzuweiser 10 liefern.
Die Realisierung der gleichzeitigen Anforderung von Ressourcen 20, das heißt einer Kommunikation zur Belegung von Ressourcen 20 ist durch die Meta-Schnittstellen 30 völlig gekapselt, was ebenfalls die Erweiterung der Plattform erleichtert.
Die Logik der Abarbeitung eines Auftrags 1 wird in einem Prozessbearbeiter 40 realisiert. Damit ist die Abarbeitung eines Auftrags 1 unabhängig von Warteschlangen-Verwaltung und von Ressourcenanforderungsprotokollen. Das Modul des Prozessbearbeiters 40 kann sich also einzig und allein auf die durch den Auftrag zu lösende Aufgabe konzentrieren. Die Implementierung des Prozessbearbeiters 40 wird dadurch erheblich vereinfacht. Durch die zentrale Instanz gemeinsam mit den Meta-Schnittstellen 30 wird die Vergabe von Ressourcen 25 dead-lock-frei erledigt und die Aufträge können durch die Prozessbearbeiter 40 abgearbeitet werden. Dabei können Aufträge 1 bei der Ablage in den Warteschlangen priorisiert werden. Ferner sind Randbedingungen für die Verwendung von Ressourcen 20 ein weiterer Bestandteil des erfindungsgemäßen Verfahrens. Solche Randbedingungen wurden oben bereits erläutert.
Selbstverständlich werden Prozessressourcen 25, die für einen Auftrag 1 reserviert wurden, nach Beendigung des Prozessbearbeiters 40 an die zentrale Instanz 5 zurückgegeben.
Die zentrale Instanz 5 entscheidet daraufhin, ob die Prozessressourcen 25 als freie Ressourcen 20 an die Meta-Schnittstelle 30 zurückgegeben werden oder gleich für einen weiteren Auftrag 1 verwendet werden. Insbesondere erlaubt die zentrale Instanz 5 zur Verteilung von Ressourcen 25 und zur Verteilung der Aufträge 1 auf Warteschlangen 15 alle laufenden Prozesse 4 zu kontrollieren. Durch die zentrale Instanz können einzelne Prozesse 4 angehalten werden.
Von einem Client 3 innerhalb der Plattform können Warnungen, Benachrichtigungen und/oder Nachrichten an die zentrale Instanz 5 gesandt werden.
Durch eine Warnung kann die zentrale Instanz 5 dazu veranlasst werden, keine weiteren Aufträge 1 mehr an Prozessbearbeiter 40 zu geben, sodass beim Eintreten eines kritischen Zustandes weniger laufende Prozesse überhaupt anzuhalten sind. Diese Warnung lässt allerdings alle bereits laufenden Prozessbearbeiter 40 noch fortfahren. Das Absetzen der Warnung ist optional und erfolgt typischerweise vor Eintritt eines kritischen Zustands.
Im Gegensatz dazu steht eine Benachrichtigung an die zentrale Instanz 5, die das Eintreten eines kritischen Zustandes bekannt gibt (z. B. Datenaufnahme hat begonnen). Durch die Benachrichtigung wird die zentrale Instanz 5 umgehend die laufenden Prozessbearbeiter 40 benachrichtigen, damit diese die Abarbeitung der laufenden Prozesse 4 einstellen.
Die Warnung ist eine optionale Vorstufe der Benachrichtigung. Offensichtlich unterstützt die Warnung das Verhalten der Plattform in kritischen Situationen: die Warnung kann dazu führen, dass weniger Prozesse 4 beim Empfang der Benachrichtigung über einen kritischen Zustand, anzuhalten sind.
Ebenso ist es möglich, über eine Nachricht mitzuteilen, dass derzeit Rohdaten eines Patienten (z. B. MR-Tomographie Untersuchung des Patienten Fischer) im Scanner aufgenommen werden und deshalb der Netzwerk-Verkehr hin zum Plattenspeicher des Scanners für weitere Prozesse 1 beschränkt werden sollte. Hohe Schreibzugriffe auf dem Plattenspeicher durch weitere Prozesse 1 würden die Geschwindigkeit der Platte zum Speichern der anfallenden Rohdaten verlangsamen. Realisieren lässt sich dies indirekt durch eine Beschränkung der möglichen Netzwerkverbindungen, die gleichzeitig abgehend vom Plattenlaufwerk des Scanners möglich sind.
Die Registrierung neuer Auftragstypen 1a, neuer Meta-Schnittstellen 30a, neuer Warteschlangenzuweiser 10a und neuer Prozessbearbeiter 40a kann über verschiedene Mechanismen innerhalb der Plattform erfolgen. Möglich ist die Realisierung über Konfigurationsfiles, ein zentrales Konfigurationsrepository, File-System-Verzeichnisse, in die Dateien gelegt werden, usw. Die konkrete Realisierung der Bekanntmachung der einzelnen Komponenten der Erfindung bei der zentralen Instanz 5 schränkt den Geist der Erfindung in keiner Weise ein, es handelt sich vielmehr um unterschiedliche Ausführungsformen, die aber alle im Sinne dieser Beschreibung für den Fachmann offensichtlich sind.
Abschließend sei darauf hingewiesen, dass die Beschreibung der Erfindung und die Ausführungsbeispiele grundsätzlich nicht einschränkend in Hinblick auf eine bestimmte physikalische Realisierung der Erfindung zu verstehen sind. Für einen einschlägigen Fachmann ist es insbesondere offensichtlich, dass die Erfindung teilweise oder vollständig in Soft- und/oder Hardware und/oder auf mehrere physikalische Produkte – dabei insbesondere auch Computerprogrammprodukte – verteilt realisiert werden kann.

Claims

Verfahren zum Steuern von Zuweisungen von Ressourcen (20) an Prozesse (4) in erweiterbaren medizinischen Plattformen mit einer zentralen Instanz (5) und einer Meta-Schnittstelle (30) zur Verwaltung von Ressourcen (20) eines Typs, wobei das Verfahren folgende Schritte umfasst: – Empfangen eines Auftrags (1) für einen Prozess (4) durch eine zentrale Instanz (5), wobei der Auftrag (1) gekennzeichnet ist durch einen Auftragstyp (1a); – Zuordnen (7) des Auftrags (1) zu einem Warteschlangenzuweiser (10) in Abhängigkeit des Auftragstyps, – Ermitteln einer Vielzahl von Prozessressourcen (25), die zur Ausführung des Auftrags (1) benötigt werden aus innerhalb der Plattform vorhandenen Ressourcen (20) und Ermitteln eines Warteschlangennamens (17) durch den Warteschlangenzuweiser (10); – Anfragen der Prozessressourcen (25) durch die zentrale Instanz (5) bei der Meta-Schnittstelle (30); – Zuweisen der Prozessressourcen (25) zu dem Auftrag (1), soweit die Prozessressourcen (25) zur Ausführung des Prozesses (4) zur Verfügung stehen, – Ausführen des Auftrags (1) für einen Prozess (4), sofern alle der Prozessressourcen (25) zur Verfügung stehen, wobei die Prozessressourcen (25) nach Abschluss des Prozesses (4) freigegeben werden und die Meta-Schnittstelle (30) informiert wird, so dass ein dead-lock freies Verhalten der Prozesse (4) innerhalb der Plattform gewährleistet wird, wobei im Falle eines Notfallereignisses ein Unterbrechen mindestens eines Auftrages (1) durch das Empfangen einer Benachrichtigung an der zentralen Instanz (5) ausgelöst wird und mindestens ein Prozess (4) angehalten wird bis ausreichend Prozessressourcen (25) zur Notfallbearbeitung verfügbar sind.
Verfahren gemäß Anspruch 1, wobei gleichzeitig mehrere Aufträge empfangen werden können und wobei ferner das gleichzeitige Ausführen mehrerer Prozesse (4) möglich ist, sofern das Zuweisen der jeweiligen Prozessressourcen (25) an eine Vielzahl gleichzeitig ablaufender Prozesse notwendig und möglich ist, wobei die zentrale Instanz (5) Prozesse (4) unterbrechen kann.
Verfahren gemäß Anspruch 1 oder 2, wobei jedem Auftragstyp (1a) eine eigene Warteschlange (10) zugeordnet wird.
Verfahren gemäß Anspruch 1 bis 3, wobei die zentrale Instanz (5) mindestens einen Prozessbearbeiter (40) mit dem Ausführen des Auftrags (1) beauftragt, und der mindestens eine Prozessbearbeiter (40) durch den Auftragstyp (1a) des Auftrags bestimmt ist.
Verfahren gemäß Anspruch 4, wobei der mindestens eine Prozessbearbeiter (40) von der zentralen Instanz (5) gestartet wird.
Verfahren gemäß einem der vorangegangenen Ansprüche, weiter umfassend einen Schritt zum Anhalten eines laufenden Prozessbearbeiters (40), um ein deterministisches Unterbrechen des Prozesses (4) zu gewährleisten.
Verfahren gemäß einem der Ansprüche 1 bis 6, weiter umfassend einen Schritt zum Empfangen einer Warnung durch die zentrale Instanz (5), woraufhin die zentrale Instanz (5) keine weiteren Prozessbearbeiter (40) startet.
Verfahren gemäß Anspruch 7, wobei jeder der innerhalb der Plattform aktiven Prozessbearbeiter (40) angehalten und/oder zum weiteren Bearbeiten wieder freigegeben werden kann.
Verfahren gemäß einem der vorhergehenden Ansprüche 4 mit 8, wobei die zentrale Instanz (5) nach Erhalt einer Benachrichtigung mindestens einen der Prozessbearbeiter (40) anhält.
Verfahren gemäß einem der vorangegangenen Ansprüche, weiter umfassend einen Schritt zum Erweitern der medizinischen Plattform um einen neuen Auftragstyp (1a) zur Ausführung eines neuen Prozesses (4a).
Verfahren gemäß Anspruch 10, wobei das Erweitern der medizinischen Plattform zur Laufzeit dynamisch erfolgen kann.
Verfahren nach einem der vorhergehenden Ansprüche 4 mit 11, wobei der Warteschlangezuweiser (10), der Prozessbearbeiter (40) und die Meta-Schnittstelle (30) unabhängig voneinander realisierbar und veränderbar sind.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Auftrag (1) neben dem Auftragstyp (1a) eine Vielzahl von Auftragsparametern aufweisen kann.
Vorrichtung zur Steuerung von Zuweisungen von Ressourcen (20) an Prozesse (4) in erweiterbaren medizinischen Plattformen, wobei die Vorrichtung Mittel umfasst, die zur Ausführung eines Verfahrens nach einem der vorstehenden Verfahrensansprüche ausgebildet ist und dazu folgendes umfasst: – Eine zentrale Instanz (5) zum Empfang eines Auftrags (1) für einen Prozess (4), wobei der Auftrag (1) gekennzeichnet ist durch einen Auftragstyp (1a); – Einer Meta-Schnittstelle (30) zur Verwaltung von Ressourcen (20) eines Typs; – Einen Warteschlangenzuweiser (10) zur Zuweisung (7) des empfangenen Auftrags (1) zu einer Warteschlange (10) in Abhängigkeit vom Auftragstyp (1a), – Ermittler, der zur Ermittlung einer Vielzahl von Pro zessressourcen (25) bestimmt ist, die zur Ausführung des Auftrags (1) nötig sind aus innerhalb der Plattform vorhandenen Ressourcen (20) und zur Ermittlung eines Warteschlangennamens (17) durch den Warteschlangenzuweiser (10), – Anfragemodul der zentralen Instanz (5), das zur Anfrage nach den Prozessressourcen (25) bei der Meta-Schnittstelle (30) bestimmt ist; – Zuweisungsmodul, das zur Zuweisung der Prozessressourcen (25) zu dem Auftrag (1) bestimmt ist, soweit die Prozessressourcen (25) zur Ausführung des Prozesses (4) zur Verfügung stehen, – Prozessbearbeiter (40), der zur Ausführung des Prozesses (4) bestimmt ist, sofern die Verfügbarkeit aller Prozessressourcen (25) gegeben ist, wobei nach Abschluss des Prozesses (4) die Freigabe der Prozessressourcen (25) sowie eine Information der Meta-Schnittstelle (30) erfolgt, so dass ein dead-lock freies Verhalten der Prozesse innerhalb der Plattform gewährleistet ist, wobei im Falle eines Notfallereignisses ein Unterbrechen mindestens eines Auftrages (1) durch das Empfangen einer Benachrichtigung an der zentralen Instanz (5) ausgelöst wird und mindestens ein Prozess (4) angehalten wird bis ausreichend Prozessressourcen (25) zur Notfallbearbeitung verfügbar sind.
Computerprogramm, geladen in einen Speicher eines Computers und das zur Durchführung des Verfahrens nach einem der Patentansprüche 1 bis 13 ausgebildet ist, wenn das Computerprogramm in dem Computer ausgeführt wird.