WO2006092318A1 - Verfahren zur echtzeitanalyse eines systems - Google Patents

Verfahren zur echtzeitanalyse eines systems Download PDF

Info

Publication number
WO2006092318A1
WO2006092318A1 PCT/EP2006/001955 EP2006001955W WO2006092318A1 WO 2006092318 A1 WO2006092318 A1 WO 2006092318A1 EP 2006001955 W EP2006001955 W EP 2006001955W WO 2006092318 A1 WO2006092318 A1 WO 2006092318A1
Authority
WO
WIPO (PCT)
Prior art keywords
act
time
task
time interval
approxlist
Prior art date
Application number
PCT/EP2006/001955
Other languages
English (en)
French (fr)
Inventor
Frank Slomka
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 EP06723199A priority Critical patent/EP1854003A1/de
Priority to JP2007557434A priority patent/JP2008532150A/ja
Priority to US11/884,916 priority patent/US8185900B2/en
Publication of WO2006092318A1 publication Critical patent/WO2006092318A1/de

Links

Classifications

    • 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

Definitions

  • the invention relates to a method for real-time analysis of a system, in particular a technical system.
  • tasks In a variety of technical systems, such as embedded real-time systems or embedded computer systems, it is necessary that the system processes tasks, so-called tasks, in a predetermined time interval, which is also designated with a time limit or deadline. H. is real-time capable. Tasks to be performed by the system are also summarized below under a "task system".
  • Real-time analysis can be used to automate the development of real-time systems. Furthermore, it is possible to perform the real-time analysis while the task system is being executed by the system. If it is determined during execution that specified real-time conditions can not be met by the system, then z. B. measures for limited but still largely secure processing of the task system can be initiated. Such measures can z. For example, outsourced individual tasks for their processing on other systems or system components. It is also possible to defer the execution of individual tasks in favor of other tasks.
  • Real-time analysis methods can be classified into adequate and necessary procedures. With a sufficient procedure, a system can always be classified error-free for a given task system. On the other hand, it may be possible with a sufficient procedure that the system is incorrectly classified as non-real-time capable for a given task system, although the system actually would be able to process the task system in compliance with the specified real-time conditions.
  • a necessary method for real-time analysis for a processor of a computer is known.
  • a maximum test interval i. H. a maximum time interval calculated for a given task system.
  • a time interval located in the test interval is selected according to a predetermined criterion, and the computing time required by the processor for processing the tasks to be processed in the time interval is calculated. Then the calculation time is compared with the length of the time interval.
  • a task system can not be processed in real time if the computing time is greater than the length of the time interval. If the system is real-time capable for the selected time interval, another time interval located in the test interval is checked. The process continues until either it is determined that the system is not real-time capable or until all of the time intervals satisfying the criterion have been verified. Although in the method only time intervals need to be checked, which are within the test interval. However, it may be that many time intervals are unnecessarily checked, unnecessarily prolonging the running time of the process.
  • the computation time is compared with a system capacity, which is available to the system in the next smaller time interval for the execution of tasks. Based on the comparison, it is determined whether the system is real-time capable.
  • a disadvantage of the method is that the comparison leads to an error which can not be completely compensated even by a high number of time intervals. Many systems are falsely classified as non-real-time capable for a given task system.
  • a further disadvantage is that, given a small maximum error selected, the running time of the method can be greater than that of a precise method. In the above methods known in the art, it is necessary to set an accuracy or error of the method before performing the method. An error that is too large for a given task system can cause the system to be incorrectly classified as non-real-time capable. A too small selected error leads to a high expenditure and to high running times.
  • the object of the invention is to eliminate the disadvantages of the prior art.
  • a particularly fast and accurate method for real-time analysis should be specified.
  • This object is achieved by the features of claims 1 and 26 to 28.
  • Advantageous embodiments of the invention will become apparent from the features of claims 2 to 25.
  • a job cost defined by the execution of a task causes the following steps:
  • the time interval is considered to be processable in real time if the total system costs do not exceed the limit, wherein (ii) if the total system cost exceeds the limit, the second quantity, if not empty, is reduced such that system cost is taken into account for further determination of the total system cost for at least one task of a second set of approximate value task and at least that Steps lit. c) and d) are carried out repeatedly, and wherein
  • an approximate value is used for a job of the first quantity and an approximate value for a job of the second quantity.
  • the approximate system cost of a job can be determined based on the system cost of the job.
  • the system costs can be a processing time or computing time or a utilization of the system.
  • the method is an approximation method.
  • the accuracy of the method depends on the thickness of the second set.
  • the accuracy or "degree of approximation" of the method is a measure of the deviation of the approximation method from an exact method. As the degree of approximation increases, the effort to perform the approximation method, e.g. B. the term.
  • the degree of approximation can be changed dynamically during the method.
  • An increase in the degree of approximation can be achieved by reducing the second amount in step lit. d) ii).
  • a reduction / enlargement of the first or second quantity is understood to mean a reduction / increase in the thickness of the first or second quantity.
  • the thickness of the second quantity can already be selected as large as possible at the beginning of the process.
  • the degree of approximation can be dynamically increased during the process by reducing the second amount.
  • a reduction in the second quantity means that the system costs are used to determine the total system costs for at least one job of the second quantity instead of the approximate value. Ie. at least one job of the second quantity is assigned to the first quantity, which is thereby increased. If the steps lit. c) and d) the system cost is used instead of the approximate value of the job. Because the approximate value is greater than the system cost, the overall system cost can be reduced by an approximate error. Due to the reduction of the total system cost, it may be possible that these are smaller than the limit. In this case, the task system may be classified as being processable by the system in real time for the time interval being checked. If the total system costs are greater than the limit despite the reduction, the second quantity can be further reduced and the first quantity can be further increased. Subsequently, the
  • the system is in particular a technical system, for.
  • a technical system for.
  • an embedded real-time or computer system with one or more interconnected computers, electronic circuits and controls, and the like.
  • the second amount when the total system cost is less than the threshold, the second amount is increased. Increasing the second set increases the number of approximated jobs. Consequently, the degree of approximation decreases and the running time of the method can be reduced. The process can be carried out even faster and more efficiently.
  • At least one task is assigned a changeable test limit, whereby for tasks whose test limit is exceeded in the time interval, the approximate value is used for the jobs of the task, and wherein if the total system costs are greater than the limit, at least one test limit of a task is changed such that the second amount is reduced.
  • the ratio of the approximate values to the total system costs can be limited or shifted.
  • the ratio can z. B. used to determine a current error or a current degree of approximation and passed to the user.
  • the thickness of the second set and the associated degree of approximation can be changed in a particularly simple manner by increasing or decreasing the test limits. By increasing the test limit / n, the degree of approximation can be increased.
  • the test limit for ne task is a number of jobs of the task.
  • the test limit is reached if there are a corresponding number of jobs in the time interval of the number. It is particularly advantageous, at least initially, to choose the same test limit for all tasks, eg. For example, the same number of jobs.
  • At least one numerical value such.
  • B. a test limit, increased, preferably doubled, and / or to increase the second amount at least one numerical value, such.
  • a change in the numerical value can be done, for example, by a predefined arithmetic operation in a particularly simple and fast manner.
  • the method is continued with an already checked time interval in which the overall system costs were less than the limit value.
  • an arbitrary time interval can be selected in which the total system costs were less than the limit value.
  • results of already checked time intervals can be used. A repeated implementation of the method from the beginning can be avoided. The process can be carried out particularly quickly and efficiently.
  • one of the following characteristics of the tasks is used to reduce the second quantity takes into account: amount of actual system cost, error rate of approximate system cost of a total error of the procedure. It is possible to first eliminate the approximation for jobs that cause the highest system cost. Similarly, the approximation can first be reversed for those jobs that have the largest error fraction. This can be achieved that the total system costs are reduced by the highest possible amount.
  • the real-time capability is checked successively for time intervals of increasing size. If a time interval can be processed in real time, all smaller time intervals can also be considered to be processable in real time. If the total system costs exceed the limit value in a checked time interval, the method can be continued in the same time interval with a higher degree of approximation. If the time intervals are checked in ascending order of magnitude, the total system costs can be particularly simple, eg. B. by adding up the system costs and the approximate values are determined.
  • the tasks for the determination of the total system costs are grouped. Such a procedure is particularly useful if they are at different priority levels.
  • At least one task is repeatedly executed by the system.
  • at least one task is executed with a minimum time interval or periodically with one period.
  • a further embodiment of the invention provides that the system costs are calculated on the basis of a processing time required for the execution of the tasks. It it is also possible that the system costs are calculated on the basis of an upper limit for the maximum required processing time. Furthermore, it is possible to calculate the system cost on the basis of a utilization of an execution component, preferably a CPU, of the system required for the execution of the jobs.
  • the limit value is determined on the basis of a capacity of the system available in the time interval. For example, it is possible to
  • Limit using the capacity of a processor or a CPU to determine If a constant capacity is assumed, the limit can be determined by multiplying the length of the time interval by the capacity. In this determination, a time interval of twice the length is assigned the double limit. It is also possible to describe the limit by an amount of system cost that can be processed by the CPU within the time interval associated with the limit. Furthermore, different limit values can be used for different time intervals. This allows better modeling of processors with fluctuating capacity. It is also possible to assign different limit values only to some time intervals. The limit values are preferably assigned in increasing size to time intervals of likewise increasing size. A threshold determined for a time interval may be used to determine the threshold of a larger, e.g. B. the next larger, time interval can be used. Compared with the method with fixed limits, a much more precise analysis can be made possible with a small additional calculation effort.
  • the total system costs for discrete, an initial and an end time having time intervals are determined, the end time
  • An end of a time limit is up to which a job of a task is to be processed at the latest.
  • the approximate value for a job is calculated based on a specific utilization of the system.
  • the specific utilization in turn can be calculated as a quotient of the processing time and period of the task. It is also possible that the specific utilization is taken into account for an interval which is smaller than the time interval.
  • That task is processed by the system first, for which the end of the time limit is closest in time. It is also possible for the tasks to be processed by the system in a priority order. Furthermore, the tasks can be described with an event stream model.
  • R act R act + C act + ( act - I old ) * U approx WHILE (R act > I act )
  • ⁇ rev means the number of tasks for which the system costs are taken into account in a further run of the algorithm instead of the respective approximate values.
  • a computer program product comprising computer readable program code means for performing the method according to the invention on a
  • Computer system provided. Furthermore, a digital storage medium with a computer-readable program stored thereon for carrying out the method according to the invention is provided. Furthermore, a computer system is provided, comprising a digital storage medium with program code means executable by the computer system for carrying out the method according to the invention.
  • an approximation method for real-time analysis of a system is considered.
  • a system-executable task system ⁇ n with n tasks ⁇ is provided, where n is a natural number.
  • system costs which caused by the execution of a task ⁇ € ⁇ n
  • a computation time required by the system for executing the task ⁇ is used.
  • Time intervals I are checked which are smaller than a predefined maximum time interval I max .
  • the time intervals I have a common start time.
  • An end time of a time interval I is given by an end of a time limit d ⁇ of a job of a task ⁇ of the task system ⁇ n . Ie. the job must be completed at the latest by the end time.
  • time intervals I ⁇ i he, ..., he I ⁇ n ⁇ e I max are selected.
  • the time intervals I ⁇ ⁇ , ... or I ⁇ n include 1, 2, ... and n ⁇ jobs of the task ⁇ .
  • a test limit T max ( ⁇ ) dependent on the parameters of the task ⁇ is also determined, for which applies: T max ( ⁇ ) he I max .
  • T max ( ⁇ ) he I max When determining a total computing time, the actual computing time of the jobs of the task ⁇ is used for the time intervals I er T max ( ⁇ ).
  • time intervals I For time intervals I, with T max ( ⁇ ) he I er I max an approximate value for the computing time is used, which is greater than the computing time.
  • corresponding time intervals are selected for each task of the task system.
  • the numbers n ⁇ and the error of the approximation method are interdependent.
  • the selected time intervals are checked in ascending order.
  • the total computing time is determined which is required by the system for processing the jobs arising therein and compared with a limit value for the computing time in the respective time interval.
  • the system is real-time capable if the total computation time is less than the limit.
  • n ⁇ 1 If the total computation time containing an error exceeds a limit for the computation time available in the checked time interval, the test limit becomes
  • T max U is shifted or increased and, accordingly, the maximum number n t of the time intervals is increased for at least one task ⁇ .
  • the real-time capability for the time interval is checked again by recalculating the total system costs and comparing them with the limit value. If the total system costs are less than the limit value, the next larger time interval can be checked. If the total system costs continue to exceed the limit value, once again one or more test limits T max ( ⁇ ) can be shifted.
  • the test limit T max ( ⁇ ) can be z. B. be increased by doubling the number n ⁇ .
  • the test limit T max ( ⁇ ) can be z. B. be increased by doubling the number n ⁇ .
  • at least one test limit T max ( ⁇ ) is shifted over the end time of the time interval being checked. This affects the number of jobs for which an approximate calculation time value is used in the time interval. If the number of approximated jobs is reduced, the total computation time is reduced by the error rate of the jobs that are no longer approaching. As a result, by increasing the degree of approximation, the determined total computing time can be reduced. It may be that this reduction reduces the determined total computation time below the limit value. If this can be achieved, the task system can be accepted for the checked time interval.
  • time intervals I are checked in size in ascending order. If the checked time interval I is classified as realizable in real time, this also applies to all smaller time intervals I. If the checked time interval I is classified as not processable in real time, the system costs are used instead of the approximate value for at least one approximated job of a task , It is sufficient to recheck the already checked time interval I from. It is not mandatory that the real-time analysis be continued with a smaller time interval I or repeated from the beginning.
  • the method can be realized as follows:
  • a specific utilization U of the task system ⁇ n can be calculated as follows:
  • ⁇ ⁇ , i 1, 2, ... tasks from the task system ⁇ n , c ⁇ the system costs, such. For example, a computation time required by the system to execute the task ⁇ i, and pi a period or a minimum time interval of the task Xj . ,
  • a first step it is checked whether the specific utilization U exceeds the value 1. In this case, the task system is not real-time capable and the real-time analysis can be ended.
  • one or more maximum test intervals I max are determined. Furthermore, variables required to perform the method are initialized, such as. For example, the total system cost as a cumulative current calculation time R act for the current time interval I act - A time interval preceding the current time interval I act is denoted by I o i d .
  • the respective first time interval I ⁇ i i of the task Ti of the task system T n is inserted into a test list TestList.
  • the first time interval I ⁇ i i results from a time limit d ⁇ .
  • an allowable number of time intervals is determined.
  • the number Anz is set to 1 and a list ApproxList of tasks ⁇ , whose jobs are approached, is empty.
  • the subsequent instructions are repeatedly executed until either the test list TestList is empty, or the maximum test interval is exceeded or reached, ie when, for example, the test list is empty. For example, I ac t ⁇ Imax
  • the first instruction is the current time interval I act .
  • the current time interval I act is equated with the smallest time interval from the test list TestList. The smallest time interval is removed from the test list TestList. If this time interval is contained several times for different tasks Ti in the test list TestList, only one entry is deleted. ⁇ ac t denotes the task associated with the current time interval I act .
  • the calculation time R act is calculated using the following formula:
  • ⁇ acfc R-old + C act + U appro ⁇ X (I aat - I 0 Id)
  • U appro ⁇ denotes a specific utilization of the approached tasks.
  • U approx can be calculated with the following formula:
  • U apPro ⁇ can also be stored in a variable and updated during real-time analysis if necessary.
  • the cumulative current computing time R act is compared with a limit value GW act for the current time interval I ac t.
  • the limit value GW act can be equated, for example, with the interval length of the current time interval I act .
  • the real-time detection for the time interval I act is provided.
  • a next instruction checks whether the test limit T max ( ⁇ ac t) of the current task ⁇ ac t has been reached or exceeded.
  • the test limit T max ( ⁇ act ) depends on the currently permissible number of times the time interval. Ie off. For periodic tasks, the check can be done by the following formula:
  • d act denotes the current time limit and p act the period of the task ⁇ ac t. If the test limit T max ( ⁇ act ) is reached, the task ⁇ act is added to the list ApproxList of the approximated tasks in a next instruction. If necessary, U approx is updated.
  • a next larger time interval I next for the task ⁇ act is inserted into the test list TestList.
  • the time interval I next can be determined as follows:
  • the value of the last accepted time interval I o i d is set to the value of the current time interval I ac t.
  • the number is increased.
  • the number Anz can be doubled, for example. It is then checked whether, due to the increase, one or more tasks included in the list ApproxList are no longer approached. The no longer approached tasks are determined. Those tasks are determined which, as a result of the increased number Anz, are assigned a test limit T max ( ⁇ ) which is greater than the current time interval I act . The tasks thus determined are removed from the list ApproxList and their next time interval, which is greater than I act , is inserted in the list TestList. Then the computation time R act is reduced by the error proportion of the tasks no longer approximated and as determined above. For periodic tasks, the error in a time interval I can be calculated as follows:
  • ⁇ ⁇ r pi, and c ⁇ denote the time limit, period and system cost, eg.
  • a task Ti of Tasksy- stems ⁇ n As the computing time, a task Ti of Tasksy- stems ⁇ n .
  • the errors calculated in this way are subtracted from the calculation time R act . If the reduced computing time R ' act is still greater than the limit value GW act , then the increase in the number of pulses was not yet sufficient. The number Anz is further increased, for example doubled again. The increase in the number is repeated until either the reduced calculation time R ' act is less than or equal to the limit value GW a c t , or until the list ApproxList is empty.
  • calculation time R ' act drops below the limit value GW act as a result of an increase in the number Anz, the method is continued as in the first case. If the calculation time R ' ac t is greater than the limit value GW act for every increase in the number Anz, then the system is not capable of real-time execution for the task system ⁇ n .
  • the degree of approximation can be reduced again.
  • the degree of approximation can be dynamically adapted to the requirements of the task system ⁇ n be adjusted, whereby the duration of the process can be further minimized. For example, a maximum number of tasks can be approached for each time interval. The following procedure can be used:
  • the time intervals are checked in size in ascending order. Is determined is that the calculation time R act in a calibrated time interval is less than the limit value GW act, the number Num is reduced so that the number of tasks for which an approximate value for the
  • test limit T max (O for at least one task ⁇ is shifted in such a way that the task ⁇ is approximated in the time interval I ac t or I new .
  • the tasks ⁇ become as early as possible, e.g. B. each after the first time interval I ⁇ i, approximated. This approximation can be canceled as described above. If an approximation is removed, it may be attempted to approximate as soon as possible, z. B. in the next time interval to reintroduce. In the method, it is possible to insert time intervals only in the test list TestList, if this is due to the cancellation of an approximation. The method allows a far-reaching approximation, is fast and accurate.
  • the fourth embodiment can be realized, for example, as follows:
  • the first time intervals I ⁇ ⁇ which are produced in each case from the first job of each task ⁇ become the test list
  • TestList inserted.
  • the time intervals I ⁇ i in the test list TestList are then processed in ascending order of size, ie the real-time capability of the Systems checked for these intervals. All other time intervals I of the tasks are initially approximated, ie are not included in the test list TestList. If real-time detection fails for a time interval 1 ⁇ , the approximation is gradually canceled as described above. This is done either until the real-time evidence for the checked time interval I is provided or no task can be approached. If a task can no longer be approached, the task system is not real-time capable.
  • the cancellation of the approximation of a task ⁇ leads to the fact that for this task ⁇ a time interval I ⁇ i, i> 2, is inserted into the test list TestList.
  • the time interval I ⁇ i corresponds to the next larger time interval of the task ⁇ , which follows a time interval in which the test failed.
  • the next larger time interval can be determined in the same way as the dynamic error real time analysis.
  • the real-time analysis ends when all tasks are approached in a time interval and / or the calculation time R act is greater than the limit value GW ac t-
  • a particularly low duration of the method can be achieved due to a significant reduction in the number of time intervals to be checked.
  • z. B. dynamic it is possible to analyze the real-time capability of systems particularly accurate.
  • the inventive method can by a, in particular technical, system such.
  • a computer system are executed in parallel to the execution of the task system. It can be checked in advance whether the tasks of the task system can be processed in real time. If z. B. determined that a real-time condition for a given future date can not be met, it is possible individual tasks to outsource for faster processing to other system components or other systems. By such outsourcing can be achieved in the favorable case that the real-time condition can be met in the future time. It is also possible that a processing of individual tasks is postponed. For example, the processing of such tasks can be postponed, which are not mandatory for safe operation of the system or emergency operation of the system. It can improve the functioning of the system.
  • the method according to the invention can also be used in a system with several interacting components.
  • Information about the real-time capability of the components obtained by the method can be used to suitably plan or define a processing of tasks on the individual components. It can be optimized and improved the interaction of the components.
  • inventive method for the development of technical systems such. Embedded real-time or computer systems, electronic circuits or controllers and the like. , be used.
  • Ci costs d ⁇ , ie time limit

Landscapes

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

Abstract

Die Erfindung betrifft ein Verfahren Echtzeitanalyse eines Systems, insbesondere eines technischen Systems, wobei vom System Tasks (t) abzuarbeiten sind und wobei ein durch das Abarbeiten einer Task (t) 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, I<SUP>t</SUP> <SUB>1</SUB>,

Description

Verfahren zur Echtzeitanalyse eines Systems
Die Erfindung betrifft ein Verfahren zur Echtzeitanalyse ei- nes Systems, insbesondere eines technischen Systems.
Bei einer Vielzahl von technischen Systemen, wie beispielsweise eingebetteten Echtzeitsystemen oder eingebetteten Computersystemen, ist es erforderlich, dass das System Aufgaben, sogenannte Tasks, in einem vorgegebenen, auch mit Zeitschranke oder Deadline bezeichneten Zeitintervall abarbeitet, d. h. echtzeitfähig ist. Vom System abzuarbeitende Aufgaben werden im Folgenden auch unter einem "Tasksystem" zusammengefasst .
Die Echtzeitanalyse kann zur Automatisierung der Entwicklung von EchtzeitSystemen verwendet werden. Ferner ist es möglich, die Echtzeitanalyse durchzuführen, während das Tasksystem vom System abgearbeitet wird. Wird während der Abarbeitung festgestellt, dass vorgegebene Echtzeitbedingungen vom System nicht eingehalten werden können, so können z. B. Maßnahmen zur eingeschränkten aber dennoch weitgehend sicheren Abarbeitung des Tasksystems eingeleitet werden. Derartige Maßnahmen können z. B. darin bestehen, einzelne Tasks zu deren Abarbeitung auf andere Systeme oder Systemkomponenten auszulagern. Es ist auch möglich, die Abarbeitung einzelner Tasks zugunsten anderer Tasks zurückzustellen.
Verfahren zur Echtzeitanalyse können eingeteilt werden in hinreichende und notwendige Verfahren. Mit einem hinreichen- den Verfahren kann ein System für ein vorgegebenes Tasksystem stets fehlerfrei klassifiziert werden. Hingegen kann es bei einem hinreichenden Verfahren möglich sein, dass das System für ein vorgegebenes Tasksystem fälschlicherweise als nicht echtzeitfähig klassifiziert wird, obwohl das System tatsäch- lieh in der Lage wäre, das Tasksystem unter Einhaltung der vorgegebenen EchtZeitbedingungen abzuarbeiten.
Aus S. Baruah, A. Mok, L. Rosier: "Preemptively Scheduling Hard-Real-Time Sporadic Tasks on One Processor." in Procee- dings of the Real-Time Systems Symposium, 182-190, 1990, ist ein notwendiges Verfahren zur Echtzeitanalyse für einen Prozessor eines Computers bekannt. Bei dem Verfahren wird zunächst ein maximales Testintervall, d. h. ein maximales Zei- tintervall, für ein vorgegebenes Tasksystem berechnet. Anschließend wird ein im Testintervall gelegenes Zeitintervall nach einem vorgegebenen Kriterium ausgewählt und die vom Prozessor zur Abarbeitung der im Zeitintervall abzuarbeitenden Tasks benötigte Rechenzeit berechnet. Dann wird die Rechen- zeit mit der Länge des Zeitintervalls verglichen. Ein Tasksystem gilt als nicht in Echtzeit abarbeitbar, wenn die Rechenzeit größer als die Länge des Zeitintervalls ist. Ist das System für das ausgewählte Zeitintervall echtzeitfähig, wird ein weiteres im Testintervall gelegenes Zeitintervall über- prüft. Das Verfahren wird so lange fortgesetzt, bis entweder festgestellt wird, dass das System nicht echtzeitfähig ist, oder bis alle das Kriterium erfüllenden Zeitintervalle überprüft worden sind. Zwar brauchen bei dem Verfahren nur Zeitintervalle überprüft werden, welche im Testintervall liegen. 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 dessen Laufzeit nicht nur von der Größe des Tasksystems, sondern auch vom Verhältnis von Parametern, wie z. B. der Periode, Deadline oder Aus- führungszeit, der Tasks 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 lβth 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 des Systems sehr viele Zeitintervalle überprüft werden. Das führt zu einer hohen Laufzeit des Verfahrens.
Aus M. Devi: "An Improved Schedulability Test for üniproces- sor Periodic Task Systems", in IEEE Proceedings of the 15th Euromicro Conference on Real-Time Systems, 2003, ist ein hin- reichendes 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" bezeich- net. Bei dem Verfahren nach Devi kann es allerdings vorkommen, dass ein für ein Tasksystem tatsächlich echtzeitfähiges System nicht als solches erkannt und falsch klassifiziert wird. Das ist beispielsweise für Tasksysteme der Fall, welche eine optimale Auslastung des Systems ermöglichen.
Ein weiteres Verfahren zur Echtzeitanalyse ist aus S. Cha- kraborty, 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. Zur Prüfung der Echtzeit- fähigkeit wird eine fest vorgegebene Anzahl an Zeitintervallen überprüft. Der maximale Fehler ist abhängig von der Anzahl der Zeitintervalle. Die Zeitintervalle können erhalten werden, indem ein minimales Zeitintervall sukzessiv jeweils um einen vorgegebenen Betrag vergrößert wird. Für jedes Zeitintervall erfolgt eine exakte Berechnung der vom System zum Abarbeiten der im Zeitintervall abzuarbeitenden Tasks benötigten Rechenzeit. Die Rechenzeit wird mit einer Systemkapa- zität verglichen, welche dem System im nächst kleineren Zeitintervall zur Abarbeitung von Tasks zur Verfügung steht. Auf der Grundlage des Vergleichs wird ermittelt, ob das System echtzeitfähig ist. Ein Nachteil des Verfahrens ist, dass der Vergleich zu einem Fehler führt, welcher auch durch eine hohe Anzahl an Zeitintervallen nicht mehr vollständig ausgeglichen werden kann. Viele Systeme werden für ein vorgegebenes Task- system fälschlicherweise als nicht echtzeitfähig klassifiziert. Ein weiterer Nachteil besteht darin, dass bei einem klein gewählten maximalen Fehler die Laufzeit des Verfahrens größer sein kann, als die eines exakten Verfahrens. Bei den obigen nach dem Stand der Technik bekannten Verfahren ist es erforderlich, dass eine Genauigkeit bzw. ein Fehler des Verfahrens vor Durchführung des Verfahrens festgelegt wird. Ein für ein vorgegebenes Tasksystem zu groß gewählter Fehler kann dazu führen, dass das System fälschlicherweise als nicht echtzeitfähig klassifiziert wird. Ein zu klein gewählter Fehler führt zu einem hohen Aufwand und zu hohen Laufzeiten.
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 bis 28. 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, wobei der Näherungswert größer als die entsprechenden Systemkosten ist,
b) 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 zumindest die Schritte lit. c) und d) wiederholt durchgeführt 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. Bei den Systemkosten kann es sich um eine Bearbeitungszeit bzw. Rechenzeit oder eine Auslastung des Systems handeln. Sofern die zweite Menge nicht leer ist handelt es sich bei dem Verfahren um ein Näherungsverfahren. Die Genauigkeit des Verfahrens ist abhängig von der Mächtigkeit der zweiten Menge. Die Genauigkeit bzw. der "Grad der Approximation" des Verfahrens ist ein Maß für die Abweichung des Näherungsverfahrens von einem exakten Verfahren. Mit steigendem Grad der Approximation steigt im Allgemeinen der Aufwand zur Ausführung des Näherungsverfahrens, z. B. die Laufzeit. Bei dem erfindungsgemäßen Verfahren kann der Grad der Approximation während des Verfahrens dynamisch verändert werden. Eine Erhöhung des Grads der Approximation kann durch eine Verringerung der zweiten Menge im Schritt lit. d) ii) erfolgen. Unter einer Verringerung/Vergrößerung der ersten bzw. zweiten Menge wird eine Verringerung/Vergrößerung der Mächtigkeit der ersten bzw. zweiten Menge verstanden. Um die Laufzeit des Verfahrens möglichst gering zu halten kann die Mächtigkeit der zweiten Menge bereits zu Beginn des Verfahrens, möglichst groß gewählt werden. Infolgedessen startet das Verfahren mit einem kleinen Grad der Approximation, niedrigem Aufwand und einer kleinen Laufzeit. Der Grad der Approximation kann im Verlauf des Verfahrens durch eine Verringerung der zweiten Menge dynamisch erhöht werden. Eine Verringerung der zweiten Menge führt dazu, dass zur Ermitt- lung der Gesamtsystemkosten zumindest für einen Job der zweiten Menge an Stelle des Näherungswerts die Systemkosten verwendet. D. h. zumindest ein Job der zweiten Menge wird der ersten Menge zugeordnet, welche dadurch vergrößert wird. Bei einer wiederholten Durchführung der Schritte lit. c) und d) werden an Stelle des Näherungswerts des Jobs dessen Systemkosten verwendet. Weil der Näherungswert größer als die Systemkosten ist, können die Gesamtsystemkosten um einen im Näherungswert enthaltenen Fehler verkleinert werden. Infolge der Verkleinerung der Gesamtsystemkosten kann es möglich sein, dass diese kleiner als der Grenzwert sind. In diesem Fall kann das Tasksystem für das überprüfte Zeitintervall als vom System in Echtzeit abarbeitbar klassifiziert werden. Sind die Gesamtsystemkosten trotz der Verkleinerung größer als der Grenzwert kann die zweite Menge weiter verkleinert und die erste Menge weiter vergrößert werden. Anschließend kann die
Echtzeitfähigkeit im Zeitintervall auf der Grundlage der verkleinerten zweiten Menge und der vergrößerten ersten Menge erneut überprüft werden. Dieser Vorgang, bei welchem der Grad der Approximation dynamisch erhöht wird, kann iterativ fort- gesetzt werden. Bei einem fest vorgegebenen Grad der Approximation wäre hingegen das System für das Tasksystem bereits bei einer erstmaligen Überschreitung des Grenzwerts als nicht echtzeitfähig klassifiziert worden. Mit dem erfindungsgemäßen Verfahren können Tasksysteme mit größerer Sicherheit richtig klassifiziert werden. Ferner können durch die Möglichkeit ei- ner dynamischen Veränderung des Grads der Approximation der Aufwand und die Laufzeit des Verfahrens deutlich reduziert werden.
Bei dem System handelt es sich insbesondere um ein technisches System, z. B. um ein eingebettetes Echtzeit- oder Com- putersystem mit einem oder mehreren miteinander verbundenen Computern, elektronische Schaltungen und Steuerungen und dgl..
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 die Anzahl der genäherten Jobs erhöht. Folglich verringert sich der Grad der Approximation und die Laufzeit des Verfahrens kann verringert werden. Das Verfahren kann noch schneller und effizienter durchgeführt werden.
Nach einer weiteren Ausgestaltung der Erfindung wird minde- stens 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 oder eines momentanen Grads der Approximation verwendet und an den Anwender weitergegeben werden. Die Mächtigkeit der zweiten Menge und der damit verknüpfte Grad der Approximation können in besonders einfacher Weise durch Erhöhen oder Erniedrigen der Testgrenzen verändert werden. Durch eine Erhöhung der Testgrenze/n kann der Grad der Approximation gestei- gert werden. Vorteilhafterweise stellt die Testgrenze für ei- ne Task eine Anzahl von Jobs der Task dar. Die Testgrenze ist erreicht, wenn im Zeitintervall der Anzahl entsprechend viele Jobs liegen. Besonders vorteilhaft ist es, zumindest anfänglich für alle Tasks die gleiche Testgrenze zu wählen, z. B. die gleiche Anzahl von Jobs. Andererseits ist es auch möglich, dass der Anwender einen anfänglichen maximal möglichen Fehler vorgibt, mit welchem das Verfahren beginnen soll, und auf dessen Grundlage die Testgrenzen bestimmt werden. Wenn die Gesamtsystemkosten kleiner als der Grenzwert sind, kann die Testgrenze einer Task der ersten Menge derart verändert werden, dass die zweite Menge vergrößert wird. Es können die Laufzeit und der Aufwand des Verfahrens reduziert werden.
Vorzugsweise wird zur Verringerung der zweiten Menge zumin- dest 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 wel- chem die Gesamtsystemkosten kleiner als der Grenzwert waren. Dabei kann ein beliebiges Zeitintervall gewählt werden, in welchem die Gesamtsystemkosten kleiner als der Grenzwert waren. 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 verursa- chen. 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 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. Über- steigen 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 Zeitintervalle der Größe nach in aufsteigender Reihenfolge überprüft, so können die Gesamtsy- stemkosten 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 die- ser 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 Grenz- werte 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äher- ten, 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 diejenige Task vom System zuerst abgearbeitet, für welche 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:
ALGORITHM AllApprox
If U > 1 => not feasible
∀ τi ∈ τn : testlist.add(τ, pi + di)
WHILE ( testlist ≠ { } ) τi, lact = testlist . getNext ( )
Ract=Ract + Cact + (lact - Iold) *Uapprox WHILE (Ract > I act)
IF (Approxlist = {}) => not feasible x' = ApproxList -> getAndRemoveFirstTask;
Uapprox = Uapprox - ci / pi
Ract = Ract ~ app(Iact, τ' ) Testlist, add (τ1 , Nextlnt (Iaot, τ1) ) END WHILE Uapproχ = Uapprox + C1 / p±
ApproxList .add (t) ; END WHILE
=> not feasible
Eine weitere Ausgestaltung der Erfindung sieht folgenden Algorithmus vor:
ALGORITHM DynamicError If U > 1 =>not feasible Iπiax = minimum feasibility interval V Ti e τn : testlist .add (τ, pi + di) WHILE (testlist ≠ { } AND Iact < Imax) t±r lact = testlist . getNext ()
Ract=Ract + Cact + (lact ~ Iold) *Uapprox WHILE (Ract > I act)
IF (Approxlist = {}) => not feasible increase level;
V Xj- G Xrev - Uapprox = Uapprox — Ci / Pi
Ract = Ract - app(Iact, Xj) END WHILE
IF (lact < Tmax(x) ) testlist . add (x, Iact + p±) ELSE
Uapprox = Uapprox + Ci / Pi
ApproxList . add (t) ; lold = lact END WHILE
=> feasible
Hierin bedeutet τrev die Menge der Tasks, für welche bei einem weiteren Durchlauf des Algorithmus an Stelle der jeweiligen Näherungswerte die entsprechenden Systemkosten berücksichtigt werden.
Nach weiterer Maßgabe der Erfindung ist ein Computer-Programm-Produkt, umfassend computerlesbare Programmcodemittel zur Durchführung des erfindungsgemäßen Verfahrens auf einem
Computersystem vorgesehen. Ferner ist ein digitales Speichermedium mit einem darauf gespeicherten computerlesbaren Programm zur Durchführung des erfindungsgemäßen Verfahrens vorgesehen. Des Weiteren ist ein Computersystem, umfassend ein digitales Speichermedium mit darauf gespeicherten, vom Computersystem ausführbaren Programmcodemitteln zur Durchführung des erfindungsgemäßen Verfahrens vorgesehen.
Vorteile des Computer-Programm-Produkts, des digitalen Spei- chermediums und des ComputerSystems ergeben sich aus den Vorteilen des oben beschriebenen Verfahrens.
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. Es ist ein vom System abzuarbeitendes Tasksystem τn mit n Tasks τ vorgesehen, wobei n eine natürliche Zahl ist. Als Systemkosten, welche durch das Abarbeiten einer Task τ € τn verursacht werden, wird eine vom System zum Abarbeiten der Task τ erforderliche Rechenzeit verwendet. Es werden Zeitintervalle I überprüft, welche kleiner als ein vorgegebenes maximales Zeitintervall Imax sind. Die Zeitintervalle I weisen einen gemeinsamen Anfangszeitpunkt auf. Ein, Endzeitpunkt eines Zeitintervalls I ist 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 nτ Zeitintervalle Iτi er , ... , er Iτ nτ e Imax, ausgewählt. Die Zeitintervalle Iτχ, ... bzw. Iτ n umfassen 1, 2, ... bzw. nτ Jobs der Task τ. Für jede Task τ wird ferner eine von den Parametern der Task τ abhängige Testgrenze Tmax(τ) bestimmt, für welche gilt: Tmax(τ) er Imax. Bei der Ermittlung einer Gesamtre- chenzeit wird für die Zeitintervalle I er Tmax(τ) die tatsächliche Rechenzeit der Jobs der Task τ verwendet. Für Zeitintervalle I, mit Tmax(τ) er I er Imax wird ein Näherungswert für die Rechenzeit verwendet, welcher größer als die Rechenzeit ist. In analoger Weise werden entsprechende Zeitintervalle für jede Task des Tasksystems ausgewählt. Die Zahlen nτ und der Fehler des Näherungsverfahrens sind voneinander abhängig. Die ausgewählten Zeitintervalle werden in aufsteigender Reihenfolge überprüft. Es wird jeweils die Gesamtrechenzeit ermittelt, welche vom System zum Abarbeiten der darin anfallen- den Jobs benötigt wird und mit einem Grenzwert für die Rechenzeit im jeweiligen Zeitintervall verglichen. Das System ist echtzeitfähig, wenn die Gesamtrechenzeit kleiner ist als der Grenzwert. Bei der Analyse eines Zeitintervalls Iτ' nχA ei~ ner Task τ' , für welche Tmax(τ)cz Iτ'n gilt, wird die genäherte Rechenzeit des Jobs der Task τ anteilmäßig berücksichtigt. Die Analyse wird so lange fortgesetzt, bis das maximale Zeitintervall Imax überschritten bzw. erreicht wird, d. h. bis alle für die Tasks des Tasksystems τn die, wie oben beschriebenen, ausgewählten Zeitintervalle überprüft worden sind. Durch den Näherungswert für die Rechenzeit entsteht bei der Ermittlung der Gesamtrechenzeit ein Fehler. Es kann also sein, dass die ermittelte Gesamtrechenzeit größer ist als die vom System tatsächlich benötigte Gesamtrechenzeit, welche z.. B. mit einem exakten Verfahren ermittelt werden kann.
Damit die Laufzeit des Verfahrens und die Anzahl der zu über- prüfenden Zeitintervalle möglichst gering sind, wird mit einer kleinen maximalen Anzahl nτ von Zeitintervallen pro Task τ, d. h. mit einer niedrigen Testgrenze Tmax(τ) begonnen, beispielsweise mit nτ = 1. Übersteigt die einen Fehler enthaltende Gesamtrechenzeit einen Grenzwert für die im überprüften Zeitintervall verfügbare Rechenzeit, so wird die Testgrenze
TmaxU) verschoben bzw. erhöht und entsprechend die maximale Anzahl nt der Zeitintervalle für zumindest eine Task τ erhöht. Anschließend wird die Echtzeitfähigkeit für das Zeitintervall erneut geprüft, indem die Gesamtsystemkosten neu be- rechnet und mit dem Grenzwert verglichen werden. Sind die Gesamtsystemkosten kleiner als der Grenzwert, kann das nächst größere Zeitintervall geprüft werden. Übersteigen die Gesamtsystemkosten den Grenzwert weiterhin, können wiederum eine oder mehrere Testgrenzen Tmax(τ) verschoben werden. Die Test- grenzen Tmax(τ) der Tasks τ können sukzessiv so lange verschoben werden, bis die Bedingung Tmax(τ) = Imax erfüllt ist. Ist diese Bedingung erfüllt und übersteigen die Gesamtsystemkosten dennoch den Grenzwert, so ist das System nicht echtzeit- fähig.
Die Testgrenze Tmax(τ) kann z. B. durch Verdoppeln der Anzahl nτ erhöht werden. Für das Verfahren sind gerade solche Verschiebungen von Bedeutung, bei welchen zumindest eine Test- grenze Tmax(τ) über den Endzeitpunkt des überprüften Zeitintervalls hinweg verschoben wird. Dies wirkt sich auf die Anzahl der Jobs aus, für welche im Zeitintervall ein Näherungswert für die Rechenzeit verwendet wird. Bei einer Verringe- rung der Anzahl der genäherten Jobs wird die Gesamtrechenzeit um den Fehleranteil der nicht mehr genäherten Jobs verringert. Dadurch kann durch eine Erhöhung des Grads der Approximation die ermittelte Gesamtrechenzeit verringert werden. Es kann sein, dass durch diese Verringerung die ermittelte Ge- samtrechenzeit 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 I 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 mit einem kleineren Zeitintervall I fortgesetzt 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:
Figure imgf000018_0001
Dabei sind τ± , i = 1, 2, ... Tasks aus dem Tasksystem τn, c± die Systemkosten, wie z. B. eine zum Abarbeiten der Task τi vom System benötigte Rechenzeit, und pi eine Periode oder ein zeitlicher Mindestabstand der Task Xj..
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 Imax festgelegt. Ferner werden zur Ausführung des Verfahrens erforderliche Variablen initialisiert, wie z. B. die Gesamtsystemkosten als eine kumulierte aktuelle Re- chenzeit Ract für das aktuelle Zeitintervall Iact- Ein dem aktuellen Zeitintervall Iact vorangehendes Zeitintervall wird mit Ioid bezeichnet. Das jeweils erste Zeitintervall Iτii der Tasks Ti des Tasksystems Tn wird in eine Testliste TestList eingefügt. Das erste Zeitintervall Iτii ergibt sich aus einer Zeitschranke dτ. des ersten Jobs einer jeden Task Xj.. 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 oder erreicht ist, d. h. wenn z. B. gilt: Iact ≥ Imax-
Als erste Anweisung wird das aktuelle Zeitintervall Iact bestimmt. Das aktuelle Zeitintervall Iact 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 Ti in der Testliste TestList enthalten sein, wird nur ein Eintrag gelöscht. τact bezeichnet die zu dem aktuellen Zeitintervall Iact gehörende Task. Als nächste Anweisung wird die Rechenzeit Ract mit folgender Formel berechnet:
^acfc = R-old + Cact + Uapproχ X (Iaat - I0Id)
Dabei bezeichnet Uapproχ eine spezifische Auslastung der genäherten Tasks. Uapprox kann mit folgender Formel berechnet werden:
Ci aapppprrooxx Δ*u τx eApproxList * i
UapProχ kann auch in einer Variable gespeichert und im Laufe der Echtzeitanalyse, sofern erforderlich, aktualisiert werden.
In einer weiteren Anweisung wird die kumulierte aktuelle Rechenzeit Ract mit einem Grenzwert GWact für das aktuelle Zeitintervall Iact verglichen. Der Grenzwert GWact kann beispielsweise mit der Intervalllänge des aktuellen Zeitintervalls Iact gleichgesetzt werden.
Ist in einem ersten Fall die Rechenzeit Ract kleiner oder gleich dem Grenzwert GWact, so ist der Echtzeitnachweis für das Zeitintervall Iact erbracht. Durch eine nächste Anweisung wird geprüft, ob die Testgrenze Tmax(τact) der aktuellen Task τact erreicht oder überschritten ist. Die Testgrenze Tmax(τact) hängt von der aktuell zulässigen Anzahl Anz der Zeitinterval- Ie ab. Für periodische Tasks kann die Überprüfung durch folgende Formel erfolgen:
/aσt >(NAnz-ϊ/)x paσt + daσt
Dabei bezeichnet dact die aktuelle Zeitschranke und pact die Periode der Task τact- Ist die Testgrenze Tmax(τact) erreicht, so wird in einer nächsten Anweisung die Task τact der Liste ApproxList der genäherten Tasks hinzugefügt. Falls erforder- lieh wird Uapprox aktualisiert.
Ist die Testgrenze Tmax(τact) noch nicht erreicht, so wird ein nächst größeres Zeitintervall Inext für die Task τact in die Testliste TestList eingefügt. Für periodische Tasks kann das Zeitintervall Inext folgendermaßen bestimmt werden:
Figure imgf000021_0001
Als letzte Anweisung des ersten Falls wird der Wert des letz- ten akzeptierten Zeitintervalls Ioid auf den Wert des aktuellen Zeitintervall Iact gesetzt.
Ist in einem zweiten Fall die Rechenzeit Ract dagegen größer als der Grenzwert GWact und ist die Liste ApproxList leer, so ist das System nicht echtzeitfähig. Ist die Liste ApproxList nicht leer, so wird versucht, die ermittelte Rechenzeit Ract schrittweise zu reduzieren. Das kann wie folgt durchgeführt werden:
Zunächst wird die Anzahl Anz erhöht. Die Anzahl Anz kann beispielsweise verdoppelt werden. Dann wird überprüft, ob infolge der Erhöhung ein oder mehrere in der Liste ApproxList enthaltene Tasks nicht mehr genähert werden. Die nicht mehr ge- näherten Tasks werden bestimmt. Es werden diejenigen Tasks bestimmt, welchen infolge der erhöhten Anzahl Anz eine Testgrenze Tmax(τ) zugeordnet wird, welche größer als das aktuelle Zeitintervall Iact ist. Die so bestimmten Tasks werden aus der Liste ApproxList entfernt und ihr nächstes Zeitintervall, das größer als Iact ist wird in die Liste TestList eingefügt. Dann wird die Rechenzeit Ract um den Fehleranteil der nicht mehr genäherten und wie oben bestimmten Tasks reduziert. Für periodische Tasks kann der Fehler in einem Zeitintervall I fol- gendermaßen berechnet werden:
Figure imgf000022_0001
Dabei bezeichnen ά±r pi, und c± die Zeitschranke, Periode und Systemkosten, z. B. die Rechenzeit, einer Task Ti des Tasksy- stems τn. Die derart berechneten Fehler werden von der Rechenzeit Ract subtrahiert. Ist die reduzierte Rechenzeit R'act nach wie vor größer der Grenzwert GWact, 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 GWact ist, oder bis die Liste ApproxList leer ist. Sinkt infolge einer Erhöhung der Anzahl Anz die Rechenzeit R'act unter den Grenzwert GWact , 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 GWact, so ist das System für das Tasksystem τn nicht echtzeitfähig.
Bei einem dritten Ausführungsbeispiel kann der Grad der Approximation wieder verringert werden. Der Grad der Approximation kann dynamisch an die Erfordernisse des Tasksystems τn angepasst werden, wodurch die Laufzeit des Verfahrens weiter minimiert werden kann. 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 Ract in einem überprüften Zeitintervall kleiner als der Grenzwert GWact ist, so wird die Anzahl Anz derart verringert, dass die Anzahl der Tasks, für welche ein Näherungswert für die
Systemkosten verwendet wird, steigt. D. h. es wird die Testgrenze Tmax (O für zumindest eine Task τ derart verschoben, dass die Task τ im Zeitintervall Iact oder Inew genähert wird.
Bei einem vierten Ausführungsbeispiel werden die Tasks τ so früh wie möglich, z. B. jeweils nach dem ersten Zeitintervall Iτi , genähert. Diese Näherung kann, wie oben beschrieben, wieder aufgehoben werden. Wird eine Näherung aufgehoben, so kann versucht werden, die Näherung baldmöglichst, z. B. im nächsten Zeitintervall, wieder einzuführen. Bei dem Verfahren ist es möglich, nur dann Zeitintervalle in die Testliste TestList einzufügen, wenn dies auf Grund 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 τ erge- benden ersten Zeitintervalle Iτχ werden in die Testliste
TestList eingefügt. Die Zeitintervalle Iτi in der Testliste TestList werden dann der Größe nach in aufsteigender Reihenfolge abgearbeitet, d. h. es wird die Echtzeitfähigkeit des Systems für diese Intervalle überprüft . Alle weiteren Zeitintervalle I der Tasks werden zunächst genähert, d.h. sind nicht in der Testliste TestList enthalten. Wenn ein Echtzeitnachweis für ein Zeitintervall l\ fehlschlägt, wird die Nä- herung, wie oben beschrieben, schrittweise aufgehoben. 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 , i > 2, in die Testliste TestList eingefügt wird. Vorzugsweise entspricht das Zeitintervall Iτ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 Zeitintervall 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 Ract größer ist als der Grenzwert GWact-
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, z. B. dynamisch, angepasst werden kann, ist es möglich, die Echtzeitfähigkeit von Systemen besonders genau zu analysieren.
Das erfindungsgemäße Verfahren kann von einem, insbesondere technischen, System, wie z. B. einem ComputerSystem, parallel zur Abarbeitung des Tasksystems ausgeführt werden. Es kann im Voraus überprüft werden, ob die Tasks des Tasksystems in Echtzeit abarbeitbar sind. Wird z. B. festgestellt, dass eine Echtzeitbedingung für einen bestimmten zukünftigen Zeitpunkt nicht erfüllt werden kann, so ist es möglich einzelne Tasks zu deren schnelleren Abarbeitung auf andere Systemkomponenten oder weitere Systeme auszulagern. Durch eine derartige Auslagerung kann im günstigen Fall erreicht werden, dass die Echtzeitbedingung im zukünftigen Zeitpunkt erfüllt werden kann. Es ist auch möglich, dass eine Abarbeitung einzelner Tasks zurückgestellt wird. Beispielsweise kann die Abarbeitung solcher Tasks zurückgestellt werden, welche für einen sicheren Betrieb des Systems oder einen Notbetrieb des Systems nicht zwingend erforderlich sind. Es kann die Funktionsfähigkeit des Systems verbessert werden.
Das erfindungsgemäße Verfahren kann auch bei einem System mit mehreren zusammenwirkenden Komponenten verwendet werden. Mit dem Verfahren erhaltene Informationen über die Echtzeitfähig- keit der Komponenten können verwendet werden, um eine Abarbeitung von Tasks auf den einzelnen Komponenten in geeigneter Weise zu planen oder festzulegen. Es kann das Zusammenwirken der Komponenten optimiert und verbessert werden.
Ferner kann das erfindungsgemäße Verfahren zur Entwicklung von technischen Systemen, wie z. B. eingebetteten Echtzeitoder Computersystemen, elektronischen Schaltungen oder Steuerungen und dgl . , verwendet werden.
Bezugs zeichenliste :
Tasksystem τ Task τ1 weitere Task
Anz Anzahl
Ci Kosten dτ,di Zeitschranke
GWact Grenzwert
I Zeitintervall i-tes Zeitintervall einer Task τ maximales Zeitintervall einer Task τ
Imax maximales Zeitintervall lact aktuelles Zeitintervall lold vorangehendes Zeitintervall nτ Anzahl von Zeitschranken
Pi Periode
R Rechenzeit
R-act aktuelle Rechenzeit
Tmax(τ) Testgrenze

Claims

fU I 'LTZ1J1J U / U U I 3 DPatentansprüche
1. Verfahren zur Echtzeitanalyse eines Systems, wobei vom System Tasks (τ) abzuarbeiten sind und wobei ein durch das Ab- arbeiten einer Task (τ) definierter Job Systemkosten verursacht, mit folgenden Schritten:
a) Festlegen eines Zeitintervalls (Iact) r in welchem Tasks (τ) vom System abzuarbeiten sind,
b) Ermitteln eines Grenzwerts (GWact) für Systemkosten, welche im Zeitintervall (I, Iτi, ... IV1) zum Abarbeiten der Tasks (τ) verfügbar sind,
c) Ermitteln von Gesamtsystemkosten (Ract) r für die durch die im Zeitintervall (I, l\, ... Iτ nτ) anfallenden Jobs verursachten Systemkosten, wobei zur Ermittlung der Gesamtsystemkosten (Ract) für
i) eine erste Menge (TestList) bildende Jobs die Systemkosten und
ii) eine zweite Menge (ApproxList) bildende Jobs jeweils ein Näherungswert für die Systemkosten
verwendet werden/wird, wobei der Näherungswert größer als die entsprechenden Systemkosten ist,
b) Vergleich der ermittelten Gesamtsystemkosten (Ract) mit dem Grenzwert (GWact) , wobei
i) das Zeitintervall (Iact) dann als in Echtzeit abarbeitbar gilt, wenn die Gesamtsystemkosten (Ract) den Grenzwert (GWact) nicht übersteigen, wobei, ii) wenn die Gesamtsystemkosten (Ract) den Grenzwert
(GWact) übersteigen, die zweite Menge (ApproxList) , falls diese nicht leer ist, derart verringert wird, dass für eine weitere Ermittlung der Gesamtsystemkosten (Ract) für zumindest einen Job einer Task (τ) der zweiten Menge (ApproxList) an Stelle des Näherungswerts die Systemkosten berücksichtigt werden und zumindest die Schritte lit. c) und d) wieder- holt ausgeführt werden, und wobei
iii) die Echtzeitfähigkeit des Systems dann als nicht gegeben angesehen wird, wenn die zweite Menge (ApproxList) leer ist und die Gesamtsystemkosten (Ract) den Grenzwert (GWact) übersteigen.
2. Verfahren nach Anspruch 1, wobei, wenn die Gesamtsystemkosten (Ract) kleiner als der Grenzwert (GWact) sind, die zweite Menge (ApproxList) vergrößert wird.
3. Verfahren nach einem der vorhergehenden Ansprüche, wobei mindestens einer Task (τ) eine veränderbare Testgrenze
(Tmax(τ)) zugeordnet wird, wobei für Tasks (τ) , deren Testgrenze (Tmax(τ)) im Zeitintervall (Iact) überschritten wird, der Näherungswert für die Jobs der Task (τ) verwendet wird, und wobei, wenn die Gesamtsystemkosten (Ract) größer als der Grenzwert (GWact) sind, zumindest eine Testgrenze (Tmax(τ)) derart verändert wird, dass die zweite Menge (ApproxList) verringert wird.
4. Verfahren nach Anspruch 3, wobei, wenn die Gesamtsystemkosten (Ract) kleiner als der Grenzwert (GWact) sind, die Testgrenze (Iτ n ) einer Task (τ) der zweiten Menge (ApproxList) derart verändert wird, dass die zweite Menge (ApproxList) vergrößert wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, wobei zur Verringerung der zweiten Menge (ApproxList) zumindest ein Zahlenwert vergrößert, vorzugsweise verdoppelt, wird und/oder zur Vergrößerung der zweiten Menge (ApproxList) zumindest ein Zahlenwert verringert wird.
6. Verfahren nach einem der vorhergehenden Ansprüche, wobei, wenn die Gesamtsystemkosten (Ract) größer als der Grenzwert (GW3Ct) sind, das Verfahren mit einem bereits überprüften Zeitintervall (I0Id) fortgeführt wird, in welchem die Gesamtsystemkosten (Ract) kleiner als der Grenzwert (GWact) waren.
7. Verfahren nach einem der vorhergehenden Ansprüche, wobei, wenn die Gesamtsystemkosten (Ract) im Zeitintervall (Iact) größer als der Grenzwert (GWact) sind, das Verfahren im Zeitintervall (Iact) fortgeführt wird.
8. Verfahren nach einem der vorhergehenden Ansprüche, wobei zur Verringerung der zweiten Menge (ApproxList) eine der folgenden Eigenschaften der Tasks berücksichtigt wird: Höhe der tatsächlichen Systemkosten, Fehleranteil der genäherten Sy- stemkosten an einem Gesamtfehler des Verfahrens.
9. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Echtzeitfähigkeit nacheinander für Zeitintervalle (I, l\, ... Iτ n ) mit ansteigender Größe überprüft wird.
10. Verfahren nach einem der vorhergehenden Ansprüche, wobei bei der Bestimmung der Gesamtsystemkosten (Ract) die Tasks (τ) gruppiert werden.
11. Verfahren nach einem der vorhergehenden Ansprüche, wobei zumindest eine Task (τ) wiederholend vom System abzuarbeiten sind.
12. Verfahren nach einem der vorhergehenden Ansprüche, wobei zumindest eine Task (τ) mit einem zeitlichen Mindestabstand oder periodisch mit einer Periode (pi) abzuarbeiten ist.
13. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Systemkosten auf der Grundlage einer für das Abarbeiten der Tasks (τ) erforderlichen Bearbeitungszeit berechnet werden.
14. 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.
15. 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ührungskompo- nente, vorzugsweise einer CPU, des Systems berechnet werden.
16. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Grenzwert (GWact) auf der Grundlage einer im Zeitintervall (Iact) verfügbaren Kapazität des Systems ermittelt wird.
17. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Gesamtsystemkosten (Ract) für diskrete, einen Anfangs- und einen Endzeitpunkt aufweisende Zeitintervalle (I, Iτi ) ermit- telt werden, wobei der Endzeitpunkt ein Ende einer Zeitschranke (dact, di) ist, bis zu welcher ein Job einer Task (τ) spätestens abzuarbeiten ist.
18. 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.
19. Verfahren nach Anspruch 18, wobei die spezifische Auslastung als Quotient aus Bearbeitungszeit und Periode (pi) der Task (τ) berechnet wird.
20. 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 (Iact)-
21. Verfahren nach einem der vorhergehenden Ansprüche, wobei diejenige Task (τ) vom System zuerst abgearbeitet wird, für welche das Ende der Zeitschranke (dact, dj.) zeitlich am nächsten liegt.
22. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Tasks (τ) in einer durch eine Priorität vorgegebenen Rei- henfolge vom System abgearbeitet werden.
23. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Tasks (τ) mit einem Ereignisstrommodell beschrieben werden.
24. Verfahren nach einem der vorhergehenden Ansprüche, wobei folgender Algorithmus verwendet wird:
ALGORITHM AllApprox If U > 1 =>not feasible
V Ti eτn : testlist.add(τ, p± + dj.) WHILE (testlist ≠ { }) ti, Iact = testlist . getNext () Ract=Ract + Cact + ( Iact - lold) * Uapprox
WHILE (Ract > I act)
IF (Approxlist = {}) => not feasible τ' = ApproxList -> getAndRemoveFirstTask; Uapprox = Uapprox - ci / pi
Ract = Ract - app(Iact, τ')
Testlist. add(τ', Nextlnt (Iact, τ' ) ) END WHILE Uapprox = Uapprox + ci / pi ApproxList . add (t) ; END WHILE => not feasible
25. Verfahren nach einem der Ansprüche 1 bis 23, wobei fol- gender Algorithmus verwendet wird:
ALGORITHM DynamicError If U > 1 => not feasible Imax = minimum feasibility interval Vx1 eτn : testlist . add (τ, P1 + dx)
WHILE (testlist ≠ {} ÄND Iact < Imax) XIΛ Iact = testlist . getNext ()
Ract=Ract T" Cact + ( Iact - lold) Uapprox WHILE ( Ract > I act ) IF (Approxlist = {}) => not feasible increase level;
V T1 G Xrev • Uapproχ = Uapprox - ci / pi
Ract = Ract ~ ^PP ( IactA τj ) END WHILE IF ( Iact < Tmax (τ) ) testlist . add (τ, Iact + P1) ELSE Uapprox ~ UapprOχ + Ci / PJ_
ApproxList . add (t) / lold = Iact END WHILE => feasible
26. Computer-Programm-Produkt,. umfassend computerlesbare Programmcodemittel zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 25 auf einem Computersystem.
27. Digitales Speichermedium mit einem darauf gespeicherten computerlesbaren Programm zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 25 auf einem Computersystem.
28. Computersystem, umfassend ein digitales Speichermedium mit darauf gespeicherten, vom Computersystem ausführbaren Programmcodemitteln zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 25.
PCT/EP2006/001955 2005-03-04 2006-03-03 Verfahren zur echtzeitanalyse eines systems WO2006092318A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP06723199A EP1854003A1 (de) 2005-03-04 2006-03-03 Verfahren zur echtzeitanalyse eines systems
JP2007557434A JP2008532150A (ja) 2005-03-04 2006-03-03 システムのリアルタイム分析のための方法
US11/884,916 US8185900B2 (en) 2005-03-04 2006-03-03 Method for the real-time capability analysis of a system by selectively using approximated or actual system expenses for jobs

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005010580.7 2005-03-04
DE102005010580A DE102005010580A1 (de) 2005-03-04 2005-03-04 Verfahren zur Echtzeitanalyse eines Systems

