DE102005010580A1

DE102005010580A1 - Verfahren zur Echtzeitanalyse eines Systems

Info

Publication number: DE102005010580A1
Application number: DE102005010580A
Authority: DE
Inventors: Frank Dr. Slomka; Karsten Albers
Original assignee: Inchron GmbH
Current assignee: INCHRON GMBH, 14482 POTSDAM, DE
Priority date: 2005-03-04
Filing date: 2005-03-04
Publication date: 2006-09-07
Also published as: JP2008532150A; EP1854003A1; US20080276247A1; US8185900B2; WO2006092318A1

Abstract

Die Erfindung betrifft ein Verfahren zur Echtzeitanalyse eines Systems, wobei vom System Tasks (Ð) abzuarbeiten sind und wobei ein durch das Abarbeiten einer Task (Ð) definierter Job Systemkosten verursacht. Um ein besonders schnelles und genaues Verfahren bereitzustellen, ist vorgesehen, dass eine Näherung des Verfahrens aufgehoben wird, wenn ein Zeitintervall (I) nicht als in Echtzeit abarbeitbar gilt, indem für zumindest einen Job einer Task (Ð) an Stelle des Näherungswerts die Systemkosten berücksichtigt werden.

Description

Die Erfindung betrifft ein Verfahren zur Echtzeitanalyse eines Systems.

Bei einer Vielzahl von technischen Systemen, wie beispielsweise eingebetteten Echtzeitsystemen oder eingebetteten Computersystemen, ist es erforderlich, dass vom System Aufgaben, sogenannte Tasks, in einem vorgegebenen, auch mit Zeitschranke oder Deadline bezeichneten Zeitintervall vom System abgearbeitet werden. Vom System abzuarbeitende Aufgaben werden im Folgenden auch unter dem Tasksystem zusammengefasst. Die Echtzeitanalyse wird zur Automatisierung der Entwicklung von Echtzeitsystemen benötigt. Bei Verfahren zur Echtzeitanalyse kann zwischen sogenannten hinreichenden und notwendigen Verfahren unterschieden werden. Mit einem hinreichenden Verfahren werden für ein System nicht echtzeitfähige Tasksysteme mit Sicherheit erkannt. Alle Tasksysteme können mit Sicherheit richtig klassifiziert werden. Bei hinreichenden Verfahren kann es dagegen möglich sein, dass ein vom System in Echtzeit abarbeitbares Tasksystem als nicht echtzeitfähig klassifiziert wird.

Aus S. Baruah, A. Mok, L. Rosier: "Preemptive Scheduling Hard-Real-Time Sporadic Tasks on One Processor." in Proceedings of the Real-Time Systems Symposium, 182-190, 1990, ist ein notwendiges Verfahren zur Echtzeitanalyse bekannt. Bei dem Verfahren wird eine in einem vorgegebenen Zeitintervall anfallende, zum Abarbeiten von Tasks erforderliche kumulierte maximale Rechenzeit mit der jeweiligen Intervalllänge verglichen. Dabei gilt ein Tasksystem als nicht in Echtzeit abarbeitbar, wenn die Rechenzeit für ein vorgegebenes Zeitintervall die Intervalllänge übersteigt. Es brauchen zwar nur Zeitintervalle überprüft werden, welche kleiner als ein be stimmbares, vom Tasksystem abhängiges maximales Zeitintervall sind. Jedoch kann es sein, dass viele Zeitintervalle unnötig überprüft werden, wodurch die Laufzeit des Verfahrens unnötig verlängert wird.

