MULTICOEUR

[0001 ] L'invention porte sur un procédé de contrôle commande par un microprocesseur multi-cœur, c'est-à-dire à plusieurs cœurs aussi dénommés unités de traitement. L'invention se situe dans le domaine du traitement en temps réel utilisant les ressources de processeurs à coeurs multiples.

[0002] Elle trouve une application particulière mais non limitative dans le domaine des véhicules automobiles pour calculateurs d'un contrôle commande moteur avec une architecture de système ouvert, c'est-à-dire un système dans lequel il est possible de réutiliser du logiciel d'application selon une interface standard ou dans une version dite adaptable un système dans lequel il est possible d'ajouter ou d'enlever de nouvelles fonctionnalités en cours d'exécution.

[0003] Une telle architecture de système ouvert peut être une architecture selon la norme Autosar pour un système à architecture ouverte pour automobile aussi connu sous la dénomination anglo-saxonne de « AUTomotive Open System Architecture », sans que ce soit une obligation pour cette invention.

[0004] Les calculateurs de contrôle moteur utilisaient jusqu'à ces dernières années des processeurs avec une seule unité de traitement, c'est-à-dire un processeur monocoeur. Plus récemment on assiste à l'apparition de processeurs comportant au moins deux unités de traitement, encore dénommés processeurs à coeurs multiples qui permettent une puissance de calcul supérieure à celle des processeurs monocoeur, tout en utilisant une fréquence de fonctionnement égale à celle d'un processeur monocoeur.

[0005] Classiquement, l'architecture fonctionnelle découpe les fonctions en sous- fonctions selon des besoins de répartition du travail ou de gestion de la diversité des options. Classiquement ce découpage fonctionnel est à la base des procédés de répartition du logiciel sur plusieurs cœurs de calcul. De plus une étude de graphes de transitions entre les différentes sous-fonctions est parfois utilisée pour cela. Plus simplement, actuellement, la mise en œuvre de fonctions sur deux unités de traitement d'un processeur à coeurs multiples est par exemple réalisée par une allocation sur un cœur du logiciel d'applications au-dessus d'une interface de l'architecture du système ouvert et une allocation du logiciel de base du système sur un autre cœur du processeur. Classiquement, les entités exécutables du logiciel sont groupées en tâches logicielles selon leur type d'activation. Chaque tâche logicielle comporte des entités exécutables d'un seul type d'activation. Ces tâches logicielles sont ainsi aptes à être gérées en temps réel par un moniteur de tâches qui les active selon leur type de déclenchement.

[0006] Le passage aux processeurs à coeurs multiples est nécessaire. En effet, la puissance de calcul d'un processeur monocoeur n'augmente plus autant que par le passé du fait notamment du plafonnement de sa fréquence d'utilisation.

[0007] Cela est problématique, d'une part, par rapport au respect des contraintes de temps. Par exemple, dans le domaine des systèmes embarqués dans l'automobile, il y a de fortes contraintes de temps d'exécution pour obtenir la réactivité nécessaire aux performances des organes et des fonctions du véhicule. Ceci est en particulier vrai pour les fonctions de la dynamique du véhicule en relation avec le régime d'un moteur thermique ou pour un véhicule à moteur électrique, ou hybride combinant moteur thermique et électrique.

[0008] Cela l'est, d'autre part, par rapport au volume des traitements qui ne cesse d'augmenter. Par exemple, pour les traitements du logiciel de contrôle commande d'un moteur de véhicule automobile, ceci est engendré notamment par les normes antipollution de plus en plus sévères et par les exigences de basse consommation de plus en plus fortes pour la réduction des émissions de C02 qui augmentent les traitements.

[0009] Les processeurs à coeurs multiples peuvent offrir en théorie plus de puissance de calcul mais ils nécessitent de paralléliser les traitements sur les différents cœurs, alors que ces traitements étaient jusqu'à présents effectués de façon séquentielle sur un seul cœur.

[0010] Pour qu'un processeur à coeurs multiples fonctionne efficacement, les traitements qui sont répartis sur ses différentes unités de traitement ne doivent pas comporter de relations de précédence. En d'autres termes, les unités de traitement doivent pouvoir fonctionner de façon désynchronisée, sans s'attendre mutuellement.