Publications (1)

Publication Number Publication Date
WO2006092318A1 true WO2006092318A1 (de) 2006-09-08

Family

ID=36480896

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/001955 WO2006092318A1 (de) 2005-03-04 2006-03-03 Verfahren zur echtzeitanalyse eines systems

Country Status (5)

Country Link
US (1) US8185900B2 (de)
EP (1) EP1854003A1 (de)
JP (1) JP2008532150A (de)
DE (1) DE102005010580A1 (de)
WO (1) WO2006092318A1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8533727B2 (en) * 2009-02-16 2013-09-10 Inchron Gmbh Method for analysing the real-time capability of a system
US9043644B2 (en) * 2012-12-04 2015-05-26 International Business Machines Corporation Using separate processes to handle short-lived and long-lived jobs to reduce failure of processes
US20150081400A1 (en) * 2013-09-19 2015-03-19 Infosys Limited Watching ARM
KR102264205B1 (ko) * 2019-09-20 2021-06-10 인천대학교 산학협력단 실시간 시스템에서의 작업 할당 스케줄링이 가능한지 여부를 판정할 수 있는 실시간성 분석 장치 및 그 동작 방법
KR102252079B1 (ko) * 2019-09-20 2021-05-13 인천대학교 산학협력단 실시간 시스템을 위한 실시간성 분석 장치 및 그 동작 방법

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2723653B1 (fr) * 1994-08-11 1996-09-13 Cegelec Procede pour ordonnancer des taches successives qui ne subissent que des contraintes du type delais
US5964829A (en) * 1996-03-27 1999-10-12 Lucent Technologies Inc. Method and apparatus for providing enhanced pay per view in a video server employing a coarse-grained striping scheme
GB9710522D0 (en) * 1997-05-23 1997-07-16 Rolls Royce Plc Control system
US7165252B1 (en) * 1999-06-21 2007-01-16 Jia Xu Method of scheduling executions of processes with various types of timing properties and constraints
JP2002342097A (ja) * 2001-05-17 2002-11-29 Matsushita Electric Ind Co Ltd タスク割当可能時間決定装置及びタスク割当可能時間決定方法