Aus J.A. Stankovic, M. Spuri, K. Ramamritham, G.C. Buttazzo: "Deadline Scheduling for Real-Time Systems EDF and Related Algorithms", in Kluwer Academic Publishers, Bosten/Dodrecht/London, 1998, S. 42–50, ist ein Verfahren bekannt, bei welchem die Anzahl der zu überprüfenden Zeitintervalle im Vergleich zum Verfahren nach Baruah et. al. reduziert werden kann. Es werden lediglich Zeitintervalle berücksichtigt, in welchen sich die Rechenzeit des Systems ändern kann. Ein Nachteil dieses Verfahrens ist, dass die Laufzeit des Verfahrens nicht nur von der Größe des Tasksystems, sondern auch vom Verhältnis der Parameter der Tasks, wie z. B. Periode, Deadline oder Ausführungszeit, abhängig ist. Aus Karsten Albers, Frank Slomka: "An Event Stream driven Approximation for the Analysis of Real-Time System", in IEEE Proceedings of the 16th Euromicro Conference on Real-Time Systems 2004 (ECRTS'04), Catania, Italy, S. 187–195 ist es bekannt, dass eine Echtzeitanalyse für ein Tasksystem, welches sowohl Tasks mit kleinen als auch mit großen Perioden enthält, mit dem Verfahren nach Stankovic et. al. eine hohe Laufzeit erfordert. Ferner müssen bei Tasksystemen mit hohem Auslastungsgrad sehr viele Zeitintervalle überprüft werden. Das führt zu einer hohen Laufzeit des Verfahrens.

Aus M. Devi: "An Improved Schedulability Test for Uniprocessor Periodic Task Systems", in IEEE Proceedings of the 15th Euromicro Conference on Real-Time Systems, 2003, ist ein hinreichendes Verfahren zur Echtzeitanalyse bekannt. Es stellt eine Weiterentwicklung der zuvor beschriebenen Verfahren dar. Die Laufzeit des Verfahrens ist im Wesentlichen nur von der Größe des Tasksystems abhängig. Ein solches Verfahren wird auch als Verfahren mit polynominaler Komplexität bezeichnet. Bei dem Verfahren nach Devi ist es möglich, dass ein tatsächlich echtzeitfähiges Tasksystem nicht als solches erkannt und falsch klassifiziert wird. Beispielsweise werden Tasksysteme, welche eine optimale Auslastung des Systems ermöglichen, nicht mit Sicherheit als echtzeitfähig klassifiziert.

Ein weiteres Verfahren zur Echtzeitanalyse ist aus S. Chakraborty, S. Künzli, L. Thiele: "Approximate Schedulability Analysis", 23rd IEEE Real-Time Systems Symposium (RTSS), IEEE Press, 159–168, 2002, bekannt. Bei dem Verfahren handelt es sich um ein Näherungsverfahren, bei welchem ein maximaler Fehler fest vorgegeben werden kann. Indem ein kleiner Fehler vorgegeben wird kann der Anteil der als echtzeitfähig klassifizierbaren Tasksysteme gegenüber einem größeren Fehler erhöht werden. Nachteilig ist es, dass die Laufzeit des Verfahrens mit kleiner werdendem Fehler ansteigt. Bei dem Verfahren nach Chakraborty et. al. handelt es sich um ein hinreichendes Verfahren, bei welchem viele Zeitintervalle unnötig überprüft werden.

Aufgabe der Erfindung ist es, die Nachteile nach dem Stand der Technik zu beseitigen. Es soll insbesondere ein besonders schnelles und genaues Verfahren zur Echtzeitanalyse angegeben werden.

Diese Aufgabe wird gelöst durch die Merkmale der Ansprüche 1 und 26. Vorteilhafte Ausgestaltungen der Erfindung ergeben sich aus den Merkmalen der Ansprüche 2 bis 25.

Nach Maßgabe der Erfindung sind bei einem Verfahren zur Echtzeitanalyse eines Systems, wobei vom System Tasks abzuarbeiten sind und wobei ein durch das Abarbeiten einer Task definierter Job Systemkosten verursacht folgende Schritte vorgesehen:

a) Festlegen eines Zeitintervalls, in welchem Tasks vom System abzuarbeiten sind,
b) Ermitteln eines Grenzwerts für Systemkosten, welche im Zeitintervall zum Abarbeiten der Tasks verfügbar sind,
c) Ermitteln von Gesamtsystemkosten, für die durch die im Zeitintervall anfallenden Jobs verursachten Systemkosten, wobei zur Ermittlung der Gesamtsystemkosten für
i) eine erste Menge bildende Jobs die Systemkosten und
ii) eine zweite Menge bildende Jobs jeweils ein Näherungswert für die Systemkosten verwendet werden/wird,
d) Vergleich der ermittelten Gesamtsystemkosten mit dem Grenzwert, wobei
i) das Zeitintervall dann als in Echtzeit abarbeitbar gilt, wenn die Gesamtsystemkosten den Grenzwert nicht übersteigen, wobei,
ii) wenn die Gesamtsystemkosten den Grenzwert übersteigen, die zweite Menge, falls diese nicht leer ist, derart verringert wird, dass für eine weitere Ermittlung der Gesamtsystemkosten für zumindest einen Job einer Task der zweiten Menge an Stelle des Näherungswerts die Systemkosten berücksichtigt werden, und wobei
iii) die Echtzeitfähigkeit des Systems dann als nicht gegeben angesehen wird, wenn die zweite Menge leer ist und die Gesamtsystemkosten den Grenzwert übersteigen.

Bei dem erfindungsgemäßen Verfahren werden für einen Job der ersten Menge die Systemkosten und für einen Job der zweiten Menge ein Näherungswert verwendet. Der Näherungswert für die Systemkosten eines Jobs kann auf der Grundlage der Systemkosten des Jobs ermittelt werden. Sofern die zweite Menge nicht leer ist handelt es sich bei dem Verfahren um ein Näherungsverfahren. Die Genauigkeit des Verfahrens, d. h. der Grad der Approximation, ist abhängig von der Mächtigkeit der zweiten Menge. Dabei ist unter dem "Grad der Approximation" die Abweichung des Näherungsverfahrens von einem exakten Verfahren zu verstehen. Die Genauigkeit des Näherungsverfahrens steigt mit steigendem Grad der Approximation. Damit steigt im Allgemeinen auch der Aufwand des Näherungsverfahrens, wodurch z. B. die Laufzeit ansteigt. Bei dem erfindungsgemäßen Verfahren kann der Grad der Approximation während des Verfahrens dynamisch verändert werden. Eine Erhöhung des Grades der Approximation kann durch eine Verringerung der zweiten Menge erfolgen. Um die Laufzeit des Verfahrens möglichst gering zu halten kann beispielsweise die Mächtigkeit der zweiten Menge, z. B. bereits bei Beginn des Verfahrens, möglichst groß gewählt werden. Das Verfahren kann mit einem kleinen Grad der Approximation und niedrigem Aufwand und einer kleinen Laufzeit gestartet werden. Stellt sich im Verlauf des Verfahrens heraus, dass der Grad der Approximation zu gering ist, weil etwa die Gesamtsystemkosten den Grenzwert übersteigen, kann der Grad der Approximation dynamisch erhöht werden. Das kann durch eine Verringerung der Mächtigkeit der zweiten Menge erfolgen. Bei einer Verringerung der zweiten Menge werden bei der Ermittlung der Gesamtsystemkosten zumindest für einen Job der zweiten Menge an Stelle des Näherungswerts die Systemkosten verwendet. Die Gesamtsystemkosten können um einen im Näherungswert enthaltenen Fehler verkleinert werden. Durch die Verkleinerung der Gesamtsystemkosten kann es möglich sein, dass die Gesamtsystemkosten unter den Grenzwert sinken. In diesem Fall kann das Tasksystem für das überprüfte Zeitintervall als vom System in Echtzeit abarbeitbar klassifiziert werden. Bei einem fest vorgegebenen Grad der Approximation wäre hingegen das Tasksystem als nicht echtzeitfähig klassifiziert worden. Mit dem erfindungsgemäßen Verfahren können Tasksysteme mit größerer Sicherheit richtig klassifiziert werden. Ferner kann durch die Möglichkeit einer dynamischen Einstellung des Grads der Approximation der Aufwand und die Laufzeit des Verfahrens deutlich reduziert werden.

