Brevet FR3082338A1 — publié le 20191213

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 multicoeur embarqué dans un véhicule automobile. L'invention permet notamment d'optimiser le flux de données entre les coeurs pour assurer que les données sont produites avant d'être consommées sur le même coeur ou sur un autre coeur. 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 A cette fin, l'invention a pour objet un procédé de traitement d'une pluralité de fonctions prédéterminées mises en oeuvre par un calculateur de véhicule automobile, ledit calculateur comprenant un microcontrôleur, ledit microcontrôleur, dit « multicoeur », 3 comprenant une pluralité de coeurs, chaque coeur de ladite pluralité de coeurs é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 5 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 10 coeurs 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 15 logiciels couplés, i.e. partageant des données (les uns produisant des données consommées par les autres), placés sur des coeurs différents d'un calculateur de véhicule automobile. Elle permet donc de mieux répartir la charge à traiter sur tous les coeurs 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 20 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 coeurs entre eux. Pour ce faire, les fonctionnalités du véhicule à mettre en oeuvre sont analysées afin de distinguer les données consommées des données non-consommées 25 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 coeur, et les fonctions qui 30 regroupent toutes les données non-consommées pour chaque ordre et pour chaque coeur. 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 coeur traite, à chaque ordre n, une et une seule [onction produisant au moins une donnée consommée d'ordre n. 35 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 4 procédé comprenant le traitement au moins partiel, sur au moins un coeur, 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 coeurs. 5 De préférence encore, chaque coeur 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 coeur 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. 10 L'invention concerne également un calculateur pour véhicule automobile, ledit calculateur comprenant un microcontrôleur, ledit microcontrôleur, dit « multicceur », comprenant une pluralité de coeurs, chaque coeur de ladite pluralité de coeurs é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 15 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 coeur est configuré, pour n variant par incrément de 1 de O à N, 20 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 coeur est configuré pour traiter, à chaque ordre n, une et une seule fonction produisant au moins une donnée consommée. 25 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 30 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 coeurs. Selon un aspect de l'invention, chaque coeur est configuré pour traiter, à chaque ordre n, une et une seule fonction produisant au moins une donnée non-consommée. 35 Dans une forme de réalisation, chaque coeur 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. 5 L'invention concerne aussi un véhicule automobile comprenant un tel calcu a eur. L'invention concerne enfin un véhicule automobile comprenant un calculateur tel que présenté précédemment. 5 La figure 1 illustre schématiquement une forme de réalisa on 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 10 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 oeuvre par un microcontrôleur ou un processeur multicceur d'un calculateur embarqué dans un véhicule automobile afin de 15 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 figurai un calculateur 1 comprenant un microcontrôleur 10. Le microcontrôleur 10 comprend trois coeurs C1. C2, C3 et une zone mémoire 100, On notera que l'invention 20 pourrait tout aussi bien être mise en oeuvre par un rnicrocontrêleur ou un processeur comportant deux ou plus de trois coeurs. 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 25 embarqué) comportant des instructions destinées à être mises en oeuvre 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 30 plusieurs fonctions, Chaque coeur Cl, C2, C3 est configure 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 35 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 6 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 5 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 10 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é 15 dans la zone mémoire 100 du calculateur 1 du véhicule lors de sa fabrication et qui sera mis en oeuvre, 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. 20 La phase de génération comprend tout d'abord une analyse, soit des fonctionnalités à mettre en oeuvre, soit des fonctions, notamment d'initialisation, d'un logiciel existant, afin de distinguer les données consommées et les données non-consommées. Les nouvelles fonctions sont ensuite créées afin de mettre en oeuvre les mêmes fonctionnalités que les fonctions d'origine du logiciel. 25 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 DCCin, où i est un entier naturel indiquant le numéro du coeur affecté au traitement de ladite fonction et n est un entier naturel indiquant l'ordre de ladite fonction, 30 comme cela sera décrit ci-après. Les fonctions productrices de données non consommées sont notées DNC Ci p. où i est un entier naturel indiquant le numéro du coeur 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, 35 consiste à déterminer le contenu des fonctions DC Ci n, DNCCfn exécutées par chacun des coeurs Cl. C2, C3 du microcontrôleur 10. 7 A cette fin, dans une première étape El, 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 : 5 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 [onction (i.e. qui ne dépendent) d'aucune autre donnée (en étant par exemple initialisées à une valeur constante ou étant 10 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, 15 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 20 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 Ci n 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 25 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 30 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 Cl 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 Ci, alors elle est d'ordre 2 car B est d'ordre 0 et Cl est d'ordre 1. Si la 35 donnée Bi dépend des données A, B et Ci, alors elle est d'ordre 2. De manière générale, 8 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 5 des fonctions DC Ci n, DNC_Ci_n entre les coeurs Cl, 02, 03. 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 10 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 15 consommée ou non consommée) et dans l'ordre du flux de donnée (production puis consommation), ceci pour chaque coeur Cl, 02, 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 20 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 25 étape E3. Ainsi, comme indiqué précédemment, pour un ordre n donné, les données de chaque coeur Cl, 02, 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 coeur sur lequel le calcul de la donnée est exécuté et 30 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 ri, où désigne le coeur sur lequel le calcul de la donnée est exécuté et n désigne l'ordre de la donnée. 9 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 5 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 coeurs Ci, 02, 03. L'indicateur FCin est ainsi défini si la fonction DC Ci n est non vide. 10 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 oeuvre lors d'une phase dite « d'utilisation » réalisée en fonctionnement du calculateur 1 du véhicule. Ainsi, à chaque mise en oeuvre du calculateur 1 lors du fonctionnement du 15 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, n variant par incrément de 1 de 0 à N, pour chaque coeur Cl 02, 03 - l'initialisation par le calculateur 1 de tous les indicateurs F Ci n à 0 (étape Si), 20 e 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 à 25 partir de l'étape Si pour l'ordre n+1. L'endroit où la fonction DNCCfn est suspendue est mémorisé par un compteur ctrCi___p associé au coeur Ci correspondant. Le reliquat d'un traitement suspendu d'une fonction DNQ___Cip est traité à la prochaine période d'attente du calculateur ou bien sinon lorsque tous les traitements des 30 données consommées ont été réalisés pour tous les ordres. Ainsi, par exemple, quand les données produites par un premier coeur 01 et attendues par un deuxième coeur 02 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 coeur 02 qui attendait d'utiliser ces données puissent les consommer. L'attente 35 précédant la mise à disposition de ces données par le premier coeur Cl est avantageusement mise à profit par le deuxième coeur 02 pour produire des données non- 10 consommées, c'est-à-dire pour produire les données qui ne seront pas utilisées par d'autres coeurs. La génération prioritaire, par chaque coeur, des données consommées par les autres coeurs permet de réduire les délais d'attente desdits autres coeurs et d'optimiser 5 ainsi le flux des données traité par le calculateur, ce qui diminue le risque qu'un coeur 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 oeuvre de la phase de fonctionnement. Dans cet exemple, chaque coeur Cl , 02, 03 met en oeuvre respectivement une fonction DC Ci n produisant une ou plusieurs données consommées 10 à chacun des ordres 0, 1, 2 attribués dans une phase d'initialisation ayant été réalisée préalablement. Ensuite, chaque coeur 01, 02, 03 met en oeuvre 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 coeur Cl, 02, 03 a terminé de traiter 15 la fonction DCCi___n produisant une ou plusieurs données consommées, et tant que la combinaison des indicateurs FCi___n associés à des données mises en oeuvre par les autres coeurs Cl, 02, 03 fait que ce coeur Cl, 02, 03 est dans une phase d'attente. Ainsi, dans l'exemple de la figure 4, on constate qu'à l'ordre 0 le premier coeur 01 commence à traiter la fonction DNC Cl 0 après avoir fini de traiter la fonction 20 DC01___O et que le troisième coeur 03 commence à traiter la fonction DNC 03 0 après avoir fini de traiter la fonction DC___030. Dès que le deuxième coeur 02 a terminé le traitement de la fonction DC C2 0, le dernier indicateur 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 DNCC2___O n'a pas le temps d'être traitée à ce stade. 25 Ainsi, à l'ordre 1, chaque coeur Cl , 02, 03 traite une fonction respectivement DO Cl 1, DC C2 1, DC C3 1 produisant une ou plusieurs données consommées et le deuxième coeur 02 et le troisième coeur 03 commencent à traiter des fonctions DNCO2___1, DNC03___1 produisant une ou plusieurs données non-consommées tant que le premier coeur Cl n'a pas terminé de traiter la fonction DC 01 1, l'indicateur F Cl 1 30 bloquant le passage des traitements à l'ordre 2 mais permettant au premier coeur Cl et au deuxième coeur 02 de traiter les fonctions non prioritaires DNCO2___1 et DNC 03 1. De même, à l'ordre 2, chaque coeur Cl 02, 03 traite une fonction respectivement D0 Cl 2, DC 02 2, DC C3 2 produisant une ou plusieurs données consommées, et le deuxième coeur 02 et le troisième coeur 03 commencent à traiter des 35 fonctions DNCO2___2, DNC___C32 produisant une ou plusieurs données non-consommées tant que le premier coeur 01 n'a pas terminé de traiter la fonction DC___01___2. 11 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 coeur Cl a terminé de traiter la [onction DC Cl 2, qui est la dernière fonction produisant une ou plusieurs données consommées, les coeurs Cl , 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 coeur 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. 15 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 REVENDICATIONS1. Procédé de traitement d'une pluralité de fonctions (DC_Ci_n, DNC_a_n) prédéterminées mises en oeuvre par un calculateur (1) de véhicule automobile, ledit calculateur (1) comprenant un microcontrôleur (10), ledit microcontrôleur (10), dit « multicceur », comprenant une pluralité de coeurs (Cl, C2, C3), chaque coeur (Cl, 02, C3) de ladite pluralité de coeurs (Cl, C2, 03) étant apte à traiter au moins une fonction (DC_Ci_n. DNC_Ci_n) de ladite pluralité de fonctions (DC_Ci_n. DNC_Ci_n), certaines fonctions (DC_Ci_n. DNC_ci_n) de la pluralité de fonctions (DC_ci_n. DNC_Ci_n) produisant au moins une donnée dite «consommée » utilisée par une autre fonction (DC_Ci_n. DNC_Ci_n) de la pluralité de fonctions (DC_Ci_n. DNC_a_n) lors du traitement de la pluralité de fonctions (DC_Ci_n. DNC_Ci_n) par le microcontrôleur (10), ledit procédé étant caractérisé en ce que chaque fonction (DC_Ci_n, DNC_Ci_n) é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 O à N. N étant un entier naturel définissant le dernier ordre à traiter, le traitement (S2) par la pluralité de coeurs (C1, C2, 03) de toutes les fonctions (DC_Ci_n) 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 (DC_ci_n+1. DNC_Ci_n+1) d'ordre n+1, 2. Procédé selon la revendication 1, dans lequel chaque coeur (C1, C2, 03) traite, à chaque ordre n, une et une seule fonction (DC_Ci_n) produisant au moins une donnée consommée d'ordre n. Procédé selon l'une des revendications précédentes, dans lequel certaines des fonctions (DNC_ci_n) de la pluralité de fonctions (DC_Ci_n. DNC_a_n) ne produisant pas de donnée consommée mais au moins une donnée dite «non- consommée », chaque fonction (DNC_Ci_n) étant caractérisée par un ordre n prédéterminé, le procédé comprenant le traitement au moins partiel, sur au moins un coeur (Cl, C2, C3), d'au moins une fonction (DNC_Ci_n) d'ordre n produisant au moins une donnée non-consommée avant de traiter les fonctions (DC_ci_n+1, DNC_Ci_n+1) d'ordre n+1 tant qu'au moins une fonction (DC_Ci_n) produisant au moins une donnée consommée est en cours de traitement par l'un des coeurs (01, C2, 03). 4. Procédé selon la revendication précédente, dans lequel chaque coeur (Cl, C2, 03) traite, à chaque ordre n, une et une seule fonction produisant au moins une donnée non consommée. 5. Procédé selon l'une des revendications précédentes, dans lequel chaque coeur (C1, C2, C3) traite après l'ordre N les fonctions produisant au moins une donnée 13 non-consommée qui ont au moins partiellement été traitées préalablement ou qui n'ont pas encore été traitées. 6. Calculateur (1) pour véhicule automobile, ledit calculateur (1) comprenant un microcontrôleur (10), ledit microcontrôleur (10), dit « multicceur », comprenant une 5 pluralité de coeurs (Cl, C2, 03), chaque coeur (Cl, 02, 03) de ladite pluralité de coeurs (Cl, C2, 03) étant apte à traiter au moins une fonction (DC_Ci_n. DNC_Ci_n) d'une pluralité de fonctions (DC_Ci_n, DNC_Ci_n), certaines fonctions (DC_ci_n, DNC_Ci_n) de ladite pluralité de fonctions (DC_Ci_n. DNC_Ci_n) produisant au moins une donnée dite «consommée » utilisée par une autre fonction (DC_Ci_n. DNC_Ci_n) de 10 la pluralité de fonctions (DC_Ci_n. DNC_Ci_n) lors du traitement de la pluralité de fonctions (DC_Ci_n. DNC_Ci_n) par le microcontrôleur (10), ledit calculateur (1) étant caractérisé en ce que, chaque fonction (DC_Ci_n, DNC_Ci_n) é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 (DC_Ci_n, DNC_Ci_n) à des données consommées 15 produites par les autres fonctions (DC_Ci_n. DNC_a_n), chaque coeur (C1, C2, 03) est configure, 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 (DC_Ci_n) 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 (DC_Ci_n+1. DNC_Ci_n-F1) d'ordre n-Fl. 20 7. Calculateur (1) selon la revendication précédente, dans lequel chaque coeur (Cl, C2, C3) est configuré pour traiter, à chaque ordre n, une et une seule fonction (DC_Ci_n) produisant au moins une donnée consommée. 8. Calculateur (1) selon l'une des revendications 6 ou 7, dans lequel, certaines des fonctions (DNC_Ci_n) de la pluralité de fonctions (DC_Ci_n. DNC_Ci_n) ne 25 produisant pas de donnée consommée mais au moins une donnée dite « non-consommée », chaque fonction (DNC_Ci_n) étant caractérisée par un ordre n prédéterminé, le calculateur (1) est configure pour traiter au moins partiellement au moins une fonction (DNC_Ci_n) d'ordre n produisant au moins une donnée non-consommée avant de traiter les fonctions (DC_Ci_n+1, DNC_Ci_n+1) d'ordre n+1 tant qu'au moins 30 une fonction (DNC_Ci_n) produisant au moins une donnée consommée est en cours de traitement par l'un des coeurs (C1, C2, 03). 9. Calculateur (1) selon la revendication précédente, dans lequel chaque coeur (01, C2, C3) est configure pour traiter, à chaque ordre n, une et une seule fonction (DNC_Ci_n) produisant au moins une donnée non consommée. 35 10. Véhicule automobile comprenant un calculateur (1) selon l'une des revendications 6 à 9.