WO2019058042A1 - Procede pour assurer la stabilite des donnees d'un processeur multicoeur d'un vehicule automobile - Google Patents

Procede pour assurer la stabilite des donnees d'un processeur multicoeur d'un vehicule automobile Download PDF

Info

Publication number
WO2019058042A1
WO2019058042A1 PCT/FR2018/052147 FR2018052147W WO2019058042A1 WO 2019058042 A1 WO2019058042 A1 WO 2019058042A1 FR 2018052147 W FR2018052147 W FR 2018052147W WO 2019058042 A1 WO2019058042 A1 WO 2019058042A1
Authority
WO
WIPO (PCT)
Prior art keywords
task
protected
variable data
variable
consuming
Prior art date
Application number
PCT/FR2018/052147
Other languages
English (en)
Inventor
Bernard Bavoux
Thierry TOUZEAU
Original Assignee
Psa Automobiles Sa
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Psa Automobiles Sa filed Critical Psa Automobiles Sa
Priority to CN201880061027.8A priority Critical patent/CN111108471A/zh
Priority to EP18778959.9A priority patent/EP3685256A1/fr
Publication of WO2019058042A1 publication Critical patent/WO2019058042A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/526—Mutual exclusion algorithms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/31—Programming languages or programming paradigms
    • G06F8/313—Logic programming, e.g. PROLOG programming language

