FR3071334B1

FR3071334B1 - Procede pour assurer la stabilite des donnees d’un processeur multicoeur d’un vehicule automobile

Info

Publication number: FR3071334B1
Application number: FR1758645A
Authority: FR
Inventors: Bernard Bavoux; Thierry Touzeau
Original assignee: PSA Automobiles SA
Current assignee: PSA Automobiles SA
Priority date: 2017-09-19
Filing date: 2017-09-19
Publication date: 2019-08-30
Anticipated expiration: 2037-09-19
Also published as: MA50262A; CN111108471A; FR3071334A1; WO2019058042A1; EP3685256A1

Abstract

L'invention porte sur un procédé conception d'un programme, comprenant : - la détermination d'au moins une donnée variable (D1) à protéger de façon systématique, ladite donnée variable à protéger (D1) étant produite et consommée par au moins deux tâches exécutées en parallèle, la tâche consommatrice présentant une priorité d'exécution supérieure à celle de la tâche productrice, ladite tâche consommatrice réalisant au moins deux accès à la donnée variable à protéger (D1), - l'implémentation d'une fonction de protection (FO) de ladite donnée variable à protéger (D1) de façon systématique lors de l'exécution de la tâche consommatrice, de sorte que les deux accès réalisés par la tâche consommatrice consomment une donnée variable à protéger (D1) ayant une valeur constante. La présente invention prévoit aussi, selon un mode de réalisation, la protection d'au moins une donnée variable préalablement définie comme étant à protéger de façon différenciée.

Description

PROCEDE POUR ASSURER LA STABILITE DES DONNEES D’UN PROCESSEUR MULTICOEUR D’UN VEHICULE AUTOMOBILE

[001] L'invention concerne, de façon générale, les processeurs de calculateur, en particulier montés au sein de véhicules automobiles. L’invention porte plus précisément sur la gestion de la stabilité des données d’un processeur multicœur, notamment intégré dans un véhicule automobile, au moyen d’un procédé d’aide à la conception d’un programme logiciel.

[002] De manière connue, un véhicule automobile comprend différents calculateurs adaptés pour prendre en charge des fonctions recevant des données de capteurs et/ou commandant différents éléments organiques du véhicule.

[003] Un calculateur comprend au moins un processeur comprenant au moins une unité de traitement, également désigné « cœur >>. Un processeur comprenant une seule unité de traitement est désigné « processeur mono-cœur >>. Un cœur permet de mettre en œuvre des fonctions qui traitent les données reçues de capteurs et génèrent des consignes vers des actionneurs. La puissance d’un tel cœur dépend fortement de sa fréquence de fonctionnement donnée en Hz. Aussi, la puissance d’un processeur monocœur est limitée par la fréquence maximale du cœur.

[004] En outre, comme déjà indiqué ci-dessus, la présente invention trouve une application particulière mais non limitative dans le domaine des véhicules automobiles comprenant des calculateurs ayant une architecture de système dit « ouvert >>, c'est-à-dire dans lequel il est possible de réutiliser des fonctionnalités selon une interface standard ou dans une version dite adaptable du système auquel il est par conséquent possible d'ajouter ou d'enlever de nouvelles fonctionnalités en cours d'exécution.

[005] Une telle architecture de système ouvert peut être une architecture selon la norme Autosar pour un système conçu pour être intégré à un véhicule automobile, le terme Autosar étant une contraction de la dénomination anglo-saxonne « AUTomotive Open System Architecture >>, comme cela est connu de l’homme de l’art.

[006] Aujourd’hui, un véhicule comprenant de plus en plus de fonctions, de nombreux calculateurs sont montés au sein du véhicule afin de prendre en charge toutes ces fonctions. Un tel nombre de fonctions et la complexité de certaines d’entre elles imposent de disposer d’au moins un calculateur ayant un processeur très puissant. Un processeur mono-cœur présente alors une puissance trop faible.

[007] Afin d’augmenter la puissance de calcul d’un processeur, il est également connu des microprocesseurs 100 comprenant plusieurs cœurs 101, 102, 103, notamment trois cœurs comme illustré sur la figure 1. Un tel processeur 100 est alors désigné « processeur multicœur >>. Ceci permet d’augmenter la puissance de calcul du microprocesseur 100 à l’aide de plusieurs cœurs 101, 102, 103 présentant chacun une fréquence par exemple égale à la fréquence du cœur d’un processeur mono-cœur. Ceci permet ainsi d’augmenter la puissance du processeur. Un tel processeur 100 comprend également une mémoire 104.