[001 1 ] Cela n'est pas sans poser des difficultés pour l'utilisation de processeurs à coeurs multiples, ceci notamment pour le contrôle moteur d'un véhicule automobile, du fait que les fonctions comportent fréquemment des asservissements en forme de boucles des sorties vers les entrées. Ces boucles de contrôle commande doivent s'exécuter dans un ordre précis et ne peuvent donc pas être découpées pour être parallélisées sur deux unités de traitement indépendantes. [0012] Il s'ensuit que l'allocation de l'ensemble ou d'une grosse partie de l'application sur une unité de traitement crée un déséquilibre de charge de travail entre les différentes unités de traitement, ce qui ne permet pas d'exploiter pleinement le potentiel d'un processeur à coeurs multiples. C'est particulièrement vrai dans le domaine automobile pour un calculateur de contrôle moteur d'une architecture de système ouvert dans lequel la charge de calcul de l'ensemble de l'application est beaucoup plus grosse que celle du logiciel de base d'une architecture de système ouvert.

[0013] Selon l'état de l'art de la conception des systèmes, il se trouve que souvent une fonction et le module logiciel correspondant comportent respectivement des sous- fonctions et des entités exécutables de différents types d'activation. Cela va entraîner une difficulté à répartir les modules sur différentes unités de traitement ou cœurs du microprocesseur.

[0014] En effet, dans le cadre d'une architecture à système ouvert du type Autosar, un module, c'est-à-dire un composant atomique au sens Autosar, ne peut être scindé sur plusieurs cœurs. Donc toutes les entités exécutables d'un module doivent aller sur le même cœur ou unité de calcul. On retrouve parfois aussi cette contrainte dans des logiciels ne faisant pas partie d'une architecture de système ouvert car elle est simplement liée à une conception du logiciel qui partage des variables globales à une fonction par les différentes sous-fonctions. [0015] D'autre part, les boucles de contrôle commande englobent souvent plusieurs fonctions et donnent naissance à des entités exécutables réparties en différentes sous- fonctions qui ont un même type de déclenchement. Ces entités exécutables doivent suivre un ordre de séquencement prédéfini au sein de leur tâche logicielle : elles doivent en conséquence aussi être sur la même unité de traitement. [0016] Il en résulte que dans cette conception classique il faut mettre une grosse partie du système fonctionnel sur une même unité de traitement, ce qui produit une surcharge de calcul sur celle-ci alors que d'autres unités de traitement sont sous-employées.

[0017] Parfois, les entités exécutables d'un même type de déclenchement sont néanmoins réparties sur différentes unités de traitement, sous la contrainte de relations de précédence entre les unités de traitement pour respecter l'ordre d'exécution de ces entités exécutables. Cela produit dans une implémentation sur processeur à coeurs multiples des temps d'attente et potentiellement des temps de réponses supérieurs à ceux d'une implémentation en processeur monocoeur. Il en résulte des situations qui peuvent devenir critiques du point de vue des performances en temps réel, en particulier pour le respect des périodes de tâches périodiques réparties sur plusieurs unités de traitement.

[0018] Par conséquent, le problème à la base de l'invention est de permettre l'accélération des traitements des cœurs multiples d'un processeur multicœur afin que ces traitements puissent se faire en temps réel sans délai.

[0019] Pour atteindre cet objectif, il est prévu selon l'invention un procédé de contrôle commande mettant en œuvre des tâches logicielles par un microprocesseur multicoeurs comportant plusieurs cœurs en tant qu'unités de traitement travaillant en parallèle, ces tâches logicielles comprenant :

-des tâches logicielles dites synchrones à période variable,

-des tâches logicielles dites périodiques à période fixe,

-des tâches logicielles ni synchrones, ni périodiques,