Definitions

  • the invention relates, in general, calculator processors, in particular mounted within motor vehicles.
  • the invention relates more specifically to the management of the data stability of a multicore processor, in particular integrated in a motor vehicle, by means of a method for assisting the design of a software program.
  • a motor vehicle comprises different computers adapted to support functions receiving sensor data and / or controlling different organic elements of the vehicle.
  • a calculator comprises at least one processor comprising at least one processing unit, also designated "heart".
  • a processor comprising a single processing unit is referred to as a “single-core processor”.
  • a heart makes it possible to implement functions that process the data received from sensors and generate instructions to actuators. The power of such a heart depends greatly on its frequency of operation given in Hz. Also, the power of a single-core processor is limited by the maximum frequency of the heart.
  • the present invention finds a particular but nonlimiting application in the field of motor vehicles comprising computers having a so-called "open" system architecture, that is to say in it is possible to reuse functionalities according to a standard interface or in a so-called adaptable version of the system to which it is therefore possible to add or remove new functionalities during execution.
  • Such an open system architecture may be an architecture according to the Autosar standard for a system designed to be integrated with a motor vehicle, the term Autosar being a contraction of the English name "AUTomotive Open System Architecture", as this is known to those skilled in the art.
  • microprocessors 100 comprising several cores 101, 102, 103, including three cores as shown in Figure 1.
  • Such a processor 100 is then designated "multicore processor". This makes it possible to increase the computing power of the microprocessor 100 by means of several cores 101, 102, 103 each having a frequency, for example equal to the heart frequency of a single-core processor. This thus makes it possible to increase the power of the processor.
  • Such a processor 100 also includes a memory 104.
  • the processing operations that are distributed over its different processing units must be able to run in parallel and, as a result, these processes must not have precedence relationships between each other.
  • this document FR 3043808 proposes a partitioning of the functional tasks implemented by a multicore microprocessor configured so that said tasks are differentiated between a first group of periodic tasks and a second group of synchronous tasks, each task group being executed by at least one core of the microprocessor dedicated to it.
  • the present invention relates to a protection device for ensuring the stability of a data, in addition to the method described in document FR 3043808. However, not all functions need the data they share to be stable.
  • the present invention proposes a protection method to ensure the stability of at least one datum in a systematic way in the event of lack of knowledge of the stability requirements for this datum or, according to one embodiment, on a case-by-case basis when a need for stability is identified by the designer of functions that use this data multiple times.
  • the combustion mode of a heat engine is a variable updated by an engine management function implemented as all the management tasks in a periodic task, for example having a period of 10 ms.
  • the variable "engine combustion mode" is consumed by various elementary injection functions, namely pre-combustion injections and injections during combustion and post-combustion injections, which are implemented in a synchronous task of combustion.
  • the synchronous task has priority over the periodic task period 10 ms because its period is greater than 10 ms at the highest engine speeds.
  • this synchronous task is generally preemptive so as to ensure its processing without delay.
  • the inputs of the synchronous task of the combustion are always stable because the synchronous task performs all the basic functions of injections without being interrupted.
  • the variable "motor combustion mode" may change during the execution of the synchronous task, which potentially causes a malfunction in the synchronous task. absence of a protection device ensuring the stability of this data.
  • variable data that had a stable value during the duration of a task in a single-core software architecture does not necessarily have a stable value in another multicore software architecture.
  • this has no consequence because there is no functional need for stability of the variable data.
  • this can cause a malfunction during a change of software architecture.
  • variable data may not have been identified as being to be protected for stability, while it was or becomes so because of the new architecture or the arrival of the new software program part.
  • variable data stability problem may arise when variable data is consumed by a consuming task external to the producing task and having a priority higher than that of said producing task. It should be noted, in fact, that when a production task takes precedence over a consuming task, the question of the protection of variable data is necessarily already taken into account in the previous conception of a mono-architecture. heart.
  • variable data when designing a new multicore architecture from a single-core architecture in a context of preemptive tasks, particular attention is required when variable data is consumed by a consumer task external to the producing task and having a priority greater than or equal to that of said producing task.
  • Such variable data in the pre-existing software program, may not have been identified as having to be protected from the point of view of stability, even if this need exists.
  • the new software program changes the order of priority between tasks, for example, a data inconsistency may occur, whereas stability was implicitly ensured by the choice of priorities.
  • the present invention aims to optimize the design of a software program to meet the need for stability of variable data by minimizing development efforts while optimizing the use of the capabilities of a microprocessor.
  • the present invention aims a method for assisting the design of a software program, in the context described above, so as to ensure the stability of variable data by implementing a protection mechanism according to two approaches possible: a systematic approach and a differentiated approach.
  • the systematic approach to protection concerns data that will be systematically protected, whether the need exists or not from a functional point of view.
  • the differentiated approach makes it possible to protect data for which there is a need for protection previously identified by the functional designers.
  • the systematic approach is advantageously applied to limit the study effort on a specific perimeter which will involve a limited number of data so as not to consume too much capacity of the microprocessor.
  • the differentiated approach requires an exhaustive search of all needs, which limits the use of microprocessor capabilities.
  • the present invention is particularly concerned with the case where a program or part of a program is intended to cooperate with a pre-existing program, with tasks executed in parallel, since problems of instability of variable data involving the pre-existing program may not have been identified before the design of the new software program.
  • the present invention aims at a method of stability protection of at least one variable datum, for a program or part of a program comprising at least two tasks implemented by a multicore microprocessor, said method comprising: the determination of at least one variable datum to be protected systematically, said variable datum to be systematically protected consisting of a variable datum produced and consumed, respectively, by at least two tasks, executed in parallel on two different cores of the multicore microprocessor each core forming an independent processing unit, said at least two tasks each having a priority of execution and consisting of at least one task producing said variable data to be protected and at least one consuming task of said variable data to be protected, said a consuming task having an execution priority higher than that of the producing task, said consuming task realizing at least two accesses to the variable data to be protected during the execution of said consuming task, via the successive execution of one or more consuming functions, of rte said variable data to be protected is likely to have evolved between said at least two accesses, the implementation of a protection function
  • said protection function consists of a local copy function, in the consuming task, of the value of said variable data item to be protected at the beginning of the execution of said consuming task.
  • said producer task consists of a periodic task.
  • said consuming task consists of a periodic task.
  • said consuming task is a synchronous task intended to achieve at least two successive accesses to the variable data to be protected during an execution of said synchronous task.
  • the method comprises the protection in stability of a variable defined as being to be protected in a differentiated manner, said variable variable to be protected differentially being produced and consumed, respectively, by at least two tasks, performed in parallel on two different cores of the multicore microprocessor, said at least two tasks having any execution priority and consisting of at least a second task producing said variable data to protect and at least a second task twice consuming said data variable to be protected, the method comprising the implementation of a protection function of said variable data to be protected in a differentiated manner, at the beginning of the execution of said second consuming task, only if said variable data item is defined as data variable to be protected in a differentiated way.
  • said protection function consists of a local copy function, in the second consuming task, of said variable data item.
  • said second producing task consists of a periodic task.
  • said second consuming task consists of a periodic task.
  • said second consuming task is a synchronous task intended to achieve at least two successive accesses to the variable data to be protected during an execution of said synchronous task.
  • FIG. 1 a diagram of a single-chip microprocessor
  • FIG. 2 a diagram of an exemplary multi-core microprocessor architecture
  • FIG. 3 a diagram highlighting an example of variable data to be protected in a multicore context with preemptive scheduling
  • FIG. 4 a diagram showing an exemplary implementation of a basic function for protecting a variable data item to be protected.
  • the described embodiments focus more particularly on an implementation of the processor according to the invention within a motor vehicle.
  • any implementation in a different context, in particular in any type of vehicle, is also covered by the present invention.
  • a motor vehicle (not shown) comprises a chassis resting on a taxiway by wheels. To allow the movement of the vehicle on the driving lane, the vehicle further comprises a powertrain adapted to drive at least a portion of the wheels in rotation.
  • the powertrain (not shown) comprises at least one internal combustion engine and / or an electric drive system.
  • the vehicle further comprises at least one control computer.
  • a control computer allows the execution of various software functions control and control of the various organic elements of the vehicle, such as propulsion group engines, the gearbox, etc..
  • the control computer comprises in this case a multicore processor 1 as shown in Figure 2, comprising a plurality of cores, including two, three, four, five cores, etc..
  • Multicore processor 1 comprises two partitions 10, 20, including a first control partition 10 of a first group of tasks and a second control partition 20 of a second group of tasks.
  • Each partition 10, 20 comprises at least one core 1 1, 12, 21.
  • the first partition 10 comprises 2 cores 11, 12 and the second partition 20 comprises a core 21.
  • the number of cores per partition 10, 20 could be different.
  • Each partition 10, 20 further comprises a storage space 13, 23 specific to each partition 10, 20.
  • a software using the heart 21 of the second partition 20 will be stored in the storage space 23 of the second partition 20. This allows to update separately the software using the first partition 10 software using the second score 20.
  • the tasks belonging to the first group or the second group may each have a priority of execution.
  • the present invention applies whether protection is provided according to a systematic or differentiated approach and regardless of the type of task scheduling determined by a sequencer or by the use of a task monitor or a task monitor. other methods, and applies in particular in the context of a "preemptive type scheduling", the scheduling allowing the main tasks, for example relating to safety or engine control in a motor vehicle, to have the Access priority to data and hardware resources when multiple tasks are supposed to be executed simultaneously.
  • a task having a higher priority will thus have priority access to the data with respect to a task having a lower priority.
  • periodic tasks synchronous tasks the latter relating, in particular, to the engine control.
  • periodic tasks may have execution periods greater than 10 ms or less than 5 ms, for example.
  • periodic tasks having a short period typically less than 5 ms
  • periodic tasks having a longer period typically greater than 10 ms
  • synchronous tasks relating to motor control always have a higher priority than any periodic task.
  • a first group of tasks may be composed of periodic tasks having a period of less than or equal to 5 ms
  • a second group of tasks may consist of periodic tasks with a period greater than or equal to 10 ms
  • a third group of tasks may be composed of synchronous tasks relating to the motor control.
  • the present invention proposes to highlight, on the one hand, the variable data produced by consuming tasks, periodic of period greater than or equal to 10 ms per example, consumed several times in periodic consumer tasks.
  • the periodic generating tasks of period less than or equal to 5 ms, for example, consumed several times within a synchronous consuming task having relating to engine control.
  • variable data consumed by synchronous consuming tasks relating to the motor control it is expected that these variable data are all identified as being to be protected to the extent that it can be very difficult. predicting whether or not a synchronous consuming task relating to the motor control will access variable data more or less over a period of time less than the period of the task generating said variable data item.
  • the method for designing a software program makes it possible to limit the amount of work to be performed to identify the requirements for variable data stability by limiting the examination to a list of variable data produced by periodic tasks consumed several times per period by tasks with a higher priority. Indeed, in the case where the producing tasks have a higher priority than the consuming tasks, the need to provide protection of the variable data is necessarily anticipated, regardless of the present method.
  • variable data when it is not possible to ensure that variable data must be protected by carrying out the analysis above, it will be considered to be protected.
  • the present invention therefore aims to ensure the stability of the variable data to be protected in a software program, in the context of implementation of parallel tasks by a multicore microprocessor, as described above.
  • the present invention makes it possible to implement a function systematic protection only for said variable data to be protected.
  • FIG. 2 illustrates a case in which variable data is identified as being to be protected.
  • the microprocessor P comprises two cores 1, 2, also called processing units.
  • the producing task A is executed several times in the processing unit 1, the producing task A is executed several times in the processing unit 1, the producing task A is executed several times in the processing unit 1, the producing task A is executed several times in the processing unit 1, the producing task A is executed several times in the processing unit 1, the producing task A is executed several times in the processing unit 1, the producing task A is executed several times in the processing unit 1, the producing task A is executed several times in the processing unit 1, the producing task A is executed several times in
  • the producing task A produces a data item D1 updated regularly each time the production task A is executed, ie at the times t0, t1, t2, etc.
  • the consuming task B is executed once in
  • the consuming task B has a higher priority than the producing task A, so that, in a single-core context, the task A was blocked and the data D1 was stable for the task B.
  • tasks A and B are performed simultaneously in parallel on two different cores.
  • the functions F1 and F2 of the consuming task B, which consume the data D1 do not see the same value of said variable data D1 within one and the same execution of the consuming task B: the variable data D1 is therefore not stable.
  • FIG. 3 and the description below illustrate a non-limiting exemplary embodiment of such a protection function.
  • FIG. 3 thus shows the presence of an elementary protection function F0 executed at the beginning of each execution of the consuming task B.
  • the elementary protection function F0 executed at the beginning of the consuming task B, performs a local copy within said consuming task B of the variable data D1 to be protected, and more generally of all the data. variables to be protected consumed by one or more functions of said consuming task B.
  • the consuming function or functions of the variable data D1 in the same way as the consuming task B, then uses the local copy produced by the elementary protection function F0, so that said variable data to protect, from the point of view of the consuming task B, has a stable value.
  • An advantage of this proposed protection method lies in the fact that it is generally possible not to rename the data D1 in the consumer task B, which makes it possible to avoid having to retouch the possibly existing code of the functions F1. and F2.
  • the only operation to be performed consists in informing the new connections between the functions F1, F2 and the producing tasks A and consumer B, by means of a link file, independently of the code of each function F1, F2.
  • the method according to the invention remains valid, but requires modifying all the consuming functions of the data D1 to indicate the new name replacing D1.
  • said elementary protection function F0 is implemented so as to comply with the Autosar standard by means of a protection component belonging to a synchronous task relating to the motor control, by priority definition before any periodic task, so that said elementary protection function F0 is called before any other function of the consuming task B.
  • the present invention involves only a minimum increase in material resources consumed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Microcomputers (AREA)
  • Debugging And Monitoring (AREA)

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 (F0) 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 mono-cœ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. [001 1 ] 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 mono- cœ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 cœurs 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 œuvre 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 cœurs 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 cœurs 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 œuvre 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 œuvre 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 œuvre du processeur selon l'invention au sein d'un véhicule automobile. Cependant, toute mise en œuvre 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 multicœur 1 comme illustré sur la figure 2, comprenant une pluralité de cœurs, notamment deux, trois, quatre, cinq cœurs, etc.
[0037] Le processeur multicœur 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 1 1 , 12, 21 . Dans l'exemple illustré sur la figure 2, la première partition 10 comprend 2 cœurs 1 1 , 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 cœurs 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ù il 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 œuvre 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 œuvre 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 cœurs 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 cœurs 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 œuvre 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 F0 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 œuvre 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 cœurs 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 cœurs 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 œuvre d'une fonction de protection (F0) 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 (F0), 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.
PCT/FR2018/052147 2017-09-19 2018-09-03 Procede pour assurer la stabilite des donnees d'un processeur multicoeur d'un vehicule automobile WO2019058042A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201880061027.8A CN111108471A (zh) 2017-09-19 2018-09-03 用于确保机动车辆的多核处理器的数据的稳定性的方法
EP18778959.9A EP3685256A1 (fr) 2017-09-19 2018-09-03 Procede pour assurer la stabilite des donnees d'un processeur multicoeur d'un vehicule automobile

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1758645A FR3071334B1 (fr) 2017-09-19 2017-09-19 Procede pour assurer la stabilite des donnees d’un processeur multicoeur d’un vehicule automobile
FR1758645 2017-09-19

