Method for executing time-triggered tasks at flexible execution intervals in computer system

Abstract

A method of executing jobs of a set of tasks in a computer system according to global time-triggered scheduling, where the computer system comprises one or more cores on one or more central processing units of the computer system,-where the one or more cores are located on the one or more central processing units of the computer system. The global time-triggered scheduling includes a time-triggered scheduling "core scheduling" for each of the cores, where a task of the set of tasks to be executed on a particular core is executed on the core according to the core scheduling of the core. The core schedule specifies a flexibility interval for each job, where the duration of the flexibility interval for a job is equal to or longer than the execution interval for the job, where at least the flexibility interval for one job is longer than the execution interval for the job, where the flexibility interval for a job is not later than the point of issue of the execution interval for the job, and where the flexibility interval for a job is not later than the point of issue of the execution interval for the job. And wherein the flexibility interval of the job is not ended earlier than the completion point of the execution interval of the job.

Description

TECHNICAL FIELD

[0001] The present invention relates to a method of executing a job of a task set in a computer system according to a globally time-triggered schedule,

[0002] - wherein the computer system comprises one or more cores on one or more central processing units of the computer system,

[0003] - wherein the globally time-triggered schedule comprises one time-triggered schedule "core schedule" for each of the cores, wherein a task of the task set to be executed on a particular core is executed on said core according to the core schedule of said core,

[0004] - wherein the globally time-triggered schedule specifies a cycle having a cycle length for the task set,

[0005] wherein the core schedule of a core specifies for each task of the task set to be executed on said core:

[0006] • an execution interval of each task instance "job" of the task during which may be performed the job, wherein each execution interval comprises a release point at which the execution interval starts and a completion point at which the execution interval ends, wherein the duration of the execution interval is the duration of the time span between the release point and the completion point of the execution interval, wherein the execution interval of the job defines a time interval during which the job has a guarantee to be executed on the core, and

[0007] • a period according to which the jobs of said task are executed on the core,

[0008] o wherein the execution interval of each job of the task is iterated cyclically according to the cycle, and

[0009] wherein the execution intervals of any two jobs of the same task and of different tasks do not overlap, and

[0010] wherein the cycle is a common multiple of all the periods of all the tasks of the task set. BACKGROUND

[0011] The execution of periodic jobs of software tasks following the time-triggered paradigm has been studied in the literature and has been adopted in the industry for many years. Among its benefits, it is highlighted the deterministic and timely execution of jobs of software tasks in a cyclic manner, typically driven by an offline computation of a schedule (tt schedule) that allows a correctness-by-design approach. Moreover, tt schedules can be computed based on optimization goals that are difficult to achieve by other paradigms, like minimizing job-level jitter or satisfying complex job inter-dependencies.

[0012] However, it is also known that the time-triggered paradigm provides little or no flexibility in adapting to changes in the runtime behavior of software jobs. This lack of adaptability can be an asset for critical systems that require precise and deterministic behavior over time, but it can also reduce the ability to maximize the use of resources in systems with less stringent determinism requirements.

[0013] Before computing a tt schedule, software tasks must be characterized, in particular with respect to their timeliness requirements, such as required execution time and execution rate (i.e., period). A common goal of the time-triggered paradigm is to compute a tt schedule based on worst-case timeliness bounds, such as worst-case execution time and minimum execution rate. Once a tt schedule is built, it is implemented cyclically at runtime by a dispatching mechanism. Considering the worst case guarantees that any change in the behavior of the jobs of the tasks during runtime will not exceed the system capacity, and thus still guarantees the correctness of the execution.

[0014] However, in modern computer systems, in particular automotive computer systems, the goal is often to maximize the utilization of hardware components, such as CPUs and memories, because any unused resource would preferably be scaled down at design time to reduce production costs and overall power consumption.

[0015] These two goals often conflict with each other and cannot be simply solved. In fact, adding flexibility to the time-triggered paradigm to enable adaptation to runtime changes in the execution timeliness of periodic jobs of tasks, while preserving determinism and correctness guarantees, is a challenge.

[0016] time triggered scheduling

[0017] The existing time-triggered scheduling method plans execution of software tasks in a defined CPU core by computing one or more execution intervals for each periodic job of the software tasks in one or more of the CPU cores according to a defined set of scheduling constraints.

[0018] An execution interval comprises a start time and a duration, during which the allocated CPU core will exclusively execute the allocated job of the software task.

[0019] The computed tt schedule is typically represented in the form of a schedule containing a list of computed intervals with allocation of jobs and CPU cores.

[0020] The computation of tt-schedule is based on defined scheduling constraints that determine the correct relationship between the execution intervals that comply with a valid tt-schedule. For example, an execution interval cannot be assigned to multiple jobs, as this would result in a single resource (CPU core) needing to execute instructions for two jobs at the same time, which is not feasible. As another example, different execution intervals on the same CPU core cannot overlap, as this would again result in multiple job plans executing on the same CPU core at the same time, thus invalidating the reservation of the guarantee of execution time for each individual job.

[0021] tt scheduling constraints

[0022] The computer system comprises one or more hosts, each of which comprises one or more CPU cores.

[0023] The software application is composed of one or more periodic software components or tasks. Each task is characterized by its period, earliest release time, and deadline - the task is executed cyclically on the core according to its period, carrying a sequence of task execution instances or jobs.

[0024] The tt-schedule is computed according to the general correctness constraints of TT scheduling found in the literature (e.g. [1]), and for completeness, are outlined here. The computation of tt-schedule involves computing the execution intervals of each periodic job of a software task within a defined scheduling cycle, where the computation complies with defined scheduling constraints, including but not limited to:

[0025] Start constraint: the start of the execution of any job of a software task sw i must be after a given earliest release time e i in each period p i .

[0026] Deadline constraint: the end of the execution of any job of a software task sw i must be before a given deadline d i in each period p i .

[0027] Non-overlapping constraint: two jobs of any task cannot be executed on the same core at the same time.

[0028] Dependency constraints: Additional dependency constraints are introduced when computing a tt schedule, further restricting the inter-relationships of the software tasks. For example, in some cases, functional correctness requires that the execution of a job of a first software task should occur after the execution of a job of a second software task in all cycles. In other cases, the order of execution of a set of software tasks' jobs can conform to a directed acyclic graph (DAG), whereby within a certain maximum time interval, the first and last software tasks of the DAG should complete their execution. Depending on the complexity of the inter-relationships, these additional dependency constraints can be classified as simple dependency constraints or complex dependency constraints.

[0029] A task can have simple dependencies or complex dependencies. Dependencies include two or more tasks, where a defined order of execution between the jobs of the tasks is specified, where,

[0030] • in simple dependencies, all of the included tasks have the same period, while

[0031] • in complex dependencies, at least two of the included tasks have different periods.

[0032] Furthermore, simple dependencies and complex dependencies involve a maximum latency constraint, where the maximum latency can be one of:

[0033] • a maximum response time, specifying that for all jobs of a first task in a defined set of tasks, there exists a trace of successor jobs following a defined order of the tasks in the set, such that the time taken by the trace is not longer than the response time,

[0034] • a maximum data age, specifying that for all jobs of a last task in a set of tasks according to a defined order, there exists a trace of jobs from some job of a first task in the set through all other intermediate tasks in the set, whereby the time taken by the trace is not longer than the data age.

[0035] Jitter constraint: For each job of a task, there is a non-negative delay between the start of the schedule and the earliest release time; the jitter constraint limits the maximum allowed difference between the delays of any pair of jobs of a task.

[0036] It is known that the construction of a tt schedule is a computationally intensive operation, which cannot be optimally solved in a reasonable time for large systems [2, 3]. Approximate heuristic algorithms have been used in the past and perform quite well on average [4].

[0037] Runtime execution variability

[0038] In some cases, job sequences of tasks can exhibit different runtime execution requirements along their looped execution, for example, due to differences in the data they need to process over time. This runtime variability can be addressed when computing tt schedules by assuming the worst-case runtime (worst-case computation time, or WCET) of each job of a software task, thus planning the amount and length of execution intervals sufficient to meet the worst-case behavior (e.g., the largest execution path) of said job. This can result in over-provisioning of the hardware resources allocated to the software tasks.