ces tâches sont regroupées en au moins un premier groupe de tâches logicielles périodiques et un deuxième groupe de tâches synchrones et en ce que le groupe de tâches périodiques, d'une part, et le groupe de tâches synchrones, d'autre part, sont traités par au moins un cœur du microprocesseur leur étant spécifique, les tâches ni synchrones, ni périodiques étant traitées par ledit au moins un cœur du premier groupe de tâches périodiques ou au moins un cœur du second groupe de tâches synchrones ou par au moins un autre cœur que les cœurs spécifiques des tâches synchrones et périodiques en formant au moins un troisième groupe.

[0020] L'effet technique est d'obtenir une architecture de logiciel qui ne génère pas de temps d'attente entre les différentes unités de traitement ou cœurs du microprocesseur. Les entités exécutables qui ont un déclenchement de type synchrone du moteur peuvent être regroupées en une ou plusieurs tâches et prises en charge par une ou des autres unités de traitement spécifiques, c'est-à-dire un ou des cœurs du microprocesseur, autres que le ou les unités de traitement qui traitent les tâches périodiques.

[0021 ] Cette répartition des tâches logicielles permet de rendre beaucoup plus régulier l'exécution des tâches périodiques qui se déroulent alors selon un ordre stable et déterministe, sans être interrompues par des tâches synchrones du moteur qui sont en général prioritaires. Le système est ainsi plus simple à valider parce que les marges de temps de réponse pour les tâches périodiques ne dépendent plus des conditions de fonctionnement de l'organe ou des organes à piloter. [0022] Par exemple, pour le cas non limitatif d'un contrôle commande intégré dans un véhicule automobile et pilotant le moteur, les conditions de fonctionnement incluent le régime moteur. A plein régime moteur, ce qui correspond à une charge de calcul maximale dans le microprocesseur d'un contrôle commande du moteur, la charge de calcul est bien répartie entre les unités de traitement qui ont en charge les tâches synchrones moteur et celles qui ont en charge les tâches périodiques.

[0023] D'une façon générale, selon l'invention, en fonction du nombre d'unités de traitement ou cœurs disponibles dans le microprocesseur et en fonction du poids de chaque type de tâche, il est possible d'optimiser l'allocation des traitements sur différentes unités de traitement en se basant sur leur type de déclenchement, essentiellement périodique ou synchrone et non plus sur une architecture fonctionnelle.

[0024] Avantageusement, ledit au moins un troisième groupe de tâches comprend les tâches s'activant de manière aléatoire. Etant donné le caractère non prédictif des tâches s'activant de manière aléatoire, on aura aussi avantage à leur dédier au moins une unité de traitement ou un cœur spécifique. De cette manière, les tâches périodiques ou synchrones ne sont pas perturbées par les tâches s'activant de manière aléatoire.

[0025] Avantageusement, les tâches s'activant de manière aléatoire comprennent des tâches activées par interruption non souhaitée d'une fonction contrôlée et/ou commandée par le microprocesseur ou d'au moins un organe de contrôle et/ou de commande dédié à la fonction et piloté par le microprocesseur. Une partie des tâches s'activant de manière aléatoire s'apparentent à des pannes de l'organe ou des organes contrôlés par le microprocesseur.

[0026] Avantageusement, le premier groupe de tâches périodiques est scindé en au moins deux sous-groupes correspondant à des tâches présentant des périodes différentes, chaque sous-groupe étant traité par un cœur différent.

[0027] Avantageusement, un premier des sous-groupes correspond à des tâches logicielles s'effectuant à des périodes inférieures ou égales à un premier seuil, tandis que le deuxième des sous-groupes correspond à des tâches logicielles s'effectuant à des périodes supérieures à un second seuil, le premier seuil étant inférieur ou égal au deuxième seuil.

[0028] Avantageusement, au moins une entité exécutable est propre à au moins une tâche respective d'une partie des tâches des premier et deuxième groupes. La présente invention propose ainsi qu'un module logiciel soit décomposé plus finement par rapport à l'état de l'art actuel afin de ne contenir des entités exécutables que d'un seul type d'activation. Ainsi, il sera possible de répartir les tâches d'un moniteur de tâche sur des cœurs différents. [0029] Avantageusement, un moniteur de tâche est utilisé au moins pour chaque tâche des premier et deuxième groupes et est intégré dans le cœur du microprocesseur spécifique pour ladite tâche.