Nach einer Ausgestaltung der Erfindung wird, wenn die Gesamtsystemkosten kleiner als der Grenzwert sind, die zweite Menge vergrößert. Bei einer Vergrößerung der zweiten Menge wird der Grad der Approximation verringert, d. h. die Anzahl der genäherten Jobs wird erhöht. Mit einer höheren Anzahl genäherter Jobs kann die Laufzeit verringert werden. Das Verfahren kann noch schneller und effizienter durchgeführt werden.

Nach einer weiteren Ausgestaltung der Erfindung wird mindestens einer Task eine veränderbare Testgrenze zugeordnet, wobei für Tasks, deren Testgrenze im Zeitintervall überschritten wird, der Näherungswert für die Jobs der Task verwendet wird, und wobei, wenn die Gesamtsystemkosten größer als der Grenzwert sind, zumindest eine Testgrenze einer Task derart verändert wird, dass die zweite Menge verringert wird. Anhand der Testgrenzen kann das Verhältnis der Näherungswerte zu den Gesamtsystemkosten begrenzt bzw. verschoben werden. Das Verhältnis kann z. B. zur Ermittlung eines momentanen Fehlers verwendet und an den Anwender weitergegeben werden. Die Mächtigkeit der zweiten Menge und der damit verknüpfte Grad der Approximation kann in besonders einfacher Weise durch Erhöhen oder Erniedrigen der Testgrenzen verändert werden. Durch eine Erhöhung der Testgrenzen kann der Grad der Approximation gesteigert werden. Vorteilhafterweise stellt die Testgrenze für eine Task eine Anzahl von Jobs der Task dar, wobei die Test grenze erreicht ist, wenn das Zeitintervall der Anzahl entsprechend viele Jobs umfasst. Besonders vorteilhaft ist es, zumindest anfänglich für alle Tasks dieselbe Testgrenze zu wählen, z. B. dieselbe Anzahl von Jobs. Andererseits ist es auch möglich, dass der Anwender beispielsweise einen anfänglichen maximal möglichen Fehler vorgibt, mit welchem das Verfahren beginnen soll und auf dessen Grundlage die Testgrenzen bestimmt werden. Um die Laufzeit und den Aufwand des Verfahrens zu reduzieren, kann, wenn die Gesamtsystemkosten kleiner als der Grenzwert sind, die Testgrenze einer Task der zweiten Menge derart verändert werden, dass die zweite Menge vergrößert wird.

Vorzugsweise wird zur Verringerung der zweiten Menge zumindest ein Zahlenwert, wie z. B. eine Testgrenze, vergrößert, vorzugsweise verdoppelt, und/oder zur Vergrößerung der zweiten Menge zumindest ein Zahlenwert, wie z. B. eine Testgrenze, verringert. Eine Veränderung des Zahlenwerts kann beispielsweise durch eine fest vorgegebene Rechenoperation in einer besonders einfachen und schnellen Weise erfolgen.

Nach einer Ausgestaltung der Erfindung wird, wenn die Gesamtsystemkosten größer als der Grenzwert sind, das Verfahren mit einem bereits überprüften Zeitintervall fortgeführt, in welchem die Gesamtsystemkosten kleiner als der Grenzwert waren. Dabei kann ein beliebiges Zeitintervall gewählt werden, in welchem die Gesamtsystemkosten kleiner als der Grenzwert waren. Es ist auch möglich, wenn die Gesamtsystemkosten im Zeitintervall größer als der Grenzwert sind, dass das Verfahren im Zeitintervall fortgeführt wird. Bei dieser Ausgestaltung können Ergebnisse von bereits überprüften Zeitintervallen verwendet werden. Eine nochmalige Durchführung des Verfahrens von Anfang an kann vermieden werden. Das Verfahren kann besonders schnell und effizient ausgeführt werden.

Nach einer Ausgestaltung des Verfahrens wird zur Verringerung der zweiten Menge eine der folgenden Eigenschaften der Tasks berücksichtigt: Höhe der tatsächlichen Systemkosten, Fehleranteil der genäherten Systemkosten an einem Gesamtfehler des Verfahrens. Es ist möglich, die Näherung für solche Jobs zuerst aufzuheben, welche die höchsten Systemkosten verursachen. Analog kann die Näherung zuerst für diejenigen Jobs aufgehoben werden, welche den größten Fehleranteil aufweisen. Damit kann erreicht werden, dass die Gesamtsystemkosten bereits zu Beginn der Aufhebung der Näherung um einen möglichst hohen Betrag reduziert werden.

Nach einer besonders bevorzugten Ausgestaltung der Erfindung wird die Echtzeitfähigkeit nacheinander für Zeitintervalle mit ansteigender Größe überprüft. Ist ein Zeitintervall in Echtzeit abarbeitbar, so können auch alle kleineren Zeitintervalle als in Echtzeit abarbeitbar angesehen werden. Übersteigen die Gesamtsystemkosten in einem überprüften Zeitintervall den Grenzwert, so kann das Verfahren im gleichen Zeitintervall mit einem höheren Grad der Approximation fortgesetzt werden. Werden die Intervalle der Größe nach in aufsteigender Reihenfolge überprüft, so können die Gesamtsystemkosten besonders einfach, z. B. durch Aufsummieren der Systemkosten und der Näherungswerte, ermittelt werden.

