Brevet FR3159688A1 — publié le 20250829

Procédé d’ordonnancement d’un ensemble de tâches sur un calculateur multitâche (30), comportant au moins un cœur de traitement, ledit procédé comprenant - pour chaque cœur, initialiser (S1) un plan d’ordonnancement (13) subdivisé en intervalles temporels à partir de données temporelles (12) obtenus pour chaque tâche (11) de l’ensemble prévu pour ledit cœur, - allouer itérativement (S3–S11) des fragments pour chaque tâche dans le plan d’ordonnancement respectif, en considérant les tâches dans un ordre dépendant de liens de précédences, en respectant un ensemble de contraintes, et en déterminant (S10) si la totalité des fragments de la tâche est allouée dans le plan (13) avant une date d’échéance associée à cette tâche, définie par lesdites données temporelles - transmettre (S13) l’ensemble des plans (13) au calculateur (30). Figure pour l’abrégé : Fig. 3 Procédé de mitigation d’interférences temporelles par exclusions temporelles configurées par compilation DOMAINE DE L’INVENTION La présente invention concerne les systèmes multitâches et multicœurs temps-réels, et notamment les systèmes de sureté mettant en œuvre des contraintes temporelles. Elle s’applique en particulier aux systèmes embarqués, par exemple dans des véhicules aériens. Elle peut notamment s’appliquer aux systèmes embarqués d’avionique modulaire intégrée (IMA pour « Integrated Module Avionics » en anglais). Dans le domaine de l’avionique, en particulier, un haut-niveau de performance et de respect de ces contraintes temporelles est nécessaire, dans la mesure où la moindre défaillance peut faire porter des risques considérables pour le véhicule aérien. Même dans le cas d’un véhicule aérien sans pilote communément appelés drones ou UAS (pour « Unmanned Aircraft System » en anglais), auquel l’invention peut également s’appliquer, le risque de la perte du véhicule demeure, en sus de son écrasement possible sur des zones habitées. Des risques similaires peuvent exister pour d’autres types de véhicules (automobiles, ferroviaires, navals…), ou d’autres systèmes nécessitant ce type de contraintes temporelles (industrie du nucléaire, etc.) Dans les systèmes multitâches temps-réels critiques, il est généralement mis en œuvre des stratégies de provisionnement de quota de temps aux différentes tâches, de sorte que chacune puisse s’exécuter dans le respect de ses contraintes propres, notamment de cadence et de latence. Les quotas de temps alloués aux tâches sont généralement basés sur le concept de temps d’exécution dans le pire cas (ou WCET pour « Worst-Case Exécution Time ») que l’on attribue préalablement à chaque tâche à déployer sur un calculateur multitâche. L’estimation de ce temps d’exécution maximal nécessaire à la complétion d’une tâche, WCET, est un problème de recherche bien connu et reconnu comme particulièrement ardu. Il gagne encore en complexité lorsqu’on considère les calculateurs, ou systèmes multicœurs, en raison des interférences temporelles engendrées du fait que certaines tâches peuvent être déployés sur des mêmes fenêtres temporelles (mais sur des cœurs différents) alors qu’elles requièrent, par exemple, des ressources matérielles communes (ports d’entrée/sortie, bus internes du calculateur, etc.) Dans le domaine particulier de l’avionique, des standards et normes internationales permettent de spécifier des exigences auxquelles doivent répondre les véhicules aériens et les différents systèmes embarqués. On peut par exemple citer le standard DO-178C publiée par la RTCA (pour « Radio Technical Commission for Aeronautics » en anglais) et imposée par de nombreux organismes de régulation tels que la FAA ou l’EASA, qui spécifie des exigences en matière de systèmes logiciels embarqués. Plus particulièrement, le document AMC 20-193 définit une utilisation possible de calculateurs multicœurs compatible avec les exigences de plus haut-niveau spécifiées par le standard DO-178C. Cette norme AMC 20-193 détaille un ensemble d’objectifs qui doivent être remplis par un ensemble de tâches déployées sur un calculateur multicœur pour permettre une certification selon ces normes. En particulier, le document AMC 20-193 impose l’identification des interférences temporelles et la définition d’une stratégie permettant de les tolérer, ou mitiger (c’est-à-dire de les atténuer, voire de les supprimer) : “ 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 mitigation of the interference .” (Le demandeur a identifié les canaux d'interférence susceptibles d'affecter les applications logicielles hébergées sur les noyaux de processeurs multicœurs et a vérifié les moyens choisis par le demandeur pour atténuer l'interférence.) Par ailleurs, des plateformes sont disponibles pour faciliter la spécification des tâches devant être déployés sur un calculateur multicœur et la détermination d’un plan d’ordonnancement permettant de respecter leurs exigences temporelles propres, ainsi que pour permettre leur exécution conformément à ce plan d’ordonnancement. A titre d’exemple, on peut citer la suite logicielle ASTERIOS™ développée par la société Asterios Technologies (anciennement Krono-Safe). Elle comporte un outil (ASTERIOS™ RTK) permettant d’exécuter un ensemble de tâches temps-réel sur un calculateur multicœurs en respect d’un plan d’ordonnancement, par exemple fourni par un autre outil de la chaîne (ASTERIOS™ Developer). Les mécanismes mis en œuvre sont par exemple décrits dans la demande de brevet WO2015092188A1. Toutefois, ces mécanismes ne permettent pas de prendre en compte les interférences temporelles entre tâches devant être déployés sur des cœurs différents du calculateur multicœur. Un but de l’invention est donc d’améliorer les propositions actuelles de l’état de la technique en permettant, notamment, la prise en compte des interférences temporelles engendrées entre tâches. À ces fins, selon un premier aspect, la présente invention peut être mise en œuvre par un procédé d’ordonnancement d’un ensemble de tâches sur un calculateur multitâche, comportant au moins un cœur de traitement, ledit procédé comprenant pour chaque cœur dudit calculateur, initialiser un plan d’ordonnancement subdivisé en intervalles temporels à partir de données temporelles obtenus pour chaque tâche dudit ensemble prévu pour ledit cœur ; allouer itérativement des fragments de traitement pour chaque tâche prévue pour ledit cœur dans le plan d’ordonnancement respectif, en considérant lesdites tâches dans un ordre dépendant de liens de précédences temporelles définis pour lesdites tâches, et en respectant un ensemble de contraintes consistant : à considérer itérativement chaque intervalle dudit plan d’ordonnancement non encore allouée à une tâche, à positionner lesdits fragments dans ledit plan d’ordonnancement au plus tôt à un instant déterminé à partir desdits liens de précédences temporelles et d’une date de début de ladite tâche définie par lesdites données temporelles, à ne pas positionner lesdits fragments en chevauchement de fragments d'une autre tâche avec laquelle il existe une contrainte d’exclusion, parmi l’ensemble des plans d’ordonnancement, et en déterminant si la totalité des fragments de traitement de ladite tâche est allouée dans ledit plan d’ordonnancement avant une date d’échéance associée à ladite tâche, définie par lesdites données temporelles ; transmettre l’ensemble desdits plans d’ordonnancement audit calculateur. Suivant des modes de réalisation préférés, l’invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles : allouer itérativement des fragments de traitement pour chaque tâche prévue pour ledit cœur comprend des étapes de : calcul dudit instant à partir desdits liens de précédences temporelles, par recherche de la plus tardive des dates parmi la date de début de ladite tâche et les dates de terminaison des tâches ayant une précédence sur ladite tâche, détermination d’une liste des fragments correspondant à des tâches ayant une relation de précédence avec ladite tâche, sélection d’un intervalle temporel dudit plan d’ordonnancement, et, pour ledit intervalle temporel sélectionné, détermination d’espaces vides non encore alloués à une tâche, à partir dudit instant, suppression des espaces vides associés à une contrainte d’exclusion pour ladite tâche, puis allocation d’espaces vides restants à un fragment de ladite tâche ; si la somme des durées des intervalles alloués à ladite tâche est inférieur au temps d’exécution associé à ladite tâche et qu’aucun intervalle non encore alloué est disponible avant une date d’échéance associé à ladite tâche, alors on supprime les allocations de ladite tâche et on essaie d’allouer une autre tâche ; le procédé comprend en outre une étape de tri des tâches dudit ensemble de tâches, et une étape de sélection d’une tâche selon ledit tri, et dans lequel essayer d’allouer une autre tâche comprend un nouveau tri desdites tâches, après avoir vérifié si tous les tris possibles n’ont pas été essayés ; essayer d’allouer une autre tâche comprend un parcours en arbre au sein desdits tris possibles ; le procédé comprend en outre, lors de l’allocation d’un fragment de traitement, une affectation audit fragment d’une date de démarrage au sein dudit plan d’ordonnancement en fonction de la date de début dudit intervalle temporel ; ladite date de démarrage est affectée à un fragment uniquement si ledit fragment ne serait pas en chevauchement d’un fragment d’une autre tâche avec lequel il existe une contrainte d’exclusion sur l’intervalle temporel précédent ledit intervalle temporel. le procédé comprend en outre une affectation d’une date de fin à un intervalle temporel, ladite date de fin correspondant à la date la plus tardive des fragments alloués sur ledit intervalle temporel dans l’ensemble desdits plans d’ordonnancement Un autre objet de l’invention concerne un calculateur adapté pour utiliser les plans d’ordonnancement produits par le procédé précédemment décrit. En particulier, cet objet concerne un calculateur multitâche disposant d’un ensemble de cœurs et adapté pour exécuter un système d’exploitation temps-réel adapté pour exécuter des tâches en fonction d’un ensemble de plans d’ordonnancement déterminés par un procédé tel que précédemment décrit. Un autre objet de l’invention concerne un véhicule comportant au moins un tel calculateur multitâche. Un autre objet de l’invention concerne un programme d’ordinateur comportant des instructions pour mettre en œuvre un procédé tel que précédemment décrit lorsque celui est exécuté par un processeur d’un équipement de configuration. Un autre objet de l’invention concerne un équipement de configuration comportant au moins un processeur et des circuits adaptés pour mettre en œuvre le procédé tel que précédemment décrit sous la forme d’un outil d’ordonnancement. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d’un mode de réalisation préféré de l'invention, donnée à titre d'exemple et en référence aux dessins annexés. BREVE DESCRIPTION DES FIGURES Les dessins annexés illustrent l’invention : Les FIG. 1 et FIG. 1 représentent schématiquement un calculateur multitâche multicœur. La FIG. 2 illustre schématiquement un contexte de déploiement d’un procédé selon un mode de réalisation. La FIG. 3 représente schématiquement un organigramme simplifié d’un procédé selon un mode de réalisation. La FIG. 4 illustre un exemple d’initialisation d’un squelette de plan d’ordonnancement, selon un mode de réalisation. La FIG. 5 représente un exemple d’application sur un ensemble de 4 tâches d’un procédé selon un mode de réalisation. Les FIG. 6 à FIG. 6 illustrent un mécanisme d’affectation d’une date de démarrage à un fragment selon un mode de réalisation. Les FIG. 7 et FIG. 7 illustrent un exemple de deux plans d’ordonnancement, sans et avec affectation d’une date de fin aux intervalles temporels, selon un mode de réalisation. Les FIG. 8 à FIG. 8 illustrent un autre exemple de déroulement du procédé selon un mode de réalisation. DESCRIPTION DETAILLEE DE MODES DE REALISATION DE L’INVENTION La FIG. 1 illustre une vue schématique et haut niveau d’un ensemble de tâches, ou agents, A déployé sur un calculateur multitâche multicœur 30. Sur la figure, des tâches A1, A 2 … A n sont représentées. Le calculateur 30 peut comporter des composants matériels, tels qu’un ou plusieurs processeurs, et des circuits associés (notamment des mémoires de type RAM, des circuits d’interface, etc.). Une couche intermédiaire comporte un système d’exploitation temps-réel RTOS (pour « Real-Time Operating System » en anglais). Un tel système d’exploitation est apte à gérer le lancement des différentes tâches et leur préemption selon une cadence déterminée, de façon statique, par un plan d’ordonnancement fourni. Ce calculateur multitâche multicœur peut être embarqué sur tout système nécessitant notamment un besoin d’un cadencement garanti de l’exécution de différentes tâches par exemple pour des raisons de sécurité ou de sûreté de fonctionnement. Il peut notamment s’agir d’un véhicule mobile dont les équipements électroniques doivent répondre à de tels contraintes afin de garantir que son fonctionnement soit conforme à un fonctionnement attendu et notamment que sa direction ne constitue un danger ni pour lui-même et ses passagers ni pour d’autres biens ou personnes autour de lui. Ce système mobile peut par exemple être un véhicule aérien, tel qu’un avion Il peut s’agir également d’un véhicule sans pilote, ou drone (ou UAS pour « Unmaned Aircraft System » ou encore UAV pour « Unmaned Aircraft Vehicle » en anglais). Le procédé décrit peut s’appliquer à des calculateurs embarqués dans un contexte d’avionique critique, mais également à tout système devant être conforme de contraintes temps-réelles avec une emphase sur la sûreté de fonctionnement (e.g. nucléaire civil, ferroviaire, automates industriels, aérospatiale…). La FIG. 1 représente une vue fonctionnelle d’un calculateur multitâche multicœur sur lequel un ensemble de tâches A ordonnancé selon le procédé proposé est susceptible d’être déployé. Cette vue vise à illustrer les différentes ressources du calculateur auquel cet ensemble de tâches peut accéder. Typiquement au moyen d’un bus logique (référencé BUS sur la figure), les agents A peuvent accéder à des ressources tels qu’une (ou plusieurs) mémoires MEM. Ces mémoires peuvent être des mémoires de type « mémoire vive » ou RAM, et des mémoires de masse de type « disque dur », à titre d’exemples. D’autres ressources peuvent être des interfaces INT avec d’autres équipements, typiquement des interfaces réseaux. D’autres ressources peuvent également être embarquées dans un calculateur 30 et ces exemples sont uniquement illustratifs. Par ailleurs d’autres tâches TSK que celles gérées dans le cadre du procédé proposé peuvent être également déployées et accéder, de façon concurrente, aux ressources du calculateur multicœur 30. Comme évoqué précédemment, un enjeu est de définir un ordonnancement des différentes tâches A afin qu’elles puissent toutes (si cela est possible) être exécutées selon leurs contraintes temporelles. En général, ces tâches sont récurrentes, c’est-à-dire qu’elles doivent se répéter dans le temps. Dans le cadre d’un véhicule aérien, par exemple, ces différentes tâches peuvent représenter des fonctions de différents équipements embarqués, qui doivent s’exécuter de façon continue lorsque le véhicule est en fonctionnement. Par exemple, des fonctions de contrôle de la trajectoire, de l’altitude, des différents capteurs du véhicule doivent être continument en fonctionnement, c’est-à-dire qu’ils doivent exécuter un traitement selon une contrainte temporelle propre (par exemple fournir une valeur toutes les n millisecondes). Aussi, l’ordonnancement peut également être répétitif : il concerne donc une ou plusieurs fenêtres temporelles prévues pour être répétée continument dans le temps. Par ailleurs, certains traitements sont dépendants d’autres traitements, par exemple parce qu’ils ont besoin d’une valeur de cet autre traitement afin de générer leurs propres sorties. Le non-respect d’une contrainte temporelle d’une tâche peut donc impacter d’autres tâches avec lesquelles elle est dans une relation de précédence. En outre, la gestion concurrente des tâches à des mêmes ressources du calculateur 30 est nécessaire pour éviter que deux tâches se bloquent ou, plus couramment, que leurs temps de traitement soient rallongés par ces accès concurrents au-delà des contraintes temporelles qui leur sont associées. Ce phénomène est appelé interférences par la suite. Il pourrait être envisagé de ne pas prendre en compte les interférences au niveau du plan d’ordonnancement fourni au calculateur et de laisser le système d’exploitation temps-réel RTOS gérer ces aspects de façon dynamique, lors de l’exécution (ou « runtime ») des tâches. Toutefois, cette façon de faire ne permet pas de garantir qu’au moment de l’exécution des tâches le système d’exploitation soit en mesure de trouver une solution pour ordonner les tâches à planifier selon leurs contraintes temporelles et afin d’éviter les interférences. Ce type de solution peut être acceptable dans des contextes non-critiques où la sécurité n’est pas primordiale, c’est-à-dire où l’ensemble des contraintes temporelles ne sont pas strictement impératives mais peuvent subir une certaine flexibilité. Aussi, il est proposé que le système d’exploitation temps-réel RTOS dispose d’un plan d’ordonnancement statique, permettant de garantir que les différentes contraintes sont respectées. La définition d’un tel plan d’ordonnancement est primordiale pour garantir la sureté du système associé à l’ensemble de tâches A. La FIG. 2 schématise un processus pour la définition d’un ensemble de tâches jusqu’à leur implantation sur un calculateur multicœur et un procédé de génération d’un tel plan d’ordonnancement. Dans un premier temps, des applications multitâches 11 peuvent être définies selon un langage de conception approprié et adapté à une mise en œuvre sur un calculateur temps-réel. Ce langage permet de définir le code informatique qui doit être exécuté sur le calculateur, ainsi que les différentes contraintes temporelles que ce code informatique doit respecter. Un exemple d’un tel langage peut être le langage PsyC défini par la société Asterios Technologies (anciennement Krono-Safe) et adapté pour produire des fichiers pouvant être utilisé par la plateforme temps-réel ASTERIOS™ RTK évoquée précédemment. Ce langage est basé sur le langage C et comporte des éléments supplémentaires permettant de gérer les aspects liés au temps-réel, au parallélisme et aux communications. Dans un tel mode de réalisation basé sur la plateforme ASTERIOS et le langage PsyC, les applications logicielles sont définies par des agents. Ces agents sont des séquences d’actions élémentaires. Des contraintes temporelles peuvent être associés à ces actions élémentaires et spécifiées par le concepteur d’une application temps-réel. Elles peuvent être décrites par le langage (par exemple le langage PsyC) et comprennent : Une contrainte de réveil, Une contrainte d’échéance, Une contrainte de temps d’exécution, Une ou plusieurs contraintes de précédence. Chaque action élémentaire peut par la suite être considérée comme étant une tâche que l’on cherche à ordonnancer sur un cœur de calculateur multitâche multicœur. Comme il sera vu ultérieurement, l’ordonnancement comprend l’allocation de temps disponible d’un cœur du calculateur sous forme de fragments de traitement, ou trame (de l’anglais « frame » usuellement utilisé). Un découpage temporel permettant l’allocation de fragments de temps est par exemple décrit dans la demande de brevet WO 2010/043706, et est connu sous la terminologie RSF pour « Repetitive Sequence of Frames » en anglais (Séquence répétitives des fenêtres temporelles). La structure d’un RSF est une série d’intervalles divisés en une partie tête et une partie boucle, chaque intervalle étant un containeur possible d’un fragment de traitement d’une tâche. Comme il vient d’être vu, chaque tâche (ou action élémentaire) a une contrainte d’échéance qui correspond à l’instant auquel elle doit impérativement avoir terminé son traitement. La contrainte de temps d’exécution correspond à la durée maximale nécessaire à la tâche pour s’exécuter. La différence entre le temps d’exécution et la date d’échéance correspond à un temps durant lequel la tâche peut être préemptée (les processeurs peuvent alors exécuter d’autres tâches concurrentes). La contrainte de précédence indique que la tâche nécessite qu’une, ou plusieurs, autre(s) tâche(s) doivent s’exécuter préalablement. Auquel cas, cette tâche ne peut donc pas démarrer avant la terminaison de ces tâches. Dans le cas où ces tâches préalables (ou précédentes) ont une exécution tronçonnée en plusieurs fragments de traitement, la date de terminaison de la dernière trame doit être considérée. En outre, des contraintes d’exclusion peuvent être définies afin de supprimer, les interférences entre tâches. Autrement dit, il est proposé de permettre aux développeurs d’applications temps-réels de mitiger les interférences entre les différentes tâches dès la phase de conception au moyen d’exclusions entre tâches. Le procédé proposé permet de prendre en compte ces spécifications pour la détermination d’un plan d’ordonnancement. Par construction, les interférences seront ainsi évitées lors de l’exécution des tâches sur le calculateur cible 30. Plus précisément, selon un mode de réalisation, les contraintes d’exclusion entre actions élémentaires d’agents d’une application écrite en langage PsyC peuvent être exprimées à travers le langage PsyC et une configuration afférente (par exemple en JSON). Ces exclusions se reportent naturellement sur les tâches à ordonnancer correspondant aux actions élémentaires. Le langage PsyC permet d’ajouter des identifiants pour les instructions « advance », sous la forme @ advance … Dans la configuration JSON, on peut utiliser les identifiants des instructions « advance » pour définir des actions élémentaires, ou tâches d’ordonnancement. Une action élémentaire représente un fragment de code qui s’exécute entre deux instructions « advance » successives. Donc une action élémentaire est définie par l’identifiant de l’instruction « advance » de départ, l’identifiant de l’instruction « advance » d’arrivée, et un nom unique pour l’identifier. Et la spécification des contraintes d’exclusion se fait aussi dans la configuration JSON, à travers la définition des groupes d’exclusion. Un groupe d’exclusion est un ensemble des actions élémentaires qui ne doivent pas s’exécuter simultanément. Un compilateur 10 peut être prévu pour prendre en entrée les spécifications des tâches 11 constitutives des applications afin de générer des fichiers de sortie 12 qui comprennent à la fois des codes objets destinés à être exécutés sur le calculateur multitâche 30, et des données destinées à être utilisées par un outil d’ordonnancement 20. Cet outil d’ordonnancement 20 est prévu pour générer un plan d’ordonnancement 13 à partir de ces données fournies par le compilateur 10. Ces données 12 générées par le compilateur peuvent notamment comprendre une structure de données représentant des données temporelles relatives aux tâches compilées. En particulier, à partir du code 11, le compilateur peut générer une structure de données fournissant des données temporelles comprenant, pour chaque tâche, ou action élémentaire, une date de début, éventuellement une date de terminaison et les contraintes temporelles associées à cette tâche. Ces contraintes temporelles peuvent notamment comporter les contraintes d’échéance, les contraintes de temps d’exécution, les contraintes de précédences, les contraintes de réveil et les contraintes d’exclusion. Selon un mode de réalisation, il est proposé un procédé de génération d’un plan d’ordonnancement 13 prenant en compte ces différents types de contraintes, pour chaque tâche (5 dans le mode de réalisation décrit). Selon un mode de réalisation basée sur le suite logicielle ASTERIOS™, ces données temporelles peuvent prendre la forme d’un graphe appelé RATS pour « Repetitive Agent Temporal Sequence » en anglais (ou séquence temporelle répétitive d’agent). Ce graphe représente essentiellement un plan d'ordonnancement partiel pour la tâche. Il s'agit d'une série d'intervalles qui sont divisés en deux parties : une tête où la tâche est exécutée une fois, et une boucle où la tâche est exécutée indéfiniment. Chacune de ces deux parties peut faire l’objet d’une partie d’un plan d’ordonnancement 13, dont la composition fournira le plan d’ordonnancement final soumis au calculateur cible 30. Dans chaque intervalle où la tâche est censée être exécutée, elle est soumise aux contraintes temporelles précédemment indiquées. Le plan d’ordonnancement 13 généré par l’outil d’ordonnancement 20 peut être constitué d’un ensemble de sous-plan, chacun étant associé à un cœur du calculateur multicœur 30. Le système d’exploitation temps-réel RTOS embarqué dans le calculateur 30 est adapté pour orchestrer les exécutions des tâches sur chacun des cœurs en fonction du sous-plan associé. Dans la suite, on appellera également, par simplification, « plan d’ordonnancement » chacune de ces parties du plan total. La FIG. 3 montre un organigramme illustratif d’un mode de réalisation du procédé mis en œuvre par l’outil d’ordonnancement 20 Dans une étape S1, pour chaque cœur du calculateur 30, l’outil d’ordonnancement initialise un plan d’ordonnancement 13 subdivisé en intervalles temporels à partir de données temporelles 12 obtenus pour chaque tâche (ou action élémentaire d’un agent), 11 de l’ensemble prévu pour être déployé sur ce cœur. Ce plan d’ordonnancement tel qu’initialisé constitue un squelette. Les étapes ultérieures vont chercher à affecter aux intervalles temporels des fragments de traitements des tâches, afin de constituer le plan d’ordonnancement du cœur considéré. Cette initialisation peut consister à subdiviser un plan d’ordonnancement vide, c’est-à-dire une simple ligne temporelle, en déterminant des jalons correspondant aux dates de début et de terminaison de l’ensemble des tâches affectées au cœur considéré. Autrement dit, si on considère que chaque tâche est associée à un intervalle temporel borné par une date de début et une date de terminaison, le squelette est formé par les intervalles temporels bornés par deux dates successives au sein de cet ensemble de dates. La FIG. 4 illustre un exemple d’initialisation d’un tel squelette 13 pour un cœur donné. Dans cet exemple, 3 tâches, A, B, C sont à ordonnancer. Le squelette 13 se base donc sur les données temporelles associées à ces 3 tâches, c’est-à-dire : Pour la tâche A, une date de début t AS et une date de terminaison t AF , Pour la tâche B, une date de début t BS et une date de terminaison t BF , Pour la tâche C, une date de début t CS et une date de terminaison t CF . Chaque tâche peut être représentée par un intervalle temporel sur la figure. Le squelette 13 est constitué d’une subdivision d’intervalles temporels bornés par deux dates successives de l’ensemble des dates considérées : t AS, t AF , t BS , t BF , t CS , t CF . On obtient ainsi un squelette formé de la suite d’intervalles [t AS , t BS ], [t BS , t CS ], [t CS , t BF ], [t BF, t AF ], [t AF , t CF ]. Dans une étape S2, les différentes tâches à ordonnancer sur un cœur donné sont triées dans un ordre donné. Ce tri est avantageusement effectué en amont de la boucle qui suit, selon le procédé de cette mise en œuvre, afin de mutualiser ce traitement de tri, mais selon d’autres mode de réalisation, on pourrait envisager de choisir une nouvelle tâche à affecter à chaque itération sans faire ce tri préalable. Cet ordre peut être global, c’est-à-dire pour l’ensemble des cœurs du calculateur 30. En effet, cet ordre doit notamment prendre en compte les relations de précédence entre tâches et cette relation est indépendante des cœurs sur lesquels les tâches sont déployées. Cette contrainte de précédence peut être prise en compte comme premier critère de tri. Un second critère de tri peut être la date d’échéance des tâches. Ainsi, l’algorithme de tri ordonne les tâches selon les règles suivantes : Pour chaque paire de tâches A, B, A est avant B si et seulement si Il existe une contrainte de précédence où A précède B, ou S’il n’existe pas de contrainte de précédence où B précède A et La date de début de la tâche A est antérieure à la date de début de la tâche B, ou, si celles-ci sont égales, La date d’échéance de la tâche A est antérieure à la date d’échéance de la tâche B, Si ces dates sont égales, le nom de la tâche A précède le nom de la tâche B lexicographiquement. Cette dernière condition est un exemple permettant de fournir une règle de tri qui est déterministe dans tous les cas. Evidemment, d’autres modes de réalisation sont possibles permettant ce même objectif de déterminisme. Ainsi qu’illustré dans l’organigramme de la FIG. 3 , les étapes ultérieures sont itératives, chaque itération considérant une des tâches à ordonnancer. Une étape S3 consiste à sélectionner une tâche selon un ordre donné, cet ordre pouvant être issu de l’étape préalable de tri S2. Cette sélection consiste à partir de la première tâche selon cet ordre puis de poursuivre aux itérations suivantes selon cet ordre. Cette allocation d’une tâche peut s’effectuer par fragments, ou trames (ou « frame » en anglais) de traitement. Chaque fragment est alloué à un intervalle temporel du plan d’ordonnancement, de façon indépendante des autres fragments de la même tâche. Autrement dit, pour une tâche donnée, son allocation s’effectue fragment par fragment. L’allocation des fragments est assujettie à des contraintes comprenant : Une contrainte de cadencement : tous les fragments doivent être alloués dans des intervalles du plan d’ordonnancement qui commencent après la date de début de la tâche, et qui finissent avant sa date d’échéance, Une contrainte de temps d’exécution : la somme des durées de tous les fragments d’une tâche doit être égale au temps d’exécution de la tâche (tel qu’indiqué dans les données temporelles fournies en entrée), Une contrainte de précédence : le premier (temporellement) fragment d’une tâche doit débuter après les terminaisons des derniers fragments des tâches qui sont en relation de précédence, Une contrainte d’exclusion : les fragments de la tâche ne doivent pas chevaucher des fragments d’autres tâches avec lesquelles il existe des contraintes d’exclusion. Deux étapes de calcul préalable S4, S5 peuvent être effectuées préférentiellement avant la phase d’itération débutant à l’étape S6 et considérant chaque intervalle temporel du plan d’ordonnancement. Comme précédemment, il s’agit d’un mode de réalisation préférentiel permettant de mutualiser des traitements plutôt que de les effectuer à chaque itération, c’est-à-dire pour chaque intervalle temporel à considérer. D’autres modes de réalisation sont toutefois envisageables. Une étape S4 vise à déterminer un instant à partir duquel les intervalles temporels peuvent être considérés pour allouer des fragments de la tâche. Cet instant dépend à la fois de la date de début de cette tâche (qui est fournie par les données temporelles associées à la tâche) et des liens de précédences temporelles. Autrement dit, cet instant est déterminé, ou calculé, par la date la plus tardive entre la date de début de la tâche et les dates de terminaison des tâches ayant une relation de précédence avec celle-ci (ces dates de terminaison correspondent aux dates de fin du dernier fragment de ces tâches). Les fragments de la tâche peuvent être positionnées, ou allouées, uniquement à partir de cet instant. Une étape S5 comprend la détermination d’une liste des fragments correspondant à des tâches ayant une relation d’exclusion avec la tâche en cours d’allocation. L’étape S6 consiste à sélectionner un intervalle temporel du plan d’ordonnancement entre la date de début de la tâche et sa date d’échéance. Les intervalles sont sélectionnés de façon itérative dans le sens du temps et en débutant par l’intervalle débutant à la date de début de la tâche. Dans une étape S7, on détermine un ensemble d’espaces vides au sein de cet intervalle temporel qui ne sont pas encore alloués à une tâche, et qui débutent après l’instant de début calculé en étape S4. Cette étape revient à calculer l’intersection entre ces espaces vides et un intervalle débutant à l’instant calculé en étape S4. Dans une étape S8, on supprime de cet ensemble les chevauchements avec les fragments présents dans la liste d’exclusion déterminée en étape S5. Dans une étape S9, on alloue des fragments à la tâche dans les espaces vides restants. Lorsqu’un intervalle temporel est considéré, l’étape S10 détermine si la totalité des fragments de la tâche ont été alloués dans le plan d’ordonnancement, avant la date d’échéance de la tâche. On compare autrement dit la somme des durées des différents fragments alloués au temps d’exécution de la tâche, ceux-ci devant être égaux. Si oui, alors une nouvelle tâche peut être considérée. On passe alors en étape S11. Sinon, deux situations peuvent se produire : soit il existe encore des intervalles temporels disponibles dans le plan d’ordonnancement avant la date d’échéance de la tâche. Dans ce cas, on reboucle sur l’étape S6 pour sélectionner un nouvel intervalle temporel. Si, au contraire, il n’existe plus d’intervalles temporels avant cette date d’échéance, cela signifie que la totalité des fragments constituant cette tâche ne peuvent pas être allouées. Un plan d’ordonnancement ne peut donc pas être généré. Selon un mode de réalisation, on reboucle alors sur l’étape S2 afin d’effectuer un nouveau tri des tâches, après avoir vérifié si tous les tris possibles n’ont pas été déjà essayés (test S12). Dans une étape S11, on détermine si une nouvelle tâche doit être sélectionnée. Si oui, on reboucle à l’étape S3 pour sélectionner une tâche selon un ordre donné, déterminé en étape S2. Si non, le plan d’ordonnancement est finalisé et peut être transmis, ou provisionné, dans le calculateur, dans une étape S13. La boucle liant l’étape S10 à l’étape S2 représente un mécanisme de retour arrière, ou « backtracking » en anglais. En effet, la phase itérative S3-S11 d’allocation des tâches dans le plan d’ordonnancement est dépendant de la phase de tri, S2 : en fonction de l’ordre dans lequel on chercher à allouer les tâches dans le plan d’ordonnancement, le résultat peut être différent, mais surtout on peut réussir ou pas à obtenir un plan d’ordonnancement. Aussi, en cas d’échec (à l’étape S10), on peut considérer un autre ordre dans les taches à allouer. Selon un mode de réalisation, on effectue un parcours en arbre au sein des tris possibles. Plus précisément, on peut parcourir un arbre des possibilités, et lorsqu’un tri donné (correspondant à une feuille de l’arbre) génère un échec, on remonte dans l’arbre pour explorer une autre branche. Le procédé peut ici suivre une exploration en arbre classique. Un échec sera généré lorsque l’ensemble des branches de l’arbre auront été explorées sans fournir de plan d’ordonnancement, lors de l’étape de test S12 (sur la figure, cette situation correspond à la flèche sortant de l’étape S12 vers la gauche). La FIG. 5 illustre un exemple d’application du procédé proposé sur un ensemble initial de 3 tâches, A, B, C devant être ordonnancées sur un calculateur disposant de deux cœurs. Une quatrième tâche, D, sera ensuite ajoutée. On suppose que les tâches A et B sont affectées à un premier cœur, et la tâche C est affecté à un second cœur, la tâche C a une date de début égale à 0 et une date d’échéance égale à 10. la tâche C a un temps d’exécution égal à 5, la tâche C a une relation de précédence avec la tâche A et doit attendre sa terminaison. La tâche C a une contrainte d’exclusion avec la tâche B. On suppose que les tâches A et B ont déjà été allouées sur le plan d’ordonnancement RSF1 correspondant au premier cœur. L’étape S3 consiste donc à sélectionner la dernière tâche, C. L’étape S4 de l’algorithme consiste à calculer un instant par recherche de la plus tardive des dates parmi la date de début de cette tâche (ici 0) et les dates de terminaison des tâches ayant une précédence sur cette tâche, ici la tâche A qui se termine en 3. Cet instant vaut donc 3. L’étape S5 consiste à déterminer la liste des fragments exclus. Pour simplifier, identifiions les frames par leurs bornes. Pour cet exemple, cette liste est composée d’un seul élément : [5, 7] (qui correspond à la tâche B). Les étapes suivantes correspondent à la boucle sur les intervalles temporels. Dans cet exemple, il n’existe qu’un seul intervalle dans lequel la tâche C peut s’exécuter, c’est l’intervalle [0, 10]. Comme aucun fragment n’est encore alloué dans cet intervalle, l’espace vide où la tâche peut s’exécuter est [0, 10]. Dans l’étape S7, on calcule l’intersection de cet intervalle [0, 10] avec l’intervalle [3, 10]. Le résultat est [3, 10]. Dans l’étape S8, on supprime les chevauchements avec les intervalles dans la liste d’exclusion. Cela découpe notre espace vide en deux sous-espaces : [3, 5] et [7, 10]. Dans l’étape S9, on peut allouer des fragments pour la tâche C dans ces deux intervalles tout en respectant les contraintes de celui-ci. On vérifie à l’étape S10 que la somme des durées de ces deux fragments est égale au temps d’exécution de la tâche C, on peut s’arrêter ici (étapes S11 et S13). Si une autre tâche D était à ordonnancer sur le premier cœur, un fragment pourrait par exemple lui être allouée sur l’intervalle [3, 10] à condition qu’elle n’ait pas de contraintes d’exclusion avec la tâche C (qui s’exécute sur le même intervalle qu’elle), qu’elle ait une date de début non antérieure à l’instant 3 et qu’elle n’ait pas de contrainte de précédence avec une autre tâche, hormis éventuellement la tâche A. Selon un mode de réalisation, on peut affecter aux fragments alloués une date de démarrage au sein du plan d’ordonnancement. Cette information permet, et impose, au système d’exploitation temps-réel, RTOS, de démarrer l’exécution de ce fragment de traitement à cette date, même si le cœur concerné est disponible plus tôt. Elle interdit donc certains fonctionnements dynamiques du système d’exploitation temps-réel. Cette date de démarrage est fonction de la date de début de l’intervalle temporel dans lequel le fragment est alloué. Cette date peut typiquement correspondre à la date de démarrage de l’intervalle temporel. En effet, certains systèmes d’exploitation temps-réel peuvent posséder des fonctionnalités d’orchestration dynamique permettant d’anticiper le démarrage d’un fragment. En effet, les traitements d’une tâche peuvent s’exécuter plus rapidement que le temps d’exécution prévu dans les données temporelles, qui représentent un pire cas. Dès lors, un fragment alloué dans le plan d’ordonnancement peut se terminer avant la date de fin de l’intervalle temporel dans lequel elle était allouée. Le système d’exploitation peut alors prévoir de démarrer le fragment alloué dans l’intervalle temporel suivant, par anticipation. Cette fonctionnalité paraît intéressante dans certaines situations, puisque permettant globalement un traitement plus rapide et de libérer de la flexibilité pour la suite du plan d’ordonnancement. Toutefois, cette anticipation peut être néfaste dans certaines situations, notamment dans le cas où le fragment anticipé viendrait chevaucher des fragments alloués sur d’autres cœurs du calculateur avec lesquels existent des contraintes d’exclusion. Il peut donc être prévu d’affecter une date de démarrage à un fragment si (et notamment uniquement si) ce fragment ne serait pas en chevauchement d’un fragment d’une autre tâche avec lequel il existe une contrainte d’exclusion sur l’intervalle temporel précédent l’intervalle temporel prévu. La FIG. 6 illustre un exemple d’une situation dans lequel le mécanisme d’affectation d’une date de démarrage à un fragment peut être mis en œuvre. Dans cet exemple, on suppose que les tâches B et C possèdent une contrainte d’exclusion. La tâche B a été allouée à un intervalle temporel [3 ; 5], à la suite d’un premier intervalle temporel [0 ; 3] auquel une tâche A a été allouée. La durée de cet intervalle [0 ; 3] a pu être déterminé lors de la construction du squelette du plan d’ordonnancement RSF1 en fonction d’une durée d’exécution prévue pour la tâche A. Ainsi qu’illustré en FIG. 6 , il s’avère que le traitement de la tâche A est plus court que prévu. Dans la situation illustrée, aucun mécanisme d’affectation d’une date de démarrage n’est mis en place : le système d’exploitation anticipe alors le démarrage du fragment correspond à la tâche B afin de bénéficier du temps machine libéré. Il s’ensuit alors que l’exécution de cette tâche B peut provoquer des interférences (accès concurrents à des ressources partagés) avec la tâche C, ce qui peut perturber a minima le fonctionnement de ces deux tâches. La contrainte d’exclusion entre deux tâches prévues par la génération des plans d’ordonnancement devient inopérante du fait de l’anticipation dynamique effectuée par le système d’exploitation RTOS (ne suivant ainsi plus strictement ces plans d’ordonnancement RSF1, RSF2). Dans la situation illustrée par la FIG. 6 , une date de démarrage a été affecté au fragment de la tâche C, qui correspond à la date de début de l’intervalle temporel à laquelle elle a été allouée (c’est-à-dire la valeur 5). Dans ce cas-là, le système d’exploitation RTOS n’anticipe pas le démarrage de ce fragment mais attend la date indiquée avant de démarrer son exécution. Comme il a été vu précédemment, il est possible pour le développeur d’une application temps-réel de définir des exclusions entre tâches, afin d’éviter ou mitiger les interférences. Ce mécanisme d’affectation d’une date de démarrage des fragments, déterminée automatiquement par l’outil d’ordonnancement 20, permet de garantir le respect de ces exclusions même dans le cas où le système d’exploitation RTOS effectuerait des orchestrations dynamiques pendant l’exécution des tâches. Par ailleurs, selon un mode de réalisation de l’invention, on peut affecter à chaque intervalle temporel d’un plan d’ordonnancement une date à partir de laquelle une tâche de fond peut être exécuté. Par définition, une tâche de fond, au contraire d’une tâche (de l’application temps-réel), n’est pas ordonnancée statiquement dans le plan d’ordonnancement. Elle est ordonnancée dynamiquement et exécutée dans le temps laissé disponible au sein d’un intervalle temporel d’ordonnancement, après l’exécution des tâches temps-réelles critiques. L'exécution de ces tâches de fond ne doit pas générer d’interférences temporelles sur d'autres cœurs, et donc de mettre en péril le cloisonnement temporel d'une application. Afin d’éviter ces interférences entre tâches et tâches de fond, le mécanisme d’exclusion précédemment décrit est étendu aux tâches de fond. Plus précisément, l’outil d’ordonnancement 20 est adapté pour affecter une date de fin à au moins les intervalles temporels concernés, cette date de fin correspondant à la date la plus tardive des fragments alloués sur l’intervalle temporel dans l’ensemble des plans d’ordonnancement (c’est-à-dire sur l’ensemble des cœurs du calculateur 30). Cette date de fin délimite l’intervalle temporel en une première partie réservée aux tâches temps-réels, et une seconde partie dans laquelle les tâches de fond peuvent être exécutés (car ne pouvant plus provoquer d’interférences avec d’autres tâches d’autres cœurs). Les FIG. 7 et FIG. 7 illustrent un exemple de deux plans d’ordonnancement, sans et avec affectation d’une date de fin aux intervalles temporels. On suppose dans cet exemple que les tâches de fond D peuvent générer des interférences avec la tâche B. On suppose les plans d’ordonnancement sont subdivisés en trois intervalles temporels [0 ; 3], [3 ; 8] et [8 ; 10]. Sur la FIG. 7 , au sein du plan d’ordonnancement RSF2 relatif au second cœur du calculateur, le premier intervalle temporel est alloué à une tâche C. Le second intervalle temporel n’étant pas alloué à une tâche, le système d’exploitation RTOS déclenche l’exécution de tâche de fond, susceptibles de générer des interférences avec la tâche B, alloué à ce même intervalle temporel sur le plan d’ordonnancement RSF1 associé au premier cœur du calculateur. Sur la FIG. 7 , une date de fin est affectée à ce second intervalle. Cette date de fin a pour valeur la date de terminaison des différents fragments alloués sur l’ensemble des plans d’ordonnancement. Dans cet exemple, un seul fragment est alloué dans cet intervalle temporel : celle de la tâche B. La date de fin pour cet intervalle prend donc pour valeur sa date de terminaison, et le système d’exploitation RTOS utilise cette date de fin pour déclencher l’exécution des tâches de fond D. La description qui précède se base sur le temps pour gérer l’orchestration des déclenchements de l’exécution des tâches (approche « time triggered » en anglais, c’est-à-dire « déclenché par le temps ») Toutefois, au lieu de gérer l’exclusion mutuelle par l’écoulement du temps, il serait possible de s’appuyer sur des mécanismes de synchronisation explicites, tels que des mutex (pour « mutual exclusion » en anglais) ou des sémaphores. À noter qu’une approche « time-triggered » est généralement plus favorable aux approches « event-triggered » (ou « déclenché par événement ») quand la sûreté de fonctionnement est de mise. Cette déclinaison reste particulièrement intéressante car elle est complètement outillée : elle permet d’automatiser l’utilisation de primitives qu’un système d’exploitation met à la disposition des utilisateurs, mais sans offrir de garantie. Ici, notre approche alternative permettrait une utilisation sûre de ces primitives, qui autrement doit être vérifiée manuellement par les développeurs des applications. Les FIG. 8 à FIG. 8 illustrent un autre exemple de déroulement du procédé décrit. La FIG. 8 illustre, sous forme d’un chronogramme, les données temporelles de trois tâches, A, B, C. On suppose en outre les contraintes suivantes : Une contrainte d’exclusion entre les tâches A et B. Une contrainte d’exclusion entre les tâches B et C. La tâche A est allouée au cœur 1 (associé à un plan d’ordonnancement RSF1) La tâche B est allouée au cœur 2 (associé à un plan d’ordonnancement RSF2). La tâche C est allouée au cœur 3 (associé à un plan d’ordonnancement RSF3). La première étape, S1, consiste à, pour chaque cœur, initialiser un plan d’ordonnancement par cœur, respectivement RSF1, RSF2, RSF3, subdivisés en intervalles temporels à partir des données temporelles des tâches prévues pour ce cœur. Dans cet exemple, puisque chaque tâche est implémentée sur un cœur différent, les plans d’ordonnancement des trois cœurs ont les mêmes intervalles que ceux des tâches. L’étape S2 de tri des tâches peut se faire sur la base des dates de terminaison de celles-ci (aucune précédence n’étant indiquée), soit l’ordre A, B, C. Ainsi qu’illustré sur la FIG. 8 , on commence donc à allouer la tâche A, puis la tâche B. En cherchant à allouer la tâche C, on détecte une impossibilité puisque l’intervalle temporel disponible est moins long que le temps d’exécution de cette tâche C. Un mécanisme de retour arrière (« backtracking ») est alors mis en place, en remontant l’arbre des possibilités. On élimine la branche correspondant au tri initial A-B-C, et on sélectionne la branche immédiatement voisine (topologiquement dans l’arbre) : A-C-B. Ainsi qu’illustré sur la FIG. 8 , on alloue donc la tâche A d’abord. Puis la tâche C, ayant une contrainte d’exclusion avec la tâche C, est allouée à sa suite dans le sens du temps. La tâche B ne peut alors plus être allouée car il n’y a plus d’espace vide dans son plan d’ordonnancement RSF2. Le mécanisme de retour arrière est à nouveau utilisé pour explorer une autre branche de l’arbre. En partant de la tâche A, l’ensemble des branches a été exploré, le mécanisme d’exploration détermine donc de débuter par la tâche suivante dans l’ordre initial, c’est-à-dire la tâche B. La première branche à explorer est alors B-A-C. Ainsi qu’illustré sur la FIG. 8 , on commence à allouer la tâche B. Puis on alloue la tâche A, qui possède une contrainte d’exclusion avec la tâche B et est donc alloué à l’intervalle temporel suivant. Puis, on alloue la tâche C. Celle-ci a également une contrainte d’exclusion avec la tâche B, mais pas avec la tâche A. L’intervalle temporel suivant la terminaison de la tâche B est donc disponible pour elle. Elle est donc allouée sur cet intervalle et s’exécute parallèlement à la tâche A. Les trois plans d’ordonnancement RSF1, RSF2, RSF3 obtenus forment donc une solution valable. Le procédé proposé répond donc aux problèmes initialement exposés et présente de nombreux avantages par rapport aux solutions actuelles de l’état de la technique. En particulier, il offre un moyen de mitigation des interférences temporelles par le calcul de plans d’ordonnancement statiques de chacun des cœurs d’exécution, le tout garant d’une exclusion temporelle des accès aux ressources matérielles partagées par les différents traitements hébergés sur des cœurs distincts. Contrairement aux systèmes existants, elle incorpore à cet ordonnancement des contraintes d’exclusion mutuelle permettant une synchronisation sûre et systématique des tâches et de l’ordonnanceur sur l’ensemble des cœurs. Ce procédé répond ainsi à des objectifs du document AMC20-193, applicable aux systèmes numériques aéronautiques critiques basés sur des composants matériels multicœurs. En outre, le procédé proposé permet également de concilier l’ordonnancement des tâches temps-réelles avec des tâches non temps-réelles, tout en préservant les contraintes d’exclusion mutuelle. Un autre avantage est de pouvoir mitiger ces interférences temporelles sans nécessairement modifier l’outil (système d’exploitation RTOS) permettant d’exécuter les tâches sur le calculateur. Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais est défini par les revendications. Elle est notamment susceptible de nombreuses variantes accessibles à l'homme de l'art. Procédé d’ordonnancement d’un ensemble de tâches sur un calculateur multitâche (30), comportant au moins un cœur de traitement, ledit procédé comprenant pour chaque cœur dudit calculateur, initialiser (S1) un plan d’ordonnancement (13) subdivisé en intervalles temporels à partir de données temporelles (12) obtenues pour chaque tâche (11) dudit ensemble prévu pour ledit cœur, allouer itérativement (S3–S11) des fragments de traitement pour chaque tâche prévue pour ledit cœur dans le plan d’ordonnancement respectif, en considérant lesdites tâches dans un ordre dépendant de liens de précédences temporelles définis pour lesdites tâches, et en respectant un ensemble de contraintes consistant : à considérer itérativement chaque intervalle temporel dudit plan d’ordonnancement (13) non encore allouée à une tâche, à positionner lesdits fragments dans ledit plan d’ordonnancement au plus tôt à un instant déterminé à partir desdits liens de précédences temporelles et d’une date de début de ladite tâche définie par lesdites données temporelles, à ne pas positionner lesdits fragments en chevauchement de fragments d'une autre tâche avec laquelle il existe une contrainte d’exclusion, parmi l’ensemble des plans d’ordonnancement, et en déterminant (S10) si la totalité des fragments de traitement de ladite tâche est allouée dans ledit plan d’ordonnancement (13) avant une date d’échéance associée à ladite tâche, définie par lesdites données temporelles transmettre (S13) l’ensemble desdits plans d’ordonnancement (13) audit calculateur (30). Procédé selon la revendication précédente, dans lequel allouer itérativement des fragments de traitement pour chaque tâche prévue pour ledit cœur comprend des étapes de calcul (S4) dudit instant à partir desdits liens de précédences temporelles, par recherche de la plus tardive des dates parmi la date de début de ladite tâche et les dates de terminaison des tâches ayant une précédence sur ladite tâche, détermination (S5) d’une liste des fragments correspondant à des tâches ayant une relation de précédence avec ladite tâche ; sélection (S6) d’un intervalle temporel dudit plan d’ordonnancement (13), et, pour ledit intervalle temporel sélectionné, détermination (S7) d’espaces vides non encore alloués à une tâche, à partir dudit instant, suppression (S8) des espaces vides associés à une contrainte d’exclusion pour ladite tâche, puis allocation (S9) d’espaces vides restants à un fragment de ladite tâche. Procédé selon la revendication précédente, dans lequel si (S10) la somme des durées des intervalles alloués à ladite tâche est inférieur au temps d’exécution associé à ladite tâche et qu’aucun intervalle non encore alloué est disponible avant une date d’échéance associé à ladite tâche, alors on supprime les allocations de ladite tâche et on essaie d’allouer une autre tâche. Procédé selon la revendication précédence, comportant une étape (S2) de tri des tâches dudit ensemble de tâches, et une étape de sélection (S3) d’une tâche selon ledit tri, et dans lequel essayer d’allouer une autre tâche comprend un nouveau tri (S2) desdites tâches, après avoir vérifié (S12) si tous les tris possibles n’ont pas été essayés. Procédé selon la revendication précédente, dans lequel essayer d’allouer une autre tâche comprend un parcours en arbre au sein desdits tris possibles. Procédé selon l’une des revendications 2 à 5, comprenant, lors de l’allocation d’un fragment de traitement, une affectation audit fragment d’une date de démarrage au sein dudit plan d’ordonnancement en fonction de la date de début dudit intervalle temporel sélectionné. Procédé selon la revendication précédente dans lequel ladite date de démarrage est affectée à un fragment uniquement si ledit fragment ne serait pas en chevauchement d’un fragment d’une autre tâche avec lequel il existe une contrainte d’exclusion sur l’intervalle temporel précédent ledit intervalle temporel sélectionné. Procédé selon l’une des revendications précédentes comprenant une affectation d’une date de fin à un intervalle temporel, ladite date de fin correspondant à la date la plus tardive des fragments alloués sur ledit intervalle temporel dans l’ensemble desdits plans d’ordonnancement. Programme d’ordinateur comportant des instructions pour mettre en œuvre un procédé selon l’une des revendications précédentes lorsque celui est exécuté par un processeur d’un équipement de configuration. Equipement de configuration comportant au moins un processeur et des circuits adaptés pour mettre en œuvre le procédé selon l’une des revendications 1 à 8, sous la forme d’un outil d’ordonnancement (20). Calculateur multitâche disposant d’un ensemble de cœurs et adapté pour exécuter un système d’exploitation temps-réel adapté pour exécuter des tâches en fonction d’un ensemble de plans d’ordonnancement déterminés par un procédé selon l’une des revendications 1 à 8. Véhicule comportant au moins un calculateur multitâche selon la revendication précédente.