[0039] An advantage of the time-triggered scheduling paradigm is the deterministic and timely behavior of the executing jobs of software tasks during runtime, regardless of their looped variations in execution requirements, typically resulting in only minimal deviations between loops (e.g., due to unavoidable runtime inaccuracies introduced by the underlying hardware and software components’ uncertainties).

[0040] Runtime adaptivity

[0041] In general, the construction during the design time of tt schedules prevents runtime adaptation to the dynamic variability of the jobs of software tasks, and can be a drawback of the time-triggered scheduling paradigm. For example, when jobs of software tasks do not require a full execution interval within a loop, the remaining time (slack) cannot be easily redistributed to the jobs of the next software task in tt schedules.

[0042] Another related drawback of the time-triggered scheduling paradigm is the over-provisioning when computing the schedule by assuming the worst-case bounds of the timeliness (particularly the WCET) of software tasks, thus allocating larger execution intervals than the average required during execution, since jobs typically require less execution time than the WCET of their respective tasks during runtime.

[0043] Some existing approaches compute tt schedules by considering lower bounds, for example, the average execution time of certain tasks instead of the WCET [5], addressing the negative effects of over-provisioning due to WCET, whereby if the jobs of said tasks exceed their allocated execution interval in any of their loops, they can be interrupted and cannot complete their execution in the current loop, or in some cases, harm the jobs of other software tasks due to exceeding their planned execution interval.

[0044] Other existing approaches allow a computer system to switch its configuration between a set of alternative pre-computed tt schedules (e.g. called "modes") during runtime [6]. These approaches try to estimate at design time the variability that will be observed during runtime, and compute dedicated tt schedules that adapt to these conditions. This adaptation of the configuration is often called execution system mode change. In these approaches, the number of supported modes is limited by two factors: on the one hand, the number of possible system states (observable variability) due to different tt schedules increases exponentially with the size of the system (e.g. number of CPU cores, number of software tasks, number of constraints), and thus only a fraction of such possible system states can feasibly be stored in the computer system for future use (e.g. due to limited memory capacity); on the other hand, system mode changes cannot be applied instantaneously, and can require complex algorithms to guarantee system stability at runtime during the transition, thus increasing the latency and limiting the adaptability opportunities in deployed running systems.

[0045] However, other existing approaches include mechanisms to dynamically modify the computed tt schedules during runtime in response to the actual state of the system [9, 10]. These approaches are limited by the computational complexity of the constraints involved in the fast (re)computation of new tt schedules, usually within one or a few execution cycles. Therefore, the algorithms employed cannot handle a large number of constraints, or satisfy all constraints within a fast enough response time. Moreover, safety and certification concerns arise when dynamic changes can negatively impact the timely execution of jobs related to safety critical tasks, such as those in deployed automotive or industrial applications. Therefore, modifying the schedule at runtime has limited use in real-world use cases.

[0046] Operating system / runtime system dispatcher

[0047] An active module, typically a software component, is provided in the computer system that orchestrates the execution of software tasks by selecting tasks from the set of ready jobs at defined time instants and dispatching them for execution in one or more of the CPU cores in the computer system. This active module, the dispatcher (or dispatching device), is the runtime component that enforces the decisions made by the scheduler, and can be implemented in different forms, e.g. as a standalone runtime software component, as a module of the operating system, or as a high-level software stack in the computer system.

[0048] Typically, one such active module is provided. However, two or more such active modules can also be provided.

[0049] In computer systems implementing the time-triggered paradigm, a dispatcher selects jobs for execution based on a tt schedule. Once a job is dispatched, the dispatcher waits until the end of the job's execution interval and continues to select the next job following the order and timing defined in the tt schedule (i.e., the schedule).

[0050] In computer systems implementing other scheduling paradigms, a dispatcher can select jobs of software tasks for execution based on defined criteria. For example, in computer systems implementing the Earliest Deadline First (EDF) paradigm, the dispatcher selects from the set of ready jobs the job with the closest deadline for execution. Conversely, in computer systems implementing the Fixed Priority (FP) paradigm, software tasks are characterized by a defined and fixed priority, whereby the dispatcher selects from the set of ready jobs the job of the software task with the highest defined priority for execution. When a dispatched job or a new job is ready, the dispatcher can select and launch the new job based on the same criteria. SUMMARY

[0051] It is an object of the present invention to optimize the use of resources, in particular the use of CPU time and / or core time, in a computer system in which jobs of periodic tasks are executed according to a time-triggered schedule.

[0052] This is achieved with the method according to claim 1, wherein the core schedule specifies for each job a flexibility interval, wherein the duration of the flexibility interval of a job is equal to or longer than the execution interval of said job, wherein,

[0053] The flexibility interval of a job is at least longer than the execution interval of said job, wherein,

[0054] The flexibility interval of a job starts no later than the release point (start point, start / release time) of the execution interval of said job, and wherein,

[0055] The flexibility interval of a job ends no earlier than the completion point (end point, end / completion time) of the execution interval of said job, wherein,

[0056] The flexibility of a job defines a time interval during which said job can be executed, and wherein,

[0057] A run-time dispatching device is provided that selects and launches jobs for execution according to a global time-triggered schedule, taking into account all flexibility intervals as specified in the core schedule for each core.

[0058] The periodic execution of tasks within a scheduling cycle comprises one or more executions of a task instance or job of said task represented by one of said elements in the schedule, wherein each job corresponds to an execution of a task according to its periodicity, which is repeated according to the scheduling cycle. If the period of a task is equal to the scheduling cycle, there is a single job of said task within the scheduling cycle, whereas if the scheduling cycle is greater than the period, there are multiple jobs of said task according to the relation between the period and the scheduling cycle. Note that the length of the scheduling cycle is preferably a common multiple, e.g. the least common multiple, of the periods of all tasks. For example, if the period of a task is 10 and the cycle is 20, there will be two instances ("jobs") of the task within the cycle. Each of them will have its own interval within its respective period interval (from 0..10 to 10..20) and the flexibility interval can even have a different length and belong to a different one of the three subsets, which will be explained below.

[0059] According to the invention, a flexibility interval is provided for each job, whereby the flexibility interval of a job completely overlaps with the execution interval of that job and is equal to or greater than its execution interval. This enables the runtime dispatching device to organize the execution of jobs more flexibly in terms of time and thereby better utilize the available resources, in particular allowing a better utilization of the time of each core.

[0060] As mentioned, the invention requires that the flexibility interval of at least one job is longer than the execution interval of said job. For the best effect of the invention, it is advantageous that the flexibility interval of several jobs, in particular multiple jobs, preferably all jobs, is longer than the corresponding execution interval.

[0061] In general, a method of computing a tt schedule involves deciding for each execution interval of each job to be scheduled an effective placement on a timeline, subject to defined scheduling constraints which define bounds of schedulability of correct placement of said interval. Once a tt schedule is computed, said constraints are implicitly satisfied by the provided execution interval of the schedule which complies. The placement of the execution interval of each job is defined by the limits imposed by the defined scheduling constraints. However, during the computation, multiple decisions are possible within said limits, resulting in alternative but equally correct tt schedules.

[0062] For example, if the periodicity and the deadline are the only constraints to be fulfilled, a periodic job subject to the deadline constraint can be arbitrarily scheduled within the interval bounded by the beginning of the periodicity and the relative deadline. By performing the decision of the execution interval of a job, the scheduling process selects one of multiple possible correct execution intervals for said job.

[0063] In some cases, early decisions made during the computation of a tt schedule affect later decisions related to other jobs. For example, when jobs are subject to dependency constraints, any decision that affects the execution interval of a preceding job affects the decision of a successor job, because the dependency requires that the successor job can only be scheduled after the execution interval of the predecessor, thus tightening the lower bound to the execution interval of the successor.

[0064] Some methods of computing tt schedules apply a simple strategy of choosing the start of the execution interval based on the lower bound when deciding the placement of the execution interval of each job, i.e., scheduling the job as early as possible. Alternatively, other methods apply a strategy of choosing the end of the execution interval based on the upper bound when deciding the placement of the execution interval of each job, i.e., scheduling the job as late as possible. More complex methods choose an arbitrary value between the bounds based on additional defined criteria when deciding the placement of the execution interval of each job.