[008] Pour qu'un microprocesseur à cœurs multiples fonctionne efficacement, les traitements qui sont répartis sur ses différentes unités de traitement doivent pouvoir s’exécuter en parallèle et, de ce fait, ces traitements ne doivent pas comporter de relations de précédence les uns entre les autres. Ceci entraîne des difficultés de conception, en particulier lorsqu’il s’agit de développer des programmes logiciels pour une mise en œuvre dans un véhicule automobile, notamment pour le contrôle moteur d'un tel véhicule automobile, du fait que les tâches 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.

[009] Pour pallier cet inconvénient, le procédé décrit dans le document FR 3043808 décrit une technique pour décomposer le logiciel en différentes tâches qui peuvent être exécutées en parallèle par un microprocesseur multicoeur. A cette fin, ce document FR 3043808 propose un partitionnement des tâches fonctionnelles mises en œuvre par un microprocesseur multicoeur configuré de telle sorte que lesdites tâches soient différenciées entre un premier groupe de tâches périodiques et un deuxième groupe de tâches synchrones, chaque groupe de tâches étant exécuté par au moins un cœur du microprocesseur lui étant dédié.

[0010] Cependant, la présente invention, partant de l’enseignement du document FR 3043808, permet de traiter une autre difficulté qui porte sur la consistance des données qui sont manipulées par des tâches logicielles mises en parallèle, et plus précisément sur le besoin de stabilité de certaines données.

[0011] Pour rappel, selon la terminologie en référence à la norme Autosar évoquée ci-dessus, la consistance des données regroupe deux notions : - la stabilité d’une donnée, comme défini en référence Autosar [TPS_SWCT_01481], concerne le besoin que différentes fonctions utilisent la même valeur d’une donnée variable ; - la cohérence d’un groupe de données, comme défini en référence Autosar [TPS_SWCT_01482], concerne le besoin qu’une fonction produise ou consomme un groupe de données échantillonnées au même instant.

[0012] Les besoins de cohérence des données existent déjà avec un processeur monocœur entre différentes tâches préemptives, et ces besoins ne sont pas modifiés par un passage d’un processeur mono-cœur à un processeur multicoeur. Il existe déjà selon l’état de l’art des solutions de protection pour assurer la cohérence d’un groupe de données, ces solutions étant les mêmes pour un processeur mono-cœur ou multicoeur. La présente invention porte sur un dispositif de protection visant à assurer la stabilité d’une donnée, en complément du procédé décrit dans le document FR 3043808. Cependant, toutes les fonctions n’ont pas besoin que les données qu’elles partagent soient stables. La présente invention propose une méthode de protection pour assurer la stabilité d’au moins une donnée de façon systématique en cas de méconnaissance des besoins de stabilité pour cette donnée ou, selon un mode de réalisation, au cas par cas lorsqu’un besoin de stabilité est identifié par le concepteur des fonctions qui utilisent plusieurs fois cette donnée.

[0013] A titre d’exemple illustratif d’un besoin de stabilité qui nécessite un dispositif de protection lors d’un passage d’une architecture monocoeur à une architecture multicoeur, dans le domaine de l’automobile, le mode de combustion d’un moteur thermique est une variable mise à jour par une fonction de gestion du moteur implémentée comme toutes les tâches de gestion dans une tâche périodique, ayant par exemple une période de 10 ms. La variable « mode de combustion moteur » est consommée par différentes fonctions élémentaires d’injection, à savoir les injections précombustion et les injections pendant la combustion et les injections postcombustion, qui sont implémentées dans une tâche synchrone de la combustion. Or, la tâche synchrone est prioritaire par rapport à la tâche périodique de période 10 ms du fait que sa période est supérieure à 10 ms aux régimes moteur les plus élevés. De plus, cette tâche synchrone est généralement préemptive de façon à assurer sans délai son traitement. En conséquence, dans un processeur monocoeur, les entrées de la tâche synchrone de la combustion sont toujours stables car la tâche synchrone exécute toutes les fonctions élémentaires d’injections sans être interrompue. Dans un processeur multicoeur qui répartit la tâche périodique de période 10 ms et la tâche synchrone sur deux coeurs différents, la variable « mode de combustion moteur >> peut changer pendant l’exécution de la tâche synchrone, ce qui engendre potentiellement un dysfonctionnement en l’absence d’un dispositif de protection assurant la stabilité de cette donnée.

