-
Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung zur dynamischen Steuerung, vorzugsweise zum dynamischen Zuweisen, von Rechnerressourcen auf eine Vielzahl von Pipeline-Prozessoren einer Pipeline bei der Verarbeitung von Prozessdaten unter veränderlichen Laufzeitbedingungen.
-
Bei der Verarbeitung von Daten auf dem medizinischen Gebiet sind die Rahmenbedingungen häufig sehr unterschiedlich: Zum einen gibt es Anwendungen, die ein sehr schnelles Verarbeiten der Daten erfordern, wie z. B. bei der Prozessdatenverarbeitung im Umfeld einer chirurgischen Operation, beispielsweise bei computergesteuerten minimal invasiven Eingriffen. Zum anderen existieren anderen Anwendungen, bei denen verstärkt auf eine möglichst umfassende Datenerfassung geachtet werden muss und bei denen die Verarbeitungszeit von geringerer Bedeutung ist, wie z. B. bei einer Analyse von bereits erfassten Daten eines Patienten im Zusammenhang mit dem Aufstellen eines Behandlungsplanes.
-
Daraus ergibt sich, dass je nach Anwendung und Einsatzzweck in ganz unterschiedlicher Weise auf die zur Verfügung stehenden Rechnerressourcen zugegriffen wird.
-
Aus den oben beispielhaft skizzierten Anwendungsfällen ergibt sich, dass die Verarbeitungsprozesse teilweise über einen relativ langen Zeitraum aktiv sind. Dies kann dazu führen, dass die aktuell zur Verfügung stehenden Rechnerressourcen über die Dauer der Verarbeitung schwanken.
-
Bei bisherigen Systemen aus dem Stand der Technik konnten diese Schwankungen der Laufzeitbedingungen und/oder der Rechnerressourcen nicht berücksichtigt werden. Es wurde von festen, d. h. zu einem Zeitpunkt erfassten Laufzeitparametern ausgegangen. Von daher erwiesen sich vielfach Anwendungen als defizitär, wenn während der Laufzeit Änderungen hinsichtlich der Systemkomponenten auftreten, z. B. dass für einen Verarbeitungsprozess nicht genügend Rechenkapazität zur Verfügung steht oder dass ein Verarbeitungsergebnis in ungenügender Qualität generiert wird (beispielsweise ein Bild, das mit einer viel zu geringen Auflösung dargestellt wird und von daher nicht brauchbar ist).
-
Bisherige Lösungen basierten auf einem monolithischen Verarbeitungskonzept, das weder eine Modularisierung der Verarbeitungsprozesse noch eine Flexibilität gegenüber variablen Systemparametern zuließ.
-
So zeigt der Fakultätsbericht „Globale dynamische Lastbalancierung in datenintensiven Anwendungen”, W. Becker, Bericht Nr. 1993/1, August 1998, dass es bekannt ist, einer Applikation zugeordnete Algorithmen auf unterschiedliche Prozesse derart aufzuteilen, dass die Verarbeitungszeit optimiert werden kann.
-
Aus der Konferenzveröffentlichung „Using Uncertainty within Computation”, D. Bernstein et al., AAAI 2001, Fall Symposium, Nov. 2001, ist es weiterhin bekannt, eine untere und obere Grenze als Optimierungsproblem für eine besondere Art von Any-Time-Algorithmen, den Contract-Algorithmen, bereitzustellen. Im Gegensatz zu einem sequentiellen Pipeline-Ansatz basiert dieses Modell auf einem Parallelverarbeitungsansatz.
-
Ebenfalls ist es aus dem Aufsatz „Decision-Theoretic Control of Inference for Time-Critical Applications”, Dean, T., Technical Report No. CS-89-44, Brown University, Dep. of Computer Science, Rhode Island 02912, 1990 bekannt, zeitkritische Applikationen nach entscheidungstheoretischen Kriterien zu optimieren.
-
Weiterhin kann der Fachmann dem Aufsatz „Monitoring and control of anytime algorithms: A dynamic programming approach”, E. A. Hansen, S. Zilberstein, Artificial Intelligence, Vol. 126, Issue 1–2, pp. 139–157, 2001, Elsevier Science Publishers Ltd. einen dynamischen Ansatz zur Steuerung von Anytime-Algorithmen entnehmen, bei dem Parameter zur Laufzeit überwacht werden.
-
Besonders einige Echtzeitsysteme auf dem Gebiet der Medizintechnik erfordern jedoch die garantierte Einhaltung von vorgegebenen Zeitbedingungen. So ist es für diese Systeme charakteristisch, dass z. B. innerhalb eines vordefinierten Zeitfensters ein Verarbeitungsprozess fertiggestellt, Messdaten erfasst bzw. verarbeitet oder bestimmte Tasks angestoßen sein müssen.
-
In Bezug auf die medizinische Datenverarbeitung von Bilddaten können die aktuellen Anforderungen an den Verarbeitungsprozess insgesamt jedoch sehr unterschiedlich sein. Sollen z. B. Bilder im Rahmen einer Befundanalyse verarbeitet werden, so ist ein maximaler Genauigkeitsgrad der Bilder entscheidend. Wie lange der Verarbeitungsprozess zur Darstellung der Bilder dauert ist in diesem Fall von nachrangiger Bedeutung. Im Gegensatz dazu muss aber z. B. die Datenabfrage von Bildern im Rahmen eines operativen Eingriffs mit einem minimalen Zeitaufwand erfolgen. Hier steht also die Einhaltung der zeitlichen Rahmenbedingungen im Vordergrund. Ein System, das für verschiedene Anwendungen ausgelegt und anwendbar ist (wie z. B. ein System zur Verarbeitung von medizinischen Bilddaten), sollte deshalb auf sich zur Laufzeit des Prozesses ändernde Systembedingungen und auch auf sonstige Bedingungen flexibel reagieren können.
-
Vergegenwärtigt man sich nun weiterhin, dass eine Vielzahl von Prozessen zeitgleich ablaufen, so wird deutlich, dass die System- oder Rechnerressourcen über die Zeit sehr starken Schwankungen unterliegen.
-
Systeme, die auf einmal erfassten Rechnerressourcen basieren und nicht flexibel auf Schwankungen hinsichtlich der Rechnerressourcen eingehen können, sind zum einen fehleranfällig und zum anderen ermöglichen sie es nicht, die Systemressourcen für den aktuellen Prozess optimal auszunutzen. Sollen z. B. Bildverarbeitungsergebnisse angezeigt werden, während sich die verfügbaren Ressourcen zur Laufzeit des Prozesses ändern, so wäre es wünschenswert, den aktiven Verarbeitungsprozess dynamisch an die veränderten, aktuell verfügbaren Ressourcen anzupassen, ohne den Verarbeitungsprozess unterbrechen zu müssen.
-
Bekannt sind Pipeline Konzepte für die Verarbeitung von Prozessdaten. Das Pipeline Konzept basiert auf einer sequentiellen Verarbeitung durch eine Vielzahl von hintereinander geschalteten Pipeline Elementen oder Pipeline-Prozessoren. Um dies zu ermöglichen, muss der Verarbeitungsprozess so strukturiert werden, dass er in kompakte, kleinere Module zerlegt werden kann. Diesen Verarbeitungsmodulen werden dann einzelne Pipeline-Prozessoren zugeordnet. Damit entsteht der Vorteil, dass diese einzelnen Module leichter erstellt, validiert und an neue Anforderungen angepasst werden können, als wenn man einen monolithischen Gesamtblock hätte.
-
Mit dem Pipeline Konzept ist weiterhin der Vorteil verbunden, dass eine bessere Lastverteilung des Gesamtsystems erzielt werden kann.
-
Auch ist es durch die Modularität des Systems möglich, sehr flexibel einzelne Module auf andere Art oder mit anderen Modulen zu kombinieren. Damit kann das Gesamtsystem geändert werden, ohne dass die Module an sich neu erstellt werden müssen.
-
Aus einem anderen Umfeld sind sogenannte Anytime Algorithmen bekannt. Anytime Algorithmen wurden für Echtzeitsysteme entwickelt und sind bisher für Systeme auf dem Gebiet der Künstlichen Intelligenz und der Robotik eingesetzt worden und basieren auf dem Ansatz, dass ein Verarbeitungsergebnis zu jedem vordefinierbaren Zeitpunkt generiert werden kann. Je nach Umfang des Zeitintervalls, das für den Verarbeitungsprozess zur Verfügung steht, wird das Ergebnis in unterschiedlichen Qualitäts- oder Gütestufen generiert: Ist das Zeitintervall kurz, so ist die Gütestufe für das Verarbeitungsergebnis geringer; ist das Zeitintervall lang, so ist die Gütestufe für das Verarbeitungsergebnis höher. Mit dem Anytime Ansatz wird es möglich, die Güte bzw. Qualität des Verarbeitungsergebnisses der Verarbeitungszeit gegenüberzustellen und diese beiden Faktoren gegeneinander abzuwägen. Bei Anytime Systemen kann die Verarbeitungszeit sozusagen vom Anwender bestimmt bzw. gewählt werden. Das Anytime Konzept erfordert eine teilweise redundante Verarbeitung von Daten und ist insofern mit dem Ansatz der Parallelverarbeitung verwandt.
-
Im Unterschied dazu basiert die Pipelineverarbeitung auf einem rein sequentiellen Ansatz.
-
Die Erfindung basiert auf einer Kombination des Pipeline- und des Anytime-Ansatzes.
-
Ausgehend vom eingangs erwähnten Stand der Technik hat sich die vorliegende Erfindung deshalb zur Aufgabe gesetzt, einen Weg aufzuzeigen, mit dem die Rechnerressourcen zur Laufzeit dynamisch den Verarbeitungs-Prozessoren zugewiesen werden können, ohne dass der Verarbeitungsprozess unterbrochen werden muss.
-
Die Aufgabe wird durch ein Verfahren nach beiliegendem Patentanspruch 1 und durch eine Vorrichtung nach beiliegendem Patentanspruch 10 gelöst.
-
Gemäß einem Aspekt dient das Verfahren zur dynamischen Steuerung von allgemeinen Systemressourcen in Bezug auf mehrere Prozessoren, die vorzugsweise in einer Pipeline angeordnet sein können, bei der Verarbeitung von Prozessdaten unter veränderlichen Laufzeitbedingungen. Das Verfahren sieht weiterhin vor, dass:
- – ein SOLL-Wert für eine gesamte Verarbeitungszeit erfasst wird
- – ein Monitoring zur Laufzeit erfolgt, das einen IST-Wert für die Verarbeitungszeit jeweils eines einzelnen Prozessors erfasst,
- – ein Logging von Meta-Daten bezüglich der Verarbeitung des jeweiligen Prozessors zur Laufzeit erfolgt,
- – ein Anytime-Algorithmus angewendet wird, der jeweils einem Prozessor zugeordnet ist und der ein Ergebnis der Verarbeitung des jeweiligen Prozessors zu einem beliebig wählbaren Zeitpunkt, insbesondere vom Anwender wählbaren Zeitpunkt, generiert, und dass
- – ein Control Mechanismus angewendet wird, der zur dynamischen Steuerung der Rechnerressourcen in Hinblick auf die Prozessoren in Abhängigkeit von dem IST-Wert bestimmt ist, wobei Daten, zumindest umfassend Prozessdaten (10) und Meta-Daten (18), von einem i-ten Pipeline-Prozessor (Pi) zu einem nachfolgenden, i + 1-ten Pipeline-Prozessor (Pi + 1) weitergeleitet werden.
-
Vorzugsweise sind die Prozessoren als Pipeline-Prozessoren ausgebildet, also in einer Pipeline angeordnet. Es ist jedoch auch denkbar, dass die Prozessoren zwar ebenfalls modular agieren aber nach einer anderen Struktur funktional miteinander interagieren.
-
Vorzugsweise umfasst die Aufgabenlösung einen weiteren Schritt, nämlich das Erfassen eines SOLL-Wertes für eine gesamte Verarbeitungszeit. Dieser SOLL-Wert kann vom Anwender eingegeben werden oder kann automatisch aus anderen Systemeigenschaften ermittelt werden. Ist dieser SOLL-Wert erfasst, wird dieser auch bei dem Control Mechanismus berücksichtigt, als dass dieser die Steuerung insbesondere das Zuweisen von Rechnerressourcen auf die Prozessoren in Abhängigkeit von dem IST- und dem SOLL-Wert vornimmt.
-
Eine weitere Aufgabenlösung liegt in einer Vorrichtung nach Anspruch 10.
-
In der bevorzugten Ausführungsform der Erfindung ist der Control Mechanismus zur Laufzeit aktiviert. Es ist jedoch auch möglich, dass der Control Mechanismus bereits im Vorfeld oder in weiteren zeitlich ggf. nachgelagerten Zeitabschnitten aktiv ist. Der Control Mechanismus ist derart ausgelegt, dass er auch unter variablen Laufzeitbedingungen die aktuell verfügbaren Rechnerressourcen steuert. Insbesondere ist er zur Zuweisung der verfügbaren Ressourcen auf die Pipeline-Prozessoren bestimmt. Damit wird der Vorteil erzielt, dass die Verarbeitungsressourcen für den jeweiligen Verarbeitungsprozess während des Ablaufs und damit mit maximaler Aktualität geplant werden können. Damit ist es möglich, auf spezifische Anforderungen, die indirekt Systemparameter betreffen, einzugehen und ein optimales Verarbeitungsergebnis zu erzielen.
-
Das Verfahren ist in der bevorzugten Ausführungsform so ausgelegt, dass das Monitoring kontinuierlich und/oder in vorbestimmbaren Zeitintervallen erfolgt. Damit kann der Anwender den Grad der gewünschten Aktualität und Flexibilität wählen.
-
Vorteilhafterweise greift der Control Mechanismus auf einen Execution-Time-Scheduler zu, der die Rechnerressourcen zur Laufzeit und ohne eine Unterbrechung der Verarbeitung der Prozessdaten dynamisch den Pipeline-Prozessoren derart zuweist, dass der SOLL-Wert für die gesamte Verarbeitungszeit eingehalten wird. Es ist jedoch auch möglich, dass der Control Mechanismus selbst so ausgelegt ist, dass der die Rechnerressourcen zur Laufzeit dynamisch den Pipeline-Prozessoren zuweist unter Berücksichtigung von IST- und SOLL-Wert. Dabei soll der IST-Wert dem SOLL-Wert angeglichen werden.
-
Die Meta-Daten umfassen zumindest Information über die Verarbeitungszeit (Timing Information) des jeweiligen Pipeline-Prozessors. Hier können aber noch weitere Verarbeitungsdaten in Bezug auf den jeweiligen Prozessor, wie z. B. Qualitätsstufe des Verarbeitungsergebnisses, Prozessorleistung, freier Speicherplatz etc. abgelegt sein. Diese Meta-Daten werden neben den Prozessdaten von Pipeline-Prozessor zu Pipeline-Prozessor weiter gereicht. Damit ist ein Pipeline-Prozessor immer über den exakt aktuellen Verarbeitungsstatus und/oder das Ergebnis des vorhergehenden Prozessors informiert.
-
Die hohe Variabilität des Systems ist darin zu sehen, dass der Anwender die Verarbeitungszeit nahezu frei bestimmen kann. Abhängig von seiner Wahl der Verarbeitungszeit ist die Qualität bzw. Güte des Verarbeitungsergebnisses. Die gesamte Verarbeitungszeit wird über den SOLL-Wert vom Anwender definiert. Dieser kann auch zur Laufzeit verändert oder erstmals eingestellt werden. Die Qualitätsstufe des Verarbeitungsergebnisses ergibt sich unmittelbar aus diesem SOLL-Wert.
-
Ein wichtiger Vorteil des Verfahrens ist darin zu sehen, dass der SOLL-Wert für die Verarbeitungszeit auch zur Laufzeit dynamisch einstellbar ist, ohne, dass die Verarbeitung der Prozessdaten unterbrochen werden muss. Sollen beispielsweise Bildverarbeitungsergebnisse dargestellt werden und werden die Anforderungen während der Berechnung verändert (z. B. die zur Verfügung stehende Zeit wird verkürzt), so können schritthaltend mit dieser Änderung Bildverarbeitungsergebnisse angezeigt werden (bezogen auf vorstehendes Beispiel: mit einer verringerten Qualität bzw. Auflösung).
-
Die Meta-Daten werden vorzugsweise dezentral und/oder parallel in den Pipeline-Prozessoren erfasst. Damit können Ressourcenzuweisungen oder sonstige Einstellungen kontinuierlich angepasst oder verändert werden.
-
Die erfassten Meta-Daten werden an den Execution Time Scheduler weitergeleitet und von ihm verarbeitet. Das Ergebnis dieser Steuerungsaufgabe kann dann wieder zu einer Neuverteilung der Rechnerressourcen führen. Bei längeren Verarbeitungszyklen sehen das Verfahren und das System hier einen iterativen Prozess vor.
-
Die Aufgabenlösung nach Anspruch 10 sieht eine Anordnung vor, die mehrere Elemente umfasst: vorzugsweise ist ein Erfassungsmodul, ein Monitoringmodul, eine Logging-Einheit, eine Anytime-Einheit, die jeweils einem Pipeline-Prozessor zugeordnet ist, und eine Control-Einheit vorgesehen. Das heißt, bezogen auf die gesamte Anordnung, sind eine Vielzahl von Pipeline-Prozessoren und diesen jeweils zugeordneten Anytime Einheiten vorgesehen. Bevorzugterweise ist die Logging-Einheit ebenfalls modular aufgebaut und ist dem jeweiligen Pipeline-Prozessor zugeordnet. Die Control-Einheit ist vorzugsweise als zentrales Bauteil ausgebildet, der mit allen Pipeline-Prozessoren der Pipeline und mit dem Erfassungsmodul in Datenaustausch steht. Alternativ kann vorgesehen sein, dass einem Pipeline-Prozessor nicht nur eine Anytime Einheit zugeordnet ist, sondern ein Verbund von Anytime Einheiten, die alle auf die Funktionalität des jeweiligen Pipeline-Prozessors bezogen sind.
-
Die vorstehend beschriebenen Ausführungsformen des Verfahren können auch als Computerprogrammprodukt ausgebildet sein, mit einem von einem Computer lesbaren Medium und mit einem Computerprogramm und zugehörigen Programmcode-Mitteln, wobei der Computer nach Laden des Computerprogramms zur Durchführung des oben beschriebenen Verfahrens veranlasst wird.
-
Eine alternative Aufgabenlösung sieht ein Speichermedium vor, das zur Speicherung des vorstehend beschriebenen, computerimplementierten Verfahrens bestimmt ist und von einem Computer lesbar ist.
-
Zusätzliche, vorteilhafte Ausführungsformen ergeben sich aus den Unteransprüchen.
-
In der folgenden detaillierten Figurenbeschreibung werden Ausführungsbeispiele mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnung besprochen. In dieser zeigen:
-
1 eine schematische Übersicht über eine beispielhafte Architektur mit drei Pipeline-Prozessoren und
-
2 ein Ablaufdiagramm über den Ablauf gemäß einer bevorzugten Ausführungsform.
-
Unter Bezugnahme auf 1 wird nachfolgend die grundlegende Struktur des Systems erläutert. Für die Verarbeitung von Prozessdaten 10 ist eine Pipeline 12 vorgesehen, die aus mehreren, vorzugsweise in Reihe geschalteten Pipeline-Prozessoren Pi besteht, dabei kennzeichnet die Bezugsziffer Pi den i-ten Pipeline-Prozessor. Den verschiedenen Pipeline-Prozessoren Pi werden, abhängig von der Aufgabe (also von der Art der Verarbeitung der Prozessdaten 10) unterschiedliche Tasks zugeordnet.
-
Ziel ist es, dass nach einem Durchlauf durch die Verarbeitungspipeline 12 ein Verarbeitungsergebnis generiert wird.
-
Bei komplexen Systemen und/oder bei komplexen Verarbeitungsaufgaben ergeben sich häufig Schwankungen hinsichtlich der Verfügbarkeit von Rechnerressourcen – und dies auch zur Laufzeit des Verarbeitungsvorganges –. Das kann möglicherweise dazu führen, dass eine zu Beginn des Verarbeitungsvorganges getroffenen Einstellung oder Festlegung hinsichtlich der Ressourcen sich zu einem späteren Zeitpunkt als unzutreffend erweist, was sich insgesamt negativ für das Verarbeitungsergebnis auswirkt.
-
Um auf diese Schwankungen auch zur Laufzeit flexibel reagieren zu können, ist es vorgesehen, die jeweiligen Pipeline-Prozessoren Pi der Pipeline 12 jeweils mit einem oder mehreren Anytime Algorithmen auszubilden. Das hat zur Folge, dass die Zeitspanne, die notwendig ist, um das Verarbeitungsergebnis des jeweiligen Pipeline-Prozessors Pi zu generieren, variabel eingestellt werden kann – in Abhängigkeit von einer Qualitäts- oder Gütestufe des Verarbeitungsergebnisses. Damit wird es möglich, die Ressourcen auch zur Laufzeit optimal auf die Pipeline-Prozessoren Pi zu verteilen.
-
Ein Erfassungsmodul 16 dient zur Erfassung eines SOLL-Wertes für die gesamte Verarbeitungszeit. Dieser SOLL-Wert kann vom Anwender, abhängig von den aktuellen Systemanforderungen, eingestellt werden. Das Erfassungsmodul 16 steht in Datenaustausch mit einem Control Mechanismus. Der Control Mechanismus dient zur Steuerung der Ressourcen in Hinblick auf die Pipeline-Prozessoren Pi. Der Control Mechanismus umfaßt ein zentrales Bauteil, nämlich den Execution Time Scheduler 20. Der Execution Time Scheduler 20 steht in Datenaustausch mit den für den Verarbeitungsprozess aktivierten bzw. benötigten Pipeline-Prozessoren Pi und mit dem Erfassungsmodul 16 (in der Zeichnung nicht dargestellt).
-
In dem in 1 dargestellten Beispiel besteht die Pipeline 12 aus drei Pipeline-Prozessoren P1, P2 und P3. Als zentrales Element ist der Execution Time Scheduler 20 vorgesehen. Jeder Pipeline-Prozessor Pi erfaßt seine Verarbeitungszeit (in der Zeichnung als ”ProcTime” bezeichnet). Meta-Daten 18 umfassen hauptsächlich diese vorgenannten Timing Informationen. Wesentlich ist, dass zusätzlich zu den zu verarbeitenden Prozessdaten 10 auch die Meta-Daten 18 von Pipeline-Prozessor Pi zu nachfolgendem Pipeline-Prozessor Pi + 1 weitergeleitet werden. Nach Durchlaufen der Pipeline 12 werden diese Verarbeitungszeiten akkumuliert und in dem Execution Time Scheduler 20 verarbeitet. Diese Zeiten beziehen sich auf die aktuellen Verarbeitungszeiten und definieren von daher einen IST-Wert für die Verarbeitungszeit eines jeweiligen Pipeline-Prozessors Pi. Der vom Erfassungsmodul 16 erfasste SOLL-Wert der Verarbeitung wird auch dem Execution Time Scheduler 20 zugeführt. Deshalb ist der Execution Time Scheduler 20 in der Lage, den IST-Wert und den SOLL-Wert in Bezug zueinander zu setzen und die Ressourcen so zuzuweisen, dass bei dem folgenden Durchlaufen der Pipeline 12 oder nach einer Sequenz von Pipelinedurchläufen der IST-Wert dem SOLL-Wert angepasst wird.
-
In 2 ist ein Ablaufdiagramm dargestellt, das den grundlegenden Ablauf der Verfahrensschritte gemäß der bevorzugten Ausführungsform zeigt.
-
Da eine Vielzahl von Pipeline-Prozessoren Pi vorgesehen sind, die – je nach Anwendungsfall – unterschiedliche Tasks erfüllen, ist es nicht immer zwingend, dass alle Pipeline-Prozessoren Pi für die jeweilige Verarbeitung notwendig sind. Deshalb werden in einem ersten Schritt die Pipeline-Prozessoren Pi erfasst, die für den aktuellen Verarbeitungsprozess erforderlich sind.
-
Zur Laufzeit werden dann die jeweiligen Verarbeitungszeiten der einzelnen Pipeline-Prozessoren Pi erfasst und überwacht. Dieses Monitoring findet auch zur Laufzeit statt.
-
In einem weiteren Verfahrensschritt, der in einer alternativen Ausführungsform auch zeitlich vorgelagert sein kann, werden die Laufzeitbedingungen erfasst. Hierunter fallen Parameter, wie insbesondere zur Verfügung stehende Rechnerressourcen, Art der gewünschten Verarbeitung und andere Parameter. Ebenso wird der SOLL-Wert erfasst, der eine Aussage über die gewünschte gesamte Verarbeitungszeit bzw. über die Qualitätsstufe des Verarbeitungsergebnisses macht.
-
Die erfassten Werte, von denen einige auch zur Laufzeit und andere im Vorfeld vor der eigentlichen Verarbeitung ermittelt werden können, werden dem Execution Time Scheduler 20 zugeführt. Dieser errechnet aufgrund der Werte eine optimale Belegung der Pipeline-Prozessoren Pi mit den aktuell verfügbaren Rechnerressourcen. Oder mit anderen Worten errechnet der Execution Time Scheduler 20, wie viel Verarbeitungszeit ein Pipeline-Prozessor Pi verbrauchen darf, damit der SOLL-Wert für den gesamten Verarbeitungsprozess eingehalten werden kann. Den Pipeline-Prozessoren Pi werden also Verarbeitungszeiten zugewiesen, innerhalb derer sie das Ergebnis an den nächsten Pipeline-Prozessor Pi + 1 weiterreichen müssen.
-
Mögliche Interdependenzen zwischen den Verarbeitungszeiten der einzelnen Pipeline-Prozessoren Pi können durch Erfassen von zusätzlichen Interdependenz-Daten verarbeitet werden. Ist es beispielsweise notwendig, dass ein i-ter Pipeline-Prozessor Pi von seinem Vorgänger, dem Pipeline-Prozessor Pi – 1 weiß, in welcher Qualitätsstufe er sein Ergebnis erzeugt hat, so ist es möglich, diese Information bei den Meta-Daten 18 zu übermitteln.
-
Nach Durchlaufen der Pipeline 12 wird überprüft, ob das Ergebnis der Pipelineverarbeitung mit dem SOLL-Wert übereinstimmt. Falls dies bejaht wird, ist das Verfahren beendet. Andernfalls kann die Pipeline 12 iterativ durchlaufen werden, bis der IST-Wert mit dem SOLL-Wert übereinstimmt.
-
Es ist jedoch auch möglich, dass der SOLL-Wert nur einmal zu Beginn der Verarbeitung und nicht dynamisch zur Laufzeit erfasst wird. Dies vereinfacht zwar das Verfahren, führt jedoch auch zu einer eingeschränkten Flexibilität, denn dann ist der Soll-Wert fest definiert und kann nicht dynamisch variiert werden.
-
Das wesentliche Architekturkonzept liegt auf der Anpassungsmöglichkeit der Systembedingungen zur Laufzeit. Verändern sich z. B. die Anforderungen an das Verarbeitungsergebnis der Prozessdaten 10 oder verändern sich die verfügbaren Rechnerressourcen zur Laufzeit, so kann sofort und unmittelbar eine Anpassung der Verteilung der Verarbeitungszeiten in den Pipeline-Prozessoren Pi bzw. in den Stufen der Pipeline 12 erfolgen, ohne dass die Verarbeitung unterbrochen werden muss. Beispielsweise werden Bilder, die bereits teilweise berechnet sind, nach den geänderten, neuen Rahmenbedingungen weiter berechnet.
-
Durch die Verwendung des Pipelinekonzeptes wird es möglich, dass parallel also gleichzeitig mehrere Tasks (z. B. Darstellen von Bildern) in den unterschiedlichen Stufen der Pipeline 12 abgearbeitet werden. Dies führt zu einer deutlichen Zeiteinsparung, da Berechnungen teilweise parallel ausgeführt werden können. Insgesamt bringt dies den Vorteil einer verbesserten Lastverteilung und nützt die positiven Eigenschaften von Multiprozessorsystemen aus.
-
Mit der Verwendung eines Anytime Ansatzes bei der Architektur der einzelnen Pipeline-Prozessoren Pi wird ein Abwägen zwischen der Verarbeitungszeit einerseits und der Qualität des Verarbeitungsergebnisses andererseits möglich. Damit kann wesentlich flexibler auf Systemänderungen reagiert werden, was bei Verfahren nach dem Stand der Technik teilweise gar nicht möglich war. Auch kann erreicht werden, dass die verfügbaren Ressourcen zu jedem Zeitpunkt optimal auf die aktiven Verarbeitungsmodule, insbesondere auf die Pipeline-Prozessoren Pi, verteilt werden können.
