EP3374866A1 - Procede de controle commande par un microprocesseur multicoeur - Google Patents

Procede de controle commande par un microprocesseur multicoeur

Info

Publication number
EP3374866A1
EP3374866A1 EP16809965.3A EP16809965A EP3374866A1 EP 3374866 A1 EP3374866 A1 EP 3374866A1 EP 16809965 A EP16809965 A EP 16809965A EP 3374866 A1 EP3374866 A1 EP 3374866A1
Authority
EP
European Patent Office
Prior art keywords
tasks
synchronous
software
periodic
group
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP16809965.3A
Other languages
German (de)
English (en)
Inventor
Bernard Bavoux
Nicolas FRANCOIS
Thierry TOUZEAU
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
PSA Automobiles SA
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
Publication of EP3374866A1 publication Critical patent/EP3374866A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic

Definitions

  • the invention relates to a control method by a multi-core microprocessor, that is to say, several cores also called processing units.
  • the invention is in the field of real-time processing using multi-core processor resources.
  • Such an open system architecture can be an architecture according to the Autosar standard for an open architecture system for automotive also known under the name "AUTOMOTIVE Open System Architecture", without this being an obligation for this invention. .
  • processors with a single processing unit, that is to say a single-core processor. More recently there is the appearance of processors comprising at least two processing units, also called multi-core processors that allow a computing power greater than that of single-core processors, while using an operating frequency equal to that of a single processor. single-core processor.
  • the functional architecture divides the functions into sub-functions according to needs of work distribution or management of the diversity of options.
  • this functional division is at the basis of the software distribution processes on several computing cores.
  • a study of graphs of transitions between the different sub-functions is sometimes used for that.
  • the implementation of functions on two processor units of a multi-core processor is for example performed by an allocation on a core of the application software over an interface of the architecture of the open system and a basic system software allocation on another processor core.
  • the executable entities of the software are grouped into software tasks according to their type of activation. Each software task has executable entities of only one type of activation. These software tasks are thus able to be managed in real time by a task monitor that activates them according to their type of trigger.
  • Multi-core processors may theoretically offer more computing power but they require parallelizing the processing on different cores, while these treatments were until now performed sequentially on a single core.
  • the processing that is distributed over its different processing units must not include precedence relationships. In other words, the processing units must be able to operate in a desynchronised manner, without expecting each other.
  • a module that is to say an atomic component in the sense of Autosar, can not be split on several cores. So all the executable entities of a module must go to the same core or compute unit. This constraint is sometimes also found in software that is not part of an open system architecture because it is simply linked to a design of the software that shares global variables to a function by the different sub-functions.
  • control command loops often include several functions and give rise to executable entities divided into different sub-functions that have the same type of trigger.
  • These executable entities must follow a predefined sequencing order within their software task: they must therefore also be on the same processing unit. It follows that in this conventional design it is necessary to put a large part of the functional system on the same processing unit, which produces a calculation overhead on it while other processing units are underemployed .
  • executable entities of the same type of trigger are nevertheless distributed over different processing units, under the constraint of precedence relations between the processing units to respect the order of execution of these executable entities.
  • the problem underlying the invention is to accelerate the processing of multiple cores of a multicore processor so that these processing can be done in real time without delay.
  • these tasks are grouped into at least one first group of periodic software tasks and a second group of synchronous tasks and in that the group of periodic tasks, on the one hand, and the group of synchronous tasks, on the other hand, are treated by at least one core of the microprocessor specific to them, the tasks neither synchronous nor periodic being processed by said at least one heart of the first group of periodic tasks or at least one core of the second group of synchronous tasks or by at least one other core that specific cores synchronous and periodic tasks by forming at least a third group.
  • Executable entities that have a synchronous engine-type trigger may be grouped into one or more tasks and supported by one or more other specific processor units, i.e. one or more microprocessor cores, other than the processing unit (s) that process the periodic tasks.
  • This distribution of software tasks makes it possible to make the execution of the periodic tasks, which then take place in a stable and deterministic order, much more regular, without being interrupted by synchronous tasks of the engine which are in general priority.
  • the system is thus simpler to validate because the response time margins for the periodic tasks no longer depend on the operating conditions of the organ or organs to be controlled.
  • the operating conditions include the engine speed. At full engine speed, which corresponds to a maximum computing load in the microprocessor of an engine control, the computing load is well distributed between the processing units which are in charge of the synchronous motor tasks and those which have in load periodic tasks.
  • said at least a third group of tasks includes tasks that activate randomly. Given the non-predictive nature of randomly activated tasks, it will also be advantageous to dedicate at least one processing unit or a specific heart. In this way, the periodic or synchronous tasks are not disturbed by randomly activated tasks.
  • the randomly activating tasks comprise tasks activated by undesired interruption of a function controlled and / or controlled by the microprocessor or at least one control and / or control member dedicated to the function and controlled by the microprocessor.
  • Part of the tasks that activate randomly are similar to failures of the organ or organs controlled by the microprocessor.
  • the first group of periodic tasks is split into at least two subgroups corresponding to tasks having different periods, each subgroup being processed by a different heart.
  • a first of the subgroups corresponds to software tasks being performed at periods less than or equal to a first threshold
  • the second of the subgroups corresponds to software tasks being performed at higher periods. at a second threshold, the first threshold being less than or equal to the second threshold.
  • At least one executable entity is specific to at least one respective task of part of the tasks of the first and second groups.
  • the current The invention thus proposes that a software module be decomposed more finely with respect to the current state of the art in order to contain executable entities that only one type of activation.
  • a task monitor is used at least for each task of the first and second groups and is integrated in the heart of the specific microprocessor for said task.
  • At least one of the synchronous tasks is relative to one or more synchronous functions of a motor controlled by a control command by rotating at a variable speed, these functions having a variable execution period depending on the speed of the engine. a given moment.
  • the invention also relates to a multicore processor for a control command, characterized in that it implements such a method.
  • the invention also relates to a control of a motor vehicle, characterized in that it comprises a processor as previously mentioned.
  • FIG. 1 is a schematic representation of an example of multicore processor with n calculation units, this processor being able to implement the method according to the invention
  • FIG. 2 is a schematic representation of an example of functional decomposition in function and sub-functions in a multi-core processor according to the state of the art
  • FIG. 3 is a schematic representation of an exemplary composition of a software with m modules and executable entities in each module in a processor that can allow the implementation of the method according to the invention. It is to be borne in mind that the figures are given by way of examples and are not limiting of the invention. They constitute schematic representations of principle intended to facilitate the understanding of the invention.
  • the invention relates to the organization of the task processing in a processor that implements different processing units, that is to say different cores of a multiple core processor. It proposes to architect the software to be able to distribute it on the various processing units, according to a favorable scenario to maximize the use of the processing units or cores and to obtain optimal response times.
  • a multi-core processor 1 is characterized by the fact that it implements several processing units 1 .1, 1 .2 to 1 .p.
  • a multi-core processor for motor control of a motor vehicle frequently used may comprise three processing units.
  • This example will be used to illustrate the invention, but one could advantageously similarly use a processor with more processing units, such as a processor having six processing units or any other number greater than 3.
  • processing units of a multi-core processor must be able to work independently without expecting each other. For this it is proceeded to put in parallel of the treatments.
  • Figure 1 illustrates an example of a multiple core processor with p computing units as processing units.
  • a functional architecture divides the functions into sub-functions according to needs of distribution of the work of design or management of the diversity of the options.
  • Figure 2 shows an example of functional decomposition in function and sub-functions for a functional architecture that can be at two levels. It is then made a distinction between:
  • FIG. 3 shows an example of a software architecture resulting from a functional design according to the state of the art existing but capable of implementing the method according to the present invention, the architecture comprising m modules and Executable entities in each module.
  • modules in the remainder of the present description in the number of m, 3.1 to 3 m, which correspond to software components in the context of a system architecture, elementary execution entities of the software corresponding to portions of modules which are each activated by a particular mechanism, hereinafter referred to as executable entities in the remainder of the present description, to the number of R1 in the module 3.1 and to the number of Rm in the module 3. m.
  • executable entities in the remainder of the present description, to the number of R1 in the module 3.1 and to the number of Rm in the module 3. m.
  • functional system 2 corresponds to software 3
  • functions 2.x correspond to modules 3.x and to elementary functions 2.x.
  • a software task is a set of executable entities of the same type of trigger.
  • a task monitor has the role of activating the various tasks as they occur.
  • the present invention consists in designing a functional architecture of the software with an additional level of division of functions defined by the separation of executable entities 3.x.y by activation type. Thus, each function has only elementary functions of a type of activation.
  • the invention relates to a control method implementing software tasks by a multi-core microprocessor comprising several cores as processing units working in parallel, these software tasks comprising so-called synchronous software tasks with variable period, so-called periodical software tasks with a fixed period of time, software tasks that are neither synchronous nor periodic.
  • these tasks are grouped into at least one first group of periodic software tasks and a second group of synchronous tasks and the group of periodic tasks, on the one hand, and the group of synchronous tasks, on the other hand, are processed by at least one core of the microprocessor specific to them, that is to say by at least one different heart.
  • Software tasks that are neither synchronous nor periodic are processed by said at least one core of the first group of periodic tasks or at least one core of the second group of synchronous tasks or by at least one other core than the specific cores of the synchronous tasks. and periodicals by forming at least a third group. As will be seen later, this second solution is preferred.
  • An analysis of an engine control software shows that the majority of the computing load is divided between two large groups, namely synchronous tasks and periodic tasks. Synchronous engine tasks have no precedence relationship with periodic tasks at all. They can therefore be put in parallel with the periodic tasks.
  • the synchronous software tasks have priority over the periodic software tasks.
  • periodic software tasks are entrusted to the control-command, as soon as these periodic software tasks have started, they can restore control to the main program without having necessarily completed their execution.
  • Randomly activated tasks may comprise mainly tasks activated by undesired interruption of a function controlled and / or controlled by the microprocessor or at least one control and / or control organ dedicated to the function and controlled by the microprocessor. These interrupts are frequently hardware interrupts. In the engine, these randomly activating software tasks have priority over synchronous software tasks.
  • the present invention allows for example the following distribution which best balances the calculation load between the three hearts:
  • - processing unit for the synchronous tasks of the engine - processing unit for the tasks under material interruption and the periodic fast tasks for example of period less than or equal to 5ms.
  • the first group of periodic tasks can be split into at least two subgroups corresponding to software tasks taking place at different periods, each subgroup being processed by a different core of the microprocessor.
  • the first of the subgroups can thus correspond to software tasks taking place at periods less than or equal to a first threshold Sp1, for example 5 ms while the second subgroup can correspond to software tasks being carried out at periods greater than a second threshold Sp2, for example 10ms, the first threshold Sp1 being less than or equal to the second threshold Sp2.
  • At least one executable entity 3.x.y may be specific to at least one respective software task of a portion of the software tasks of the first and second groups.
  • each software task can have at least one executable entity 3.x.y unless several software tasks are similar.
  • the task monitor previously mentioned in the description of the state of the art, may be, in the context of the invention, specific at least for each software task of the first and second groups and may be integrated in the heart of the microprocessor specific for said task.
  • the invention also relates to a multi-core processor 1 .1, 1 .2 to 1 .p for control control, characterized in that it implements such a method.
  • the invention also relates to a control of a motor vehicle, characterized in that it comprises a processor as previously mentioned.
  • the present invention will now be developed in the context of a control system for a motor vehicle, mainly an engine control that can also control other features present in the motor vehicle. This is a preferred application of the present invention but is not limiting.
  • a very large part of the periodic tasks consists first of all of the software tasks with a period of 10 ms then with those of period of 5 ms. If enough processing units are available, it is advantageous to reserve a processing unit for the majority of the tasks at 10 ms and to put the tasks at 5 ms on another processing unit.
  • the invention relates to a motor vehicle comprising at least one motor and such control control at least in charge of the operation of said at least one engine.
  • the control command can also control a vehicle driving aid, as taken individually or in combination with an anti-lock system for wheels or ABS, a programmed electrostatic or ESP, an automatic gearbox or BVA, a power steering electric, without this being limiting.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Microcomputers (AREA)