[0014] L’exemple précédent illustre qu’une donnée variable qui avait une valeur stable pendant la durée d’une tâche dans une architecture logicielle monocoeur n’a pas obligatoirement une valeur stable dans une autre architecture logicielle multicoeur. Or, d’une part, dans certains cas, cela n’a pas de conséquence parce qu’il n’y a pas de besoin fonctionnel de stabilité de la donnée variable. D’autre part, dans d’autres cas, cela peut générer un dysfonctionnement lors d’un changement d’architecture logicielle.

[0015] En outre, de manière générale, dans le contexte où l’architecture d’un programme logiciel est modifiée, pour passer d’une architecture monocoeur à une architecture multicoeur, ou lorsqu’une nouvelle partie d’un programme logiciel est développée et destinée à coopérer avec une partie de programme logiciel tierce, préexistante, des données variables peuvent ne pas avoir été identifiées comme étant à protéger pour assurer leur stabilité, alors qu’elles l’étaient ou le deviennent en raison de la nouvelle architecture ou de l’arrivée de la nouvelle partie de programme logiciel.

[0016] En résumé, dans un contexte de tâches préemptives comme évoqué ci-dessus, un problème de stabilité de données variable peut apparaître lorsqu’une donnée variable est consommée par une tâche consommatrice extérieure à la tâche productrice et ayant une priorité supérieure à celle de ladite tâche productrice. Il faut noter, en effet, que lorsqu’une tâche productrice est prioritaire vis-à-vis d’une tâche consommatrice, la question de la protection des données variables est nécessairement déjà prise en compte dans la conception antérieure d’une architecture mono-cœur.

[0017] Dans le cadre de la présente invention, lors de la conception d’une nouvelle architecture multicoeur à partir d’une architecture mono-cœur dans un contexte de tâches préemptives, une attention particulière est nécessaire lorsqu’une donnée variable est consommée par une tâche consommatrice extérieure à la tâche productrice et ayant une priorité supérieure ou égale à celle de ladite tâche productrice. Une telle donnée variable, dans le programme logiciel préexistant, peut ne pas avoir été identifiée comme devant être protégée du point de vue de la stabilité, même si ce besoin existe. De même, si le nouveau programme logiciel change les ordres de priorité entre les tâches, par exemple, une inconsistance des données peut survenir, alors qu’implicitement la stabilité était assurée par le choix des priorités. Plus généralement, que l’on soit dans un contexte de tâches préemptives ou non, lors de la conception ou de la modification d’un logiciel existant dans un processeur multicoeur, toutes les données produites dans un cœur et consommées deux fois ou plus dans un autre cœur doivent faire l’objet d’une vérification pour savoir si elles ont besoin d’être stables ou non pour leurs différentes fonctions consommatrices. Ce travail peut être très lourd, notamment lorsque l’on récupère, dans une architecture multicoeur, un logiciel préalablement conçu pour une architecture monocoeur.

[0018] Dans ce contexte, la présente invention vise à optimiser la conception d’un programme logiciel de façon à répondre au besoin de stabilité des données variables en minimisant les efforts de développement tout en optimisant l’utilisation des capacités d’un microprocesseur.

[0019] Plus précisément, la présente invention vise un procédé d’assistance à la conception d’un programme logiciel, dans le cadre décrit précédemment, de façon à assurer la stabilité de données variables en mettant en œuvre un mécanisme de protection selon deux approches possibles : une approche systématique et une approche différenciée. L’approche systématique de protection concerne des données qui vont être systématiquement protégées, que le besoin existe ou non d’un point de vue fonctionnel. L’approche différenciée permet de protéger des données pour lesquelles il y a un besoin de protection préalablement identifié par les concepteurs fonctionnels.