[0065] It can be provided that a method of computing tt schedules is extended to keep track of and update the schedulability bounds of each job by iteratively adjusting the upper and lower bounds of all jobs at each scheduling decision. It can also be provided that the extended method additionally computes a flexibility interval for each job based on the schedulability upper and lower bounds after computing the tt schedule, where the start of its flexibility interval corresponds to the schedulability lower bound and the end of its flexibility interval corresponds to the schedulability upper bound for each job.

[0066] It can also be provided that a method of deriving schedulability bounds based on an existing tt schedule and a set of scheduling constraints, where the method computes an upper and lower bound for each execution interval subject to the defined set of scheduling constraints. For example, an iterative method can start the flexibility interval of a first job from the tt schedule to the interval corresponding to its execution interval and iteratively increase the flexibility interval while checking that the defined set of constraints is still satisfied. Once at least one constraint is not satisfied, the flexibility interval of the first job is fixed to the flexibility interval of the previous iteration and the next job is selected as the first job until all jobs are provided with a flexibility interval.

[0067] It can be provided that, among the jobs of the tasks in the set of tasks to be executed on the core, at least one first subset of jobs is provided, where, for the jobs in the at least one first subset, the core schedule specifies flexibility intervals that do not overlap each other, where at least one of the flexibility intervals of a job is longer than the execution of the job.

[0068] The first case, where the jobs including flexibility intervals are jobs with flexibility intervals that follow the rules of the first subset, maximally simplifies the runtime behavior of the dispatcher.

[0069] Alternatively or additionally, it can be provided that, among those tasks of the task set that are to be executed on the core, at least one second subset of jobs is provided, wherein, for the jobs of the at least one second subset, the core schedule specifies a flexibility interval, such that the flexibility intervals of two or more jobs of the at least one second subset of jobs are identical, i.e. the start time of the flexibility intervals of the two or more jobs is the same time and the end time of the flexibility intervals of the two or more jobs is the same time, for the two or more jobs of the at least one second subset. For example, at least one of the flexibility intervals of the jobs is longer than the execution of the jobs.

[0070] This third case of jobs comprising flexibility intervals, which are jobs having flexibility intervals following the rules of the third subset, adds the maximum complexity to the runtime dispatching device.

[0071] Alternatively or additionally, it can be provided that, among those tasks of the task set that are to be executed on the core, at least one third subset of jobs is provided, wherein the flexibility intervals of any two jobs of the at least one third subset partially overlap. For example, at least one of the flexibility intervals of the jobs is longer than the execution of the jobs.

[0072] This third case of jobs comprising flexibility intervals, which are jobs having flexibility intervals following the rules of the third subset, adds the maximum complexity to the runtime dispatching device.

[0073] In this context, it is noted that the described subsets are self-contained, which means that, for those jobs having overlapping intervals, the overlap has to be between jobs of the same set (i.e. not overlapping with jobs being in one of the other sets).

[0074] The non-overlapping subset (first subset, subset 1) is the most restrictive subset: for a job to be in this subset, its flexibility interval shall not overlap with any flexibility interval of any other job of this subset. If there is an overlap between the flexibility intervals of two jobs, the two overlapping jobs are not part of the first subset.

[0075] Next is the second subset (subset 2) of jobs having the same flexibility interval. The flexibility interval of a job of this subset shall only overlap with the flexibility interval of other jobs having the same flexibility interval. If there is an overlap with a different flexibility interval, the two jobs cannot be in the second subset either.

[0076] Any other combination of flexibility intervals refers to the tasks of the third subset.

[0077] In the present invention, there must be tasks from at least one subset, wherein the at least one existing subset contains at least one flexibility interval which is longer than the corresponding execution interval. However, it is also possible that there are jobs from two or even three subsets. The dispatching device must be configured to be able to handle jobs from the existing subsets. Typically, a dispatcher is provided which can handle jobs from all subsets, but the dispatching device can also comprise a separate dispatcher for each of the current subsets.

[0078] It should be noted that there can be more subsets of each type. For example, there can be two different subsets of "type" subset 1, one with 3 jobs and one with 5 jobs, wherein all 3 jobs of the first subset 1 overlap each other and all 5 jobs of the second subset 1 overlap each other, but none of the 3 jobs overlaps with any of the 5 jobs.

[0079] With regard to the dispatching strategy applied by the dispatching device, different possible cases (case 1 to case 3) connected with the above described subsets of jobs (subset 1 to subset 3) will be described in the following.

[0080] For the sake of completeness, "case 0" is described here, as there can still be jobs with "rigid" execution intervals without flexibility intervals, such jobs must also be handled by the dispatching device. The dispatching strategy in this case is as follows: The runtime dispatching device will iterate through the schedule in time, while keeping track of the time progression in relation to the loop. The dispatching device (also referred to as "dispatcher") will compare the current time with the instants defining the start and end of each execution interval, which will be ordered incrementally in the schedule. The following rules describe the behavior of the runtime dispatcher in case 0:

[0081] • At the start of an execution interval, the corresponding job will be selected and started for execution. If another job is executing, it will be pre-empted (i.e. interrupted).

[0082] • At the end of said execution interval, if the job is still running, the job will be stopped and a new job will be selected as described above.

[0083] • If there is no execution interval within the time interval (e.g. gap in the schedule), the dispatcher will yield and wait until the next execution interval.

[0084] • If a job finishes execution before the end of its execution interval, the dispatcher will yield.

[0085] According to case 1 (non-overlapping flexibility intervals), it can be provided that for the jobs of at least one first subset of task jobs, the runtime dispatching device acts according to the following rules:

[0086] ■ if the current time is within the flexibility interval of the job, then:

[0087] o if the core for the job is free, i.e. no job is executing, then the job will be started for execution; and

[0088] o if the core for the job is not free, i.e. another job is executing, then the selected job will be started for execution at the first of:

[0089] ■ the time the core for the job becomes free, or

[0090] ■ the current time reaches the start of the execution interval of the selected job.

[0091] The runtime dispatcher according to this case 1 will iterate on a schedule while keeping track of the time progression related to the loop. The dispatcher will compare the current time with the times defining the start and end of each flexibility interval, which will be ordered incrementally in the schedule.

[0092] In the case of a non-free (processing) core, the job will start at the publication point of its execution interval in any case. At the end of the flexibility interval, if the job is still running, the job will be stopped. If this time corresponds to the start of the flexibility interval of another job, the job will be selected as described above.

[0093] If there is no flexibility interval within a time interval (e.g. a gap in the schedule), the dispatcher (= runtime dispatching means) will yield until the next flexibility interval. Yielding means giving up control of the CPU or core as the dispatcher has nothing to do (there is no job that can be executed now).

[0094] If all jobs complete execution before the end of their flexibility interval, the dispatcher will yield until the next flexibility interval.

[0095] In general, the execution interval defines a guaranteed interval, but it is replaced by the flexibility interval used to select and start jobs for their execution. Thus, the execution time of jobs can be greater than the time of their execution interval, which is an advantage in the following cases: when the exact worst-case execution time of a task is not known, or when one or all jobs of the task are underestimated, or when a job can eventually overrun.

[0096] Moreover, in general, there can be another dispatcher controlling and selecting other jobs of other tasks to execute in "gaps" of the tt schedule (i.e. when the tt schedule "yields"). Thus, when the dispatcher according to the present application schedules a job of a task in the tt schedule, there can already be a job of "another" task running, the "another" task being one of the set of tasks related to the tt schedule, or some other task related to some other dispatcher.

[0097] When such additional dispatchers are active in the computer system (e.g. hierarchically), execution of jobs of other tasks (e.g. fixed priority tasks) can occur within the flexibility interval of the selected job, at most until the beginning of the execution interval.

[0098] In this case, the present application has the advantage that:

[0099] ■execution of jobs of other tasks (e.g. fixed priority tasks) is allowed without compromising the guaranteed execution interval of the tasks provided by the tt schedule, and

[0100] ■execution of jobs of tasks in the tt schedule is allowed as soon as the processing core remains idle within its flexibility interval but not later than at the moment the execution interval starts, and

[0101] ■execution of jobs of tasks in the tt schedule is allowed until the end of its flexibility interval.

[0102] According to case 2 (strictly overlapping flexibility intervals), it can be provided that, for jobs of at least a second subset of task jobs, the run-time dispatching means act according to the following rules:

[0103] ■if the current time is within one or more flexibility intervals, the selection of one of the jobs equal to said flexibility intervals will be performed based on one of the following defined criteria:

[0104] o the job with the earliest execution interval will be selected and launched for execution; or

[0105] o the job with the shortest execution time will be selected and launched for execution; or

[0106] o the job resulting from the selection based on defined constraints (e.g. earliest deadline or highest priority) will be selected and launched for execution (this allows selection based on dynamic algorithms like Earliest Deadline First (EDF) or fixed priority dispatchers), or

[0107] o the job with higher probability of completing execution in less time than considered in the execution interval of the job will be selected (this provides more slack, i.e. unused CPU execution time).

[0108] The run-time dispatching means according to this case 2 will iterate on a schedule while keeping track of the time progression relative to the loop. The dispatcher will compare the current time to the instants defining the start and end of each flexibility interval, which will be ordered incrementally in the schedule. The selection in this sub-case is based on an estimation of the probability that the job will leave unused execution time. This time slack can then be used by other overrunning jobs within the subset of jobs sharing the flexibility interval bounds. The probability that the job will finish earlier can be measured dynamically during the execution in past loops, for example by computing a moving average over a series of past execution loops, or it can be based on static analysis and predefined before run-time.

[0109] In the context of case 2, it can be provided that the job selected and launched to execute will remain executing until any of the following events occurs:

[0110] ■the job completes the execution of the job within the current loop, or

[0111] ■the job reaches the amount of execution time corresponding to the execution interval of the job, regardless of the relative position of the current time within the flexibility interval during the execution of the job, preferably plus any slack amount available within the execution interval, computed as:

[0112] o the sum of the existing free intervals within the flexibility interval, computed as the difference between the length of the flexibility interval and the sum of the execution intervals of all jobs within said flexibility interval (this can be determined statically before run-time; this condition guarantees that no job will be left with less than the interval corresponding to the length of its execution interval), or

[0113] o the sum of the slacks provided by any job executing within the flexibility interval and not consumed by any other previous job (this can be determined dynamically based on the execution of the jobs),

[0114] or

[0115] ■the job reaches the amount of execution time corresponding to the execution interval of the job plus a defined overrun budget, specified as:

[0116] o a fixed time interval, for example 1 ms, or

[0117] o a relative percentage of the own execution time of the job, for example 10%,

[0118] or

[0119] ■the current time reaches the end of the flexibility interval.

[0120] The selection process will repeat as above for the remaining jobs (i.e. excluding the jobs already executed). The slack amount and statistical parameters will be updated if necessary.

[0121] Once all jobs have completed their execution within the cycle, the dispatcher will yield until the end of the flexibility interval and then repeat.

[0122] According to the most general case, case 3, the flexibility interval of a different job can partially overlap with the flexibility or execution interval of other jobs. Note that the execution interval of a different job cannot overlap. According to this case, the runtime dispatcher will iterate on a schedule while keeping track of the time progression related to the cycle. The dispatcher will compare the current time with the instants that define the start and end of each flexibility interval and execution interval, which will be ordered incrementally in the schedule.

[0123] In this context, it can be provided that, for a job of at least one third subset of jobs, the runtime dispatching device acts according to the following rules:

[0124] ■when the current time reaches the start of a flexibility interval, the job related to said flexibility interval is added to the list of eligible jobs, and wherein,

[0125] ■when one of the following conditions is met:

[0126] o the core on which the job is to be executed becomes free,

[0127] o the currently executed job completes the execution of the job, or is stopped, or is forced to stop,

[0128] o the current time reaches the start of the execution interval of one of the jobs of the list of eligible jobs,

[0129] the runtime dispatching device selects from the list of eligible jobs the job for which the start of the execution interval occurs earlier.

[0130] Once a job is selected from the list of eligible jobs, said job is removed from said list and is launched for execution. When the list of eligible jobs is empty, the runtime dispatching device yields.

[0131] It can also be provided that the execution of a job is stopped or the job is forced to stop execution when:

[0132] • the current time is equal to the completion point of the execution interval of said job and there exists in the list of eligible jobs a job whose start of execution interval is equal to the current time, or

[0133] • the current time is later than the completion point of the execution interval of said job and there exists in the list of eligible jobs a job whose start of execution interval is equal to the current time, or

[0134] • at the current time reaching the end of the flexibility interval of the performed job, if there is no job in the list of eligible jobs whose start of execution interval equals the current time.

[0135] In this context, it should be noted that it can be provided that the job completes its execution by itself before the above-mentioned condition is met.

[0136] According to the invention, at least one of the cases 1 to 3 and the corresponding strategy of the dispatching device exist. However, it is also possible that other cases, also case 0, or all cases 0, 1 to 3 exist in the schedule. The dispatching device is configured to handle all those cases that exist, implementing at least one of the run-time dispatching strategies described in cases 1, 2 and 3, in combination or not with the strategy described in case 0.

[0137] Furthermore, the invention relates to a run-time dispatching device for selecting jobs of tasks according to a global time-triggered schedule and starting said jobs for execution in a computer system, in particular for use in a method as described above,

[0138] - wherein the computer system comprises one or more cores on one or more central processing units of the computer system,

[0139] - wherein the global time-triggered schedule comprises one time-triggered schedule "core schedule" for each of the cores, wherein a job of a task of the set of tasks to be executed on a particular core is executed on said core according to the core schedule of said core,

[0140] - wherein the global time-triggered schedule specifies a cycle with a cycle length for the set of tasks,

[0141] wherein the core schedule of a core specifies for each job of a task of the set of tasks to be executed on said core:

[0142] • an execution interval of each task instance "job" of the task, during which may be performed the job, wherein each execution interval comprises a publication point of the start of the execution interval and a completion point of the end of the execution interval, wherein the duration of the execution interval is the duration of the time span between the publication point and the completion point of the execution interval, wherein the execution interval of the job defines the following time interval: during which said job has a guarantee to be executed on the core, and

[0143] • a period according to which the jobs of the task are executed on the core,

[0144] o wherein the execution interval of each job of the task is iteratively looped according to the cycle, and

[0145] wherein the execution interval of any two jobs in the same task and in different tasks do not overlap, and

[0146] wherein the cycle is a common multiple of all the periods of all the tasks in the task set.

[0147] The runtime dispatching device is characterized in that it is configured to select and launch a job of a task for execution according to the core schedule, taking into account all the flexibility intervals of the core schedule.

[0148] The present invention relates to a runtime dispatching device, for example a runtime dispatcher module, for example an operating system dispatcher, responsible for selecting one job among a set of jobs to be executed on a core, and launching said job for execution. The selection is performed among a subset of eligible jobs of the set of jobs, usually called the ready set of jobs, and depends on the above-mentioned cases in relation with the respective interval of each job.

[0149] In some cases, a runtime dispatcher can implement several dispatching policies, or in other cases, several dispatchers can coexist simultaneously in a computer system. For example, a system can be composed of two dispatchers, one implementing a fixed priority policy and one implementing a time triggered policy, where each of said dispatchers involves a separate set of jobs.

[0150] Some computer systems, for example GNU / Linux based computer systems, implement several runtime dispatchers organized in a hierarchy. When the top dispatcher has no job to select for execution in the list of eligible jobs of its task set, the top dispatcher yields and delegates the selection to the next dispatcher in the hierarchy. If no dispatcher has an eligible job to select, the corresponding core (CPU) is idle until a job becomes eligible.

[0151] In connection with case 1, it can be provided that the runtime dispatching device is configured to act for a first subset of jobs for which the core schedule specifies flexibility intervals that do not overlap each other, wherein at least one of the flexibility intervals of a job is longer than the execution of said job according to the following rules:

[0152] ■if the current time is within the flexibility interval of a job, then:

[0153] oif the core for said job is free, i.e. no job is executing, then said job will be launched for execution; and

[0154] oif the core for said job is not free, i.e. another job is executing, then the selected job will be launched for execution at the first of:

[0155] ■the time the core for said job becomes free, or

[0156] ■the current time reaches the start of the execution interval of the selected job.