Nach einer weiteren Ausgestaltung des Verfahrens werden die Tasks zur Bestimmung der Gesamtsystemkosten gruppiert. Ein derartiges Vorgehen ist insbesondere dann sinnvoll, wenn diese auf unterschiedlichen Prioritätsebenen liegen.

Nach einer Ausgestaltung der Erfindung wird zumindest eine Task wiederholend vom System abgearbeitet. Vorzugsweise wird zumindest eine Task mit einem zeitlichen Mindestabstand oder periodisch mit einer Periode abgearbeitet.

Eine weitere Ausgestaltung der Erfindung sieht vor, dass die Systemkosten auf der Grundlage einer für das Abarbeiten der Tasks erforderlichen Bearbeitungszeit berechnet werden. Es ist auch möglich, dass die Systemkosten auf der Grundlage einer oberen Schranke für die höchstens erforderliche Bearbeitungszeit berechnet werden. Ferner ist es möglich, die Systemkosten auf der Grundlage einer für das Abarbeiten der Jobs erforderlichen Auslastung einer Ausführungskomponente, vorzugsweise einer CPU, des Systems zu berechnen.

Nach einer Ausgestaltung der Erfindung wird der Grenzwert auf der Grundlage einer im Zeitintervall verfügbaren Kapazität des Systems ermittelt. Beispielsweise ist es möglich, den Grenzwert mit Hilfe der Kapazität eines Prozessors oder einer CPU zu bestimmen. Wird eine konstante Kapazität angenommen, so kann der Grenzwert bestimmt werden, indem die Länge des Zeitintervalls mit der Kapazität multipliziert wird. Bei dieser Bestimmung wird einem Zeitintervall der doppelten Länge der doppelte Grenzwert zugeordnet. Es ist auch möglich, den Grenzwert durch eine Menge von Systemkosten zu beschreiben, welche von der CPU innerhalb des dem Grenzwert zugeordneten Zeitintervalls abgearbeitet werden können. Ferner können für unterschiedliche Zeitintervalle verschiedene Grenzwerte verwendet werden. Dadurch können Prozessoren mit einer schwankenden Kapazität besser und genauer modelliert werden. Es ist auch möglich, lediglich einigen Zeitintervallen unterschiedliche Grenzwerte zuzuordnen. Vorzugsweise werden die Grenzwerte in aufsteigender Größe Zeitintervallen mit ebenfalls steigender Größe zugeordnet. Ein für ein Zeitintervall bestimmter Grenzwert, kann zur Bestimmung des Grenzwerts eines größeren, z. B. des nächst größeren, Zeitintervalls verwendet werden. Verglichen mit dem Verfahren mit festen Grenzwerten kann mit einem geringen zusätzlichen Berechnungsaufwand eine wesentlich genauere Analyse ermöglicht werden.

Nach einer Ausgestaltung der Erfindung werden die Gesamtsystemkosten für diskrete, einen Anfangs- und einen Endzeitpunkt aufweisende Zeitintervalle ermittelt, wobei der Endzeitpunkt ein Ende einer Zeitschranke ist, bis zu welcher ein Job einer Task spätestens abzuarbeiten ist. Mit diskreten Zeitintervallen kann in einem einfachen Zahlensystem gerechnet werden. Es brauchen keine aufwändigen Gleitkommaoperationen ausgeführt werden. Indem als Endzeitpunkte an sich bekannte Zeitschranken verwendet werden, können die Zeitintervalle in besonders einfacher Weise bestimmt werden. Bei gleichem Anfangspunkt der Zeitintervalle ist es lediglich erforderlich, den Endzeitpunkt mit einer Zeitschranke eines, z. B. nicht genäherten, Jobs gleichzusetzen.

Nach einer Ausgestaltung des Verfahrens wird der Näherungswert für einen Job auf der Grundlage einer spezifischen Auslastung des Systems berechnet. Die spezifische Auslastung wiederum kann als Quotient aus Bearbeitungszeit und Periode der Task berechnet werden. Es ist auch möglich, dass die spezifische Auslastung für ein Intervall berücksichtigt wird, welches kleiner ist als das Zeitintervall.

Nach einer besonders bevorzugten Ausgestaltung der Erfindung wird derjenige Task vom System zuerst abgearbeitet, für welchen das Ende der Zeitschranke zeitlich am nächsten liegt. Es ist auch möglich, dass die Tasks in einer durch eine Priorität vorgegebenen Reihenfolge vom System abgearbeitet werden. Ferner können die Tasks mit einem Ereignisstrommodell beschrieben werden.

Nach einer Ausgestaltung der Erfindung wird folgender Algorithmus verwendet:

Eine weitere Ausgestaltung der Erfindung sieht folgenden Algorithmus vor:

Hierin bedeutet τ_rev die Menge der Tasks, für welche die Näherung bei einem Durchlauf des Algorithmus aufgehoben wird.

Nach weiterer Maßgabe der Erfindung ist ein Computerprogrammiererzeugnis zur Analyse des Zeitverhaltens komplexer Systeme mit Programmcodemitteln zur Durchführung des erfindungsgemäßen Verfahrens vorgesehen. Vorteile des Computerprogrammiererzeugnis ergeben sich aus den Vorteilen der oben beschriebenen Verfahren.

Im Folgenden wird das erfindungsgemäße Verfahren anhand von Ausführungsbeispielen näher erläutert.