[0030] Avantageusement, au moins une des tâches synchrones est relative à une ou plusieurs fonctions synchrones d'un moteur piloté par un contrôle commande en tournant à un régime variable, ces fonctions présentant une période d'exécution variable fonction du régime du moteur à un instant donné.

[0031 ] Une analyse du système physique permet de remarquer que les fonctions synchrones du moteur ont une période d'exécution variable : ainsi par exemple la tâche synchrone moteur est tantôt plus lente que la tâche périodique à 10 ms tantôt plus rapide, selon le régime du moteur. Il est donc intéressant de traiter les tâches synchrones du moteur et les tâches périodiques en parallèle sur au moins deux cœurs différents sachant qu'en conséquence de la constitution du système physique, les fonctions synchrones du moteur n'ont généralement pas de relation de précédence avec les tâches périodiques et réciproquement. [0032] L'invention concerne aussi un processeur à plusieurs cœurs pour un contrôle commande, caractérisé en ce qu'il met en œuvre un tel procédé.

[0033] L'invention concerne aussi un contrôle commande de véhicule automobile, caractérisé en ce qu'il comprend un processeur tel que précédemment mentionné.

[0034] L'invention concerne enfin un véhicule automobile comprenant au moins un moteur et un tel contrôle commande au moins en charge du fonctionnement dudit au moins un moteur et d'une aide à la conduite du véhicule comme, pris unitairement ou en combinaison, un système d'antiblocage des roues ou ABS, un électrostabilisateur programmé ou ESP, une boîte de vitesses automatique ou BVA, une direction assistée électrique. [0035] D'autres caractéristiques, buts et avantages de la présente invention apparaîtront à la lecture de la description détaillée qui va suivre et au regard des dessins annexés donnés à titre d'exemples non limitatifs et sur lesquels : - la figure 1 est une représentation schématique d'un exemple de processeur multicoeurs avec n unités de calcul, ce processeur pouvant permettre la mise en œuvre du procédé selon l'invention,

- la figure 2 est une représentation schématique d'un exemple de décomposition fonctionnelle en fonction et sous-fonctions dans un processeur multicoeurs selon l'état de la technique,

- la figure 3 est une représentation schématique d'un exemple de composition d'un logiciel avec m modules et des entités exécutables en chaque module dans un processeur pouvant permettre la mise en œuvre du procédé selon l'invention. [0036] Il est à garder à l'esprit que les figures sont données à titre d'exemples et ne sont pas limitatives de l'invention. Elles constituent des représentations schématiques de principe destinées à faciliter la compréhension de l'invention.

[0037] Dans ce qui va suivre, il est fait référence à toutes les figures prises en combinaison. Quand il est fait référence à une ou des figures spécifiques, ces figures sont à prendre en combinaison avec les autres figures pour la reconnaissance des références numériques désignées.

[0038] L'invention concerne l'organisation du traitement des tâches dans un processeur qui met en oeuvre différentes unités de traitement, c'est-à-dire différents cœurs d'un processeur à coeurs multiples. Elle propose d'architecturer le logiciel pour pouvoir le répartir sur les différentes unités de traitement, selon un scénario avantageux pour maximiser l'utilisation des unités de traitement ou cœurs et obtenir des temps de réponses optimaux.

[0039] Il va être débuté par un rappel du contexte d'un processeur à coeurs multiples comportant plusieurs unités de traitement autonomes. [0040] Selon la figure 1 , un processeur à coeurs multiples 1 se caractérise par le fait qu'il met en œuvre plusieurs unités de traitement 1 .1 , 1 .2 à 1 .p. A titre d'exemple non limitatif, un processeur à coeurs multiples pour un contrôle moteur d'un véhicule automobile fréquemment utilisé peut comporter trois unités de traitement. Cet exemple sera utilisé pour illustrer l'invention, mais on pourrait de façon avantageuse utiliser de façon similaire un processeur comportant davantage d'unités de traitement, comme par exemple un processeur comportant six unités de traitement ou tout autre nombre supérieur à 3. [0041 ] Pour obtenir des temps de réponses les plus rapides possible, les unités de traitement d'un processeur à coeurs multiples doivent pouvoir travailler de façon indépendante, sans s'attendre les unes les autres. Pour cela il est procédé à une mise en en parallèle des traitements. Ceci est montré à la figure 1 qui illustre un exemple d'un processeur à coeurs multiples avec p unités de calcul comme unités de traitement.