Publications (1)

Publication Number Publication Date
WO2019058042A1 true WO2019058042A1 (fr) 2019-03-28

Family

ID=60182770

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2018/052147 WO2019058042A1 (fr) 2017-09-19 2018-09-03 Procede pour assurer la stabilite des donnees d'un processeur multicoeur d'un vehicule automobile

Country Status (5)

Country Link
EP (1) EP3685256A1 (fr)
CN (1) CN111108471A (fr)
FR (1) FR3071334B1 (fr)
MA (1) MA50262A (fr)
WO (1) WO2019058042A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3101460B1 (fr) * 2019-09-27 2021-09-03 Continental Automotive Procédé et calculateur de gestion d’échanges de données entre une pluralité de tâches

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090049437A1 (en) * 2004-04-07 2009-02-19 Udo Woersching Method for configuring a computer program
FR3043808A1 (fr) 2015-11-12 2017-05-19 Peugeot Citroen Automobiles Sa Procede de controle commande de taches fonctionnelles par un microprocesseur multicoeurs

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10056046A1 (de) * 2000-11-11 2002-05-23 Bosch Gmbh Robert Verfahren zur Realisierung einer Intertask-Kommunikation in einem Multitasking-Betriebssystem
JP5516744B2 (ja) * 2010-08-27 2014-06-11 富士通株式会社 スケジューラ、マルチコアプロセッサシステムおよびスケジューリング方法
DE102013202774A1 (de) * 2013-02-20 2014-08-21 Robert Bosch Gmbh Vorrichtung, Verfahren und System zum Steuern eines Prozessors
EP3080668B1 (fr) * 2013-12-09 2017-06-14 dSPACE digital signal processing and control engineering GmbH Procédé destiné à influencer un programme de commande d'un appareil de commande
DE102014103139B4 (de) * 2014-03-10 2017-08-10 Denso Automotive Deutschland Gmbh Parallelisierte Ausführung von Single-Core Steuerungssoftware auf Multi-Core Fahrzeugsteuergeräten
DE102014019531A1 (de) * 2014-12-23 2016-06-23 Liebherr-Aerospace Lindenberg Gmbh Verfahren zum Betrieb einer Steuerungskomponente für ein Luftfahrzeug sowie Steuerungskomponente

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090049437A1 (en) * 2004-04-07 2009-02-19 Udo Woersching Method for configuring a computer program
FR3043808A1 (fr) 2015-11-12 2017-05-19 Peugeot Citroen Automobiles Sa Procede de controle commande de taches fonctionnelles par un microprocesseur multicoeurs