Non-Patent Citations (5)

* 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 June 2004 (2004-06-30), pages 187 - 195, XP002383592, ISSN: 1068-3070 *
ALBERS K ET AL: "Efficient Feasibility Analysis for Real-Time Systems with EDF Scheduling", DESIGN, AUTOMATION AND TEST IN EUROPE, 2005. PROCEEDINGS MUNICH, GERMANY 07-11 MARCH 2005, PISCATAWAY, NJ, USA,IEEE, 7 March 2005 (2005-03-07), pages 492 - 497, XP010780009, ISBN: 0-7695-2288-2 *
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, vol. SYMP. 11, 5 December 1990 (1990-12-05), pages 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 December 2002 (2002-12-03), pages 1 - 10, XP002383591 *
DEVI U C: "An improved schedulability test for uniprocessor periodic task systems", REAL-TIME SYSTEMS, 2003. PROCEEDINGS. 15TH EUROMICRO CONFERENCE ON 2-4 JULY 2003, PISCATAWAY, NJ, USA,IEEE, 2 July 2003 (2003-07-02), pages 23 - 30, XP010644814, ISBN: 0-7695-1936-9 *

Also Published As

Publication number Publication date
US8185900B2 (en) 2012-05-22
EP1854003A1 (de) 2007-11-14
US20080276247A1 (en) 2008-11-06
JP2008532150A (ja) 2008-08-14
DE102005010580A1 (de) 2006-09-07

