DE102011079429A1 - Performancesimulation von medizintechnischen Prozeduren in einer Client-Server-Umgebung - Google Patents

Performancesimulation von medizintechnischen Prozeduren in einer Client-Server-Umgebung Download PDF

Info

Publication number
DE102011079429A1
DE102011079429A1 DE102011079429A DE102011079429A DE102011079429A1 DE 102011079429 A1 DE102011079429 A1 DE 102011079429A1 DE 102011079429 A DE102011079429 A DE 102011079429A DE 102011079429 A DE102011079429 A DE 102011079429A DE 102011079429 A1 DE102011079429 A1 DE 102011079429A1
Authority
DE
Germany
Prior art keywords
client
simulation
application
clients
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE102011079429A
Other languages
English (en)
Inventor
Edgar Maass
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens Healthcare GmbH
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE102011079429A priority Critical patent/DE102011079429A1/de
Priority to US13/552,173 priority patent/US9286124B2/en
Publication of DE102011079429A1 publication Critical patent/DE102011079429A1/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/503—Resource availability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Die Erfindung betrifft ein Verfahren, ein System, zur Simulation einer Performance einer medizintechnischen Prozedur (P), die die Ausführung einer Vielzahl von Applikationen (A) umfasst, wobei die Applikationen (A) in einer Multi-Client-Umgebung parallel auf mehreren Clients (C) ausgeführt werden sollen. Die Simulation basiert auf der Ausführung der Applikation (A) in einer Single-Client-Umgebung. Dabei werden Ausführungszeit und Ressourcenbedarf gemessen und der Simulation als Eingangsgrößen zugeführt. Als Ausgabe der Simulation werden eine Latenz für die Ausführungszeit und der Ressourcenbedarf für die Ausführung in der Multi-Client-Umgebung ausgegeben.