[0157] In connection with case 2, it can be provided that the runtime dispatching device is configured to act for a second subset of jobs for which the core schedule specifies a flexibility interval such that the flexibility intervals of two or more jobs of said second subset of jobs are identical, i.e. according to the following rule, for said two or more jobs of said second subset, the start time of the flexibility intervals of said two or more jobs is the same time and the end time of the flexibility intervals of said two or more jobs is the same time:

[0158] ■if the current time is within one or more flexibility intervals, the selection of one of said jobs equal in flexibility interval will be performed based on one of the following defined criteria:

[0159] o the job with the earliest execution interval will be selected and started for execution; or

[0160] o the job with the shortest execution time will be selected and started for execution; or

[0161] o the job selected by a selection based on defined constraints, e.g. earliest deadline or highest priority, will be selected and started for execution; or

[0162] o the job with higher probability to complete execution of the job in less time than considered in the execution interval of the job and providing more slack, i.e. unused CPU execution time, will be selected.

[0163] In connection with case 2, it can also be provided that the runtime dispatching device is configured such that the job selected and started for execution will remain in execution until any of the following events occurs:

[0164] ■the job completes execution of the job within the current cycle, or

[0165] ■the job reaches the amount of execution time corresponding to the execution interval of the job, regardless of the relative position of the current time within the flexibility interval during execution of the job, preferably plus any amount of slack available within the execution interval, calculated as:

[0166] o the sum of existing free intervals within the flexibility interval, calculated as the difference between the length of the flexibility interval and the sum of the execution intervals of all jobs within said flexibility interval, or

[0167] o the sum of slack provided by any job executing within the flexibility interval and not consumed by any other preceding job,

[0168] or

[0169] ■ the job reaches an execution time amount corresponding to the execution interval of the job plus a defined overrunning budget, is designated as:

[0170] o a fixed time interval, for example 1 ms, or

[0171] o a relative percentage of the own execution time of the job, for example 10%,

[0172] or

[0173] ■ the current time reaches the end of the flexibility interval.

[0174] In connection with case 3, it can be provided that the runtime dispatching device is configured to act for a third subset of jobs for which the core schedule specifies that the flexibility interval of any two jobs of said third subset partially overlaps according to the following rules:

[0175] ■ at the current time reaching the start of the flexibility interval, the job related to said flexibility interval will be added to the list of eligible jobs, and wherein

[0176] ■ when one of the following conditions is met:

[0177] o the core on which the job is to be executed becomes free,

[0178] o the currently executed job finishes the execution of the job, or is stopped, or is forced to stop,

[0179] o the current time reaches the start of the execution interval of one of the jobs in the list of eligible jobs,

[0180] the runtime dispatching device will select from the list of eligible jobs the job for which the start of the execution interval occurs earlier.

[0181] In connection with case 3, it can also be provided that the execution of a job is stopped or the job is forced to stop execution when:

[0182] • the current time is equal to the completion point of the execution interval of said job and there is a job in the list of eligible jobs whose start of execution interval is equal to the current time, or

[0183] • the current time is later than the completion point of the execution interval of said job and there is a job in the list of eligible jobs whose start of execution interval is equal to the current time, or

[0184] • at the current time reaching the end of the flexibility interval of the executed job, if there is no job in the list of eligible jobs whose execution interval starts at the current time.

[0185] The present application also relates to a computer system comprising one or more cores on one or more central processing units, wherein the computer system is configured to perform tasks according to the method as described above, the computer system comprising a runtime dispatching device as described above.

[0186] Furthermore, the present application relates to a method of generating a core schedule of jobs for performing tasks on cores of a computer system, in particular for use in the method as described above, wherein the core schedule comprises flexibility intervals of jobs to be executed on said cores, the method comprising the steps of:

[0187] • providing a time-triggered schedule for the tasks to be executed on said cores, the time-triggered schedule comprising an execution interval for each job of each task and a period for each task according to which the jobs of said task are executed cyclically,

[0188] • determining schedulability bounds based on said time-triggered schedule and based on a set of scheduling constraints, resulting in an upper bound and a lower bound for each execution interval,

[0189] • for example, by iteratively increasing the execution interval starting from the execution interval of a first job of a task according to said time-triggered schedule for said cores, while checking whether the scheduling constraints are met, and

[0190] • determining the extended execution interval of the previous iteration as the flexibility interval of said first job as soon as at least one scheduling constraint is not met in the iteration,

[0191] • being selected as first job until all jobs are provided with a flexibility interval,

[0192] selecting the next job and repeating said method until all jobs are provided with a flexibility interval. BRIEF DESCRIPTION OF DRAWINGS

[0193] The present application is described by way of non-limiting example with reference to the accompanying drawings:

[0194] figure 1 A time-triggered schedule is depicted for a set of jobs TS1 without flexibility intervals.

[0195] figure 2 A time-triggered schedule with flexibility intervals is depicted for a set of jobs TS2 with non-overlapping flexibility intervals.

[0196] figure 3A time triggered scheduling with flexible slots is depicted for a set of jobs TS3 with fully overlapping flexible slots.

[0197] figure 4 A time triggered scheduling with flexible slots is depicted for a set of jobs with partially overlapping flexible slots.

[0198] figures 5 to 8 An exemplary execution instance of the time triggered scheduling depicted in figures 1 to 4 the middle is depicted. DETAILED DESCRIPTION