Abstract

L'invention porte sur un procédé de contrôle commande mettant en œuvre des tâches logicielles par un microprocesseur multicoeurs en tant qu'unités de traitement travaillant en parallèle, ces tâches logicielles comprenant des tâches synchrones, des tâches périodiques, des tâches ni synchrones, ni périodiques, caractérisé en ce que ces tâches sont regroupées en au moins un premier groupe de tâches logicielles périodiques et un deuxième groupe de tâches synchrones et en ce que le groupe de tâches périodiques, d'une part, et le groupe de tâches synchrones, d'autre part, sont traités par un cœur spécifique, les tâches ni synchrones, ni périodiques étant traitées par ledit cœur du premier groupe de tâches périodiques ou un cœur du second groupe de tâches synchrones ou par un autre cœur que les cœurs spécifiques des tâches synchrones et périodiques en formant au moins un troisième groupe.

Description

PROCEDE DE CONTROLE COMMANDE PAR UN MICROPROCESSEUR
MULTICOEUR
[0001 ] L'invention porte sur un procédé de contrôle commande par un microprocesseur multi-cœur, c'est-à-dire à plusieurs cœurs aussi dénommés unités de traitement. L'invention se situe dans le domaine du traitement en temps réel utilisant les ressources de processeurs à coeurs multiples.
[0002] Elle trouve une application particulière mais non limitative dans le domaine des véhicules automobiles pour calculateurs d'un contrôle commande moteur avec une architecture de système ouvert, c'est-à-dire un système dans lequel il est possible de réutiliser du logiciel d'application selon une interface standard ou dans une version dite adaptable un système dans lequel il est possible d'ajouter ou d'enlever de nouvelles fonctionnalités en cours d'exécution.
[0003] Une telle architecture de système ouvert peut être une architecture selon la norme Autosar pour un système à architecture ouverte pour automobile aussi connu sous la dénomination anglo-saxonne de « AUTomotive Open System Architecture », sans que ce soit une obligation pour cette invention.
[0004] Les calculateurs de contrôle moteur utilisaient jusqu'à ces dernières années des processeurs avec une seule unité de traitement, c'est-à-dire un processeur monocoeur. Plus récemment on assiste à l'apparition de processeurs comportant au moins deux unités de traitement, encore dénommés processeurs à coeurs multiples qui permettent une puissance de calcul supérieure à celle des processeurs monocoeur, tout en utilisant une fréquence de fonctionnement égale à celle d'un processeur monocoeur.
[0005] Classiquement, l'architecture fonctionnelle découpe les fonctions en sous- fonctions selon des besoins de répartition du travail ou de gestion de la diversité des options. Classiquement ce découpage fonctionnel est à la base des procédés de répartition du logiciel sur plusieurs cœurs de calcul. De plus une étude de graphes de transitions entre les différentes sous-fonctions est parfois utilisée pour cela. Plus simplement, actuellement, la mise en œuvre de fonctions sur deux unités de traitement d'un processeur à coeurs multiples est par exemple réalisée par une allocation sur un cœur du logiciel d'applications au-dessus d'une interface de l'architecture du système ouvert et une allocation du logiciel de base du système sur un autre cœur du processeur. Classiquement, les entités exécutables du logiciel sont groupées en tâches logicielles selon leur type d'activation. Chaque tâche logicielle comporte des entités exécutables d'un seul type d'activation. Ces tâches logicielles sont ainsi aptes à être gérées en temps réel par un moniteur de tâches qui les active selon leur type de déclenchement.
[0006] Le passage aux processeurs à coeurs multiples est nécessaire. En effet, la puissance de calcul d'un processeur monocoeur n'augmente plus autant que par le passé du fait notamment du plafonnement de sa fréquence d'utilisation.
[0007] Cela est problématique, d'une part, par rapport au respect des contraintes de temps. Par exemple, dans le domaine des systèmes embarqués dans l'automobile, il y a de fortes contraintes de temps d'exécution pour obtenir la réactivité nécessaire aux performances des organes et des fonctions du véhicule. Ceci est en particulier vrai pour les fonctions de la dynamique du véhicule en relation avec le régime d'un moteur thermique ou pour un véhicule à moteur électrique, ou hybride combinant moteur thermique et électrique.
[0008] Cela l'est, d'autre part, par rapport au volume des traitements qui ne cesse d'augmenter. Par exemple, pour les traitements du logiciel de contrôle commande d'un moteur de véhicule automobile, ceci est engendré notamment par les normes antipollution de plus en plus sévères et par les exigences de basse consommation de plus en plus fortes pour la réduction des émissions de C02 qui augmentent les traitements.
[0009] Les processeurs à coeurs multiples peuvent offrir en théorie plus de puissance de calcul mais ils nécessitent de paralléliser les traitements sur les différents cœurs, alors que ces traitements étaient jusqu'à présents effectués de façon séquentielle sur un seul cœur.
[0010] Pour qu'un processeur à coeurs multiples fonctionne efficacement, les traitements qui sont répartis sur ses différentes unités de traitement ne doivent pas comporter de relations de précédence. En d'autres termes, les unités de traitement doivent pouvoir fonctionner de façon désynchronisée, sans s'attendre mutuellement.
[001 1 ] Cela n'est pas sans poser des difficultés pour l'utilisation de processeurs à coeurs multiples, ceci notamment pour le contrôle moteur d'un véhicule automobile, du fait que les fonctions comportent fréquemment des asservissements en forme de boucles des sorties vers les entrées. Ces boucles de contrôle commande doivent s'exécuter dans un ordre précis et ne peuvent donc pas être découpées pour être parallélisées sur deux unités de traitement indépendantes. [0012] Il s'ensuit que l'allocation de l'ensemble ou d'une grosse partie de l'application sur une unité de traitement crée un déséquilibre de charge de travail entre les différentes unités de traitement, ce qui ne permet pas d'exploiter pleinement le potentiel d'un processeur à coeurs multiples. C'est particulièrement vrai dans le domaine automobile pour un calculateur de contrôle moteur d'une architecture de système ouvert dans lequel la charge de calcul de l'ensemble de l'application est beaucoup plus grosse que celle du logiciel de base d'une architecture de système ouvert.
[0013] Selon l'état de l'art de la conception des systèmes, il se trouve que souvent une fonction et le module logiciel correspondant comportent respectivement des sous- fonctions et des entités exécutables de différents types d'activation. Cela va entraîner une difficulté à répartir les modules sur différentes unités de traitement ou cœurs du microprocesseur.
[0014] En effet, dans le cadre d'une architecture à système ouvert du type Autosar, un module, c'est-à-dire un composant atomique au sens Autosar, ne peut être scindé sur plusieurs cœurs. Donc toutes les entités exécutables d'un module doivent aller sur le même cœur ou unité de calcul. On retrouve parfois aussi cette contrainte dans des logiciels ne faisant pas partie d'une architecture de système ouvert car elle est simplement liée à une conception du logiciel qui partage des variables globales à une fonction par les différentes sous-fonctions. [0015] D'autre part, les boucles de contrôle commande englobent souvent plusieurs fonctions et donnent naissance à des entités exécutables réparties en différentes sous- fonctions qui ont un même type de déclenchement. Ces entités exécutables doivent suivre un ordre de séquencement prédéfini au sein de leur tâche logicielle : elles doivent en conséquence aussi être sur la même unité de traitement. [0016] Il en résulte que dans cette conception classique il faut mettre une grosse partie du système fonctionnel sur une même unité de traitement, ce qui produit une surcharge de calcul sur celle-ci alors que d'autres unités de traitement sont sous-employées.
[0017] Parfois, les entités exécutables d'un même type de déclenchement sont néanmoins réparties sur différentes unités de traitement, sous la contrainte de relations de précédence entre les unités de traitement pour respecter l'ordre d'exécution de ces entités exécutables. Cela produit dans une implémentation sur processeur à coeurs multiples des temps d'attente et potentiellement des temps de réponses supérieurs à ceux d'une implémentation en processeur monocoeur. Il en résulte des situations qui peuvent devenir critiques du point de vue des performances en temps réel, en particulier pour le respect des périodes de tâches périodiques réparties sur plusieurs unités de traitement.
[0018] Par conséquent, le problème à la base de l'invention est de permettre l'accélération des traitements des cœurs multiples d'un processeur multicœur afin que ces traitements puissent se faire en temps réel sans délai.
[0019] Pour atteindre cet objectif, il est prévu selon l'invention un procédé de contrôle commande mettant en œuvre des tâches logicielles par un microprocesseur multicoeurs comportant plusieurs cœurs en tant qu'unités de traitement travaillant en parallèle, ces tâches logicielles comprenant :
-des tâches logicielles dites synchrones à période variable,
-des tâches logicielles dites périodiques à période fixe,
-des tâches logicielles ni synchrones, ni périodiques,
ces tâches sont regroupées en au moins un premier groupe de tâches logicielles périodiques et un deuxième groupe de tâches synchrones et en ce que le groupe de tâches périodiques, d'une part, et le groupe de tâches synchrones, d'autre part, sont traités par au moins un cœur du microprocesseur leur étant spécifique, les tâches ni synchrones, ni périodiques étant traitées par ledit au moins un cœur du premier groupe de tâches périodiques ou au moins un cœur du second groupe de tâches synchrones ou par au moins un autre cœur que les cœurs spécifiques des tâches synchrones et périodiques en formant au moins un troisième groupe.
[0020] L'effet technique est d'obtenir une architecture de logiciel qui ne génère pas de temps d'attente entre les différentes unités de traitement ou cœurs du microprocesseur. Les entités exécutables qui ont un déclenchement de type synchrone du moteur peuvent être regroupées en une ou plusieurs tâches et prises en charge par une ou des autres unités de traitement spécifiques, c'est-à-dire un ou des cœurs du microprocesseur, autres que le ou les unités de traitement qui traitent les tâches périodiques.
[0021 ] Cette répartition des tâches logicielles permet de rendre beaucoup plus régulier l'exécution des tâches périodiques qui se déroulent alors selon un ordre stable et déterministe, sans être interrompues par des tâches synchrones du moteur qui sont en général prioritaires. Le système est ainsi plus simple à valider parce que les marges de temps de réponse pour les tâches périodiques ne dépendent plus des conditions de fonctionnement de l'organe ou des organes à piloter. [0022] Par exemple, pour le cas non limitatif d'un contrôle commande intégré dans un véhicule automobile et pilotant le moteur, les conditions de fonctionnement incluent le régime moteur. A plein régime moteur, ce qui correspond à une charge de calcul maximale dans le microprocesseur d'un contrôle commande du moteur, la charge de calcul est bien répartie entre les unités de traitement qui ont en charge les tâches synchrones moteur et celles qui ont en charge les tâches périodiques.
[0023] D'une façon générale, selon l'invention, en fonction du nombre d'unités de traitement ou cœurs disponibles dans le microprocesseur et en fonction du poids de chaque type de tâche, il est possible d'optimiser l'allocation des traitements sur différentes unités de traitement en se basant sur leur type de déclenchement, essentiellement périodique ou synchrone et non plus sur une architecture fonctionnelle.
[0024] Avantageusement, ledit au moins un troisième groupe de tâches comprend les tâches s'activant de manière aléatoire. Etant donné le caractère non prédictif des tâches s'activant de manière aléatoire, on aura aussi avantage à leur dédier au moins une unité de traitement ou un cœur spécifique. De cette manière, les tâches périodiques ou synchrones ne sont pas perturbées par les tâches s'activant de manière aléatoire.
[0025] Avantageusement, les tâches s'activant de manière aléatoire comprennent des tâches activées par interruption non souhaitée d'une fonction contrôlée et/ou commandée par le microprocesseur ou d'au moins un organe de contrôle et/ou de commande dédié à la fonction et piloté par le microprocesseur. Une partie des tâches s'activant de manière aléatoire s'apparentent à des pannes de l'organe ou des organes contrôlés par le microprocesseur.
[0026] Avantageusement, le premier groupe de tâches périodiques est scindé en au moins deux sous-groupes correspondant à des tâches présentant des périodes différentes, chaque sous-groupe étant traité par un cœur différent.
[0027] Avantageusement, un premier des sous-groupes correspond à des tâches logicielles s'effectuant à des périodes inférieures ou égales à un premier seuil, tandis que le deuxième des sous-groupes correspond à des tâches logicielles s'effectuant à des périodes supérieures à un second seuil, le premier seuil étant inférieur ou égal au deuxième seuil.
[0028] Avantageusement, au moins une entité exécutable est propre à au moins une tâche respective d'une partie des tâches des premier et deuxième groupes. La présente invention propose ainsi qu'un module logiciel soit décomposé plus finement par rapport à l'état de l'art actuel afin de ne contenir des entités exécutables que d'un seul type d'activation. Ainsi, il sera possible de répartir les tâches d'un moniteur de tâche sur des cœurs différents. [0029] Avantageusement, un moniteur de tâche est utilisé au moins pour chaque tâche des premier et deuxième groupes et est intégré dans le cœur du microprocesseur spécifique pour ladite tâche.
[0030] Avantageusement, au moins une des tâches synchrones est relative à une ou plusieurs fonctions synchrones d'un moteur piloté par un contrôle commande en tournant à un régime variable, ces fonctions présentant une période d'exécution variable fonction du régime du moteur à un instant donné.
[0031 ] Une analyse du système physique permet de remarquer que les fonctions synchrones du moteur ont une période d'exécution variable : ainsi par exemple la tâche synchrone moteur est tantôt plus lente que la tâche périodique à 10 ms tantôt plus rapide, selon le régime du moteur. Il est donc intéressant de traiter les tâches synchrones du moteur et les tâches périodiques en parallèle sur au moins deux cœurs différents sachant qu'en conséquence de la constitution du système physique, les fonctions synchrones du moteur n'ont généralement pas de relation de précédence avec les tâches périodiques et réciproquement. [0032] L'invention concerne aussi un processeur à plusieurs cœurs pour un contrôle commande, caractérisé en ce qu'il met en œuvre un tel procédé.
[0033] L'invention concerne aussi un contrôle commande de véhicule automobile, caractérisé en ce qu'il comprend un processeur tel que précédemment mentionné.
[0034] L'invention concerne enfin un véhicule automobile comprenant au moins un moteur et un tel contrôle commande au moins en charge du fonctionnement dudit au moins un moteur et d'une aide à la conduite du véhicule comme, pris unitairement ou en combinaison, un système d'antiblocage des roues ou ABS, un électrostabilisateur programmé ou ESP, une boîte de vitesses automatique ou BVA, une direction assistée électrique. [0035] D'autres caractéristiques, buts et avantages de la présente invention apparaîtront à la lecture de la description détaillée qui va suivre et au regard des dessins annexés donnés à titre d'exemples non limitatifs et sur lesquels : - la figure 1 est une représentation schématique d'un exemple de processeur multicoeurs avec n unités de calcul, ce processeur pouvant permettre la mise en œuvre du procédé selon l'invention,
- la figure 2 est une représentation schématique d'un exemple de décomposition fonctionnelle en fonction et sous-fonctions dans un processeur multicoeurs selon l'état de la technique,
- la figure 3 est une représentation schématique d'un exemple de composition d'un logiciel avec m modules et des entités exécutables en chaque module dans un processeur pouvant permettre la mise en œuvre du procédé selon l'invention. [0036] Il est à garder à l'esprit que les figures sont données à titre d'exemples et ne sont pas limitatives de l'invention. Elles constituent des représentations schématiques de principe destinées à faciliter la compréhension de l'invention.
[0037] Dans ce qui va suivre, il est fait référence à toutes les figures prises en combinaison. Quand il est fait référence à une ou des figures spécifiques, ces figures sont à prendre en combinaison avec les autres figures pour la reconnaissance des références numériques désignées.
[0038] L'invention concerne l'organisation du traitement des tâches dans un processeur qui met en oeuvre différentes unités de traitement, c'est-à-dire différents cœurs d'un processeur à coeurs multiples. Elle propose d'architecturer le logiciel pour pouvoir le répartir sur les différentes unités de traitement, selon un scénario avantageux pour maximiser l'utilisation des unités de traitement ou cœurs et obtenir des temps de réponses optimaux.
[0039] Il va être débuté par un rappel du contexte d'un processeur à coeurs multiples comportant plusieurs unités de traitement autonomes. [0040] Selon la figure 1 , un processeur à coeurs multiples 1 se caractérise par le fait qu'il met en œuvre plusieurs unités de traitement 1 .1 , 1 .2 à 1 .p. A titre d'exemple non limitatif, un processeur à coeurs multiples pour un contrôle moteur d'un véhicule automobile fréquemment utilisé peut comporter trois unités de traitement. Cet exemple sera utilisé pour illustrer l'invention, mais on pourrait de façon avantageuse utiliser de façon similaire un processeur comportant davantage d'unités de traitement, comme par exemple un processeur comportant six unités de traitement ou tout autre nombre supérieur à 3. [0041 ] Pour obtenir des temps de réponses les plus rapides possible, les unités de traitement d'un processeur à coeurs multiples doivent pouvoir travailler de façon indépendante, sans s'attendre les unes les autres. Pour cela il est procédé à une mise en en parallèle des traitements. Ceci est montré à la figure 1 qui illustre un exemple d'un processeur à coeurs multiples avec p unités de calcul comme unités de traitement.
[0042] Dans ce qui va suivre, il va ensuite être procédé à un rappel de ce qu'est une architecture fonctionnelle connue. Classiquement, une architecture fonctionnelle découpe les fonctions en sous-fonctions selon des besoins de répartition du travail de conception ou de gestion de la diversité des options. [0043] En se référant à la figure 2, qui montre un exemple de décomposition fonctionnelle en fonction et sous-fonctions pour une architecture fonctionnelle qui peut être à deux niveaux. Il est alors fait une distinction entre:
l'ensemble des fonctions ou système fonctionnel 2,
- les fonctions, au nombre de f qui sont référencées 2.1 à 2.f,
- les sous-fonctions, encore nommées fonctions élémentaires, au nombre de S1 pour la fonction 2.1 et au nombre de Sf pour la fonction 2.f.
[0044] Il est bien connu dans l'état de l'art des systèmes fonctionnant en temps réel que les mécanismes d'activation des fonctions élémentaires peuvent être périodiques de période fixe, ou cycliques avec une période variable, ou événementiels aléatoires. [0045] Dans ce qui va suivre, la présente invention va être illustrée en prenant ces exemples de types d'activation. Il convient cependant de garder à l'esprit que d'autres types d'activation peuvent être pris en compte de façon similaire.
[0046] La figure 3 présente un exemple d'une architecture de logiciel issue d'une conception fonctionnelle selon l'état de l'art existant mais pouvant mettre en œuvre le procédé selon la présente invention, l'architecture comprenant m modules et des entités exécutables en chaque module.
[0047] A cette figure 3, il est possible de distinguer :
- le logiciel 3,
- des entités élémentaires de conception du logiciel nommées modules dans la suite de la présente description, au nombre de m, 3.1 à 3. m, qui correspondent à des composants logiciels dans le contexte d'une architecture de système, - des entités élémentaires d'exécution du logiciel correspondant à des portions de modules qui sont activées chacune par un mécanisme particulier, ci-après dénommées entités exécutables dans la suite de la présente description, au nombre de R1 dans le module 3.1 et au nombre de Rm dans le module 3. m. [0048] En se référant aux figures 2 et 3, au système fonctionnel 2 correspond le logiciel 3, aux fonctions 2.x correspondent les modules 3.x et aux fonctions élémentaires 2.x. y correspondent les entités exécutables 3.x.y.
[0049] Dans l'implémentation du logiciel, il est bien connu selon l'état de l'art que les entités exécutables sont regroupées par type de déclenchement en tâches logicielles. Autrement dit une tâche logicielle est un ensemble d'entités exécutables d'un même type de déclenchement. Un moniteur de tâche a pour rôle d'activer au fur et à mesure des déclenchements les différentes tâches.
[0050] Dans le domaine automobile du contrôle moteur, sans que cela soit limitatif, il peut être cité des exemples de différents types d'activation de fonctions élémentaires 2.x.y :
- activation périodique avec une période fixe d'environ 10 ms,
- activation périodique avec une période fixe d'environ 5ms,
- activation événementielle cyclique avec une période variable. Dans le cas d'un contrôle commande pilotant un moteur, synchronisé par exemple relativement à une position de piston, un régime moteur, cette activation est aussi désigné synchrone moteur,
- activation événementielle aléatoire issue du matériel, encore nommée interruption.
[0051 ] La présente invention consiste à concevoir une architecture fonctionnelle du logiciel avec un niveau supplémentaire de découpage des fonctions défini par la séparation des entités exécutables 3.x.y par type d'activation. Ainsi, chaque fonction ne comporte que des fonctions élémentaires d'un type d'activation.
[0052] L'invention concerne un procédé de contrôle commande mettant en œuvre des tâches logicielles par un microprocesseur multicoeurs comportant plusieurs cœurs en tant qu'unités de traitement travaillant en parallèle, ces tâches logicielles comprenant des tâches logicielles dites synchrones à période variable, des tâches logicielles dites périodiques à période fixe, des tâches logicielles ni synchrones, ni périodiques. Selon l'invention, ces tâches sont regroupées en au moins un premier groupe de tâches logicielles périodiques et un deuxième groupe de tâches synchrones et le groupe de tâches périodiques, d'une part, et le groupe de tâches synchrones, d'autre part, sont traités par au moins un cœur du microprocesseur leur étant spécifique, c'est-à-dire par au moins un cœur différent.
[0053] Les tâches logicielles ni synchrones, ni périodiques sont traitées par ledit au moins un cœur du premier groupe de tâches périodiques ou au moins un cœur du second groupe de tâches synchrones ou par au moins un autre cœur que les cœurs spécifiques des tâches synchrones et périodiques en formant au moins un troisième groupe. Comme il sera vu par la suite, cette deuxième solution est préférée.
[0054] Une analyse d'un logiciel de contrôle moteur montre que la majorité de la charge de calcul se répartit entre deux grands groupes, à savoir les tâches synchrones et les tâches périodiques. Les tâches synchrones du moteur n'ont pas du tout de relation de précédence avec les tâches périodiques. Elles peuvent donc être mises en parallèle des tâches périodiques.
[0055] De manière générale, dans le moteur, les tâches logicielles synchrones sont prioritaires sur les tâches logicielles périodiques. Quand des tâches logicielles périodiques sont confiées au contrôle commande, dès que ces tâches logicielles périodiques ont démarré, elles peuvent redonner le contrôle au programme principal sans avoir nécessairement terminé leur exécution.
[0056] Un autre groupe, appelée troisième groupe de tâches, comprend les tâches logicielles s'activant de manière aléatoire. Les tâches s'activant de manière aléatoire peuvent comprendre principalement des tâches activées par interruption non souhaitée d'une fonction contrôlée et/ou commandée par le microprocesseur ou d'au moins un organe de contrôle et/ou de commande dédié à la fonction et piloté par le microprocesseur. Ces interruptions sont fréquemment des interruptions matérielles. Dans le moteur, ces tâches logicielles s'activant de manière aléatoire sont prioritaires sur les tâches logicielles synchrones.
[0057] Dans le cas non limitatif d'un processeur avec trois cœurs 1 .1 , 1 .2 à 1 .3 réalisant des unités de traitement, la présente invention permet par exemple la répartition suivante qui équilibre au mieux la charge de calcul entre les trois coeurs :
- unité de traitement pour les tâches périodiques lentes, par exemple de période supérieure ou égale à 10 ms,
- unité de traitement pour les tâches synchrones du moteur, - unité de traitement pour les tâches sous interruption matérielle et les tâches périodiques rapides par exemple de période inférieure ou égale à 5ms.
[0058] Une analyse supplémentaire du système montre que généralement la conception fonctionnelle produit des tâches périodiques, avec des sous-fonctions qui n'ont pas de relation de précédence entre différentes périodes d'activation.
[0059] On peut donc mettre en parallèle sur différentes unités de traitement, sans les ralentir mutuellement des tâches périodiques de différentes périodes. Le premier groupe de tâches périodiques peut être scindé en au moins deux sous-groupes correspondant à des tâches logicielles s'effectuant à des périodes différentes, chaque sous-groupe étant traité par un cœur différent du microprocesseur. Le premier des sous-groupes peut ainsi correspondre à des tâches logicielles s'effectuant à des périodes inférieures ou égales à un premier seuil Sp1 , par exemple de 5 ms tandis que le deuxième sous-groupe peut correspondre à des tâches logicielles s'effectuant à des périodes supérieures à un second seuil Sp2, par exemple 10ms, le premier seuil Sp1 étant inférieur ou égal au deuxième seuil Sp2.
[0060] Tout cela sera rendu possible en maximisant la capacité de traitement globale et en minimisant les temps de réponse du système. Ceci requiert comme condition qu'on ait fait une architecture du logiciel basée sur un découpage fin des fonctions 2.1 à 2.f en sous fonctions 2.x.y afin d'obtenir des entités exécutables 3.x.y d'un seul type d'activation du logiciel dans chaque module logiciel 3.1 à 3. m.
[0061 ] Ainsi, au moins une entité exécutable 3.x.y peut être propre à au moins une tâche logicielle respective d'une partie des tâches logicielles des premier et deuxième groupes. En général chaque tâche logicielle peut présenter au moins une entité exécutable 3.x.y sauf si plusieurs tâches logicielles sont similaires. Le moniteur de tâche, précédemment mentionné dans la description de l'état de la technique, peut être, dans le cadre de l'invention, spécifique au moins pour chaque tâche logicielle des premier et deuxième groupes et peut être intégré dans le cœur du microprocesseur spécifique pour ladite tâche.
[0062] Selon l'invention, il existe une possibilité de répartition de la charge de calcul entre les différents cœurs 1 .1 , 1 .2 à 1 .p de traitement pour en diminuer la charge de calcul et pour en améliorer le temps de réponse.
[0063] L'invention concerne aussi un processeur à plusieurs cœurs 1 .1 , 1 .2 à 1 .p pour un contrôle commande, caractérisé en ce qu'il met en œuvre un tel procédé. [0064] Dans une application non limitative mais avantageuse, l'invention concerne aussi un contrôle commande de véhicule automobile, caractérisé en ce qu'il comprend un processeur tel que précédemment mentionné.
[0065] La présente invention va maintenant être développée dans le cadre d'un contrôle commande pour véhicule automobile, principalement un contrôle commande de moteur qui peut aussi piloter d'autres fonctionnalités présentes dans le véhicule automobile. Ceci est une application préférée de la présente invention mais n'est pas limitative.
[0066] Dans ce cas, quand au moins une des tâches synchrones est relative à une ou plusieurs fonctions synchrones d'un moteur piloté par un contrôle commande en tournant à un régime variable, ces fonctions présentent une période d'exécution variable qui est fonction du régime du moteur à un instant donné.
[0067] En particulier, pour le cas spécifique et non limitatif d'un contrôle moteur, une part très importante des tâches périodiques est constituée d'abord par les tâches logicielles de période de 10 ms puis par celles de période de 5 ms. Si on dispose de suffisamment d'unités de traitement, on pourra avantageusement réserver une unité de traitement majoritairement pour les tâches à 10 ms et mettre les tâches à 5 ms sur une autre unité de traitement.
[0068] L'invention concerne enfin un véhicule automobile comprenant au moins un moteur et un tel contrôle commande au moins en charge du fonctionnement dudit au moins un moteur.
[0069] Prendre en charge le fonctionnement du moteur signifie prendre en charge son alimentation en air et carburant, son échappement notamment en ce qui concerne les éléments de dépollution présents dans sa ligne d'échappement et tous ses périphériques, par exemple une ligne de recirculation des gaz d'échappement à l'admission d'air, un turbocompresseur, son système de lubrification et son système de refroidissement pris dans son sens large avec le cas échéant la climatisation de l'habitacle.
[0070] Le contrôle commande peut piloter aussi une aide à la conduite du véhicule, comme pris unitairement ou en combinaison un système d'antiblocage des roues ou ABS, un électrostabilisateur programmé ou ESP, une boîte de vitesses automatique ou BVA, une direction assistée électrique, sans que cela soit limitatif.
[0071 ] Dans le cadre de la présente invention, il existe aussi une possibilité d'utilisation du microprocesseur pour plusieurs types de véhicule, ceci en ajoutant de nouvelles fonctions logicielles sans devoir reconcevoir l'électronique du microprocesseur. La place disponible pour les nouvelles fonctions logicielles a été augmentée par la mise en oeuvre du procédé selon l'invention.
[0072] L'invention n'est nullement limitée aux modes de réalisation décrits et illustrés qui n'ont été donnés qu'à titre d'exemples.