Also Published As

Publication number Publication date
CN111108471A (zh) 2020-05-05
FR3071334B1 (fr) 2019-08-30
EP3685256A1 (fr) 2020-07-29
MA50262A (fr) 2020-07-29
FR3071334A1 (fr) 2019-03-22

Similar Documents

Publication Publication Date Title
EP3238056B1 (fr) Methode d'ordonnancement de taches au niveau des noeuds d'un cluster informatique, ordonnanceur de taches et cluster associes
EP2987081B1 (fr) Procédé d'allocation temporelle de tâches permettant une récupération d'erreur deterministe en temps réel
FR2771193A1 (fr) Appareil de commande d'un systeme et procede de mise en oeuvre d'un tel appareil de commande
FR3043808A1 (fr) Procede de controle commande de taches fonctionnelles par un microprocesseur multicoeurs
EP0637798B1 (fr) Procédé d'analyse d'interblocage dans un système d'exploitation
EP3123344B1 (fr) Procede de transfert de donnees entre taches temps reel utilisant un controleur memoire dma
FR2972821A1 (fr) Procede et dispositif d'installation/desinstallation de modules logiciels, avec resolution centralisee de contraintes, dans des equipements d'aeronef
FR3071334B1 (fr) Procede pour assurer la stabilite des donnees d’un processeur multicoeur d’un vehicule automobile
FR3075414B1 (fr) Procede de gestion d'une pluralite de taches par un calculateur automobile multicœur
WO2013171227A1 (fr) Procede de gestion d'une execution de taches dans un systeme informatique
EP2856323B1 (fr) Procédé, dispositif et programme d'ordinateur de contrôle dynamique de distances d'accès mémoire dans un système de type numa
CA2886466A1 (fr) Systeme multicoeur de traitement de donnees a dispositifs d'entree/sortie locaux et globaux et interface graphique comportant un tel systeme de traitement de donnees
EP3663953A1 (fr) Procédé et dispositif de contrôle d'accès à une ressource partagée entre tâches logicielles exécutées dans un contexte applicatif prédéterminé
WO2016034447A1 (fr) Système embarqué mettant en oeuvre des fonctions avioniques critiques
EP2545449B1 (fr) Procédé de configuration d'un système informatique, programme d'ordinateur et système informatique correspondants
FR3053140B1 (fr) Architecture de calcul notamment pour un systeme embarque aeronautique
WO2019145632A1 (fr) Procédé de conception d'une architecture de tâches applicative d'une unité de contrôle électronique avec un ou des coeurs virtuels
WO2021058773A1 (fr) Procédé et calculateur de gestion d'échanges de données entre une pluralité de tâches
WO2010109609A1 (fr) Dispositif de traitement et dispositif de commande de moteur de véhicule
WO2013038112A1 (fr) Procede, dispositif et programme d'ordinateur pour allouer dynamiquement des ressources d'un cluster a l'execution de processus d'une application
EP3131005A1 (fr) Equipement électronique ferroviaire comprenant un programme de démarrage comportant une ou plusieurs partitions de démarrage, véhicule ferroviaire et système ferroviaire associés
EP2572253A1 (fr) Procede d'optimisation de gestion de veille d'un microprocesseur permettant la mise en oeuvre de plusieurs coeurs logiques et programme d'ordinateur mettant en oeuvre un tel procede
FR2658628A1 (fr) Systeme informatique pour gerer l'execution en temps reel de taches selon des priorites et hierarchies predeterminees.
FR2829848A1 (fr) Procede de gestion d'acces a des ressources partagees dans un systeme embarque et systeme embarque pour la mise en oeuvre d'un tel procede
WO2015145035A1 (fr) Procédé et dispositif de contrôle du changement de système d'exploitation dans des nœuds de service d'un calculateur haute performance

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18778959

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018778959

Country of ref document: EP

Effective date: 20200420