Description

  • Die vorliegende Erfindung liegt auf dem Gebiet der Medizintechnik und betrifft die Problemstellung, eine Vorhersage über die Leistungsfähigkeit und Ausführbarkeit von Computerbasierten Prozessen zu ermöglichen, die in einer Vielzahl von Computer-basierten Applikationen in einer Client-Server-Umgebung implementiert sind mit unterschiedlichen Anforderungen und unterschiedlichen Ressourcen. Die Erfindung hat somit medizininformatischen Hintergrund und betrifft neben der Medizintechnik auch das Gebiet der Informationstechnologie und bezieht sich insbesondere auf ein Verfahren und ein Client-Server-System zur Vorhersage bzw. zur Simulation einer Performance einer mehrschichtigen, medizintechnischen Prozedur in einer Multi-Client-Umgebung.
  • Nicht zuletzt aufgrund des Kostendrucks werden bei modernen, medizintechnischen Systemen heutzutage möglichst viele Prozeduren durch den Einsatz von Computerimplementierungen automatisiert. Medizintechnische Prozeduren, beispielsweise in der medizinischen Bildverarbeitung, basieren in der Regel auf einer Abfolge von Schritten oder Applikationen. Zur Erstellung eines Befundes muss beispielsweise zunächst eine Bildserie geladen werden, relevante Bilder müssen aus der Bildserie ausgewählt und vergrößert werden und es müssen medizinische Messungen auf dem Bild vorgenommen werden (zum Beispiel zur Bestimmung des Volumens eines Tumors). Diese Schritte werden durch die Ausführung von teilweise unterschiedlichen Applikationen implementiert. Das eben erwähnte Beispiel ist stark vereinfacht und soll nur auf schematische Weise die – für den Endanwender in der Regel verdeckt ablaufenden – informationstechnologischen Hintergrundprozesse erläutern. Ein anderes Beispiel ist in der Steuerung von Bauteilen eines komplexen medizinischen Gerätes, wie zum Beispiel eines Computertomographen. Üblicherweise sind zur Steuerung eines Computertomographen oder einer Magnetresonanzanlage Steuerungsapplikationen vorgesehen, die aufgrund von Umgebungsparametern, patientenspezifischen Parametern und weiteren Eingangsgrößen eine automatische Voreinstellung der Anlage vornehmen. Hierzu zählen beispielsweise die Steuerung des Lagerungstisches, die Positionierung von Registrierungssystemen (Kamera, Markersysteme etc.). Diese Voreinstellungen werden in der Regel vollautomatisch (d. h. ohne Benutzerinteraktion) ausgeführt. Je nach Gerät und medizinischer Einrichtung können auch parallel mehrere Untersuchungsgeräte betrieben und gesteuert werden. Neuerdings werden dabei die medizintechnischen Applikationen als Client-Server-Applikation ausgelegt. Deren Performance kann mit dem erfindungsgemäßen Vorschlag im Vorfeld simuliert, überwacht und gesteuert werden.
  • Gerade auf dem Gebiet der Medizintechnik ist es unerlässlich, sicherzustellen, dass die beteiligten Applikationen eine ausreichende Performance bzw. Leistungsfähigkeit aufweisen, um beispielsweise Notfallszenarien durchführen zu können. So muss es beispielsweise sicher gewährleistet sein, dass die Untersuchung eines Patienten zur Vorbereitung einer Notoperation möglich ist. Dafür müssen wiederum die informationstechnologischen Grundlagen geschaffen sein. Alle Applikationen müssen in einer maximal zulässigen Ausführungszeit mit den notwendigen Ressourcen (zum Beispiel Bandbreite des Netzwerks, Speicherressourcen, CPU-Auslastung, etc.) ausgeführt werden können.
  • Dafür ist es wiederum wichtig, das Verhalten der beteiligten Clients und des Servers vorherzusagen, wobei die unterschiedlichen Clients unterschiedliche Anforderungen an Ressourcen auf dem Server haben. Für die Konfiguration des Systems ist es weiterhin wichtig, eine Aussage darüber zu treffen, ab welcher Anzahl von Clients, die möglicherweise parallel auf Applikationen zugreifen, die auf dem Server liegen, zu einer Verlangsamung der Abläufe bzw. der medizintechnischen Prozedur kommt. Falls eine solche Verzögerung festgestellt wird, ist es weiterhin wichtig zu wissen, wodurch die Verzögerung hervorgerufen wurde, um mögliche Gegenmaßnahmen ergreifen zu können.
  • Im Stand der Technik war es zur Lösung dieser Fragen bekannt, Tests in dem Client-Server-Umfeld durchzuführen, die den Einsatz von Testingenieuren und manuell konfigurierten Testprozeduren erforderten. Nachteiligerweise war die Durchführung dieser Tests umständlich, zeitaufwändig und kostenintensiv. Deshalb wurden automatisierte Tests eingeführt, in denen bestimmte typische Fehlerszenarien zur Überprüfung der medizintechnischen Prozeduren auf Fehlerfreiheit modelliert wurden. Es liegt auf der Hand, dass die Implementierung dieser automatisierten Tests sehr aufwändig ist, da die Qualität dieser automatisierten Tests stark von der Güte der Modellierung der realen Client-Server-Umgebung abhängt. In diesem Zusammenhang ist zu berücksichtigen, dass das medizinische Umfeld sehr variabel ist und flexible Umgebungsparameter hat mit extremen Anforderungen an die Qualität. Dies stellt sehr hohe Anforderungen an die Durchführung von automatisierten Tests.
  • Die vorliegende Erfindung hat sich zur Aufgabe gestellt, die vorstehend erwähnten Probleme zu lösen und einen Ansatz bereitzustellen, mit dem die Konfiguration der informationstechnischen Grundlagen verbessert und verkürzt werden kann. Insbesondere soll in der realen Multi-Client-Umgebung eine Planungsaussage (Vorhersage) über die Performance des gesamten Systems möglich sein. Die Erfindung kann für die Auslegung eines medizintechnischen Systems und/oder für das Testen des medizintechnischen Systems vor oder während der Inbetriebnahme oder bei etwaigen Änderungen am System eingesetzt werden. Es sollen insbesondere Aussagen möglich sein, wie sich das gesamte System hinsichtlich Zeitbedarf und Ressourcenbedarf verhält, wie sich ein bestimmter Client im System verhält, wie viele Clients parallel aktiv sein dürfen, bevor es zu einer Überschreitung einer maximal zulässigen Ausführungszeit kommt, welche Ressourcen auf dem Server bereitgestellt werden müssen, um die angeschlossenen Clients zu bedienen. Falls sich herausstellt, dass bestimmte maximal zulässige Schwellenwerte (etwa hinsichtlich Ausführungszeit oder Ressourcenbedarf) überschritten werden, soll eine Analyse durchführbar sein, um den Grund der Schwellenwertüberschreitung angeben zu können. Darüber hinaus ist zu berücksichtigen, dass die medizintechnische Prozedur eine Abfolge von unterschiedlichen, mehrschrittigen Applikationen erfordert. Diese Abfolge ist nicht festgelegt und kann unter bestimmten Umständen variieren. Wünschenswert ist es deshalb auch, einen Ansatz bereitzustellen, mit dem eine Aussage über die Performance des Gesamtsystems erhalten werden kann, wobei die unterschiedlichen Abfolgen von Applikationen (und jeweils deren Auswirkung auf das technische Verhalten des Gesamtsystems) berücksichtigt werden.
  • Diese Aufgabe wird durch die beiliegenden nebengeordneten Patentansprüche gelöst, die auf ein Verfahren, auf ein System und auf ein Computerprogrammprodukt (das auch den Schutz als Speichermedium umfasst) gerichtet sind.
  • Ein Aspekt der Erfindung betrifft ein Verfahren zur Simulation einer Performance zumindest einer medizintechnischen Prozedur, die eine Ausführung einer Vielzahl von Client-Serverbasierten Applikationen umfasst, wobei die Applikationen in einer Multi-Client-Umgebung mitunter auch parallel auf mehreren Clients ausgeführt werden sollen. Das Verfahren umfasst zumindest folgende Verfahrensschritte:
    • – Ausführen der medizintechnischen Prozedur mit den als erforderlich erfassten Applikationen auf einem Referenz-Client mit bestimmten Referenz-Ressourcen in einer Single-Client-Umgebung;
    • – Messen einer tatsächlich benötigten Ausführungszeit und Erfassen der Referenz-Ressourcen bei Ausführung der erforderlichen Applikationen in der Single-Client-Umgebung;
    • – Bestimmen der Clients der Multi-Client-Umgebung, bedarfsweise mit deren Ressourcen;
    • – Simulation der Performance der medizintechnischen Prozedur in der Multi-Client-Umgebung, indem die bestimmten Ressourcen der parallel ausführenden Clients der Multi-Client-Umgebung mit der gemessenen tatsächlichen Ausführungszeit und mit den erfassten Referenz-Ressourcen der Single-Client-Umgebung in einer zweifachen Iteration verrechnet werden, umfassend eine erste Iteration über die Zeit hinsichtlich eines ermittelten Ressourcenbedarfes auf jeweils einem Client und eine zweite Iteration über die bestimmten Clients durch Addition der ermittelten Ressourcenbedarfe in jeweils einem Zeitintervall;
    • – wobei bei der Verrechnung und/oder im Rahmen der Simulation geprüft wird, ob auf einem Server ausreichend Ressourcen vorhanden sind, um in jeweils einem Zeitintervall auszuführende Applikationsschritte der Applikation ausführen zu können.
  • Im Folgenden wird die Erfindung anhand der verfahrensgemäßen Lösung beschrieben. Hierbei erwähnte Vorteile, Merkmale und/oder alternative Ausführungsformen sind ebenso auch auf die anderen Implementierungen der Erfindung zu übertragen und somit auf das System, das Computerprogrammprodukt und das Speichermedium anzuwenden. Dabei sind entsprechende funktionale Merkmale des Verfahrens durch gegenständliche Module de Systems gelöst, die mit der jeweiligen Funktionalität belegt sind. Dasselbe gilt auch umgekehrt, sodass auch Merkmale, die im Zusammenhang mit dem System erwähnt sind, ebenso auf das Verfahren zu übertragen sind. Unter Schutz gestellt werden soll neben einer Implementierung in Hardware auch eine Softwareimplementierung, die teilweise auf Hardwarebauteile und/oder auf anderweitige Bauteile des medizintechnischen Systems (zum Beispiel bildgebende Anlagen, Steuerungssysteme, etc.) zugreift oder aufsetzt.
  • Im Folgenden werden die im Rahmen dieser Anmeldung verwendeten Begrifflichkeiten näher erläutert.
  • Der Begriff "Simulation" kennzeichnet eine Computer-basierte Vorhersage einer Performance einer medizintechnischen Prozedur. Die Simulation erfolgt vorzugsweise vollautomatisch und Computer-basiert. Sie umfasst ein Berechnen von Ausführungszeiten und von erforderlichen Ressourcen. Wie der Begriff "Simulation" nahe legt, ist es erfindungsgemäß nicht notwendig, die zu untersuchende medizintechnische Prozedur in der zu testenden, realen (Multi-Client) Umgebung tatsächlich auszuführen, sondern eine Aussage über die Performance der medizintechnischen Prozedur kann bereits vor realer Ausführung derselben in der Multi-Client-Umgebung abgeleitet werden. Die Ausführung der medizintechnischen Prozedur in der zu testenden Umgebung wird also vor deren Ausführung simuliert. Die Prozedur wird lediglich in einer Referenzumgebung ausgeführt. Die Referenzumgebung ist insbesondere eine Single-Client-Umgebung.
  • Bei der medizintechnischen Prozedur handelt es sich um einen medizintechnischen Workflow, der in der Regel mehrere Schritte umfasst. Der Inhalt der jeweiligen Prozedur ist für die Ausführung des Erfindungskonzeptes in Wesentlichen unerheblich. Vorzugsweise sollen hier aber Steuerungsaufgaben simuliert werden, die in den Ablauf einer medizintechnischen Anlage eingebettet sind. Beispielsweise zählen hierzu Konfigurations- und Steuerungsprozeduren für medizinische Apparate und Geräte oder Prozeduren im Rahmen der medizintechnischen Bildverarbeitung (zum Beispiel das Laden oder Speichern von umfangreichen Bilddatenserien im DICOM-Format). Üblicherweise können einzelne Arbeitsschritte der Prozedur hinsichtlich ihrer Abfolge variiert werden, während andere Schritte der Prozedur jeweils einen festgelegten Ausführungszeitpunkt erfordern. Dies wird bei der erfindungsgemäßen Simulation berücksichtigt. Auch ist es möglich, dass die Prozedur einen hierarchischen Aufbau von einzelnen Prozedurschritten umfasst – auch dies wird bei der erfindungsgemäßen Simulation berücksichtigt. Alle möglichen Variationen hinsichtlich der medizintechnischen Prozedur (zum Beispiel alternative Arbeitsschritte und/oder eine andere Abfolge von Arbeitsschritten der Prozedur) können bei der Simulation berücksichtigt werden, um ein anderes Ergebnis hinsichtlich der Performance ableiten zu können. Je nach Umgebung wird die medizintechnische Prozedur auch „Workflow“ genannt.
  • Das „Bestimmen der Clients“ der Multi-Client-Umgebung umfasst vorzugsweise das Bestimmen einer maximal möglichen Anzahl der Clients der Multi-Client-Umgebung, bedarfsweise mit deren Ressourcen. Das heißt, dass in der bevorzugten Ausführung der Erfindung im Vorfeld (vor der Simulation) – z.B. durch eine Benutzereingabe – festgelegt wird, wie viele Clients maximal gleichzeitig zur Ausführung der Applikation berechtigt sein sollen. In einer Weiterbildung umfasst das „Bestimmen der Clients“ auch die Bestimmung, welche Clients (mit welchen technischen Parametern und Ressourcen) der Multi-Client-Umgebung zugeordnet werden sollen, um automatisch deren technische Ressourcen ermitteln zu können.
  • Üblicherweise ist die Applikation Computer-basiert oder vollständig Computerapplikation implementiert. Die Applikation ist in der Regel für ein Client-Server-System ausgelegt und kann Server-seitige und Client-seitige Module umfassen. Die Server-seitigen Module laufen auf dem Server ab, während die Client-seitigen Module lokal auf dem Client ablaufen oder diesen zugeordnet sind. Der Client greift zum Ausführen der Applikation auf die serverseitigen Module der Applikation zu, wobei die Applikation für eine Multi-Client-Umgebung ausgelegt ist. Dies bedeutet, dass eine Applikation auch parallel auf mehreren Clients ausgeführt werden kann. Beispielsweise ist es im Rahmen der medizinischen Bildverarbeitung im klinischen Alltag häufig notwendig, mehrfach auf medizinische Bilddaten zuzugreifen (zum Beispiel zur Steuerung eines Ablaufs oder einer Patientenuntersuchung oder zur Konfiguration eines Gerätes oder zur Erstellung einer patientenspezifischen Diagnose). Der Zugriff auf die jeweiligen Bilddaten wird üblicherweise über eine Lade-Applikation (load application) durchgeführt. Dabei soll es möglich sein, dass derselbe Bilddatensatz von einer ersten Arbeitsstation und gleichzeitig von weiteren Arbeitsstationen angefragt wird, sodass diese Arbeitsstationen parallel die entsprechende „load application“ ausführen. Je nachdem, wie viele Clients und unter welchen Bedingungen diese auf die jeweilige Applikation zugreifen, hat dies unterschiedliche Auswirkungen auf die Leistungsfähigkeit der Applikation und auch unterschiedliche Anforderungen an den Server-seitigen Teil der Applikation und an den Server selbst (zum Beispiel hinsichtlich Ressourcen, Speicherbedarf und Verarbeitungsgeschwindigkeit, Übertragungskapazität etc.). Hier setzt die Erfindung an, um unterschiedliche Szenarien im Vorfeld testen zu können und zu messen. Insbesondere soll im Vorfeld die Vorhersage einer Performance der Applikation ermittelt werden, die sozusagen als "Belastungstest" dient. Mit der Durchführung dieser Simulation kann festgestellt werden, unter welchen Anwendungsbedingungen die medizintechnische Prozedur mit den jeweiligen Applikationen fehlerfrei (zum Beispiel ohne Engpass) ausführbar ist. Dazu wird eine simulierte Ausführungszeit (die auf einer gemessenen Ausführungszeit in einer Single-Client-Umgebung basiert) mit einer maximal zulässigen Schwellenwertausführungszeit verglichen. Bei Überschreiten der letzteren wird fakultativ ein Warnsignal ausgegeben, der auf eine nicht zulässige Verzögerung der Ausführungszeit hinweist. Bedarfsweise kann eine Analyse für den Engpass berechnet werden. Grundsätzlich ist der Inhalt der jeweiligen Applikation für die Idee der vorliegenden Erfindung ohne Belang. Die Applikation kann eine Benutzerschnittstelle umfassen, über die der Anwender Eingaben zur Ausführung der Applikation tätigen kann. Andernfalls kann die Applikation auch vollautomatisch ausführbar sein. Die Applikation dient in einer bevorzugten Ausführung zur Steuerung einer medizintechnischen Anlage (zum Beispiel eines Magnetresonanztomographen etc.) und ist in den Ablauf der technischen Einrichtung eingebettet. Alternativ dient die Applikation zur Erfassung von Messwerten (zum Beispiel Laborwerten). In einer weiteren Variante der Erfindung dient die Applikation zur Erfassung von patientenspezifischen Messwerten oder untersuchungsspezifischen Messwerten, die über physikalische Sensoren erfasst und elektronisch weiterverarbeitet werden (zum Beispiel Temperatursensoren, Lagesensoren, Positionssensoren, Bewegungssensoren, medizinische Messwerte, etc.).
  • Erfindungsgemäß wird zwischen zwei unterschiedlichen Anwendungsszenarien bei der Ausführung der Applikation unterschieden:
    • – eine Single-Client-Umgebung; dies bedeutet, dass die jeweilige Applikation auf jeweils nur einem einzelnen Client (dem sogenannten Referenz-Client) ausgeführt wird;
    • – eine Multi-Client-Umgebung, bei der die Applikation parallel auf mehreren Clients ausgeführt wird. Dabei können die Clients von derselben Art oder unterschiedlicher Art sein (zum Beispiel über unterschiedliche Ressourcen verfügen). Auch ist es möglich, dass der Startpunkt für die Ausführungszeit auf den Clients nicht identisch ist, sondern sich die Ausführungszeiten auf den unterschiedlichen Clients in zeitlicher Hinsicht nur überlappen. Dies führt zu unterschiedlichen Anforderungen an die Applikation und an die informationstechnologische Plattform.
  • Ein wesentlicher Aspekt der Erfindung liegt in der Idee, dass die Applikation zunächst lediglich in der Single-Client-Umgebung auf nur einem Referenz-Client ausgeführt wird, von dem die Referenzressourcen bekannt sind. Bei dieser Ausführung werden die Ausführungszeit und/oder der Ressourcenbedarf auf dem Server gemessen. Alternativ können noch weitere ausführungsbezogene Parameter erfasst werden (zum Beispiel Zeit der Speicherzugriffe, Anzahl der parallel auszuführenden Zugriffe etc.). Nach Ausführung der Applikation in der Single-Client-Umgebung werden die gemessene tatsächlich benötigte Ausführungszeit und die erfassten/gemessenen Ressourcen des Referenz-Clients als Eingangsgrößen für die Simulationsberechnung zugeführt. Darüber hinaus wird bestimmt, welche Clients in der Multi-Client-Umgebung aktiviert werden sollen (auf welchen Clients also die Applikation parallel ausführbar sein soll). Auch diese Größen werden als Eingangsgrößen für die Simulationsberechnung weitergeleitet.
  • Nach dem Erfassen aller Eingangsgrößen kann unmittelbar oder zu einem späteren Zeitpunkt das Simulationsmodul gestartet werden, das zur Ausführung der Simulation der Performance der medizintechnischen Prozedur in der Multi-Client-Umgebung ausgelegt ist. Dies wird ausgeführt, indem – vorzugsweise im Vorfeld – eine Taktfrequenz festgelegt wird.
  • Die Taktfrequenz entspricht somit einem Zeitintervall (zum Beispiel 0,2 Sekunden), in dem einzelne Applikationsschritte der Applikation ausgeführt werden können. Die Taktfrequenz stimmt damit üblicherweise nicht mit der Taktfrequenz des Prozessors oder der Prozessoren bei einem Multicore-System überein, sondern bezieht sich vielmehr auf die Ausführungszeit eines einzelnen Applikationsschrittes einer Applikation. Damit ist der Vorteil verbunden, dass die Simulation sehr zielgerichtet und effizient auf die zu testende Applikation zugschnitten werden kann und z.B. nicht zu kurze Intervalle vorsieht, in denen aufgrund des Prozedurablaufs keine Veränderung auftritt.
  • In einer bevorzugten Ausführungsform der Erfindung ist es vorgesehen, dass in einer Vorbereitungsphase die Applikation einem Parser zugeführt wird, der dazu bestimmt ist, die Applikation in einzelne Applikationsschritte bzw. Aktionen zu zerlegen. Üblicherweise werden die Aktionen auf dem Client und/oder auf dem Server ausgeführt. Selbstverständlich gibt es hier Variationsmöglichkeiten hinsichtlich der Abfolge der auszuführenden Applikationsschritte. Diese werden vorzugsweise bei der Simulation berücksichtigt. So kann beispielsweise ein erstes Simulationsergebnis für eine erste Abfolge von Applikationsschritten erarbeitet werden und mit einem zweiten Ergebnis für eine weitere (andere) Abfolge von Applikationsschritten hinsichtlich der Auswirkungen auf die Performance verglichen werden. Vorzugsweise ist also die Abfolge von Applikationsschritten konfigurierbar und/oder vorbestimmt.
  • Nach Ausführung des Parser-Moduls ist es sichergestellt, dass es die Applikation in Applikationsschritte unterteilt werden kann, in denen der Ressourcenbedarf ermittelt wird. Selbstverständlich kann auch die Ausführungszeit einer einzelnen Aktion (Applikationsschritt) berechnet werden. Durch die Ausführung der Applikation in der Single-Client-Umgebung ist es nun möglich, Eingangsgrößen für den Simulationsvorgang zuzuführen. Diese Eingangsgrößen umfassen die Ausführungszeit der einzelnen Applikationsschritte auf dem jeweiligen Client und/oder der jeweilige Ressourcenbedarf auf dem Server und/oder dem jeweiligen Client, also dem Referenz-Client. Von dem Referenz-Client ist es im Vorfeld bekannt, über welche technischen Ressourcen er verfügt (zum Beispiel Hauptspeicher, Datenübertragungskapazität etc.).
  • Vorzugsweise wird die Simulation durch ein Simulationsmodul ausgebildet. Das Simulationsmodul basiert auf einer Vorkonfiguration, die es vorsieht, dass die einzelnen Arbeitsschritte auf den Clients in einer Abfolge ausgeführt werden, die mittels eines Zufallsgenerators ermittelt wird. Alternativ kann hier auch eine vorkonfigurierbare Ausführungsabfolge von Applikationsschritten voreingestellt sein. Das Simulationsmodul kann aufgrund der ihm übermittelten Eingangsgrößen für jeden Simulationsschritt bzw. für jede Taktfrequenz bestimmen, wie hoch der Ressourcenbedarf ist.
  • Die Simulation umfasst eine zweifache Iteration, eine erste Iteration über die Taktfrequenz bzw. über die Simulationsschritte und eine zweite Iteration über die beteiligten Clients (in der Multi-Client-Umgebung). Dabei ist es vorgesehen, dass der Ressourcenbedarf der beteiligten Clients für jeweils ein Zeitintervall addiert wird. Somit kann insgesamt als Ergebnis der Simulation der Performance eine Entwicklung über die Ausführungszeit und/oder über den Ressourcenbedarf der einzelnen Clients jeweils im Verhältnis zu jedem einzelnen Applikationsschritt bzw. zur Taktfrequenz ermittelt werden. Das Ergebnis wird vorzugsweise in Form einer Graphik dargestellt, die auf einer Benutzeroberfläche angezeigt wird. Hier gibt es unterschiedliche Möglichkeiten. Zum einen ist es möglich die unterschiedlichen Simulationsparameter in eine Graphik zu integrieren, sodass Ausführungszeiten und Ressourcenbedarf über die Zeit aufgetragen werden. Alternativ ist es möglich, das Ergebnis auf unterschiedlichen Fenstern anzuzeigen und beispielsweise in einem Fenster lediglich die Speicherauslastung über die Zeit (Taktfrequenz) anzuzeigen und in einer weiteren Graphik die Ausführungszeit und/oder die Verzögerungen der Ausführungszeit in Bezug auf eine Anzahl von Clients aufzuzeichnen. Üblicherweise werden die gesamte Ausführungszeit und auch die Verzögerung hinsichtlich der Ausführungszeit mit der Anzahl der Clients steigen. Der Anstieg erfolgt jedoch nicht linear. In alternativen Ausführungsformen können hier noch andere technische Parameter zur Anzeige gebracht werden, wie beispielsweise Hardwareparameter, die eine bestimmte Hardwarekonfiguration des Clients und/oder des Servers umfassen, wie zum Beispiel verfügbarer Hauptspeicher, externer Speicher, Taktfrequenz, Anschluss von Coprozessoren etc.
  • Im Rahmen der Simulation wird für jeden einzelnen Simulationsschritt geprüft, ob genügend Ressourcen auf dem Server vorhanden sind, um den einzelnen Applikationsschritt durchführen zu können oder nicht. Falls genügend Ressourcen vorhanden sind, wird davon ausgegangen, dass der Applikationsschritt ohne Verzögerung ausgeführt wird. Andernfalls berechnet das Simulationsmodul eine Verzögerungszeit bei der Ausführung des jeweiligen Applikationsschrittes ein.
  • Am Ende der Simulation wird ausgegeben, wie hoch die Latenz der Ausführungszeit war. Dabei ist besonders zu berücksichtigen, dass die Verzögerung bzw. Ausführungslatenz unterschiedlichen Bezugsgrößen zugeordnet werden kann. Zum einen ist es möglich, die Verzögerung jeweils pro Applikationsschritt auszugeben. Zum anderen ist es möglich, die Verzögerung jeweils pro Client auszugeben. Selbstverständlich sind hier auch Kombinationen oder weitere Bezugsgrößen denkbar. Des Weiteren wird als Ergebnis der Simulation ausgegeben, welche Ressource oder welche Ressourcenkombination die Verzögerung verursacht hat (zum Beispiel Hauptspeicher, Prozessor, etc.). Damit wird eine Analyse von Fehlerzuständen bereits im Vorfeld möglich. Aufgrund der ausgegebenen Werte der Simulation können noch weitere Analysen durchgeführt werden. Beispielsweise kann geprüft werden, ob sich die Ausführungszeit oder der Ressourcenbedarf verbessert, falls die Anzahl der Client reduziert wird, oder falls Hardwareparameter modifiziert werden.
  • In einer bevorzugten Ausführungsform ist es vorgesehen, vorkonfigurierbare Schwellenwerte zu bestimmen, die auf Einhaltung mit den in der Simulation berechneten Simulationswerten verglichen werden. So kann beispielsweise eine mittlere Verzögerungszeit eingestellt werden und die Abweichungen der simulierten Ausführungszeit können mit dieser mittleren Verzögerungszeit verglichen werden. Darüber hinaus ist es möglich, eine maximale Ausführungszeit zu bestimmen, wobei die mittels der Simulation berechneten simulierten Ausführungszeiten mit den Schwellenwerten verglichen werden. Die Schwellenwertausführungszeiten können sich zum Einen auf eine gesamte Ausführungszeit oder zum Anderen auf die Ausführungszeit von einzelnen Applikationsschritten beziehen. Damit kann eine fein granulierte Aussage über das Verhalten der Client-Server-Applikation bzw. der Client-Server-basierten medizintechnischen Prozedur abgeleitet werden (dabei ist die Granularität der Aussage konfigurierbar).
  • Das erfindungsgemäße System umfasst somit eine Verrechnung der Eingangsgrößen, bei der geprüft wird, ob auf dem Server oder der Servergruppe ausreichend Ressourcen vorhanden sind, um in jeweils einem Zeitintervall (Simulationsschritt) die auszuführenden Applikationsschritte der Applikation der medizintechnischen Prozedur ausführen zu können. Die Verrechnung erfolgt vorzugsweise vollautomatisch, sodass es nicht notwendig ist, dass der Anwender Eingaben über eine Benutzerstelle tätigt. Alternative Ausbildungen sehen hier eine Benutzerschnittstelle vor, über die der Anwender Parameter zur Konfiguration eingeben kann, die daraufhin bei der Simulation berücksichtigt werden. Üblicherweise wird das Ergebnis der Simulation auf einer Benutzeroberfläche ausgegeben; dies erfolgt insbesondere graphisch. Bedarfsweise können hier auch noch weitere Fenster geöffnet werden, in denen beispielsweise Warnhinweise ausgegeben werden, falls voreingestellte Schwellenwerte überschritten oder unterschritten werden.
  • In einer bevorzugten Ausführungsform dient das Verfahren zur Simulation der Performance und umfasst damit alle Parameter, die eine Leistungsfähigkeit der Client-Server-Applikation kennzeichnen. In einer einfachen Ausführungsform handelt es sich dabei zumindest um die Ausführungszeit. Optional können noch technische Ressourcen berücksichtigt werden. Die technischen Ressourcen können sich dabei sowohl auf die Clientseitigen Anteile der Applikation und/oder auf die Serverseitigen Anteile der Applikation beziehen. Darüber hinaus können die Ressourcen folgende Parameter umfassen:
    • – CPU-Auslastung
    • – Speicherbedarf
    • – Input-/Output-Netzwerkbedarf
    • – Input-/Output-Plattenzugriffe
    • – Grafikkartenzugriffe
    • – Zugriffe auf externe Applikationen und/oder Ressourcen.
  • An dieser Stelle sei jedoch darauf hingewiesen, dass es für einen Fachmann auf der Hand liegt, hier noch weitere technische Parameter zu berücksichtigen. Dabei ist darauf hinzuweisen, dass es sich bei diesen Parametern eindeutig um technische Parameter handelt, die entweder auf die Hardware der informationstechnischen Plattform bezogen sind (wie zum Beispiel Plattenzugriffe, Netzwerkbandbreite, etc.) oder auf einer unteren Schicht des ISO-OSI-Schichtenprotokolls angeordnet sind. In einer komplexeren Ausführungsform können hier auch technische Parameter der medizintechnischen Geräte umfasst sein, wie zum Beispiel Positions- oder Bewegungsparameter etc., deren Werte über physikalische Sensoren gemessen werden.
  • In einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens umfasst das Ergebnis der Simulation auch eine Aussage über die Latenz, also über die Verzögerungszeit, bei der Ausführung der medizintechnischen Prozedur in der Multi-Client-Umgebung.
  • In einer weiteren Variante der Erfindung umfasst das Ergebnis des Simulationsverfahrens zusätzlich eine Aussage über mögliche Fehlerquellen bzw. über die Fehleranfälligkeit bei der Ausführung in der Multi-Client-Umgebung. Ein besonderer Vorteil ist darin zu sehen, dass automatisch mögliche Fehlerursachen im Vorfeld indiziert werden können. So kann beispielsweise noch vor dem Einsatz in der Praxis festgestellt werden, dass die Festplatte der Engpass ist und bei der geplanten Auslegung der Client-Server-Struktur schwerwiegende Fehler durch diesen Engpass hervorgerufen werden. Deshalb kann mit Hilfe dieser Erfindung bereits im Vorfeld gezielt investiert oder gezielte Änderungen können vorgenommen werden, um die Performance zu verbessern.
  • Ein wesentliches Merkmal der Erfindung ist darin zu sehen, dass die jeweilige Applikation auf dem Referenz-Client ausgeführt wird, der als Single-Client-Umgebung dient. Dabei ist es wesentlich, dass die technischen Parameter des Referenz-Clients und mit seinen Anforderungen an den Ressourcenbedarf auf dem Server bekannt sind, damit die gemessene Ausführungszeit auch den jeweiligen Parametern des Clients zugeordnet werden können, um bei der Simulation berücksichtigt zu werden. Üblicherweise umfasst das Verfahren die Ausführung der Applikation auf einem Referenz-Client. Selbstverständlich kann hier auch eine Gruppe oder ein Grid von Referenz-Clients vorgesehen sein, deren technische Ressourcen bekannt sind.
  • Wie vorstehend bereits erwähnt, kann als Ergebnis des Simulationsverfahrens nicht nur eine Ausführungszeit bzw. Verzögerungszeit bei der Ausführung von der Multi-Client-Umgebung ausgegeben werden. Alternativ kann zusätzlich auch noch der Ressourcen-Bedarf in vorkonfigurierbaren Zeitintervallen ermittelt werden. Dabei ist der Simulationsschritt die kleinste wählbare Zeiteinheit.
  • In einer bevorzugten Ausführungsform wird bei Feststellung von unzulässigen Verzögerungszeiten oder bei Feststellung von nicht vorhandenem Ressourcenbedarf ein weiterer Analyseschritt ausgeführt. Dieser Analyseschritt umfasst eine Analyse hinsichtlich möglicher Fehlerquellen. Darüber hinaus können sich noch weitere statistische Auswertungen anschließen, etwa um gezielter festzustellen, durch welche Ressource oder welchen Ressourcengruppe der Engpass verursacht worden ist und ob dieser Engpass bereits in früheren Simulationsdurchläufen als Fehlerquelle erfasst worden ist. Des Weiteren kann eine allgemeine statistische Auswertung der beteiligten möglichen Fehlerquellen ausgegeben werden.
  • Eine vorteilhafte, komplexere Ausbildung der Analyse umfasst zugleich einen Vorschlag zur Performanceverbesserung, falls eindeutig eine Fehlerursache identifiziert werden konnte. Beispielsweise kann der Vorschlag eine Erweiterung der technischen Ressourcen oder der Kapazität des Clients und/oder des Servers umfassen.
  • Gemäß einem weiteren Aspekt umfasst die Applikation eine bestimmte Sequenz bzw. Abfolge von Applikationsschritten, die mitunter veränderlich ist. Ein besonderer Vorteil der Simulation ist nun darin zu sehen, dass die Simulation unterschiedliche Abfolgen von Applikationsschritten berücksichtigt, sodass beispielsweise festgestellt werden kann, dass sich die Applikation mit der Abfolge der Schritte A, B, C als besser performant erweist als bei der Abfolge der Schritte B, A, C.
  • Ein weiterer Aspekt der Erfindung ist darin zu sehen, dass für die Ausführung der medizintechnischen Prozedur seinerseits wiederum unterschiedliche Applikationen in unterschiedlicher Reihenfolge ausführbar sind. So kann auch die medizintechnische Prozedur in der Abfolge der Applikationen A1, A2, A3 ausgeführt werden und beispielsweise in der Abfolge A2, A1, A3. Auch hier ist der Vorteil des Simulationsverfahrens darin zu sehen, dass auch unterschiedliche Abfolgen von Applikationen bei der Simulation der medizintechnischen Prozedur berücksichtigt werden können.
  • Gemäß einem Aspekt kann die Dauer des Zeitintervalls für einen Simulationsschritt im Vorfeld konfiguriert werden. Damit ergibt sich der Vorteil, dass das Simulationsverfahren eher feinmaschig oder grobmaschig mit unterschiedlicher Granularität ausgeführt werden kann. Durch die hierarchische Strukturierung einer medizintechnischen Prozedur in unterschiedliche Folgen von Applikationen und die Strukturierung einer jeweiligen Applikation in unterschiedliche Abfolgen von Applikationsschritten und deren jeweilige Berücksichtigung bei dem Simulationsprozess kann die Simulation sehr flexibel gehalten werden.
  • Gemäß einem Aspekt der Erfindung umfasst das Verfahren zumindest folgende Eingangsgrößen als Input:
    • – Die medizinische Prozedur mit den erforderlichen Applikationen
    • – Eine Abfolge von Applikationsschritten der erforderlichen Applikation
    • – Eine Anzahl der die Applikation parallel ausführenden Clients in der Multi-Client-Umgebung
    • – Ressourcen der Clients und des Servers in der Multi-Client-Umgebung
    • – Gemessene Ausführungszeit und gemessene bzw. bestimmte Ressourcen bei Ausführung der Applikation in der Single-Client-Umgebung und
    • – Dauer eines Zeitintervalls (Simulationsschritt) und optional
    • – Ein maximaler Schwellenwert für die Ausführungszeit der medizintechnischen Prozedur. Selbstverständlich können auch einzelne Schwellenwerte für die Ausführung der einzelnen Applikationen bestimmt werden.
  • Gemäß einem weiteren Aspekt der Erfindung umfasst das Verfahren zumindest folgende Ausgangsgrößen als Output, die bedarfsweise den Applikationsschritten der Applikation zugeordnet werden können:
    • – Alle oder ausgewählte Eingangsgrößen als Information für den User (optional)
    • – Eine simulierte durchschnittliche Ausführungszeit der medizintechnischen Prozedur und optional eine simulierte durchschnittliche Ausführungszeit der einzelnen Applikationen
    • – Eine Latenzzeit
    • – Warnhinweise bei Überschreiten von Schwellen- und/oder Grenzwerten
    • – Analyse der Simulation
    • – Vergleich mit früheren Simulationen und gegebenenfalls statistische Auswertung
    • – Auswertung von möglichen Performance-Beschränkungen.
  • Grundsätzlich lässt sich zur Client-Server-Architektur der Applikation Folgendes sagen. Bei Ausführung der Applikation auf einem Client, greift dieser Client auf die serverseitigen Anteile der Applikation und damit auf den Server zu. Die dabei anfallenden Anforderungen an den Server werden erfindungsgemäß (und möglicherweise zusätzlich zu dem Ressourcenbedarf auf dem Client selbst) erfasst und der zugreifenden/anfragenden Clientapplikation zugeordnet. Damit kann als Ergebnis der Simulation vorteilhafterweise auch abgeleitet werden, welcher Client (zu welchem Zeitpunkt), welche Anforderungen (Ressourcenbedarf) an den Server hat bzw. auslöst.
  • Eine weitere Lösung der vorstehend erwähnten Aufgabe besteht in einem System zur Simulation einer Performance zumindest einer medizintechnischen Prozedur, wobei die Prozedur die Ausführung einer Vielzahl von Client-Server-basierten Applikationen umfasst. Die Applikationen sollen in einer Multi-Client-Umgebung parallel auf mehreren Clients ausgeführt werden können. Die Simulation dient dazu, im Vorfeld (also noch vor Ausführung der Prozedur und der Applikation) eine Aussage über die Leistungsfähigkeit in der Multi-Client-Umgebung ableiten zu können, um bereits im Vorfeld mögliche Fehlerquellen und Engpässe eruieren zu können.
  • Dabei umfasst das System eine Vielzahl von Clients, wobei zumindest ein Client als Referenz-Client dient, bei dem Referenzressourcen für die Ausführung in der Single-Client-Umgebung bekannt bzw. bestimmbar sind. Die Bestimmung der Referenzressourcen kann automatisch oder durch Eingabe über eine Benutzerschnittstelle erfolgen. Bei der automatischen Ausführung können die Referenzressourcen aus Datenblättern eingelesen werden. Darüber hinaus umfasst das System zumindest einen Server oder eine Server-Cloud, sowie entsprechende Netzwerkverbindungen zwischen den einzelnen Computerbasierten Instanzen. Darüber hinaus umfasst das System einen Simulator (auch Simulationsmodul genannt), der zur Simulation der Performance der medizintechnischen Prozedur in der Multi-Client-Umgebung bestimmt ist. Der Simulator umfasst ein Verrechnungsmodul, das dazu ausgebildet ist, die Ausführungszeit der medizintechnischen Prozedur und deren Ressourcenbedarf bei Ausführung derselben in der Multi-Client-Umgebung zu simulieren.
  • Je nach Ausführungsform können der Simulator und/oder das Verrechnungsmodul teilweise oder vollständig auf einem der Clients und/oder auf dem Server ausgebildet sein. Darüber hinaus ist es möglich, den Simulator und/oder das Verrechnungsmodul in einer separaten, externen computerbasierten Instanz bereitzustellen. Dieser Fall erweist sich als besonders vorteilhaft, wenn ein externer Steuerrechner bereitgestellt werden soll. Die Ausführungszeit wird vorzugsweise auf dem Client bzw. dem Referenz-Client erfasst. Das Messgerät zur Erfassung der Ausführungszeit ist deshalb vorzugsweise auf dem Referenz-Client implementiert. Der Ressourcenbedarf wird vorzugsweise auf dem Server ermittelt. Deshalb ist das Ressourcenbestimmungsgerät, das auch zur Erfassung des Ressourcenbedarfs (der von dem jeweiligen Client ausgelöst/angefragt wird) auf dem Server bestimmt sein kann, vorzugsweise auf dem Server implementiert.
  • Eine weitere Aufgabenlösung besteht in einem Computerprogrammprodukt gemäß beiliegendem Anspruch. Das Computerprogrammprodukt umfasst ein computerimplementiertes Simulationsverfahren, wie es vorstehend beschrieben worden ist mit bedarfsweise zuordenbaren informationstechnologischen Modulen, wie beispielsweise Programmbibliotheken, IT-Strukturen, Hardwaretopologien oder Softwaretopologien. Vom Schutz umfasst sein soll somit auch das Computerprogramm, das auch auf einem Speichermedium gespeichert sein kann, so dass sich der Schutz auch auf das Speichermedium mit dem darauf gespeicherten Simulationsverfahren erstreckt.
  • Wie vorstehend bereits ausgeführt, bezieht sich die Erfindung somit auf die Planung, Steuerung und Realisierung von Automatisierungslösungen in der Medizintechnik. Dabei können insbesondere Computerprogramme, einzelne Programmstrukturen, Hardwareelemente und Kommunikationstopologien für den technischen Prozess zusammengefasst werden. Dabei ist zu berücksichtigen, dass das erfindungsgemäße Verfahren und der erfindungsgemäße Vorschlag auf einem technischen Gerät, das computerbasierte Instanzen umfasst, ausgeführt wird. Sowohl das Simulationsverfahren als auch die zu simulierende medizintechnische Prozedur basieren auf technischen Geräten, Einrichtungen oder Systemen, wie zum Beispiel Steuerungen, speicherprogrammierbare Steuerungen, Prozessrechner, Industriecomputer und medizintechnischen Geräten.
  • Die oben beschriebenen Eigenschaften, Merkmale, Aspekte und Vorteile dieser Erfindung, sowie die Art und Weise, wie diese erreicht werden, werden klarer und deutlicher verständlich im Zusammenhang mit der folgenden Beschreibung der Ausführungsbeispiele, die im Zusammenhang mit den Zeichnungen näher erläutert werden. Dabei zeigt:
  • 1 eine schematische Übersichtsdarstellung einer Client-Server-Architektur, auf der Client-Server-basierte Applikationen zur Ausführung kommen sollen und deren Performance im Vorfeld simuliert wird;
  • 2 eine schematische Übersichtsdarstellung über das Bereitstellen eines Simulators, der einem Server zugeordnet ist;
  • 3 eine Übersichtsdarstellung über weitere Bauteile des Servers;
  • 4 eine schematische Darstellung von einzelnen computerbasierten Instanzen, die gemäß einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens zum Einsatz kommen können;
  • 5 eine beispielhafte Darstellung von gemessenen Ausführungszeiten und gemessenen Hardwareressourcen;
  • 6 eine beispielhafte Darstellung von Teilen einer Benutzeroberfläche zur Ausgabe von Ergebnissen oder Teilergebnissen des Simulationsverfahrens, umfassend Verzögerungsangaben und eine Aufzeichnung von Ressourcen über die Zeit;
  • 7 eine grafische Darstellung einer simulierten Ausführungszeit, einer gemessenen durchschnittlichen Ausführungszeit und gemessenen Maximal- und Minimalwerten bei einer variablen Anzahl von Clients;
  • 8 eine beispielhafte Darstellung eines Simulationsergebnisses mit der Darstellung von Speicherzugriffen und den Ressourcenverbrauch über die Zeit;
  • 9 eine beispielhafte Darstellung der simulierten Ausführungszeit für unterschiedliche Anzahlen von Clients für eine Beispielapplikation („Load MM3D“);
  • 10 eine schematische Darstellung einer medizinischen Prozedur mit Applikationen und Applikationsschritten,
  • 11 eine schematische Darstellung einer Single-Client-Umgebung und einer Multi-Client-Umgebung und
  • 12 ein Ablaufdiagramm des Simulationsverfahrens gemäß einer vorteilhaften Ausbildung der Erfindung.
  • 1 zeigt in schematischer, vereinfachter Form ein Client-Server-basiertes Automatisierungssystem, das zur Ausführung von unterschiedlichen Computer-basierten Modulen und Verfahren ausgelegt ist und eine Vielzahl von Computerbasierten Instanzen und/oder Modulen umfasst, die über ein Netzwerk N miteinander in Datenaustausch stehen.
  • In der hauptsächlichen Ausführungsform der vorliegenden Erfindung haben die Applikationen, die auf dem Client-Server-System ausgeführt werden sollen, medizinischen Hintergrund, sodass es sich um medizintechnische Applikationen handelt, wie zum Beispiel das Laden von Bildern in einen 3D-Viewer. Der Gegenstand der Anmeldung ist jedoch nicht auf das Gebiet der Medizintechnik beschränkt, sondern der Simulationsprozess kann ebenso auch auf andere Gebiete, zum Beispiel auf die Simulation von Produktionsprozessen und Prozessen in Fertigungsanlagen, bezogen werden, die die Ausführung von unterschiedlichen Computer-basierten Applikationen erfordern.
  • Wie in 1 dargestellt, umfasst die Client-Server-Architektur als wesentliche Bestandteile einen Server S. Der Server S kann als separater Computer oder als separate Computer-basierte Instanz der Plattform angeschlossen sein. Dies ist in 1 mit dem mit einer durchgehenden Linie dargestellten Kasten gekennzeichnet, der das Bezugszeichen "S" trägt. Alternativ kann der Server S auch durch eine Serverfarm gebildet werden, die eine Vielzahl von Servern umfasst. Dies ist in 1 durch den gestrichelt dargestellten Kasten gekennzeichnet, der die Bezugszeichen S1, S2, S3 trägt und jeweils zusammengeschaltete Server einer Serverfarm kennzeichnen soll. Neben dem Server S umfasst die Client-Server-Architektur als wesentliche Bestandteile eine Vielzahl von Clients C1, C2, C3, ..., die ihrerseits über ein Netzwerk N mit dem Server S in Datenaustausch stehen und bedarfsweise auch untereinander Daten austauschen können. Des Weiteren ist der Client-Server-Architektur ein Simulationsmodul SIM zugeordnet, das seinerseits ein Verrechnungsmodul V umfasst. Das Simulationsmodul (auch Simulator genannt) steht ebenfalls über das Netzwerk N in Datenaustausch mit den anderen Computer-basierten Instanzen der Client-Server-Architektur.
  • In 11 ist schematisch dargestellt, dass die Ausführung des erfindungsgemäßen Simulationsverfahrens gemäß einer bevorzugten Ausführungsform zwischen zwei unterschiedlichen Umgebungen unterscheidet:
    • 1. Einer Single-Client-Umgebung, bei der ein Referenz-Client REF-C bereitgestellt ist, auf dem die medizintechnische Prozedur und/oder die Applikationen aufgerufen werden (deren Ausführung erfolgt teilweise auf dem Server S).
    • 2. Einer Multi-Client-Umgebung, die eine Vielzahl von Clients C umfasst, wobei die jeweilige Applikation parallel auf mehreren Clients der Multi-Client-Umgebung ausführbar ist.
  • Die Single-Client-Umgebung und die Multi-Client-Umgebung werden bei der Simulation des Simulationsmoduls SIM berücksichtigt. Soll beispielsweise eine medizintechnische Prozedur P auf Performanz geprüft werden, bei der es vorgesehen ist, dass einzelne Applikationen A der medizintechnischen Prozedur P parallel auf mehreren Clients C1, C2, Cn ausgeführt werden sollen, so kann das erfindungsgemäße Simulationsverfahren eingesetzt werden, um auf Basis der gemessenen Ausführungszeiten und der gemessenen bzw. erfassten Ressourcen in der Single-Client-Umgebung eine Vorhersage über die Ausführungszeiten und den Ressourcenbedarf in der Multi-Client-Umgebung zu generieren. Die dabei parallel agierenden Clients C können demselben bzw. voneinander abweichenden Aufbau bzw. Struktur haben. Soll beispielsweise ein Bilddatensatz geladen werden, um in einem 3D-Viewer dargestellt zu werden, ist es erforderlich, eine Vielzahl von Applikationen auszuführen. Dabei soll es jedoch möglich sein, dass diese Prozedur P (Laden des Bilddatensatzes zur Anzeige auf 3D-Viewer) parallel auf mehreren Clients C1, C2, ... ausgeführt wird. Die Ausführung auf mehreren parallelen Clients mit teilweise unterschiedlichen Ressourcen führt zu einer Änderung der Performanz (Ausführungszeiten und Ressourcenbedarf). Eine Vorhersage über diese Performanzänderung (vorzugsweise umfassend: serverseitige und clientseitige Anteile) wird erfindungsgemäß automatisch bereitgestellt.
  • Gemäß einem Aspekt der Erfindung wird das simulierte Verhalten der Client-Server-basierten Applikation bzw. des umfassenden Client-Server-basierten medizintechnischen Prozesses dadurch gewährleistet, dass im Vorfeld ein Referenz-Client REF-C bestimmt wird, dessen Ressourcen (vorzugsweise automatisch) erfasst werden. Üblicherweise kann dies durch Einlesen von entsprechenden Angaben erfolgen, beispielsweise Herstellerangaben aus dem Datenblatt des Herstellers des medizintechnischen Gerätes. Der Referenz-Client REF-C kann aus der Menge der zur Verfügung stehenden Clients C1, C2, ..., Cn ausgewählt werden und dient als Referenz-Client zur Ausführung der erforderlichen Applikationen oder zur Ausführungsanfrage der erforderlichen Applikationen auf dem Server S.
  • Dazu ist es erforderlich, dass in einem Parse-Durchgang für die jeweilige medizintechnische Prozedur P automatisch erkannt wird, welche Applikationen A für die Ausführung der medizintechnischen Prozedur P erforderlich sind. Üblicherweise handelt es sich um eine Abfolge von Applikationen A1, A2, A3, .... Ai.
  • In Zusammenhang mit 10 sei im Folgenden der hierarchische Aufbau der medizintechnischen Prozedur P kurz erläutert. Die medizinische Prozedur P umfasst eine Abfolge von Applikationen, die in 10 mit den Rechteckkästen gekennzeichnet sind, die die Bezugszeichen A1, A2, A3.1, A3.2, A4, ... tragen. Dabei können auch parallel mehrere Applikationen ausgeführt werden oder es ergeben sich sonstige zeitliche Überschneidungen bei der Ausführung der Applikationen.
  • Jede der Applikationen A ist ihrerseits wiederum hierarchisch aufgebaut und umfasst eine Abfolge von Applikationsschritten AS1, AS2, AS3, .... Selbstverständlich liegt es für den Fachmann auf der Hand, dass es hier auch zu Rekursionen, Iterationen oder Parallelausführungen der einzelnen Applikationsschritte AS und/oder der einzelnen Applikationen A kommen kann. Deshalb ist der in 10 dargestellte Aufbau lediglich als grobes Schema zu verstehen, das in der Praxis abweichend implementiert sein wird.
  • Gemäß einer bevorzugten Ausführungsform ist es vorgesehen, dass das Simulationssystem ein Bestimmungsmodul umfasst, das dazu ausgebildet ist, automatisch eine möglichst optimale Abfolge von Applikationsschritten AS innerhalb der Applikation und eine möglichst optimale Abfolge an Applikationen A innerhalb der medizintechnischen Prozedur P zu bestimmen. Die Abfolge der Applikationsschritte AS und/oder die Abfolge der Applikationen A können auch vorkonfiguriert sein. Dabei ist hervorzuheben, dass Änderungen dieser Vorkonfiguration möglich sind und auch bei der Simulation berücksichtigt werden können. So ist es ein besonderer Vorteil, dass das Simulationsverfahren auch abweichende Abfolgen von Applikationsschritten AS und/oder von Applikationen A simuliert. Dementsprechend können die Simulationsergebnisse in Bezug auf unterschiedliche Abfolgen von Applikationen A und/oder Applikationsschritten AS miteinander verglichen werden, um das System insgesamt möglichst hochperformant zu gestalten.
  • Üblicherweise ist es vorgesehen, dass eine Datenstruktur existiert, in der eine Zuordnungstabelle hinterlegt ist, umfassend Zuordnungen zwischen jeweils einer medizintechnischen Prozedur P und einer (vorkonfigurierbaren) Abfolge von Applikationen A (ihrerseits umfassend eine Abfolge von Applikationsschritten AS). Damit kann automatisch erkannt werden, welche Applikationen für die Ausführung der jeweiligen medizintechnischen Prozedur (die simuliert werden soll) erforderlich sind.
  • Nach Durchführung der vorstehend genannten Vorbereitungsschritte, wird nun die Abfolge von Applikationen A, die als erforderlich erkannt worden sind in der Single-Client-Umgebung ausgeführt. Dabei wird die tatsächlich benötigte Ausführungszeit auf dem Referenz-Client REF-C und auf dem Server S gemessen und es werden automatisch die vorhandenen Ressourcen auf den Referenz-Client REF-C und auf dem Server S erfasst.
  • In 3 ist schematisch dargestellt, welche Module bzw. Bauteile für die Ausführung der Applikation A in der Single-Client-Umgebung auf dem Referenz-Client REF-C erforderlich sind. In der Single-Client-Umgebung wird der Referenz-Client REF-C verwendet, um die jeweilige Applikation bzw. die Abfolge von Applikationen A auf den Server S zur Ausführung zu bringen. Dabei werden die Ausführungszeit und der Ressourcenbedarf auf dem Referenz-Client REF-C gemessen. Dies geschieht über ein Messgerät 12, das zur Erfassung der Ausführungszeit dient (auch als "Performance Counter" bezeichnet). Des Weiteren wird ein Ressourcenbestimmungsgerät 13 verwendet, das zur automatischen Bestimmung der Ressourcen des Referenz-Client REF-C dient. Dabei kann es sich um ein Einlesemodul handeln, das aus Datenblättern in einem bestimmten Format automatisch die relevanten Ressourcengrößen extrahiert. Bei den Ressourcen handelt es sich vornehmlich um Hardware-Ressourcen 11 und um allgemeine oder sonstige technische Ressourcen 10 (z.B. Sensoren, Schnittstellen, Adaptergeräte etc.).
  • Wie auch in 1 dargestellt umfasst also jeder Client C Hardware-Ressourcen 11 und sonstige technische Ressourcen 10.
  • Gemäß einer bevorzugten Ausführungsform ist es vorgesehen, dass die jeweiligen Hardwareressourcen 11 in Klassen eingeteilt werden und hinsichtlich ihres Grades bestimmt werden. So kann beispielsweise eine erste Klasse von Hardware-Ressourcen mit dem Grad 1 bestimmt werden, die eine bestimmte Kombination von Hardware-Ressourcen (Speicherbedarf, CPU, Netzwerkanbindung, etc.) umfassen, während eine zweite Klasse von Hardware-Ressourcen definiert werden kann, die beispielsweise eine geringere oder höhere Ressourcenbestückung aufweisen. Wie vorstehend beschrieben, handelt es sich bei den allgemeinen sonstigen Ressourcen um technische Ressourcen, die beispielsweise die CPU-Auslastung, den Speicherbedarf, die Netzwerkbedarfsparameter, Plattenzugriffe, Grafikkartenzugriffe oder Bedarf bzw. Zugriffe auf externe Ressourcen umfassen.
  • Wie ebenfalls vorstehend bereits beschrieben, werden die Ausführungszeit und der Ressourcenbedarf bei Ausführung der jeweiligen Applikation A auf dem Referenz-Client REF-C und/oder auf dem Server S in der Single-Client-Umgebung erfasst. Diese erfassten Größen bzw. Werte werden dann automatisch zum Zwecke der Simulation an das Simulationsmodul SIM weitergeleitet. Selbstverständlich können hier noch weitere Metaparameter (zum Beispiel Metaparameter im Hinblick auf die Ausführungssituation, wie zum Beispiel wenig Belastung bei Nacht oder hohe Belastung da Notfall-OP) berücksichtigt werden.
  • Im Folgenden wird unter Bezugnahme auf 2 dargestellt, dass es unterschiedliche Möglichkeiten gibt, das Simulationsmodul SIM bereitzustellen. Eine Möglichkeit besteht darin, das Simulationsmodul SIM auf dem Server S zu implementieren. Dies ist in 2 durch den Schnitt einer durchgezogenen Linie und den Bezugszeichen SIM tragenden Rechteckkasten dargestellt. Alternativ kann das Simulationsmodul SIM auch als separate Instanz dem Server S zugeschaltet werden und sozusagen als externes Bauteil bereitgestellt werden. Dies ist in 2 mit der Strichlinie dargestellt. Alternativ kann das Simulationsmodul SIM auch Client-seitig bereitgestellt werden oder direkt auf einem der Clients C angeordnet sein. Dies ist in 2 durch den gepunktet dargestellten Kasten angedeutet. Selbstverständlich liegen auch Kombinationen der vorstehend beschriebenen Implementierungsalternativen im Rahmen dieser Erfindung. Ein Vorteil der Erfindung ist darin zu sehen, dass das Simulationsmodul SIM auf jedem Client ausführbar ist und keine besonderen oder erhöhten Voraussetzungen in Bezug auf informationstechnologische Parameter erfüllt sein müssen. So kann das Simulationsmodul SIM beispielsweise ohne weiteres auf einem Windows-Rechner ablaufen.
  • Im Folgenden wird unter Bezugnahme auf 4 beschrieben, welche Module bei Durchführung des Simulationsprozesses erforderlich sind. Zunächst ist dies natürlich das Simulationsmodul SIM, das einen Prozedur- und Applikations-Serializer 14 umfassen kann. Dieser dient dazu, die Abfolge von Applikationsschritten AS und die Abfolge von Applikationen A zu bestimmen und/oder aus vorkonfigurierten Werten einzulesen. Darüber hinaus ist das Ressourcenbestimmungsgerät 13 erforderlich und der Client C. Der Client C umfasst einen Applikationsklassen-Serializer 15, der zur Bestimmung und/oder Verwaltung der Abfolge der Applikationen und/oder der Applikationsschritte bestimmt ist. Sowohl Prozedur-Applikations-Serializer und Applikationsklassen-Serializer 14, 15 können auf einer XML-Datei basieren. Darüber hinaus umfasst der Client C ein Property-Modul 16 und ein Methoden-Modul 17 um Eigenschaften und Methoden der auszuführenden Applikation A festzulegen. Darüber hinaus ist ein Hardware-Klassen-Bestimmungsgerät 18 vorgesehen, das ebenfalls eine XML-Datei umfassen kann, in der die jeweiligen Clients der Multi-Client-Umgebung hinsichtlich ihrer technischen Parameter (CPU, Memory, Zugriffe, angeschlossene Prozessoren, etc.) klassifizieren und bestimmen. Des Weiteren ist ein Applikationsschrittverwalter 20 vorgesehen, der dazu dient, die Abfolge der einzelnen Applikationsschritte AS und/oder insgesamt auch die Abfolge der Applikationen A zu überwachen und zu verwalten.
  • In Zusammenhang mit 3 werden im Folgenden der Aufbau und eine mögliche Benutzerschnittstelle des Messgerätes 12 und des Ressourcenbestimmungsgerätes 13 dargestellt. Wie in 5 dargestellt, umfasst das Messgerät 12 zumindest ein Messgerät zur Erfassung der Ausführungszeit bei Ausführung der jeweiligen Applikation A auf dem Referenz-Client REF-C in der Single-Client-Umgebung. Dabei wird die Ausführungszeit mittels des Performance Counters 12-1 gemessen und grafisch dargestellt. Des Weiteren umfasst das Ressourcenbestimmungsgerät 13 eine grafische Darstellung des ermittelten bzw. gemessenen Ressourcenbedarfs (hier dargestellt CPU und Speicherbedarf: CPU/Memory), der sich in einer Ausführung der Erfindung auf den Server S bezieht (alternativ kann bedarfsweise zusätzlich auch der Ressourcenbedarf auf dem Client REF-C ermittelt werden). Die Darstellung des Ressourcenbedarfs ist in 5 mit dem Bezugszeichen 13-1 gekennzeichnet. Sowohl die Darstellung 12-1 und 13-1 umfassen eine grafische Darstellung über die Zeit.
  • In 6 ist beispielhaft eine Benutzeroberfläche des erfindungsgemäßen Simulationsmoduls SIM dargestellt. Das Simulationsmodul SIM umfasst somit auch eine Benutzerschnittstelle zur Darstellung des Simulationsergebnisses. Üblicherweise wird dabei das Ergebnis in unterschiedlichen Fenstern dargestellt. Wie in 6 gezeigt, kann ein oberes Fenster vorgesehen sein, in dem der jeweilige Applikationsschritt (in 6 bezeichnet mit "Activity"), eine Anzahl der Ausführungen, die Ausgabe der gemessenen Ausführungszeit in der Single-Client-Umgebung ("Single Client Performance"), und eine durchschnittliche simulierte Ausführungszeit für die Ausführung in der Multi-Client-Umgebung ("simulated (average, in seconds/s)“) ausgegeben werden. Fakultativ kann das eben beschriebene Fenster noch eine Verzögerungskomponente umfassen, die zur Darstellung der Verzögerungszeit ("delay") dient. Damit ergibt sich der Vorteil, dass der Anwender sozusagen auf einen Blick eine prozentuale Verzögerung bei Ausführung der geplanten Applikation in der Multi-Client-Umgebung unter den jeweiligen Bedingungen (unter anderem Anzahl der Clients und deren Ausstattung, sowie Ressourcenbedarf/Server) ausgibt.
  • Im unteren Fenster der in 6 dargestellten Benutzeroberfläche findet sich eine grafische Darstellung der Ressourcen über die Zeit. In diesem Beispiel ist der CPU-Bedarf und der Speicherbedarf über die Zeit dargestellt (CPU, Memory and Disc Usage). Dabei ist es grundsätzlich möglich, unterschiedliche technische Ressourcen in einer grafischen Darstellung zu kombinieren oder jede einzelne technische Ressource in einem separaten, einzelnen Fenster zur Anzeige zu bringen (beispielsweise als Grafik über die Zeit). Ebenfalls ist nur eine verkürzte Thumbnail-Darstellung möglich, die nur einen Hinweis ausgibt, ob die simulierten Größen (hier Performance und Ressourcenbedarf) in einem zulässigen Bereich liegen oder nicht.
  • Darüber hinaus umfasst das Ergebnis des Simulationsvorganges üblicherweise eine Ausgabe der jeweiligen Ausführungszeiten bei variierender Anzahl von Clients im Vergleich. Dies ist beispielhaft in 7 dargestellt. In 7 ist in der durchgezogenen Linie die gemessene durchschnittliche Ausführungszeit eine Applikation A auf dem Referenz-Client REF-C dargestellt. In der geschwungenen Linie ist die simulierte Ausführungszeit zur Ausführung der Applikation A in der Multi-Client-Umgebung dargestellt. In der unteren (Strichpunktlinie) und in der oberen (Punktlinie) sind jeweils die gemessenen Minimalwerte und die jeweils gemessenen Maximalwerte für die Ausführungszeiten (vor-konfigurierbar) dargestellt. In 7 wurde zwischen einer One-Single-Client-Umgebung (ein Client), einer Two-Client-Umgebung (zwei Clients) und einer Multi-Client-Umgebung mit drei Clients unterschieden. Vorteilhafterweise erkennt der Fachmann sozusagen auf einen Blick, wie sich die Ausführungszeiten und der Ressourcenbedarf bei Zuschaltung von weiteren Clients in der Multi-Client-Umgebung verändert (bzw. erhöht/verschlechtert).
  • In einer weiteren Ausführungsform der Erfindung ist es vorgesehen, dass das Simulationsergebnis noch weitere Angaben umfasst, so beispielsweise eine statistische Auswertung der simulierten Werte. Dabei kann beispielsweise die simulierte Ausführungszeit mit Referenzausführungszeiten oder zu einem früheren Zeitpunkt ausgeführten, gemessenen oder simulierten Ausführungszeiten verglichen werden. Dasselbe gilt auch für den Ressourcenbedarf. Ebenso sind andere Vergleichsoperationen (beispielsweise mit vor-konfigurierbaren Schwellenwerten) möglich. Ein wesentlicher Vorteil der Erfindung ist darin zu sehen, dass das Simulationsmodul SIM zusätzlich ein Analysemodul (in den Figuren nicht gezeigt) umfasst, das zur konfigurierbaren Analyse der simulierten Werte dient. So kann beispielsweise automatisch eine mögliche Fehlerursache bzw. eine Ursache für die Einschränkung der simulierten Performance ermittelt werden. Sobald ein sogenanntes "bottleneck" der Client-Server-Architektur ermittelt werden konnte, kann unter Zugriff auf eine Datenbank eine entsprechende Remedy-Maßnahme abgeleitet werden. In dieser Datenbank sind für typische Muster bzw. typische Fehler (Vorschläge üblicherweise eine Kombination von einzelnen Maßnahme) enthalten, um diesen Fehler zu beheben. Beispielsweise kann hier das Aufschalten eines Co-Prozessors oder die Hinzuschaltung eines externen Speichers bei einem festgestellten zu geringen Speicherbedarf ausgegeben werden.
  • In 8 ist eine weitere Möglichkeit zur Darstellung des Simulationsergebnisses beschrieben. Dabei werden in einem Fenster zwei Grafen dargestellt, in denen jeweils der Ressourcenbedarf (hier Disc Read/Write-Zugriffe und CPU/Memory) über die Zeit aufgetragen werden. Damit erhält der Anwender auf einen Blick Informationen, zu welchem Ausführungszeitpunkt der Applikation ein erhöhter Speicherbedarf und/oder eine erhöhte CPU-Belastung gefahren wird. Falls die simulierte Ausführungszeit und der simulierte Ressourcenbedarf einen vorbestimmten maximalen Schwellenwert überschreiten, können automatisch Behebungsmaßnahmen eingeleitet werden
  • 9 zeigt eine beispielhafte Darstellung der simulierten Ausführungszeiten bzw. Antwortzeiten als Prozentangabe für eine unterschiedliche Anzahl von Clients für die Ausführung der Beispielapplikation "MM3D_6 Clients". Dabei wird die Verzögerungszeit als Prozentangabe über die Anzahl der Clients aufgetragen. Die Tatsache, dass sich die gesamte Ausführungszeit bei Erhöhung der Anzahl der Clients verlängert, liegt auf der Hand; mit Hilfe der Simulation wird es jedoch möglich, eine genauere Aussage hierzu abzuleiten und insgesamt auch eine maximal zulässige Anzahl von Clients zu bestimmen, die parallel die jeweilige Applikation auf dem Server S zur Ausführung bringen, ohne dass Ausführungszeiten und Ressourcenbedarf unzulässige Grenzen überschreiten. Wie in 9 dargestellt verläuft diese Kurve nicht proportional.
  • Vorteilhafterweise können mit der erfindungsgemäßen Lösung auch Interdependenzen zwischen den einzelnen Clients hinsichtlich der Gesamtperformance (umfassend Ausführungszeit und Ressourcenbedarf) ermittelt werden. Dies wird durch den Simulationsalgorithmus mit der zweifachen Iteration erreicht.
  • Im Folgenden wird unter Bezugnahme auf 12 ein beispielhafter Ablauf gemäß einer bevorzugten Ausführungsform der Erfindung näher beschrieben.
  • Nach dem Start der Simulationsprozedur werden unter Schritt 1 folgende Maßnahmen ausgeführt:
    • Bestimmen der Applikation A für die medizintechnische Prozedur P und deren Abfolge.
    • Bestimmen der Applikationsschritte AS für die jeweiligen Applikationen A und deren Abfolge.
  • Schritt 2:
    • Bestimmen der technischen Ressourcen des Referenz-Clients REF-C, der zur Ausführung der jeweiligen Applikation in der Single-Client-Umgebung dient.
  • Schritt 3:
    • Ausführen der Applikation A in der Single-Client-Umgebung auf dem Referenz-Client REF-C.
  • Schritt 4:
    • Messen der Ausführungszeit auf dem Referenz-Client REF-C.
    • Bestimmen des Ressourcenbedarfs, der bei Ausführung der Applikation A durch den Referenz-Client REF-C auf dem Server S anfällt. Gegebenenfalls kann zusätzlich auch noch der Ressourcenbedarf ermittelt werden, der auf dem jeweiligen Client anfällt.
  • Schritt 5:
    • Bestimmen der Clients C zur Ausführung der Applikation in der Multi-Client-Umgebung. Hier werden also die Clients bestimmt, auf denen die jeweilige Applikation A parallel ausgeführt werden soll.
  • Schritt 6:
    • Simulation der Performance bei Ausführung der Applikation A in der Multi-Client-Umgebung.
  • Schritt 7:
    • Überprüfung: Sind alle Applikationen A für den medizintechnischen Prozess P abgearbeitet? Je nach Ergebnis erfolgt hier eine Fallunterscheidung. Falls die vorhergehende Überprüfung hat, dass noch nicht alle Applikationen A abgearbeitet worden sind, so wird in dem in 12 auf der linken Seite dargestellten Zweig verzweigt. Dabei wird auf die nächste, folgende Applikation A innerhalb der bestimmten Abfolge von Applikationen A gesprungen und die Schritte 3 bis 6 werden für die nächstfolgende Applikation A ausgeführt. Damit erfolgt die Ausführung der Schritte 3 bis 6 iterativ für alle Applikationen A der bestimmten Folge von Applikationen. Falls die Überprüfung in Schritt 7 ergeben hat, dass bereits alle Applikationen A der bestimmten Abfolge von Applikationen abgearbeitet worden sind, so endet der Simulationsprozess.
  • Selbstverständlich liegt es auf der Hand, dass die in 12 dargestellte Abfolge von Verfahrens- bzw. Simulationsschritten nicht fest ist und bedarfsweise auch variiert werden kann. So ist es beispielsweise möglich, dass die Schritte 1 und 2 in einer Vorbereitungsphase ausgeführt werden, was vorteilhafterweise dazu führt, dass die Simulation schneller zu einem Ergebnis kommt, wenn die Eingangsgrößen bereits feststehen. Auch ist es möglich, den Schritt 2 zu einem späteren Zeitpunkt, etwa nach Schritt 3 auszuführen.
  • Gemäß einer bevorzugten Ausführungsform umfasst Schritt 6 bei der Simulation der Performance seinerseits eine Iteration. Diese bezieht sich auf die Iteration über die Zeit. Dabei ist es vorzugsweise vorgesehen, dass im Vorfeld der Simulation ein Simulationsschritt als Zeitintervall festgelegt wird (zum Beispiel zwei Sekunden). Nach Zerlegen des medizintechnischen Prozesses P in eine Abfolge von Applikationen und in eine Abfolge von Applikationsschritten AS wird iterativ untersucht, wie hoch die Ausführungszeiten in dem jeweiligen Simulationsschritt sind. Dies wird für jeden Simulationsschritt durchgeführt.
  • Insgesamt basiert die erfindungsgemäße Simulation somit auf einer zweifachen Iteration, umfassend eine Iteration über die Simulationsschritte bzw. über die jeweiligen Applikationen und eine zweite Iteration über die beteiligten Clients C. Dabei wird der Ressourcenbedarf der parallel zugreifenden Client für den jeweiligen Applikationsschritt addiert.
  • Grundsätzlich dient die Simulation der Vorhersage des technischen Verhaltens einer Client-Server-basierten Applikationsstruktur. Insbesondere soll vorhergesagt werden, wie sich die Programmstruktur verhält, wenn gleichzeitig bzw. parallel mehrere Clients C auf alle oder ausgewählte Teile der Programmstruktur zugreifen bzw. diese auf dem Server S zur Ausführung bringen. Mit erhöhter Anzahl der Clients C werden auch die Ausführungszeit und der Ressourcenverbrauch steigen. Wie dieser Anstieg jedoch im Detail aussieht und welche möglichen Beschränkungen über die Zeit bestehen, kann jedoch nicht pauschal gesagt werden. Dazu sind komplexe und umfangreiche Messungen und Berechnungen notwendig, die mittels des Simulationsmoduls SIM und der Verrechnungseinheit V automatisch durchgeführt werden.
  • Die Erfindung basiert im Wesentlichen darauf, dass eine Applikation A bzw. eine Abfolge von Applikationen A zunächst nur in der Single-Client-Umgebung auf einem Referenz-Client REF-C ausgeführt wird. Dabei werden Ausführungszeiten (vorzugsweise auf dem Referenz-Client REF-C) und Ressourcenverbrauch (vorzugsweise auf dem Server S) gemessen. Die gemessenen Werte werden dann der Simulation zugeführt, sodass in der Simulation komplizierte Applikationsszenarien simulierbar werden, beispielsweise dann, wenn auf unterschiedlichen Clients (teilweise mit unterschiedlichen Ressourcen) parallel bestimmte Applikationsschritte ausgeführt werden sollen. Das Ergebnis der Simulation umfasst die Ausgabe eine Verzögerungszeit (Latenz), des Ressourcenbedarfs und gegebenenfalls kann noch eine Zuordnung zwischen einer bestimmten Ressource als Ursache für die Latenz und weitere Fehlerbehebungsmaßnahmen, die automatisch ermittelt werden.
  • Vorzugsweise ist die Taktung des Simulationsprozesses variierbar. Hierbei wird im Vorfeld ein Zeitintervall für die Dauer des Simulationsschrittes bestimmt.
  • Wenn im folgenden Beispiel die jeweilige Applikation A zum Laden eines Bilddatensatzes bestimmt ist, so wird bei der Ausführung des Ladevorganges auf einem ausgewählten Referenz-Client REF-C die Ausführungsdauer bemessen (zum Beispiel 6 Sekunden), der Hauptspeicherbedarf (zum Beispiel 1 GB), die Belastung des Prozessors auf dem Server während dieser Zeit (zum Beispiel 15 %) und eine Festplattedatenrate (zum Beispiel 1 MB/s). Davor oder danach werden die technischen Parameter (also die Referenz-Ressourcen) des Servers (und/oder des Referenz-Client REF-C) eingegeben oder eingelesen, wie zum Beispiel: Hauptspeicher auf dem Server: 16 GB, maximale Daten-Leserate 100 MB/s. Nachdem weiterhin bestimmt wurde, dass maximal 5 Clients C gleichzeitig den Bilddatensatz laden können sollen, ergibt die Simulation, dass die Latenzzeit in der Simulation zwei Sekunden beträgt. Dies bedeutet, dass mit einer Verzögerung von zwei Sekunden zu rechnen ist, wenn die bestimmten 5 Clients C gleichzeitig die Bilddaten laden (im Vergleich zum Laden des Bilddatensatzes von nur einem Client). Des Weiteren ergibt die Simulation als Ursache für die erhöhte Latenzzeit, dass die Festplatte zu gering ausgelegt ist, und die Bilder nicht so schnell wie erforderlich laden kann. Vorteilhafterweise können nun automatisch Fehlerbehebungsmaßnahmen eingesetzt werden.
  • Ein besonderer Vorteil ist deshalb darin zu sehen, dass bereits im Vorfeld (also vor Ausführung der jeweiligen Applikation und noch bei Auslegung der informationstechnologischen Parameter des Client-Server-Systems) festgestellt werden kann, ob das Client-Server-System, die Plattform und die jeweilige Architektur ausreichend dimensioniert und ausgelegt sind. Somit können Fehler frühzeitig erkannt und vermieden werden, ohne dass es notwendig ist, die Applikationen konkret in der Multi-Client-Umgebung auszuführen. Damit dient die erfindungsgemäße Simulation zur Steuerung und Auslegung der technischen Architektur des Client-Server-Systems. Somit könne Kosten und Zeit in deutlichem Maße eingespart werden.
  • Ein weiterer, wichtiger Vorteil ist auch darin zu sehen, dass der Simulationsvorgang vollautomatisch ausgeführt werden kann, wodurch insgesamt Fehler vermieden werden können, die beispielsweise durch manuelle Fehleingaben entstehen.
  • Ein weiterer wichtiger Vorteil ist darin zu sehen, dass es mit der Simulation auf einem Blick möglich wird, unterschiedliche Architekturprinzipien oder Konstellationen zu vergleichen. Wenn beispielsweise die Simulation ergeben hat, dass die Latenzzeit bei Ausführung der medizintechnischen Prozedur P in der Multi-Client-Umgebung bei 5 Clients zu einer unzulässig hohen Ausführungszeit geführt hat, so kann unmittelbar (sozusagen durch einen Klick) getestet werden, ob sich die Ausführungszeit verbessert, wenn nur weniger (zum Beispiel 4) Clients für die Multi-Client-Umgebung bestimmt werden. Des Weiteren können auch sonstige Variationen (andere Abfolge von Applikationsschritten, andere Abfolge von Applikationen, andere Ressourcen auf dem Server, veränderte Ressourcen auf dem Client, andere Netzwerkanbindung, etc.) untersucht werden. Als Ergebnis des erfindungsgemäßen Simulationsvorgangs wird immer ausgegeben, wie sich die technischen Parameter des Systems verhalten, unter den voreingestellten Bedingungen und ob die simulierte Performance noch im zulässigen Bereich liegt.
  • Ein Beispiel einer medizintechnischen Prozedur P mit einer Abfolge von Applikationen A sei im Folgenden geschildert:
    • 1. Laden einer Bildserie
    • 2. Pause (z.B. 4 Sekunden)
    • 3. Vergrößern eines Bildes der Bildserie (1 Sekunde)
    • 4. Pause (z.B. 2 Sekunden)
    • 5. medizinische Messungen auf einem Bild der Bildserie (z.B. Volumenmessung eines Tumors)
    • 6. Pause (z.B. 5 Sekunden)
    • 7. Erstellen eine Befundes (z.B. 15 Sekunden)
    • 8. Schließen der Bildserie und Beenden der Applikation.
  • Ein weiterer Vorteil ist darin zu sehen, dass keine zusätzlichen Anforderungen hinsichtlich der informationstechnologischen Grundlagen zur Ausführung der Simulation gestellt werden. Die Simulation kann auf einem beliebigen Rechner mit beliebiger Plattform ausgeführt werden. Des Weiteren kann durch das Bereitstellen der einzelnen Module bzw. durch den modularen Charakter des erfindungsgemäßen Systems eine Flexibilität und Variabilität hinsichtlich der zu simulierenden Werte und Größen erzielt werden.
  • Damit wird es möglich, im Vorfeld zu überprüfen, ob bestimmte klinische Anforderungen und Szenarien mit einer gegebenen technischen Infrastruktur überhaupt umsetzbar sind. Es kann somit bereits im Vorfeld überprüft werden, ob die Performanz überhaupt akzeptabel ist.
  • Darüber hinaus ist es möglich, die Simulationsergebnisse mit vorhergehenden Messungen und Ergebnissen zu vergleichen und möglicherweise zu überprüfen, ob das Simulationsergebnis überhaupt in einem gültigen Bereich liegt oder ob möglicherweise Fehlmessungen erfolgt sind. So kann beispielsweise als Ergebnis abgeleitet werden, dass eine Multi-Client-Umgebung mit drei gleichzeitig zugreifenden Clients noch akzeptierbar ist, während ein Zugriff von fünf parallelen Clients zu einem Ressourcenengpass führen würde.
  • Bei der Simulation können als folgende Parameter variiert werden:
    • – Anzahl der Anwender (Clients, die parallel auf die Applikation A auf dem Server S zugreifen)
    • – unterschiedliche Workflows (unterschiedliche Abfolgen von Applikationen A)
    • – unterschiedliche Abfolgen von Arbeitsschritten AS innerhalb einer Applikation A
    • – unterschiedliche Verzögerungszeiten
    • – unterschiedliche Hardwareklassen
    • – unterschiedliche technische Gegebenheiten (bzw. Parameter) auf dem Server S und/oder auf den jeweiligen Clients C der Multi-Client-Umgebung.
  • Gemäß einer bevorzugten Ausführungsform der Erfindung wird bei der Simulation davon ausgegangen, dass für jeden Simulationsschritt überprüft wird, ob ausreichend Ressourcen (CPU, Speicher, etc.) auf dem Server zur Ausführung der Applikation vorhanden sind. Falls dies der Fall ist, wird davon ausgegangen (simuliert), dass der jeweilige Applikationsschritt ohne Verzögerung ausgeführt wird. Andernfalls (falls also nicht genügend Ressourcen auf dem Server S bereitstehen) wird bei der Simulation davon ausgegangen, dass der jeweilige Applikationsschritt um einen Applikationsschritt verzögert wird, sodass sich also die Antwortzeiten des Servers S erhöhen. Vorteilhafterweise sind hier noch Voreinstellungen (zum Beispiel bei der exakten Zeitdauer zur Erhöhung der Antwortzeit) voreinstellbar.
  • Folgende exemplarische Einstellungen bzw. Voreinstellungen sind für die geringe Hardwareklasse der Stufe 3.0 möglich:
    CPU: 2 Quad Core: 100%
    Main Memory: 48
    Disc Read max: 160 MB/s
    Disc Write max: 50 MB/s
    Network Send max: 0 MBit/s
    Network Receive max: 0 MBit/s
  • In einer Variante der Erfindung ist es voreinstellbar, auf welche Art und Weise die Simulation durchgeführt werden soll. Vorzugsweise sind hier drei Simulationskonfigurationen möglich bzw. auswählbar:
    • – zufallsbasierte Simulation, die auf einer zufallsbasierten Abfolge von Clients C basiert,
    • – anzahlbasierte Simulation, bei der eine Anzahl von parallel ausführenden Clients bestimmbar ist
    • – manuelle konfigurierte Simulation, bei der die Abfolge von Clients C auf einer manuellen Benutzereingabe basiert, um spezifischen Anwendungsgegebenheiten zu modellieren.
  • Die vorstehende Beschreibung der Erfindung im Zusammenhang mit den bevorzugten Ausführungsbeispielen im Zusammenhang mit der Zeichnung ist nicht einschränkend zu verstehen, sodass auch Kombinationen der erwähnten Merkmale und Ausführungsformen und andere Varianten vom Fachmann abgeleitet werden können, ohne den Schutzumfang der Anmeldung zu verlassen.
  • Zusammenfassend lässt sich die vorliegende Erfindung damit beschreiben, dass ein Simulationstool bereitgestellt wird, mit dem es möglich wird, eine bestimmte technische Hardware-Ausbildung eines Client-Server-basierten Applikationssystems im Vorfeld auf Performanz (unter anderem hinsichtlich Ausführungszeit und Ressourcenbedarf vorzugsweise auf dem Server S) zu überprüfen. Dabei wird eine Applikation zunächst auf einem Referenz-Client in einer Single-Client-Umgebung ausgeführt und dabei werden Messgrößen gemessen und erfasst. Diese werden dann der Simulation zugeführt und anhand des Simulationsalgorithmus zur Simulation des technischen Verhaltens der Applikation in der Multi-Client-Umgebung verwendet.
  • Bezugszeichenliste
    • S
    Server
    S1, S2, S3, ...
    Server 1, Server 2, Server 3
    C
    Client
    Ref-C
    Referenz-Client
    C1, C2, C3,
    Client 1, Client 2, Client 3,
    10
    technische Ressourcen
    11
    Hardware-Ressourcen
    12
    Messgerät zur Erfassung der Ausführungszeit (Performance Counter)
    13
    Ressourcenbestimmungsgerät
    14
    Prozedur- und Applikations-Serializer
    15
    Applikationsklassen-Serializer
    16
    Property-Modul
    17
    Methoden-Modul
    18
    Hardwareklassenbestimmungsgerät
    20
    Applikationsschritt-Verwalter
    N
    Netzwerk
    P
    medizintechnische Prozedur
    SIM
    Simulationsmodul
    V
    Verrechnungsmodul
    A
    Applikation
    A1, A2, A3
    Applikation 1, Applikation 2, Applikation 3
    AS
    Applikationsschritt
    AS1, AS2, AS3
    Applikationsschritt 1, Applikationsschritt 2, Applikationsschritt 3

Claims (11)

  1. Verfahren zur Simulation einer Performance zumindest einer medizintechnischen Prozedur (P), die eine Ausführung einer Vielzahl von Client-Server-basierten Applikationen (A) umfasst, wobei die Applikationen (A) in einer Multi-Client-Umgebung parallel auf mehreren Clients (C) ausgeführt werden sollen, umfassend: – Ausführen der medizintechnischen Prozedur (P) mit den erforderlichen Applikationen (A) auf einem Referenz-Client (REF-C) mit bestimmten Referenz-Ressourcen in einer Single Client-Umgebung – Messen einer tatsächlich benötigten Ausführungszeit und Erfassen der Referenz-Ressourcen bei Ausführung der erforderlichen Applikationen in der Single Client Umgebung – Bestimmen der Clients (C) der Multi-Client-Umgebung – Simulation der Performance der medizintechnischen Prozedur (P) in der Multi-Client-Umgebung, indem die bestimmten Ressourcen der parallel ausführenden Clients (C) der Multi-Client-Umgebung mit der gemessenen tatsächlichen Ausführungszeit und mit den erfassten Referenz-Ressourcen der Single Client-Umgebung in einer zweifachen Iteration verrechnet werden, umfassend eine erste Iteration über die Zeit hinsichtlich eines ermittelten Ressourcenbedarfes und eine zweite Iteration über die bestimmten Clients (C) durch Addition der ermittelten Ressourcenbedarfe in jeweils einem Zeitintervall, – wobei bei der Verrechnung geprüft wird, ob auf einem Server (S) ausreichend Ressourcen vorhanden sind, um in jeweils einem Zeitintervall auszuführende Applikationsschritte (AS) der Applikation (A) ausführen zu können.
  2. Verfahren nach Anspruch 1, bei dem die Simulation der Performance eine Analyse im Falle eines Performance-Engpasses und/oder eine Angabe der Ausführungszeit oder der einen vordefinierbaren Grenzwert überschreitende Verzögerungszeit umfasst.
  3. Verfahren nach Anspruch 2, bei dem die Analyse eine Auswertung, insbesondere eine statische Auswertung, umfasst, durch welche Ressource(n) der Engpass verursacht wird. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die technischen Ressourcen folgende Parameter umfassen: – CPU Auslastung – Speicherbedarf – Input-/Output-Netzwerkbedarf – Input-/Output-Plattenzugriffe – Grafikkartenzugriffe – Zugriffe auf externe Applikationen und/oder Ressourcen.
  4. Verfahren nach einem der vorhergehenden Ansprüche, bei dem ein Vorschlag zur Verbesserung der Performance in Hinblick auf die technischen Ressourcen, eine Datenaustauschverbindung zwischen Client (C) und Server (S), den Server (S) und/oder die Clients (C) ausgegeben wird.
  5. Verfahren nach einem der vorhergehenden Ansprüche, umfassend folgenden Verfahrensschritt: – Bestimmen, welche Applikationsschritte (AS) der Applikation (A) in jeweils einem Zeitintervall bei der Ausführung der Applikation (A) erforderlich sind.
  6. Verfahren nach einem der vorhergehenden Ansprüche, umfassend folgenden Verfahrensschritt: – Bestimmen, welche Applikationen (A) in jeweils einem Zeitintervall bei der Ausführung der medizintechnischen Prozedur (P) auszuführen sind.
  7. Verfahren nach einem der vorhergehenden Ansprüche, wobei bei der Simulation unterschiedliche Abfolgen von Applikationsschritten (AS) der Applikation (A) und/oder unterschiedliche Abfolgen von Applikationen (A) der medizintechnischen Prozedur (P) berücksichtigt und/oder gegenübergestellt werden.
  8. Verfahren nach einem der vorhergehenden Ansprüche, bei dem eine Länge des Zeitintervalls der als Simulationsschritt dient vor-konfigurierbar und/oder bei dem die Anzahl der Clients (C) für die Multi-Client-Umgebung variabel ist.
  9. Verfahren nach einem der vorhergehenden Ansprüche, bei dem ein vor-konfigurierbarer maximaler Schwellenwert für die simulierte Ausführungszeit mit der simulierten Ausführungszeit verglichen wird, um bei Überschreitung automatisch ein Warnsignal auszugeben.
  10. System zur Simulation einer Performance zumindest einer medizintechnischen Prozedur (P), die eine Ausführung einer Vielzahl von Client-Server-basierten Applikationen (A) umfasst, wobei die Applikationen (A) in einer Multi-Client-Umgebung parallel auf mehreren Clients (C) ausgeführt werden sollen, umfassend: – Eine Vielzahl von Clients (C), wobei zumindest ein Client (C) als Referenz-Client (REF-C) dient – Einen Server (S), der zur Ausführung zumindest einer der Applikationen (A) bestimmt ist – Ein Messgerät (12), das zum Messen einer tatsächlich benötigten Ausführungszeit bei Ausführung der erforderlichen Applikationen (A) in der Single Client Umgebung auf dem Referenz-Client (REF-C) bestimmt ist – Ein Hardwarebestimmungsgerät (13), das zum Erfassen der Referenz-Ressourcen bei Ausführung der erforderlichen Applikationen (A) in der Single Client Umgebung bestimmt ist, wobei vorzugsweise nur die Referenz-Ressourcen auf dem Server (S) erfasst werden – Ein Simulationsmodul (SIM), das ein Bestimmungsmodul umfasst zum Bestimmen der Clients (C) der Multi-Client-Umgebung, wobei das Simulationsmodul (SIM) zu Folgendem bestimmt ist: – Simulation der Performance der medizintechnischen Prozedur (P) in der Multi-Client-Umgebung, indem die bestimmten Ressourcen der parallel ausführenden Clients (C) der Multi-Client-Umgebung mit der gemessenen tatsächlichen Ausführungszeit und mit den erfassten Referenz-Ressourcen der Single Client-Umgebung in einer zweifachen Iteration verrechnet werden, umfassend eine erste Iteration über die Zeit hinsichtlich eines ermittelten Ressourcenbedarfes und eine zweite Iteration über die bestimmten Clients (C) durch Addition der ermittelten Ressourcenbedarfe in jeweils einem Zeitintervall, wobei das Simulationsmodul (SIM) ein Verrechnungsmodul (V) umfasst, das dazu ausgebildet ist bei der Verrechnung zu prüfen, ob auf einem Server (S) ausreichend Ressourcen vorhanden sind, um in jeweils einem Zeitintervall auszuführende Applikationsschritte (AS) der Applikation (A) ausführen zu können.
  11. Computerprogrammprodukt ladbar oder geladen in einen Speicher eines Computers mit von dem Computer lesbaren Befehlen zur Ausführung des Verfahrens nach einem der vorstehenden Verfahrensansprüche, wenn die Befehle auf dem Computer ausgeführt werden.
DE102011079429A 2011-07-19 2011-07-19 Performancesimulation von medizintechnischen Prozeduren in einer Client-Server-Umgebung Ceased DE102011079429A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102011079429A DE102011079429A1 (de) 2011-07-19 2011-07-19 Performancesimulation von medizintechnischen Prozeduren in einer Client-Server-Umgebung
US13/552,173 US9286124B2 (en) 2011-07-19 2012-07-18 Simulating the performance of medical-engineering procedures in a client-server environment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102011079429A DE102011079429A1 (de) 2011-07-19 2011-07-19 Performancesimulation von medizintechnischen Prozeduren in einer Client-Server-Umgebung

Publications (1)

Publication Number Publication Date
DE102011079429A1 true DE102011079429A1 (de) 2013-01-24

Family

ID=47501936

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102011079429A Ceased DE102011079429A1 (de) 2011-07-19 2011-07-19 Performancesimulation von medizintechnischen Prozeduren in einer Client-Server-Umgebung

Country Status (2)

Country Link
US (1) US9286124B2 (de)
DE (1) DE102011079429A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022201291A1 (de) 2022-02-08 2023-08-10 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Betreiben einer Cloud-Applikation und zum Auswählen einer Skalierungstrategie

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10514954B2 (en) * 2015-10-28 2019-12-24 Qomplx, Inc. Platform for hierarchy cooperative computing

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003054696A1 (en) * 2001-12-12 2003-07-03 Valve Corporation Method and system for preloading resources
US7493249B2 (en) * 2006-06-23 2009-02-17 International Business Machines Corporation Method and system for dynamic performance modeling of computer application services
US7630862B2 (en) * 2004-03-26 2009-12-08 Microsoft Corporation Load test simulator
US7805496B2 (en) * 2005-05-10 2010-09-28 International Business Machines Corporation Automatic generation of hybrid performance models

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4961224A (en) * 1989-03-06 1990-10-02 Darby Yung Controlling access to network resources
GB2296565B (en) * 1994-12-23 1999-06-16 Intravascular Res Ltd Ultrasound imaging
JP3730740B2 (ja) * 1997-02-24 2006-01-05 株式会社日立製作所 並列ジョブ多重スケジューリング方法
US6898564B1 (en) * 2000-05-23 2005-05-24 Microsoft Corporation Load simulation tool for server resource capacity planning
US7167821B2 (en) * 2000-06-06 2007-01-23 Microsoft Corporation Evaluating hardware models having resource contention
US6591262B1 (en) * 2000-08-01 2003-07-08 International Business Machines Corporation Collaborative workload management incorporating work unit attributes in resource allocation
JP2002219119A (ja) * 2000-10-24 2002-08-06 Siemens Ag 医学システムアーキテクチャ
US7133842B2 (en) * 2000-12-29 2006-11-07 International Business Machines Corporation System, method and program for bidding for best solution process execution in a heterogeneous network
US7334228B2 (en) * 2001-07-27 2008-02-19 International Business Machines Corporation Runtime-resource management
US8122453B2 (en) * 2003-02-04 2012-02-21 International Business Machines Corporation Method and system for managing resources in a data center
US7107187B1 (en) * 2003-11-12 2006-09-12 Sprint Communications Company L.P. Method for modeling system performance
JP3896111B2 (ja) * 2003-12-15 2007-03-22 株式会社日立製作所 リソース割り当てシステム、方法及びプログラム
DE102004001680B4 (de) * 2004-01-12 2012-07-05 Siemens Ag Dynamische Steuerung von Rechnerressourcen bei der Pipelineverarbeitung von Daten unter Verwendung von Anytime Algorithmen
US7543020B2 (en) * 2005-02-10 2009-06-02 Cisco Technology, Inc. Distributed client services based on execution of service attributes and data attributes by multiple nodes in resource groups
US7870256B2 (en) * 2005-03-25 2011-01-11 Hewlett-Packard Development Company, L.P. Remote desktop performance model for assigning resources
US20070094668A1 (en) * 2005-10-17 2007-04-26 Jacquot Bryan J Method and apparatus for dynamically allocating resources used by software
US7958509B2 (en) * 2005-12-21 2011-06-07 International Business Machines Corporation Method and system for scheduling of jobs
DE102006027222A1 (de) * 2006-06-12 2007-12-13 Siemens Ag Verfahren und Vorrichtung zum Betrieb medizintechnischer Computerapplikationen in einem Computernetzwerk
US8108844B2 (en) * 2006-06-20 2012-01-31 Google Inc. Systems and methods for dynamically choosing a processing element for a compute kernel
US8375368B2 (en) * 2006-06-20 2013-02-12 Google Inc. Systems and methods for profiling an application running on a parallel-processing computer system
US8341611B2 (en) * 2007-04-11 2012-12-25 Apple Inc. Application interface on multiple processors
WO2009009204A2 (en) * 2007-04-20 2009-01-15 Edison Welding Institute, Inc. Remote high-performance computing material joining and material forming modeling system and method
US8069021B2 (en) * 2007-09-28 2011-11-29 Rockwell Automation Technologies, Inc. Distributed simulation and synchronization
DE102008004658B4 (de) * 2008-01-16 2010-03-25 Siemens Aktiengesellschaft Verfahren zur zentralen Steuerung von Prozessen in erweiterbaren medizinischen Plattformen
EP2422305A4 (de) * 2009-04-22 2013-07-10 Lead Horse Technologies Inc Auf künstlicher intelligenz basierendes medizinisches referenzsystem und verfahren
US8498728B2 (en) * 2009-10-19 2013-07-30 Edison Welding Institute, Inc. Remote high-performance modeling system for material joining and material forming
US8250213B2 (en) * 2009-11-16 2012-08-21 At&T Intellectual Property I, L.P. Methods and apparatus to allocate resources associated with a distributive computing network
US20110154355A1 (en) * 2009-12-22 2011-06-23 Siemens Aktiengesellschaft Method and system for resource allocation for the electronic preprocessing of digital medical image data
US20110191821A1 (en) * 2010-01-29 2011-08-04 Open Imaging, Inc. Controlled use medical application
US9003416B2 (en) * 2010-09-29 2015-04-07 International Business Machines Corporation Predicting resource requirements for a computer application
US8874457B2 (en) * 2010-11-17 2014-10-28 International Business Machines Corporation Concurrent scheduling of plan operations in a virtualized computing environment
US8744870B2 (en) * 2010-12-10 2014-06-03 Infosys Limited Method and system for forecasting clinical pathways and resource requirements

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003054696A1 (en) * 2001-12-12 2003-07-03 Valve Corporation Method and system for preloading resources
US7630862B2 (en) * 2004-03-26 2009-12-08 Microsoft Corporation Load test simulator
US7805496B2 (en) * 2005-05-10 2010-09-28 International Business Machines Corporation Automatic generation of hybrid performance models
US7493249B2 (en) * 2006-06-23 2009-02-17 International Business Machines Corporation Method and system for dynamic performance modeling of computer application services

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022201291A1 (de) 2022-02-08 2023-08-10 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Betreiben einer Cloud-Applikation und zum Auswählen einer Skalierungstrategie

Also Published As

Publication number Publication date
US20130024498A1 (en) 2013-01-24
US9286124B2 (en) 2016-03-15

Similar Documents

Publication Publication Date Title
EP2685382B1 (de) Verfahren und Vorrichtung zum Erstellen und Testen eines Steuergeräteprogramms
DE60017457T2 (de) Verfahren zur isolierung eines fehlers in fehlernachrichten
CH709322B1 (de) System, Verfahren und Computer zur verbesserten automatisierten visuellen Inspektion eines physischen Guts.
EP2897011B1 (de) Verfahren und Simulationsanordnung zur Simulation einer automatisierten Industrieanlage
EP2442248B1 (de) Kopplungsmethodik für nicht-iterative Co-Simulation
DE102005010900A1 (de) Modellspezifische Registeroperationen
EP1736907A2 (de) Verbesserung von Messdaten-Erfassung- und Bild-Rekonstruktion bei MR-Bildern
DE102004057021A1 (de) Verfahren und System zum Testen eines Computersystems durch ein Anlegen einer Last
DE10127170A1 (de) Fehlersuchverfahren und Fehlersuchvorrichtung
DE102005036321A1 (de) Verfahren und Vorrichtung zum dynamischen Generieren von Testszenarien für komplexe rechnergesteuerte Systeme, z.B. für medizintechnische Anlagen
DE102006019292A1 (de) Modellieren programmierbarer Einrichtungen
EP3188053A1 (de) Verfahren zum konfigurieren einer co-simulation für ein gesamtsystem
DE102021116906A1 (de) Test- und messsystem zur analyse von zu testenden vorrichtungen
DE102014102551A1 (de) Maschine und Verfahren zum Evaluieren von fehlschlagenden Softwareprogrammen
EP1657670A1 (de) System und Verfahren zur Status- und Fortschriftskontrolle eines technischen Prozesses oder eines technischen Projektes
DE102018104070A1 (de) System und verfahren zur auswahl einer computerplattform
DE112009000211T5 (de) Programmprüfvorrichtung und -programm
EP3232327B1 (de) Verfahren zum testen eines steuerprogramms eines steuergeräts in einer simulationsumgebung auf einem rechner
DE112011100168T5 (de) Erfassen von Diagnosedaten in einer Datenverarbeitungsumgebung
DE102006052223A1 (de) Steuerung eines Magnetresonanz-Tomographen
DE112021003677T5 (de) Automatisierte unterstützte schaltkreisvalidierung
DE102011079429A1 (de) Performancesimulation von medizintechnischen Prozeduren in einer Client-Server-Umgebung
EP2492701A1 (de) Verfahren und Vorrichtung zum Testen einer Windturbinenanlage
CN102769774B (zh) 宽带视频网络系统中实现跨平台视频服务质量诊断的方法
DE102005056250A1 (de) Verfahren bzw. Computerprogrammprodukt zur Bestimmung der Leistung eines Computersystems

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R081 Change of applicant/patentee

Owner name: SIEMENS HEALTHCARE GMBH, DE

Free format text: FORMER OWNER: SIEMENS AKTIENGESELLSCHAFT, 80333 MUENCHEN, DE

R016 Response to examination communication
R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final