Claims

Revendications :
Procédé de contrôle commande mettant en œuvre des tâches logicielles par un microprocesseur multicoeurs comportant plusieurs cœurs (1 .1 , 1 .2 à 1 .p) en tant qu'unités de traitement travaillant en parallèle, ces tâches logicielles comprenant : -des tâches logicielles à période variable, dites synchrones,
-des tâches logicielles à période fixe, dites périodiques,
-des tâches logicielles ni synchrones, ni périodiques,
, caractérisé en ce que ces tâches sont regroupées en au moins un premier groupe de tâches logicielles périodiques et un deuxième groupe de tâches synchrones et en ce que le groupe de tâches périodiques, d'une part, et le groupe de tâches synchrones, d'autre part, sont traités par au moins un cœur du microprocesseur leur étant spécifique, les tâches ni synchrones, ni périodiques étant traitées par ledit au moins un cœur du premier groupe de tâches périodiques ou au moins un cœur du second groupe de tâches synchrones ou par au moins un autre cœur que les cœurs (1 .1 , 1 .2 à 1 .p) spécifiques des tâches synchrones et périodiques en formant au moins un troisième groupe.
Procédé selon la revendication précédente, dans lequel ledit au moins un troisième groupe de tâches comprend les tâches s'activant de manière aléatoire.
Procédé selon la revendication précédente, dans lequel les tâches s'activant de manière aléatoire comprennent des tâches activées par interruption non souhaitée d'une fonction contrôlée et/ou commandée par le microprocesseur ou d'au moins un organe de contrôle et/ou de commande dédié à la fonction et piloté par le microprocesseur.
Procédé selon l'une quelconque des revendications précédentes, dans lequel le premier groupe de tâches périodiques est scindé en au moins deux sous-groupes correspondant à des tâches présentant des périodes différentes, chaque sous-groupe étant traité par un cœur différent.
Procédé selon la revendication précédente, dans lequel un premier des sous-groupes correspond à des tâches logicielles s'effectuant à des périodes inférieures ou égales à un premier seuil (Sp1 ), tandis que le deuxième des sous-groupes correspond à des tâches logicielles s'effectuant à des périodes supérieures à un second seuil (Sp2), le premier seuil (Sp1 ) étant inférieur ou égal au deuxième seuil (Sp2).
6. Procédé selon l'une quelconque des revendications précédentes, dans lequel au moins une entité exécutable est propre à au moins une tâche respective d'une partie des tâches des premier et deuxième groupes.
7. Procédé selon l'une quelconque des revendications précédentes, dans lequel un moniteur de tâche est utilisé au moins pour chaque tâche des premier et deuxième groupes et est intégré dans le cœur du microprocesseur spécifique pour ladite tâche.
8. Procédé selon l'une quelconque des revendications précédentes, dans lequel au moins une des tâches synchrones est relative à une ou plusieurs fonctions synchrones d'un moteur piloté par un contrôle commande en tournant à un régime variable, ces fonctions présentant une période d'exécution variable qui est fonction du régime du moteur à un instant donné.
9. Processeur à plusieurs cœurs (1 .1 , 1 .2 à 1 .p) pour un contrôle commande, caractérisé en ce qu'il met en œuvre un procédé selon l'une quelconque des revendications précédentes. 10. Contrôle commande de véhicule automobile, caractérisé en ce qu'il comprend un processeur selon la revendication précédente.
1 1 . Véhicule automobile comprenant au moins un moteur et un contrôle commande selon la revendication précédente, lequel est au moins en charge du fonctionnement dudit au moins un moteur et d'une aide à la conduite du véhicule comme, pris unitairement ou en combinaison, un système d'antiblocage des roues ou ABS, un électrostabilisateur programmé ou ESP, une boîte de vitesses automatique ou BVA, une direction assistée électrique.
EP16809965.3A 2015-11-12 2016-11-07 Procede de controle commande par un microprocesseur multicoeur Withdrawn EP3374866A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1560783A FR3043808B1 (fr) 2015-11-12 2015-11-12 Procede de controle commande de taches fonctionnelles par un microprocesseur multicoeurs
PCT/FR2016/052871 WO2017081391A1 (fr) 2015-11-12 2016-11-07 Procede de controle commande par un microprocesseur multicoeur