[0042] Dans ce qui va suivre, il va ensuite être procédé à un rappel de ce qu'est une architecture fonctionnelle connue. Classiquement, une architecture fonctionnelle découpe les fonctions en sous-fonctions selon des besoins de répartition du travail de conception ou de gestion de la diversité des options. [0043] En se référant à la figure 2, qui montre un exemple de décomposition fonctionnelle en fonction et sous-fonctions pour une architecture fonctionnelle qui peut être à deux niveaux. Il est alors fait une distinction entre:

l'ensemble des fonctions ou système fonctionnel 2,

- les fonctions, au nombre de f qui sont référencées 2.1 à 2.f,

- les sous-fonctions, encore nommées fonctions élémentaires, au nombre de S1 pour la fonction 2.1 et au nombre de Sf pour la fonction 2.f.

[0044] Il est bien connu dans l'état de l'art des systèmes fonctionnant en temps réel que les mécanismes d'activation des fonctions élémentaires peuvent être périodiques de période fixe, ou cycliques avec une période variable, ou événementiels aléatoires. [0045] Dans ce qui va suivre, la présente invention va être illustrée en prenant ces exemples de types d'activation. Il convient cependant de garder à l'esprit que d'autres types d'activation peuvent être pris en compte de façon similaire.

[0046] La figure 3 présente un exemple d'une architecture de logiciel issue d'une conception fonctionnelle selon l'état de l'art existant mais pouvant mettre en œuvre le procédé selon la présente invention, l'architecture comprenant m modules et des entités exécutables en chaque module.

[0047] A cette figure 3, il est possible de distinguer :

- le logiciel 3,

- des entités élémentaires de conception du logiciel nommées modules dans la suite de la présente description, au nombre de m, 3.1 à 3. m, qui correspondent à des composants logiciels dans le contexte d'une architecture de système, - des entités élémentaires d'exécution du logiciel correspondant à des portions de modules qui sont activées chacune par un mécanisme particulier, ci-après dénommées entités exécutables dans la suite de la présente description, au nombre de R1 dans le module 3.1 et au nombre de Rm dans le module 3. m. [0048] En se référant aux figures 2 et 3, au système fonctionnel 2 correspond le logiciel 3, aux fonctions 2.x correspondent les modules 3.x et aux fonctions élémentaires 2.x. y correspondent les entités exécutables 3.x.y.

[0049] Dans l'implémentation du logiciel, il est bien connu selon l'état de l'art que les entités exécutables sont regroupées par type de déclenchement en tâches logicielles. Autrement dit une tâche logicielle est un ensemble d'entités exécutables d'un même type de déclenchement. Un moniteur de tâche a pour rôle d'activer au fur et à mesure des déclenchements les différentes tâches.

[0050] Dans le domaine automobile du contrôle moteur, sans que cela soit limitatif, il peut être cité des exemples de différents types d'activation de fonctions élémentaires 2.x.y :

- activation périodique avec une période fixe d'environ 10 ms,

- activation périodique avec une période fixe d'environ 5ms,

- activation événementielle cyclique avec une période variable. Dans le cas d'un contrôle commande pilotant un moteur, synchronisé par exemple relativement à une position de piston, un régime moteur, cette activation est aussi désigné synchrone moteur,

- activation événementielle aléatoire issue du matériel, encore nommée interruption.

[0051 ] La présente invention consiste à concevoir une architecture fonctionnelle du logiciel avec un niveau supplémentaire de découpage des fonctions défini par la séparation des entités exécutables 3.x.y par type d'activation. Ainsi, chaque fonction ne comporte que des fonctions élémentaires d'un type d'activation.

