La présente invention se rapporte au domaine des calculateurs embarqués dans les véhicules automobiles et concerne plus particulièrement un procédé de gestion d’une pluralité de tâches par un microcontrôleur multicœur embarqué dans un véhicule automobile. L’invention permet notamment d’optimiser le flux de données entre les cœurs pour assurer que les données sont produites avant d’être consommées sur le même cœur ou sur un autre cœur.
De nos jours, un véhicule automobile comporte de manière connue une pluralité de calculateurs utilisés pour exécuter diverses fonctionnalités telles que, notamment, le contrôle du ou des moteurs du véhicule. Chaque calculateur comprend au moins un processeur ou un microcontrôleur qui exécute un ou plusieurs logiciels afin de remplir les fonctionnalités désirées.
De manière connue, un logiciel comprend des composants logiciels. Chaque composant permet de gérer une fonctionnalité du véhicule et regroupe dans ce but des fonctions spécifiques. Chaque fonction d’un composant peut générer une ou plusieurs données, par exemple de manière périodique. Parmi ces données, certaines sont utilisées par une ou plusieurs autres fonctions (on parle alors de « données consommées par une autre fonction » ou « données consommées ») tandis que d’autres données ne sont pas utilisées par une autre fonction (on parle alors de « données non-consommées par une autre fonction » ou « données non-consommées »). Ainsi, dans le cas d’une donnée consommée, lorsqu’une deuxième fonction consomme une donnée produite par une première fonction, la deuxième fonction utilise la dernière valeur de la donnée qui a été générée et stockée par la première fonction.
Quand un logiciel s’exécute sur un processeur ou un microcontrôleur qui possède un seul cœur, le traitement des fonctions d’un composant est réalisé en série selon un ordre prédéterminé de sorte que la première fonction s’exécute entièrement avant de fournir sa ou ses données consommées à la deuxième fonction qui va les utiliser. Sur un système mono-cœur, lors de l’écriture du logiciel, si une fonction qui produit une donnée est placée dans la séquence d’appel des fonctions avant une autre fonction qui consomme cette même donnée, alors, lors de toutes les exécutions du logiciel, cette donnée sera toujours produite avant d’être consommée. Ainsi, sur un processeur ou un microcontrôleur qui possède un seul cœur, l’ordre du flux de données déterminé lors de l’écriture du logiciel sera toujours le même lors de l’exécution du logiciel.
En revanche, quand un logiciel s’exécute sur un processeur ou un microcontrôleur qui possède plusieurs cœurs, dit « multicœur », le traitement des fonctions d’un composant sera la plupart du temps réalisé en parallèle sur les différents cœurs (on dit alors que les tâches exécutant ces fonctions ne sont pas chaînées). Les cœurs étant indépendants les uns des autres, il n’est pas possible de garantir qu’une fonction qui produit une donnée sur un cœur sera exécutée avant une autre fonction qui consomme cette même donnée sur un autre cœur.
Parmi les fonctions, on distingue les fonctions d’initialisation et les fonctions dites « récurrentes ». Une fonction d’initialisation est exécutée au démarrage de l’exécution d’un composant et correspond à une mise à jour de données suite à la réception de signaux particuliers (par exemple, la réception ou la disparition du signal relatif à la clé de contact, le démarrage ou l’arrêt du moteur, ...). Une fonction récurrente concerne un traitement qui a lieu après une fonction d’initialisation, à récurrence fixe (temporelle) ou variable (par exemple exécutée à chaque point mort haut d’un cylindre, c’esî-à-dire à la vitesse de rotation du moteur).
Lors de l’exécution des fonctions récurrentes, si le flux de données n’est pas respecté (c’est-à-dire si la mise à jour d’une donnée n’est pas encore réalisée par une première fonction lorsqu’une deuxième fonction utilise ladite donnée), les données consommées utilisées auront la valeur des données produites à la récurrence précédente. Si la donnée consommée concerne une grandeur analogique, par exemple celle mesurée par un capteur, l’utilisation d’une valeur obsolète de la donnée par une fonction ne présente pas forcément une erreur importante dans la mesure où, entre deux récurrences successives, la grandeur analogique varie peu et de manière continue (sans discontinuité) dans un faible laps de temps. De plus, dans ce cas, il est connu de procéder à un paramétrage du logiciel pour qu’il compense de telles erreurs.
En revanche, les erreurs de mise à jour et l’utilisation de données erronées par une fonction d’initialisation peuvent être particulièrement dommageables lors de l’exécution desdites fonctions d'initialisation qui permettent notamment le démarrage du calculateur qui met en œuvre le logiciel. En effet, une erreur, notamment sur une grandeur booléenne (de type tout ou rien), commise lors de l’exécution de ces fonctions peut fausser des stratégies de contrôle du moteur du véhicule, engendrer des instabilités et mettre un temps significativement long à être corrigée.
Il existe donc le besoin d’une solution simple, fiable et efficace permettant de remédier au moins en partie à ces inconvénients. En particulier, il existe un besoin pour gérer efficacement et de manière fiable un flux de données générées et utilisées par plusieurs fonctions d’un composant, notamment par une fonction d’initialisation.
A cette fin, l’invention a pour objet un procédé de traitement d’une pluralité de fonctions prédéterminées mises en œuvre par un calculateur de véhicule automobile, ledit calculateur comprenant un microcontrôleur, ledit microcontrôleur, dit « multicœur », comprenant une pluralité de cœurs, chaque cœur de ladite pluralité de cœurs étant apte à traiter au moins une fonction de ladite pluralité de fonctions, certaines fonctions de la pluralité de fonctions produisant au moins une donnée dite « consommée » utilisée par une autre fonction de la pluralité de fonctions lors du traitement de la pluralité de fonctions par le microcontrôleur, ledit procédé étant remarquable en ce que, chaque fonction étant caractérisée par un ordre n prédéterminé, n étant un entier naturel, ledit ordre n indiquant le degré de dépendance de ladite fonction à des données consommées produites par les autres fonctions, le procédé comprend, pour n variant par incrément de 1 de 0 à N, N étant un entier naturel définissant le dernier ordre à traiter, le traitement par la pluralité de cœurs de toutes les fonctions d’ordre n produisant au moins une donnée consommée nécessaire à au moins une fonction d’un ordre supérieur avant de traiter les fonctions d’ordre n+1.
Le procédé selon l’invention a pour but de diminuer, voire de supprimer, dans la limite du possible, tous les problèmes de flux de données, même sur des composants logiciels couplés, i.e. partageant des données (les uns produisant des données consommées par les autres), placés sur des cœurs différents d’un calculateur de véhicule automobile. Elle permet donc de mieux répartir la charge à traiter sur tous les cœurs tout en optimisant le flux de données (données consommées après avoir été produites). Elle permet également de garantir un flux de données optimum lors de l’exécution de fonctions d’initialisation, qui sont des fonctions cruciales pour le véhicule. Elle permet en outre d’optimiser le temps d’exécution en réalisant des traitements lors des temps d’attente dédiés à la synchronisation des cœurs entre eux.
Pour ce faire, les fonctionnalités du véhicule à mettre en œuvre sont analysées afin de distinguer les données consommées des données non-consommées puis de déterminer un degré de dépendance et un ordre pour chaque donnée.
Une fois cette analyse de flux de donnée réalisée, de nouvelles fonctions sont créées, permettant par exemple de remplacer des fonctions d’initialisation d’un logiciel existant. Ces fonctions sont de deux types : les fonctions qui regroupent toutes les données consommées pour chaque ordre et pour chaque cœur, et les fonctions qui regroupent toutes les données non-consommées pour chaque ordre et pour chaque cœur. Ces fonctions sont ensuite exécutées dans le logiciel, par exemple à la place des fonctions d’initialisation d’origine du logiciel.
De préférence, chaque cœur traite, à chaque ordre n, une et une seule fonction produisant au moins une donnée consommée d’ordre n.
Selon un autre aspect de l’invention, certaines des fonctions de la pluralité de fonctions ne produisent pas de donnée consommée mais au moins une donnée dite « non-consommée », chaque fonction étant caractérisée par un ordre n prédéterminé, le procédé comprenant le traitement au moins partiel, sur au moins un cœur, d’au moins une fonction d’ordre n produisant au moins une donnée non-consommée avant de traiter les fonctions d’ordre n+1 tant qu’au moins une fonction produisant au moins une donnée consommée est en cours de traitement par l’un des cœurs.
De préférence encore, chaque cœur traite, à chaque ordre n, une et une seule fonction produisant au moins une donnée non consommée.
Dans un mode de réalisation, chaque cœur traite après l’ordre N les fonctions produisant au moins une donnée non-consommée qui ont au moins partiellement été traitées préalablement ou qui n’ont pas encore été traitées.
L’invention concerne également un calculateur pour véhicule automobile, ledit calculateur comprenant un microcontrôleur, ledit microcontrôleur, dit « multicœur », comprenant une pluralité de cœurs, chaque cœur de ladite pluralité de cœurs étant apte à traiter au moins une fonction d’une pluralité de fonctions, certaines fonctions de ladite pluralité de fonctions produisant au moins une donnée dite « consommée » utilisée par une autre fonction de la pluralité de fonctions lors du traitement de la pluralité de fonctions par le microcontrôleur, ledit calculateur étant caractérisé en ce que, chaque fonction étant caractérisée par un ordre n prédéterminé, n étant un entier naturel, ledit ordre n indiquant le degré de dépendance de ladite fonction à des données consommées produites par les autres fonctions, chaque cœur est configuré, pour n variant par incrément de 1 de 0 à N, N étant un entier naturel définissant le dernier ordre à traiter, pour traiter toutes les fonctions d’ordre n produisant des données consommées nécessaires à au moins une fonction d’un ordre supérieur avant de traiter les fonctions d’ordre n+1.
Selon un aspect de l’invention, chaque cœur est configuré pour traiter, à chaque ordre n, une et une seule fonction produisant au moins une donnée consommée.
Selon un autre aspect de l’invention, certaines des fonctions de la pluralité de fonctions ne produisant pas de donnée consommée mais au moins une donnée dite « non-consommée », chaque fonction étant caractérisée par un ordre n prédéterminé, le calculateur est configuré pour traiter au moins partiellement au moins une fonction d’ordre n produisant au moins une donnée non-consommée avant de traiter les fonctions d’ordre n+1 tant qu’au moins une fonction produisant au moins une donnée consommée est en cours de traitement par l’un des cœurs.
Selon un aspect de l’invention, chaque cœur est configuré pour traiter, à chaque ordre n, une et une seule fonction produisant au moins une donnée nonconsommée.
Dans une forme de réalisation, chaque cœur est configuré pour traiter, après l’ordre N, les fonctions produisant au moins une donnée non-consommée qui ont au moins partiellement été traitées préalablement ou qui n’ont pas encore été traitées.
L’invention concerne aussi un véhicule automobile comprenant un tei calculateur.
L’invention concerne enfin un véhicule automobile comprenant un calculateur tel que présenté précédemment.
- La figure 1 illustre schématiquement une forme de réalisation du calculateur selon l'invention.
- La figure 2 illustre schématiquement un exemple de phase d’initialisation du procédé selon l’invention.
- La figure 3 illustre schématiquement un exemple de phase de fonctionnement du procédé selon l’invention.
- La figure 4 illustre un exemple de traitement de fonctions par le procédé selon l’invention.
L’invention est destinée à être mise en œuvre par un microcontrôleur ou un processeur multicœur d’un calculateur embarqué dans un véhicule automobile afin de gérer des tâches relatives au fonctionnement du véhicule, notamment de son ou ses moteurs.
Afin d’illustrer la présente invention, on a représenté schématiquement à la figure! un calculateur! comprenant un microcontrôleur 10. Le microcontrôleur 10 comprend trois cœurs C1, C2, C3 et une zone mémoire 100. On notera que l’invention pourrait tout aussi bien être mise en œuvre par un microcontrôleur ou un processeur comportant deux ou plus de trois cœurs. De même, en variante, on notera que la zone mémoire 100 pourrait être externe au microcontrôleur et se trouver dans une autre partie du calculateur 1, voire hors du calculateur 1.
La zone mémoire 100 comprend un logiciel (également appelé programme embarqué) comportant des instructions destinées à être mises en œuvre par le calculateur 1 pour gérer le fonctionnement du véhicule, et notamment les équipements électroniques. On notera que, dans une autre forme de réalisation, la zone mémoire 100 pourrait comprendre plus d’un logiciel.
Le logiciel comprend des instructions qui permettent d’exécuter une ou plusieurs fonctions. Chaque cœurCI, C2, C3 est configuré pour traiter séquentiellement une série de fonctions.
Dans les solutions antérieures, on distinguait les fonctions d’initialisation et les fonctions dites « récurrentes ». Une fonction d’initialisation concerne une mise à jour de données suite à la réception de signaux particuliers (par exemple, la réception ou la disparition du signal relatif à la clé de contact, le démarrage ou l’arrêt du moteur, Une fonction récurrente concerne un traitement qui a lieu après une fonction d’initialisation, à récurrence fixe (temporelle) ou variable (au point mort haut d’un cylindre, c’est-à-dire dépendant de la vitesse de rotation du moteur). Chaque fonction peut utiliser une ou plusieurs données et/ou générer une ou plusieurs données. Les données générées par une fonction du logiciel et utilisées par une ou plusieurs autres fonctions du logiciel sont appelées données consommées (ou externes). Les données générées par une fonction du logiciel et qui ne sont pas utilisées par une ou plusieurs autres fonctions du logiciel sont appelées données non-consommées (ou internes).
Dans la présente invention, on crée des nouvelles fonctions permettant de remplir les fonctionnalités souhaitées (par exemple mise à jour de données suite à la réception ou à la disparition du signal relatif à la clé de contact, le démarrage ou l’arrêt du moteur, etc.) à la place des fonctions, notamment d’initialisation, telles que définies dans les solutions antérieures.
A cette fin, la procédé selon l’invention comprend tout d’abord une étape de création, appelée phase de génération, de ces nouvelles fonctions. Cette phase de génération est réalisée en laboratoire et permet de générer le logiciel qui sera sauvegardé dans la zone mémoire 100 du calculateur 1 du véhicule lors de sa fabrication et qui sera mis en œuvre, dans une phase d’utilisation, lors du fonctionnement de véhicule.
Les nouvelles fonctions peuvent être créées directement dès lors qu’aucun logiciel d’origine n’existe ou afin de remplacer des fonctions, notamment d’initialisation, d’un logiciel existant.
La phase de génération comprend tout d’abord une analyse, soit des fonctionnalités à mettre en œuvre, soit des fonctions, notamment d’initialisation, d’un logiciel existant, afin de distinguer les données consommées et les données nonconsommées. Les nouvelles fonctions sont ensuite créées afin de mettre en œuvre les mêmes fonctionnalités que les fonctions d’origine du logiciel.
Par la suite, par le terme « fonction » on entend une série d’instructions de logiciel générée ou qui a été générée lors de ladite phase de génération.
Dans ce cadre, les fonctions productrices de données consommées sont notées DC Ci q, où i est un entier naturel indiquant le numéro du cœur affecté au traitement de ladite fonction et n est un entier naturel indiquant l’ordre de ladite fonction, comme cela sera décrit ci-après. Les fonctions productrices de données non consommées sont notées DNC__Ci_n, où i est un entier naturel indiquant le numéro du cœur affecté au traitement de ladite fonction et n est un entier naturel indiquant l’ordre de ladite fonction, comme cela sera décrit ci-après.
Ainsi, la phase de génération, illustrée schématiquement à la figure 2, consiste à déterminer le contenu des fonctions DC__Ci__n, DNC Ci n exécutées par chacun des cœurs C1, C2, C3 du microcontrôleur 10.
A cette fin, dans une première étape E1, chaque donnée se voit attribuer un attribut de dépendance et un attribut d’ordre.
L’attribut de dépendance définit le degré de dépendance d’une donnée avec les autres données de la façon suivante :
• 0 correspond à une donnée non-consommée, • 1 correspond à une donnée consommée.
L’attribut d’ordre définit l’ordre de dépendance par rapport au nombre de données consommées. Ainsi, les données qui ne sont fonction (i.e. qui ne dépendent) d’aucune autre donnée (en étant par exemple initialisées à une valeur constante ou étant une donnée acquise par un capteur) sont d’ordre 0. Les données qui ne dépendent que d’une autre donnée d’ordre 0 sont d’ordre 1. Les données qui dépendent d’une donnée dépendant elle-même d’une donnée d’ordre 0 sont d’ordre 2. Plus généralement, les données qui dépendent d’une donnée d’ordre n sont d’ordre n+1, n étant un entier naturel. L’ordre d’une donnée peut ainsi varier de 0 à N, N étant un entier naturel, correspondant à l’ordre maximal déterminé lors de l’analyse des dépendances des données.
Les fonctions DC__Ci__n et DNC_Ci__n sont créées lors de la phase de construction du logiciel. Ce ne sont pas des fonctions existantes dans le logiciel. A partir des fonctions d’initialisation existantes du logiciel, une analyse est faite pour déterminer le couple (dépendance, ordre) pour chaque donnée mise à jour dans les fonctions d’initialisation du logiciel. Une fois cette analyse faite, les fonctions du logiciel sont remplacées par les fonctions DC_Ci_n et DNC_CLn aux différents ordres pour optimiser le flux de données.
Une fois que l’analyse de toutes les données est terminée et que les interdépendances et les couples (dépendance, ordre) sont connus, il est alors possible de regrouper les initialisations ou calculs des données des fonctions originelles, qui ne seront pas exécutées, dans les fonctions DC_Ci_n et DNC_Ci__n qui, elles, seront exécutées à la place des fonctions originelles.
Par exemple, si la donnée B ne dépend d’aucune autre donnée (B est par exemple une donnée initialisée à une constante ou correspond au résultat de l’acquisition d’un signal), elle est d’ordre 0. Si la donnée A est fonction (i.e. dépend) de B (A=f(B)), alors A est d’ordre 1. Si la donnée C1 dépend de B, elle est d’ordre 1. Si la donnée C2 dépend de A (qui dépend de B), alors la donnée C2 est d’ordre 2. Si la donnée C3 dépend de B et de C1, alors elle est d’ordre 2 car B est d’ordre 0 et C1 est d’ordre 1. Si la donnée B1 dépend des données A, B et CI, alors elle est d’ordre 2. De manière générale, l’ordre des données qui dépendent de plusieurs autres données est égal à l’ordre maximum desdites autres variables incrémenté d’une unité.
Le couple (dépendance, ordre) permet de traiter la donnée au bon moment afin de respecter l’ordre du flux de données tout en optimisant la répartition du traitement des fonctions DC_Ci_n, DNC_Ci_n entre les cœurs C1, C2, C3. Plus précisément, l’attribut de dépendance permet ainsi de prioriser les traitements, le traitement d’une donnée consommée étant prioritaire sur le traitement d’une donnée non-consommée. L’attribut d’ordre permet de traiter chaque donnée dans l’ordre du flux de donnée de sorte à s’assurer qu’une donnée devant être utilisée par une autre donnée soit produite avant sa consommation. L’attribut de dépendance permet de prioriser les traitements : le traitement d’une donnée non consommée par la suite n’est pas prioritaire par rapport à celui d’une donnée consommée par la suite.
Grâce au tri ainsi réalisé sur les données, il est alors possible (dans une étape E3 décrite ci-après) de ranger chaque donnée dans la fonction adéquate (donnée consommée ou non consommée) et dans l’ordre du flux de donnée (production puis consommation), ceci pour chaque cœur C1, C2, 03.
Dans une étape E2, les cas incohérents ou impossibles peuvent être détectés s’ils existent. Par exemple, si la donnée D est fonction de la donnée E qui est fonction de la donnée F qui est fonction de la donnée D, il n’est pas possible de déterminer un ordre de traitement pour chacune des données. Dans ce cas, un ordre est imposé, par exemple, la donnée D doit être traitée en premier afin d’obtenir la donnée F puis la donnée E.
Les fonctions DC__Ci__n, DNC__Ci__n qui regroupent les calculs des données ayant les mêmes attributs de dépendance et d’ordre sont ensuite générées dans une étape E3. Ainsi, comme indiqué précédemment, pour un ordre n donné, les données de chaque cœur 01, C2, 03 sont rangées de la manière suivante :
* si la donnée n’est pas destinée à être consommée par une autre fonction (i.e. est une donnée non-consommée), ladite donnée est rangée dans la fonction notée DNC_Ci_n, où i désigne le cœur sur lequel le calcul de la donnée est exécuté et n désigne l’ordre de la donnée, • si la donnée est destinée à être consommée par une autre fonction (i.e. est une donnée consommée), ladite donnée est rangée dans la fonction notée DC_Ci_n, où i désigne le cœur sur lequel le calcul de la donnée est exécuté et n désigne l’ordre de la donnée.
Les données sont ainsi regroupées en fonction de leurs attributs de dépendance et d’ordre de sorte que les données consommées soient traitées avant les données non-consommées pour chaque ordre.
Ensuite, dans une quatrième étape E4 de la phase d’initialisation, des indicateurs sont définis en fonction du classement des données réalisé aux étapes précédentes. Ces indicateurs sont de type binaire (appelés « flag » en langue anglaise) et ne sont associés qu’aux fonctions gérant des données consommées afin de synchroniser leur production avec leur consommation entre les cœurs C1, C2, C3. L’indicateur F Ci. n est ainsi défini si la fonction DC_Ci_n est non vide.
Une fois la phase de génération réalisée, le logiciel regroupant les nouvelles fonctions générées est stocké dans la zone mémoire 100 de sorte à être mis en œuvre lors d’une phase dite « d’utilisation » réalisée en fonctionnement du calculateur 1 du véhicule.
Ainsi, à chaque mise en œuvre du calculateur 1 lors du fonctionnement du véhicule, le calculateur 1 procède à la phase d’utilisation, illustrée schématiquement à la figure 3.
Cette phase d’utilisation comprend pour chaque ordre η, n variant par incrément de 1 de 0 à N, pour chaque cœur C1, C2, C3 :
* l’initialisation par le calculateur 1 de tous les indicateurs F Ci__n à 0 (étape S1 ), « l’exécution de la fonction DC__Ci__n, si elle existe, et le passage de l’indicateur F„Ci__n correspondant à 1 dès que cette fonction est terminée (étape S2), * l’exécution de la fonction DNC__Ci„n, si elle existe, est ensuite réalisée jusqu’à ce que tous les indicateurs F_Ci_n soient à 1 (étape S3) auquel cas l’exécution de la fonction DNC_Ci_n est suspendue et les étapes sont reprises dans l’ordre à partir de l’étape S1 pour l’ordre n+1. L’endroit où la fonction DNC..CI n est suspendue est mémorisé par un compteur ctr.Ci n associé au cœur Ci correspondant.
Le reliquat d’un traitement suspendu d’une fonction DNCCin est traité à la prochaine période d’attente du calculateur ou bien sinon lorsque tous les traitements des données consommées ont été réalisés pour tous les ordres.
Ainsi, par exemple, quand les données produites par un premier cœur C1 et attendues par un deuxième cœur C2 sont mises à jour (données consommées prêtes à être consommées), l’indicateur F Ci...n correspondant est mis à 1 de sorte que le deuxième cœur C2 qui attendait d’utiliser ces données puissent les consommer. L’attente précédant la mise à disposition de ces données par le premier cœur C1 est avantageusement mise à profit par le deuxième cœur C2 pour produire des données non consommées, c’est-à-dire pour produire les données qui ne seront pas utilisées par d’autres cœurs.
La génération prioritaire, par chaque cœur, des données consommées par les autres cœurs permet de réduire les délais d’attente desdits autres cœurs et d’optimiser ainsi le flux des données traité par le calculateur, ce qui diminue le risque qu’un cœur utilise des données erronées (i.e. qui ne sont pas à jour).
On a représenté à la figure 4 un exemple de mise en œuvre de la phase de fonctionnement. Dans cet exemple, chaque cœur C1, C2, C3 met en œuvre respectivement une fonction DC__Ci__n produisant une ou plusieurs données consommées à chacun des ordres 0,1,2 attribués dans une phase d’initialisation ayant été réalisée préalablement.
Ensuite, chaque cœur C1, 02, 03 met en œuvre respectivement une fonction DNC__Ci__n produisant une ou plusieurs données non-consommées à chacun des ordres 0,1,2 dès qu’elle le peut, c’est-à-dire dès que ledit cœur 01,02, C3 a terminé de traiter la fonction DC__Cî_n produisant une ou plusieurs données consommées, et tant que la combinaison des indicateurs F Ci n associés à des données mises en œuvre par les autres cœurs C1,02, 03 fait que ce cœur C1,02, 03 est dans une phase d’attente.
Ainsi, dans l’exemple de la figure 4, on constate qu’à l’ordre 0 le premier cœur 01 commence à traiter la fonction DNC_C1_0 après avoir fini de traiter la fonction DC C1...0 et que le troisième cœur C3 commence à traiter la fonction DNC 03 „0 après avoir fini de traiter la fonction DC__C3__0. Dès que le deuxième cœur 02 a terminé le traitement de la fonction DC C2 0, le dernier indicateur F_Ci_n d’ordre 0 est positionné à 1, ce qui permet ainsi le passage au traitement de l’ordre 1 (les boucles d’attentes se terminent). Ainsi, la fonction DNC C2 0 n’a pas le temps d’être traitée à ce stade.
Ainsi, à l’ordre 1, chaque cœur 01, C2, C3 traite une fonction respectivement DC_C1_1, DC_C2_1, DC_C3_1 produisant une ou plusieurs données consommées et le deuxième cœur C2 et le troisième cœur C3 commencent à traiter des fonctions DNC 02 1. DNC C3 1 produisant une ou plusieurs données non-consommées tant que le premier cœur C1 n’a pas terminé de traiter la fonction DC_C1_1, l’indicateur F_C1_1 bloquant le passage des traitements à l’ordre 2 mais permettant au premier cœur C1 et au deuxième cœur C2 de traiter les fonctions non prioritaires DNC 02 1 et DNC C3_J.
De même, à l’ordre 2, chaque cœur 01, 02, C3 traite une fonction respectivement DC__C1__2, DC C2 2. DC__C3_2 produisant une ou plusieurs données consommées, et le deuxième cœur C2 et le troisième cœur 03 commencent à traiter des fonctions DNC C2 2, DNC C3 ,2 produisant une ou plusieurs données nonconsommées tant que le premier cœur C1 n’a pas terminé de traiter la fonction DC C1 .2.
Dans le cas de l’exemple Illustré par la figure 4, l’ordre 2 est le dernier ordre à traiter ; ainsi, une fois que le premier cœur C1 a terminé de traiter la fonction DC_C1_2, qui est la dernière fonction produisant une ou plusieurs données consommées, les cœurs 01, C2, C3 peuvent terminer de traiter les fonctions produisant une ou plusieurs données 5 non-consommées qu’ils avaient commencé de traiter préalablement ou peuvent traiter les fonctions produisant une ou plusieurs données non-consommées qu’ils n’avaient pas encore eu le temps de traiter.
On notera que, dans cet exemple, chaque cœur qui dispose de temps pour traiter une fonction produisant une ou plusieurs données non-consommées à un ordre 10 donné traite la fonction produisant une ou plusieurs données non-consommées du même ordre et, s’il reste du temps, termine de traiter les fonctions produisant une ou plusieurs données non-consommées qu’il a commencé de traiter aux ordres inférieurs mais dont le traitement a été interrompu après le traitement de la dernière fonction produisant une ou plusieurs données consommées.
Le procédé selon l’invention permet ainsi avantageusement de traiter prioritairement les fonctions produisant des données utilisées par d’autres fonctions de manière à optimiser le temps de traitement global des fonctions du logiciel par le calculateur tout en s’assurant que les données utilisées par les fonctions soient le plus à jour possible.