[0199] A computer system, e.g. an automotive computer system, comprises one or more hosts, in particular processors, wherein each host h n of a host set H = {h i comprises one or more CPU cores, characterized by a CPU core set C H = {c h 1.. c h k}, wherein the CPU cores are configured to execute instructions. A software application, e.g. an automotive function, comprises software components (tasks) comprising sequences of instructions executable in the one or more CPU cores.

[0200] A software task is executed cyclically in the CPU cores, wherein each software task sw m of a defined software task set SW = {sw i is characterized by

[0201] • its length of execution cycle, i.e. its period, or minimum interarrival time p i , and

[0202] • its maximum required execution budget w i corresponding to the cumulative time required for executing the task in one CPU core within one cycle, e.g. its worst case computation time (WCET), or an estimate of the required computation time.

[0203] A software task sw i may be further characterized by

[0204] • its earliest release time e i indicating the earliest relative time at which the software task is ready for execution with respect to the start of the cycle, and / or

[0205] • its execution deadline d iIt indicates that the software task should be completed at the latest relative time point after the start of the execution cycle corresponding to the loop.

[0206] Software tasks in the CPU are executed according to a time-triggered scheduling paradigm, whereby the runtime components (dispatchers) of the computer system, such as the runtime dispatcher components of the operating system, select and dispatch instances of the tasks (jobs) to be executed in the CPU core at defined time intervals or intervals according to a predefined time-triggered scheduling (TT scheduling).

[0207] Each of the intervals is characterized by a start time or time offset o and a duration or length b.

[0208] The time-to-time (TT) scheduling used for CPU core c, also known as "core scheduling," involves the time schedule TT. c Its loop is a table z c, The timetable is characterized by its length, or scheduling cycle, and a sequence of one or more elements, wherein each element of the timetable is characterized by a reference to an assigned job of a software task sw from a software task SW set.

[0209] The periodic execution of a task within a scheduling loop comprises one or more executions of a task instance or job of the task, represented by one of the elements in the timetable, wherein each job corresponds to the task according to its periodic execution within the scheduling loop. If the task period is equal to the scheduling loop, there is a single job of the task within the scheduling loop; if the scheduling loop is longer than the period, there are multiple jobs of the task depending on the relationship between the period and the scheduling loop. Note that the length of the scheduling loop should be a common multiple of the periods of all tasks, for example, the least common multiple.

[0210] In the example shown below, for simplicity, it is assumed that each particular task is executed only once within a loop of length T (more precisely, only one job of the task is executed within the loop), such that in the following description, for simplicity, the phrase "execution of the task" is used instead of the phrase "execution of the job of the task".

[0211] According to the invention, each element of the timetable is further characterized by an additional flexibility interval fi.

[0212] Table 1 shows an exemplary task set (also referred to as the "task set") TS0, which includes three tasks (each task being a job) sw1, sw2, and sw3, characterized by their period p, early release time e (earliest start point), deadline d (latest completion point), and execution budget w.

[0213]

[0214] Table 1

[0215] The reference symbol "T" denotes the length of the cycle specified by the global time-triggered schedule.

[0216] figure 1 An example of a time-triggered schedule computed by an offline time-triggered scheduler for the task set TSO according to the prior art is depicted. As can be seen from figure 1 As in the prior art, each task is assigned a fixed execution interval and no flexibility interval is provided.

[0217] Table 2 characterizes in the form of a time table the tt schedule from figure 1 with the schedule cycle z equal to the period p (i.e. z = T) and the execution intervals si, s2 and s3 (o is the start time and b the duration / length),

[0218]

[0219] Table 2

[0220] Table 3 shows an exemplary task set ("first" task set) TS1 comprising three tasks sw4, sw5 and sw6 characterized by their period p, early release time e, deadline d and execution budget w.

[0221]

[0222] Table 3

[0223] figure 2 An example of a time-triggered schedule for the task set TS1 from Table 3 is depicted, which has for the tasks in the task set TS1 the execution intervals s4, s5, s6 and the non-overlapping flexibility intervals fi4, fi5 and fi6.

[0224] Table 4 characterizes in the form of a time table the tt schedule from figure 2 with the schedule cycle equal to the period T (i.e. z = T) and the execution intervals s4, s5 and s6. The parameters o and b refer to the execution interval of the respective task and fi to the flexibility interval of the respective task.

[0225]

[0226] Table 4

[0227] Table 5 shows an exemplary task set ("second" task set) TS2 comprising three tasks sw7, sw8 and sw9 characterized by their period p, early release time e, deadline d and execution budget w.

[0228]

[0229] Table 5

[0230] figure 3 A time-triggered schedule with flexibility intervals is depicted for a task set with identical, fully overlapping flexibility intervals f17, f18, and f19 for the task set TS2.

[0231] Table 6 characterizes in tabular form a tt schedule from figure 3 with a schedule cycle equal to the period T (i.e., z = T) and execution intervals (parameters o, b) s7, s8, and s9.

[0232]

[0233] Table 6

[0234] An additional exemplary task set ("third" task set) TS3 comprising three tasks sw 10 , sw 11 , and sw 12 is characterized in Table 7 by the period p, early release time e, deadline d, and execution budget w of each task sw 10 , sw 11 , sw 12 in the task set TS3.

[0235]

[0236] Table 7

[0237] figure 4 A time-triggered schedule with flexibility intervals is depicted for a task set with partially overlapping flexibility intervals f 10 , f 11 , and f 12 for the task set TS3 from Table 7.

[0238] Table 8 characterizes in tabular form a tt schedule from figure 4 with a schedule cycle equal to the period T (i.e., z = T) and execution intervals (parameters o, b) s 10 , s 11 , s 12 .

[0239]

[0240] Table 8

[0241] figures 5 to 8 An exemplary execution instance ("job") of the time-triggered schedule depicted in figures 1 to 4 and characterized in the above tables is depicted.

[0242] Case 0: (Pre-existing technology)

[0243] As described above, the exemplary task set TS0 includes three tasks: sw1, sw2, and sw3.

[0244] The time-triggered scheduler accordingly calculates the time-triggered schedule for TS0 without flexible intervals as shown in Table 2.

[0245] For the purposes of this example, figure 5 The possible execution trajectories of the task set TS0 are depicted, wherein the execution time of each task in the task set is less than or equal to the corresponding execution interval of the task.

[0246] The start time of each task is strictly defined to the beginning of the execution interval determined by the time-triggered schedule, regardless of the early termination of any previous tasks in the corresponding time-triggered schedule. For example, figure 5 The execution of sw2 begins at time t3, which is earlier than the execution interval t2 of task sw1 as defined in the time-triggered scheduling table 2. 11 The facts of the execution are irrelevant.

[0247] Furthermore, according to a general time-triggered dispatcher that lacks the additional advantages of the present invention, figure 5 The end of the execution time of task sw3 is defined as the end of the execution interval t6, regardless of whether the task has completed its execution at point t6.

[0248] Scenario 1:

[0249] The first task set TS1, comprising three tasks sw4, sw5, and sw6, is described in detail above and characterized in Table 3. The time-triggered scheduler, incorporating the advantages of this invention, can calculate the values ​​characterized in Table 4. figure 2 The time-triggered scheduling described in the text has flexible intervals for non-overlapping tasks.

[0250] For the purposes of this example, figure 6 The possible execution trajectories of the first task set TS1 are depicted, wherein the available execution time of some tasks in the task set is greater than the corresponding task execution interval.

[0251] like figure 6 As depicted herein, the time-triggered dispatcher (dispatch device) according to the invention can select and initiate tasks for execution. For example, in an exemplary trajectory, if the CPU core is idle for a time t0 prior to the start of the execution interval t1 of sw4, then figure 6 The execution of sw4 in the middle can begin at that time (due to its flexible interval).

[0252] In this example, the task sw5 starts at a time t0 earlier than the start of its execution interval s5 (= t4-t3) during its flexibility interval, and ends at a time t1 later than the end of its execution interval t4 (but before the end of its flexibility interval). Thus, according to the execution time of the task sw5 is bounded by the start of its flexibility interval t2 and the end of its execution interval t4. 31 In this example, the task sw5 starts at a time t0 earlier than the start of its execution interval s5 (= t4-t3) during its flexibility interval, and ends at a time t1 later than the end of its execution interval t4 (but before the end of its flexibility interval). Thus, according to the execution time of the task sw5 is bounded by the start of its flexibility interval t2 and the end of its execution interval t4. figure 6 In this example, the execution time of the task sw5 starts at a time t3 later than the start of its execution interval s5 (= t4-t3) during its flexibility interval, and ends at a time t4 later than the end of its execution interval t4 (but before the end of its flexibility interval). Thus, according to the execution time of the task sw5 is bounded by the start of its execution interval s5 and the end of its flexibility interval t6. 31 In this example, the execution time of the task sw5 starts at a time t3 later than the start of its execution interval s5 (= t4-t3) during its flexibility interval, and ends at a time t4 later than the end of its execution interval t4 (but before the end of its flexibility interval). Thus, according to the execution time of the task sw5 is bounded by the start of its execution interval s5 and the end of its flexibility interval t6.

[0253] figure 6 In this example, the execution time of the task sw5 starts at a time t3 later than the start of its execution interval s5 (= t4-t3) during its flexibility interval, and ends at a time t4 later than the end of its execution interval t4 (but before the end of its flexibility interval). Thus, according to the execution time of the task sw5 is bounded by the start of its execution interval s5 and the end of its flexibility interval t6.

[0254] Case 2:

[0255] As described in detail above, a further exemplary task set, i.e. a second task set TS2, comprising three tasks sw7, sw8 and sw9 is characterized in Table 5. A time-triggered scheduler comprising the advantages of the present invention can compute a time-triggered schedule with flexibility intervals for the tasks as characterized in Table 6, e.g. as depicted in Table 6. figure 3 In this example, the flexibility intervals are equal.

[0256] For the purpose of this example, figure 7 a possible execution trajectory of the task set is depicted, wherein the task execution time of some tasks of the task set is greater than the corresponding task execution interval.

[0257] According to the time-triggered scheduler based on the present invention, the start execution time of each task is bounded by the corresponding flexibility interval determined by the time-triggered schedule, wherein the flexibility intervals are equal for all tasks of the task set. For example, in the exemplary trajectory, figure 7 the execution of sw9 in Table 6 starts at a time t0 before the start of its execution interval t5 and before the tasks sw7 and sw8 with earlier execution intervals, e.g. this is due to the fact that the task sw9 has a shorter execution time than its budget execution interval s9, e.g. identified by historical observation of previous cycles, or due to the fact that the tasks are dispatched based on a static definition or a dynamic allocation of priorities, whereby sw9 is allocated a higher priority than sw8 and sw7.

[0258] Further, according to the time-triggered scheduler based on the present invention, the end of the execution time of sw9 in Table 6 is bounded by the end of the flexibility interval t7, regardless of the defined end of the execution interval t6, e.g. if needed, thereby allowing the task sw9 to execute longer than its allocated execution interval. figure 7In the example of Fig. 6, the execution time (t7-t3) of task sw8 is greater than the execution budget corresponding to its execution interval t4-t3, thus allowing a greater execution time for sw8, which for example includes the cumulative slack of unused time from previous tasks plus additional time within the flexibility interval, thus for example allowing sw8 to implement a progressive algorithm that maximizes its execution time until the end of the flexibility interval, whereby the functional performance of said algorithm improves proportionally to its runtime.

[0259] Case 3:

[0260] Another example task TS3, i.e. third set of tasks, comprising three tasks sw 10 , sw 11 and sw 12 is characterized in Table 7. A time-triggered scheduler can compute a time-triggered schedule as described in Table 8 and depicted in Fig. 6 by the start of the execution interval o, the length of the execution interval b, the related tasks sw and the flexibility interval fi of each execution interval, and is provided with flexibility intervals computed according to an embodiment of the application, and wherein said flexibility intervals partially overlap. figure 4

[0261] For the purpose of this example, figure 8 a possible execution trajectory of said third set of tasks is depicted, wherein the task execution time of some tasks of the set of tasks is greater than the corresponding task execution interval.

[0262] According to a time-triggered scheduler based on the application, the start execution time of each task is delimited by the corresponding flexibility interval determined by the time-triggered schedule, which flexibility intervals partially overlap. For example, in the example trajectory, figure 8 the execution of sw 10 may start at time t0 before the start of its execution interval t2. Similarly, task sw 11 may start at time t 10 just after sw 21 has finished executing and before the start of its execution interval t4.

[0263] Moreover, figure 8 the execution time (t 61 -t 41 ) of task sw 12 in Fig. 6 is greater than the execution budget corresponding to its execution interval t7-t6, thus allowing a greater execution time for sw 12 .

[0264] References

[0265] ​[1] S. S. Craciunas, R. Serna Oliver. Combined Task- and Network-level Scheduling for Distributed Time-triggered Networked Systems. Real-Time Systems, Volume 52, Issue 2, pp. 161-200, Springer, 2016.

[0266] [2] Anna Minaeva and Zdenek Hanzalek. 2021. Survey on Periodic Scheduling for Time-triggered Hard Real-time Systems. ACM Computing Surveys, Volume 54, Issue 1, Article 23 (January 2022), 32 pages. https: / / doi.org / 10.1145 / 3431232

[0267] [3] Richard Hladik, Anna Minaeva, and Zdenek Hanzalek. 2020. On the Complexity of a Periodic Scheduling Problem with Precedence Relations. Combinatorial Optimization and Applications: 14th International Conference, COCOA 2020 Proceedings, Dallas, TX, USA, December 11-13, 2020. Springer-Verlag, Berlin, Heidelberg, pp. 107-124. https: / / doi.org / 10.1007 / 978-3-030-64843-5_8

[0268] [4] McLean SD, Juul Hansen EA, Pop P, and Craciunas SS (2022) Configuring ADAS Platforms for Automotive Applications Using Metaheuristics. Front. Robot. AI. 8:762227. doi: 10.3389 / frobt.2021.762227

[0269] [5] A. F. Mills and J. H. Anderson, “A Multiprocessor Server-Based Scheduler for Soft Real-Time Tasks with Stochastic Execution Demand,” in 17th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications, Toyama, Japan, 2011, pp. 207-217, doi: 10.1109 / RTCSA.2011.30.

[0270] [6] Ramon Serna Oliver, Paraskevas Karachatzis, and Silviu Craciunas, “Method to execute a mode-transition in a multi-mode computer system.” U.S. Patent Application No. 17 / 930,811.

[0271] [7] Baruah, S. K., Rosier, L. E., and Howell, R. R. Algorithms and complexity concerning the preemptive scheduling of periodic, real-time tasks on one processor. Real-Time Systems 2, pp. 301-324 (1990). https: / / doi.org / 10.1007 / BF01995675

[0272] [8] R. Pellizzoni and G. Lipari, “Feasibility analysis of real-time periodic tasks with offsets,” Real-Time Systems, vol. 30, no. 1-2, pp. 105-128, 2005

[0273] [9] Kong, W; Nabi, M.; Goossens, K. Run. Time Recovery and Failure Analysis of Time-Triggered Traffic in Time Sensitive Networks. IEEE Access. 2021, 9, 91710-91722.

[0274]

[10] Li, J.; Xiong, H.; Li, Q.; Xiong, F.; Feng, J. Time Reconfiguration Strategy and Implementation of Time-Triggered Networks. Electronics, 2022, 11, 1477. https: / / doi.org / 10.3390 / electronics11091477.

Claims

1. A method of executing a job of a set of tasks in a computer system according to a global time-triggered schedule, - wherein, said computer system comprising one or more cores on one or more central processing units of said computer system, - wherein said global time-triggered schedule comprises one time-triggered schedule "core schedule" for each of said cores, wherein a task of said set of tasks to be executed on a particular core is executed on said core according to the core schedule of said core, - wherein said global time-triggered schedule specifies a cycle of a cycle length for said set of tasks, wherein the core schedule of a core specifies for each task of said set of tasks to be executed on said core: • an execution interval of each task instance "job" of said task, during which said job can be executed, wherein each execution interval comprises a publication point at which said execution interval starts and a completion point at which said execution interval ends, wherein the duration of an execution interval is the duration of the time span between said publication point and said completion point of said execution interval, wherein the execution interval of a job defines a time interval during which said job has a guarantee to be executed on said core, and • a period according to which jobs of said task are executed on said core, o wherein the execution interval of each job of said task is iteratively looped according to said cycle, and wherein the execution intervals of any two jobs of the same task and of different tasks do not overlap, and wherein said cycle is a common multiple of all periods of all tasks of said set of tasks, characterized in that: the core schedule specifies for each job a flexibility interval, wherein the duration of the flexibility interval of a job is equal to or longer than the execution interval of said job, wherein, the flexibility interval of at least one job is longer than the execution interval of said job, wherein, the flexibility interval of a job starts no later than the publication point of the execution interval of said job, and wherein, the flexibility interval of a job ends no earlier than the completion point of the execution interval of said job, wherein, the flexibility of a job defines a time interval during which said job can be executed, and wherein, a run-time dispatching means is provided which selects and launches jobs for execution according to said global time-triggered schedule taking into account all flexibility intervals specified in said core schedule for each core.

2. The method of claim 1, wherein, Among the jobs of those tasks of said set of tasks to be executed on said core, a first at least one subset of jobs is provided, wherein for the jobs of said first at least one subset, the core schedule specifies flexibility intervals which do not overlap each other, wherein at least one of the flexibility intervals of a job is longer than the execution of said job.

3. The method of claim 1 or 2, wherein, Among those tasks of the task set to be executed on the core, at least one second subset of jobs is provided, wherein, for the jobs of the at least one second subset, the core schedule specifies a flexibility interval, such that the flexibility intervals of two or more jobs of the at least one second subset of jobs are identical, i.e. the start time of the flexibility intervals of the two or more jobs of the at least one second subset of jobs is the same time and the end time of the flexibility intervals of the two or more jobs is the same time.

4. The method of any one of claims 1 to 3, wherein, Among those tasks of the task set to be executed on the core, at least one third subset of jobs is provided, wherein the flexibility intervals of any two jobs of the at least one third subset partially overlap.

5. The method of any one of claims 2 to 4, wherein, For a job of the at least one first subset of task jobs, the runtime dispatching device acts according to the following rules: ■if the current time is within the flexibility interval of the job, then: o if the core for the job is free, i.e. no job is executing, then the job will be started to execute; and o if the core for the job is not free, i.e. another job is executing, then the selected job will be started to execute at the first of the following times: ■the time at which the core for the job becomes free, or ■the current time reaches the start of the execution interval of the selected job.

6. The method of any one of claims 3 to 5, wherein, For a job of the at least one second subset of task jobs, the runtime dispatching device acts according to the following rules: ■if the current time is within one or more flexibility intervals, then the selection of one of the jobs equal in flexibility interval will be performed based on one of the following defined criteria: o the job with the earliest execution interval will be selected and started to execute; or o the job with the shortest execution time will be selected and started to execute; or o the job resulting from the selection based on defined constraints, e.g. earliest deadline or highest priority, will be selected and started to execute; or o the job with higher probability of being selected to complete the execution of the job in less time than considered in the execution interval of the job will be selected, thus providing more slack, i.e. unused CPU execution time.

7. The method of claim 6, wherein, The job selected and started to execute will remain executing until any of the following events occurs: ■the job completes the execution of the job within the current cycle, or ■the job reaches the amount of execution time corresponding to the execution interval of the job, regardless of the relative position of the current time within the flexibility interval during the execution of the job, preferably plus any amount of slack available within the execution interval, calculated as: o the sum of existing free intervals within the flexibility interval, calculated as the difference between the length of the flexibility interval and the sum of the execution intervals of all jobs executing within the flexibility interval, or o the sum of slack provided by any job executing within the flexibility interval and not consumed by any other previous job, or ■ said job reaches an execution time amount corresponding to an execution interval of said job plus a defined overrunning budget, designated as: o a fixed time interval, e.g. 1 ms, or o a relative percentage of the own execution time of said job, e.g. 10%, or ■ said current time reaches the end of said flexibility interval.

8. The method of any one of claims 4 to 7, wherein, For jobs of said at least one third subset of jobs, said runtime dispatching device acts according to the following rules: ■ when said current time reaches the start of a flexibility interval, a job related to said flexibility interval will be added to the list of eligible jobs, and wherein, ■ when one of the following conditions is met: o the following core becomes free: said job is to be executed on said core, o a currently executed job finishes the execution of said job, or is stopped, or is forced to stop, o said current time reaches the start of the execution interval of one of the jobs of said list of eligible jobs, said runtime dispatching device will select from said list of eligible jobs the job for which the start of the execution interval of said job occurs earlier.

9. The method of claim 8, wherein, Execution of a job is stopped or said job is forced to stop execution in the following cases, • when said current time is equal to the completion point (completion time) of the execution interval of said job and there exists in said list of eligible jobs a job for which the start of the execution interval of said job is equal to said current time, or • when said current time is later than the completion point of the execution interval of said job and there exists in said list of eligible jobs a job for which the start point (start time) of the execution interval of said job is equal to said current time, or • when said current time reaches the end of the flexibility interval of said executed job, if there is no job in said list of eligible jobs for which the start of the execution interval of said job is equal to said current time.

10. A runtime dispatching device for selecting jobs of tasks and starting said jobs for execution in a computer system according to a globally time-triggered schedule, in particular for use in a method according to one of claims 1 to 9, - wherein, said computer system comprising one or more cores on one or more central processing units of said computer system, - wherein said globally time-triggered schedule comprises one time-triggered schedule "core schedule" for each of said cores, wherein a job of a task of said task set to be executed on a particular core is executed on said core according to the core schedule of said core, - wherein said globally time-triggered schedule specifies a cycle with a cycle length for said task set, wherein the core schedule of a core specifies for a job of each task of said task set to be executed on said core: ■ the start of the execution interval of said job, • an execution interval of each task instance "job" of said task, during which said job can be executed, wherein each execution interval comprises a release point at which said execution interval starts and a completion point at which said execution interval ends, wherein the duration of an execution interval is the duration of the time span between said release point and said completion point of said execution interval, wherein an execution interval of a job defines a time interval during which said job has a guarantee to be executed on said core, and • a period according to which jobs of said task are executed on said core, o wherein the execution intervals of each job of said task are iteratively looped according to said loop, and o wherein the execution intervals of any two jobs of said task are non-overlapping, and o wherein said loop is a common multiple of all periods of all tasks of said task set, characterized in that: said runtime dispatching means are configured to select and launch jobs of a task for execution according to said core schedule, taking into account all flexibility intervals of said core schedule.

11. The runtime dispatch apparatus of claim 10, wherein, said runtime dispatching means are configured to act for a first subset of jobs for which said core schedule specifies flexibility intervals that are non-overlapping with each other, wherein at least one of the flexibility intervals of a job is longer than the execution of said job according to the following rule: ■if the current time is within a flexibility interval of a job, then: o if the core for said job is free, i.e. no job is executing, then said job will be launched for execution; and o if the core for said job is not free, i.e. another job is executing, then the selected job will be launched for execution at the first of the following moments: ■the moment at which the core for said job becomes free, or ■the current time reaches the start of the execution interval of the selected job.

12. The run-time dispatch apparatus of claim 10 or 11, wherein, said runtime dispatching means are configured to act for a second subset of jobs for which said core schedule specifies flexibility intervals such that the flexibility intervals of two or more jobs of said second subset of jobs are identical, i.e. according to the following rule, for said two or more jobs of said second subset, the start moment of the flexibility intervals of said two or more jobs is the same moment and the end moment of the flexibility intervals of said two or more jobs is the same moment: ■if the current time is within one or more flexibility intervals, then the selection of one of the jobs whose flexibility intervals are equal will be performed based on one of the following defined criteria: o the job with the earliest execution interval will be selected and launched for execution; or o the job with the shortest execution time will be selected and launched for execution; or o the job resulting from a selection based on defined constraints, e.g. earliest deadline or highest priority, will be selected and launched for execution; or o the job for which the probability of being selected is higher to complete the execution of said job in less time than the time considered in the execution interval of the job, thus providing more slack, i.e. unused CPU execution time, will be selected.

13. The runtime dispatch apparatus of claim 12, wherein, The runtime dispatching device is configured so that the job selected and started to execute will remain executing until any of the following events occurs: ■the job completes the execution of the job within the current cycle, or ■the job reaches an amount of execution time corresponding to the execution interval of the job, regardless of the relative position of the current time within the execution interval of the job during the execution of the job, preferably plus any amount of slack available within the execution interval, computed as: o the sum of existing slack intervals within the flexibility interval, computed as the difference between the length of the flexibility interval and the sum of the execution intervals of all jobs within the flexibility interval, or o the sum of slacks provided by any job executing within the flexibility interval and not consumed by any other preceding job, or ■the current time reaches the end of the flexibility interval. The runtime dispatching device is configured to act for a third subset of jobs for which the core schedule specifies that the flexibility intervals of any two jobs of the third subset partially overlap according to the following rules: ■when the current time reaches the beginning of a flexibility interval, the job related to the flexibility interval will be added to a list of eligible jobs, and wherein ■when one of the following conditions is met: o the following core becomes idle: the job is to be executed on the core, 14. The runtime dispatch apparatus of any one of claims 10 to 13, wherein, o a currently executing job completes the execution of the job, or is stopped, or is forced to stop, o the current time reaches the beginning of the execution interval of one of the jobs in the list of eligible jobs, the runtime dispatching device will select from the list of eligible jobs the job for which the beginning of the execution interval of the job occurs earlier. The execution of a job is stopped or the job is forced to stop execution in the following cases: ● when the current time is equal to the completion point of the execution interval of the job and there exists in the list of eligible jobs the job for which the beginning of the execution interval of the job is equal to the current time, or ● when the current time is later than the completion point of the execution interval of the job and there exists in the list of eligible jobs the job for which the beginning of the execution interval of the job is equal to the current time, or ● when the current time reaches the end of the flexibility interval of the executing job, if there is no job in the list of eligible jobs for which the beginning of the execution interval of the job is equal to the current time.

15. The runtime dispatch apparatus of claim 14, wherein, The computer system is configured to perform tasks according to the method based on one of claims 1 to 9, the computer system comprising a runtime dispatching device according to one of claims 10 to 15. ​ ​ ​ 16. A computer system comprising one or more cores on one or more central processing units, wherein, ​ 17. A method of generating a core schedule of jobs for executing tasks on cores of a computer system, in particular for use in a method according to one of claims 1 to 9, wherein, The core schedule comprises flexibility intervals for the jobs to be executed on the core, the method comprising the steps of: • providing a time triggered schedule for the tasks to be executed on the core, the time triggered schedule comprising an execution interval for each job of each task and a period for each task, the jobs of the tasks being executed cyclically according to the period, • determining schedulability bounds based on the time triggered schedule and based on a set of scheduling constraints, resulting in an upper bound and a lower bound for each execution interval, • for example by iteratively increasing the execution interval starting from the execution interval of a first job of a task according to the time triggered schedule for the core, while checking whether the scheduling constraints are met, and • once in an iteration at least one scheduling constraint is not met, determining the extended execution interval of the previous iteration as the flexibility interval for the first job, • being selected as first job until all jobs are provided with a flexibility interval, selecting the next job and repeating the method until all jobs are provided with a flexibility interval.

Images