Two-level static scheduling of a set of real-time tasks for a multi-core multitasking computer

Abstract

Method for scheduling a set of tasks, belonging to a partition, on a multitask computer (30) comprising at least one processing core, said method comprising a determination (S2), for each task, of a temporal modeling constrained by a scheduling of said partition within a time line, then a determination (S3) of a static scheduling of said tasks within said time line from said temporal models and temporal constraints associated with each task. Figure for the abstract: Fig. 6

Description

Title of the invention: Two-level static scheduling of a set of real-time tasks for a multi-core multitask computer FIELD OF THE INVENTION

[0001] The present invention relates to real-time multitasking 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.

[0002] 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.)

[0003] Many specialized industries such as avionics, railways, automobiles or civil nuclear power have the mission of designing and developing such systems, governed by strict standards and norms, which ensure proper compliance with operational safety constraints, such as ISO 26262, IEC 60880 or DO-178C.

[0004] In the specific field of avionics, the DO-178C standard published by the RTCA (for "Radio Technical Commission for Aeronautics" in English) and imposed by numerous regulatory bodies such as the FAA or the EASA, specifies requirements for on-board software systems.

[0005] Systems of this magnitude are often developed according to an industrial "V" or spiral cycle scheme. The manufacturer holds the roadmap that divides the final system into multiple components, for which entities, sometimes multiple, are responsible for their delivery. The real-time safety subsystems are divided into software bricks — or partitions — whose consistency is ensured by an "integrator" entity. This entity carries out a temporal design of its system upstream, which can be amended downstream, as integration progresses. It is combined with a segregation watertight or porous hardware resources (eg address space, inputs / outputs) between partitions.

[0006] In particular, this way of doing things makes it possible to integrate real-time applications developed by separate entities ("application suppliers" in English, or application providers) within separate partitions, then by grouping them together in a final integration phase (by a "System integrator" in English, or system integrator).

[0007] In civil avionics, the IMA (“Integrated Modular Avionics”) concept was defined by the DO-297 standard, and makes it possible to design a shared infrastructure (a computer) for a plurality of real-time processing operations, which were previously provided in as many discrete vertical devices. This infrastructure, or platform, is provided by a platform provider. The integrator deploys the applications (developed by application providers) there, so as to produce a self-supporting computer performing its functions. In such a framework, it is understood that each processing operation (or application) can be associated with time constraints inherent to its function (providing a measurement every x milliseconds, for example, for a sensor, etc.)

[0008] Systems claiming to fulfill such an IMA function must comply with the DO-297 standard (or construct an equivalent demonstration of compliance), and possibly follow additional recommendations (e.g. EASA AMC 20-170). An essential property of IMA platforms is to guarantee that partitions developed in total independence from each other behave identically once shared on the platform.

[0009] This property is particularly complex to implement and guarantee. The guarantees of interoperability between components and of development in total independence allowing the conservation of certification credits make the incremental certification capacity an important indicator of industrial performance.

[0010] To achieve such properties, IMA systems are built around a two-level hierarchical scheduling pattern (as specified in ARINC-653): the first, static, written by the integrator, expresses the temporal constraints applied to the partitions (therefore, to the interoperable components). A second-level scheduling, local to the partitions (therefore specific to each application provider), is expressed within these first-level temporal constraints.

[0011] Defining the nature of these scheduling plans is crucial for the smooth running and industrial performance of IMA systems. Second-level scheduling plans can be static or dynamic in nature. A static approach is desirable for critical systems, because it carries interesting properties which are difficult to demonstrate with a dynamic approach.

[0012] Implementing a static scheduling duplicate is particularly difficult, and hides significant maintenance costs.

[0013] Furthermore, due to the multiplicity of stakeholders, it is complex to establish a global scheduling plan which responds to all the issues.

[0014] There is therefore a need for a method which makes it possible to automatically construct a scheduling plan which meets both the integrator's constraints linked to standards and other security requirements, particularly in an avionics context, and the constraints specific to each software application.

[0015] An aim of the invention is therefore to improve the current proposals of the state of the art which do not allow the development and validation of a partition associated with a real-time application to be managed in a satisfactory manner, with a view to its integration into a multi-partition scheduling plan.

[0016] . Summary of the invention

[0017] The invention aims to automate at least in part

[0018] For these purposes, according to a first aspect, the present invention can be implemented by a method for scheduling a set of tasks, belonging to a partition, on a multitask computer comprising at least one processing core, said method comprising a determination, for each task, of a temporal modeling constrained by a scheduling of said partition within a time line, then a determination of a static scheduling of said tasks within said time line from said temporal models and temporal constraints associated with each task.

[0019] Thus, the proposed method makes it possible to keep the time constraints of the tasks (therefore of the software applications) separate from the high-level time constraints set by the integrator.

[0020] In other words, this involves enabling the entity responsible for developing an application intended for a modular integrated avionics system, IMA, to determine as soon as possible whether its application complies with the scheduling parameters imposed by the platform, and therefore is compatible with the operations of the other applications which will also be deployed on the same IMA system (i.e. on the same multi-core multitasking computer).

[0021] According to preferred embodiments, the invention comprises one or more of the following features which can be used separately or in partial combination with each other or in total combination with each other: - said timeline is provided in the form of a data structure specifying a division of time into time intervals, each time interval being individually assignable to a single partition. - the method further comprises a preliminary phase of ordering said partition within said timeline, itself comprising a specialization of said timeline to said partition, a resetting of said timeline, then a merging of the empty time intervals. - said temporal model is a temporal state graph, and said determining comprises creating a first temporal state graph, then iteratively modifying said first temporal state graph using said ordering of said partition within said timeline. - said iterative modification comprises a fragmentation of an arc of said time state graph if said arc is not totally included in an interval of said ordering of said partition within a time line.

[0022] Another object of the invention relates to a computer adapted to use the scheduling plans produced by the method previously described. 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 previously described.