[0052] L'invention concerne un procédé de contrôle commande mettant en œuvre des tâches logicielles par un microprocesseur multicoeurs comportant plusieurs cœurs en tant qu'unités de traitement travaillant en parallèle, ces tâches logicielles comprenant des tâches logicielles dites synchrones à période variable, des tâches logicielles dites périodiques à période fixe, des tâches logicielles ni synchrones, ni périodiques. Selon l'invention, ces tâches sont regroupées en au moins un premier groupe de tâches logicielles périodiques et un deuxième groupe de tâches synchrones et le groupe de tâches périodiques, d'une part, et le groupe de tâches synchrones, d'autre part, sont traités par au moins un cœur du microprocesseur leur étant spécifique, c'est-à-dire par au moins un cœur différent.

[0053] Les tâches logicielles ni synchrones, ni périodiques sont traitées par ledit au moins un cœur du premier groupe de tâches périodiques ou au moins un cœur du second groupe de tâches synchrones ou par au moins un autre cœur que les cœurs spécifiques des tâches synchrones et périodiques en formant au moins un troisième groupe. Comme il sera vu par la suite, cette deuxième solution est préférée.

[0054] Une analyse d'un logiciel de contrôle moteur montre que la majorité de la charge de calcul se répartit entre deux grands groupes, à savoir les tâches synchrones et les tâches périodiques. Les tâches synchrones du moteur n'ont pas du tout de relation de précédence avec les tâches périodiques. Elles peuvent donc être mises en parallèle des tâches périodiques.

[0055] De manière générale, dans le moteur, les tâches logicielles synchrones sont prioritaires sur les tâches logicielles périodiques. Quand des tâches logicielles périodiques sont confiées au contrôle commande, dès que ces tâches logicielles périodiques ont démarré, elles peuvent redonner le contrôle au programme principal sans avoir nécessairement terminé leur exécution.

[0056] Un autre groupe, appelée troisième groupe de tâches, comprend les tâches logicielles s'activant de manière aléatoire. Les tâches s'activant de manière aléatoire peuvent comprendre principalement des tâches activées par interruption non souhaitée d'une fonction contrôlée et/ou commandée par le microprocesseur ou d'au moins un organe de contrôle et/ou de commande dédié à la fonction et piloté par le microprocesseur. Ces interruptions sont fréquemment des interruptions matérielles. Dans le moteur, ces tâches logicielles s'activant de manière aléatoire sont prioritaires sur les tâches logicielles synchrones.

[0057] Dans le cas non limitatif d'un processeur avec trois cœurs 1 .1 , 1 .2 à 1 .3 réalisant des unités de traitement, la présente invention permet par exemple la répartition suivante qui équilibre au mieux la charge de calcul entre les trois coeurs :

- unité de traitement pour les tâches périodiques lentes, par exemple de période supérieure ou égale à 10 ms,

- unité de traitement pour les tâches synchrones du moteur, - unité de traitement pour les tâches sous interruption matérielle et les tâches périodiques rapides par exemple de période inférieure ou égale à 5ms.

[0058] Une analyse supplémentaire du système montre que généralement la conception fonctionnelle produit des tâches périodiques, avec des sous-fonctions qui n'ont pas de relation de précédence entre différentes périodes d'activation.

[0059] On peut donc mettre en parallèle sur différentes unités de traitement, sans les ralentir mutuellement des tâches périodiques de différentes périodes. Le premier groupe de tâches périodiques peut être scindé en au moins deux sous-groupes correspondant à des tâches logicielles s'effectuant à des périodes différentes, chaque sous-groupe étant traité par un cœur différent du microprocesseur. Le premier des sous-groupes peut ainsi correspondre à des tâches logicielles s'effectuant à des périodes inférieures ou égales à un premier seuil Sp1 , par exemple de 5 ms tandis que le deuxième sous-groupe peut correspondre à des tâches logicielles s'effectuant à des périodes supérieures à un second seuil Sp2, par exemple 10ms, le premier seuil Sp1 étant inférieur ou égal au deuxième seuil Sp2.

