Brevet FR3159689A1 — publié le 20250829

Procédé d’ordonnancement d’un ensemble de tâches, appartenant à une partition, sur un calculateur multitâche (30) comportant au moins un cœur de traitement, ledit procédé comprenant une détermination (S2), pour chaque tâche, d’une modélisation temporelle contrainte par un ordonnancement de ladite partition au sein d’une ligne temporelle, puis une détermination (S3) d’un ordonnancement statique desdites tâches au sein de ladite ligne temporelle à partir desdites modélisations temporelles et de contraintes temporelles associées à chaque tâche.. Figure pour l’abrégé : Fig. 6 Ordonnancement statique à deux niveaux d’un ensemble de tâches temps-réelles pour un calculateur multitâche multicœur DOMAINE DE L’INVENTION La présente invention concerne les systèmes multitâches 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.) De nombreuses industries spécialisées comme l’avionique, le ferroviaire, l’automobile ou le nucléaire civil ont comme mission de concevoir et de développer de tels systèmes, régis par des standards et normes strictes, qui veillent au bon respect des contraintes de sûreté de fonctionnement, comme l’ISO 26262, l’IEC 60880 ou le DO-178C. Dans le domaine particulier de l’avionique, le standard DO-178C publié 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, spécifie des exigences en matière de systèmes logiciels embarqués. Les systèmes de cette ampleur sont souvent développés selon un schéma industriel de cycle en « V » ou en spirale. Le constructeur détient la feuille de route qui découpe le système final en de multiples composants, dont des entités, parfois multiples, sont responsables de leur livraison. Les sous-systèmes temps-réels de sûreté sont découpés en briques logicielles — ou partitions —, dont la cohérence est assurée par une entité « intégrateur ». Celle-ci réalise en amont une conception temporelle de son système, qui peut être amendée en aval, au fil de l’intégration. Elle s’adjoint à une ségrégation étanche ou poreuse des ressources matérielles (e.g. espace d’adressages, entrées/sorties) entre partitions. En particulier, cette façon de faire permet d’intégrer des applications temps-réelles développées par des entités distinctes (« application suppliers » en anglais, ou fournisseurs d’applications) au sein de partitions séparées, puis en les regroupant dans une phase d’intégration finale (par un « system integrator » en anglais, ou intégrateur système). En avionique civile, le concept IMA (« Integrated Modular Avionics » ) a été défini par le standard DO-297, et permet de concevoir une infrastructure mutualisée (un calculateur) pour une pluralité de traitements temps réels, qui auparavant étaient fournis en autant d’équipement verticaux discrets. Cette infrastructure, ou plateforme, est fournie par un fournisseur de plateforme. L’intégrateur y déploie les applications (développées par des fournisseurs d’applications), de sorte à produire un calculateur autoporteur effectuant ses fonctions. Dans un tel cadre, on comprend que chaque traitement (ou application) peut être associé à des contraintes temporelles inhérentes à sa fonction (fournir une mesure toutes les x millisecondes, par exemple, pour un capteur, etc.) Les systèmes prétendant à remplir une telle fonction d’IMA doivent se conformer au standard DO-297 (ou construire une démonstration de conformité équivalente), et éventuellement suivre des recommandations additionnelles (e.g. AMC 20-170 de l’EASA). Une propriété essentielle des plateformes IMA est de garantir que des partitions développées en indépendance totale les unes des autres se comportent de manière identique une fois mises en commun sur la plateforme. Cette propriété est particulièrement complexe à mettre en œuvre et à garantir. Les garanties d’interopérabilité entre composants et de développement en indépendance totale permettant la conservation de crédits de certification font de la capacité de certification incrémentale un indicateur important de performance industrielle. Pour arriver à de telles propriétés, les systèmes IMA sont construits autour d’un motif d’ordonnancement hiérarchique à deux niveaux (comme spécifié dans l’ARINC-653) : le premier, statique, écrit par l’intégrateur, exprime les contraintes temporelles appliquées aux partitions (donc, aux composants interopérables). Un ordonnancement de second niveau, local aux partitions (donc propre à chaque fournisseur d’applications), s’exprime au sein de ces contraintes temporelles de premier niveau. La définition de la nature de ces plans d’ordonnancements est cruciale pour la bonne marche et la performance industrielle des systèmes IMA. Les plans d’ordonnancement de second niveau peuvent être de nature statique ou dynamique. Une approche statique est souhaitable pour des systèmes critiques, car porteuse de propriétés intéressantes dont la démonstration est ardue avec une approche dynamique. La mise en œuvre d’un double d’ordonnancement statique est particulièrement ardue, et cache des coûts de maintenance conséquents. Par ailleurs, du fait de la multiplicité des intervenants, il est complexe d’établir un plan d’ordonnancement global qui répond à l’ensemble des problématiques. Il existe donc un besoin d’un procédé qui permette de construire automatiquement un plan d’ordonnancement qui répondent à la fois aux contraintes de l’intégrateur liés aux standards et autres exigences en matière de sécurité, notamment dans un cadre avionique, et aux contraintes propres à chaque application logicielle. Un but de l’invention est donc d’améliorer les propositions actuelles de l’état de la technique qui ne permettent pas de gérer de façon satisfaisante le développement et la validation d’une partition associée à une application temps-réel, en vue de son intégration dans un plan d’ordonnancement multi-partitions. . L’invention vise à automatiser au moins en partie À 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, appartenant à une partition, sur un calculateur multitâche comportant au moins un cœur de traitement, ledit procédé comprenant une détermination, pour chaque tâche, d’une modélisation temporelle contrainte par un ordonnancement de ladite partition au sein d’une ligne temporelle, puis une détermination d’un ordonnancement statique desdites tâches au sein de ladite ligne temporelle à partir desdites modélisations temporelles et de contraintes temporelles associées à chaque tâche. Ainsi, le procédé proposé permet de garder les contraintes temporelles des tâches (donc des applications logicielles) dissociées des contraintes temporelles de haut niveau fixées par l’intégrateur. Autrement dit, il s’agit de permettre à l’entité en charge du développement d’une application destiné à un système d’avionique intégré modulaire, IMA, de déterminer au plus tôt si son application est conforme aux paramètres d’ordonnancement imposés par la plateforme, et, donc, compatible avec les fonctionnements des autres applications qui seront également déployées sur le même système IMA (c’est-à-dire sur un même calculateur multitâche multicœur). 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 : ladite ligne temporelle est fournie sous la forme d’une structure de données spécifiant un découpage du temps en intervalles temporels, chaque intervalle temporel pouvant être individuellement affecté à une unique partition. le procédé comporte en outre une phase préalable d’ordonnancement de ladite partition au sein de ladite ligne temporelle, comportant elle-même une spécialisation de ladite ligne temporelle à ladite partition, un recalage de ladite ligne temporelle, puis une fusion des intervalles temporels vides. ledit modèle temporel est un graphe d’états temporels, et ladite détermination comprend une création d’un premier graphe d’états temporels, puis une modification itérative dudit premier graphe d’états temporels en utilisant ledit ordonnancement de ladite partition au sein de ladite ligne temporelle. ladite modification itérative comprend une fragmentation d’un arc dudit graphe d’états temporels si ledit arc n’est pas totalement inclus dans un intervalle dudit ordonnancement de ladite partition au sein d’une ligne temporelle. Un autre objet de l’invention concerne un calculateur adapté pour utiliser les plans d’ordonnancement produit 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 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 des circuits adaptés pour mettre en œuvre le procédé tel que décrit, sous la forme d’un outil d’ordonnancement (20). 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 dans lequel s’insère le procédé proposé, selon un mode de réalisation. Les FIG. 3 à FIG. 3 représentent un exemple de plan d’ordonnancement. La FIG. 4 illustre un exemple de ligne temporelle selon un mode de réalisation. Les FIG. 5 à FIG. 5 illustrent le déroulement de certaines étapes du procédé décrit sur un exemple de ligne temporel pour une partition donnée. La FIG. 6 représente un organigramme d’un procédé selon un mode de réalisation. La FIG. 7 représente un graphe d’états temporels selon un mode de réalisation. La FIG. 8 illustre un exemple d’application d’une étape de fragmentation selon un mode de réalisation du procédé proposé. La FIG. 9 illustre un exemple de résultat possible à l’issue d’une phase de détermination d’une modélisation temporelle selon un mode de réalisation du procédé proposé. Les FIG. 10 à FIG. 10 illustrent un autre exemple d’application du procédé proposé. Les FIG. 11 et FIG. 11 illustrent des exemples pour une étape de linéarisation des modélisations temporelles des tâches. 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. Un exemple d’un tel outil d’orchestration peut être l’outil ASTERIOS™ RTK qui permet d’exécuter un ensemble de tâches temps-réel sur un calculateur multicœur en respect d’un plan d’ordonnancement, par exemple fourni par un autre outil de la chaîne outillée (ASTERIOS™ Développer). 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 telles 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 UAV pour « Unmaned aircraft vehicle » en anglais, ou encore UAS pour « Unmaned Aircraft System »). 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és 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 selon une contrainte de répétition. 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 fenêtre temporelle prévue 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 leur propre sortie. 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és. 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, ou noyau temps-réel, RTK (pour « Real-Time Kernel » en anglais), 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, ou le noyau temps-réel, RTK, 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. Il permet notamment la déclaration de tâches temps-réelles, la définition de canaux de communication entre plusieurs tâches et permet d’associer des contraintes temporelles aux déclarations impératives du langage C. Il a été présenté pour la première fois dans l’article de Vincent David, Jean Delcoigne, Evelyne Leret, Alain Ourghanlian, Philippe Hilsenkopf et 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, p. 45-59. doi: 10.1007/3-540-49646-7_4. 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 contrainte 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 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 au temps 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 interrompue (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’un, 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 taches. Dans le cas où ces tâches préalables (ou précédentes) ont une exécution tronçonnée en plusieurs fragments, ou trames, 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 mitiger, voire supprimer, les interférences entre tâches. Autrement dit, il est proposé de permettre aux développeurs d’applications temps-réels de définir et spécifier 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. Le langage PsyC permet d’ajouter des identifiants pour les instructions « advance », sous la forme @ advance … Les instructions advance permettent la déclaration de contraintes de synchronisation, fixant l’échéance des instructions qui les précèdent et déterminant les dates de début au plus tôt de celles qui suivent. Un mécanisme d’annotations, préfixé par « @ » permet de nommer une instruction advance . D’avantage d’informations peuvent être trouvé dans la thèse de Jean Guyomarc’h, « Analyse de systèmes temps-réels de sûreté et mitigation de leurs interférences temporelles », http://www.theses.fr/2021UPASG070 , octobre 2021. Dans la configuration JSON, on peut utiliser les identifiants des instructions « advance » pour définir des actions élémentaires. 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é 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 fournier une structure de données fournissant des données temporelles comprenant, pour chaque tâche (ou action élémentaire d’un agent), 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 et les contraintes d’exclusion. Selon un mode de réalisation basée sur la suite logicielle ASTERIOS™ développé par la société Asterios Technologies (anciennement Krono-Safe), ces données temporelles peuvent prendre la forme d’un graphe appelée 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 combinaison 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-plans, 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 Ce plan d’ordonnancement peut ensuite être transmis, ou provisionné, dans le calculateur multicœur 30. Le système d’exploitation temps-réel outillé R-TOS peut alors utiliser ce plan d’ordonnancement pour orchestrer l’exécution des différentes tâches installées. Le procédé proposé vise donc à déterminer un plan d’ordonnancement, pour chaque cœur du calculateur 30 qui respecte à la fois les données temporelles (notamment des contraintes temporelles, ainsi que mentionné précédemment) de chaque tâche et le plan de premier niveau d’ordonnancement des partitions définis par la plateforme. Pour rappel, une partition est constituée d’un ensemble de tâches temps-réelles disposant d’un cadencement qui leur est propre ; ces cadencements servent, in fine, à mettre en œuvre une exécution time-triggered (déclenchée, ou contrôlée, par le temps) de ces tâches. On peut en général assimiler une partition à une application temps-réel. D’un point de vue industriel, chaque partition peut être assignée à une entité (un sous-traitant), un fournisseur d’applications, en charge du développement d’une application. Les partitions permettent d’isoler chaque application les unes des autres, et à chaque fournisseur d’application de déterminer un ordonnancement local à cette partition en fonction des contraintes temporelles des tâches de son application. Toutefois, comme on a vu, l’enjeu est de concilier ces plans d’ordonnancement « locaux » de l’ensemble des partitions pour un déploiement sur un même calculateur. Créer un plan d’ordonnancement statique de second niveau nécessite de construire le comportement temporel des tâches en fonction de la topologie du plan d’ordonnancement de premier niveau. Selon l’état de la technique, une construction manuelle du plan d’ordonnancement implique nécessairement un micro-design : l’implémentation du comportement temporel des tâches d’une partition va être sur-contrainte par le plan d’ordonnancement statique de premier niveau. Il n’existe pas actuellement de solution outillée permettant d’automatiser leur génération, et donc de soulager les développeurs des partitions de ces problématiques. Les FIG. 3 à FIG. 3 représentent un exemple de plan d’ordonnancement illustrant la problématique d’un ordonnancement à deux niveaux. La FIG. 3 montre un plan d’ordonnancement statique de premier niveau, au sein duquel s’exécutent deux partitions, P1 et P2. Typiquement, un tel plan d’ordonnancement comporte une première partie appelée « tête » exécuté qu’une fois (ici de la date 0 à la date 1) et une seconde partie, appelée « boucle » qui est exécuté de façon répétitive (ici, de la date 1 à la date 9). La spécification temporelle de haut niveau déterminée par l’intégrateur est : « la partition P1 dispose d’une durée d’exécution de 2, et une fréquence d’exécution de 8 ». Une lecture possible du plan d’ordonnancement statique pour P1 est : P1 s’exécute à partir de la date 3, pendant une durée de 2. Après avoir terminé, P1 reprend son exécution après 6 unités de temps. On est donc bien conforme à la spécification. La partition P2 correspond à une durée d’exécution de 1 unité de temps et une fréquence d’exécution de 8 unités de temps. Si l’on se concentre sur cette partition P1, l’entité en charge de son développement n’a, en principe, qu’à se concentrer sur la manière d’implémenter sa fonctionnalité. Dans cet exemple, on suppose une tâche T1 qui s’exécute avec une période de 8 unités de temps, pendant une durée totale de 1,5 unités de temps. A noter que ces spécifications temporelles relèvent du métier de l’entité (développeur d’application) en charge de la partition P1, et qu’elles sont formulées ici en indépendance complète du plan d’ordonnancement de premier niveau. Selon l’état de l’art, l’utilisation d’un ordonnancement dynamique au sein de la partition P1 permet au développeur de cette partition P1 de faire effectivement abstraction du premier niveau. Mais il demeure délicat d’apporter la preuve du respect des contraintes temporelles, ce qui est problématique en environnement critique. Par contre, pour construire un plan d’ordonnancement statique il faut maintenant que le développeur de la partition P1 connaisse avec précision la topologie du plan d’ordonnancement choisie par l’intégrateur (illustré en FIG. 3 ). La FIG. 3 montre un exemple de plan d’ordonnancement statique que le développeur de la partition P1 doit écrire manuellement. On suppose qu’ensuite, l’intégrateur choisisse de modifier, non pas ses exigences temporelles de haut niveau mais son plan d’ordonnancement de premier niveau, par exemple comme illustré par la FIG. 3 . Ce nouveau plan d’ordonnancement de premier niveau est toujours parfaitement compatible avec les contraintes temporelles de haut niveau précédemment indiquées : la partition P1 dispose d’une durée totale d’exécution de 2 et d’un motif d’exécution périodique de 8. Pour l’intégrateur, cette modification est donc mineure et ne remet pas en cause un contrat établi avec le développeur de la partition P1 puisque les contraintes temporelles de haut niveau négociées ne sont pas impactées. Toutefois, on constate que le plan d’ordonnancement de second niveau proposé initialement par le développeur de la partition P1 est complètement invalide puisque sa proposition est incompatible avec le nouveau plan d’ordonnancement de premier niveau. En effet, l’allocation d’un intervalle de 1.5 unités de temps pour la tâche T1 n’est plus compatible avec les deux intervalles correspondant à la partition P1, chacun d’une durée de 1 unité de temps. Il respecte pourtant bien la spécification temporelle de haut niveau. En revanche on voit bien que se plier à la topologie du plan d’ordonnancement de premier niveau impose des contraintes supplémentaires sur le développement de P1, dont la prise en compte peut être coûteuse. A titre d’exemple, la FIG. 3 illustre un plan d’ordonnancement de second niveau de la partition P1 compatible de ce nouveau plan de premier niveau. Cette nouvelle découpe a nécessité une préemption de la tâche T1. Autrement dit, cette tâche a été subdivisée en deux tronçons exécutables, chacun alloué sur un des deux intervalles de temps attribuée à la partition P1. En effet, outre le besoin d’écrire ce nouveau plan d’ordonnancement de second niveau, c’est également le comportement de la tâche T1 qu’il faut segmenter pour s’exécuter en deux fois. Dans une approche dynamique, cette segmentation se fait à l’exécution sans connaitre à l’avance sa position dans le code. Inversement, avec un ordonnancement statique, il faut le faire spécifiquement. On parle alors de micro-design, qui est une sur-spécification du besoin initial du fait de contraintes de bas biveau (ici le plan d’exécution de premier niveau). Cela nécessite donc une intervention supplémentaire du développeur de l’application qui doit redéfinir la conception de son application (voire partiellement la redévelopper afin de l’adapter à ses nouvelles contraintes temporelles). Du fait de ce micro-design nécessitant une modification substantielle de l’application, une nouvelle certification de l’application est nécessaire (selon les exigences habituelles pour des systèmes critiques tels que les systèmes avioniques). L’objectif de certification incrémentale est alors remis en cause. Il apparaît aux inventeurs que si avec une seule tâche, une telle modification reste tractable, composer avec plusieurs dizaines de tâches qui peuvent être apériodiques, avec des contraintes de cadence et de latence hétérogènes, préemptibles ou non préemptibles, avec des contraintes de précédence et éventuellement des contraintes d’exclusion mutuelle, rend l’opération particulièrement laborieuse sans assistance outillée. Il apparait donc crucial de pouvoir proposer un mécanisme de génération automatique de plans d’ordonnancement qui soient compatibles avec ces différents niveaux de contraintes. Notamment, il est proposé un procédé permettant d’abstraire la conception temporelle des applications des contraintes temporelles du plan d’ordonnancement de premier niveau défini par l’intégrateur. Ainsi, un changement de celui-ci n’a plus d’impact sur les applications telles que définies par leur code en PsyC (par exemple). La vérification de la cohérence temporelle et spatiale d’un système IMA est réalisée lors de phases de V&V durant l’intégration système. Elles nécessitent des tests sur cible, possiblement sur bancs de tests. Pouvoir détecter bien en amont une violation des contrats temporels et spatiaux passés entre partitions et intégrateur permettrait de réduire avantageusement les coûts d’intégration, une erreur étant d’autant moins couteuse qu’elle est détectée tôt dans le « cycle en V ». Le procédé proposé, par ricochet, permet de faire bénéficier à l’intégrateur de moyens de vérification automatique du bon respect des partitions vis-à-vis des contrats fixés avec les partitions. En particulier en ce qui concerne le contrat temporel, on peut détecter en amont si chaque partition est bien conforme au plan d’ordonnancement de premier niveau. Cette vérification peut découler directement de l’analyse systématique des plans d’ordonnancement statiques aux premiers et seconds niveaux. Dans l’exemple illustré par les FIG. 3 à FIG. 3 , si l’on suppose qu’une contrainte d’atomicité est attachée à la tâche T1 (c’est-à-dire que celle-ci ne peut pas être divisée dans un plan d’ordonnancement), alors la situation proposée en FIG. 3 violerait cette contrainte. Grâce au mécanisme proposé, cette erreur d’intégration peut être détectée très tôt dans le processus d’intégration. Cela n’aurait pas été possible avec un ordonnancement dynamique au second niveau, sans effectuer une exécution sur cible matérielle ou sur émulateur, mais dans tous les cas bien plus en aval du processus d’intégration. Selon un mode de réalisation, dans un premier temps, l’intégrateur rédige le contrat de partitionnement temporel (et spatial, si besoin) appelé ligne temporelle, ou ligne de temps, ou encore « timeline » selon le vocabulaire anglais habituel. Ces spécifications peuvent être fournies en langage PsyC. Le langage PsyC est un langage informatique défini par la société Asterios Technologies (anciennement Krono-Safe) et adapté pour produire des fichiers pouvant être utilisés 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. Le compilateur PsyC 10 peut générer cette ligne temporelle (« timeline ») à partir de ces fichiers sources PsyC, qui est destiné à être transmis à l’ensemble des acteurs développant des partitions. C’est sous cette forme que sont portés les contrats de partitionnement temporels. A ces contrats peuvent également être adjoints d’autres contrats portant sur d’autres domaines (ségrégation spatiale, etc.). La ligne temporelle peut être fournie sous la forme d’une structure de données spécifiant un découpage du temps en intervalles temporels, chaque intervalle temporel pouvant être individuellement affecté à une unique partition. Une ligne temporelle peut être prévue pour un cœur donné du calculateur cible. On peut ainsi découper le temps disponible sur un cœur en fenêtres de temps, chacune pouvant être dédiée à une partition. Une grammaire possible permettant de décrire une ligne temporelle dans un dialecte du langage PsyC peut être : timeline_decl : " timeline " " identifier " '(' timeline_parameter_list ')' '{' partition_decl_list '}' timeline_parameter : " uses " " identifier " | " defaultclock " " identifier " | " starttime " expr_long opt_with_clock_def | " period " duration_expr | " period " expr_long timeline_parameter_list : timeline_parameter | timeline_parameter ',' timeline_parameter_list partition_decl : " partition " " identifier " ',' partition_parameter_list ';' partition_parameter_list : partition_parameter_list ',' partition_parameter | partition_parameter timeslot_decl : " timeslot " " identifier " ',' timeslot_parameter_list timeslot_offset_parameter : " offset " duration_expr | " offset " expr_long timeslot_duration_parameter : " duration " duration_expr | " duration " expr_long timeslot_parameter_list : timeslot_offset_parameter ',' timeslot_duration_parameter | timeslot_duration_parameter ',' timeslot_offset_parameter partition_parameter : timeslot_decl partition_decl_list : partition_decl_list partition_decl | partition_decl Bien évidemment, il ne s’agit là que d’un exemple, et de nombreuses variantes de cette grammaire sont possibles. De même, d’autres formalismes peuvent être utilisés pour décrire une ligne temporelle, que cela soit à l’aide du langage PsyC ou d’autres langages équivalents. La FIG. 4 illustre un exemple de ligne temporelle. Cette ligne temporelle correspond au code PsyC suivant, donné selon le formalisme défini par la grammaire donné précédemment : source realtime_us ; clock clk_ms = 1000 * realtime_ms ; timeline T (uses realtime_us , defaultclock clk_ms , starttime 1, period 8) { partition P1 , timeslot a, offset 2, duration 2; partition P2 , timeslot b, offset 6, duration 1; } Ce code décrit une ligne temporelle qui est statiquement allouée à un cœur, via un système de configuration déclaratif compris par le compilateur PsyC. La ligne temporelle T est définie comme disposant de deux fenêtres temporelles (appelées « timeslots »), a et b, qui hébergent respectivement les tâches des partitions P1 et P2 configurées pour s’exécuter sur le cœur mobilisé par la ligne temporelle T. Topologiquement, chaque ligne temporelle est constituée de deux parties : une « tête » et une « boucle ». La boucle consiste en un motif répétitif démarrant à une date particulière, fixée par le mot-clef « starttime » et d’une longueur déterminée par le mot-clef « period » dans l’en-tête de la ligne temporelle. Seule la boucle permet d’exécuter le code de partitions. Sur l’ensemble des figures illustrant la Description, la boucle est illustrée par une flèche partant de la fin de la ligne temporelle et rebouclant sur le début de cette partie. La tête est donc définie par la partie entre le début de la ligne temporelle et le jalon où termine cette flèche, c’est-à-dire au début de la boucle. Ainsi, dans cet exemple, la partition P1 est ordonnancée dans un intervalle [3 ; 5] de la ligne temporelle, et la partition P2 est ordonnancée dans un intervalle [7 ; 8] de cette ligne temporelle T. Selon un mode de réalisation, les différents fichiers PsyC décrivant les lignes temporelles des cœurs sont compilés en un fichier unique, qui fait office de contrat temporel formalisé. A ce contrat est adjoint un contrat de nature spatiale, garant de la ségrégation spatiale entre partitions ; cette dernière partie est indispensable pour l’aspect de certification incrémentale, mais n’est pas essentielle pour la génération des plans d’ordonnancement. La FIG. 6 représente un organigramme d’un procédé selon un mode de réalisation. Le procédé décrit concerne une partition donnée, car la validation et l’intégration peuvent se faire individuellement, partition par partition. Traiter une pluralité de partitions revient alors à itérer ce processus sur les partitions à considérer. Une phase S2 comprend la détermination, pour chaque tâche d’une partition P, d’une modélisation temporelle contrainte par un ordonnancement de cette partition au sein d’une ligne temporelle. Puis, une phase S3 comprend la détermination d’un ordonnancement statique de ces tâches au sein de la ligne temporelle à partir des modélisations temporelles précédemment obtenues et de contraintes temporelles associées à chaque tâche. Préalablement, une phase S1 peut comprendre la détermination de l’ordonnancement de cette partition au sein de la ligne temporelle. Selon un mode de réalisation, cette phase S1 comprend une étape S11 de personnalisation de la ligne temporelle à la partition P1 traitée, une étape S12 de recalage de la ligne temporelle, et une étape S13 de fusion des intervalles temporels. La structure finale, issue de la ligne temporelle, est propre à la partition considérée et peut être appelée RST (pour « Repetitive Sequence of Timeslots » en anglais, c’est-à-dire « séquence répétitive d’intervalles temporels »). Cette RST représente donc l’ordonnancement de la partition considérée au sein de la ligne temporelle. Les FIG. 5 à FIG. 5 illustrent le déroulement des étapes S1-S3 sur un exemple de ligne temporel pour une partition P1. La FIG. 5 représente la ligne temporelle initiale comportant deux partitions, P1, P2. Dans la première étape S11, on spécialise la ligne temporelle en ne conservant que les intervalles temporels alloués (ou exécutant) la partition P1 considérée. Les intervalles temporels alloués à d’autres partitions sont remplacés par des intervalles temporels vides. On obtient ainsi la ligne temporelle illustrée en FIG. 5 . Dans l’étape S12, on cherche à minimiser le nombre d’intervalles temporels (ou « timeslots » en anglais) vides (c’est-à-dire qui n’exécutent aucune partition), afin de simplifier au maximum la structure de données et conserver l’essence de spécification temporelle relative à la partition P1 considérée. Aussi, on modifie la topologie de ce premier résultat de calcul, de sorte que le motif répétitif débute lors de l’exécution du premier intervalle exécutant la partition P1. Pour cela, on parcourt une première fois la séquence répétitive d’intervalles temporels RST afin d’en déduire la première date à laquelle un intervalle exécutant P1 est mobilisé. Dans l’exemple plus haut, cette date est 3. On calcule la durée entre le début de la boucle et la date précédemment obtenu. Dans l’exemple plus haut, cette durée est de 2, la boucle débutant à la date 1 (calcul : 3 – 1). Si cette date n’est pas zéro, pour conserver l’intégrité du motif périodique, on recopie le ou les intervalles couverts entre ces deux dates, et on place ces copies à la fin de la boucle (ici, l’intervalle [9 ; 11]. On modifie ensuite la date de début de boucle pour qu’elle coïncide avec la date d’exécution du premier intervalle de P. On obtient ainsi la ligne temporelle illustrée en FIG. 5 . Enfin, l’étape S13 consiste à fusionner les intervalles temporels vides adjacents. On peut en effet chercher à minimiser le nombre de fenêtres « vides » consécutives pour simplifier encore la structure. On effectue un parcours linéaire de la RST précédemment obtenu. On détermine ainsi les intervalles adjacents vides, et on modifie la RST de sorte à les fusionner. On obtient ainsi l’artéfact RST illustré en FIG. 5 . La deuxième phase S2 comprend la détermination d’une modélisation temporelle de chaque tâche de la partition P1 considérée, cette modélisation étant contrainte par l’ordonnancement de la partition dans la ligne de temps tel que, par exemple, défini dans la RST déterminé en phase S1. En particulier, les tâches (ou actions élémentaires des agents) sont compilées selon la RST correspondant à la partition qui les contient (pour un cœur donné ; on rappelle que les tâches sont liées statiquement à un seul cœur du calculateur cible), c’est-à-dire selon l’ordonnancement de cette partition au sein de la ligne temporelle. Une tâche est classiquement compilée sous la forme d’une modélisation temporelle. Cette modélisation temporelle est basée sur les dates absolues ou relatives déterminées par le code de la tâche. Les dates absolues sont celles fournies dans le code selon une horloge. Les dates relatives correspondent à des durées fournies à partir d’une autre date (absolue ou relative). Cette modélisation temporelle est typiquement un graphe d’états temporels. On peut ainsi considérer que les nœuds de ces graphes correspondent à des dates logiques qui bornent les calculs de la tâche, matérialisés par les arcs joignant deux nœuds. Aux arcs peuvent donc être associés les durées indiquées dans le code, correspondant à des temps de calcul. Pour illustrer la notion de modélisation temporelle, on peut prendre un exemple de code en langage PsyC suivant : clock clk_ms = 1000 * realtime_ms ; agent Task ( uses realtime , defaultclock clk_ms , starttime 3) { if ( condition ) { advance 8; advance 8; } else { advance 16; advance 8; } } Ainsi, ce code contient des dates absolues (le jalon « starttime »), et des dates relatives données par le mot-clé « advance »). Une étape S21 consiste à déterminer une première modélisation temporelle, par exemple un graphe d’états temporels, à partir du code de la tâche. Les étapes suivantes S22-S25 de la phase S2 vont ensuite effectuer des traitements modifiant cette première modélisation, en utilisant la séquence répétitive d’intervalles temporels RST déterminé en phase S1, afin de déterminer une modélisation temporelle finale de la tâche, contrainte par cette RST. La FIG. 7 représente un graphe d’états temporels qui peut être construit à partir de l’exemple de code donné ci-dessus. Les nœuds S (pour « Start », commencement de la tâche), A, B, C correspondent aux différents états temporels qui découlent de ce code. Les arcs correspondent aux traitements permettant de passer d’un état à un autre. Les valeurs affectées aux arcs correspondent aux durées pour passer d’un état à un autre, indiquées par les mots-clés « advance » dans le code. La condition (« if ») dans le code représente l’alternative, dans la FIG. 7 , de passer de l’état A vers l’état B ou vers l’état C. La construction d’un tel graphe d’états temporels découle de l’état de la technique correspondant à la suite logicielle ASTERIOS™. Elle est en particulier décrite dans la documentation de cette suite logicielle, ainsi que par exemple dans la demande de brevet WO2014/170569 déposée par la société Krono-Safe (maintenant Asterios Technologies). Les étapes S22-S26 consistent à effectuer une projection de ce modèle temporel sur la séquence répétitive d’intervalles temporels RST, afin d’obtenir une modélisation temporelle contrainte par cette séquence RST. Les étapes S22-S24 sont itératives afin de parcourir l’ensemble du modèle temporel (en particulier du graphe d’états temporels). Une étape S22 consiste à sélectionner un arc du graphe d’états temporels, et un intervalle de l’ordonnancement de la partition dans la ligne temporelle (c’est-à-dire de la séquence RST de cette partition). Pour ce faire, le processus itératif peut débuter au premier arc et au premier intervalle, selon l’ordre chronologique, puis parcourir les deux structures en parallèle, toujours selon l’ordre chronologique, et conformément à des règles de parcours. En particulier, cette étape consiste à explorer de manière synchrone le graphe d’états temporels et la RST. On réalise une opération assimilable à un produit synchrone : on associe à chaque graphe une date (Da pour le graphe d’états et Di pour la RST). A chaque mise à jour de Da et Di, on déroule les étapes S23, S24, S25 pour chaque paire d’arc temporel et d’intervalle de la RST exécutables à ces dates. Da et Di sont mis à jour en fonction des branchements temporels disponibles : - on passe à l’arc suivant seulement si celui-ci ne termine pas son exécution au sein de l’intervalle considérée de la RST ; - on passe à l’intervalle suivant une fois que tous les arcs pouvant débuter dans l’intervalle ont été considérés ; - si plusieurs arcs sont disponibles à une même date (plusieurs branchements possibles), l’un des choix est sélectionné ; lorsque tous les chemins temporels possibles auront été couverts, cette exécution s’arrête et l’autre option sera prise, et ce de manière récursive. L’étape S23 consiste à tester, pour chaque paire itérativement visitée, si l’arc du graphe d’états temporels est inclus ou non dans l’intervalle considérée de la RST. Si on considère un arc A=[a, b], a et b étant ses bornes temporelles, et un intervalle I=[c, d] de la RST, c et d étant ses bornes temporelles, alors on peut définir que l’arc A est inclus dans l’intervalle I si et seulement si a≥c et b≤d. Dans le cas où un arc A n’est pas inclus dans l’intervalle I, alors l’étape S24 est mise en œuvre pour fragmenter cet arc. Lorsqu’un arc n’est pas totalement inclus dans un intervalle, alors cet arc A est fragmenté en deux arcs, A1, A2, de sorte qu’un de ces deux arcs soit inclus dans l’intervalle. Autrement dit, on fragmente l’arc A en une date correspondant à une des bornes de l’intervalle I considérée. La FIG. 8 illustre un exemple d’application de cette étape de fragmentation S24. L’arc A=[a, b] n’est pas inclus dans l’intervalle I=[c, d]. Il est donc fragmenté en deux arcs A1, A2 de sorte que l’arc A1 soit inclus dans l’intervalle I. La date de fractionnement correspond à une borne d de l’intervalle I. On a ainsi A1=[a, d] et A2=[d, b]. L’arc A2 sera considéré dans une itération subséquente et, dans le cas où il n’est pas inclus totalement dans un intervalle (suivant l’intervalle I), il est à nouveau fractionné. Lorsque l’ensemble des arcs ont été visités, on peut mettre en œuvre l’étape S25 (toutefois, selon d’autres modes de réalisation, cette étape S25 d’étiquetage peut être mise en œuvre en même temps que le parcours itératif des étapes S22-S24). L’étape d’étiquetage S25 consiste à attribuer à chaque arc une étiquette, ou valeur, représentant si l’arc est inclus ou non dans un intervalle temporel de la RST allouée à une exécution de la partition considérée. Plus particulièrement, on analyse l’ensemble des arcs, y compris ceux fragmentés. Pour chacun de ces arcs, on étudie la nature de l’intervalle de la RST auquel ils sont associés. Si l’intervalle est vide, l’arc A est marqué comme non-exécutable, c’est-à-dire qu’aucun code exécutable (notamment celui des agents PsyC) ne pourra y être alloué lorsque le processus de génération des plans d’ordonnancement interviendra. Inversement, si l’intervalle héberge la partition P (ce qui est le seul autre cas possible), A est marqué comme exécutable. La FIG. 9 illustre un exemple de résultat possible à l’issue de cette phase S2 de détermination d’une modélisation temporelle contrainte par l’ordonnancement de la partition au sein de la ligne temporelle. Sur cette FIG. 9 sont représentés le graphe d’états temporels modifiés par les étapes itératives S22-S24 à partir du graphe illustré en FIG. 7 , ainsi que la RST de la partition concernée en dessous. Les états temporels A d’une part et B et C d’autre part sont calés sur les bornes respectives de l’intervalle temporel dédié à la partition dans la ligne temporelle. Les petits ronds représentent les fractionnements des arcs (étape S24). Ainsi, l’arc initial entre les états A et B est associé à une durée (« advance ») de 8. Or l’intervalle [3 ; 5] dédié à la partition a une durée de 2. Il doit donc être fractionné en un premier intervalle sur les dates [3 ; 5], de durée 2, puis un second intervalle de durée 6 correspondant à du temps allouable au sein de cette partition (c’est-à-dire l’intervalle [5 ; 11]). De même, l’arc initial entre les états A et C est associé à une durée de 16. Il est fractionné une première fois en un arc de durée 2 et un arc d’une durée de 14, correspondant au reliquat. Selon les règles de parcours susmentionnées, cet arc est ensuite comparé à l’intervalle suivant de la RST, qui a une durée de 6. L’arc est donc fractionné à nouveau en un arc d’une durée de 6 et en un arc d’une durée de 8 (c’est-à-dire 14-6) correspond au reliquat. Cet arc d’une durée de 8 est ensuite comparé à l’intervalle suivant qui est (puisque la RST forme une boucle) l’intervalle [3 ; 5] (modulo 8) allouée à l’exécution de la partition. Cet arc est à nouveau fractionné en un arc d’une durée de 2 et un arc d’une durée de 6. Ce dernier arc étant inclus dans l’intervalle suivant [5 ; 11], le processus peut s’interrompre. On obtient alors la séquence représentée en FIG. 9 . Les doubles flèches correspondent aux arcs qui ont pu être mis en correspondance avec l’intervalle [3 : 5] (au modulo près) qui est alloué à l’exécution de la partition. Ces doubles flèches correspondent donc aux arcs exécutables. Les autres flèches (simples) correspondent aux arcs non-exécutables. L’étape S26 consiste à « linéariser » le modèle temporel obtenu à l’étape S25 afin d’obtenir un modèle final. Ce modèle final peut ensuite être utilisé par la phase S3 de détermination d’un ordonnancement statique de la tâche au sein de la ligne temporelle. En particulier, un mécanisme existant peut être utilisé pour implémenter cette phase S3, comme par exemple celui de la suite logicielle Asterios™. Dans une telle mise en œuvre, le modèle temporel de la tâche peut être un RATS pour « Repetitive Agent Temporal Sequence » en anglais (ou séquence temporelle répétitive d’agent). Cette modélisation temporelle représente essentiellement un plan d'ordonnancement partiel pour la tâche. Elle comporte une série d'intervalles 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. Du fait de la contrainte imposée par la RST (issue de la contrainte de ne pouvoir exécuter une tâche que lorsque la partition associée est exécutée par le cœur, donc planifiée dans la ligne temporelle), la longueur de la tête devient fonction de la longueur de tête de la RST, et la longueur de la boucle devient fonction de la longueur de boucle de la RST. Plus précisément, la longueur de tête du RATS correspond au maximum de la longueur de tête de la modélisation temporelle initiale de la tâche (issue de son code) et de la longueur et la tête de la séquence RST. La longueur de boucle du RATS correspond au PPCM (Plus Petit Commun Multiple) de la longueur de boucle de la modélisation initiale et de la longueur de boucle de la séquence RST. Cette étape de linéarisation, S26, peut être mise en œuvre de différentes façons. L’idée repose sur une réécriture des modélisations temporelles, RATS, des tâches de sorte à ce qu’un seul arc sorte de chaque nœud. Pour ce faire, on associe deux informations à chaque arc : une durée D et un budget B. La durée D peut se traduire par une fenêtre temporelle au sein de laquelle on peut allouer un temps d’exécution effectif de durée B. Sur les FIG. 11 et FIG. 11 , on note les budgets et durées associés à un arc en les séparant par le signe « + » (B+D), par souci de concision. On parcourt le graphe depuis son point d’entrée (c’est un nœud particulier, identifié a priori comme tel), qui correspond au point d’entrée d’un agent. On explore récursivement le graphe en suivant les arcs. L’exploration s’arrête lorsque le graphe est pleinement linéarisé. On considère les arcs sortants d’un même nœud deux à deux. Si les arcs ont la même durée, on les fusionne. L’arc résultant a ainsi une durée D et un budget qui correspond au maximum des budgets des deux arcs fusionnés. La FIG. 11 illustre une telle situation dans laquelle les arcs de budget B1, B2 respectivement et de même durée, 1, sont fusionnées en un arc de budget max(B1, B2) et de durée 1. Si les arcs à fusionner ont des durées différentes, on fragmente l’un ou l’autre (voire les deux), de sorte à obtenir des arcs que l’on peut fusionner ensemble, selon la méthode au point précédent. Lorsqu’un arc (B+D) est fragmenté en deux arcs (B1+D1) et (B2+D2), on pose B=B1+B2 et D=D1+D2. Dans l’exemple illustré en FIG. 11 , l’arc B1+2 est ainsi fragmenté en un premier arc B1’+1 et un second arc B1’’+1 avec B1=B1’+B1’’. Le premier arc, B1’+1 peut ensuite être fusionné avec l’arc B2+1 selon le mécanisme décrit précédemment. Ce mécanisme de linéarisation pour la détermination de modélisations temporelles, RATS, est décrit avec davantage de précisions dans la demande de brevet WO2014/167197. L’étape S3 consiste à déterminer un ordonnancement statique de l’ensemble des tâches d’une partition au sein de la ligne temporelle à partir des modélisations temporelles (RATS) de chacune de ces tâches, obtenues en étape S25 et linéarisés en étape S26, et de contraintes temporelles associées à chaque tâche. Comme évoqué précédemment, ces contraintes temporelles peuvent comprendre, pour une tâche, Une contrainte de réveil, Une contrainte d’échéance, Une contrainte de temps d’exécution, Une contrainte de précédence. Comme indiqué précédemment, cette phase S3 peut être mise en œuvre par les outils de la suite logicielle ASTERIOS™. En particulier, les algorithmes décrits dans la demande de brevet WO2014/170569A1 peuvent être mis en œuvre. Dans une telle situation, le procédé proposé peut donc se greffer sur un mécanisme existant mais prépare les données d’entrée avant que ce mécanisme soit forcé de produire, en sortie, un ordonnancement statique vérifiant la contrainte supplémentaire d’un ordonnancement d’une tâche dans les intervalles temporels alloués à sa partition. Selon un mode de réalisation particulier, cette phase S3 peut être mise en œuvre en prenant en compte, en outre, une contrainte d’exclusion entre tâches mises en œuvre sur des cœurs distincts du calculateur. Cette contrainte, établie en amont par le développeur d’une application correspondant à une partition donnée, permet d’éviter des interférences lors de l’accès à des ressources communes (mémoire, ports d’entrée/sortie, etc.) par des tâches qui pourraient être exécutées en même temps. La contrainte temporelle impose à l’outil d’ordonnancement d’allouer des intervalles temporels disjoints à des tâches ayant une contrainte d’exclusion entre elles. Il est à noter que la phase S3 est mise en œuvre pour chaque tâche d’une application correspondant à une partition, afin de pouvoir ensuite, en phase S4, déterminer un plan d’ordonnancement de l’ensemble des tâches de cette partition. Le plan d’ordonnancement obtenu peut être appelé RSF pour « Repetitive Sequence of Frames » en anglais (Séquence répétitives des fenêtres temporelles). La structure d’un RSF correspond à une série d’intervalles divisés en une partie tête et une partie boucle. Les intervalles d’un RSF sont des conteneurs de trames, qui représentent du temps CPU réservés aux tâches auxquels ils ont été alloués. Cette notion de RSF a été décrit, notamment, dans la demande de brevet WO2014170569 déposée par la société Krono-Safe (maintenant Asterios). Une étape optionnelle S5 consiste à vérifier la cohérence entre le plan d’ordonnancement de second niveau, RSF, obtenu en phase S4, et le plan d’ordonnancement de premier niveau, RST. Pour ce faire, on peut dérouler pour chaque cœur de la partition une exploration synchrone entre la séquence RST et la séquence RSF. A chaque graphe, on associe une date d’exploration Di pour la RST et Dr pour la RSF. Dans la même veine que les étapes itératives S22-S24, on récupère, pour chaque intervalle de RST, l’intersection entre cet intervalle de RST et la RSF. Dans une étape S6, chaque intervalle de RSF est marqué par la nature de l’intervalle de RST auquel il est associé. Pour que la validation temporelle soit effective, tous les critères ci-dessous doivent être respectés : Un intervalle de RSF doit être associé à un et un seul intervalle de RST. Un intervalle de RSF exécutant du code doit être associé à un intervalle de RST exécutant la partition P concernée. Ainsi, par exemple, en cas de changement d’un plan d’ordonnancement de premier niveau par l’intégrateur, on peut vérifier rapidement qu’il y a bien compatibilité entre celui-ci et les différentes contraintes temporelles des tâches d’une application/partition, ces contraintes étant matérialisées dans les modélisations temporelles RATS. Les FIG. 10 à FIG. 10 illustrent un autre exemple d’application du procédé proposé, afin d’en montrer des avantages. En particulier, cet exemple illustre notamment pourquoi la gestion de plans d’ordonnancement statiques monolithiques n’est pas complètement satisfaisante, et doivent être soumis à des restrictions importantes pour être compatibles avec des contraintes de certification incrémentale (comme c’est le cas de la technologie ASTERIOS™ actuelle). Pour illustrer un avantage procuré par le procédé proposé, considérons deux agents PsyC (ou tâches) formant une partition autonome, dont le code est fourni ci-dessous : agent ag_1 ( uses realtime , defaultclock clk_ms , starttime 1) { body start { if ( condition ) { timebudget A, advance 10; // A = 2 ms timebudget B, advance 10; // B = 3 ms } else { timebudget C, advance 20; // C = 3 ms } } } agent ag_2 ( uses realtime , defaultclock clk_ms , starttime 1) { body start { timebudget D, advance 20; // D = 2 ms } } La période minimale d’exécution de la partition est de 10 ms. C’est à dire que toutes les 10 ms au plus tôt, les tâches composant la partition doivent produire un résultat de calcul, et ce peu importe le comportement temporel des tâches qui composent cette partition. La seule contrainte est qu’aucune tâche de la partition n’ait de contrainte temporelle inférieure à une exécution de 10 ms. Les budgets de temps (précisés via l’instruction « timebudget » indiquent la quantité maximale de temps d’exécution allouée à chaque portion de la tâche. Un plan d’ordonnancement statique possible est montré en FIG. 10 . En abscisse, les dates sont indiquées, avec entre crochets, la période de répétition pour la partie boucle du plan. Les tâches de l’agent ag_1 sont représentées par des zones hachurées, et celles de l’agent ag_2 sont représentées par des zones pointillées. On suppose alors l’ajout d’une nouvelle partition comportant un troisième agent, ag_3, avec une période d’exécution minimal de 5 ms. Le code peut en être le suivant : agent ag_3 ( uses realtime , defaultclock clk_ms , starttime 1) { body start { timebudget E, advance 5; // E = 1 ms } } La FIG. 10 représente un plan d’ordonnancement statique traduisant l’ensemble des contraintes des deux partitions (donc, avec un total de trois tâches, ag_1, ag_2, ag_3). Les tâches du troisième agent, ag_3, sont illustrées par des zones avec une texte de cadrillage pointillé. En comparant les deux plans d’ordonnancement des FIG. 10 et FIG. 10 , on constate que le rajout d’une nouvelle partition (au sens d’un intégrateur) vient significativement bousculer le plan d’ordonnancement initial. On constate par exemple que la tâche ag_2, qui pouvait s’exécuter sans préemption dans l’intervalle [1, 11] du plan initial est préempté dans le plan de la FIG. 10 avec la découpe de cet intervalle en deux sous-intervalles [1, 6] et [6, 11]. Ce genre de perturbations du plan d’ordonnancement complexifie beaucoup les estimations de WCET (« Worst Case Execution Time » en anglais, soit « temps d’exécution dans le pire cas ») des utilisateurs : le plan d’ordonnancement n’offrant pas de garantie de stabilité lorsque l’on souhaite rajouter une nouvelle partition, il est difficile d’arguer que les propriétés démontrées sur un plan d’ordonnancement donné sont conservées sur un autre. Ces perturbations sont généralement imputables aux effets de bords sur les caches. Comme vu précédemment, le procédé proposé repose au contraire sur le principe d’une ligne temporelle qui permet d’organiser un ordonnancement statique automatique à double niveau. Le principe de « timeline » et l’ordonnancement statique à double niveau qu’il apporte amènent ainsi la garantie de stabilité nécessaire. Pour illustrer cet avantage sur la base du même exemple, on peut considérer une ligne temporelle triviale, décrivant l’alternance des deux partitions. P1 est d’abord exécutée pendant 3 ms, puis suit P2 pendant 2 ms, et ainsi de suite. Le code dans un dialecte du langage PsyC peut être alors : timeline t (uses realtime , defaultclock clk_ms , starttime 1, period 5) { partition P1 , timeslot a, offset 0, duration 3; partition P2 , timeslot b, offset 3, duration 2; } Le procédé proposé permet de rajouter une contrainte au générateur d’ordonnancement, de sorte que celui-ci intègre une contrainte supplémentaire au moment de la génération du plan d’ordonnancement d’une partition. Les fenêtres de temps exécutables des plans d’ordonnancement d’une partition donnée doivent coïncider avec un intervalle de temps alloué à la partition en question. Les plans d’ordonnancement des partitions P1 et P2 sont ainsi montrés, respectivement, dans les FIG. 10 et FIG. 10 . On constate que ces plans d’ordonnancement secondaire sont fragmentés de telle sorte à exhiber des intervalles vides coïncidant avec les zones de temps de l’intervalle de temps alloué à l’autre partition. Par exemple, on remarque, dans cet exemple, que la tâche ag_3 s’exécute dans l’intervalle [4, 6] ( FIG. 10 ) et qu’aucune tâche ne s’exécute dans cet intervalle pour la partition P1 ( FIG. 10 ). De même, les autres intervalles durant lesquels la tâche ag_3 s’exécute sont vides dans la partition P1 illustré en FIG. 10 . On peut constater qu’il en est de même pour les tâches ag_1 et ag_2 qui sont exécutés dans des intervalles de temps vides de la partition P2. On constate donc que le procédé proposé, selon ces différents modes de réalisation, permet de nombreux avantages par rapport aux propositions de l’état de la technique. Selon un mode de réalisation, le procédé peut se baser sur des outils existants mais propose de formater et construire des données d’entrée à ces outils pour les forcer à produire des plans d’ordonnancement différents, contraints, et répondant aux exigences mentionnées préalablement. Selon des modes de réalisation, le procédé peut être vu comme reposant sur une découpe du temps CPU en fenêtres d’exécution temporelles de taille fixe, organisées selon un schéma périodique et répétitif. Une partition donnée ne peut s’exécuter que durant les fenêtres d’exécution qui lui sont statiquement allouées. Comme on l’a vu, ce formalisme peut se traduire, par exemple, par un langage de programmation dédié ou par une configuration déclarative. C’est à l’intégrateur de rédiger cette spécification temporelle, en amont du processus d’intégration. Cette spécification est fournie aux divers sous-traitants et fait office de contrat entre sous-traitants et intégrateur. À noter que ce contrat peut s’accompagner de spécifications optionnelles déclarant les permissions d’accès de chaque partition à l’espace d’adressage mémoire. Ainsi, le procédé offre à l’intégrateur un outil lui permettant d’exprimer une conception temporelle formalisée, interopérable avec des procédés d’ordonnancement existants ou non, et utilisables par chaque entité développant des partitions. Il permet d’implémenter un partitionnement robuste entre composants logiciels maîtrisés. L’accent est mis sur le partitionnement temporel entre partitions, mais les aspects de partitionnement spatial sont également adressés, sans être normatifs pour autant, ce qui permet une certaine souplesse dans la mise en œuvre du procédé. D’une façon plus générale, le procédé peut être vu comme se basant sur un principe de multiplexage temporel statique, ce qui permet un cloisonnement — ou partitionnement — temporel strict entre les partitions qui composent le système, et, a fortiori, des tâches qui les constituent. Ce mécanisme s’appuie sur le paradigme « time-triggered » (déclenchement par le temps), dans lequel l’écoulement du temps est la seule source d’événements qui régit le système. Particulièrement utilisé dans le domaine de l’avionique critique, il offre un niveau de sûreté supérieur au paradigme « event-triggered » (déclenchement par événements), au détriment de la réactivité et des performances pures du système. Le contrat entre intégrateur et développeur d’applications/partitions (sous-traitants, ou fournisseur d’application) est utilisé, explicitement ou implicitement, par les sous-traitants en charge de fabriquer les partitions. Ces deux modes d’utilisation du contrat, représentent un aspect primordial. À noter qu’il est possible de les combiner localement : une tâche n’a pas nécessairement vocation à utiliser ces modes de manière exclusive. Ainsi : Utilisation explicite. L’utilisateur peut effectuer la conception temporelle de sa partition en se calquant sur les fenêtres temporelles délimitées par le contrat. Les tâches sont explicitement resynchronisées sur les bornes des fenêtres temporelles. Utilisation implicite. L’utilisateur peut exprimer des contraintes temporelles et le procédé décrit permet de générer automatiquement le plan d'ordonnancement compatible avec les contraintes de haut niveau D’une façon générale, les tâches peuvent exprimer des contraintes temporelles plus fines au sein des fenêtres temporelles. Il est important que les directives temporelles de l’utilisateur ne contredisent pas le contrat, sous peine de rendre impossible la création de plans d’ordonnancement cohérents. Grâce au procédé proposé, les partitions sont développées, testées et vérifiées en autonomie les unes des autres, avant validation du système par l’intégrateur. Ce principe de l’invention est primordial car il offre une approche modulaire, favorisant la conservation des crédits de certification obtenus par chaque partition, tout en réduisant le coût de certification lors de l’intégration. 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, appartenant à une partition, sur un calculateur multitâche (30) comportant au moins un cœur de traitement, ledit procédé comprenant une détermination (S2), pour chaque tâche, d’une modélisation temporelle contrainte par un ordonnancement de ladite partition au sein d’une ligne temporelle, puis une détermination (S3) d’un ordonnancement statique desdites tâches au sein de ladite ligne temporelle à partir desdites modélisations temporelles et de contraintes temporelles associées à chaque tâche. Procédé selon la revendication précédente, dans lequel ladite ligne temporelle est fournie sous la forme d’une structure de données spécifiant un découpage du temps en intervalles temporels, chaque intervalle temporel pouvant être individuellement affecté à une unique partition. Procédé selon l’une des revendications précédentes, comportant une phase préalable (S1) d’ordonnancement de ladite partition au sein de ladite ligne temporelle, comportant une spécialisation (S11) de ladite ligne temporelle à ladite partition, un recalage (S12) de ladite ligne temporelle, puis une fusion (S13) des intervalles temporels vides. Procédé selon l’une des revendications précédentes dans lequel ledit modèle temporel est un graphe d’états temporels, et ladite détermination (S2) comprend une création (S21) d’un premier graphe d’états temporels, puis une modification itérative (S22-S25) dudit premier graphe d’états temporels en utilisant ledit ordonnancement de ladite partition au sein de ladite ligne temporelle. Procédé selon la revendication précédente, dans lequel ladite modification itérative (S22-S25) comprend une fragmentation (S24) d’un arc dudit graphe d’états temporels si ledit arc n’est pas totalement inclus dans un intervalle dudit ordonnancement de ladite partition au sein d’une ligne temporelle (S23). 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 des circuits adaptés pour mettre en œuvre le procédé selon l’une des revendications 1 à 5, 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 à 5. Véhicule comportant au moins un calculateur multitâche selon la revendication précédente.