[0020] L’approche systématique s’applique avantageusement pour limiter l’effort d’étude sur un périmètre bien précis qui va concerner un nombre limité de données afin de ne pas consommer trop de capacités du microprocesseur. L’approche différenciée demande une recherche exhaustive de tous les besoins, ce qui permet de limiter le recours aux capacités du microprocesseur. La présente invention vise en particulier le cas où un programme ou une partie de programme est destiné à coopérer avec un programme préexistant, avec des tâches exécutées en parallèle, car des problèmes d’instabilité de données variables impliquant le programme préexistant peuvent ne pas avoir été identifiés avant la conception du nouveau programme logiciel.

[0021] Autrement dit, la présente invention vise un procédé de protection en stabilité d’au moins une donnée variable, pour un programme ou une partie de programme comprenant au moins deux tâches mises en oeuvre par un microprocesseur multicoeur, ledit procédé comprenant : la détermination d’au moins une donnée variable à protéger de façon systématique, ladite donnée variable à protéger de façon systématique consistant en une donnée variable produite et consommée, respectivement, par au moins deux tâches, exécutées en parallèle sur deux coeurs distincts du microprocesseur multicoeur, chaque cœur formant une unité de traitement indépendante, lesdites au moins deux tâches présentant chacune une priorité d’exécution et consistant en au moins une tâche productrice de ladite donnée variable à protéger et au moins une tâche consommatrice de ladite donnée variable à protéger, ladite tâche consommatrice présentant une priorité d’exécution supérieure à celle de la tâche productrice, ladite tâche consommatrice réalisant au moins deux accès à la donnée variable à protéger durant l’exécution de ladite tâche consommatrice, par l’intermédiaire de l’exécution successive d’une ou plusieurs fonctions consommatrices, de sorte que ladite donnée variable à protéger soit susceptible d’avoir évolué entre lesdits au moins deux accès, l’implémentation d’une fonction de protection de ladite donnée variable à protéger de façon systématique lors de l’exécution de la tâche consommatrice, de sorte que les deux accès réalisés par la tâche consommatrice consomment une donnée variable à protéger ayant une valeur constante pour l’exécution considérée de la tâche consommatrice.

[0022] Grâce à la présente invention, il est possible de concevoir un partie de programme logiciel destinée à coopérer avec une partie de programme logiciel préexistante, avec des tâches productrices et consommatrices de données variables mises en œuvre par des unités de traitement indépendantes d’un microprocesseur multicoeur, tout en assurant une stabilité desdites données variables, y compris dans les cas où le besoin de stabilité n’a pas pu être identifié préalablement à la conception de la nouvelle partie de programme. Avantageusement, ladite fonction de protection consiste en une fonction de copie locale, dans la tâche consommatrice, de la valeur de ladite donnée variable à protéger au début de l’exécution de ladite tâche consommatrice. La présente invention vaut aussi lorsqu’un programme logiciel mis en œuvre par un microprocesseur monocoeur est migré sur une architecture disposant d’un microprocesseur multicoeur.

[0023] Selon un mode de réalisation, ladite tâche productrice consiste en une tâche périodique.

[0024] Selon un mode de réalisation, ladite tâche consommatrice consiste en une tâche périodique.

[0025] Selon un mode de réalisation, ladite tâche consommatrice est une tâche synchrone destinée à réaliser au moins deux accès successifs à la donnée variable à protéger lors d’une exécution de ladite tâche synchrone.

[0026] Selon un mode de réalisation, le procédé comprend la protection en stabilité d’une variable définie comme étant à protéger de façon différenciée, ladite donnée variable à protéger de façon différenciée étant produite et consommée, respectivement, par au moins deux tâches, exécutées en parallèle sur deux coeurs distincts du microprocesseur multicoeur, lesdites au moins deux tâches présentant une priorité d’exécution quelconque et consistant en au moins une deuxième tâche productrice de ladite donnée variable à protéger et au moins une deuxième tâche deux fois consommatrice de ladite donnée variable à protéger, le procédé comprenant la mise en oeuvre d’une fonction de protection de ladite donnée variable à protéger de façon différenciée, au début de l’exécution de ladite deuxième tâche consommatrice, uniquement si ladite donnée variable est définie comme étant une donnée variable à protéger de façon différenciée.