Similar Documents

Publication Publication Date Title
DE60226176T2 (de) Verfahren und programme zur einstellung von prioritätsstufen in einem datenverarbeitungssystem mit multiprogrammierung und priorisierte warteschlangenbildung
EP1831786B1 (de) Verfahren zur verteilung von rechenzeit in einem rechnersystem
EP0771444B1 (de) Verfahren zur steuerung von technischen vorgängen oder prozessen
EP1756714A2 (de) Verfahren zur prüfung der echtzeitfähigkeit eines systems
DE102010029209B4 (de) Verfahren zur dynamischen Verteilung von einem oder mehreren Diensten in einem Netz aus einer Vielzahl von Rechnern
WO2006092318A1 (de) Verfahren zur echtzeitanalyse eines systems
DE102007051803A1 (de) Verfahren und Vorrichtung zur Datenverarbeitung
EP1810139A1 (de) Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
EP1149338B1 (de) Lastverteilungsverfahren eines multiprozessorsystems und multiprozessorsystem
DE102016221526A1 (de) Vorrichtung und Verfahren zum Bearbeiten einer Mehrzahl Aufgaben
EP1514180A2 (de) Reaktionszeit-beschränkung eines software-prozesses
DE102004059972A1 (de) Thread-Scheduling-Verfahren, und Einrichtung zur Verwendung bei einem Thread-Scheduling-Verfahren
DE10110444A1 (de) Verfahren und Vorrichtung zum Ermitteln der Auslastung eines Rechengeräts
WO2018091329A1 (de) Vorrichtung und verfahren zum bearbeiten von aufträgen
WO2006045733A2 (de) Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
WO2021249616A1 (de) Verfahren zum konfigurieren von komponenten in einem system mit hilfe von multi-agent reinforcement learning, computerlesbares speichermedium und system
DE102022200160A1 (de) Verfahren zum Optimieren eines Prozesses
EP1502189B1 (de) Verfahren zur ermittlung der prioritätsabhangigen rechenzeitverteilung in einem priorit tsgesteuerten mehrprozess-rechenysystem
WO2009034063A2 (de) Edf-implementierung für realzeitsysteme mit statischen prioritäten
DE10018660B4 (de) Verfahren und Vorrichtung zum Steuern eines oder mehrerer elektromechanischer Stellantriebe
EP3690563A1 (de) Verteilung einer steueraufgabe auf mehrere prozessorkerne
WO2007048675A1 (de) Verfahren zum implementieren von software-timern und datenverarbeitungssystem
DE102021101309A1 (de) Elektronische steuervorrichtung
EP1889159A2 (de) Verfahren zur speicherverwaltung von digitalen recheneinrichtungen
EP2891030B1 (de) Bestimmung eines ersatzwerts für die primärseitige leistungsaufnahme eines netzteils

Legal Events

Date Code Title Description
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: 2006723199

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2007557434

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

WWW Wipo information: withdrawn in national office

Country of ref document: RU

WWP Wipo information: published in national office

Ref document number: 2006723199

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11884916

Country of ref document: US