Method for mitigating temporal interference via temporal exclusions configured by compilation

Abstract

The invention relates to a method for scheduling a set of tasks on a multitask computer (30) comprising at least one processing core, the method comprising - for each core, initialising (S1) a scheduling plan (13) subdivided into time intervals based on time data (12) obtained for each task (11) in the set intended for the core; - iteratively allocating (S3–S11) fragments for each task in the corresponding scheduling plan, by considering the tasks in an order determined by the precedence relationships, while observing a set of constraints, and determining (S10) whether all of the fragments of the task have been allocated in the plan (13) before a deadline associated with this task, as defined by the time data - transmitting (S13) all of the plans (13) to the computer (30).

Description

Description Title of the invention: Method for mitigating temporal interference by temporal exclusions configured by compilation

[0001] [FIELD OF THE INVENTION

[0002] The present invention relates to real-time multitasking and multi-core systems, and in particular to safety systems implementing time constraints. It applies in particular to on-board systems, for example in aerial vehicles. It can in particular be applied to on-board integrated modular avionics (IMA) systems.

[0003] In the field of avionics, in particular, a high level of performance and compliance with these time constraints is necessary, since the slightest failure can pose considerable risks to the aerial vehicle. Even in the case of an unmanned aerial vehicle commonly called drones or UAS (for "Unmanned Aircraft System" in English), to which the invention can also be applied, the risk of loss of the vehicle remains, in addition to its possible crash into inhabited areas. Similar risks may exist for other types of vehicles (automobiles, railways, naval, etc.), or other systems requiring this type of time constraints (nuclear industry, etc.)

[0004] In critical real-time multitasking systems, strategies are generally implemented for provisioning time quotas to the different tasks, so that each can execute within its own constraints, in particular rate and latency.

[0005] Time quotas allocated to tasks are generally based on the concept of worst-case execution time (or WCET) which is previously assigned to each task to be deployed on a multitasking computer.

[0006] Estimating this maximum execution time required to complete a task, WCET, is a well-known research problem and recognized as particularly difficult.

[0007] It becomes even more complex when considering computers, or multi-core systems, due to the temporal interference generated by the fact that certain tasks can be deployed on the same time windows (but on different cores) while they require, for example, common hardware resources (input / output ports, internal buses of the computer, etc.).

[0008] In the specific field of avionics, international standards and norms make it possible to specify the requirements that aerial vehicles and the various on-board systems must meet.

[0009] For example, we can cite the DO-178C standard published by the RTCA (for "Radio Technical Commission for Aeronautics") and imposed by numerous regulatory bodies such as the FAA or the EASA, which specifies requirements for on-board software systems.

[0010] More specifically, AMC 20-193 defines a possible use of multi-core computers compatible with the higher-level requirements specified by the DO-178C standard. This AMC 20-193 standard details a set of objectives that must be met by a set of tasks deployed on a multi-core computer to enable certification according to these standards.

[0011] In particular, document AMC 20-193 requires the identification of temporal interferences and the definition of a strategy to tolerate or mitigate them (i.e. to attenuate them, or even eliminate them):

[0012] “MCP_Resource_Usage_3: The applicant has identified the interference channels that could permit interference to affect the software applications hosted on the MCP cores, and has verified the applicant's chosen means of mitigating the interference.”

[0013] Furthermore, platforms are available to facilitate the specification of tasks to be deployed on a multi-core computer and the determination of a scheduling plan to meet their specific time requirements, as well as to enable their execution in accordance with this scheduling plan.

[0014] An example is the ASTERIOS™ software suite developed by Asterios Technologies (formerly Krono-Safe).

[0015] It includes a tool (ASTERIOS™ RTK) allowing a set of real-time tasks to be executed on a multi-core computer in accordance with a scheduling plan, for example provided by another tool in the chain (ASTERIOS™ Developer).

[0016] The mechanisms implemented are for example described in patent application WO2015092188A1.

[0017] However, these mechanisms do not allow for taking into account temporal interference between tasks to be deployed on different cores of the multi-core computer.

[0018] One aim of the invention is therefore to improve the current proposals of the state of the art by allowing, in particular, the taking into account of temporal interferences generated between tasks.

[0019] SUMMARY OF THE INVENTION

[0020] For these purposes, according to a first aspect, the present invention can be implemented by a method of scheduling a set of tasks on a multitask computer, comprising at least one processing core, said method comprising - for each core of said computer, initialize a scheduling plan subdivided into time intervals from time data obtained for each task of said set provided for said core; - iteratively allocating processing fragments for each task scheduled for said core in the respective scheduling plan, considering said tasks in a link-dependent order of temporal precedents defined for said tasks, and respecting a set of constraints consisting of: - to iteratively consider each interval of said scheduling plan not yet allocated to a task, - to position said fragments in said scheduling plan at the earliest at a time determined from said temporal precedent links and a start date of said task defined by said temporal data, - not positioning said fragments in overlap with fragments of another task with which there is an exclusion constraint, among the set of scheduling plans, and determining whether all of the processing fragments of said task are allocated in said scheduling plan before a due date associated with said task, defined by said time data; - transmit all of said scheduling plans to said calculator.

[0021] According to preferred embodiments, the invention comprises one or more of the following features which may be used separately or in partial combination with each other or in total combination with each other: - iteratively allocating processing fragments for each task planned for said core includes steps of: - calculation of said instant from said temporal precedent links, by searching for the latest of the dates among the start date of said task and the completion dates of the tasks having precedent over said task, - determination of a list of fragments corresponding to tasks having a precedence relationship with said task, - selection of a time interval of said scheduling plan, and, for said selected time interval, determination of empty spaces not yet allocated to a task, from said instant, deletion of the empty spaces associated with an exclusion constraint for said task, then allocating remaining empty spaces to a fragment of said task; - if the sum of the durations of the intervals allocated to said task is less than the execution time associated with said task and no interval not yet allocated is available before a deadline associated with said task, then the allocations of said task are deleted and an attempt is made to allocate another task; - the method further comprises a step of sorting the tasks of said set of tasks, and a step of selecting a task according to said sorting, and in which trying to allocate another task comprises a new sorting of said tasks, after having checked whether all possible sorts have not been tried; - trying to allocate another task includes a tree traversal within said possible sorts; - the method further comprises, when allocating a processing fragment, an assignment to said fragment of a start date within said scheduling plan as a function of the start date of said time interval; - said start date is assigned to a fragment only if said fragment would not overlap with a fragment of another task with which there is an exclusion constraint on the time interval preceding said time interval. - the method further comprises assigning an end date to a time interval, said end date corresponding to the latest date of the fragments allocated on said time interval in all of said scheduling plans

[0022] Another object of the invention relates to a computer adapted to use the scheduling plans produced by the method described above. In particular, this object relates to a multitasking computer having a set of cores and adapted to execute a real-time operating system adapted to execute tasks according to a set of scheduling plans determined by a method as described above.

[0023] Another object of the invention relates to a vehicle comprising at least one such multitask computer.

[0024] Another object of the invention relates to a computer program comprising instructions for implementing a method as previously described when it is executed by a processor of a configuration device.

[0025] Another object of the invention relates to configuration equipment comprising at least one processor and circuits adapted to implement the method as previously described in the form of a scheduling tool.

[0026] Other characteristics and advantages of the invention will appear on reading the following description of a preferred embodiment of the invention, given by way of example and with reference to the appended drawings.

[0027] BRIEF DESCRIPTION OF THE FIGURES

[0028] The accompanying drawings illustrate the invention: [FIG. 1A] and [FIG. 1B] schematically represent a multi-core multitasking computer. [FIG. 2] schematically illustrates a context for deploying a method according to one embodiment. [FIG. 3] schematically represents a simplified flowchart of a method according to one embodiment. [FIG. 4] illustrates an example of initialization of a scheduling plan skeleton, according to one embodiment. [FIG. 5] represents an example of application on a set of 4 tasks of a method according to one embodiment. [FIG. 6A] to [FIG. 6C] illustrate a mechanism for assigning a start date to a fragment according to one embodiment. [FIG. 7A] and [FIG. 7B] illustrate an example of two scheduling plans, without and with assignment of an end date to the time intervals, according to one embodiment. [FIG. 8A] to [FIG. 8D] illustrate another example of the process according to one embodiment.

[0029] DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

[0030] FIG. 1A illustrates a schematic and high-level view of a set of tasks, or agents, A deployed on a multi-core multitasking computer 30. In the figure, tasks A1, A2... A n are represented.

[0031] The computer 30 may comprise hardware components, such as one or more processors, and associated circuits (in particular RAM-type memories, interface circuits, etc.).

[0032] An intermediate layer includes a real-time operating system (RTOS). Such an operating system is able to manage the launch of different tasks and their preemption according to a rate determined, statically, by a provided scheduling plan.

[0033] This multi-core multitasking computer can be embedded in any system requiring in particular a need for a guaranteed timing of the execution of different tasks, for example for reasons of security or operational safety. It may in particular be a mobile vehicle whose electronic equipment must meet such constraints in order to guarantee that its operation is in accordance with an expected operation and in particular that its direction does not constitute a danger either for itself and its passengers or for other goods or people around it. This mobile system may for example be an aerial vehicle, such as an airplane. It may also be an unmanned vehicle, or drone (or UAS for "Unmaned Aircraft System" or UAV for "Unmaned Aircraft Vehicle" in English).

[0034] The method described can be applied to on-board computers in a critical avionics context, but also to any system that must comply with real-time constraints with an emphasis on operational safety (e.g. civil nuclear, railway, industrial automation, aerospace, etc.).

[0035] FIG. 1 B represents a functional view of a multi-core multitasking computer on which a set of tasks A scheduled according to the proposed method is likely to be deployed.

[0036] This view aims to illustrate the different resources of the computer that this set of tasks can access. Typically by means of a logical bus (referenced BUS in the figure), the agents A can access resources such as one (or more) MEM memories. These memories can be memories of the “random access memory” or RAM type, and mass memories of the “hard disk” type, as examples. Other resources can be INT interfaces with other equipment, typically network interfaces. Other resources can also be embedded in a computer 30 and these examples are only illustrative. Furthermore, other TSK tasks than those managed within the framework of the proposed method can also be deployed and access, concurrently, the resources of the multicore computer 30.

[0037] As mentioned previously, one challenge is to define a schedule for the different A tasks so that they can all (if possible) be executed according to their time constraints.

[0038] In general, these tasks are recurring, that is, they must be repeated over time.

[0039] In an aerial vehicle, for example, these different tasks may represent functions of different on-board equipment, which must be executed continuously while the vehicle is in operation.

[0040] For example, functions for controlling the trajectory, altitude, and various vehicle sensors must be continuously in operation, i.e. they must perform processing according to a specific time constraint (for example, providing a value every n milliseconds).

[0041] Also, scheduling can also be repetitive: it therefore concerns one or more time windows planned to be repeated continuously over time.

[0042] Furthermore, some processes are dependent on other processes, for example because they need a value from that other process in order to generate their own outputs. Failure to respect a time constraint of a task can therefore impact other tasks with which it is in a precedence relationship.

[0043] Furthermore, concurrent management of tasks to the same resources of the computer 30 is necessary to prevent two tasks from blocking or, more commonly, their processing times from being extended by these concurrent accesses beyond the time constraints associated with them. This phenomenon is subsequently called interference.

[0044] It could be considered not to take into account interferences at the level of the scheduling plan provided to the computer and to let the real-time operating system RTOS manage these aspects dynamically, during the execution (or "runtime") of the tasks. However, this way of doing things does not guarantee that at the time of the execution of the tasks the operating system is able to find a solution to order the tasks to be scheduled according to their temporal constraints and in order to avoid interferences. This type of solution can be acceptable in non-critical contexts where security is not paramount, that is to say where the set of temporal constraints are not strictly imperative but can be subject to a certain flexibility.

[0045] Therefore, it is proposed that the real-time operating system RTOS has a static scheduling plan, to ensure that the various constraints are respected. The definition of such a scheduling plan is essential to guarantee the safety of the system associated with the set of tasks A.

[0046] FIG. 2 diagrams a process for defining a set of tasks up to their implementation on a multi-core computer and a method for generating such a scheduling plan.

[0047] Firstly, multitasking applications 11 can be defined according to an appropriate design language and adapted to implementation on a real-time computer.

[0048] This language allows you to define the computer code that must be executed on the computer, as well as the various time constraints that this computer code must respect.

[0049] An example of such a language is the PsyC language defined by Asterios Technologies (formerly Krono-Safe) and adapted to produce files that can be used by the ASTERIOS™ RTK real-time platform mentioned above. This language is based on the C language and includes additional elements to manage real-time, parallelism and communications aspects.

[0050] In such an embodiment based on the ASTERIOS platform and the PsyC language, software applications are defined by agents. These agents are sequences of elementary actions.

[0051] Temporal constraints can be associated with these elementary actions and specified by the designer of a real-time application. They can be described by language (for example, the PsyC language) and include: - A wake-up call, - A deadline constraint, - An execution time constraint, - One or more precedent constraints.

[0052] Each elementary action can subsequently be considered as a task that we seek to schedule on a multi-core multitasking computer core.

[0053] As will be seen later, scheduling includes the allocation of available time of a computer core in the form of processing fragments, or frames (from the English "frame" usually used). A time division allowing the allocation of time fragments is for example described in the patent application WO 2010 / 043706, and is known under the terminology RSF for "Repetitive Sequence of Frames" in English (Repetitive sequence of time windows). The structure of an RSF is a series of intervals divided into a head part and a loop part, each interval being a possible container of a processing fragment of a task.

[0054] As has just been seen, each task (or elementary action) has a deadline constraint which corresponds to the moment at which it must imperatively have finished its processing.

[0055] The execution time constraint is the maximum time required for the task to execute. The difference between the execution time and the deadline is the time during which the task can be preempted (processors can then execute other concurrent tasks).

[0056] The precedence constraint indicates that the task requires one or more other tasks to be executed beforehand. In this case, this task cannot start before the completion of these tasks. In the case where these previous (or preceding) tasks have an execution split into several processing fragments, the completion date of the last frame must be considered.

[0057] Additionally, exclusion constraints can be defined to remove interference between tasks.

[0058] In other words, it is proposed to allow developers of real-time applications to mitigate interference between the different tasks from the design phase by means of exclusions between tasks. The proposed method makes it possible to take these specifications into account when determining a scheduling plan. By construction, interference will thus be avoided during the execution of the tasks on the target computer 30.

[0059] More specifically, according to one embodiment, the exclusion constraints between elementary actions of agents of an application written in PsyC language can be expressed through the PsyC language and a related configuration (for example in JSON). These exclusions are naturally carried over to the tasks to be scheduled corresponding to the elementary actions.

[0060] The PsyC language allows you to add identifiers for “advance” instructions, in the form @<MON IDENTIFIANT> advance ...

[0061] In the JSON configuration, we can use the identifiers of the "advance" instructions to define elementary actions, or scheduling tasks. An elementary action represents a fragment of code that executes between two successive "advance" instructions. Therefore, an elementary action is defined by the identifier of the starting "advance" instruction, the identifier of the ending "advance" instruction, and a unique name to identify it.

[0062] And the specification of exclusion constraints is also done in the JSON configuration, through the definition of exclusion groups. An exclusion group is a set of elementary actions that must not be executed simultaneously.

[0063] A compiler 10 may be provided to take as input the specifications of the tasks 11 constituting the applications in order to generate output files 12 which comprise both object codes intended to be executed on the multitask computer 30, and data intended to be used by a scheduling tool 20. This scheduling tool 20 is provided to generate a scheduling plan 13 from this data provided by the compiler 10.

[0064] This data 12 generated by the compiler may notably include a data structure representing temporal data relating to the compiled tasks.

[0065] In particular, from code 11, the compiler can generate a data structure providing temporal data including, for each task, or elementary action, a start date, possibly a termination date and the temporal constraints associated with this task. These temporal constraints can notably include deadline constraints, execution time constraints, precedent constraints, wake-up constraints and exclusion constraints.

[0066] According to one embodiment, a method is proposed for generating a scheduling plan 13 taking into account these different types of constraints, for each task (5 in the embodiment described).

[0067] According to an embodiment based on the ASTERIOS™ software suite, this temporal data can take the form of a graph called RATS for “Repetitive Agent Temporal Sequence” in English (or repetitive agent temporal sequence).

[0068] This graph essentially represents a partial scheduling plan for the task. It is a series of intervals that are divided into two parts: a head where the task is executed once, and a loop where the task is executed indefinitely.

[0069] Each of these two parts can be the subject of a part of a scheduling plan 13, the composition of which will provide the final scheduling plan submitted to the target calculator 30.

[0070] In each interval where the task is supposed to be executed, it is subject to the time constraints previously indicated.

[0071] The scheduling plan 13 generated by the scheduling tool 20 may consist of a set of sub-plans, each being associated with a core of the multi-core computer 30. The real-time operating system RTOS embedded in the computer 30 is adapted to orchestrate the executions of the tasks on each of the cores according to the associated sub-plan. In the following, each of these parts of the total plan will also be called, for simplification, “scheduling plan”.

[0072] FIG. 3 shows an illustrative flowchart of one embodiment of the method implemented by the scheduling tool 20.

[0073] In a step S1, for each core of the computer 30, the scheduling tool initializes a scheduling plan 13 subdivided into time intervals from time data 12 obtained for each task (or elementary action of an agent), 11 of the set planned to be deployed on this core.

[0074] This scheduling plan as initialized constitutes a skeleton. The subsequent steps will seek to assign fragments of task processing to the time intervals, in order to constitute the scheduling plan of the core considered.

[0075] This initialization can consist of subdividing an empty scheduling plan, that is to say a simple timeline, by determining milestones corresponding to the start and end dates of all the tasks assigned to the core considered. In other words, if we consider that each task is associated with a time interval bounded by a start date and an end date, the skeleton is formed by the time intervals bounded by two successive dates within this set of dates.

[0076] FIG.4 illustrates an example of initialization of such a skeleton 13 for a given core. In this example, 3 tasks, A, B, C are to be scheduled. The skeleton 13 is therefore based on the temporal data associated with these 3 tasks, that is to say: - For task A, a start date LAS and an end date tAF, - For task B, a start date tss and an end date tBF, - For task C, a start date tes and an end date tcF.

[0077] Each task can be represented by a time interval in the figure. Skeleton 13 consists of a subdivision of time intervals bounded by two successive dates from the set of dates considered: LAS, tAF, tss, tBF, tes, tcF. We thus obtain a skeleton formed from the sequence of intervals [tAs, tBs], [tBS, tes], [tes, tBF], [tBF, tAF], [tAF, tcF].

[0078] In a step S2, the different tasks to be scheduled on a given core are sorted in a given order. This sorting is advantageously carried out upstream of the loop which follows, according to the method of this implementation, in order to share this sorting processing, but according to other embodiments, one could envisage choosing a new task to be assigned to each iteration without carrying out this prior sorting.

[0079] This order can be global, that is to say for all the cores of the computer 30. Indeed, this order must in particular take into account the precedence relationships between tasks and this relationship is independent of the cores on which the tasks are deployed.

[0080] This precedence constraint can be taken into account as the first sorting criterion. A second sorting criterion can be the due date of the tasks.

[0081] Thus, the sorting algorithm orders the tasks according to the following rules: For each pair of tasks A, B, A is before B if and only if There is a precedent constraint where A precedes B, or If there is no precedence constraint where B precedes A and - The start date of task A is before the start date of task B, or, if these are equal, - The due date of task A is before the due date of task B, - If these dates are equal, the name of task A precedes the name of task B lexicographically.

[0082] This last condition is an example of providing a sorting rule that is deterministic in all cases. Obviously, other implementations are possible that achieve the same objective of determinism.

[0083] As illustrated in the flowchart of FIG. 3, subsequent steps are iterative, with each iteration considering one of the tasks to be scheduled.

[0084] A step S3 consists of selecting a task according to a given order, this order being able to come from the previous sorting step S2. This selection consists of starting from the first task according to this order then continuing to the following iterations according to this order.

[0085] This allocation of a task can be done by fragments, or frames (or "frames" in English) of processing. Each fragment is allocated to a time interval of the scheduling plan, independently of the other fragments of the same task. In other words, for a given task, its allocation is done fragment by fragment.

[0086] The allocation of fragments is subject to constraints including: - A timing constraint: all fragments must be allocated in intervals of the scheduling plan that begin after the task's start date, and end before its due date, - An execution time constraint: the sum of the durations of all fragments of a task must be equal to the execution time of the task (as indicated in the time data provided as input), - A precedence constraint: the first (temporally) fragment of a task must begin after the terminations of the last fragments of the tasks which are in a precedence relationship, - An exclusion constraint: fragments of the task must not overlap fragments of other tasks with which there are exclusion constraints.

[0087] Two preliminary calculation steps S4, S5 can be carried out preferentially before the iteration phase starting at step S6 and considering each time interval of the scheduling plan. As previously, this is a preferred embodiment allowing processing to be shared rather than carried out at each iteration, i.e. for each time interval to be considered. Other embodiments are however conceivable.

[0088] A step S4 aims to determine a time from which the time intervals can be considered to allocate fragments of the task. This time depends both on the start date of this task (which is provided by the time data associated with the task) and on the temporal precedent links. In other words, this time is determined, or calculated, by the latest date between the start date of the task and the completion dates of the tasks having a precedent relationship with it (these completion dates correspond to the completion dates of the last fragment of these tasks).

[0089] The task fragments can only be positioned, or allocated, from this point on.

[0090] A step S5 comprises determining a list of fragments corresponding to tasks having an exclusion relationship with the task being allocated.

[0091] Step S6 consists of selecting a time interval of the scheduling plan between the start date of the task and its due date. The intervals are selected iteratively in the time direction and starting with the interval beginning at the task start date.

[0092] In a step S7, a set of empty spaces within this time interval is determined which are not yet allocated to a task, and which begin after the start time calculated in step S4. This step amounts to calculating the intersection between these empty spaces and an interval beginning at the time calculated in step S4.

[0093] In a step S8, the overlaps with the fragments present in the exclusion list determined in step S5 are removed from this set.

[0094] In step S9, fragments are allocated to the task in the remaining empty spaces.

[0095] When a time interval is considered, step S10 determines whether all the fragments of the task have been allocated in the scheduling plan, before the task's due date. In other words, the sum of the durations of the different allocated fragments is compared to the execution time of the task, these having to be equal.

[0096] If yes, then a new task can be considered. We then move on to step S11.

[0097] Otherwise, two situations can occur: either there are still time intervals available in the scheduling plan before the task's due date. In this case, we loop back to step S6 to select a new time interval.

[0098] If, on the other hand, there are no more time slots before this deadline, this means that all the fragments constituting this task cannot be allocated. A scheduling plan cannot therefore be generated.

[0099] According to one embodiment, we then loop back to step S2 in order to carry out a new sorting of the tasks, after having checked whether all possible sortings have not already been tried (test S12).

[0100] In a step S11, it is determined whether a new task must be selected. If so, we loop back to step S3 to select a task according to a given order, determined in step S2. If not, the scheduling plan is finalized and can be transmitted, or provisioned, in the calculator, in step S13.

[0101] The loop linking step S10 to step S2 represents a backtracking mechanism. Indeed, the iterative phase S3-S11 of allocating tasks in the scheduling plan is dependent on the sorting phase, S2: depending on the order in which we seek to allocate the tasks in the scheduling plan, the result may be different, but above all we may or may not succeed in obtaining a scheduling plan.

[0102] Also, in case of failure (at step S10), we can consider another order in the tasks to be allocated.

[0103] According to one embodiment, a tree traversal is performed within the possible sorts. More precisely, a tree of possibilities can be traversed, and when a given sort (corresponding to a leaf of the tree) generates a failure, the tree is moved up to explore another branch. The method can here follow a classic tree exploration. A failure will be generated when all the branches of the tree have been explored without providing an ordering plan, during the test step S12 (in the figure, this situation corresponds to the arrow coming out of step S12 to the left).

[0104] FIG. 5 illustrates an example of application of the proposed method on an initial set of 3 tasks, A, B, C to be scheduled on a computer with two cores. A fourth task, D, will then be added.

[0105] It is assumed that - tasks A and B are assigned to a first core, and task C is assigned to a second core, - task C has a start date of 0 and a due date of 10. - task C has an execution time equal to 5, - task C has a precedence relationship with task A and must wait for its completion. - Task C has an exclusion constraint with task B.

[0106] It is assumed that tasks A and B have already been allocated on the RSF1 scheduling plan corresponding to the first core.

[0107] Step S3 therefore consists of selecting the last task, C.

[0108] Step S4 of the algorithm consists of calculating an instant by searching for the latest of the dates among the start date of this task (here 0) and the completion dates of the tasks having a precedent over this task, here task A which ends in 3. This instant is therefore worth 3.

[0109] Step S5 consists of determining the list of excluded fragments.

[0110] For simplicity, let's identify the frames by their boundaries. For this example, this list is composed of a single element: [5, 7] (which corresponds to task B).

[0111] The following steps correspond to looping over time intervals.

[0112] In this example, there is only one interval in which task C can execute, which is the interval [0, 10].

[0113] Since no fragments are yet allocated in this range, the empty space where the task can run is [0, 10].

[0114] In step S7, the intersection of this interval [0, 10] with the interval [3, 10] is calculated. The result is [3, 10].

[0115] In step S8, we remove overlaps with the intervals in the exclusion list. This splits our empty space into two subspaces: [3, 5] and [7, 10].

[0116] In step S9, fragments can be allocated for task C in these two intervals while respecting its constraints.

[0117] We check in step S10 that the sum of the durations of these two fragments is equal to the execution time of task C, we can stop here (steps S11 and S13).

[0118] If another task D were to be scheduled on the first core, a fragment could for example be allocated to it on the interval [3, 10] provided that it has no exclusion constraints with task C (which runs on the same interval as it), that it has a start date not earlier than time 3 and that it has no precedence constraint with any other task, except possibly task A.

[0119] According to one embodiment, the allocated fragments can be assigned a start date within the scheduling plan. This information allows, and requires, the real-time operating system, RTOS, to start the execution of this processing fragment on this date, even if the core concerned is available earlier. It therefore prohibits certain dynamic operations of the real-time operating system.

[0120] This start date is a function of the start date of the time interval in which the fragment is allocated. This date can typically correspond to the start date of the time interval.

[0121] Indeed, some real-time operating systems may have dynamic orchestration features that allow the startup of a fragment to be anticipated.

[0122] Indeed, the processing of a task can execute faster than the execution time expected in the temporal data, which represents a worst case. Therefore, a fragment allocated in the scheduling plan can finish before the end date of the time interval in which it was allocated. The operating system can then plan to start the allocated fragment in the next time interval, in anticipation. This functionality seems interesting in certain situations, since it allows overall faster processing and frees up flexibility for the rest of the scheduling plan.

[0123] However, this anticipation can be harmful in certain situations, particularly in the case where the anticipated fragment overlaps fragments allocated on other cores of the computer with which exclusion constraints exist.

[0124] It can therefore be planned to assign a start date to a fragment if (and in particular only if) this fragment would not overlap of a fragment of another task with which there is an exclusion constraint on the time interval preceding the expected time interval.

[0125] FIG. 6A illustrates an example of a situation in which the mechanism for assigning a start date to a fragment can be implemented.

[0126] In this example, we assume that tasks B and C have an exclusion constraint. Task B was allocated to a time interval [3; 5], following a first time interval [0; 3] to which a task A was allocated. The duration of this interval [0; 3] could be determined during the construction of the skeleton of the RSF1 scheduling plan based on an expected execution duration for task A.

[0127] As illustrated in FIG. 6B, it turns out that the processing of task A is shorter than expected. In the illustrated situation, no mechanism for assigning a start date is put in place: the operating system then anticipates the start of the fragment corresponding to task B in order to benefit from the freed machine time. It then follows that the execution of this task B can cause interference (concurrent access to shared resources) with task C, which can minimally disrupt the operation of these two tasks. The exclusion constraint between two tasks planned by the generation of the scheduling plans becomes inoperative due to the dynamic anticipation carried out by the RTOS operating system (thus no longer strictly following these scheduling plans RSF1, RSF2).

[0128] In the situation illustrated in FIG. 6C, a start date has been assigned to the fragment of task C, which corresponds to the start date of the time interval to which it was allocated (i.e., the value 5). In this case, the RTOS operating system does not anticipate the start of this fragment but waits for the indicated date before starting its execution.

[0129] As seen previously, it is possible for the developer of a real-time application to define exclusions between tasks, in order to avoid or mitigate interference. This mechanism of assigning a start date for the fragments, determined automatically by the scheduling tool 20, makes it possible to guarantee compliance with these exclusions even in the case where the system RTOS operating system would perform dynamic orchestrations during task execution.

[0130] Furthermore, according to one embodiment of the invention, each time interval of a scheduling plan can be assigned a date from which a background task can be executed.

[0131] By definition, a background task, unlike a task (of the real-time application), is not statically scheduled in the scheduling plan. It is dynamically scheduled and executed in the time left available within a scheduling time interval, after the execution of critical real-time tasks.

[0132] The execution of these background tasks must not generate temporal interference on other cores, and therefore jeopardize the temporal partitioning of an application.

[0133] In order to avoid these interferences between tasks and background tasks, the exclusion mechanism previously described is extended to background tasks.

[0134] More precisely, the scheduling tool 20 is adapted to assign an end date to at least the time intervals concerned, this end date corresponding to the latest date of the fragments allocated on the time interval in all the scheduling plans (i.e. on all the cores of the computer 30).

[0135] This end date delimits the time interval into a first part reserved for real-time tasks, and a second part in which background tasks can be executed (because they can no longer cause interference with other tasks from other cores).

[0136] FIG. 7A and FIG. 7B illustrate an example of two scheduling plans, without and with assignment of an end date to the time intervals.

[0137] In this example, it is assumed that background tasks D can generate interference with task B. It is assumed that the scheduling plans are subdivided into three time intervals [0; 3], [3; 8] and [8; 10].

[0138] In FIG. 7A, within the RSF2 scheduling plan relating to the second core of the computer, the first time interval is allocated to a task C. The second time interval not being allocated to a task, the RTOS operating system triggers the execution of background tasks, likely to generate interference with task B, allocated to this same time interval on the RSF1 scheduling plan associated with the first core of the computer.

[0139] In FIG. 7B, an end date is assigned to this second interval. This end date has as its value the termination date of the different fragments allocated on all the scheduling plans. In this example, only one fragment is allocated in this time interval: that of task B. The end date for this interval therefore takes as its value its termination date, and the RTOS operating system uses this end date to trigger the execution of background tasks D.

[0140] The above description is based on time to manage the orchestration of task execution triggers (time triggered approach).

[0141] However, instead of managing mutual exclusion by the flow of time, it would be possible to rely on explicit synchronization mechanisms, such as mutexes (for "mutual exclusion") or semaphores. Note that a "time-triggered" approach is generally more favorable to "event-triggered" approaches when safety is a priority. This variation remains particularly interesting because it is fully tooled: it allows the automation of the use of primitives that an operating system makes available to users, but without offering any guarantee. Here, our alternative approach would allow a safe use of these primitives, which otherwise must be manually verified by application developers.

[0142] FIGS. 8A to FIG. 8D illustrate another example of the flow of the described method.

[0143] FIG. 8A illustrates, in the form of a timing diagram, the time data of three tasks, A, B, C.

[0144] We further assume the following constraints: - An exclusion constraint between tasks A and B. - An exclusion constraint between tasks B and C. - Task A is allocated to core 1 (associated with a scheduling plan RSF1) - Task B is allocated to core 2 (associated with an RSF2 scheduling plan). - Task C is allocated to core 3 (associated with an RSF3 scheduling plan).

[0145] The first step, S1, consists of, for each core, initializing a scheduling plan per core, respectively RSF1, RSF2, RSF3, subdivided into time intervals from the time data of the tasks planned for this core.

[0146] In this example, since each task is implemented on a different core, the scheduling plans of the three cores have the same intervals as those of the tasks.

[0147] Step S2 of sorting tasks can be done on the basis of their completion dates (no precedence being indicated), i.e. the order A, B, C.

[0148] As illustrated in FIG. 8B, we therefore begin to allocate task A, then task B. When trying to allocate task C, we detect an impossibility since the available time interval is shorter than the execution time of this task C.

[0149] A backtracking mechanism is then implemented, going up the possibility tree. The branch corresponding to the initial sort ABC is eliminated, and the immediately neighboring branch (topologically in the tree) is selected: ACB.

[0150] As illustrated in FIG. 8C, we therefore allocate task A first. Then task C, having an exclusion constraint with task C, is allocated to its continuation in the time direction. Task B can then no longer be allocated because there is no more empty space in its RSF2 scheduling plan.

[0151] The backtracking mechanism is used again to explore another branch of the tree. Starting from task A, all branches have been explored, so the exploration mechanism determines to start with the next task in the original order, i.e., task B. The first branch to be explored is then BAC.

[0152] As illustrated in FIG. 8D, we begin to allocate task B.

[0153] Then we allocate task A, which has an exclusion constraint with task B and is therefore allocated at the next time interval.

[0154] Then, we allocate task C. This also has an exclusion constraint with task B, but not with task A. The time interval following the completion of task B is therefore available for it. It is therefore allocated on this interval and executes in parallel with task A.

[0155] The three scheduling plans RSF1, RSF2, RSF3 obtained therefore form a valid solution.

[0156] The proposed method therefore addresses the problems initially exposed and presents numerous advantages compared to current state-of-the-art solutions.

[0157] In particular, it offers a means of mitigating temporal interference by calculating static scheduling plans for each of the execution cores, all of which guarantees temporal exclusion of access to hardware resources shared by the different processes hosted on separate cores. Unlike existing systems, it incorporates mutual exclusion constraints into this scheduling, allowing safe and systematic synchronization of tasks and the scheduler across all cores.

[0158] This process thus meets the objectives of document AMC20-193, applicable to critical digital aeronautical systems based on multi-core hardware components.

[0159] Furthermore, the proposed method also allows to reconcile the scheduling of real-time tasks with non-real-time tasks, while preserving the mutual exclusion constraints.

[0160] Another advantage is being able to mitigate these temporal interferences without necessarily modifying the tool (RTOS operating system) used to execute the tasks on the computer.

[0161] Of course, the present invention is not limited to the examples and the embodiment described and shown, but is defined by the claims. It is in particular susceptible of numerous variants accessible to those skilled in the art.

Claims

Claims

1. Method for scheduling a set of tasks on a multitask computer (30), comprising at least one processing core, said method comprising - for each core of said computer, initialize (S1) a scheduling plan (13) subdivided into time intervals from time data (12) obtained for each task (11) of said set provided for said core, - iteratively allocating (S3-S11) processing fragments for each task planned for said core in the respective scheduling plan, considering said tasks in an order dependent on temporal precedent links defined for said tasks, and respecting a set of constraints consisting of: (a) iteratively considering each time interval of said scheduling plan (13) not yet allocated to a task, (b) positioning said fragments in said scheduling plan at the earliest at a time determined from said temporal precedent links and a start date of said task defined by said temporal data, (c) not positioning said fragments in overlap with fragments of another task with which there is an exclusion constraint, among the set of scheduling plans, and determining (S10) whether all the processing fragments of said task are allocated in said scheduling plan (13) before a deadline associated with said task, defined by said time data - transmitting (S13) all of said scheduling plans (13) to said computer (30).

2. A method according to the preceding claim, wherein iteratively allocating processing fragments for each task provided for said core comprises steps of - calculation (S4) of said instant from said temporal precedent links, by searching for the latest of the dates among the start date of said task and the completion dates of the tasks having precedent over said task, - determination (S5) of a list of fragments corresponding to tasks having a precedence relationship with said task; - selection (S6) of a time interval of said scheduling plan (13), and, for said selected time interval, determination (S7) of empty spaces not yet allocated to a task, from said instant, deletion (S8) of the empty spaces associated with an exclusion constraint for said task, then allocation (S9) of remaining empty spaces to a fragment of said task.

3. Method according to the preceding claim, in which if (S10) the sum of the durations of the intervals allocated to said task is less than the execution time associated with said task and no interval not yet allocated is available before a deadline associated with said task, then the allocations of said task are deleted and an attempt is made to allocate another task.

4. Method according to the preceding claim, comprising a step (S2) of sorting the tasks of said set of tasks, and a step (S3) of selecting a task according to said sorting, and in which trying to allocate another task comprises a new sorting (S2) of said tasks, after having checked (S12) whether all possible sorts have not been tried.

5. A method according to the preceding claim, wherein attempting to allocate another task comprises a tree traversal within said possible sorts.

6. Method according to one of claims 2 to 5, comprising, when allocating a processing fragment, an assignment to said fragment of a start date within said scheduling plan as a function of the start date of said selected time interval.

7. Method according to the preceding claim in which said start date is assigned to a fragment only if said fragment would not overlap a fragment of another task with which there is an exclusion constraint on the time interval preceding said selected time interval.

8. Method according to one of the preceding claims comprising an assignment of an end date to a time interval, said end date corresponding to the latest date of the fragments allocated on said time interval in all of said scheduling plans.

9. Computer program comprising instructions for implementing a method according to one of the preceding claims when it is executed by a processor of a configuration device.

10. Configuration equipment comprising at least one processor and circuits adapted to implement the method according to one of claims 1 to 8, in the form of a scheduling tool (20).

11. A multitasking computer having a set of cores and adapted to execute a real-time operating system adapted to execute tasks according to a set of plans scheduling determined by a method according to one of claims 1 to 8.

12. Vehicle comprising at least one multitask computer according to the preceding claim.

Images