[0027] Avantageusement, ladite fonction de protection consiste en une fonction de copie locale, dans la deuxième tâche consommatrice, de ladite donnée variable.

[0028] Selon un mode de réalisation, ladite deuxième tâche productrice consiste en une tâche périodique.

[0029] Selon un mode de réalisation, ladite deuxième tâche consommatrice consiste en une tâche périodique.

[0030] Selon un mode de réalisation, ladite deuxième tâche consommatrice est une tâche synchrone destinée à réaliser au moins deux accès successifs à la donnée variable à protéger lors d’une exécution de ladite tâche synchrone.

[0031] D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description détaillée des modes de réalisation de l'invention, donnés à titre d'exemple uniquement, et en référence aux dessins qui montrent : • la figure 1, un schéma d’un microprocesseur monocoeur, • la figure 2, un schéma d’un exemple d’architecture de microprocesseur multicoeur, • la figure 3, un schéma mettant en évidence un exemple de donnée variable à protéger dans un contexte multicoeur avec un ordonnancement préemptif, • la figure 4, un schéma montrant un exemple de mise en oeuvre d’une fonction élémentaire de protection d’une donnée variable à protéger.

[0032] Dans ce qui va suivre, les modes de réalisation décrits s’attachent plus particulièrement à une mise en oeuvre du processeur selon l’invention au sein d’un véhicule automobile. Cependant, toute mise en oeuvre dans un contexte différent, en particulier dans tout type de véhicule, est également visée par la présente invention.

[0033] Un véhicule automobile (non représenté) comprend un châssis reposant sur une voie de circulation par des roues. Afin de permettre le déplacement du véhicule sur la voie de circulation, le véhicule comprend en outre un groupe motopropulseur adapté pour entraîner, au moins une partie des roues en rotation.

[0034] Le groupe motopropulseur (non représenté) comprend au moins un moteur à combustion interne et/ou un système de motorisation électrique.

[0035] Afin notamment de contrôler et de commander le fonctionnement d’un moteur à combustion et d’un moteur électrique, le véhicule comprend en outre au moins un calculateur de contrôle. De façon générale, un calculateur de contrôle permet l’exécution de différents logiciels de fonctions de contrôle et de commande des différents éléments organiques du véhicule, tels que les moteurs du groupe de propulsion, la boîte de vitesse, etc.

[0036] Le calculateur de contrôle comprend en l’espèce un processeur multicoeur 1 comme illustré sur la figure 2, comprenant une pluralité de coeurs, notamment deux, trois, quatre, cinq coeurs, etc.

[0037] Le processeur multicoeur 1 comprend deux partitions 10, 20, dont une première partition 10 de contrôle d’un premier groupe de tâches et une deuxième partition 20 de contrôle d’un deuxième groupe de tâches.

[0038] Chaque partition 10, 20 comprend au moins un cœur 11, 12, 21. Dans l’exemple illustré sur la figure 2, la première partition 10 comprend 2 cœurs 11, 12 et la deuxième partition 20 comprend un cœur 21. Cependant, il va de soi que le nombre de cœur par partition 10, 20 pourrait être différent.

[0039] Chaque partition 10, 20 comprend en outre un espace de stockage 13, 23 propre à chaque partition 10, 20.

[0040] Ainsi, un logiciel utilisant le cœur 21 de la deuxième partition 20 sera stocké dans l’espace de stockage 23 de la deuxième partition 20. Ceci permet de mettre à jour séparément les logiciels utilisant la première partition 10 des logiciels utilisant la deuxième partition 20.

[0041] Il faut noter par ailleurs que les tâches appartenant au premier groupe ou au deuxième groupe (il peut bien entendu y avoir davantage de groupes de tâches) peuvent présenter chacune une priorité d’exécution. Néanmoins, la présente invention s’applique que l’on réalise une protection selon une approche systématique ou différenciée, et quel que soit le type d’ordonnancement des tâches déterminé par un séquenceur ou par l’utilisation d’un moniteur de tâches ou d’autres méthodes, et s’applique en particulier dans le contexte d’un « ordonnancement de type préemptif », les ordonnancements permettant aux tâches principales, ayant trait par exemple à la sécurité ou au contrôle moteur dans un véhicule automobile, d’avoir la priorité d’accès aux données et aux ressources matérielles lorsque plusieurs tâches sont supposées être exécutées simultanément. L’utilisation d’un microprocesseur multicoeur permet de résoudre a priori des conflits en termes d’accès aux ressources matérielles mais, comme expliqué précédemment, l’accès aux données variables peut rester conflictuel.