[0060] Tout cela sera rendu possible en maximisant la capacité de traitement globale et en minimisant les temps de réponse du système. Ceci requiert comme condition qu'on ait fait une architecture du logiciel basée sur un découpage fin des fonctions 2.1 à 2.f en sous fonctions 2.x.y afin d'obtenir des entités exécutables 3.x.y d'un seul type d'activation du logiciel dans chaque module logiciel 3.1 à 3. m.

[0061 ] Ainsi, au moins une entité exécutable 3.x.y peut être propre à au moins une tâche logicielle respective d'une partie des tâches logicielles des premier et deuxième groupes. En général chaque tâche logicielle peut présenter au moins une entité exécutable 3.x.y sauf si plusieurs tâches logicielles sont similaires. Le moniteur de tâche, précédemment mentionné dans la description de l'état de la technique, peut être, dans le cadre de l'invention, spécifique au moins pour chaque tâche logicielle des premier et deuxième groupes et peut être intégré dans le cœur du microprocesseur spécifique pour ladite tâche.

[0062] Selon l'invention, il existe une possibilité de répartition de la charge de calcul entre les différents cœurs 1 .1 , 1 .2 à 1 .p de traitement pour en diminuer la charge de calcul et pour en améliorer le temps de réponse.

[0063] L'invention concerne aussi un processeur à plusieurs cœurs 1 .1 , 1 .2 à 1 .p pour un contrôle commande, caractérisé en ce qu'il met en œuvre un tel procédé. [0064] Dans une application non limitative mais avantageuse, l'invention concerne aussi un contrôle commande de véhicule automobile, caractérisé en ce qu'il comprend un processeur tel que précédemment mentionné.

[0065] La présente invention va maintenant être développée dans le cadre d'un contrôle commande pour véhicule automobile, principalement un contrôle commande de moteur qui peut aussi piloter d'autres fonctionnalités présentes dans le véhicule automobile. Ceci est une application préférée de la présente invention mais n'est pas limitative.

[0066] Dans ce cas, quand au moins une des tâches synchrones est relative à une ou plusieurs fonctions synchrones d'un moteur piloté par un contrôle commande en tournant à un régime variable, ces fonctions présentent une période d'exécution variable qui est fonction du régime du moteur à un instant donné.

[0067] En particulier, pour le cas spécifique et non limitatif d'un contrôle moteur, une part très importante des tâches périodiques est constituée d'abord par les tâches logicielles de période de 10 ms puis par celles de période de 5 ms. Si on dispose de suffisamment d'unités de traitement, on pourra avantageusement réserver une unité de traitement majoritairement pour les tâches à 10 ms et mettre les tâches à 5 ms sur une autre unité de traitement.

[0068] L'invention concerne enfin un véhicule automobile comprenant au moins un moteur et un tel contrôle commande au moins en charge du fonctionnement dudit au moins un moteur.

[0069] Prendre en charge le fonctionnement du moteur signifie prendre en charge son alimentation en air et carburant, son échappement notamment en ce qui concerne les éléments de dépollution présents dans sa ligne d'échappement et tous ses périphériques, par exemple une ligne de recirculation des gaz d'échappement à l'admission d'air, un turbocompresseur, son système de lubrification et son système de refroidissement pris dans son sens large avec le cas échéant la climatisation de l'habitacle.

[0070] Le contrôle commande peut piloter aussi une aide à la conduite du véhicule, comme pris unitairement ou en combinaison un système d'antiblocage des roues ou ABS, un électrostabilisateur programmé ou ESP, une boîte de vitesses automatique ou BVA, une direction assistée électrique, sans que cela soit limitatif.

[0071 ] Dans le cadre de la présente invention, il existe aussi une possibilité d'utilisation du microprocesseur pour plusieurs types de véhicule, ceci en ajoutant de nouvelles fonctions logicielles sans devoir reconcevoir l'électronique du microprocesseur. La place disponible pour les nouvelles fonctions logicielles a été augmentée par la mise en oeuvre du procédé selon l'invention.

[0072] L'invention n'est nullement limitée aux modes de réalisation décrits et illustrés qui n'ont été donnés qu'à titre d'exemples.