Bei einem ersten Beispiel wird ein Näherungsverfahren zur Echtzeitanalyse eines Systems betrachtet. Für ein System ist ein abzuarbeitendes Tasksystem τ_n mit n Tasks τ vorgesehen, wobei n eine natürliche Zahl ist. Bei dem Verfahren werden für die Tasks τ werden nur solche Zeitintervalle I überprüft, welche kleiner als ein maximales Zeitintervall sind. Als Systemkosten wird die Rechenzeit R verwendet. Die Zeitintervalle I sind diskret, d. h. sie weisen einen Anfangs- und einen Endzeitpunkt auf. Dabei ist ein Endzeitpunkt eines Zeitintervalls I durch ein Ende einer Zeitschranke d_τ eines Jobs einer Task τ des Tasksystems τ_n gegeben. D. h. der Job muss spätestens bis zum Endzeitpunkt abgearbeitet sein. Für eine Task τ werden die ersten n_τ Zeitintervalle I^τ ₁, ...,

< I_max, z. B. der Größe nach in aufsteigender Reihenfolge, überprüft. Die Intervalle I^τ ₁, ... bzw.

umfassen 1, 2, ... bzw. n_τ Jobs der Task τ. Für jede Task τ wird ferner eine von den Parametern der Task τ abhängige Testobergrenze T_max(τ) bestimmt, für welche gilt:

≤ T_max(τ) ≤ I_max. Bei der Ermittlung einer Gesamtrechenzeit werden für die Zeitintervalle I ≤ T_max(τ) die tatsächlichen Systemkosten der Jobs der Task τ und für Zeitintervalle I, mit T_max(τ) ≤ I ≤ I_max ein Näherungswert für die Systemkosten verwendet. Die Zahlen n_τ und der Fehler des Näherungsverfahrens sind voneinander abhängig. Bei der Analyse von Zeitintervallen

einer weiteren Task τ', für welche T_max(τ) <

gilt, werden die genäherten Kosten des Jobs der Task τ anteilmäßig berücksichtigt. Die Analyse ist so lange fortzuführen bis das maximale Zeitintervall I_max überschritten wird. Durch die genäherten Systemkosten entsteht bei der Ermittlung der Gesamtrechenzeit ein Fehler. Es kann also sein, dass die ermittelte Gesamtrechenzeit größer ist als die des exakten Verfahrens.

Damit die Laufzeit des Verfahrens und die Anzahl der zu überprüfenden Zeitintervalle möglichst gering sind, wird mit einer kleinen maximalen Anzahl n_τ von Zeitintervallen pro Task τ, d. h. mit einer niedrigen Testobergrenze T_max(τ) begonnen, beispielsweise mit n_τ = 1. Übersteigt die einen Fehler enthaltende Gesamtrechenzeit einen Grenzwert für die im überprüften Intervall verfügbare Rechenzeit, so wird die Testobergrenze T_max(τ) verschoben und entsprechend die maximale Anzahl n_τ der Zeitintervalle für zumindest eine Task τ erhöht. Beispielsweise kann die Erhöhung derart erfolgen, dass die Anzahl n_τ verdoppelt wird. Dabei sind gerade solche Verschiebungen der Testobergrenze T_max(τ) von Bedeutung, welche über den Endzeitpunkt des überprüften Zeitintervalls hinweg verschoben werden. Dies wirkt sich auf die Anzahl der im Zeitintervall genäherten Jobs aus. Bei einer Verringerung der Anzahl der genäherten Jobs wird die Gesamtrechenzeit um den Fehleranteil der nicht mehr genäherten Jobs verringert. Dadurch ist es möglich, dass die Gesamtrechenzeit unter den Grenzwert sinkt. Kann das erreicht werden, so kann das Tasksystem für das überprüfte Zeitintervall akzeptiert werden.

Bei einem zweiten Ausführungsbeispiel des Verfahrens werden Zeitintervalle I der Größe nach in aufsteigender Reihenfolge überprüft. Wird das überprüfte Zeitintervall als in Echtzeit abarbeitbar klassifiziert, so gilt dies auch für alle kleineren Zeitintervalle I. Wird das überprüfte Zeitintervall I als nicht in Echtzeit abarbeitbar klassifiziert, so werden für zumindest einen genäherten Job einer Task τ an Stelle des Näherungswerts die Systemkosten verwendet. Dabei reicht eine nochmalige Überprüfung des bereits überprüften Zeitintervalls I aus. Es ist nicht zwingend erforderlich, dass die Echtzeitanalyse ausgehend von einem kleineren Zeitintervall I oder von Anfang an wiederholt wird.

Das Verfahren kann wie folgt realisiert werden:
Bei dem Verfahren kann eine spezifische Auslastung U des Tasksystems τ_n folgendermaßen berechnet werden:

Dabei sind τ_i, i = 1, 2, ... Tasks aus dem Tasksystem τ_n, c_i die Systemkosten und p_i eine Periode oder ein zeitlicher Mindestabstand der Task τ_i.

In einem ersten Schritt wird überprüft, ob die spezifische Auslastung U den Wert 1 übersteigt. In diesem Fall ist das Tasksystem nicht echtzeitfähig und die Echtzeitanalyse kann beendet werden.

In einem zweiten Schritt werden ein oder mehrere maximale Testintervalle I_max festgelegt. Ferner werden zur Ausführung des Verfahrens notwendige Variablen initialisiert, wie z. B. eine kumulierten aktuellen Rechenzeit R_act für das aktuelle Zeitintervall I_act. Die Variablen werden, z. B. mit Null, initialisiert. Ein dem aktuellen Zeitintervall I_act vorangehendes Zeitintervall wird mit I_old bezeichnet. Das jeweils erste Zeitintervall