[0042] Une tâche ayant une priorité supérieure aura ainsi accès aux données en priorité par rapport à une tâche présentant tune priorité inférieure.

[0043] Lorsque plusieurs logiciels cohabitent sur un calculateur, que plusieurs tâches sont exécutées en parallèle sur un microprocesseur multicoeur, avec un ordonnancement préemptif régissant les priorités respectives des différentes tâches, des interruptions des tâches surviennent, les unes avec les autres, à des moments variables continûment et aléatoirement dans le temps.

[0044] Parmi les groupes de tâches précités, dans le cadre, notamment, d’une mise en œuvre dans un véhicule automobile, on distingue les tâches périodiques des tâches synchrones, ces dernières ayant trait, en particulier, au contrôle moteur. D’autre part, les tâches périodiques peuvent présenter des périodes d’exécutions supérieures à 10 ms ou inférieures à 5 ms, par exemple. Enfin, on distingue, s’agissant des données variables, et plus particulièrement des données variables à protéger parce que leur consistance doit être assurée, les tâches productrices de ces données variables et les tâches qui en sont consommatrices.

[0045] Dans la suite, on considère par ailleurs que les tâches périodiques ayant une période courte, typiquement inférieure à 5 ms, ont une priorité supérieure aux tâches périodiques ayant une période plus longue, typiquement supérieure à 10 ms, et que les tâches synchrones ayant trait au contrôle moteur ont toujours une priorité plus élevée que n’importe quelle tâche périodique.

[0046] En particulier, dans le contexte où des groupes de tâches sont parallélisées sur différents coeurs d’un microprocesseur multicoeur, comme illustré à la figure 2, un premier groupe de tâches peut être composé des tâches périodiques de période inférieure ou égale à 5 ms, un deuxième groupe de tâches peut être composé de tâches périodiques de période supérieure ou égale à 10 ms et un troisième groupe de tâches peut être composé de tâches synchrones ayant trait au contrôle moteur.

[0047] Selon un mode de réalisation, pour identifier les données variables à protéger, la présente invention propose de mettre en exergue, d’une part, les données variables produites par des tâches consommatrices, périodiques de période supérieure ou égale à 10 ms par exemple, consommées plusieurs fois au sein de tâches consommatrices périodiques. D’autre part, selon ce mode de réalisation, il s’agit d’identifier les données produites par les tâches productrices, périodiques de période inférieure ou égale à 5 ms par exemple, consommées plusieurs fois au sein d’une tâche consommatrice synchrone ayant trait au contrôle moteur.

[0048] Selon un mode de réalisation, s’agissant des données variables consommées par des tâches consommatrices synchrones ayant trait au contrôle moteur, il est prévu que ces données variables soient toutes identifiées comme étant à protéger dans la mesure où 11 peut être très difficile de prédire si une tâche consommatrice synchrone ayant trait au contrôle moteur accédera plusieurs fois, ou non, à une donnée variable, sur une durée inférieure ou non à la période de la tâche productrice de ladite donnée variable.

[0049] Dès lors, selon l’invention, le procédé de conception d’un programme logiciel, selon l’invention, permet de limiter la quantité de travail à fournir pour identifier les besoins de stabilité de données variables en limitant l’examen à une liste de données variables produites par des tâches périodiques consommées plusieurs fois par période par des tâches présentant une priorité plus élevée.

[0050] En effet, dans le cas où les tâches productrices ont une priorité supérieure à celle des tâches consommatrices, la nécessité de prévoir une protection des données variables est obligatoirement anticipée, indépendamment du présent procédé.

[0051] Selon un mode de réalisation, lorsqu’il n’est pas possible de s’assurer qu’une donnée variable doit être protégée en réalisant l’analyse ci-dessus, celle-ci sera considérée comme devant être protégée.

[0052] La présente invention vise donc à permettre d’assurer la stabilité des données variables à protéger dans un programme logiciel, dans le contexte d’une mise en oeuvre de tâches parallèles par un microprocesseur multicoeur, comme décrit précédemment.

