FR3043808A1 - Procede de controle commande de taches fonctionnelles par un microprocesseur multicoeurs - Google Patents

Abstract

L'invention porte sur un procédé de contrôle commande de tâches fonctionnelles par un microprocesseur multicoeurs comportant plusieurs cœurs en tant qu'unités de traitement travaillant en parallèle, caractérisé en ce que les tâches sont différenciées entre au moins un premier groupe de tâches 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 non différenciées comme étant des tâches périodiques ou synchrones étant traitées par ledit au moins un cœur du premier ou du deuxième groupe de tâches périodiques 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.

Description

PROCEDE DE CONTROLE COMMANDE DE TACHES FONCTIONNELLES PAR UN

MICROPROCESSEUR MULTICOEURS

[0001] L’invention porte sur un procédé de contrôle commande de tâches fonctionnelles par un microprocesseur multicoeurs, 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 des fonctionnalités 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 du logiciel associé au microprocesseur découpe les fonctions en sous-fonctions selon des besoins de répartition du travail ou de gestion de la diversité des options. Actuellement, une allocation 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.

[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 leur 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.

[0011] 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 ou tâche et donc un module comporte des sous-fonctions ou sous-tâches et donc 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 coeurs 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 coeurs. 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’une même tâche 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 multicoeurs 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 de tâches fonctionnelles par un microprocesseur multicoeurs comportant plusieurs cœurs en tant qu’unités de traitement travaillant en parallèle, caractérisé en ce que les tâches sont différenciées entre au moins un premier groupe de tâches 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 non différenciées comme étant des tâches périodiques ou synchrones é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 fonctions ou tâches synchrones 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] Ceci 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 coeurs 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, 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.

[0028] Avantageusement, un moniteur de tâche est spécifique 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.

[0029] 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é.

[0030] 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.

[0031] 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é.

[0032] 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é.

[0033] 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.

[0034] 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 de tâches 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.

[0035] 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.

[0036] 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.

[0037] 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 coeurs 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 coeurs et obtenir des temps de réponses optimaux.

[0038] Il va être débuté par un rappel du contexte d’un processeur à coeurs multiples comportant plusieurs unités de traitement autonomes.

[0039] Selon la figure 1, un processeur à coeurs multiples 1 se caractérise par le fait qu’il met en oeuvre 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.

[0040] 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é à un mise en en parallèle des traitements. Ceci est montré à la figure 1 qui illustre un exemple d’un processeur à coeurs multiples avec n unités de calcul comme unités de traitement.

[0041] 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 ou de gestion de la diversité des options.

[0042] 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.

[0043] 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 ou événementiels.

[0044] 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.

[0045] 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 oeuvre le procédé selon la présente invention, l’architecture comprenant m modules et des entités exécutables en chaque module.

[0046] 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 se distinguent 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.

[0047] 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.

[0048] 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. Un moniteur de tâche a pour rôle d’activer au fur et à mesure des déclenchements les différentes tâches.

[0049] 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 : activation périodique avec une période d’environ 10 ms, - activation périodique avec une période d’environ 5ms, activation événementielle cyclique, par exemple relative à une position de piston, cette activation étant nommée synchrone moteur, activation événementielle aléatoire issue du matériel, encore nommée interruption.

[0050] La présente invention consiste préalablement à concevoir l’architecture du logiciel avec un niveau supplémentaire de séparation des entités exécutables R1 à Rm par type d’activation.

[0051] L’invention concerne un procédé de contrôle commande de tâches 2.1 à 2.f.p fonctionnelles par un microprocesseur multicoeurs comportant plusieurs cœurs 1.1, 1.2 à 1.p en tant qu’unités de traitement travaillant en parallèle. Selon l’invention, les tâches 2.1 à 2.f.p confiées au pilotage par le contrôle commande sont différenciées entre au moins un premier groupe de tâches périodiques et un deuxième groupe de tâches synchrones. 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.

[0052] Les tâches 2.1 à 2.f.p non différenciées comme étant des tâches périodiques ou synchrones sont traitées par ledit au moins un cœur du premier groupe de tâches périodiques ou par au moins un autre cœur que les cœurs 1.1, 1.2 à 1 .p 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.