der Tasks τ_i des Tasksystems τ_n wird in eine Testliste TestList eingefügt. Das erste Zeitintervall

ergibt sich aus einer Zeitschranke

des ersten Jobs einer jeden Task τ_i. Ferner wird eine zulässige Anzahl Anz von Zeitintervallen bestimmt. Vorzugsweise ist zu Beginn des Verfahrens die Anzahl Anz auf 1 gesetzt und eine Liste ApproxList von Tasks τ, deren Jobs genähert werden leer.

In einem dritten Schritt werden die nachfolgenden Anweisungen wiederholend ausgeführt, bis entweder die Testliste TestList leer ist, oder das maximale Testintervall überschritten ist, d. h. wenn z. B. gilt: I_act ≥ I_max.

Als erste Anweisung wird als aktuelle Zeitintervall I_act bestimmt. Das aktuelle Zeitintervall I_act wird mit dem kleinsten Zeitintervall aus der Testliste Testlist gleichgesetzt. Das kleinste Zeitintervall wird aus der Testliste TestList entfernt. Sollte dieses Zeitintervall mehrfach für verschiedene Tasks τ_i in der Testliste TestList enthalten sein, wird nur ein Eintrag gelöscht. τ_act bezeichnet die zu dem aktuellen Zeitintervall I_act gehörende Task. Als nächste Anweisung wird die Rechenzeit R_act mit folgender Formel berechnet: Ract = Rold + cact + Uapprox × (Iact – Iold)

Dabei bezeichnet U_approx eine spezifische Auslastung der genäherten Tasks. U_approx kann mit folgender Formel berechnet werden:

U_approx kann auch in einer Variable gespeichert und im Laufe der Echtzeitanalyse, sofern erforderlich, aktualisiert werden.

In einer weiteren Anweisung wird die kumulierte aktuelle Rechenzeit R_act mit einem Grenzwert GW_act für das aktuelle Zeitintervall I_act verglichen. Der Grenzwert GW_act kann beispielsweise mit der Intervalllänge des aktuellen Zeitintervalls I_act gleichgesetzt werden.

Ist in einem ersten Fall die Rechenzeit R_act kleiner oder gleich dem Grenzwert GW_act, so ist der Echtzeitnachweis für das Zeitintervall I_act erbracht. Durch eine nächste Anweisung wird geprüft, ob die Testobergrenze T_max(τ_act) der aktuellen Task τ_act erreicht oder überschritten ist. Die Testobergrenze T_max(τ_act) hängt von der aktuell zulässigen Anzahl Anz der Zeitintervalle ab. Für periodische Tasks kann die Überprüfung durch folgende Formel erfolgen: Iact ≥ (Anz – 1) × pact + dact

Dabei bezeichnet d_act die aktuelle Zeitschranke und p_act die Periode der Task τ_act. Ist die Testobergrenze Tmax(τ_act) erreicht, so wird in einer nächsten Anweisung die Task τ_act der Liste ApproxList der genäherten Tasks hinzugefügt. Falls erforderlich wird U_approx aktualisiert.

Ist die Testobergrenze T_max(τ_act) noch nicht erreicht, so wird ein nächst größeres Zeitintervall I_next für die Task τ_act in die Testliste TestList eingefügt. Für periodische Tasks kann das Zeitintervall I_next folgendermaßen bestimmt werden: Inext = Iact' + pact

Als letzte Anweisung des ersten Falls wird der Wert des letzten akzeptierten Zeitintervalls I_old auf den Wert des aktuellen Zeitintervall I_act gesetzt.

Ist in einem zweiten Fall die Rechenzeit R_act dagegen größer als der Grenzwert GW_act, so wird versucht, die Rechenzeit R_act schrittweise zu reduzieren. Es wird geprüft, ob durch die Reduktion die Rechenzeit R_act kleiner wird als der Grenzwert GW_act. Das kann wie folgt durchgeführt werden:
Ist die Liste ApproxList leer so ist das Tasksystem nicht echtzeitfähig.

Ist die Liste ApproxList nicht leer, so wird die Anzahl Anz erhöht. Die Anzahl Anz kann beispielsweise verdoppelt werden. Dann wird überprüft, ob durch die Erhöhung in der Liste ApproxList enthaltene Tasks nicht mehr genähert werden. Die nicht mehr genäherten Tasks werden bestimmt. Es werden diejenigen Tasks bestimmt, welchen infolge der erhöhten Anzahl Anz eine Testobergrenze T_max(τ) zugeordnet wird, welche größer als das aktuelle Zeitintervall I_act ist. Die so bestimmten Tasks werden aus der Liste ApproxList entfernt und ihr nächstes Zeitintervall, das größer als I_act ist wird in die Liste Test-List eingefügt. Dann wird die Rechenzeit R_act um den Fehleranteil der wie oben bestimmten Tasks reduziert. Für periodische Tasks kann der Fehler in einem Intervall I folgendermaßen bestimmt werden:

Dabei bezeichnen d_i, p_i, und c_i die Zeitschranke, Periode und Kosten der Task τ_i. Die Fehler werden von Rechenzeit R_act subtrahiert. Ist die reduzierte Rechenzeit R'_act nach wie vor größer der Grenzwert GW_act, so war die Erhöhung der Anzahl Anz noch nicht ausreichend. Die Anzahl Anz wird weiter erhöht, beispielsweise nochmals verdoppelt. Die Erhöhung der Anzahl wird so lange wiederholt bis entweder die reduzierte Rechenzeit R'_act kleiner oder gleich dem Grenzwert GW_act ist oder bis die Liste ApproxList leer ist. Ist infolge einer Erhöhung der Anzahl Anz die Rechenzeit R'_act nicht mehr größer als der Grenzwert GW_act, so wird das Verfahren wie im ersten Fall fortgeführt. Ist für jede Erhöhung der Anzahl Anz die Rechenzeit R'_act größer als der Grenzwert GW_act, so ist der Echtzeitnachweis für das Tasksystem τ_n fehlgeschlagen.