[0053] En identifiant les données variables à protéger au moyen d’une analyse optimisée, comme expliqué précédemment, afin de réduire la charge de travail nécessaire en phase de conception du programme logiciel, la présente invention permet la mise en oeuvre d'une fonction de protection systématique uniquement pour lesdites données variables à protéger.

[0054] La figure 2 permet d’illustrer un cas dans lequel une donnée variable est identifiée comme étant à protéger. Sur la figure 2, l’écoulement temporel t se produit du haut vers le bas. Le microprocesseur P comporte deux coeurs 1, 2, également désignés unités de traitement.

[0055] Dans l’unité de traitement 1, la tâche productrice A est exécutée plusieurs fois en A. 0, A.1 et A.2, respectivement aux instants tO, t1 et t2. La tâche productrice A produit une donnée D1 mise à jour régulièrement à chaque exécution de la tâche productrice A, soit aux instants tO, t1, t2, etc.

[0056] Dans l’unité de traitement 2, la tâche consommatrice B est exécutée une fois en B. 1 et comporte deux fonctions F1 et F2 qui consomme deux fois la donnée D1 aux instants t1 ’ et t2’, respectivement intercalés entre les instants t1 et t2 d’une part, et après t2 d’autre part. La tâche consommatrice B présente une priorité supérieure à celle de la tâche productrice A, de sorte que, dans un contexte mono-cœur, la tâche A était bloquée et la donnée D1 était stable pour la tâche B. Dans un contexte multicoeur, en référence à la figure 3, les tâches A et B sont exécutées simultanément en parallèle sur deux coeurs différents. Ainsi, les fonctions F1 et F2 de la tâche consommatrice B, qui consomment la donnée D1, ne voient pas la même valeur de ladite donnée variable D1 au sein d’une seule et même exécution de la tâche consommatrice B : la donnée variable D1 n’est par conséquent pas stable.

[0057] En cas de nécessité, la présente invention prévoit la mise en oeuvre d’une fonction de protection de la donnée variable à protéger. La figure 3 et la description ci-après illustre un exemple de réalisation non limitatif d’une telle fonction de protection.

[0058] La figure 3 montre ainsi la présence d’une fonction élémentaire de protection FO exécutée au début de chaque exécution de la tâche consommatrice B.

[0059] Selon un mode de réalisation, la fonction élémentaire de protection F0, exécutée en début de tâche consommatrice B, réalise une copie locale au sein de ladite tâche consommatrice B de la donnée variable D1 à protéger, et plus généralement de toutes les données variables à protéger consommées par une ou plusieurs fonctions de ladite tâche consommatrice B. La ou les fonctions consommatrices de la donnée variable D1, au sien de la tâche consommatrice B, utilise alors la copie locale réalisée par la fonction élémentaire de protection F0, de sorte que ladite donnée variable à protéger, du point de vue de la tâche consommatrice B, présente bien une valeur stable.

[0060] Un avantage de cette méthode de protection proposée réside dans le fait qu’il est généralement possible de ne pas renommer la donnée D1 dans la tâche consommatrice B, ce qui permet de ne pas avoir à retoucher le code éventuellement préexistant des fonctions F1 et F2. La seule opération à réaliser consiste à renseigner les nouvelles connexions entre les fonctions F1, F2 et les tâches productrices A et consommatrice B, au moyen d’un fichier de liens, indépendamment du code de chaque fonction F1, F2. Lorsque l’architecture logicielle ou les outils imposent de renommer la donnée D1, le procédé selon l’invention reste valable, mais nécessite de modifier toutes les fonctions consommatrices de la donnée D1 pour y indiquer le nouveau nom remplaçant D1.

[0061] De préférence, ladite fonction élémentaire de protection F0 est implémentée de façon à être conforme à la norme Autosar au moyen d’un composant de protection appartenant à une tâche synchrone ayant trait au contrôle moteur, par définition prioritaire devant toute tâche périodique, de sorte que ladite fonction élémentaire de protection F0 soit appelée avant toute autre fonction de la tâche consommatrice B.