Publications (1)

Publication Number Publication Date
EP3374866A1 true EP3374866A1 (fr) 2018-09-19

Family

ID=55300546

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16809965.3A Withdrawn EP3374866A1 (fr) 2015-11-12 2016-11-07 Procede de controle commande par un microprocesseur multicoeur

Country Status (4)

Country Link
EP (1) EP3374866A1 (fr)
CN (1) CN108351809A (fr)
FR (1) FR3043808B1 (fr)
WO (1) WO2017081391A1 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3071334B1 (fr) 2017-09-19 2019-08-30 Psa Automobiles Sa Procede pour assurer la stabilite des donnees d’un processeur multicoeur d’un vehicule automobile
FR3071332B1 (fr) * 2017-09-19 2019-09-27 Psa Automobiles Sa Procede de gestion de taches par un processeur multicoeur d’un vehicule automobile
FR3090157B1 (fr) * 2018-12-12 2020-11-20 Continental Automotive France Procédé de commande d’une unité de contrôle moteur à processeur multicœur
EP3671450A1 (fr) * 2018-12-18 2020-06-24 Aptiv Technologies Limited Unités de commande électroniques virtuelles dans autosar
CN111427742B (zh) * 2020-03-09 2023-11-03 创驱（上海）新能源科技有限公司 一种基于autosar架构的复杂驱动任务实时监控方法
CN113704156B (zh) * 2021-08-30 2022-09-06 寒武纪行歌(南京)科技有限公司 感知数据处理装置、板卡、系统及方法
CN117951064A (zh) * 2022-10-31 2024-04-30 华为技术有限公司 一种芯片系统和集合通信方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8683471B2 (en) * 2008-10-02 2014-03-25 Mindspeed Technologies, Inc. Highly distributed parallel processing on multi-core device
DE102010053490A1 (de) * 2010-12-04 2011-07-28 Daimler AG, 70327 Lenkrad für ein Kraftfahrzeug
EP2707814A4 (fr) * 2011-05-11 2015-04-29 Google Inc Génération parallèle de sujets à partir de documents
CN103207782B (zh) * 2013-03-27 2014-02-26 北京航空航天大学 基于multi-kernel MOS 的分区系统构建方法
US9223627B2 (en) * 2013-03-27 2015-12-29 Nice-Systems Ltd. Management of task allocation in a multi-core processing system
CN103823706B (zh) * 2014-02-12 2018-02-06 浙江大学 一种基于RTLinux的被控对象模型模拟仿真实时调度方法