Bei einem dritten Ausführungsbeispiel kann der Grad der Approximation verringert werden. Der Grad der Approximation kann dynamisch an die Erfordernisse des Tasksystems τ_n angepasst werden. Die Laufzeit des Verfahrens kann weiter minimiert werden. Beispielsweise kann für jedes Zeitintervall eine maximale Anzahl von Tasks genähert werden. Dabei kann folgendes Verfahren angewandt werden:
Die Zeitintervalle werden der Größe nach in aufsteigender Reihenfolge überprüft. Wird festgestellt, dass die Rechenzeit R_act kleiner als der Grenzwert GW_act ist, so wird die Anzahl Anz verringert. Dabei wird die Testobergrenze T_max(τ) für zumindest eine Task τ derart verschoben, dass die Task τ im Zeitintervall I_act oder I_new genähert wird.

Bei einem vierten Ausführungsbeispiel werden die Tasks τ so früh wie möglich, z. B. nach dem ersten Zeitintervall I^τ ₁, genähert. Diese Näherung kann, wie oben beschrieben, wieder aufgehoben werden. Wird eine Näherung aufgehoben, so erfolgt eine erneute Wiedereinführung der Näherung baldmöglichst, z. B. in dem der Aufhebung folgenden Zeitintervall. Bei dem Verfahren ist es möglich, nur dann Zeitintervalle I in die Testliste einzufügen, wenn dies aufgrund der Aufhebung einer Näherung erfolgt. Das Verfahren ermöglicht eine weitgehende Näherung, ist schnell und genau.

Das vierte Ausführungsbeispiel kann beispielsweise folgendermaßen realisiert werden:
Die sich jeweils aus dem ersten Job einer jeden Task τ ergebenden ersten Zeitintervalle I^τ ₁ werden in die Testliste TestList eingefügt. Die Zeitintervalle I^τ ₁ in der Testliste TestList werden dann der Größe nach in aufsteigender Reihenfolge abgearbeitet. Alle weiteren Zeitintervalle I der Tasks werden zunächst genähert, d.h. sind nicht in der Testliste TestList eingefügt. Wenn ein Echtzeitnachweis für ein Zeitintervall I^τ ₁ fehlschlägt, wird die Näherung, wie oben beschrieben, schrittweise reduziert. Das erfolgt entweder bis der Echtzeitnachweis für das überprüfte Zeitintervall I erbracht ist oder keine Task mehr genähert werden kann. Kann keine Task mehr genähert werden ist das Tasksystem nicht echtzeitfähig. Die Aufhebung der Näherung einer Task τ führt dazu, dass für diese Task τ ein Zeitintervall I^τ ₁, i > 2, in die Testliste TestList eingefügt wird. Vorzugsweise entspricht das Zeitintervall I^τ ₁ dem nächst größeren Zeitintervall der Task τ, welches auf ein Zeitintervall folgt, in welchem der Test fehlgeschlagen ist. Das nächst größere Intervall kann auf die gleiche Weise bestimmt werden wie bei der Echtzeitanalyse mit dynamischem Fehler. Die Echtzeitanalyse endet, wenn in einem Zeitintervall alle Tasks genähert werden und/oder die Rechenzeit R_act größer ist als der Grenzwert GW_act.

Bei allen Ausführungsbeispielen kann infolge einer deutlichen Reduktion der Zahl der zu überprüfenden Zeitintervalle eine besonders geringe Laufzeit des Verfahrens erreicht werden. Indem der Grad der Approximation angepasst wird kann die Echtzeitfähigkeit von Systemen sehr genau analysiert werden.

τ_n: Tasksystem
τ: Task
τ': weitere Task
Anz: Anzahl
c_i: Kosten
d_τ, d_i: Zeitschranke
GW_act: Grenzwert
I: Zeitintervall
I^τiτ: i-tes Zeitintervall einer Task τ
I^τnτ: maximales Zeitintervall einer Task τ
I_max: maximales Zeitintervall
I_act: aktuelles Zeitintervall
I_old: vorangehendes Zeitintervall
n_τ: Anzahl von Zeitschranken
p_i: Periode
R: Rechenzeit
R_act: aktuelle Rechenzeit
T_max(τ): Testobergrenze

Claims

