WO2005111807A2 - Verfahren zur prüfung der echtzeitfähigkeit eines systems - Google Patents

Verfahren zur prüfung der echtzeitfähigkeit eines systems Download PDF

Info

Publication number
WO2005111807A2
WO2005111807A2 PCT/EP2005/005037 EP2005005037W WO2005111807A2 WO 2005111807 A2 WO2005111807 A2 WO 2005111807A2 EP 2005005037 W EP2005005037 W EP 2005005037W WO 2005111807 A2 WO2005111807 A2 WO 2005111807A2
Authority
WO
WIPO (PCT)
Prior art keywords
time
task
tasks
interval
system costs
Prior art date
Application number
PCT/EP2005/005037
Other languages
English (en)
French (fr)
Other versions
WO2005111807A3 (de
Inventor
Karsten Albers
Original Assignee
Inchron Gmbh
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 Inchron Gmbh filed Critical Inchron Gmbh
Priority to US11/579,828 priority Critical patent/US8010592B2/en
Priority to EP05752682A priority patent/EP1756714A2/de
Publication of WO2005111807A2 publication Critical patent/WO2005111807A2/de
Publication of WO2005111807A3 publication Critical patent/WO2005111807A3/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3447—Performance evaluation by modeling
    • 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic
    • 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/0637—Strategic management or analysis, e.g. setting a goal or target of an organisation; Planning actions based on goals; Analysis or evaluation of effectiveness of goals
    • G06Q10/06375—Prediction of business process outcome or impact based on a proposed change

Definitions

  • the invention relates to a method for checking the real-time capability of a system, in particular a computer system.
  • a method for time analysis for periodic real-time task systems is known from [16].
  • tasks to be processed by a processor are considered with fixed priorities.
  • the blockage is taken into account in the form of additional system costs. The additional system costs are exactly determined.
  • Each task is described by a starting time a, a relative time limit d (measured from the starting time), a processing time c for the worst case and a smallest distance or a smallest period p between two events of the task.
  • An event of a task can also be called a job.
  • Each job has its own start time. In the worst case, the start time results from the start time a of the task and the interval or period p.
  • the processing time c and the time limit d of the task are assigned to each job. The time limit is measured from the start time of the respective job. All tasks can be carried out on the same processor.
  • a processor is understood to be an execution component of the system that processes tasks. For example, tasks can be performed by a CPU, electronic circuit modules or software components. The following description assumes that the tasks are scheduled according to the Earliest Deadline First, the so-called EDF algorithm. In the EDF algorithm, the task which has the smallest time interval from the end of the time limit d of the task is carried out first. It is also possible for the tasks to be scheduled using other scheduling methods.
  • Spuri describes in [14] an algorithm for a response-time analysis for EDF scheduling with a pseudo-polynomial complexity [15]. However, the algorithm requires more effort than the processor demand test.
  • the algorithm is defined for an extended task model, the recurring real-time task model [1], [2].
  • a fixed number of time intervals is evenly distributed over the maximum interval I ma ⁇ .
  • a cumulative processing time is only for these time intervals . checked.
  • an approximation is carried out, in which the cumulative processing time is compared with a capacity available by the system for the next smaller time interval.
  • the maximum error of this approximation is limited. The maximum error corresponds to the interval between two time intervals.
  • the test is always successful. With such an approximation, a compromise between execution time and error of the algorithm is possible. A large error leads to only a few time intervals and consequently to a short execution time. A small error leads to a large number of time intervals to be checked and a large execution time. If a system contains tasks with a small time limit d, the distance between the ends of their execution time and their time limits d is also small. In order to increase the prospect of acceptance of such a system, the test must have only one small error. This leads to long execution times of the algorithm. However, the algorithm always fails for tasks for which the time limit d is identical with their processing time in the worst case.
  • the object of the present invention is to eliminate the aforementioned disadvantages according to the prior art.
  • the proposed method is suitable both for carrying out a predictive real-time analysis and for a real-time analysis that can be carried out during the operation of the system.
  • it can be used to determine whether the system loaded with the current load is still real-time capable. If it is determined with the method according to the invention that this is no longer the case, countermeasures such as e.g. For example, provision of additional resources, task interruption or error handling can be initiated.
  • the correctness of the proposed algorithm can be verified formally.
  • system costs can be calculated on the basis of a processing time required to process the tasks. But you can also on the
  • Total system costs are understood to mean the cumulative system costs incurred for processing the tasks.
  • System costs for a time interval can, depending on the application, e.g. B. be used, maximum required, incurred or requested costs.
  • further system costs of at least one second task are taken into account at least for a time interval.
  • the additional system costs are determined by an approximation based on the actual system costs.
  • Actual system costs of a task are understood to be those system costs that are actually used by the system during execution.
  • the actual system costs of a task can e.g. B. be the execution time that the system actually needs to process the task.
  • the actual system costs can be precisely calculated, for example, using the so-called "worst case execution time" analysis. Due to the additional system costs, the costs incurred in the omitted larger time intervals can be partially anticipated.
  • this anticipation takes place only for a subset of the tasks.
  • system costs can be taken into account for the first tasks, which include two or more jobs of this task. This can increase the acceptance rate of the test.
  • the acceptance rate for a set of tasks the difference between at least one task being see time limit and processing time is small, can be increased. This applies in particular if, at least for the task with a small difference, the anticipation of future costs only takes place for time intervals which are several, e.g. B. include at least two jobs.
  • An interval comprises two jobs of a task if, taking into account the smallest distances and the relative time limits, the distance between the start time of the first job of the task and the time limit of the second job of the task is not greater than the time interval. This also applies to any number of jobs in a task.
  • the jobs of the task can occur either with a minimum time interval (sporadic case) or periodically (periodic case).
  • the set of tasks can also contain tasks from both cases.
  • An analysis of both cases can be covered with the method according to the invention.
  • test limits are at least partially introduced for the tasks. Additional system costs are only taken into account for those tasks whose test limit is reached in the time interval to be checked. A first task can become a second task when the test limit is reached.
  • the test limits can be variable, ie they are not necessarily fixed.
  • the test limits allow the ratio of the additional system costs to the total system costs to be limited. The ratio can be shifted by changing the test limits. The accuracy of the test can be increased by increasing the test limits. But u. U. more time intervals can be checked.
  • the ratio can also be limited by having fixed test limits be used.
  • the fixed test limit for a task advantageously represents a number of jobs of the task, the test limit being reached when the time interval of the number comprises a corresponding number of jobs.
  • the ratio of the share of the task in the total system costs to their additional system costs can be limited to the same value for each task.
  • the ratio can be used to estimate a maximum possible error and, for example, be passed on to the user.
  • the test limit can e.g. B. represented by a numerical value.
  • the additional system costs are calculated on the basis of the specific workload of a task. This can be determined by the quotient of the computing time and period of the task.
  • the maximum error for each task can be limited. It is possible that the maximum error is independent of the length of the time interval to be considered.
  • the specific capacity can usefully be determined for the difference between the time interval and the test interval of the task.
  • the maximum error for each task can be limited to twice its computing time.
  • the test limit preferably represents a number of jobs in the task.
  • the test limit is reached in a time interval if the time interval comprises a corresponding number of jobs. In this case, the error can even occur the simple computing time of the task can be limited.
  • the total system costs can be calculated step by step. Time intervals are preferred with increasing
  • the actual system costs of these approximated tasks have already been obtained in the further system costs determined in this way. As a result, the determination of the actual system costs of the approximated tasks can be omitted.
  • the additional system costs can be determined in one step for all tasks whose test limit has already been exceeded. Time intervals are not checked, for which only system costs of tasks change whose test limit has already been reached.
  • Such a procedure is particularly useful if they are on different priority levels.
  • the limit value for the total system costs consumed in a time interval can be described by a set of system costs.
  • the limit value can be described by an amount of such system costs which the processor can process within the time interval assigned to the limit value. It is also possible to determine the limit value using the capacity of the processor. If a constant capacity of the processor is assumed, the limit value can be determined by multiplying the length of the time interval by the capacity. at Such a determination of the limit value is assigned to a time interval of twice the length, twice the amount of processable system costs.
  • different capacities can be assigned to different time intervals in order to determine the limit value. This makes it easier to model processors with fluctuating capacity. The accuracy of the test for systems with such processors can be increased.
  • different capacities can only be assigned to a few time intervals.
  • the capacities are preferably assigned in increasing size to time intervals with increasing size. I.e. larger capacities are assigned to larger time intervals and smaller capacities are assigned to smaller time intervals. For time intervals to which no capacity is assigned, the capacity that is assigned to the next smaller time interval or is used for this can be used to determine the limit value.
  • the limitation to just a few changes in capacity enables a particularly efficient calculation of the limit values. This applies in particular when using the approximation described above. In comparison to the determination of the limit value assuming a constant capacity, a much more precise analysis is possible with only a small additional calculation effort.
  • the event flow model according to Gresser [9] describes the time relationships between two events for the worst case.
  • the idea is to define a minimum time interval between one, two, three or more events by a formal specification of the input stimuli.
  • the model defines the maximum number of events in different predefined time intervals. To formulate the problem in a formal manner, the following definitions are required:
  • the time T is a monotonically arranged set of numbers te R + , which are defined as multipliers for a given physical time period.
  • Each time ti can be described by the interval 1 (0, ti).
  • Processing time c The time interval that a processor needs to calculate a specific piece of software code.
  • a task ⁇ is described by the processing time c for the worst case and by the relative time limit d and represents part of a software code.
  • time barriers are understood to mean relative, fixed time barriers.
  • a processor can only calculate one task ⁇ at a time.
  • EDF Earliest Deadline First
  • An event sequence is an ordered set of events:
  • Event interval function n ⁇ E ⁇ e
  • Event interval function n ⁇ E ⁇ e
  • Event interval function n ⁇ E ⁇ e
  • a homogeneous event sequence E H is an event sequence that consists exclusively of events of the same task:
  • a periodic event sequence E p is a homogeneous event sequence E H , which consists of an infinite number of events separated by a fixed distance (the period p).
  • the order time of the first event is the first order time a of a sequence:
  • a periodic event sequence E p is described by its period p, its first order time a and the values of the underlying task ⁇ , the processing time c for the worst case and the relative time limit d of the corresponding task ⁇ :
  • E P (P, ai, di, C) (*)
  • a periodic event sequence E p with an infinite period is an event sequence E which consists of a single event e.
  • All periodic portions of the event sequence E can be represented by a single periodic event sequence E P.
  • the others are represented by a periodic event sequence E p with an infinite period.
  • the number of periodic event sequences E P can become quite large.
  • each task ⁇ can be described with only one periodic event sequence E P and with exactly two periodic event sequences E P if fluctuations are taken into account.
  • To define a test algorithm only an upper bound for the density of events e has to be taken into account:
  • the event function n e defines the number of events e that can occur in I in the worst case:
  • n e is a monotonically non-decreasing function. It is difficult to describe these functions. to win on from a predetermined event sequence E. For this reason, we consider the reverse function:
  • (3teT: n n e (E, I)) ⁇
  • An event stream E s is a special case of an event sequence E in which all events e occur in their most unfavorable time ratio, which describes the event stream function a (n):
  • Event stream element is a periodic event sequence which belongs to an event stream E s .
  • the time ratio for the worst case describes the density of the events e in the worst case.
  • An interval a (n) is described by the order time interval of an event.
  • the first event ei of the event stream E s represents the limit interval which contains a maximum of one event (which is always 0 in the limit case)
  • the second event e 2 represents the interval which contains two events e
  • the nth event e n represents an interval with n events e n .
  • the event sequence E 2 ⁇ 0, p 2 -t, 2p 2 -t, 3p 2 -t, ... ⁇ , consequently
  • E S 2 ⁇ ( ⁇ 0, d 2 , c 2 ), (p 2 , t, d 2 , c 2 ) ⁇ . It is a periodic sequence of events with elements that can fluctuate. The minimum distance between two events e is pt in this event stream. This occurs if one event occurs at the end of the fluctuation interval and the next event e occurs at the beginning of the next fluctuation interval.
  • the event sequence E 3 ⁇ 0, 0, 0, t, p, p, p, t + p, 2p, 2p, 2p, t + 2p, ... ⁇ .
  • E s3 ⁇ (p, 0, d 3 , c 3 ), (p, 0, d 3 , c 3 ), (p, 0, d 3 , c 3 ), (p, t, d 3 , c 3 ) ⁇ . Note that in an event sequence E, several events e can have the same output time.
  • Event stream E s will maintain the period of the sequence.
  • An algorithm for real-time analysis can be carried out if all events e occur with a smaller or the same density, as described by the event stream E s .
  • n i (Es, I) [((Ia 1 ) / p i ) + 1], I> 0 (*)
  • each event stream element describes a periodic event sequence E p .
  • Each event stream element generates exactly one event e.
  • each task ⁇ has a separate uniform event-E nisstrom s are designed as non-uniform event streams E s are not suitable for real-time analysis.
  • uniform event streams E s can be simply summarized by summarizing the sets of event stream elements. This event stream E s represents the density in the worst case for a single task ⁇ .
  • E S ⁇ and E S2 are both uniform event streams. That is why the summarized event stream
  • D bi The demand flow element D bi is a description of a periodic sequence of the demand. It consists of an end date, period p and the additional requirement requirement c. [((I-di-ai) / pi) + l3 * Ci I ⁇ di
  • a demand flow is a set of demand flow elements D b i that describe the entire scope of the worst case execution.
  • a demand flow can also describe the difference between two alternative event flows E s with different costs and a time course. This concept enables a new formal representation of the barrier function of the demand and results from the definitions given above.
  • An feasibility test or real-time analysis can be constructed using the constraint function of need.
  • a system can be executed if the barrier function of the demand is always less than or equal to 1: Vl> 0 D b (I) ⁇ I
  • the main problem with using the processor demand test is to find the length of the interval I.
  • a scheduling capability test must consider all relevant events to ensure that all tasks are finished before their time limits. Since the barrier function of demand D b (I) is a non-continuous function, " each - event defines a relevant test point for the analysis algorithm defined below. The runtime complexity of the analysis algorithm depends on the length of the interval I.
  • a time interval I max is called the feasibility interval if (3I> 0)
  • Lemma 2 Be the maximum capacity used. Then I max is an executable interval.
  • the approximation is based in particular on reducing the number of test points for each demand flow separately by constructing an approximated demand flow element function D ' b i (I) and superimposing all approximations for an approximated barrier function of the demand D' b (I). This defines a separate test interval for each demand flow element D b i.
  • the maximum test interval I m (ei) of the demand flow element ex is the interval which contains k + 1 test points for ei:
  • a demand flow element D bl is described by its initial end time f and its period p x .
  • the approximated demand flow element function is always the same or larger than the demand flow element function. Of course, it also depends on E s .
  • the approximated barrier function of demand D ' b (I) is a superposition of all approximated demand flow element functions (FIG. 2, right side)
  • the decisive test points of D ' b (I) are all test points of the elements D' b i (I). For intervals greater than I m (ei), the approximated costs for the events ei must be taken into account for each remaining test interval of the demand flow elements.
  • test points I m (e 3 ) 398.
  • the next test point is the first test point of event e 2 ,
  • the error of the approximation is given by the difference between the bound function of the demand D b (I) and the approximated bound function of the demand D ' b (I).
  • the error in the example is less than 0.1%. This means that the feasibility is guaranteed for a processor with a capacity 0.1% larger than that of the optimal processor.
  • Barrier function of need D b (I) to be calculated separately for each test interval. 4 shows a complete algorithm for an approximated executability test. First, this initializes the test list with the first instance of all the demand flow elements Dbi using their end times fi as the start time. Then he processes this list in ascending order of the test intervals. For each event e x , he adds the corresponding costs Ci to the accumulated costs. He checks whether the accumulated costs are higher than the computing time for the current test interval, the test would then fail. If the maximum number of test intervals of this element e ⁇ has not yet been reached, the next instance of this element ei is added to the test list. It is at a distance pi from the current test interval.
  • the test list contains at most one test point of each demand flow element at any time. If the maximum number of test points for an element ei is reached, its utilization becomes ci / pi ü ready added. In this case the next test point is not included in the test list.
  • n the number of barrier elements and k the maximum number of test points for each element ! .
  • the number of barrier elements is equal to the number of tasks ⁇ .
  • the value k is a selectable variable that affects both the complexity and the error of the algorithm. A compromise between the runtime of the algorithm and the error is therefore possible.
  • Each test point must be inserted in a sorted list (O (log n)). Therefore the complexity of the approximated feasibility test is 0 (n * logn * l / ⁇ ).
  • the given analysis error ⁇ places a condition on the processor P, which is used in the final implementation of the system. In order to comply with all time limits of the system under consideration, this processor P is at most ⁇ percent faster than the unknown optimal processor.
  • the algorithm of Baruah et al. [3] shows a pseudo-polynomial complexity that depends on the number of tasks, the total workload and the interval between the periods.
  • the first example comes from [4] and models the Olympus Attitude and Orbital Control System for satellites. This example contains 10 periodic and 4 sporadic tasks and is given in Table 1.
  • the second example was originally presented by Ma and Shin [13] and can also be found in [11].
  • the model describes an application for a palm pilot with 13 different tasks ⁇ . All tasks ⁇ have time limits that are the same with their periods. To define a more difficult problem for the experiment, we set the time limits of tasks ⁇ 7 to 100 ms instead of the 150 ms of the original model.
  • the effort of the algorithm according to the invention - apart from the overhead of the approximation - is always less than or equal to the effort of the exact algorithm, even with a very small error.
  • the complexity of the algorithm according to Chakraborty et al. grows with smaller errors. The density of the test intervals can therefore be greater than is required for the exact algorithm.
  • the results show the same tendency.
  • the algorithm according to the invention tolerates the set of tasks ⁇ with an error of 5%, while the algorithm according to the prior art requires a narrower error (the experiments have shown that an error of 0.2% is sufficient). If both algorithms run with an error of 0.01%, which is close to the optimal processor, then the algorithm according to the invention requires 49 ms in comparison to 1817 ms, which the algorithm of Chakraborty et al. [6] are required.
  • Figure 6 illustrates the reason for this behavior. It contains a section from a test run of the two algorithms compared to the exact solution.
  • the same section of the run of the algorithm according to the invention is shown using an error of 5%. The error allows some test points to be omitted. Nevertheless, the approximation for the critical test points is closer to the exact solution than the approximation according to Chakraborty et al ..
  • the method according to the invention can be carried out while the tasks are being processed by the system. It can be determined essentially simultaneously with the processing of the tasks whether the system can process the tasks in real time. If it is determined that i'as ⁇ s menr to be processed by the system can become aogearoei-cer, measures can be taken at an early stage. The measures can e.g. This could be, for example, the provision of additional resources for processing the tasks, an interruption of tasks or the initiation of error handling.
  • the method according to the invention can be provided on a chip or other hardware as a program for carrying out the method.
  • the method can also be integrated on the chip or hardware on a hardware basis. It is also possible that the program for performing the method on a storage medium, such as. B. a CD, DVD or hard drive is stored.

Abstract

Die Erfindung betrifft ein Verfahren zur Prüfung der Echtzeitfähigkeit eines Systems, insbesondere eines Computersystems, bei dem eine Menge unterschiedlicher Tasks (τ) abzuarbeiten ist, und wobei durch das Abarbeiten jeder Task (τ) Systemkosten entstehen. Um ein besonders schnelles und genaues Verfahren bereitzustellen, wird erfindungsgemäß vorgeschlagen, dass zur Ermittlung der Gesamtkosten (Dbi(I)) für mindestens ein Zeitintervall (I) für mindestens einen ersten Task die tatsächlichen Systemkosten (Dbi(I)) ihrer Jobs, für zumindest einen ersten Task die tatsächlichen Systemkosten (Dbi(I)) von mindestens zwei Jobs der ersten Task und für mindestens einen zweiten Task weitere Systemkosten berücksichtigt werden, wobei die weiteren Systemkosten durch eine Näherung auf der Grundlage der tatsächlichen Systemkosten (Dbi(I)) ermittelt werden.

Description

Verfahren zur Prüfung der Echtzeitfähigkeit eines Systems
Die Erfindung betrifft ein Verfahren zur Prüfung der Echt- zeitfähigkeit eines Systems, insbesondere eines Computersystems .
Die Analyse des zeitlichen Verhaltens von eingebetteten Echtzeitsystemen wird zur Automation der Entwicklung solcher Systeme benötigt. Um feste Zeitschranken zu gewährleisten wurden Tests zur Schedulingfähigkeit in den letzten Jahren eingehend untersucht [1], [2], [3], [5], [6], [7], [8], [9], [12] . Eine gute Einführung in das Gebiet der Echtzeitanalyse ist in [5] gegeben.
Aus [16] ist ein Verfahren zur Zeitanalyse für periodische Echtzeittasksysteme bekannt. Bei dem Verfahren werden von einem Prozessor abzuarbeitende Tasks mit festgesetzten Prioritäten betrachtet. Beim Abarbeiten einer Task ist es mög- lieh, dass es zu einer Blockade für ein Abarbeiten von weiteren Tasks kommt. Bei der Berechnung der für ein Abarbeiten einer Task erforderlichen Systemkosten, wie z. B. der Ausführungszeit, wird die Blockade in Form von zusätzlichen Systemkosten berücksichtigt. Die zusätzlichen Systemkosten werden exakt ermittelt.
Die [17] beschreibt ein Verfahren zur exakten Berechnung der vom Prozessor tatsächlich verbrauchten Systemkosten.
Betrachte folgendes einfaches sporadisches Taskmodell. Gegeben ist eine Menge von Tasks. Jede Task wird beschrieben durch einen Anfangszeitpunkt a, eine relative Zeitschranke d (gemessen vom Anfangszeitpunkt an) , eine Bearbeitungszeit c für den ungünstigsten Fall und einen kleinsten Abstand oder eine kleinste Periode p zwischen zwei Ereignissen der Task.
Ein Ereignis einer Task kann auch als Job bezeichnet werden. Jeder Job hat einen eigenen StartZeitpunkt . Der Startzeitpunkt ergibt sich im ungünstigsten Fall aus dem Anfangzeitpunkt a der Task und dem Abstand bzw. der Periode p. Jedem Job ist die Bearbeitungszeit c und die Zeitschranke d der Task zugewiesen. Die Zeitschranke wird dabei vom Startzeit- punkt des jeweiligen Jobs aus gemessen. Alle Tasks können auf dem gleichen Prozessor ausgeführt werden. Unter einem Prozessor wird eine Ausführungskomponente des Systems, welche Tasks bearbeitet, verstanden. Beispielsweise können Tasks von einer CPU, elektronischen Schaltungsmodulen oder Softwarekomponenten ausgeführt werden. In der folgenden Beschreibung wird von einem Scheduling der Tasks gemäß dem Earliest Deadline First, dem so genannten EDF-Algorithmus ausgegangen. Beim EDF-Algorithmus wird der Task, welcher einen kleinsten zeitlichen Abstand zum Ende der Zeitschranke d der Task aufweist, als Erstes ausgeführt. Es ist auch möglich, dass das Scheduling der Tasks mit anderen Scheduling- verfahren erfolgt.
Falls die Zeitschranken und die Perioden der Tasks nicht gleich sind, ist die Komplexität des Tests zur Schedulingfä- higkeit nicht bekannt [3] . Bis heute gibt es keine Algorithmen mit polynomialer Komplexität. Die am besten bekannten Algorithmen sind Algorithmen mit einer pseudo-polyno ialen Komplexität. Um eine derartige Analyse zur Schedulingfähig- keit bei automatischen Analysemitteln verwenden zu können, ist es erforderlich, die Komplexität des Tests zu reduzieren. Dies kann durch eine Approximation [10] erfolgen, wo- durch ein kleiner Fehler bei den Endergebnissen des Algorithmus in Kauf zu nehmen ist. Ein erster Ansatz war die Analyse nach Baruah et al . [3].
Baruah et al . haben gezeigt, dass dieser Test nur bis zu ei- ne maximalen Intervall Imax durchgeführt werden muss. Um eine pseudo-polynomiale Komplexität zu erreichen betrachten Baruah et al. nur solche Mengen von Tasks, welche eine Prozessorauslastung unterhalb einer vorgegebenen Schranke haben. Dies führt zu einer oberen Schranke für das maximale Intervall Imaχ-
Spuri beschreibt in [14] einen Algorithmus für eine Antwort- Zeit-Analyse für EDF-Scheduling mit einer pseudo- polynomialen Komplexität [15] . Der Algorithmus erfordert je- doch einen höheren Aufwand als der Prozessor-Bedarfstest.
Die Komplexität der oben genannten Tests hängt nicht nur von der Anzahl der Tasks ab, sondern auch vom Verhältnis ihrer unterschiedlichen Perioden.
Kürzlich haben Chakraborty et al. [6] einen anderen Ansatz präsentiert, der dieses Problem löst und zu einem Algorithmus mit polynomialer Komplexität führt. Der Algorithmus wird definiert für ein erweitertes Taskmodell, das wiederkehrende Echtzeit-Taskmodell [1] , [2] . Eine feste Anzahl von Zeitintervallen wird gleichmäßig über das maximale Intervall Imaκ verteilt. Eine kumulierte Bearbeitungszeit wird nur für diese Zeitintervalle .überprüft . Um das richtige Verhalten des Tests auch für Intervalle zwischen den Zeitintervallen zu gewährleisten, wird eine Approximation durchgeführt, bei welcher die kumulierte Bearbeitungszeit mit einer vom System verfügbaren Kapazität für das nächst kleinere Zeitintervall verglichen wird. Der maximale Fehler dieser Approximation ist beschränkt. Der maximale Fehler stimmt mit dem Abstand zwischen zwei Zeitintervallen überein. Falls für alle Jobs aller Tasks der Abstand zwischen dem Ende ihrer Ausführung und ihrer Zeitschranke d größer als der Fehler ist, so ist der Test stets erfolgreich. Bei einer derartigen Approximation ist ein Kompromiss zwischen Ausführungszeit und Fehler des Algorithmus möglich. Ein großer Fehler führt zu nur wenigen Zeitintervallen und folglich zu einer kleinen Ausführungszeit. Ein kleiner Fehler führt zu einer Vielzahl von zu überprüfenden Zeitintervallen und einer großen Ausführungszeit. Falls ein System Tasks mit kleiner Zeitschranke d enthält, so ist der Abstand zwischen den Enden ihrer Ausführungszeit und ihrer Zeitschranken d ebenfalls klein. Um die Aussicht auf eine Akzeptanz eines solchen Systems zu erhöhen darf der Test nur einen kleinen Fehler aufweisen. Dies führt zu langen Ausführungszeiten des Algorithmus. Der Algorithmus schlägt jedoch immer fehl bei Tasks, für welche die Zeitschranke d identisch ist mit deren Bearbeitungszeit für den ungünstigsten Fall.
Aufgabe der vorliegenden Erfindung ist es, die vorgenannten Nachteile nach dem Stand der Technik zu beseitigen.
Diese Aufgabe wird durch die Merkmale des Anspruchs 1 ge- löst. Zweckmäßige Ausgestaltungen ergeben sich aus den Merkmalen der Ansprüche 2 bis 21. Der durch das erfindungsgemäße Verfahren beschriebene Algorithmus ist unabhängig vom Verhältnis und der Größe der Zeitschranken und Abstände bzw. Perioden. Er verwendet eine andere Art von Fehler. Der Algorithmus gewährleistet, dass ein Prozessor mit geringfügig höherer Leistung als die eines unbekannten optimalen Prozessors akzeptiert wird. Ein derartiger optimaler Prozessor ist ein Prozessor dessen Kapazität nicht verkleinert werden kann, ohne das System unausführbar zu machen. Der Fehler ist einstellbar und führt zu einem skalierbaren Algorithmus für die Analyse. Durch Verwenden des erfindungsgemäßen Verfahrens ist es möglich, einen Kom- promiss zwischen der Laufzeit des Algorithmus und der Größe des Fehlers zu schließen.
Das vorgeschlagene Verfahren eignet sich sowohl zur Durchführung einer vorausschauenden Echtzeitanalyse als auch zu einer während des Betriebs des Systems durchführbaren Echtzeitanalyse. Es kann damit insbesondere ermittelt werden, ob das mit der aktuellen Last belastete System noch echtzeitfä- hig ist. Falls mit dem erfindungsgemäßen Verfahren festgestellt wird, dass das nicht mehr der Fall ist, können rechtzeitig Gegenmaßnahmen, wie z. B. eine Bereitstellung zusätzlicher Ressourcen, eine Unterbrechung von Tasks oder eine Fehlerbehandlung, eingeleitet werden. Die Korrektheit des vorgeschlagenen Algorithmus kann formal nachgewiesen werden.
Die Auslastung des betrachteten Systems wird durch Systemkosten beschrieben. Die Systemkosten können auf der Grundlage einer für das Abarbeiten der Tasks erforderlichen Bearbei- tungszeit berechnet werden. Sie können aber auch auf der
Grundlage einer für das Abarbeiten der Tasks erforderlichen Auslastung des Prozessors berechnet werden. Die Echtzeitfähigkeit des Systems wird dann als nicht gegeben angesehen, wenn ein vorgegebener Grenzwert für die in einem Zeitintervall verbrauchten Gesamtsystemkosten überschritten wird. Unter Gesamtsystemkosten werden die kumulierten, für die Abarbeitung der Tasks entstandenen Systemkosten verstanden. Sy- stemkosten für ein Zeitintervall können, je nach Anwendungsfall z. B. verbrauchte, maximal benötigte, angefallene oder angeforderte Kosten sein.
In der vorgeschlagenen Erfindung werden zumindest für ein Zeitintervall weitere Systemkosten von mindestens einer zweiten Task berücksichtigt. Damit ist es möglich die Überprüfung bestimmter größerer Zeitintervalle auszulassen und dadurch den Gesamtaufwand zur Prüfung aller relevanten Zeitintervalle erheblich zu reduzieren. Die zusätzlichen Sy- stemkosten werden durch eine Näherung auf Grundlage der tatsächlichen Systemkosten bestimmt. Unter tatsächlichen Systemkosten einer Task werden diejenigen Systemkosten verstanden, welche vom System beim Abarbeiten tatsächlich verbraucht werden. Die tatsächlichen Systemkosten einer Task können z. B. eine die Ausführungszeit sein, welche das System zum Abarbeiten der Task tatsächlich benötigt. Die tatsächlichen Systemkosten können beispielsweise mit der sogenannten "worst-case-execution-time"-Analyse exakt berechnet werden. Durch die zusätzlichen Systemkosten können die in den ausgelassenen größeren Zeitintervallen anfallenden Kosten teilweise vorweggenommen werden. Im Gegensatz zum Stand der Technik erfolgt diese Vorwegnahme gezielt nur für eine Teilmenge der Tasks. Weiterhin können, im Gegensatz zum Stand der Technik, für die ersten Tasks auch Systemkosten berücksichtigt werden, die zwei oder mehr Jobs dieser Task umfassen. Dadurch kann die Akzeptanzrate des Tests erhöht werden. Insbesondere kann die Akzeptanzrate für eine Menge von Tasks, wobei zumindest für eine Task die Differenz zwi- sehen Zeitschranke und Bearbeitungszeit klein ist, erhöht werden. Dies gilt insbesondere dann, wenn zumindest für denjenigen Task mit kleiner Differenz die Vorwegnahme zukünftiger Kosten nur für Zeitintervalle erfolgt, die mehrere, z. B. mindestens zwei, Jobs umfassen. Ein Intervall umfasst zwei Jobs einer Task, wenn unter Berücksichtigung der kleinsten Abstände und der relativen Zeitschranken der Abstand zwischen dem Anfangszeitpunkt des ersten Jobs der Task und der Zeitschranke des zweiten Jobs der Task nicht größer ist als das Zeitintervall. Dies gilt entsprechend auch für beliebig viele Jobs einer Task.
Die Jobs der Task können je nach vorgegebenem Anwendungsfall entweder mit einem zeitlichen Mindestabstand (sporadischer Fall) oder periodisch (periodischer Fall) auftreten. Eine
Menge von Tasks kann aber auch Tasks aus beiden Fällen beinhalten. Mit dem erfindungsgemäßen Verfahren kann eine Analyse beider Fälle abgedeckt werden.
In einer Ausgestaltung der Erfindung werden für die Tasks zumindest teilweise Testgrenzen eingeführt. Dabei werden nur für solche Tasks zusätzliche Systemkosten berücksichtigt, deren Testgrenze im zu überprüfenden Zeitintervall erreicht wird. Eine erste Task kann bei einem Erreichen der Testgren- ze zu einer zweiten Task werden. Die Testgrenzen können variabel sein, d. h. sie sind nicht notwendigerweise fest vorgegeben. Die Testgrenzen erlauben es das Verhältnis der zusätzlichen Systemkosten zu den Gesamtsystemkosten zu begrenzen. Das Verhältnis kann durch Veränderung der Testgrenzen verschoben werden. Durch eine Erhöhung der Testgrenzen kann die Genauigkeit des Tests gesteigert werden. Es müssen aber u. U. mehr Zeitintervalle überprüft werden. Das Verhältnis kann auch dadurch begrenzt werden, dass feste Testgrenzen verwendet werden. Vorteilhafterweise stellt die feste Testgrenze für eine Task eine Anzahl von Jobs der Task dar, wobei die Testgrenze erreicht ist, wenn das Zeitintervall der Anzahl entsprechend viele Jobs umfasst. Besonders vorteil- haft ist es, für alle Tasks dieselbe feste Testgrenze zu wählen, z. B. dieselbe Anzahl von Jobs. Mit derartigen festen Testgrenzen kann das Verhältnis des Anteils der Task an den Gesamtsystemkosten zu ihren zusätzlichen Systemkosten für jeden Task auf den gleichen Wert begrenzt werden. Das Verhältnis kann zur Abschätzung eines maximal möglichen Fehlers verwendet werden und beispielsweise an den Anwender weitergegeben werden. Andererseits ist es auch möglich, dass der Anwender einen maximal möglichen Fehler vorgibt, auf dessen Grundlage die Testgrenzen bestimmt werden. Die Test- grenze kann z. B. durch einen Zahlenwert repräsentiert werden.
In einer vorteilhaften Ausführung werden die zusätzlichen Systemkosten auf Grundlage der spezifischen Auslastung einer Task berechnet. Diese kann durch den Quotienten aus Rechenzeit und Periode der Task bestimmt werden. Der maximale Fehler für jeden Task kann begrenzt werden. Es ist möglich, dass der maximale Fehler unabhängig von der Länge des zu betrachtenden Zeitintervalls ist. Die spezifische Kapazität kann sinnvoller Weise für die Differenz des Zeitintervalls zum Testintervall der Task bestimmt werden. Der maximale Fehler für jede Task kann auf das zweifache seiner Rechenzeit begrenzt werden.
Vorzugsweise stellt die Testgrenze eine Anzahl von Jobs der Task dar. Die Testgrenze wird in einem Zeitintervall dann erreicht, wenn das Zeitintervall der Anzahl entsprechend viele Jobs umfasst. Der Fehler kann in diesem Fall sogar auf das jeweils Einfache der Rechenzeit der Task begrenzt werden.
Die Berechnung der Gesamtsystemkosten kann schrittweise er- folgen. Vorzugsweise werden Zeitintervalle mit steigender
Länge untersucht. Damit ist es möglich, dass die spezifische Auslastung ab der Testgrenze für die Differenz jeweils aufeinander folgender Zeitintervalle ermittelt wird und als weitere Systemkosten den bisherigen Gesamtkosten zugefügt werden. Die tatsächlichen Systemkosten dieser approximierten Tasks sind in den auf diese Weise ermittelten weiteren Systemkosten bereits erhalten. Infolgedessen kann die Ermittlung der tatsächlichen Systemkosten der approximierten Tasks ausgelassen werden. Die weiteren Systemkosten können für al- le Tasks, deren Testgrenze schon überschritten ist, in einem Schritt ermittelt werden. Dabei werden Zeitintervalle nicht geprüft, für welche sich ausschließlich Systemkosten von Tasks ändern, deren Testgrenze bereits erreicht ist.
Es ist möglich, lediglich Gruppen von Tasks zu betrachten.
Ein derartiges Vorgehen ist insbesondere dann sinnvoll, wenn diese auf unterschiedlichen Prioritätsebenen liegen.
Der Grenzwert für die in einem Zeitintervall verbrauchten Gesamtsystemkosten kann durch eine Menge von Systemkosten beschrieben werden. Beispielsweise kann der Grenzwert durch eine Menge von solchen Systemkosten beschrieben werden, welche der Prozessor innerhalb des dem Grenzwert zugeordneten Zeitintervalls abarbeiten kann. Es ist auch möglich, den Grenzwert mit Hilfe der Kapazität des Prozessors zu bestimmen. Wird eine konstante Kapazität des Prozessors angenommen, so kann der Grenzwert bestimmt werden, indem die Länge des Zeitintervalls mit der Kapazität multipliziert wird. Bei einer derartigen Bestimmung des Grenzwerts wird einem Zeitintervall der doppelten Länge die doppelte Menge an abarbeitbaren Systemkosten zugeordnet.
Nach einer vorteilhaften Ausgestaltung der Erfindung können zur Bestimmung des Grenzwerts verschiedenen Zeitintervallen unterschiedliche Kapazitäten zugeordnet werden. Dadurch können Prozessoren mit schwankender Kapazität besser modelliert werden. Die Genauigkeit des Tests für Systeme mit derartigen Prozessoren kann gesteigert werden. Nach einer weiteren Ausgestaltung können nur einigen Zeitintervallen unterschiedliche Kapazitäten zugeordnet werden. Vorzugsweise werden die Kapazitäten in aufsteigender Größe Zeitintervallen mit ebenfalls steigender Größe zugeordnet. D. h. größere Kapazitäten werden größeren Zeitintervallen und kleinere Kapazitäten werden kleineren Zeitintervallen zugeordnet. Für Zeitintervalle, denen keine Kapazität zugeordnet ist, kann zur Bestimmung des Grenzwerts die Kapazität verwendet werden, die dem nächst kleineren Zeitintervall zugeordnet ist bzw. bei diesem verwendet wird. Durch die Beschränkung auf lediglich einige Kapazitätsänderungen wird eine besonders effiziente Berechnung der Grenzwerte ermöglicht. Dies gilt insbesondere bei Anwendung der oben beschriebenen Approximation. Im Vergleich zur Bestimmung des Grenzwerts unter Annahme einer konstanten Kapazität wird mit einem lediglich geringen zusätzlichen Berechnungsaufwand eine wesentlich genauere Analyse ermöglicht.
Alle bei dem Verfahren verwendeten Zahlenwerte können in ei- nem diskreten Zahlensystem realisiert werden, was die Durchführung des Verfahrens vereinfacht, da keine aufwändigen Gleitkommaoperationen notwendig werden. Bei der nachfolgenden Erläuterung des erfindungsgemäßen Verfahrens wird vom Ereignisstrommodell nach Gresser [9] ausgegangen. Das erfindungsgemäße Verfahren kann aber auch ausgehend von anderen Modellen entwickelt oder auf andere Modelle angewandt werden.
Das Ereignisstrommodell nach Gresser [9] beschreibt die Zeitverhältnisse zwischen zwei Ereignissen für den ungünstigsten Fall. Die Idee besteht darin, einen minimalen Zeit- abstand zwischen ein, zwei, drei oder mehr Ereignissen durch eine formale Spezifikation der Eingabestimuli zu definieren. Das Modell definiert die maximale Anzahl der Ereignisse in unterschiedlichen vorgegebenen Zeitintervallen. Um das Problem in einer formalen Art und Weise zu formulieren werden folgende Definitionen benötigt:
Definition 1. Zeit T
Die Zeit T ist eine monoton angeordnete Menge von Zahlen t e R+, welche als Multiplikatoren für einen vorgegebenen physi- kaiischen Zeitabschnitt definiert sind.
Jeder Zeitpunkt ti kann durch das Intervall 1(0, ti) beschrieben werden.
Definition 2. Spezielles Zeitintervall
Ein spezielles Zeitintervall ist ein Intervall zwischen zwei speziellen Zeitpunkten: Is=(ti,tj).
Definition 3. Zeitintervall I Ein Zeitintervall ist ein Zeitabstand zwischen zwei Zeitpunkten ti und tj : I (Is) = | ti-tj | .
Definition 4. Bearbeitungszeit c Das Zeitintervall, welches ein Prozessor zum Berechnen eines speziellen Teils eines Softwarecodes benötigt.
Definition 5. Task τ
Ein Task τ wird durch die Bearbeitungszeit c für den ungünstigsten Fall und durch die relative Zeitschranke d beschrieben und stellt einen Teil eines Softwarecodes dar. Die relative Zeitschranke ist ein Intervall, welches die maximal zulässige Bearbeitungszeit der Task τ beschreibt: τ=(c,d).
Im Sinne der vorliegenden Erfindung werden unter Zeitschranken relative, feste Zeitschranken verstanden. Ein Prozessor kann jeweils nur einen Task τ berechnen. Im folgenden wird ein Scheduling gemäß dem Earliest Deadline First (EDF) Algo- rith us angenommen, welches sich für die Durchführung des erfindungsgemäßen Verfahrens als besonders vorteilhaft erwiesen hat.
Definition 6. Ereignis e Ein Ereignis ist ein Auftrag zur Ausführung eines Tasks τ zu einem speziellen Zeitpunkt tr (Auftragszeit) : e=(tr,τ) t(e)=tr τ(e)=τ
Definition 7. Ereignissequenz E
Eine Ereignissequenz ist eine geordnete Menge von Ereignissen:
E={e| (t(ei)≥t(ej) o i≥j } Definition 8. Ereignisintervallfunktion n^E,!) Die Ereignisintervallfunktion definiert für ein spezielles Zeitintervall I die Anzahl der Ereignisse, welche innerhalb dieses Zeitintervalls I auftreten: ni (E , Is ) = | { eeE | ti<t ( e ) <ti } |
Definition 9. Homogene Ereignissequenz EH
Eine homogene Ereignissequenz EH ist eine Ereignissequenz, welche ausschließlich aus Ereignissen des gleichen Tasks besteht:
Figure imgf000015_0001
Definition 10. Periodische Ereignissequenz EP
Eine periodische Ereignissequenz Ep ist eine homogene Ereignissequenz EH, welche aus einer unendlichen Anzahl von Ereignissen besteht, die durch einen festen Abstand (die Periode p) getrennt sind. Die Auftragszeit des ersten Ereignis- ses ist die erste Auftragszeit a einer Sequenz:
VeeEH13keN0 +: (k*p+a=t(e) )-
Et Er VkeN0 +|3eeEH: (k*p+a=t (e) )-
Eine periodische Ereignissequenz Ep wird durch ihre Periode p, ihre erste Auftragszeit a und die Werte des zu Grunde liegenden Tasks τ, der Bearbeitungszeit c für den ungünstigsten Fall und die relative Zeitschranke d des entsprechenden Tasks τ beschrieben:
EP=(P,ai,di,C) (*) Eine periodische Ereignissequenz Ep mit einer unendlichen Periode ist eine Ereignissequenz E, welche aus einem einzigen Ereignis e besteht.
Lemma 1 : •
Jede Ereignissequenz E kann durch eine Menge von periodischen Ereignissequenzen EP dargestellt werden: E={EP}.
Alle periodischen Anteile der Ereignissequenz E können durch eine einzige periodische Ereignissequenz EP dargestellt werden. Die anderen werden durch eine periodische Ereignissequenz Ep mit einer unendlichen Periode dargestellt. Jedoch kann für allgemeinere Ereignissequenzen E die Anzahl von pe- riodischen Ereignissequenzen EP ziemlich groß werden. Für die meisten Systeme wird nur eine endliche Menge an periodischen Ereignissequenzen EP benötigt. Im betrachteten sporadischen Tasksystem kann jeder Task τ beschrieben werden mit nur einer periodischen Ereignissequenz EP und mit genau zwei periodischen Ereignissequenzen EP, falls Fluktuationen berücksichtigt werden. Um einen Testalgorithmus zu definieren muss lediglich eine obere Schranke für die Dichte der Ereignisse e berücksichtigt werden:
Definition 11. Ereignisfunktion ne
Die Ereignisfunktion ne definiert für jedes Zeitintervall I die Anzahl der Ereignisse e, die im ungünstigsten Fall in I auftreten können:
Figure imgf000016_0001
Die Ereignisfunktion ne ist eine monoton nicht abnehmende Funktion. Es ist aufwändig, eine Beschreibung dieser Funkti- on aus einer vorgegebenen Ereignissequenz E zu gewinnen. Aus diesem Grund betrachten wir die Umkehrfunktion:
Definition 12. Ereignisstromfunktion a(n) Eine Ereignisstromfunktion a(n) definiert für jede Anzahl n von Ereignissen e das minimale Intervall I, in dem n Ereignisse auftreten können: a(n)=min{IeT| (3teT:n=ne (E, I) ) }
Definition 13. Ereignisstrom Es
Ein Ereignisstrom Es ist ein Spezialfall einer Ereignissequenz E, bei der alle Ereignisse e in ihrem ungünstigsten Zeitverhältnis, das die Ereignisstromfunktion a (n) be- schreibt, auftreten:
Es={eeE|3neN0 +:I(0,t (e) )=a(n) }
Definition 14. Ereignisstromelement Das Ereignisstromelement ist eine periodische Ereignissequenz, welche zu einem Ereignisstrom Es gehört.
Das Zeitverhältnis für den ungünstigsten Fall beschreibt die Dichte der Ereignisse e im ungünstigsten Fall. Ein Intervall a(n) wird durch das Auftragszeitintervall eines Ereignisses eieEs beschrieben. Das erste Ereignis ei des Ereignisstroms Es stellt das Grenzintervall, welches maximal ein Ereignis enthält dar (das im Grenzfall immer 0 ist) , das zweite Ereignis e2 stellt das Intervall dar, welches zwei Ereignisse e enthält und das n-te Ereignis en stellt ein Intervall mit n Ereignissen en dar. Beispiel:
Die Ereignissequenz Eι={ 0,pι, 2px, 3pι, ...} der Fig. 1 ist eine periodische Ereignissequenz. Deshalb ist der Ereignisstrom Esi gegeben durch Esι={ (pi, 0, di, cl) } . Die Ereignissequenz E2={ 0,p2-t, 2p2-t, 3p2-t, ...} , folglich
ES2={ (∞ 0,d2, c2) , (p2, t,d2, c2) } . Es ist eine periodische Ereignissequenz mit Elementen, die fluktuieren können. Der minimale Abstand zwischen zwei Ereignissen e ist in diesem Ereignisstrom p-t. Das kommt vor, falls ein Ereignis am Ende des Fluktuationsintervalls auftritt und das nächste Ereignis e am Anfang des nächsten Fluktuationsintervalls auftritt. Die Ereignissequenz E3={ 0, 0, 0, t,p,p,p, t+p, 2p, 2p, 2p, t+2p, ...} . Folglich Es3={ (p,0,d3,c3) , (p,0,d3,c3) , (p,0,d3,c3) , (p,t,d3,c3) } . Beachte, dass in einer Ereignissequenz E mehrere Ereignisse e die gleiche Ausgabezeit aufweisen können.
Während der Transformation einer Ereignissequenz E in einen
Ereignisstrom Es wird die Periode der Sequenz beibehalten.
Ein Algorithmus zur Echtzeitanalyse ist ausführbar, falls alle Ereignisse e mit einer kleineren oder gleichen Dichte, wie durch den Ereignisstrom Es beschrieben ist, auftreten.
Er ist nicht ausführbar, falls sie mit einer größeren Dichte als durch den Ereignisstrom Es beschrieben ist auftreten.
Durch Verwenden des Begriffs Ereignisstrom Es kann die Er- eignisfunktion ne einfach berechnet werden: ni(Es,I) = [((I-a1)/pi) + 1], I>0 (*)
Es ist zu beachten, dass jedes Ereignisstromelement eine pe- riodische Ereignissequenz Ep beschreibt. Die maximale Anzahl der Ereignisse e im Intervall I ist dann einfach die Summe aller einzelnen Ereignisstromelemente: n VI≥O ne(Es,I)=∑[((I-a1)/p1) + 1] (*; i=l
Beispiel:
Für Kp ist die Anzahl der Ereignisse ES1(I) 1, für p≤I≤2*p ist der Wert 2 usw. Betrachte die Situation im Intervall I=T: ne(ES2,p) = [((t-0)/cc) + l] + [((t-t)/p) + 1]=2
Jedes Ereignisstromelement erzeugt genau ein Ereignis e.
Für jeden Task τ muss ein gesonderter gleichförmiger Ereig- nisstrom Es konstruiert werden, da nicht gleichförmige Ereignisströme Es für Echtzeitanalysen nicht geeignet sind.
Falls alle Tasks τ der gleichen Art unabhängig sind, können gleichförmige Ereignisströme Es einfach zusammengefasst werden, indem die Mengen der Ereignisstromelemente zusammenge- fasst werden. Dieser Ereignisstrom Es stellt für einen einzelnen Task τ die Dichte im ungünstigsten Fall dar.
Beispiel:
ESι und ES2 sind beide gleichförmige Ereignisströme. Deshalb ist der zusammengefasste Ereignisstrom
ESi2={ (°c,0,d2,c2) , (pι,0,dι,cι) , (p2 t,d2,c2) }={ (oc, 0,2000, 900) , (4 ,0,2,2) , (4000, t, 2000, 900) } .
Schrankenfunktion des Bedarfs
Um einen Echtzeitalgorithmus zu konstruieren, ist es notwendig, die maximal benötigte Arbeitslast eines Prozessors in einem vorgegebenen Zeitintervall zu berechnen. Das kann mit der Schrankenfunktion des Bedarfs erreicht werden, welche zuerst von Baruah et al . [1-3] und Gresser [9] definiert und später auch von Buttazzo [5] verwendet wurde. 5 Definition 15. Schrankenfunktion des Bedarfs Db(I): Die Schrankenfunktion des Bedarfs Db(I) bezeichnet den maximalen gesamten Ausführungsbedarf, welcher durch Ereignisse e gegeben ist, die sowohl ihre Auftragszeit als auch ihre 10 Zeitschranke innerhalb eines beliebigen Zeitintervalls der Länge I haben:
Db ( I =∑nι Es , I-di ) *Ci ( * ] i I≥d 15 oder
Db ( I ) =Σ [ ( ( I - • i-ai) /pi) +l] *Ci ( * ) Vi
„20 I≥d i
Bei der Echtzeitanalyse sind nur Ereignisse e relevant, welche sowohl ihre Auftragszeit t(e) als auch ihre Zeitschranke
25 t(e)+de innerhalb des Intervalls I haben. Dies alles sind Ereignisse e, welche im Intervall I-de auftreten. Die Schrankenfunktion des Bedarfs entspricht der Ereignisfunktion und ist ebenso eine monoton nicht fallende Funktion. Demzufolge ist es auch möglich, einen Bedarfsstrom, der dem Er-
30 eignisstrom Es entspricht, zu definieren:
Definition 16. Bedarfsstromelement Dbi Das Bedarfsstromelement Dbi ist eine Beschreibung einer periodischen Abfolge des Bedarfs. Sie besteht aus einem an- fänglichen Endzeitpunkt, der Periode p und der zusätzlichen Bedarfsanforderung c.
Figure imgf000021_0001
[((I-di-ai)/pi)+l3*Ci I≥di
Definition 17. Bedarfsstrom
Ein Bedarfsstrom ist eine Menge von Bedarfsstromelementen Dbi, welche den gesamten Umfang der Ausführung im ungünstigsten Fall beschreiben.
Um einen Ereignisstrom Es auf den zugehörigen Bedarfsstrom zu übertragen, wird jedes Ereignisstromelement ersetzt durch ein Bedarfsstromelement Db mit einem anfänglichen Endzeitpunkt fi=ai+di und den gleichen Kosten Ci und der gleichen Zeitschranke di wie das Ereignisstromelement. Es ist nicht notwendig, dass ein Bedarfsstrom einen entsprechenden Ereignisstrom hat. Ein Bedarfsstrom kann auch den Unterschied zwischen zwei alternativen Ereignisströmen Es mit unterschiedlichen Kosten und zeitlichem Ablauf beschreiben. Die- ses Konzept ermöglicht eine neue formale Darstellung der Schrankenfunktion des Bedarfs und resultiert aus den oben gegebenen Definitionen.
Ausführbarkeitstest
Ein Ausführbarkeitstest oder eine Echtzeitanalyse kann unter Verwendung der Schrankenfunktion des Bedarfs konstruiert werden.
Lemma 2: Bedarfskriterien für den Prozessor
Ein System ist ausführbar, falls die Schrankenfunktion des Bedarfs immer kleiner oder gleich 1 ist: Vl>0 Db(I)<I Das wesentliche Problem bei Verwenden des Prozessor-Bedarfstests ist, die Länge des Intervalls I zu finden. Ein Test zur Schedulingfähigkeit muss alle relevanten Ereignisse berücksichtigen, um sicherzustellen, dass alle Tasks vor ihren Zeitschranken beendet sind. Da die Schrankenfunktion des Bedarfs Db(I) eine nicht stetige Funktion ist," definiert jedes - Ereignis einen relevanten Testpunkt für den weiter unten definierten Analysealgorithmus. Die LaufZeitkomplexität des Analysealgorithmus hängt ab von der Länge des Intervalls I.
Definition 18. Ausführbarkeitsintervall Imax
Ein Zeitintervall Imax wird Ausführbarkeitsintervall bezeichnet, falls (3I>0) | (Db(I)>I)^3l':0<I'<Iaax| (Db(I')>I')
Falls der Prozessor-Bedarfstest für das Zeitintervall I fehlschlägt, gibt es ein Zeitintervall I'<Imax, für welches der Prozessor-Bedarfstest ebenfalls fehlschlägt. Um die Aus- führbarkeit eines vorgegebenen Tasksystems zu zeigen, ist es erforderlich, nur Intervalle I<Imax zu testen. Baruah et al . geben ein solches Ausführbarkeitsintervall an:
Lemma 2 : Sei
Figure imgf000022_0001
die maximal benutzte Kapazität. Dann ist Imax ein Ausführbarkeitsintervall.
Figure imgf000022_0002
Falls U beschränkt ist, kann das Bedarfskriterium für den Prozessor in pseudo-polynomialer Zeit getestet werden. In [15] werden ein paar bessere Ausführbarkeitsintervalle ange- führt. Für all diese Intervalle tritt ein Problem auf, falls Db(I) mehrere Ereignisströme mit einer großen Streuung der Perioden enthält.
Beispiel:
Betrachte ESι und Es2 der Figur (1). U=2/4+900/4000=77 , 5% . Das Testintervall hängt nur von p2 ab. Es ist lmax=0, 775/0, 225* (4000-2000) =6889. Daher sind für e2 2 Testpunkte (zum Zeitpunkt 2000 und 6000) notwendig, während für e3 mehr als 1700 Testpunkte notwendig sind.
Es ist offensichtlich, dass die Komplexität des Prozessor- Bedarfstests auch von den unterschiedlichen Perioden der Menge der Tasks τ abhängt . Um dieses Problem zu vermeiden wird nach Maßgabe der Erfindung eine Approximation vorgeschlagen, welche unabhängig von den vorgegebenen Perioden ist. Der nächste Abschnitt gibt eine derartige Approximation an.
Die Approximation beruht insbesondere darauf, die Anzahl der Testpunkte für jeden Bedarfsstrom separat zu reduzieren durch Konstruieren einer approximierten Bedarfsstromelement- funktion D'bi(I) und Überlagern aller Approximationen für eine approximierte Schrankenfunktion des Bedarfs D'b(I). Da- durch wird für jedes Bedarfsstromelement Dbi ein separates Testintervall definiert.
Definition 19. Maximales Testintervall Im(ei)
Das maximale Testintervall Im(ei) des Bedarfsstromelements ex ist das Intervall welches k+1 Testpunkte für ei beinhaltet:
Im(ei)=k*pi+fi Es ist zu beachten, dass ein Bedarfsstromelement Dbl durch seinen anfänglichen Endzeitpunkt f und seine Periode px beschrieben wird.
Definition 20. Approximierte Bedarfsstromelementfunktion
Dbi (Im(e_.) J+Ci/p * (I-Iffl(e1) ) I>Im(e1) D' bi :D=
Figure imgf000024_0001
Wie Figur 2 zeigt, ist die approximierte Bedarfsstromele- mentfunktion stets gleich oder größer als die Bedarfsstromelementfunktion. Natürlich hangt sie auch von Es ab. Da
C/pχ<l ist es lediglich notwendig, alle Testpunkte bis zu I (eχ) zu überprüfen.
Definition 21. Approximierte Schrankenfunktion des Bedarfs
D'b(I)
Die approximierte Schrankenfunktion des Bedarfs D'b(I) ist eine Überlagerung aller approximierten Bedarfsstromelement- funktionen (Fig. 2, rechte Seite)
Figure imgf000024_0002
Da der Betrag eines jeden approximierten Elements zumindest gleich dem Betrag des genauen Elements ist, ist auch der aufaddierte Betrag der approximierten Elemente zumindest gleich dem Betrag der Schrankenfunktion des Bedarfs. Die entscheidenden Testpunkte von D'b(I) sind alle Testpunkte der Elemente D'bi(I). Für Intervalle größer als Im(ei) müssen die approximierten Kosten für die Ereignisse ei für jedes verbleibende Testintervall der Bedarfsstromelemente berücksichtigt werden.
Beispiel:
Man betrachte nochmals ESι und Es2 der Figur 1. (Sei k=100.
Die maximale Anzahl der Testpunkte Im(e3)=398. Der nächste Testpunkt ist der erste Testpunkt von Ereignis e2,
I=0* 2+d2=2000. Die verbleibenden Testpunkte von Ereignis ei werden übersprungen. Der genaue Wert für den Bedarf von I2 wäre Db(I2) =c2+500*Cι und der genaue Wert von D' (I2) ist D'b(I2)=C2+500,5*Cι.
Der Fehler der Approximation ist durch die Differenz zwischen der Schrankenfunktion des Bedarfs Db(I) und der approximierten Schrankenfunktion des Bedarfs D'b(I) gegeben. Der Fehler des Beispiels ist kleiner als 0,1 %. Das bedeutet, dass die Ausführbarkeit sicnergeste lt ist für einen Prozessor mit einer 0,1 % größeren Kapazität als der des optimalen Prozessors .
Lemma 2 : Sei P ein Prozessor mit einer Kapazität C(I) und P' ein Prozessor mit der Kapazität C ' (I) =C (I) +l/k*C (I) . Falls der Ausführbarkeitstest für den Prozessor P unter Verwendung der Schrankenfunktion des Bedarfs Db(I) gelingt (d.h.
VI :C (I)>Db (I) ) , gelingt auch der Ausführbarkeitstest bei Verwenden der approximierten Schrankenfunktion des Bedarfs D'b(I)- Das bedeutet:
(D« b(I)-Db(I))/Db(I)≤l/k=(C' (I)-C(I))/C(I) Daher kann der Fehler durch die Testschranke k beschränkt werden. Eine Testschranke k von 100 Intervallen führt zu einem maximalen Fehler von 1 %, eine Schranke von 1000 zu ei- nem Fehler von 0,1 %. Der Ursache ist in Fig. 3 dargestellt. Wenn die Testschranke k erreicht ist und die Approximation beginnt, enthält der Bedarf bereits k*Ci Kosten von Dbi. Der maximale Fehler, der von der Approximation von den Ereignissen ei herrührt ist beschränkt auf l*cι. Im ungünstigsten Fall ist das Verhältnis zwischen dem Fehler und den gesamten Kosten kleiner als
Figure imgf000026_0001
Nachfolgend wird beispielhaft ein auf der vorliegenden Erfindung beruhender Algorithmus beschrieben. Für einen lei- stungsfähigen Algorithmus ist es nicht erforderlich, die
Schrankenfunktion des Bedarfs Db(I) für jedes Testintervall separat zu berechnen. Fig. 4 zeigt einen vollständigen Algorithmus für einen approximierten Ausführbarkeitstest. Zuerst initialisiert dieser die Testliste mit der ersten Instanz aller Bedarfsstromelemente Dbi unter Verwendung ihrer Endzeitpunkte fi als Anfangszeitpunkt. Dann prozessiert er diese Liste mit aufsteigender Reihenfolge der Testintervalle. Für jedes Ereignis ex addiert er die entsprechenden Kosten Ci zu den angehäuften Kosten. Er prüft, ob die angehäuften Kosten höher sind als die Rechenzeit für das aktuelle Testintervall, der Test würde dann fehlschlagen. Falls die maximale Anzahl von Testintervallen dieses Elements e± noch nicht erreicht ist, wird die nächste Instanz dieses Elements ei in die Testliste aufgenommen. Es hat einen Abstand pi zum momentanen Testintervall. Daher enthält die Testliste zu jedem Zeitpunkt höchstens einen Testpunkt von jedem Bedarfsstromelement. Falls die maximale Anzahl der Testpunkte für ein Element ei erreicht ist, wird deren Auslastung ci/pi zu üready addiert. In diesem Fall wird der nächste Testpunkt nicht in die Testliste aufgenommen. Die approximierten Kosten approxi werden ebenso für jedes Testintervall addiert. Die Berechnung dieser Kosten ist durch approxi= (Iact- I0id) *Uready gegeben.
Die Komplexität des ursprünglichen Problems ist nicht bekannt. Bisher sind nur pseudo-polynomiale Lösungen bekannt.
Sei n die Anzahl der Bedarfsschrankenelemente und k die maximale Anzahl der Testpunkte für jedes Elemente! . Für das sporadische Tasksystem ist die Anzahl der Bedarfsschrankenelemente gleich der Anzahl von Tasks τ. Der Wert k ist eine wählbare Variable, die sowohl die Komplexität als auch den Fehler des Algorithmus beeinflusst. Deshalb ist ein Kom- promiss zwischen der Laufzeit des Algorithmus und dem Fehler möglich. Der Fehler ε ist ε=l/k. Jeder Testpunkt muss in eine sortierte Liste (O(log n) ) eingefügt werden. Daher ist die Komplexität des approximierten Ausführbarkeitstests 0 (n*logn*l/ε) . Der gegebene Analysefehler ε stellt eine Bedingung an den Prozessor P, der bei der endgültigen Implementierung des Systems verwendet wird. Um alle Zeitschranken des betrachteten Systems einzuhalten ist dieser Prozessor P höchstens ε Prozent schneller als der unbekannte optimale Prozessor.
Im Vergleich zum erfindungsgemäß vorgeschlagenen Algorithmus weist der Algorithmus von Baruah et al. [3] eine pseudo- polynomiale Komplexität auf, die von der Anzahl der Tasks, der Gesamtauslastung und dem Abstand der Perioden abhängt.
Die Komplexität des von Chakraborty et al . [6] gegebenen Algorithmus ist mit der des erfindungsgemäßen Algorithmus ver- gleichbar. Allerdings benutzt der Algorithmus nach Chakraborty et al. [6] eine andere Art von Fehler.
In Fig. 5 ist eine vereinfachte Version des Algorithmus von Chakraborty et al . [6] wiedergegeben. Im folgenden wird die Leistungsfähigkeit des erfindungsgemäßen Algorithmus' mit dem Algorithmus von Chakraborty et al . [6] verglichen. Dazu wurde der Algorithmus nach Chakraborty et al. [6] unter den gleichen Rahmenbedingungen wie der erfindungsgemäße Algo- rithmus in Java implementiert, das auf einem 1GHz PowerPC auf MacOS X läuft.
Zwei Fallstudien werden betrachtet: Das erste Beispiel rührt aus [4] her und modelliert das Olympus Attitüde and Orbital Control System für Satelliten. Dieses Beispiel beinhaltet 10 periodische und 4 sporadische Tasks und ist in Tab. 1 gegeben.
Das zweite Beispiel wurde ursprünglich von Ma und Shin [13] dargelegt und ist auch in [11] zu finden. Das Modell beschreibt eine Anwendung für einen Palmpilot mit 13 verschiedenen Tasks τ. Alle Tasks τ haben Zeitschranken, die gleich mit ihren Perioden sind. Um ein schwierigeres Problem für das Experiment zu definieren haben wir anstelle der 150 ms des ursprünglichen Modells die Zeitschranken der Tasks τ7 auf 100 ms gesetzt.
Betrachten wir das Experiment unter Verwendung der Menge der Tasks des Olympus Attitüde and Orbital Control System. Es ist in den ersten 7 Zeilen von Tab. 2 gezeigt und mit dem Ausdruck SAT bezeichnet. Falls wir einen Approximationsfehler von 0,05 % annehmen, beendet die neue Approximation den Test zur Schedulingfähigkeit nach 114' ms (100 Läufe in 11423 ms), während der Algorithmus nach Chakraborty et al. 228 ms benötigt. Trotz der Tatsache, dass für die Menge der Tasks τ ein Ausführbarkeitsschedule existiert schlägt der Algorithmus nach Chakraborty et al . in den Fällen fehl, wenn er einen gewählten Fehler von 50 %, 5 %, 1 % und 0,5 % verwendet. In all diesen Fällen erzielt der erfindungsgemäße Algorithmus Ergebnisse. Deswegen ist es möglich, mit dem Überlagerungsalgorithmus eine Analyse zur Schedulingfähigkeit in 17 ms mit einem zu erwartenden Fehler von 1 % durchzuführen.
Der Aufwand des erfindungsgemäßen Algorithmus - abgesehen vom Overhead der Approximation - ist stets kleiner oder gleich dem Aufwand des exakten Algorithmus, selbst bei einem sehr kleinen Fehler. Der Aufwand des Algorithmus nach Cha- kraborty et al. wächst mit kleiner werdendem Fehler. Daher kann die Dichte der Testintervalle größer sein als für den exakten Algorithmus erforderlich ist.
Im Beispiel des Palmpilot zeigen die Ergebnisse die αleiche Tendenz. Der erfindungsgemäße Algorithmus toleriert die Menge der Tasks τ mit einem Fehler von 5 %, während der Algorithmus nach dem Stand der Technik einen engeren Fehler benötigt (die Experimente haben gezeigt, dass ein Fehler von 0,2 % ausreichend ist). Laufen beide Algorithmen mit einem Fehler von 0,01 %, der nahe am optimalen Prozessor liegt, so benötigt der erfindungsgemäße Algorithmus 49 ms im Vergleich zu 1817 ms, welche vom Algorithmus nach Chakraborty et al. [6] benötigt werden.
Figur 6 veranschaulicht den Grund für dieses Verhalten. Sie enthält einen Abschnitt aus einem Testlauf der beiden Algorithmen, verglichen mit der exakten Lösung. In a) ist ein Lauf des Algorithmus nach Chakraborty et al . [6] mit einem Fehler von 0,1 % gezeigt. Der Fehler ist zu klein, um irgendeinen Testpunkt in diesem Abschnitt des Laufs auszulassen. Trotzdem liegt die vom Algorithmus nach Chakraborty et al. [6] erzeugte approximierte Bedarfsfunktion stets zeit- lieh vor der exakten Lösung. Daher ist es mit diesem Algorithmus nicht möglich an die exakte Lösung heranzukommen, selbst wenn eine unbegrenzte Anzahl an Testpunkten betrachtet wird. In b) ist der gleiche Abschnitt des Laufs des erfindungsgemäßen Algorithmus bei Verwenden eines Fehlers von 5 % gezeigt. Der Fehler ermöglicht es, einige Testpunkte auszulassen. Trotzdem liegt die Approximation bei den kritischen Testpunkten näher an der exakten Lösung als die Approximation nach Chakraborty et al..
Das erfindungsgemäße Verfahren kann ausgeführt werden, während die Tasks vom System abgearbeitet werden. Es kann im Wesentlichen gleichzeitig mit dem Abarbeiten der Tasks ermittelt werden, ob die Tasks vom System in Echtzeit abarbeitbar sind. Falls festgestellt wird, dass vom System abzu- arbeitende i'asκs menr m tcrnzzeit aogearoei-cer werden können, können frühzeitig Maßnahmen ergriffen werden. Die Maßnahmen können z. B. eine Bereitstellung zusätzlicher Resour- cen zur Abarbeitung der Tasks, eine Unterbrechung von Tasks oder ein Einleiten einer Fehlerbehandlung sein.
Das erfindungsgemäße Verfahren kann auf einem Chip oder einer sonstigen Hardware als Programm zur Durchführung des Verfahrens vorgesehen sein. Das Verfahren kann auch auf Hardwarebasis auf dem Chip oder der Hardware integriert sein. Es ist auch möglich, dass das Programm zur Durchführung des Verfahrens auf einem Speichermedium, wie z. B. einer CD, DVD oder einer Festplatte, gespeichert ist. Literatur
[1] S.K. Baruah, Dynamic- and Sta tic-priority Scheduling of Recurring Real-Time Tasks , Journal of Real-Time Systems, 24, 93-128, 2003. [2] S. Baruah, D. Chen, S. Gorinsky, A. Mok. Generalized Mul tiframe Tasks . The International Journal of Time-Critical Computing Systems, 17, 5-22, 1999. [3] S. Baruah, A. Mok, L. Rosier. Preemptive Scheduling
Hard-Real-Time Sporadic Tasks on One Processor . Proceedings of the Real-Time Systems Symposium, 182-190,1999. [4] A. Burns, A. Wellings. HRT-HOOD: A Stτuctured Design Method for Hard Real -Time Ada Systems . Elsevier, Oxford, 1995. [5] G. Buttazzo, Jϊar Real-Time Computing Systems : Predic- table Scheduling Algori thms and Applica tions . Kluwer Acade- mic Publishers, 1997.
[6] S. Chakraborty, S. Künzli, L. Thiele. Approxima te Sche- dulahili ty Analysis . 23rd IEEE Real-Time Systems Symposium (TRSS), IEEE Press, 159-168, 2002.
[7] S. Chakraborty, T. Erlebach, L. Thiele. On the Complexi - ty of Scheduling Conditional Real-Time Code . TIK Report Nr. 107, ETH Zürich, 2001. [8] D. Chen, A. Mok, S. Baruah. On Modeling Real-Time Task Systems. Lectures on Embedded Systems: Proceedings of The European Educational Forum School on Embedded Systems, in Lecture Notes in Computer Science, No. 1494, 153-169, Springer Verlag, 1998. [9] K. Gresser. Echtzei tnachweis Ereignisgesteuerter Real- zeitsysteme . Dissertation, VDI Verlag, Düsseldorf, 10(286), 1993. (in german) . [10] J. Hromkovic. Algori thmics for Hard Problems . Texts in Theoretical Computer Science, Springer Verlag, 2003. [11] T.M. Lee. J. Henkel. W. Wolf. Dynamic Runtime Re- Scheduling Allowing Mul tiple Implementa tions of a Task for pla tform-based Designs . 296-301. Proceedings of the Design and Test Conference in Europe, DATE, IEEE Press, 2002. [12] C. Liu. J. Layland. Scheduling Algorithms for Multipro- gramming in Hard Real-Time Environments . Journal of the ACM, 20(1), 46-61, 1973. [13] C. Ma, K. Shin. A user-customizable energy-adaptive combined static/dynamic scheduler for mobile Communications . Proceedings of the Real-Time Symposium, 2000. [14] M. Spuri. Analysis of Deadline Scheduled Real-Time Systems , Rapport de Recherche RR-2772, INRIA, Le Chesnay Ce- dex, France 1996. [15] J.A. Stankovic, M. Spuri, K. Ramamritham, G.C. But- tazzo. Deadline Scheduling for Real -Time Systems EDF and Re- lated Algori thms . Kluwer Academic Publishers, 1998. _[16 . Michael Gonzalez Härbour Mark H. Klein and John P. Le- hoczky. Timing Analysis for Fixed-Priority Scheduling of
Hard Real-Time Systems . IEE Transactions on Software Engeneering, Vol. 20 Nr. 1, 1994. [17] Erik Yu-Shing Hu, Guillem Bernat and Andy Wellings. A Static Timing Analysis Environment Using Java Architecture for Safety Critical Real-Time Systems . Proceedings of the
Seventh International Workshop on Object-Oriented Real-Time Dependable Systems 1530-1443/02, 2002.

Claims

Patentansprüche
1. Verfahren zur Prüfung der Echtzeitfähigkeit eines Systems, insbesondere eines Computersystems, bei dem eine Men- ge unterschiedlicher Tasks (τ) vorgesehen ist,
wobei die Tasks (τ) zumindest teilweise wiederholend vom System angefordert und abgearbeitet werden,
wobei ein durch das Abarbeiten jeder Task (τ) definierter Job Systemkosten verursacht,
wobei mehrere Zeitintervalle (I) überprüft werden,
wobei die Echtzeitfähigkeit des Systems dann als nicht gegeben angesehen wird, wenn ein für ein Zeitintervall (I) vorgegebener Grenzwert für die in diesem Zeitintervall verbrauchten Gesamtsystemkosten (Db(I)) überschritten wird,
und wobei zur Ermittlung .der Gesamtsystemkosten (Db(I)) für mindestens ein Zeitintervall
für mindestens einen ersten Task die tatsächlichen Systemkosten (Dbi(I)) ihrer Jobs,
für zumindest einen ersten Task die tatsächlichen Systemkosten (Dbi(I)) von mindestens 2 Jobs der ersten Task
und
für mindestens einen zweiten Task weitere Systemkosten berücksichtigt werden, wobei die weiteren Systemkosen durch eine Näherung auf der Grundlage der tatsächlichen Systemkosten (Dbi(I)) ermittelt werden.
2. Verfahren nach Anspruch 1 wobei mindestens einer Task (τ) eine Testgrenze (ki) zugeordnet wird und wobei für Tasks (τ) , deren Testgrenze (ki) im Zeitintervall (I) erreicht wird, weitere Systemkosten berücksichtigt werden.
3. Verfahren nach Anspruch 2, wobei die erste Task bei überschreiten der Testgrenze (ki) zu einer zweiten Task wird.
4. Verfahren nach einem der Ansprüche 2 oder 3, wobei die Testgrenze (ki) durch einen Zahlenwert repräsentiert wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, wobei angefallene Systemkosten berücksichtigt werden.
X . -Verfahren_nach einem, der. vorhergehenden Ansprüche, wo- bei zur Bestimmung der Gesamtsystemkosten (Db(I)) Gruppen von Tasks berücksichtigt werden.
7. Verfahren nach einem der vorhergehenden Ansprüche, wobei zumindest eine Task (τ) mit einem zeitlichen Mindestab- stand wiederkehrt.
8. Verfahren nach einem der vorhergehenden Ansprüche, wobei mindestens eine Task (τ) periodisch mit einer Periode (Pi) wiederkehrt.
9. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Systemkosten auf der Grundlage einer für das Abar- beiten der Tasks (τ) erforderlichen Bearbeitungszeit berechnet werden.
10. Verfahren nach Ansprüchen 1 bis 8, wobei die Systemko- sten auf der Grundlage einer oberen Schranke der im ungünstigsten Fall benötigten Bearbeitungszeit berechnet werden.
11. Verfahren nach Ansprüchen 1 bis 8, 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.
12. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Grenzwert auf der Grundlage einer im Zeitintervall (I) verfügbaren Kapazität des Systems ermittelt wird.
13. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Gesamtsystemkosten (Db(I)) für diskrete, einen An- -fangs-.~unci- einen Endzeitpunkt aufweisende Zeitintervalle (I) ermittelt werden.
14. Verfahren nach Anspruch 12, wobei der Endzeitpunkt ein Ende einer Zeitschranke eines Jobs einer Task (τ) ist.
15. Verfahren nach einem der vorhergehenden Ansprüche, wobei die weiteren Systemkosten auf Grundlage einer spezifischen Auslastung des Systems für die Task (τ) berechnet werden.
16. Verfahren nach Anspruch 15, wobei die spezifische Auslastung als Quotient aus Bearbeitungszeit (Ci) und Periode (Pi) der Task (τ) berechnet wird.
17. Verfahren nach den Ansprüchen 15 oder 16, wobei die spezifische Auslastung für ein Intervall berücksichtigt wird, welches sich aus einer Differenz zwischen dem Zeitin- tervall (I) und einem zweiten Intervall (Im(eχ)) ergibt, wobei das zweite Intervall (Im(eχ) ) genau den letzten vollständig in beiden Zeitintervallen liegenden Job ( e ) der Task umfasst.
18. Verfahren nach Anspruch 17, wobei genäherte Systemkosten für das Intervall (I) wie folgt berechnet werden:
Dbχ(I (ex) ) + Cχ/pχ* (I-Im(eχ) ) , wobei I>Iπι(e1).
19. Verfahren nach einem der vorhergehenden Ansprüche, wobei derjenige Task (τ) vom System zuerst abgearbeitet wird, für welchen das Ende der Zeitschranke zeitlich am nächsten liegt .
20. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Tasks (τ) in einer durch eine Priorität vorgegebene Reihenfolge vom System abgearbeitet werden.
21. Verfahren nach einem der vorhergehenden Ansprüche, wo- bei die Tasks (τ) mit einem Ereignisstrommodell beschrieben werden.
22. Verfahren nach einem der vorhergehenden Ansprüche, wobei folgender Algorithmus verwendet wird: ALGORITHM ApproxFeasabilityTest INPUT: ListOfEvents {βj}, testLimit i IFU>100%=> not feasible aX= U/(\-U)-maxi≤i≤n(p d:) II Test interval from [3] /eieDb ;testlist.add(/;.,e );. \NH\LE(Iact≤ImaχvListe≠{}) i = testiist.getNextDemand(); I - testlistintervallForDemand(i)
W(D'b > Cb{!) ) => not feasible
Figure imgf000037_0001
test!ist.add(/αc/ + . ,e.) ELSE U→ = Ur→+c pi *old *act ENDWHILE => feasible
23. Verfahren nach einem der vorangehenden Ansprüche, wobei das Verfahren ausgeführt wird, während die Tasks (τ) vom Sy- stem abgearbeitet werden.
24. Verfahren nach Anspruch 23, wobei zumindest eine der folgenden Maßnahmen ergriffen wird, falls festgestellt wird, dass vom System abzuarbeitende Tasks nicht in Echtzeit abar- beitbar sind: Bereitstellung zusätzlicher Resourcen zur Abarbeitung der Tasks, Unterbrechung von Tasks, Einleiten einer Fehlerbehandlung.
25. Chip mit einem Programm zur Durchführung des Verfahrens nach einem der vorangehenden Ansprüche.
26. Speichermedium mit einem Programm zur Durchführung des Verfahrens nach einem der vorangehenden Ansprüche.
PCT/EP2005/005037 2004-05-11 2005-05-10 Verfahren zur prüfung der echtzeitfähigkeit eines systems WO2005111807A2 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/579,828 US8010592B2 (en) 2004-05-11 2005-05-10 Method for testing the real-time capability of a system
EP05752682A EP1756714A2 (de) 2004-05-11 2005-05-10 Verfahren zur prüfung der echtzeitfähigkeit eines systems

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE102004023738 2004-05-11
DE102004023738.7 2004-05-11
DE102004053979.0 2004-11-09
DE102004053979A DE102004053979A1 (de) 2004-05-11 2004-11-09 Verfahren zur Prüfung der Echtzeitfähigkeit eines Systems

Publications (2)

Publication Number Publication Date
WO2005111807A2 true WO2005111807A2 (de) 2005-11-24
WO2005111807A3 WO2005111807A3 (de) 2006-08-03

Family

ID=35134277

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/005037 WO2005111807A2 (de) 2004-05-11 2005-05-10 Verfahren zur prüfung der echtzeitfähigkeit eines systems

Country Status (4)

Country Link
US (1) US8010592B2 (de)
EP (1) EP1756714A2 (de)
DE (1) DE102004053979A1 (de)
WO (1) WO2005111807A2 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8102552B2 (en) 2008-04-03 2012-01-24 Sharp Laboratories Of America, Inc. Performance monitoring and control of a multifunction printer
US8392924B2 (en) 2008-04-03 2013-03-05 Sharp Laboratories Of America, Inc. Custom scheduling and control of a multifunction printer

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2044541A2 (de) * 2006-07-03 2009-04-08 Inchron GmbH Verfahren zur prüfung der echtzeitfähigkeit eines systems
CN102549510B (zh) * 2010-07-20 2014-09-03 西门子公司 用于检查操作系统的实时特性的方法
US9477537B2 (en) * 2010-12-13 2016-10-25 Microsoft Technology Licensing, Llc Reactive coincidence
US10395247B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc Systems and methods for facilitating a secure transaction at a non-financial institution system
US10970688B2 (en) 2012-03-07 2021-04-06 Early Warning Services, Llc System and method for transferring funds
US10078821B2 (en) 2012-03-07 2018-09-18 Early Warning Services, Llc System and method for securely registering a recipient to a computer-implemented funds transfer payment network
US11593800B2 (en) 2012-03-07 2023-02-28 Early Warning Services, Llc System and method for transferring funds
US10395223B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc System and method for transferring funds
US9612907B2 (en) * 2014-02-21 2017-04-04 Unisys Corporation Power efficient distribution and execution of tasks upon hardware fault with multiple processors
CN104572261B (zh) * 2014-12-17 2017-11-17 鞠秋萍 一种动态生成提醒信息的方法
US10839359B2 (en) * 2015-03-23 2020-11-17 Early Warning Services, Llc Payment real-time funds availability
US10769606B2 (en) * 2015-03-23 2020-09-08 Early Warning Services, Llc Payment real-time funds availability
US10878387B2 (en) 2015-03-23 2020-12-29 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US10832246B2 (en) 2015-03-23 2020-11-10 Early Warning Services, Llc Payment real-time funds availability
US10748127B2 (en) * 2015-03-23 2020-08-18 Early Warning Services, Llc Payment real-time funds availability
US11151523B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US10970695B2 (en) 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
US11157884B2 (en) 2015-07-21 2021-10-26 Early Warning Services, Llc Secure transactions with offline device
US10438175B2 (en) 2015-07-21 2019-10-08 Early Warning Services, Llc Secure real-time payment transactions
US10963856B2 (en) 2015-07-21 2021-03-30 Early Warning Services, Llc Secure real-time transactions
US11037122B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US10956888B2 (en) 2015-07-21 2021-03-23 Early Warning Services, Llc Secure real-time transactions
US11386410B2 (en) 2015-07-21 2022-07-12 Early Warning Services, Llc Secure transactions with offline device
US11037121B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11062290B2 (en) 2015-07-21 2021-07-13 Early Warning Services, Llc Secure real-time transactions
US11151522B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US10152360B2 (en) * 2016-04-22 2018-12-11 Schneider Electric Software, Llc Coordinating event-driven object execution
US11144928B2 (en) 2016-09-19 2021-10-12 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
US11042404B2 (en) 2018-03-16 2021-06-22 Imam Abdulrahman Bin Faisal University Real-time feasibility systems and methods

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ALBERS K ET AL: "An event stream driven approximation for the analysis of real-time systems" REAL-TIME SYSTEMS, 2004. PROCEEDINGS. 16TH EUROMICRO CONFERENCE ON JUNE 30 - JULY 2, 2004, CATANIA, ITALY,IEEE, 30. Juni 2004 (2004-06-30), Seiten 187-195, XP002383592 ISSN: 1068-3070 *
BARUAH S K ET AL: "Preemptively scheduling hard-real-time sporadic tasks on one processor" PROCEEDINGS OF THE REAL TIME SYSTEMS SYMPOSIUM. LAKE BUENA VISTA, DEC. 5 - 7, 1990, WASHINGTON, IEEE. COMP. SOC. PRESS, US, Bd. SYMP. 11, 5. Dezember 1990 (1990-12-05), Seiten 182-190, XP010022049 ISBN: 0-8186-2112-5 *
CHAKRABORTY S., ET AL.: "Approximate Schedulability Analysis" PROCEEDINGS REAL-TIME SYSTEMS SYMPOSIUM ON 3-5 DECEMBER 2002, AUSTIN, TX, USA, IEEE, 3. Dezember 2002 (2002-12-03), Seiten 1-10, XP002383591 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8102552B2 (en) 2008-04-03 2012-01-24 Sharp Laboratories Of America, Inc. Performance monitoring and control of a multifunction printer
US8392924B2 (en) 2008-04-03 2013-03-05 Sharp Laboratories Of America, Inc. Custom scheduling and control of a multifunction printer

Also Published As

Publication number Publication date
DE102004053979A1 (de) 2005-12-08
US8010592B2 (en) 2011-08-30
EP1756714A2 (de) 2007-02-28
WO2005111807A3 (de) 2006-08-03
US20080040171A1 (en) 2008-02-14

Similar Documents

Publication Publication Date Title
WO2005111807A2 (de) Verfahren zur prüfung der echtzeitfähigkeit eines systems
EP1831786B1 (de) Verfahren zur verteilung von rechenzeit in einem rechnersystem
DE112012000797B4 (de) Mehrfach-Modellierungsparadigma für eine Vorhersageanalytik
DE2753062C2 (de) Einrichtung zur wiederholten Durchführung von Programmschleifen
DE102010029209B4 (de) Verfahren zur dynamischen Verteilung von einem oder mehreren Diensten in einem Netz aus einer Vielzahl von Rechnern
EP1924913B1 (de) Steuerung eines zugriffs auf dienste und/oder ressourcen eines datenverarbeitungssystems
DE60303413T2 (de) Verfahren und computersystem zum reduzieren von ausführungszeiten bei der materialbedarfsplanung
WO2008003427A2 (de) Verfahren zur prüfung der echtzeitfähigkeit eines systems
EP2386949B1 (de) Verfahren und Vorrichtung zum zuweisen einer Mehrzahl von Teilaufgaben einer Aufgabe zu einer Mehrzahl von Recheneinheiten einer vorgegebenen Prozessorarchitektur
WO2012089579A1 (de) Verfahren und vorrichtung zur verarbeitung von datenelementen mit minimaler latenzzeit
DE102016221526A1 (de) Vorrichtung und Verfahren zum Bearbeiten einer Mehrzahl Aufgaben
DE102009025572A1 (de) Eine Methode zur Entwicklung von garantiert korrekten Echtzeitsystemen
WO2006092318A1 (de) Verfahren zur echtzeitanalyse eines systems
EP1320047B1 (de) Verfahren zur Analyse des Zeitverhaltens komplexer verteilter Systeme
DE102010053971A1 (de) Aufteilen eines gezählten Wertes auf einem auf einem Mehrkernprozessor ausgeführten Task
EP1402423A2 (de) Verfahren zur bestimmung des kritischen pfades einer integrierten schaltung
EP1502189B1 (de) Verfahren zur ermittlung der prioritätsabhangigen rechenzeitverteilung in einem priorit tsgesteuerten mehrprozess-rechenysystem
DE10330839A1 (de) Abstimmbarer Analog-Digital-Wandler
EP1047990B1 (de) Vorrichtung und verfahren zur steuerung von prozessen auf einem computersystem
EP3073375A1 (de) Verfahren zur ermittlung einer maximalen laufzeit für ein tasksystem
DE102007040148B4 (de) Mikroprozessor mit einer Schaltung zum Auswerten einer Vielzahl von Program Counter (PC)-Werten zur Erzeugung von Haltepunkt-Steuersignalen für eine Programmprotokolliereinheit
DE60315264T2 (de) Durch timebox angesteuertes scheduling von softwarekomponenten in hard-echtzeitsystemen
WO2023131450A1 (de) Verfahren zum optimieren eines prozesses
DE19928798C2 (de) Verfahren zur Erfassung der Auslastung eines Prozessors
DE102019201309A1 (de) Computerimplementiertes Verfahren zum Betreiben einer Kraftfahrzeugsteuereinheit

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2005752682

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

WWE Wipo information: entry into national phase

Ref document number: 11579828

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2005752682

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11579828

Country of ref document: US