Also Published As

Publication number Publication date
FR3043808A1 (fr) 2017-05-19
FR3043808B1 (fr) 2017-12-08
WO2017081391A1 (fr) 2017-05-18
CN108351809A (zh) 2018-07-31

Similar Documents

Publication Publication Date Title
EP3374866A1 (fr) Procede de controle commande par un microprocesseur multicoeur
EP3286647A1 (fr) Placement d'une tâche de calcul sur un processeur fonctionnellement asymetrique
EP3238056B1 (fr) Methode d'ordonnancement de taches au niveau des noeuds d'un cluster informatique, ordonnanceur de taches et cluster associes
WO2014170569A1 (fr) Procédé d'allocation temporelle de tâches permettant une récupération d'erreur deterministe en temps réel
WO2013107819A1 (fr) Procédé d'optimisation de traitement parallèle de données sur une plateforme matérielle.
EP2342636A1 (fr) Procédé de réalisation d'un appel d'une instance d'une fonction, dispositif, et programme d'ordinateur correspondant
WO2010105889A1 (fr) Unité d'allocation et de contrôle
EP0637798A1 (fr) Procédé d'analyse d'interblocage dans un système d'exploitation
FR3062357A1 (fr) Procede de surveillance d'un defaut de controle du groupe motopropulseur d’un vehicule
FR3075414B1 (fr) Procede de gestion d'une pluralite de taches par un calculateur automobile multicœur
FR3056782A1 (fr) Generation de codes applicatifs a partir d'une specification formelle
Pan et al. Parm: Efficient training of large sparsely-activated models with dedicated schedules
EP2029911A1 (fr) Procede et systeme de contrôle antivibratoire et antibruit pour groupe motopropulseur d'un vehicule.
WO2020120690A1 (fr) Procédé de commande d'une unité de contrôle moteur à processeur multicoeur
FR3071334B1 (fr) Procede pour assurer la stabilite des donnees d’un processeur multicoeur d’un vehicule automobile
FR3077403A1 (fr) Procede de conception d’une architecture de taches applicative d’une unite de controle electronique avec un ou des cœurs virtuels
FR2926146A1 (fr) Dispositif informatique a memoire reservee pour des applications prioritaires.
FR3031822A1 (fr) Telechargement de donnees sur un equipement distant
FR3082338A1 (fr) Procede de gestion d’une pluralite de taches par un calculateur automobile multicœur
EP4104056A1 (fr) Calculateur électronique, système électronique, procédé de surveillance de l'exécution d'une application et programme d'ordinateur associé
FR2989528A1 (fr) Systeme d'alimentation electrique
CN109947232A (zh) 用于管理悬挂式电子控制单元中系统存储器完整性的系统和方法
CA2778576C (fr) Procede et dispositif de traitement de taches optimise pour un fws
FR2658628A1 (fr) Systeme informatique pour gerer l'execution en temps reel de taches selon des priorites et hierarchies predeterminees.
FR3071332B1 (fr) Procede de gestion de taches par un processeur multicoeur d’un vehicule automobile

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20180410

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20200424

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: PSA AUTOMOBILES SA

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20200905