Verfahren Echtzeitanalyse eines Systems, wobei vom System Tasks (τ) abzuarbeiten sind und wobei ein durch das Abarbeiten einer Task (τ) definierter Job Systemkosten verursacht, mit folgenden Schritten: a) Festlegen eines Zeitintervalls (I_act), in welchem Tasks (τ) vom System abzuarbeiten sind, b) Ermitteln eines Grenzwerts (GW_act) für Systemkosten, welche im Zeitintervall (I) zum Abarbeiten der Tasks (τ) verfügbar sind, c) Ermitteln von Gesamtsystemkosten (R_act), für die durch die im Zeitintervall (I) anfallenden Jobs verursachten Systemkosten, wobei zur Ermittlung der Gesamtsystemkosten (R_act) für i) eine erste Menge bildende Jobs die Systemkosten und ii) eine zweite Menge bildende Jobs jeweils ein Näherungswert für die Systemkosten verwendet werden/wird, d) Vergleich der ermittelten Gesamtsystemkosten (R_act) mit dem Grenzwert (GW_act), wobei i) das Zeitintervall (I_act) dann als in Echtzeit abarbeitbar gilt, wenn die Gesamtsystemkosten (R_act) den Grenzwert (GW_act) nicht übersteigen, wobei, ii) wenn die Gesamtsystemkosten (R_act) den Grenzwert (GW_act) übersteigen, die zweite Menge, falls diese nicht leer ist, derart verringert wird, dass für eine weitere Ermittlung der Gesamtsystemkosten (Rat) für zumindest einen Job einer Task (τ) der zweiten Mengen an Stelle des Näherungswerts die Systemkosten berücksichtigt werden, und wobei iii) die Echtzeitfähigkeit des Systems dann als nicht gegeben angesehen wird, wenn die zweite Menge leer ist und die Gesamtsystemkosten (R_act) den Grenzwert (GW_act) übersteigen.
Verfahren nach Anspruch 1, wobei, wenn die Gesamtsystemkosten (R_act) kleiner als der Grenzwert (GW_act) sind, die zweite Menge vergrößert wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei mindestens einer Task (τ) eine veränderbare Testgrenze
zugeordnet wird, wobei für Tasks (τ), deren Testgrenze
im Zeitintervall (I_act) überschritten wird, der Näherungswert für die Jobs der Task (τ) verwendet wird, und wobei, wenn die Gesamtsystemkosten (R_act) größer als der Grenzwert (GW_act) sind, zumindest eine Testgrenze
derart verändert wird, dass die zweite Menge verringert wird.
Verfahren nach Anspruch 3, wobei, wenn die Gesamtsystemkosten (R_act) kleiner als der Grenzwert (GW_act) sind, die Testgrenze
einer Task (τ) der zweiten Menge derart verändert wird, dass die zweite Menge vergrößert wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei zur Verringerung der zweiten Menge zumindest ein Zahlenwert vergrößert, vorzugsweise verdoppelt, wird und/oder zur Vergrößerung der zweiten Menge zumindest ein Zahlenwert verringert wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei, wenn die Gesamtsystemkosten (R_act) größer als der Grenzwert (GW_act) sind, das Verfahren mit einem bereits überprüften Zeitintervall (I_old) fortgeführt wird, in welchem die Gesamtsystemkosten (R_act) kleiner als der Grenzwert (GW_act) waren.
Verfahren nach einem der vorhergehenden Ansprüche, wobei, wenn die Gesamtsystemkosten (R_act) im Zeitintervall (I_act) größer als der Grenzwert (GW_act) sind, das Verfahren im Zeitintervall (I_act) fortgeführt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei zur Verringerung der zweiten Menge eine der folgenden Eigenschaften der Tasks berücksichtigt wird: Höhe der tatsächlichen Systemkosten, Fehleranteil der genäherten Systemkosten an einem Gesamtfehler des Verfahrens.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Echtzeitfähigkeit nacheinander für Zeitintervalle (I) mit ansteigender Größe überprüft wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei bei der Bestimmung der Gesamtsystemkosten (R_act) die Tasks (τ) gruppiert werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei zumindest eine Task (τ) wiederholend vom System abzuarbeiten sind.
Verfahren nach einem der vorhergehenden Ansprüche, wobei zumindest eine Task (τ) mit einem zeitlichen Mindestabstand oder periodisch mit einer Periode (p_i) abzuarbeiten ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Systemkosten auf der Grundlage einer für das Abarbeiten der Tasks (τ) erforderlichen Bearbeitungszeit berechnet werden.
Verfahren nach einem der Ansprüche 1 bis 12, wobei die Systemkosten auf der Grundlage einer oberen Schranke für die höchstens erforderliche Bearbeitungszeit berechnet werden.
Verfahren nach einem der Ansprüche 1 bis 12, wobei die Systemkosten auf der Grundlage einer für das Abarbeiten der Tasks (τ) erforderlichen Auslastung einer Ausführungskomponente, vorzugsweise einer CPU, des Systems berechnet werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Grenzwert (GW_act) auf der Grundlage einer im Zeitintervall (I_act) verfügbaren Kapazität des Systems ermittelt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Gesamtsystemkosten (Rat) für diskrete, einen Anfangs- und einen Endzeitpunkt aufweisende Zeitintervalle (I,
) ermittelt werden, wobei der Endzeitpunkt ein Ende einer Zeitschranke (d_act, d_i) ist, bis zu welcher ein Job einer Task (τ) spätestens abzuarbeiten ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Näherungswert für einen Job auf der Grundlage einer spezifischen Auslastung des Systems berechnet wird.
Verfahren nach Anspruch 18, wobei die spezifische Auslastung als Quotient aus Bearbeitungszeit und Periode (p_i) der Task (τ) berechnet wird.
Verfahren nach einem der Ansprüche 18 oder 19, wobei die spezifische Auslastung für ein Intervall berücksichtigt wird, welches kleiner ist als das Zeitintervall (I_act).
Verfahren nach einem der vorhergehenden Ansprüche, wobei derjenige Task (τ) vom System zuerst abgearbeitet wird, für welchen das Ende der Zeitschranke (d_act, d_i) zeitlich am nächsten liegt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Tasks (τ) in einer durch eine Priorität vorgegebenen Reihenfolge vom System abgearbeitet werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Tasks (τ) mit einem Ereignisstrommodell beschrieben werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei folgender Algorithmus verwendet wird:
Verfahren nach einem der Ansprüche 1 bis 23, wobei folgender Algorithmus verwendet wird:
Computerprogrammiererzeugnis zur Analyse des Zeitverhaltens komplexer Systemen mit Programmcodemitteln zur Durchführung des Verfahrens nach einem der vorhergehenden Ansprüche.