[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 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 of circuits adapted to implement the method as described, in the form of a scheduling tool (20).

[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. BRIEF DESCRIPTION OF THE FIGURES

[0027] The attached drawings illustrate the invention:

[0028] [Fig.lA] and [Fig.lB] schematically represent a multi-core multitasking computer.

[0029] [Fig.2] schematically illustrates a context in which the proposed method is inserted, according to one embodiment.

[0030] [Fig.3A] to [Fig.3D] represent an example of a scheduling plan.

[0031] [Fig.4] illustrates an example of a timeline according to one embodiment.

[0032] [Fig.5A] to [Fig.5D] illustrate the progress of certain steps of the method described on an example timeline for a given partition.

[0033] [Fig.6] represents a flowchart of a method according to one embodiment.

[0034] [Fig.7] represents a graph of temporal states according to one embodiment.

[0035] [Fig.8] illustrates an example of application of a fragmentation step according to a embodiment of the proposed method.

[0036] [Fig.9] illustrates an example of a possible result at the end of a phase of determining a temporal model according to an embodiment of the proposed method.

[0037] [Fig.10A] to [Fig.10D] illustrate another example of application of the proposed method.

[0038] [Fig.l 1A] and [Fig.l 1B] illustrate examples for a step of linearization of the temporal models of the tasks.

[0039] DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

[0040] [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 Al, A2... An are represented.

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

[0042] An intermediate layer comprises a real-time operating system RTOS (for "Real-Time Operating System" in English). Such an operating system is capable of managing the launch of the different tasks and their preemption according to a rate determined, statically, by a scheduling plan provided.

[0043] An example of such an orchestration tool may be the ASTERIOS™ RTK tool which makes it possible to execute a set of real-time tasks on a multi-core computer in accordance with a scheduling plan, for example provided by another tool in the tool chain (ASTERIOS™ Developer).

[0044] This multi-core multitasking computer can be embedded in any system requiring in particular a need for 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 complies with an expected operation and in particular that its direction does not constitute a danger or for itself and its passengers nor for other goods or people around it. This mobile system can for example be an aerial vehicle, such as an airplane. It can also be an unmanned vehicle, or drone (or UAV for "Unmaned Aircraft Vehicle" in English, or UAS for "Unmaned Aircraft System").

[0045] 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.).

[0046] [Fig.lB] 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.

[0047] 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 multi-core computer 30.

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

[0049] In general, these tasks are recurring, that is to say they must be repeated over time according to a repetition constraint.

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

[0051] For example, functions for controlling the trajectory, the altitude, the various sensors of the vehicle must be continuously in operation, that is to say they must execute processing according to a specific time constraint (for example providing a value every n milliseconds).

[0052] Also, the scheduling can also be repetitive: it therefore concerns a time window planned to be repeated continuously over time.

[0053] Furthermore, some treatments are dependent on other treatments, for example because they need a value from this other treatment in order to generate their own output. Failure to comply with a time constraint of a task can therefore impact other tasks with which it is in a relationship of precedence.

[0054] 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 called interference hereinafter.

[0055] It could be envisaged 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, or real-time kernel, RTK (for "Real-Time Kernel" in English), 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 time constraints and in order to avoid interferences. This type of solution may be acceptable in non-critical contexts where security is not essential, that is to say where all the time constraints are not strictly imperative but can be subject to a certain flexibility.

[0056] Also, it is proposed that the real-time operating system RTOS, or the real-time kernel, RTK, has a static scheduling plan, making it possible to guarantee 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.

[0057] [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.

[0058] Firstly, multitasking applications 11 can be defined according to a design language suitable for implementation on a real-time computer.

[0059] This language makes it possible to define the computer code which must be executed on the computer, as well as the various time constraints which this computer code must respect.

[0060] An example of such a language may be the PsyC language defined by the company 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 for managing aspects related to real-time. In particular, it allows the declaration of real-time tasks, the definition of communication channels between several tasks and allows to associate temporal constraints with the imperative declarations of the C language.

[0061] It was first presented in the article by Vincent David, Jean Delcoigne, Evelyne Leret, Alain Ourghanlian, Philippe Hilsenkopf and Philippe Paris. "Safety properties ensured by the OASIS model for safety critical real-time Systems" in: Computer Safety, Reliability and Security, 17th International Conference, SAFECOMP'98. T. 1516. Lecture Notes in computer Science. Springer. Heidelberg, Germany: Springer, 1998, pp. 45-59. doi: 10.1007 / 3-540-49646-7_4.

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

[0063] Time 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, A precedence constraint.

[0064] Each elementary action can subsequently be considered as being a task that one seeks to schedule on a multi-core multitask computer core.

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

[0066] The execution time constraint corresponds to the time required for the task to execute. The difference between the execution time and the deadline corresponds to a time during which the task can be interrupted (the processors can then execute other concurrent tasks).

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

[0068] In addition, exclusion constraints can be defined in order to mitigate, or even eliminate, interference between tasks. In other words, it is proposed to allow developers of real-time applications to define and specify 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 for the determination of a scheduling plan. By construction, interference will thus be avoided during the execution of tasks on the target computer 30.

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

[0070] Advance instructions allow the declaration of synchronization constraints, setting the deadline for instructions preceding them and determining the earliest start dates for those following them. An annotation mechanism, prefixed by "@", allows an advance instruction to be named.

[0071] Further information can be found in Jean Guyomarc'h's thesis, “Analysis of real-time safety systems and mitigation of their temporal interference”, http: / / www.theses.fr / 2021UPASG070, October 2021.

[0072] In the JSON configuration, we can use the identifiers of the "advance" instructions to define elementary actions. 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.

[0073] 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.

[0074] 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.

[0075] This data 12 generated by the compiler may in particular comprise a data structure representing temporal data relating to the compiled tasks.

[0076] In particular, from code 11, the compiler can provide a data structure providing temporal data comprising, for each task (or elementary action of an agent), 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 and exclusion constraints.

[0077] According to an embodiment based on the ASTERIOS™ software suite developed by the company Asterios Technologies (formerly Krono-Safe), this data Temporal sequences can take the form of a graph called RATS for “Repetitive Agent Temporal Sequence” in English (or repetitive agent temporal sequence).

[0078] 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.

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

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

[0081] 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”.

[0082] This scheduling plan can then be transmitted, or provisioned, in the multi-core computer 30. The real-time operating system equipped with R-TOS can then use this scheduling plan to orchestrate the execution of the various installed tasks.

[0083] The proposed method therefore aims to determine a scheduling plan, for each core of the computer 30 which respects both the temporal data (in particular temporal constraints, as mentioned previously) of each task and the first level scheduling plan of the partitions defined by the platform.

[0084] As a reminder, a partition is made up of a set of real-time tasks with their own specific timing; these timings are ultimately used to implement a time-triggered execution (triggered, or controlled, by time) of these tasks. A partition can generally be likened to a real-time application. From an industrial point of view, each partition can be assigned to an entity (a subcontractor), an application provider, in charge of developing an application. Partitions make it possible to isolate each application from each other, and for each application provider to determine a local schedule for this partition based on the time constraints of the tasks in its application. However, as we have seen, the challenge is to reconcile these "local" scheduling plans for all the partitions for deployment on the same computer.

[0085] Creating a second-level static scheduling plan requires constructing the temporal behavior of tasks based on the topology of the first-level scheduling plan.

[0086] According to the state of the art, manual construction of the scheduling plan necessarily involves micro-design: the implementation of the temporal behavior of the tasks of a partition will be over-constrained by the first-level static scheduling plan. There is currently no tooled solution to automate their generation, and therefore relieve partition developers of these issues.

[0087] [Fig.3A] to [Fig.3D] represent an example of a scheduling plan illustrating the problem of a two-level scheduling.

[0088] [Fig.3A] shows a first-level static scheduling plan, within which two partitions, PI and P2, are executed.

[0089] Typically, such a scheduling plan comprises a first part called “head” executed only once (here from date 0 to date 1) and a second part, called “loop” which is executed repetitively (here, from date 1 to date 9).

[0090] The high-level time specification determined by the integrator is: "partition PI has an execution duration of 2, and an execution frequency of 8". A possible reading of the static scheduling plan for PI is: PI executes from date 3, for a duration of 2. After finishing, PI resumes its execution after 6 time units. We are therefore in compliance with the specification.

[0091] Partition P2 corresponds to an execution duration of 1 time unit and an execution frequency of 8 time units.

[0092] If we focus on this PI partition, the entity in charge of its development has, in principle, only to concentrate on how to implement its functionality.

[0093] In this example, we assume a task T1 that executes with a period of 8 time units, for a total duration of 1.5 time units. Note that these time specifications are the responsibility of the entity (application developer) in charge of the partition PI, and that they are formulated here in complete independence from the first-level scheduling plan.

[0094] According to the state of the art, the use of dynamic scheduling within the PI partition allows the developer of this PI partition to effectively ignore the first level. But it remains difficult to provide proof of compliance with time constraints, which is problematic in a critical environment.

[0095] On the other hand, to construct a static scheduling plan, the developer of the PI partition must now know precisely the topology of the scheduling plan chosen by the integrator (illustrated in [Fig.3A]).

[0096] [Fig.3B] shows an example of a static scheduling plan that the PI partition developer must write manually.

[0097] It is assumed that the integrator then chooses to modify, not its high-level time requirements but its first-level scheduling plan, for example as illustrated by [Fig.3C].

[0098] This new first-level scheduling plan is still perfectly compatible with the previously indicated high-level time constraints: the PI partition has a total execution time of 2 and a periodic execution pattern of 8. For the integrator, this modification is therefore minor and does not call into question a contract established with the developer of the PI partition since the negotiated high-level time constraints are not impacted.

[0099] However, it is noted that the second-level scheduling plan initially proposed by the developer of the PI partition is completely invalid since his proposal is incompatible with the new first-level scheduling plan. Indeed, the allocation of an interval of 1.5 time units for the task T1 is no longer compatible with the two intervals corresponding to the PI partition, each with a duration of 1 time unit.

[0100] However, it does respect the high-level temporal specification. On the other hand, we can clearly see that complying with the topology of the first-level scheduling plan imposes additional constraints on the development of PI, which can be costly to take into account.

[0101] As an example, [Fig.3D] illustrates a second-level scheduling plan of the PI partition compatible with this new first-level plan.

[0102] This new division required a preemption of task T1. In other words, this task was subdivided into two executable sections, each allocated over one of the two time intervals assigned to partition PI.

[0103] Indeed, in addition to the need to write this new second-level scheduling plan, it is also the behavior of task T1 that must be segmented to execute twice. In a dynamic approach, this segmentation is done at runtime without knowing its position in the code in advance. Conversely, with static scheduling, it must be done specifically. We then speak of micro-design, which is an over-specification of the initial need due to low-level constraints (here the first-level execution plan). This therefore requires additional intervention from the application developer who must redefine the design of his application (or even partially redevelop it in order to adapt it to his new time constraints).

[0104] Due to this micro-design requiring a substantial modification of the application, a new certification of the application is necessary (according to the usual requirements for critical systems such as avionics systems). The objective of incremental certification is then called into question.

[0105] It appears to the inventors that if with a single task, such a modification remains tractable, dealing with several dozen tasks which can be aperiodic, with heterogeneous cadence and latency constraints, preemptible or non-preemptible, with precedent constraints and possibly mutual exclusion constraints, makes the operation particularly laborious without tool assistance.

[0106] It therefore appears crucial to be able to propose a mechanism for automatically generating scheduling plans that are compatible with these different levels of constraints.

[0107] In particular, a method is proposed for abstracting the temporal design of applications from the temporal constraints of the first-level scheduling plan defined by the integrator. Thus, a change in the latter no longer has an impact on the applications as defined by their code in PsyC (for example).

[0108] Verification of the temporal and spatial consistency of an IMA system is carried out during V&V phases during system integration. They require on-target testing, possibly on test benches. Being able to detect well in advance a violation of the temporal and spatial contracts between partitions and the integrator would make it possible to advantageously reduce integration costs, an error being all the less costly the earlier it is detected in the "V cycle".

[0109] The proposed method, by ricochet, allows the integrator to benefit from means of automatic verification of the proper respect of the partitions with respect to the contracts fixed with the partitions. In particular with regard to the time contract, it is possible to detect upstream whether each partition is in conformity with the first level scheduling plan.

[0110] This verification can result directly from the systematic analysis of the static scheduling plans at the first and second levels.

[0111] In the example illustrated by [Fig.3A] to [Fig.3D], if we assume that an atomicity constraint is attached to task T1 (i.e. that it cannot be divided in a scheduling plan), then the situation proposed in [Fig.3D] would violate this constraint.

[0112] Thanks to the proposed mechanism, this integration error can be detected very early in the integration process. This would not have been possible with dynamic scheduling at the second level, without performing an execution on a hardware target or on an emulator, but in any case much further downstream in the integration process.

[0113] According to one embodiment, initially, the integrator draws up the temporal (and spatial, if necessary) partitioning contract called a time line, or time line, or even “timeline” according to the usual English vocabulary.

[0114] These specifications can be provided in PsyC language. The PsyC language is a computer language defined by the company 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 for managing real-time aspects.

[0115] The PsyC 10 compiler can generate this timeline from these PsyC source files, which is intended to be transmitted to all the actors developing partitions. It is in this form that the temporal partitioning contracts are carried. Other contracts relating to other areas (spatial segregation, etc.) can also be added to these contracts.

[0116] The timeline may be provided as a data structure specifying a division of time into time intervals, each time interval being individually assignable to a single partition.

[0117] A timeline can be provided for a given core of the target computer. The time available on a core can thus be divided into time windows, each of which can be dedicated to a partition.

[0118] A possible grammar for describing a timeline in a dialect of the PsyC language might be:

[0119] timeline_decl

[0120] : “timeline” “identify”

[0121] '(' timeline_parameter_list ')'

[0122] '{'partition_decl_list

[0123] timeline_parameter

[0124] : “uses” “identifier”

[0125] I “defaultclock” “identify”

[0126] I “starttime” expr_long opt_with_clock_def

[0127] I " period " duration_expr

[0128] I " period " expr_long

[0129] timeline_parameter_list

[0130] : timeline_parameter

[0131] I timeline_parameter timeline_parameter_list

[0132] partition_decl

[0133] : " partition " " identifier " partition_parameter_list

[0134] partition_parameter_list

[0135] : partition_parameter_list partition_parameter

[0136] I partition_parameter

[0137] thneslot_decl

[0138] : " timeslot " " identifier " timeslot_parameter_list

[0139] timeslot_offset_parameter

[0140] : " offset " duration_expr

[0141] I " offset " expr_long

[0142] time slot_duration_parameter

[0143] : " duration " duration_expr

[0144] I " duration " expr_long

[0145] timeslot_parameter_list

[0146] : timeslot_offset_parameter timeslot_duration_parameter

[0147] I timeslot_duration_parameter timeslot_offset_parameter

[0148] partition_parameter

[0149] : timeslot_decl

[0150] partition_decl_list

[0151] : partition_decl_list partition_decl

[0152] I partition_decl

[0153] Of course, this is just one example, and many variations of this grammar are possible. Similarly, other formalisms can be used to describe a timeline, whether using the PsyC language or other equivalent languages.

[0154] [Fig.4] illustrates an example of a timeline.

[0155] This timeline corresponds to the following PsyC code, given according to the formalism defined by the grammar given previously:

[0156] source realtime_us ;

[0157] clock clk_ms = 1000 * realtime_ms;

[0158] timeline T (uses realtime_us, defaultclock clk_ms, starttime 1, period 8)

[0159] {

[0160] partition PI, timeslot a, offset 2, duration 2;

[0161] partition P2, timeslot b, offset 6, duration 1;

[0162] }

[0163] This code describes a timeline that is statically allocated to a core, via a declarative configuration system understood by the PsyC compiler.

[0164] The time line T is defined as having two time windows (called "timeslots"), a and b, which respectively host the tasks of the partitions PI and P2 configured to execute on the core mobilized by the time line T.

[0165] Topologically, each timeline consists of two parts: a "head" and a "loop". The loop consists of a repeating pattern starting at a particular date, set by the keyword "starttime" and of a length determined by the keyword "period" in the timeline header. Only the loop can execute the partition code.

[0166] In all the figures illustrating the Description, the loop is illustrated by an arrow starting from the end of the timeline and looping back to the beginning of this part. The head is therefore defined by the part between the beginning of the timeline and the milestone where this arrow ends, that is to say at the beginning of the loop.

[0167] Thus, in this example, the partition PI is scheduled in an interval [3; 5] of the time line, and the partition P2 is scheduled in an interval [7; 8] of this time line T.

[0168] According to one embodiment, the different PsyC files describing the timelines of the cores are compiled into a single file, which acts as a formalized temporal contract. To this contract is added a spatial contract, guaranteeing the spatial segregation between partitions; this latter part is essential for the incremental certification aspect, but is not essential for the generation of the scheduling plans.

[0169] [Fig.6] represents a flowchart of a method according to one embodiment.

[0170] The method described relates to a given partition, because the validation and integration can be done individually, partition by partition. Processing a plurality of partitions then comes down to iterating this process on the partitions to be considered.

[0171] A phase S2 comprises the determination, for each task of a partition P, of a temporal modeling constrained by an ordering of this partition within a timeline.

[0172] Then, a phase S3 comprises the determination of a static scheduling of these tasks within the timeline based on the previously obtained temporal models and temporal constraints associated with each task.

[0173] Previously, an SI phase may comprise determining the ordering of this partition within the timeline.

[0174] According to one embodiment, this phase SI comprises a step SI 1 of customizing the timeline to the processed partition PI, a step S12 of resetting the timeline, and a step S13 of merging the time slots. The final structure, resulting from the timeline, is specific to the partition considered and can be called RST (for “Repetitive Sequence of Timeslots” in English, i.e. “repetitive sequence of time slots”). This RST therefore represents the ordering of the partition considered within the timeline.

[0175] [Fig.5A] to [Fig.5D] illustrate the sequence of steps S1-S3 on an example timeline for a PL partition

[0176] [Fig.5A] represents the initial timeline comprising two partitions, PI, P2.

[0177] In the first step SI 1, the timeline is specialized by keeping only the time intervals allocated (or executing) the PI partition considered. The time intervals allocated to other partitions are replaced by empty time intervals.

[0178] We thus obtain the timeline illustrated in [Fig.5B].

[0179] In step S12, we seek to minimize the number of empty time slots (i.e. which do not execute any partition), in order to simplify the data structure as much as possible and preserve the essence of the time specification relating to the partition PI considered.

[0180] Also, we modify the topology of this first calculation result, so that the repetitive pattern begins during the execution of the first interval executing the partition PI. To do this, we first go through the repetitive sequence of time intervals RST in order to deduce the first date on which an interval executing PI is mobilized. In the example above, this date is 3. We calculate the duration between the start of the loop and the date previously obtained. In the example above, this duration is 2, the loop starting at date 1 (calculation: 3 - 1). If this date is not zero, to preserve the integrity of the periodic pattern, we copy the interval(s) covered between these two dates, and we place these copies at the end of the loop (here, the interval [9; 11]. We then modify the start date of the loop so that it coincides with the execution date of the first interval of P.

[0181] We thus obtain the timeline illustrated in [Fig.5C].

[0182] Finally, step S13 consists of merging the adjacent empty time intervals.

[0183] We can indeed seek to minimize the number of consecutive “empty” windows to further simplify the structure. We perform a linear traversal of the previously obtained RST. We thus determine the adjacent empty intervals, and we modify the RST so as to merge them.

[0184] We thus obtain the RST artifact illustrated in [Fig.5D].

[0185] The second phase S2 comprises the determination of a temporal modeling of each task of the partition PI considered, this modeling being constrained by the scheduling of the partition in the timeline as, for example, defined in the RST determined in phase SL

[0186] In particular, the tasks (or elementary actions of the agents) are compiled according to the RST corresponding to the partition which contains them (for a given core; we recall that the tasks are statically linked to a single core of the target computer), that is to say according to the ordering of this partition within the timeline.

[0187] A task is classically compiled in the form of a temporal model.

[0188] This temporal modeling is based on absolute or relative dates determined by the task code. The absolute dates are those provided in the code according to a clock. Relative dates correspond to durations provided from another date (absolute or relative).

[0189] This temporal modeling is typically a graph of temporal states. We can thus consider that the nodes of these graphs correspond to logical dates which limit the calculations of the task, materialized by the arcs joining two nodes. The arcs can therefore be associated with the durations indicated in the code, corresponding to calculation times.

[0190] To illustrate the notion of temporal modeling, we can take an example of code in the following PsyC language:

[0191] clock clk_ms = 1000 * realtime_ms;

[0192] agent Task (uses realtime, defaultclock clk_ms, starttime 3)

[0193] {

[0194] if ( condition ) {

[0195] advance 8;

[0196] advance 8;

[0197] } else {

[0198] advance 16;

[0199] advance 8;

[0200] }

[0201] }

[0202] Thus, this code contains absolute dates (the “starttime” milestone), and relative dates given by the “advance” keyword.

[0203] A step S21 consists of determining a first temporal model, for example a graph of temporal states, from the task code. The following steps S22-S25 of phase S2 will then carry out processing modifying this first model, using the repetitive sequence of time intervals RST determined in phase SI, in order to determine a final temporal model of the task, constrained by this RST.

[0204] [Fig.7] represents a time state graph that can be constructed from the code example given above. The nodes S (for "Start", beginning of the task), A, B, C correspond to the different time states that result from this code. The arcs correspond to the processes allowing to move from one state to another. The values ​​assigned to the arcs correspond to the durations to move from one state to another, indicated by the keywords "advance" in the code.

[0205] The condition (“if”) in the code represents the alternative, in [Fig.7], of moving from state A to state B or to state C.

[0206] The construction of such a time state graph follows from the state of the art corresponding to the ASTERIOS™ software suite. It is in particular described in the documentation of this software suite, as well as for example in the patent application WO2014 / 170569 filed by the company Krono-Safe (now Asterios Technologies).

[0207] Steps S22-S26 consist of carrying out a projection of this temporal model onto the repetitive sequence of RST time intervals, in order to obtain a temporal modeling constrained by this RST sequence.

[0208] Steps S22-S24 are iterative in order to traverse the entire temporal model (in particular the temporal state graph).

[0209] A step S22 consists of selecting an arc of the time state graph, and an interval of the ordering of the partition in the time line (i.e. of the RST sequence of this partition).

[0210] To do this, the iterative process can start at the first arc and at the first interval, in chronological order, then traverse the two structures in parallel, still in chronological order, and in accordance with traversal rules.

[0211] In particular, this step consists of synchronously exploring the time state graph and the RST. An operation similar to a synchronous product is performed: a date is associated with each graph (Da for the state graph and Di for the RST). At each update of Da and Di, steps S23, S24, S25 are carried out for each pair of time arc and interval of the RST executable at these dates. Da and Di are updated according to the available time branches:

[0212] - we move on to the next arc only if this one does not finish its execution within of the considered interval of the RST;

[0213] - we move on to the next interval once all the arcs that can start in the interval were considered;

[0214] - if several arcs are available on the same date (several connections possible), one of the choices is selected; when all possible time paths have been covered, this execution stops and the other option will be taken, recursively.

[0215] Step S23 consists of testing, for each iteratively visited pair, whether the arc of the time state graph is included or not in the considered interval of the RST.

[0216] If we consider an arc A=[a, b], a and b being its temporal limits, and an interval I=[c, d] of the RST, c and d being its temporal limits, then we can define that the arc A is included in the interval I if and only if a>c and b <d.

[0217] In the case where an arc A is not included in the interval I, then step S24 is implemented to fragment this arc.

[0218] When an arc is not totally included in an interval, then this arc A is fragmented into two arcs, Al, A2, so that one of these two arcs is included in the interval. In other words, we fragment the arc A into a date corresponding to one of the limits of the interval I considered.

[0219] [Fig.8] illustrates an example of application of this fragmentation step S24.

[0220] The arc A=[a, b] is not included in the interval I=[c, d]. It is therefore fragmented into two arcs Al, A2 so that the arc Al is included in the interval I. The splitting date corresponds to a boundary d of the interval I. We thus have Al=[a, d] and A2=[d, b],

[0221] Arc A2 will be considered in a subsequent iteration and, in the case where it is not included totally in an interval (following interval I), it is split again.

[0222] When all the arcs have been visited, step S25 can be implemented (however, according to other embodiments, this labeling step S25 can be implemented at the same time as the iterative traversal of steps S22-S24).

[0223] The labeling step S25 consists of assigning to each arc a label, or value, representing whether or not the arc is included in a time interval of the RST allocated to an execution of the partition considered.

[0224] More specifically, we analyze all the arcs, including the fragmented ones. For each of these arcs, we study the nature of the RST interval with which they are associated. If the interval is empty, the arc A is marked as non-executable, that is to say that no executable code (in particular that of the PsyC agents) can be allocated to it when the scheduling plan generation process occurs. Conversely, if the interval hosts the partition P (which is the only other possible case), A is marked as executable.

[0225] [Fig.9] illustrates an example of a possible result at the end of this phase S2 of determining a temporal model constrained by the ordering of the partition within the timeline.

[0226] In this [Fig.9] are represented the graph of temporal states modified by the iterative steps S22-S24 from the graph illustrated in [Fig.7], as well as the RST of the partition concerned below.

[0227] The temporal states A on the one hand and B and C on the other hand are aligned with the respective limits of the temporal interval dedicated to the partition in the timeline.

[0228] The small circles represent the splits of the arcs (step S24).

[0229] Thus, the initial arc between states A and B is associated with a duration (“advance”) of 8. Now the interval [3; 5] dedicated to the partition has a duration of 2. It must therefore be split into a first interval on the dates [3; 5], of duration 2, then a second interval of duration 6 corresponding to the time allocatable within this partition (i.e. the interval [5; 11]).

[0230] Similarly, the initial arc between states A and C is associated with a duration of 16. It is split a first time into an arc of duration 2 and an arc of duration 14, corresponding to the remainder. According to the aforementioned traversal rules, this arc is then compared to the next interval of the RST, which has a duration of 6.

[0231] The arc is therefore split again into an arc of duration 6 and an arc of duration 8 (i.e. 14-6) corresponding to the remainder. This arc of duration 8 is then compared to the following interval which is (since the RST forms a loop) the interval [3; 5] (modulo 8) allocated to the execution of the partition. This arc is split again into an arc of duration 2 and an arc of duration 6. This last arc being included in the following interval [5; 11], the process can be interrupted.

[0232] We then obtain the sequence represented in [Fig.9].

[0233] The double arrows correspond to the arcs that could be matched with the interval [3 : 5] (to the nearest modulo) which is allocated to the execution of the score. These double arrows therefore correspond to the executable arcs. The other (single) arrows correspond to the non-executable arcs.

[0234] Step S26 consists of “linearizing” the temporal model obtained in step S25 in order to obtain a final model. This final model can then be used by phase S3 of determining a static scheduling of the task within the timeline.

[0235] In particular, an existing mechanism can be used to implement this S3 phase, such as that of the Asterios™ software suite. In such an implementation, the temporal model of the task can be a RATS for “Repetitive Agent Temporal Sequence” in English (or repetitive agent temporal sequence).

[0236] This temporal modeling essentially represents a partial scheduling plan for the task. It consists of a series of intervals divided into two parts: a head where the task is executed once, and a loop where the task is executed indefinitely.

[0237] Due to the constraint imposed by the RST (resulting from the constraint of only being able to execute a task when the associated partition is executed by the core, therefore scheduled in the timeline), the length of the head becomes a function of the head length of the RST, and the length of the loop becomes a function of the loop length of the RST.

[0238] More precisely, the head length of the RATS corresponds to the maximum of the head length of the initial temporal modeling of the task (from its code) and the length and head of the RST sequence. The loop length of the RATS corresponds to the LCM (Least Common Multiple) of the loop length of the initial modeling and the loop length of the RST sequence.

[0239] This linearization step, S26, can be implemented in different ways.

[0240] The idea is based on a rewriting of the temporal models, RATS, of the tasks so that only one arc comes out of each node.

[0241] To do this, we associate two pieces of information with each arc: a duration D and a budget B. The duration D can be translated into a time window within which we can allocate an effective execution time of duration B.

[0242] In [Fig. 11 A] and [Fig. 11B], we note the budgets and durations associated with an arc by separating them with the “+” sign (B+D), for the sake of brevity.

[0243] We traverse the graph from its entry point (it is a particular node, identified a priori as such), which corresponds to the entry point of an agent. We recursively explore the graph by following the arcs. The exploration stops when the graph is fully linearized.

[0244] We consider the outgoing arcs from the same node two by two. If the arcs have the same duration, we merge them. The resulting arc thus has a duration D and a budget which corresponds to the maximum of the budgets of the two merged arcs.

[0245] [Fig. 11 A] illustrates such a situation in which the arcs of budget Bl, B2 respectively and of the same duration, 1, are merged into an arc of budget max(Bl, B2) and of duration 1.

[0246] If the arcs to be merged have different durations, one or the other (or even both) is fragmented, so as to obtain arcs that can be merged together, according to the method in the previous point. When an arc (B+D) is fragmented into two arcs (Bl+Dl) and (B2+D2), we set B=B1+B2 and D=D1+D2.

[0247] In the example illustrated in [Fig.llB], the arc B1+2 is thus fragmented into a first arc Bl'+1 and a second arc Bl”+1 with B1=B1'+B1”. The first arc, Bl'+1 can then be merged with the arc B2+1 according to the mechanism described previously.

[0248] This linearization mechanism for determining temporal models, RATS, is described in more detail in patent application WO2014 / 167197.

[0249] Step S3 consists of determining a static scheduling of all the tasks of a partition within the timeline from the temporal models (RATS) of each of these tasks, obtained in step S25 and linearized in step S26, and from temporal constraints associated with each task.

[0250] As mentioned previously, these time constraints may include, for a task, A wake-up call, A deadline constraint, An execution time constraint, A precedence constraint.

[0251] As indicated previously, this phase S3 can be implemented by the tools of the ASTERIOS™ software suite. In particular, the algorithms described in patent application WO2014 / 170569Al can be implemented. In a such a situation, the proposed method can therefore be grafted onto an existing mechanism but prepares the input data before this mechanism is forced to produce, as output, a static schedule verifying the additional constraint of scheduling a task in the time intervals allocated to its partition.

[0252] According to a particular embodiment, this phase S3 can be implemented by taking into account, in addition, an exclusion constraint between tasks implemented on distinct cores of the computer.

[0253] This constraint, established upstream by the developer of an application corresponding to a given partition, makes it possible to avoid interference when accessing common resources (memory, input / output ports, etc.) by tasks that could be executed at the same time. The time constraint requires the scheduling tool to allocate disjoint time intervals to tasks having an exclusion constraint between them.

[0254] It should be noted that phase S3 is implemented for each task of an application corresponding to a partition, in order to then be able, in phase S4, to determine a scheduling plan for all the tasks of this partition.

[0255] The obtained scheduling plan can be called RSF for "Repetitive Sequence of Frames" in English (Repetitive sequence of time windows). The structure of an RSF corresponds to a series of intervals divided into a head part and a loop part. The intervals of an RSF are frame containers, which represent CPU time reserved for the tasks to which they have been allocated. This notion of RSF has been described, in particular, in the patent application WO2014170569 filed by the company Krono-Safe (now Asterios).

[0256] An optional step S5 consists of verifying the consistency between the second-level scheduling plan, RSF, obtained in phase S4, and the first-level scheduling plan, RST.

[0257] To do this, we can perform for each core of the partition a synchronous exploration between the RST sequence and the RSF sequence. To each graph, we associate an exploration date Di for the RST and Dr for the RSF. In the same vein as the iterative steps S22-S24, we recover, for each RST interval, the intersection between this RST interval and the RSF.

[0258] In a step S6, each RSF interval is marked by the nature of the RST interval with which it is associated.

[0259] For time validation to be effective, all of the following criteria must be met: - An RSF interval must be associated with one and only one RST interval. - An RSF interval executing code must be associated with an interval of RST running the affected P partition.

[0260] Thus, for example, in the event of a change to a first-level scheduling plan by the integrator, it is possible to quickly verify that there is indeed compatibility between it and the different temporal constraints of the tasks of an application / partition, these constraints being materialized in the RATS temporal models.

[0261] [Fig.10A] to [Fig.10D] illustrate another example of application of the proposed method, in order to show its advantages.

[0262] In particular, this example illustrates why the management of monolithic static scheduling plans is not completely satisfactory, and must be subject to significant restrictions to be compatible with incremental certification constraints (as is the case with current ASTERIOS™ technology).

[0263] To illustrate an advantage provided by the proposed method, consider two PsyC agents (or tasks) forming an autonomous partition, the code of which is provided below:

[0264] agent ag_l (uses realtime, defaultclock clk_ms, starttime 1)

[0265] {

[0266] body start {

[0267] if ( condition ) {

[0268] timebudget A, advance 10; / / A = 2ms

[0269] timebudget B, advance 10; / / B = 3ms

[0270] } else {

[0271] timebudget C, advance 20; / / C = 3ms

[0272] }

[0273] }

[0274] }

[0275] agent ag_2 (uses realtime, defaultclock clk_ms, starttime 1)

[0276] {

[0277] body start {

[0278] timebudget D, advance 20; / / D = 2ms

[0279] }

[0280] }

[0281] The minimum execution period of the partition is 10 ms. That is to say that every 10 ms at the earliest, the tasks composing the partition must produce a calculation result, regardless of the temporal behavior of the tasks composing this partition. The only constraint is that no task in the partition has a temporal constraint less than an execution of 10 ms. The time budgets (specified via the "timebudget" instruction) indicate the maximum amount of execution time allocated to each portion of the task.

[0282] A possible static scheduling plan is shown in [Fig.lOA]. On the abscissa, the dates are indicated, with the repetition period for the loop part of the plan in brackets. The tasks of agent ag_l are represented by hatched areas, and those of agent ag_2 are represented by dotted areas.

[0283] We then assume the addition of a new partition comprising a third agent, ag_3, with a minimum execution period of 5 ms. The code could be as follows:

[0284] agent ag_3 (uses realtime, defaultclock clk_ms, starttime 1)

[0285] {

[0286] body start {

[0287] timebudget E, advance 5; / / E = 1ms

[0288] }

[0289] }

[0290] [Fig.lOB] represents a static scheduling plan reflecting all the constraints of the two partitions (therefore, with a total of three tasks, ag_l, ag_2, ag_3). The tasks of the third agent, ag_3, are illustrated by areas with a dotted grid text.

[0291] By comparing the two scheduling plans of [Fig.lOA] and [Fig.lOB], we see that the addition of a new partition (in the sense of an integrator) significantly disrupts the initial scheduling plan. We see, for example, that task ag_2, which could be executed without preemption in the interval [1, 11] of the initial plan, is preempted in the plan of [Fig.lOB] with the division of this interval into two sub-intervals [1, 6] and [6, 11].

[0292] This type of disruption to the scheduling plan greatly complicates users' WCET (Worst Case Execution Time) estimates: since the scheduling plan does not offer a guarantee of stability when a new partition is added, it is difficult to argue that the properties demonstrated on a given scheduling plan are preserved on another. These disruptions are generally attributable to edge effects on the caches.

[0293] As seen previously, the proposed method is based on the principle of a timeline which allows for the organization of an automatic static two-level scheduling. The "timeline" principle and the two-level static scheduling it provides thus provide the necessary guarantee of stability.

[0294] To illustrate this advantage based on the same example, we can consider a trivial timeline, describing the alternation of the two partitions. PI is first executed for 3 ms, then follows P2 for 2 ms, and so on.

[0295] The code in a dialect of the PsyC language can then be:

[0296] timeline t (uses realtime, defaultclock clk_ms, starttime 1, period 5)

[0297] {

[0298] partition PI, timeslot a, offset 0, duration 3;

[0299] partition P2, timeslot b, offset 3, duration 2;

[0300] }

[0301] The proposed method makes it possible to add a constraint to the scheduling generator, so that the latter integrates an additional constraint at the time of generating the scheduling plan of a partition. The executable time windows of the scheduling plans of a given partition must coincide with a time interval allocated to the partition in question.

[0302] The scheduling plans of partitions PI and P2 are thus shown, respectively, in [Fig.l0C] and [Fig.l0D]. It can be seen that these secondary scheduling plans are fragmented in such a way as to exhibit empty intervals coinciding with the time zones of the time interval allocated to the other partition.

[0303] For example, we notice, in this example, that the task ag_3 executes in the interval [4, 6] ([Fig.lOD]) and that no task executes in this interval for the partition PI ([Fig.lOC]). Similarly, the other intervals during which the task ag_3 executes are empty in the partition PI illustrated in [Fig.lOC]. We can see that the same is true for the tasks ag_l and ag_2 which are executed in empty time intervals of the partition P2.

[0304] It is therefore noted that the proposed method, according to these different embodiments, allows numerous advantages compared to the proposals of the state of the art.

[0305] According to one embodiment, the method can be based on existing tools but proposes to format and construct input data for these tools to force them to produce different, constrained scheduling plans that meet the requirements mentioned above.

[0306] According to embodiments, the method can be seen as based on a division of CPU time into fixed-size time execution windows, organized according to a periodic and repetitive pattern. A given partition can only execute during the execution windows that are statically allocated to it.

[0307] As we have seen, this formalism can be translated, for example, by a dedicated programming language or by a declarative configuration. It is up to the integrator to write this temporal specification, upstream of the integration process. This specification is provided to the various subcontractors and serves as a contract between subcontractors and integrator. Note that this contract can be accompanied by optional specifications declaring the access permissions of each partition to the memory address space.

[0308] Thus, the method offers the integrator a tool allowing him to express a formalized temporal design, interoperable with existing or non-existing scheduling methods, and usable by each entity developing partitions. It allows the implementation of robust partitioning between controlled software components. The emphasis is placed on temporal partitioning between partitions, but the spatial partitioning aspects are also addressed, without being normative, which allows a certain flexibility in the implementation of the method.

[0309] More generally, the method can be seen as being based on a principle of static time multiplexing, which allows strict temporal partitioning — or partitioning — between the partitions that make up the system, and, a fortiori, the tasks that constitute them. This mechanism is based on the “time-triggered” paradigm, in which the flow of time is the only source of events that governs the system. Particularly used in the field of critical avionics, it offers a higher level of safety than the “event-triggered” paradigm, to the detriment of the responsiveness and pure performance of the system.

[0310] The contract between integrator and application / partition developer (subcontractors, or application provider) is used, explicitly or implicitly, by the subcontractors in charge of manufacturing the partitions. These two modes of use of the contract represent a primordial aspect. Note that it is possible to combine them locally: a task is not necessarily intended to use these modes exclusively. Thus: - Explicit use. The user can perform the temporal design of his partition by modeling it on the time windows delimited by the contract. The tasks are explicitly resynchronized on the boundaries of the time windows. - Implicit use. The user can express time constraints and the described method allows to automatically generate the scheduling plan compatible with the high-level constraints.

[0311] Generally speaking, tasks can express finer time constraints within time windows.

[0312] It is important that the user's time directives do not contradict the contract, otherwise it will make it impossible to create consistent scheduling plans.

[0313] Thanks to the proposed method, the partitions are developed, tested and verified independently of each other, before validation of the system by the integrator. This principle of the invention is essential because it offers a modular approach, favoring the retention of certification credits obtained by each partition, while reducing the cost of certification during integration.

[0314] 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, belonging to a partition, on a multitask computer (30) comprising at least one processing core, said method comprising a determination (S2), for each task, of a temporal modeling constrained by a scheduling of said partition within a timeline, then a determination (S3) of a static scheduling of said tasks within said timeline from said temporal models and temporal constraints associated with each task.

2. Method according to the preceding claim, in which said timeline is provided in the form of a data structure specifying a division of time into time intervals, each time interval being individually assignable to a single partition.

3. Method according to one of the preceding claims, comprising a preliminary phase (SI) of ordering said partition within said time line, comprising a specialization (SU) of said time line to said partition, a resetting (S 12) of said time line, then a merging (S 13) of the empty time intervals.

4. Method according to one of the preceding claims in which said temporal model is a graph of temporal states, and said determination (S2) comprises a creation (S21) of a first graph of temporal states, then an iterative modification (S22-S25) of said first graph of temporal states using said ordering of said partition within said timeline.

5. Method according to the preceding claim, wherein said iterative modification (S22-S25) comprises a fragmentation (S24) of an arc of said temporal state graph if said arc is not totally included in an interval of said ordering of said partition within a time line (S23).

6. 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.

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

8. 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 according to one of claims 1 to 5.

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

Images