[0053] Une analyse d’un logiciel de contrôle moteur montre en effet 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 ou peu 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.

[0054] De manière générale, les tâches synchrones sont des tâches 2.1 à 2.f.p qui redonnent le contrôle au programme principal une fois qu'elles ont été exécutées. Quand des tâches 2.1 à 2.f.p asynchrones sont confiées au contrôle commande, dès que ces tâches 2.1 à 2.f.p asynchrones ont démarré, elles peuvent redonner le contrôle au programme principal sans avoir nécessairement terminé leur exécution.

[0055] Un autre groupe, appelée troisième groupe de tâches 2.1 à 2.f.p, comprend les tâches 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.

[0056] Dans le cas non limitatif d’un processeur avec trois cœurs 1.1, 1.2 à 1 .p réalisant des unités de traitement, la présente invention permet par exemple la répartition suivante : - unité de traitement pour les tâches périodiques, - unité de traitement pour les tâches synchrones du moteur, - unité de traitement pour les tâches sous interruption matérielle.

[0057] 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.

[0058] 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 2.1 à 2.f.p s’effectuant à des périodes différentes, chaque sous-groupe étant traité par un cœur différent du microprocesseur.

[0059] 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 d’entité exécutable R1 à Rm par type d’activation du logiciel. Ceci est aussi possible dans la mesure où on a exprimé les contraintes de précédence au niveau de la fin des entités exécutables R1 à Rm de façon à pouvoir créer des tâches 2.1 à 2.f.p indépendantes.

[0060] Ainsi, au moins une entité exécutable R1 à Rm peut être propre à au moins une tâche respective d’une partie des tâches 2.1 à 2.f.p des premier et deuxième groupes. En général chaque tâche peut présenter au moins une entité exécutable R1 à Rm sauf si plusieurs tâches 2.1 à 2.f.p sont similaires. Dans ce cas, 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 des premier et deuxième groupes et peut être intégré dans le cœur du microprocesseur spécifique pour ladite tâche.

[0061] 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.

[0062] 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é.

[0063] 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é.

[0064] 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.

[0065] 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é.

[0066] 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 2.1 à 2.f.p 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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.

Claims (10)

1. Revendications :

   1. Procédé de contrôle commande de tâches (2.1 à 2.f.p) fonctionnelles par un microprocesseur multicoeurs comportant plusieurs cœurs (1.1, 1.2 à 1.p) en tant qu’unités de traitement travaillant en parallèle, caractérisé en ce que les tâches (2.1 à 2.f.p) sont différenciées entre au moins un premier groupe de tâches 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 non différenciées comme étant des tâches périodiques ou synchrones é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 (1.1, 1.2 à 1.p) spécifiques des tâches synchrones et périodiques en formant au moins un troisième groupe.
2. 2. Procédé selon la revendication précédente, dans lequel ledit au moins un troisième groupe de tâches comprend les tâches s’activant de manière aléatoire.
3. 3. Procédé selon la revendication précédente, dans lequel 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.
4. 4. Procédé selon l’une quelconque des revendications précédentes, dans lequel 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.
5. 5. Procédé selon l’une quelconque des revendications précédentes, dans lequel 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.
6. 6. Procédé selon l’une quelconque des revendications précédentes, dans lequel un moniteur de tâche est spécifique 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.
7. 7. Procédé selon l’une quelconque des revendications précédentes, dans lequel 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 qui est fonction du régime du moteur à un instant donné.
8. 8. Processeur à plusieurs coeurs (1.1, 1.2 à 1 .p) pour un contrôle commande, caractérisé en ce qu’il met en oeuvre un procédé selon l’une quelconque des revendications précédentes.
9. 9. Contrôle commande de véhicule automobile, caractérisé en ce qu’il comprend un processeur selon la revendication précédente.
10. 10. Véhicule automobile comprenant au moins un moteur et un contrôle commande selon la revendication précédente, lequel est 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.