[0062] Avantageusement, grâce à l’analyse ciblée préalablement décrite, ayant permis l’identification d’un nombre limité de données variables à protéger, la présente invention n’implique qu’un minimum d’augmentation des ressources matérielles consommées.

Claims

Revendications :

1. Procédé de protection en stabilité d’au moins une donnée variable (D1), pour un programme ou une partie de programme comprenant au moins deux tâches mises en oeuvre par un microprocesseur multicoeur, ledit procédé comprenant : la détermination d’au moins une donnée variable (D1) à protéger de façon systématique, ladite donnée variable à protéger (D1) de façon systématique consistant en une donnée variable produite et consommée, respectivement, par au moins deux tâches, exécutées en parallèle sur deux coeurs distincts du microprocesseur multicoeur, chaque cœur formant une unité de traitement indépendante, lesdites au moins deux tâches présentant chacune une priorité d’exécution et consistant en au moins une tâche productrice (A) de ladite donnée variable à protéger (D1) et au moins une tâche consommatrice (B) de ladite donnée variable à protéger (D1), ladite tâche consommatrice (B) présentant une priorité d’exécution supérieure à celle de la tâche productrice (A), ladite tâche consommatrice (B) réalisant au moins deux accès à la donnée variable à protéger (D1) durant l’exécution de ladite tâche consommatrice (B), par l’intermédiaire de l’exécution successive d’une ou plusieurs fonctions consommatrices (F1, F2), de sorte que ladite donnée variable à protéger (D1) soit susceptible d’avoir évolué entre lesdits au moins deux accès, l’implémentation d’une fonction de protection (FO) de ladite donnée variable à protéger de façon systématique lors de l’exécution de la tâche consommatrice (B), de sorte que les deux accès réalisés par la tâche consommatrice (B) consomment une donnée variable à protéger (D1) ayant une valeur constante pour l’exécution considérée de la tâche consommatrice (B).
2. Procédé selon la revendication 1, dans lequel ladite fonction de protection (FO) consiste en une fonction de copie locale (FO), dans la tâche consommatrice (B), de la valeur de ladite donnée variable à protéger (D1) au début de l’exécution de ladite tâche consommatrice (B).
3. Procédé selon l’une des revendications précédentes, dans lequel ladite tâche productrice (A) consiste en une tâche périodique.
4. Procédé selon l’une des revendications précédentes, dans lequel ladite tâche consommatrice (B) consiste en une tâche périodique.
5. Procédé selon l’une des revendications 1 à 3, dans lequel ladite tâche consommatrice (B) est une tâche synchrone destinée à réaliser au moins deux accès successifs à la donnée variable à protéger (D1) lors d’une exécution de ladite tâche synchrone (B).
6. Procédé selon l’une des revendications précédentes, comprenant la protection en stabilité d’au moins une donnée variable (D1) définie comme étant à protéger de façon différenciée, ladite donnée variable (D1) à protéger de façon différenciée étant produite et consommée, respectivement, par au moins deux tâches, exécutées en parallèle sur deux coeurs distincts du microprocesseur multicoeur, lesdites au moins deux tâches présentant une priorité d’exécution quelconque et consistant en au moins une deuxième tâche productrice de ladite donnée variable à protéger (D1) et au moins une deuxième tâche deux fois consommatrice de ladite donnée variable à protéger (D1), le procédé comprenant la mise en oeuvre d’une fonction de protection (FO) de ladite donnée variable à protéger de façon différenciée, au début de l’exécution de ladite deuxième tâche consommatrice, uniquement si ladite donnée variable (D1) est définie comme étant une donnée variable à protéger de façon différenciée.
7. Procédé selon la revendication précédente, dans lequel ladite fonction de protection consiste en une fonction de copie locale (FO), dans la deuxième tâche consommatrice, de ladite donnée variable.
8. Procédé selon l’une des revendications 6 à 7, dans lequel ladite deuxième tâche productrice consiste en une tâche périodique.
9. Procédé selon l’une des revendications 6 à 8, dans lequel ladite deuxième tâche consommatrice consiste en une tâche périodique.
10. Procédé selon l’une des revendications 6 à 8, dans lequel ladite deuxième tâche consommatrice est une tâche synchrone destinée à réaliser au moins deux accès successifs à la donnée variable à protéger (D1) lors d’une exécution de ladite tâche synchrone.