FR3063359B1 - Methode de determination d'une performance temporelle d'une unite de traitement electronique executant un algorithme - Google Patents

Abstract

Méthode de détermination d'une performance temporelle d'une unité de traitement électronique exécutant un algorithme donné, des éléments de code (k1, k2,..., k5) de l'algorithme étant exécutés en parallèle au moyen de plusieurs processeurs (pu1, pu2) de l'unité de traitement. Selon l'invention, la méthode comprend les étapes suivantes : - pour chacun desdits processeurs, détermination de la valeur d'une fonction de coût individuelle associée à ce processeur en fonction de l'écart entre : - une période de répétition (T) séparant deux données successives à traiter, et - une durée totale d'exécution (tpu1, tpu2) de l'ensemble des éléments de code attribués à ce processeur, et - détermination de la valeur d'une fonction de coût globale, représentative de ladite performance temporelle, en fonction des valeurs de chacune desdites fonctions de coût individuelles.

Description

Domaine technique auquel se rapporte l'invention

La présente invention concerne de manière générale une méthode de détermination d’une performance temporelle d’une unité de traitement électronique exécutant un algorithme donné, en particulier lorsque des éléments de code de l’algorithme sont exécutés en parallèle au moyen de plusieurs processeurs de l’unité de traitement. L’invention concerne également une méthode associée de sélection d’un mode de répartition d’éléments de code à exécuter, entre plusieurs processeurs d’une unité de traitement électronique.

Elle concerne également une méthode de sélection d’une unité de traitement électronique, parmi plusieurs telles unités.

Elle s’applique de manière particulièrement intéressante à la caractérisation et/ou à la sélection d’une unité de traitement électronique, en vue d’installer cette unité de traitement dans un véhicule automobile pour qu’elle y exécute un algorithme d’aide à la conduite comprenant le traitement successif de plusieurs images capturées par une caméra.

Arriere-plan technologique

De plus en plus de véhicules automobiles sont équipés de dispositifs d’aide à la conduite qui comprennent une caméra vidéo ainsi qu’une unité de traitement de données configurée pour traiter des images capturées par la caméra afin d’en extraire des informations relatives à l’environnement routier du véhicule automobile. Ces informations, qui peuvent par exemple être relatives à la position d’un obstacle présent dans cet environnement routier, sont alors communiquées à un conducteur du véhicule automobile et/ou prises en compte directement pour commander des actionneurs du véhicule automobile tels qu’un dispositif de freinage d’urgence.

En pratique, la caméra capture plusieurs images successivement, et délivre ainsi un flux d’images successives. Deux de ces images, capturées l’une à la suite de l’autre, sont alors séparées au cours du temps par une période de répétition donnée, comprise par exemple entre 10 et 100 millisecondes.

Comme les informations obtenues par traitement de ces images sont utilisées dans un algorithme d’aide à la conduite, il est bien sûr souhaitable que ce traitement soit réalisé « en temps réel ». Pour cela, la puissance de calcul de l’unité de traitement doit être suffisante pour traiter les images capturées au fur et à mesure qu’elles sont délivrées par la caméra.

Pour obtenir une vitesse de traitement suffisante, il est connu de répartir les opérations nécessaires au traitement d’une image entre plusieurs processeurs de l’unité de traitement électronique, afin d’effectuer ces opérations en parallèle les unes des autres. L’algorithme d’aide à la conduite, destiné à être exécuté ainsi en parallèle, est alors scindé en plusieurs processus élémentaires. Chaque processus élémentaire est codé sous la forme d’un élément de code, et l’un des processeurs de l’unité de traitement est choisi pour exécuter cet élément de code. Cette répartition de l’algorithme à exécuter, entre les différents processeurs de l’unité de traitement, est parfois désignée dans la littérature spécialisée par le terme anglo-saxon de « mapping », ou « mise en correspondance ».

Avant d’installer une telle unité de traitement électronique dans un véhicule automobile, il est important de déterminer si elle pourra effectivement exécuter en temps réel l’algorithme d’aide à la conduite considéré.

Par ailleurs, les éléments de code correspondant à cet algorithme peuvent en général être répartis de plusieurs manières différentes au sein des processeurs de l’unité de traitement. Il est alors intéressant de déterminer lequel de ces modes de répartition (c’est-à-dire lequel de ces « mappings ») conduit à l’exécution de l’algorithme la plus rapide.

Il est alors connu : - pour chaque élément de code, de mesurer son temps d’exécution par le processeur auquel il a été attribué, puis - pour chaque processeur, d’estimer la durée nécessaire pour que ce processeur exécute l’ensemble des éléments de code qui lui sont attribués, et enfin - de déterminer que l’algorithme d’aide à la conduite peut être exécuté en temps réel par l’unité de traitement électronique, en vérifiant que chacune des durées estimées précédemment est inférieure à la période de répétition précitée.

Mais cette approche ne donne qu’une image partielle de la capacité de l’unité de traitement électronique à exécuter l’algorithme d’aide à la conduite en temps réel, et la fiabilité de cette approche reste limitée, notamment parce que le temps d’exécution de chaque élément de code n’est pas connu avec une parfaite précision et/ou parce que sa valeur peut fluctuer légèrement.

Objet de l’invention

Afin de remédier aux inconvénients précités de l’état de la technique, la présente invention propose une méthode de détermination d’une performance temporelle d’une unité de traitement électronique exécutant un algorithme donné, - l’unité de traitement comprenant plusieurs processeurs, - l’algorithme étant configuré pour traiter successivement plusieurs données représentatives chacune d’une image, deux desdites données étant fournies successivement en entrée de l’unité de traitement en étant séparées temporeilement par une période de répétition donnée, - l’algorithme étant mis en œuvre en exécutant, pour chacune de ces données, une pluralité d’éléments de code, - l’exécution de chaque élément de code étant attribuée à l’un desdits processeurs, conformément à un mode de répartition donné.

Selon l’invention, la méthode comprend une détermination d’une valeur d’une fonction de coût globale représentative de ladite performance temporelle, au moyen des étapes suivantes : - pour chacun desdits processeurs : - détermination d’une durée totale d’exécution de l’ensemble des éléments de code attribués à ce processeur, puis - détermination de la valeur d’une fonction de coût individuelle associée à ce processeur en fonction de l’écart entre ladite période de répétition et ladite durée totale d’exécution, et - détermination de la valeur de la fonction de coût globale en fonction des valeurs de chacune desdites fonctions de coût individuelles.

Pour traiter en temps réel le flux des données entrant successivement dans l’unité de traitement, il est nécessaire, pour chacun des processeurs, que la durée totale d’exécution de l’ensemble des éléments de code attribués à ce processeur soit (pour chaque donnée entrante) inférieure à la période de répétition.

Comme la valeur de la fonction de coût individuelle associée à ce processeur dépend de l’écart entre la période de répétition et la durée totale d’exécution correspondante, la valeur de la fonction de coût globale représente de manière avantageusement concise, et pour l’ensemble des processeurs, la marge disponible, en termes de durée d’exécution, par rapport à une limite au-delà de la laquelle un traitement en temps réel n’est plus assuré (cette limite correspond à la période de répétition).

Par ailleurs, la valeur de la fonction de coût globale dépend directement de la vitesse d’exécution de l’algorithme par la l’unité de traitement.

La valeur de la fonction de coût globale est donc représentative de la performance globale obtenue, en termes de temps d’exécution, avec cette unité de traitement électronique, tout en permettant de détecter individuellement, pour chaque processeur, si celui-ci est proche de sa limite de charge (au-delà de laquelle un traitement en temps réel n’est plus assuré).

De plus, une telle fonction de coût globale permet de traduire de manière continue la marge disponible entre la période de répétition et chacune des durées totales d’exécution, ce qui est particulièrement intéressant car les valeurs des temps d’exécution des différents éléments de code ne sont en général pas connues avec une précision parfaite.

La valeur de cette fonction de coût globale permet en particulier d’estimer le caractère exécutable en temps réel de l’algorithme de manière plus fiable qu’une comparaison directe de la période de répétition T avec chacune des durées totales d’exécution, qui délivrait un résultat booléen du type tout ou rien.

Par ailleurs, le calcul de la valeur de la fonction de coût globale ne nécessite qu’un nombre d’opérations numériques limité, et peut donc être réalisé même avec des ressources de calcul restreintes.

Une optimisation ultérieure du mode de répartition des différents processus élémentaires, dans les processeurs de l’unité de traitement, peut donc être réalisée efficacement sur la base de la valeur de la fonction de coût globale.

Dans un mode de réalisation particulier de la méthode de détermination selon l’invention, la valeur de chaque fonction de coût individuelle augmente lorsque la durée totale d’exécution associée à cette fonction s’approche, par valeurs inférieures, de ladite période de répétition. Dans ce mode de réalisation, la valeur de la fonction de coût globale est d’autant plus grande que chacune des valeurs des fonctions de coût individuelles est grande

La valeur de la fonction de coût globale augmente alors lorsque l’une quelconque de ces durées totales d’exécution s’approche de la période de répétition. Dans ce cas, la valeur de la fonction de coût globale est par ailleurs d’autant plus petite que l’exécution de l’algorithme par l’unité de traitement est rapide.

On comprend toutefois que l’invention pourrait être mise en œuvre de manière équivalente en utilisant plutôt des fonctions de coût individuelles qui soient chacune une fonction décroissante de la durée totale d’exécution correspondante. Dans ce cas, une valeur élevée de la fonction de coût globale serait représentative, au contraire, d’une exécution rapide de l’algorithme, réalisable en temps réel, tandis qu’une valeur faible de la fonction de coût globale permettrait de détecter que l’un des processeurs est en limite de charge. D’autres caractéristiques non limitatives et avantageuses de la méthode de détermination conforme à l’invention sont les suivantes : - l’une au moins desdites fonctions de coût individuelles est une fonction croissante et concave de la durée totale d’exécution associée à cette fonction de coût individuelle ; - l’une au moins desdites fonctions de coût individuelles diverge lorsque la durée totale d’exécution associée à cette fonction de coût individuelle tend vers la période de répétition ou dépasse la période de répétition ; - il est prévu de déterminer une valeur d’un temps de latence, égal à l’écart temporel entre le début et la fin du traitement de l’une desdites données par ledit algorithme, et la valeur de la fonction de coût globale diverge lorsque ledit temps de latence tend vers un seuil de temps de latence préalablement spécifié, ou dépasse ce seuil de temps de latence ; - ledit algorithme est configuré pour qu’un résultat du traitement d’une première desdites données soit pris en compte pour traiter une deuxième desdites données reçue ultérieurement par l’unité de traitement, et dans lequel ladite valeur du temps de latence est déterminée en tenant compte d’une durée liée à la prise en compte de ladite première donnée ; - le traitement de l’une desdites données au moyen dudit algorithme débutant par l’un desdits éléments de code, d’entrée, et se terminant par l’un desdits éléments de code, de sortie, le temps de latence est déterminé au moyen des étapes suivantes : - détermination de chaque chemin d’exécution menant dudit élément de code, d’entrée, audit élément de code, de sortie, - pour chacun desdits chemins d’exécution, détermination d’un temps de parcours associé, - détermination du temps de latence en fonction du plus grand desdits temps de parcours ; - le temps de latence est déterminé en fonction de temps d’exécution associés chacun à l’un desdits éléments de code, et en fonction d’un ou plusieurs délais associés chacun à un transfert de données réalisé au cours dudit algorithme, entre deux desdits processeurs ; - chaque durée totale d’exécution est déterminée en fonction du temps d’exécution desdits éléments de code, chaque temps d’exécution étant défini sous la forme d’un intervalle de confiance délimité par une valeur minimale et une valeur maximale de ce temps d’exécution, et dans laquelle les valeurs des fonctions de coût individuelles sont déterminées en fonction de valeurs moyennes définies par lesdits intervalles de confiance.

On peut prévoir par ailleurs, dans ladite méthode de détermination, de : - déterminer une valeur maximale de chaque durée totale d’exécution, sur la base des valeurs maximales desdits temps d’exécution, - si l’une au moins des valeurs maximales des durées totales d’exécution est supérieure à la période de répétition, déterminer la valeur de la fonction coût globale en fonction des valeurs des fonctions de coût individuelles, ou - sinon, affecter la valeur nulle à la fonction de coût globale.

On peut prévoir aussi, dans ladite méthode de détermination de : - déterminer une valeur minimale de chaque durée totale d’exécution, sur la base des valeurs minimales desdits temps d’exécution, - si les valeurs minimales des durées totales d’exécution sont chacune inférieure à la période de répétition, déterminer la valeur de la fonction coût globale en fonction des valeurs des fonctions de coût individuelles, ou - sinon, affecter une valeur infinie à la valeur de la fonction de coût globale. L’invention propose également une méthode de sélection d’un mode de répartition d’éléments de code d’un algorithme de traitement de données entre plusieurs processeurs d’une unité de traitement électronique, parmi plusieurs tels modes de répartitions distincts, dans laquelle : - pour chaque mode de répartition, une valeur d’une fonction de coût globale est déterminée au moyen d’une méthode de détermination telle que décrite ci-dessus, et dans laquelle - l’un des modes de répartition est sélectionné sur la base desdites valeurs de la fonction de coût globale. L’invention propose aussi une méthode de sélection d’une unité de traitement électronique destinée à exécuter un algorithme, parmi plusieurs unités de traitement électronique, chaque unité de traitement comprenant plusieurs processeurs, l’algorithme étant mis en œuvre en exécutant plusieurs éléments de code, dans laquelle il est prévu : - pour chaque unité de traitement, de mettre en œuvre une méthode de sélection telle que décrite ci-dessus, et d’attribuer à l’unité de traitement la valeur de la fonction de coût globale correspondant au mode de répartition ainsi sélectionné, puis - de sélectionner l’une desdites unités de traitement en fonction au moins des valeurs de fonction de coût globale attribuées à chaque unité de traitement.

Description detaillee d’un exemple de réalisation

La description qui va suivre en regard des dessins annexés, donnés à titre d’exemples non limitatifs, fera bien comprendre en quoi consiste l’invention et comment elle peut être réalisée.

Sur les dessins annexés : - la figure 1 représente schématiquement l’exécution, au cours du temps, de différents éléments de code par des processeurs d’une unité de traitement électronique, - la figure 2 représente schématiquement, sous la forme d’un graphe, un algorithme de traitement de données formé des éléments de code de la figure 1, - la figure 3 représente schématiquement un autre exemple d’algorithme de traitement de données, - la figure 4 représente schématiquement l’évolution de la valeur d’une fonction de coût individuelle, associée à l’un des processeurs de l’unité de traitement électronique, en fonction d’une durée totale d’exécution d’un ensemble d’éléments de code, par ce processeur, et - la figure 5 représente schématiquement, sous la forme d’un organigramme, une méthode de sélection d’un mode de répartition d’éléments de code à exécuter, entre plusieurs processeurs de l’unité de traitement électronique.

Dans cet exposé, un exemple de réalisation d’une méthode de détermination d’une performance temporelle d’une unité de traitement électronique exécutant un algorithme donné sera décrit dans un premier temps en référence aux figures 1 à 4.

Une méthode associée de sélection d’un mode de répartition d’éléments de code à exécuter, entre plusieurs processeurs de l’unité de traitement électronique (figure 5), ainsi qu’une méthode de sélection d’une unité de traitement électronique parmi plusieurs telles unités, seront décrites ensuite.

Implémentation matérielle de l’algorithme L’unité de traitement électronique, dont on souhaite évaluer les performances en termes de temps de calcul, comprend plusieurs processeurs pui, pu2, pux, adaptés chacun à réaliser des opérations portant sur des données numériques. L’unité de traitement électronique, désignée plus simplement dans la suite par l’expression « unité de traitement », peut comprendre en outre une ou plusieurs mémoires électroniques, et un ou plusieurs périphériques d’interface. L’unité de traitement est ici intégrée sur une même puce électronique (on parle alors de système sur puce, ou SoC, selon l’acronyme anglo-saxon de « System-on-Chip »). L’algorithme, destiné à être exécuté par l’unité de traitement, est configuré pour traiter successivement plusieurs données D-ι, D2, Dn représentatives chacune d’une image. En pratique, ces images sont capturées successivement par une caméra vidéo, et transmises au fur et à mesure de leur capture à l’unité de traitement.

Lesdites données D1t D2, Dn sont fournies en entrée de l’unité de traitement en étant séparées deux à deux, au cours du temps, par une période de répétition T donnée (figure 1). La période de répétition correspond à la durée séparant deux captures d’images successives par la caméra vidéo.

La période de répétition T peut par exemple être comprise entre 10 et 100 millisecondes. Pour une capture d’images à un taux de 30 images par seconde, par exemple, la période de répétition T est égale à 33 millisecondes environ.

Ici, les images traitées sont plus précisément représentatives d’un environnement routier dans lequel circule un véhicule automobile muni de la caméra vidéo et de l’unité de traitement mentionnées ci-dessus. Ces images pourraient aussi comprendre des images d’un conducteur du véhicule. L’algorithme est adapté, ici, à extraire de ces images des informations relatives à cet environnement routier, à des fins d’aide à la conduite du véhicule. Il peut d’ailleurs être prévu, au cours de cet algorithme, de mettre en œuvre des fonctionnalités d’aide à la conduite, telles par exemple que des fonctionnalités de freinage d’urgence, de régulation de vitesse, ou d’alerte du conducteur, exécutées sur la base des informations extraites des images traitées. L’algorithme est configuré pour traiter chacune desdites données Di, D2, ..., Dn au moyen d’un même procédé de base dont l’exécution est répétée pour chacune desdites données.

Ce procédé de base est formé d’une pluralité de processus élémentaires, qu’il est prévu d’exécuter en série et/ou en parallèle.

Chacun de ces processus élémentaires est représenté, c’est-à-dire codé, par un élément de code k-ι, k2, ..., k,, pour pouvoir être exécuté par l’unité de traitement. Cet élément de code (parfois désigné dans la littérature spécialisée par le terme anglo-saxon « kernel », c’est-à-dire « noyau ») peut être écrit notamment en langage C, en pseudo-code, ou encore en langage machine.

Un tel processus élémentaire peut par exemple correspondre à une correction de distorsion de l’image, à un calcul de gradient vertical ou horizontal, à un calcul de gradient d’orientation, ou encore à une classification d’éléments remarquables présents dans l’image, par exemple sur la base de résultats obtenus précédemment par calcul de gradients.

Les figures 1 et 3 illustrent schématiquement, pour un exemple d’algorithme tel que décrit ci-dessus, la manière dont le procédé de base se décompose en processus élémentaires qui s’enchaînent les uns avec les autres. L’exécution de chacun desdits éléments de code est attribuée à l’un des processeurs pui, pu2, ..., pux de l’unité de traitement, conformément à un mode de répartition M, donné (ce mode de répartition étant parfois désigné dans la littérature spécialisée par le terme anglo-saxon de « mapping »).

Un tel mode de répartition M, associe de manière univoque l’un des processeurs de l’unité de traitement à chacun des éléments de code à exécuter, et caractérise ainsi une implémentation matérielle donnée de l’algorithme dans l’unité de traitement.

La figure 1 représente l’exécution, au cours du temps t, des différents éléments de code k-ι, k2, k3, k4 et k5 associés à l’exemple de l’algorithme considéré.

Les traitements des données D-ι, D2, ..., Dn débutent respectivement aux instants t1, t2, t3, ..., ces instants étant séparés deux à deux par la période de répétition T.

Comme représenté, le traitement de chaque donnée D-ι, D2, ..., Dn est réalisé, dans cet exemple, en exécutant les éléments de code ki à k5 selon la séquence suivante : - ki puis k2 au moyen de l’un des processeurs pui de l’unité de traitement, - k3 puis k4 puis k5 au moyen d’un autre des processeurs pu2 de l’unité de traitement, les éléments de codes k2 et k3 étant exécutés en parallèle, c’est-à-dire qu’ils sont au moins en partie exécutés à un même instant.

Comme le traitement des données D-ι, D2, ..., Dn capturées par la caméra vise à en extraire des informations relatives à l’environnement routier, à des fins d’aide à la conduite, il est souhaitable : - que ces données Di, D2, ..., Dn soient traitées au fur et à mesure de leur capture, ce qui impose un taux de répétition minimal à l’unité de traitement (égal à l’inverse de la période de répétition T) ; autrement formulé, il faut que chaque processeur puisse exécuter l’ensemble des éléments de code qui lui sont attribués en une durée qui est inférieure à la période de répétition T, - mais aussi que la durée nécessaire pour traiter entièrement l’une des données, appelée « temps de latence » (tp sur la figure 1), soit aussi petite que possible, et en particulier inférieure à un temps de réaction typique d’un individu.

Le temps de latence tp correspond plus précisément à l’écart temporel entre (figure 1 ) : - l’instant t1, t2, t3, ... auquel le traitement de l’une des données D-ι, D2, ..., Dn débute, et - l’instant t1f, t2f, t3f, ... auquel le résultat du traitement de cette donnée est disponible, ce résultat pouvant correspondre notamment aux informations extraites de cette données, et/ou à une commande à destination d’un dispositif d’aide à la conduite.

La méthode de détermination de la performance temporelle de l’unité de traitement considérée vise notamment à déterminer si l’implémentation matérielle de l’algorithme dans cette unité de traitement permettra d’obtenir une exécution en temps réel de cet algorithme, c’est-à-dire si les deux contraintes mentionnées ci-dessus pourront être respectées.

La manière dont est prise en compte la contrainte associée au taux de répétition sera examinée dans un premier temps. La contrainte associée au temps de latence sera quant à elle examinée dans un second temps.

Contrainte associée au taux de répétition

Comme illustré sur la figure 1, pour obtenir un traitement des différentes données D-ι, D2, Dn au fur et à mesure de leur réception par l’unité de traitement, il est nécessaire que, à chaque exécution du procédé de base (c’est-à-dire pour chaque image à traiter), chaque processeur exécute l’ensemble des éléments de codes qui lui sont attribués en un temps inférieur à la période de répétition T.

Autrement formulé, pour obtenir une exécution en temps réel de l’algorithme, il est nécessaire, pour chacun des processeurs pu-ι, pu2, ...pux, que, à chaque exécution du procédé de base, la durée totale d’exécution tpui, tpU2, ... tpux de l’ensemble des éléments de code attribués à ce processeur soit inférieure à la période de répétition T.

Par exemple, dans le cas de la figure 1, pour obtenir une exécution en temps réel de l’algorithme, il est nécessaire que : - la durée totale d’exécution des éléments de code ki et k2 par le processeur pu1; notée tpu1, soit inférieure à la période de répétition T, et que - la durée totale d’exécution des éléments de code k3, k4 et k5 par le processeur pu2, notée tpu2, soit elle aussi inférieure à la période de répétition T.

Selon une caractéristique particulièrement remarquable de la méthode de détermination de la performance temporelle de l’unité de traitement exécutant l’algorithme précité, il est prévu de déterminer une valeur d’une fonction de coût globale .3^ représentative de ladite performance temporelle, au moyen des étapes suivantes : a) pour chacun desdits processeurs pu-ι, pu2, ... pux , détermination de la durée totale d’exécution tpux, par ce processeur, de l’ensemble des éléments de code k-ι, k2, ...k, qui lui sont attribués, b) pour chacun desdits processeurs pu-ι, pu2, ... pux, détermination de la valeur d’une fonction de coût individuelle pux, T) associée à ce processeur pux, en fonction de l’écart entre ladite période de répétition T et la durée totale d’exécution tpu1, tpu2, ... tpux associée à ce processeur, et c) détermination de la valeur de la fonction de coût globale en fonction des valeurs de chacune desdites fonctions de coût individuelles.

La valeur de la fonction de coût globale dépend directement de la vitesse d’exécution de l’algorithme par l’unité de traitement.

La valeur de la fonction de coût globale représente ainsi de manière concise la performance globale obtenue, en termes de temps d’exécution, avec cette unité de traitement, tout en permettant de détecter, pour chacun des processeurs pu-ι, pu2, ..., pux, si celui-ci est proche, en termes de charge de calcul, d’une limite au-delà de la laquelle un traitement en temps réel n’est plus assuré.

Ici, chaque fonction de coût individuelle //(M,, pux, T) est plus précisément une fonction croissante de la durée totale d’exécution tpu1, tpu2, ... tpux associée à cette fonction, et la valeur de la fonction de coût globale cFest d’autant plus grande que chacune des valeurs des fonctions de coût individuelles /r(Mj, pux, T) est grande. A l’étape a), la durée totale d’exécution tpuxde l’ensemble des éléments de code ki, k2, ...k, attribués au processeur pux est déterminée conformément à la formule F1 suivante :

(F1) dans laquelle la somme porte sur l’ensemble des éléments de code k-i, k2, ...kj attribués au processeur pux, notés kj|x .

Les valeurs des temps d’exécution τ1; τ2 , ..., τέ intervenant dans ce calcul sont connues, du fait qu’elles ont été mesurées ou estimées préalablement.

Toutefois, en pratique, une incertitude peut subsister quant aux valeurs de ces temps d’exécution τ±, τ2 , ..., τέ, du fait d’incertitudes de mesure ou de détermination et/ou du fait de fluctuations éventuelles de ces temps d’exécution au cours du temps.

En particulier, la mesure ou l’estimation préalable de l’un de ces temps d’exécution τέ peut montrer que la valeur de ce temps d’exécution est comprise

dans une plage de confiance [τί7ηίη ; Timax], appelée aussi intervalle de confiance, délimitée par une valeur minimale iimin du temps d’exécution τέ, et par une valeur maximale Timax de ce temps d’exécution. Dans un tel cas, la valeur du temps d’exécution τέ prise en compte pour calculer la durée totale d’exécution tpux peut par exemple être correspondre au milieu, c’est-à-dire à la valeur moyenne, de cette plage de confiance.

Quoi qu’il en soit, les valeurs des durées totales d’exécution tpui, tpU2,..., tpux ne sont en général connues qu’avec une précision limitée, du fait de ces incertitudes relatives aux valeur des temps d’exécution Tlt τ2 , ..., τέ.

Il est donc intéressant que la fonction de coût globale traduise ainsi de manière continue la marge disponible entre la période de répétition T et chacune des durées totales d’exécution tpui, tpU2,·, tpux.. En particulier, pour déterminer que l’algorithme peut être exécuté en temps réel par l’unité de traitement, il est plus fiable de se baser sur la valeur de la fonction globale (continue), que de se baser seulement sur un résultat booléen du type tout ou rien qui serait obtenu en comparant directement la période de répétition T avec une valeur moyenne de chacune des durées totales d’exécution.

Comme déjà indiqué, chaque fonction de coût individuelle /r(Mj, pux, T) est ici une fonction croissante de la durée totale d’exécution tpux associée à cette fonction.

Chaque fonction de coût individuelle /r(Mj, pux, T) est par ailleurs une fonction concave de la durée totale d’exécution tpux. La croissance de cette fonction de coût individuelle est ainsi d’autant plus forte que la durée totale d’exécution tpux est proche de la période de répétition T. Cette disposition permet de détecter encore plus efficacement, sur la base de la valeur de la fonction de coût globale, que l’un des processeurs est proche de sa limite de charge.

De plus, ici, chaque fonction de coût individuelle /Γ(Μ,, pux, T) diverge, c’est-à-dire tend vers l’infini, lorsque la durée totale d’exécution tpux associée tend vers la période de répétition T ou la dépasse. En pratique, une valeur infinie ici, par exemple, à la plus grande valeur numérique pouvant être manipulée par un ordinateur chargé du calcul des fonctions de coûts. A nouveau, cette disposition favorise la détection du fait que l’une des durées totales d’exécution s’approche la limite correspondant à la période de répétition T, que l’on souhaite ne pas dépasser.

Plus précisément la valeur de chaque fonction de coût individuelle est calculée ici, à l’étape b, conformément à la formule F2 suivante :

(F2) où le coefficient βΓ est positif.

La fonction de coût individuelle //(M,, pux, T) est tracée sur la figure 4, en fonction de la durée totale d’exécution tpux, pour trois valeurs différentes du coefficient βΓ (en l’occurrence pour βΓ = 0,1, pour βΓ = 0,5 et pour βΓ = 2).

Comme on peut le voir sur cette figure, la croissance de la fonction de coût individuelle fr(M\, pux, T) à l’approche de la période de répétition T est d’autant plus abrupte que la valeur du coefficient βΓ est petite. Le coefficient βΓ permet ainsi, par un ajustement de sa valeur, de choisir une croissance plus ou moins progressive de la fonction de coût individuelle fr(M\, pux, T) au voisinage de la période de répétition T.

En variante, la fonction de coût individuelle de la formule F2 pourrait bien sûr être remplacée par une fonction différente et présentant néanmoins les caractéristiques utiles mentionnées ci-dessus (croissance, concavité, divergence à l’approche de la période de répétition). A titre d’exemple, une fonction f telle que définie par la formule F3 pourrait par exemple être utilisée à la place de celle de la formule F2 :

(F3)

Dans une autre variante, on pourrait prévoir que chaque fonction de coût individuelle soit égale à la durée totale d’exécution des éléments de code mis en œuvre par le processeur associé.

On notera que, comme suggéré par la notation //(M,, pux, T), cette fonction de coût individuelle dépend du mode de répartition M, considéré. En effet, le fait d’attribuer l’élément de code kj à l’un ou à l’autre des processeur pui, pU2, pux de l’unité de traitement influe directement sur la valeur du temps d’exécution τέ de cet élément de code, et donc sur la valeur de la durée totale d’exécution tpux.

La valeur de chaque fonction de coût individuelle dépend bien sûr aussi de l’unité de traitement qui exécute l’algorithme, puisque les valeurs des temps d’exécution τ1; τ2, ..., τέ dépendent des caractéristiques (type de processeurs utilisés, bande passante des mémoires, ...) de cette unité de traitement.

Ici, la valeur de la fonction de coût globale est déterminée, à l’étape ç), en fonction de la somme des valeurs des fonctions de coût individuelles déterminées à l’étape b).

La fonction de coût globale J*" est plus précisément égale, ici, à la somme des fonctions de coût individuelles, et d’une ou plusieurs fonctions de coût additionnelles f (M,, dtspec, T) :

Dans la formule F4 ci-dessus, la première somme porte sur l’ensemble des processeurs pu1, pu2, ..., pux de l’unité de traitement. La deuxième somme porte quant à elle sur un ensemble {dtspec} d’une ou plusieurs contraintes temporelles additionnelles, liées à l’exécution de l’algorithme par l’unité de traitement. En particulier, l’une de ces contraintes temporelles additionnelles peut correspondre au fait qu’un seuil limite, à ne pas dépasser, ait été spécifiée pour le temps de latence. Ainsi, si le seuil limite est dépassé, la fonction de coût globale .y présentera par exemple une valeur très élevée.

En variante, la fonction de coût globale jF” pourrait s’exprimer différemment, en fonction des fonctions de coût individuelles, par exemple sous la forme d’une somme des carrés de ces fonctions de coût individuelles.

En variante encore, les fonctions de coûts additionnelles mentionnées ci-dessus pourraient être omises, la fonction de coût globale dépendant alors seulement des fonctions de coût individuelles.

Contrainte associée au temps de latence

Il est prévu ici, dans ladite méthode de détermination, de déterminer une valeur du temps de latence tp, et, comme indiqué ci-dessus de prendre en compte cette valeur dans le calcul de valeur de la fonction de coût globale .y.

Afin notamment de déterminer la valeur du temps de latence tp, l’algorithme est représenté sous la forme d’un graphe, comme illustré sur la figure 2.

Sur ce graphe, chacun des éléments de code k-ι, k2, ...k5 mentionnés précédemment correspond à un sommet du graphe. Ces sommets sont reliés entre eux de manière à représenter les dépendances de ces éléments de codes les uns par rapport aux autres. Ce graphe est plus précisément un graphe orienté, et sans boucle.

Sur ce graphe, un arc relie deux éléments de code k, et kj lorsque que des données, obtenues ou modifiées en exécutant l’élément de code kj, doivent être disponibles pour pouvoir exécuter ensuite l’élément de code kj. Cet arc est orienté de l’élément de code kj vers l’élément de code kj. Le temps de transfert de ces données est représenté par un délai ôjj, associé cet arc.

En particulier, lorsque l’élément de code kj est exécuté par l’un des processeurs de l’unité de traitement, tandis que l’élément de code kj est exécuté par un autre de ces processeurs, on comprend qu’un certain temps, correspondant au délai ôjj, est nécessaire pour transférer les données précitées de l’un à l’autre de ces processeurs. L’exécution de l’élément de code kj ne peut débuter, en pratique, que lorsque : - tous les éléments de codes antécédents de l’élément de code kj ont été exécutés, et que - les données obtenues ou modifiées en exécutant ces éléments de code antécédents ont été transférées, de manière à pouvoir être utilisées par l’élément de code kj.

Les éléments de code antécédents de l’élément de code kj sont les éléments de code depuis lesquels part un arc aboutissant à l’élément de code kj.

Le ou les éléments de code d’entrée du graphe, c’est-à-dire ceux par lesquels débute le traitement de la donnée D-ι, D2, Dn, correspondent à l’élément de code, ou aux éléments de code sans antécédents.

Le ou les éléments de code de sortie du graphe, c’est-à-dire ceux par lesquels s’achève le traitement de la donnée D-ι, D2, Dn, sont les éléments de code de l’algorithme depuis lesquels aucun arc ne part.

Par exemple, pour l’algorithme correspondant au graphe de la figure 2, qui est le même algorithme que celui de la figure 1, le traitement de l’une des données Di, D2, Dn débute par l’exécution de l’élément de code k-ι, et se termine après l’exécution de l’élément de code k5.

La valeur du temps de latence tp est déterminée, sur la base du graphe représentant l’algorithme, au moyen des étapes suivantes : - détermination de tous les chemins d’exécution ^m;q menant, sur le graphe, de l’un des élément de code k| d’entrée du graphe, à l’un des éléments de code km de sortie du graphe, - pour chaque chemin d’exécution ;q, détermination du temps de parcours t ^(l, m ; q), nécessaire pour exécuter la suite d’éléments de code formant ce chemin d’exécution (délais de transfert inclus), et - détermination du temps de latence tp en fonction du plus grand desdits temps de parcours t^(l, m ; q ).

Ici, le temps de latence tp est déterminé plus précisément comme étant égal au plus grand desdits temps de parcours t.^(1, m ; q ).

Dans le cas de la figure 2, par exemple, il existe trois chemins d’exécution ^1,5 ;i , ^j5;2 et ^1,5 ;3 qui mènent chacun, sur le graphe de l’algorithme, de l’élément de code k-ι, d’entrée, à l’élément de code k5, de sortie. Le chemin d’exécution . 3 , par exemple, comprend les éléments de code k1; k3 et k5, et le temps de parcours V(l, 5 ; 3) associé à ce chemin d’exécution est donné par la formule suivante :

Plus généralement, le temps de parcours t,^(l, m ; q) correspondant au chemin d’exécution ;q est déterminé conformément à la formule F5 suivante :

Comme indiqué ci-dessus, les valeurs des temps de parcours U?(l, m ; q) sont calculées pour tous les chemins d’exécution ^Î.m ;q possibles, c’est-à-dire pour : - toutes les valeurs de l’indice I, qui repère le ou les éléments de code d’entrée du graphe, - toutes les valeurs de l’indice m, qui repère le ou les éléments de code de sortie du graphe, et - pour chaque couple donné (I, m) d’éléments de code d’entrée et de sortie, pour toutes les valeurs de l’indice q qui repère les différents chemins d’exécution menant de l’élément de code ki à l’élément de code km.

Le temps de latence tp est ensuite déterminé conformément à la formule F6 suivante :

Cette technique de détermination du temps de latence tp est particulièrement efficace en termes de temps de calcul. En effet, pour chaque chemin d’exécution, le calcul du temps de parcours correspondant est réalisé sans avoir à tenir compte de l’intégralité des dépendances entre éléments de code : seules les dépendances correspondant aux arcs appartenant à ce chemin d’exécution sont prises en compte. L’influence, sur le temps de latence, de dépendances multiples entre éléments de code, est prise en compte ensuite en sélectionnant le plus grand des temps de parcours, ce qui ne nécessite qu’un nombre d’opérations limitées.

Le temps de latence tp ainsi déterminé correspond au temps de latence qu’il est prévu d’obtenir avec l’unité de traitement considérée.

En pratique, on souhaite que ce temps de latence tp reste inférieur à un seuil de temps de latence dtspec, préalablement spécifié en fonction de l’algorithme considéré.

Pour un algorithme de détection de piéton et freinage d’urgence, une valeur du seuil de temps de latence dtspec comprise entre 1 et 100 millisecondes peut par exemple être spécifiée, tandis que pour un algorithme d’aide à la navigation (basé sur un système de navigation de type GPS par exemple), un temps de latence compris par exemple entre 0,2 et 1 seconde peut être considéré comme acceptable.

La marge disponible entre le seuil de temps de latence dtspec et le temps de latence tp est prise en compte par l’intermédiaire de l’une desdites fonctions de coût additionnelles /)(Μ,, dtspec, T), qui sera décrite en détail plus bas.

La technique de détermination du temps de latence tp qui vient d’être présentée peut s’appliquer plus généralement au cas où des éléments de code associés au traitement d’une donnée (c’est-à-dire ici d’une image) ne peuvent être exécutés qu’à l’aide de résultats obtenus en exécutant des éléments de code associés au traitement d’au moins une donnée précédente.

Par conséquent, avant de décrire cette fonction de coût additionnelle, nous décrivons tout d’abord comment la technique de détermination du temps de

latence tp, qui vient d’être présentée, s’applique à un algorithme dans lequel le résultat du traitement d’une desdites données D-ι, D2, Dn est pris en compte pour traiter la donnée suivante.

Un tel algorithme est d’usage courant en traitement d’images, en particulier pour suivre la position d’un élément de l’environnement au cours du temps. Ainsi, par exemple, lorsque l’élément de l’environnement a été repéré au niveau d’une position donnée d’une première image, il est intéressant, lors du traitement d’une deuxième image capturée juste après la première image, de commencer la recherche de cet élément au voisinage de ladite position (on parle alors de prise en compte de dépendances spatio-temporelles entre images capturées successivement).

Dans un tel algorithme, le traitement de la donnée Dn s’appuie donc sur le résultat du traitement de la donnée Dn-i capturée précédemment, et éventuellement aussi sur les résultats des traitements des données Dn.2, Dn_3, ... précédentes.

Un tel algorithme peut, de même que précédemment, être représenté par un graphe, orienté et sans boucle, comme illustré par la figure 3.

Ce graphe comprend alors une suite de plusieurs sous-graphes qui correspondent chacun au traitement d’une des données D-ι, D2, Dn reçues par l’unité de traitement.

On rappelle que chacune de ces données est traitée en exécutant le même procédé de base (ce procédé de base étant exécuté autant de fois qu’il y a de données à traiter). Chacun des sous-graphes correspond donc à une occurrence (c’est-à-dire à une répétition) d’un même sous-graphe de base, comparable au graphe décrit plus haut en référence à la figure 2, et assorti en outre d’un indice n. L’indice n repère les occurrences successives du procédé de base les unes par rapport aux autres. L’occurrence numéro n du sous graphe de base représente une suite d’éléments de code k(n)i, k(n)2, k(n)j, dont l’exécution permet de traiter la donnée Dn reçue par l’unité de traitement.

On comprend que, dans un tel algorithme, l’occurrence numéro n du sous-graphe de base est reliée à l’occurrence numéro n-1 précédente par un ou plusieurs arcs, de manière à traduire que les résultats du traitement de la donnée Dn-i sont pris en compte pour traiter la donnée Dn.

Un tel arc relie plus précisément l’un des éléments de code k(n"1)j de l’occurrence numéro n-1 , à l’un des éléments de code k(n)j de l’occurrence numéro n. Un délai ô*j est associé à cet arc. Le délai ô*j est représentatif d’un temps (éventuellement nul) nécessaire pour transférer des données, obtenues ou modifiées en exécutant l’élément de code k(n'1)j, nécessaires à l’exécution de l’élément de code k(n)j.

Dans le graphe qui représente ainsi l’algorithme, l’occurrence numéro n du sous-graphe de base est, comme expliqué ci-dessus, reliée à l’occurrence précédente numéro n-1. En revanche, l’occurrence numéro n n’est pas reliée directement aux occurrences antérieures à la précédente, c’est-à-dire qu’elle n’est pas reliée directement aux occurrences numéro n-2, n-3, ... (figure 3).

On notera toutefois qu’un algorithme, dans lequel les résultats obtenus lors des occurrences antérieures à la précédente (occurrences numéro n-2, n- з, ...) sont pris en compte à l’occurrence numéro n, peut être représenté au moyen d’un tel graphe. En effet, des résultats obtenus lors de l’exécution numéro n-2 du procédé de base se répercutent lors de l’exécution numéro n, puisque l’exécution numéro n est réalisée en tenant compte des résultats obtenus lors de l’exécution numéro n-1, qui eux-mêmes dépendent de ceux obtenus lors de l’exécution numéro n-2.

Le traitement de la donnée Dn peut ainsi dépendre de l’ensemble des résultats obtenus lors des traitements des données précédant la donnée Dn.

Toutefois, pour déterminer le temps de la latence tp, seule l’influence des résultats de traitement des données Dn-i, Dn-2, ·, Dn.u, sur le traitement de la donnée Dn, est pris en compte. Autrement formulé, seules les u données précédant immédiatement la donnée Dn sont prises en compte. Le nombre entier и, qui correspond à un niveau de récursivité pris en compte pour déterminer le temps de latence tp, est positif et constant. Il peut par exemple être compris entre 1 et 10.

Le temps de latence tp est alors déterminé en déterminant tout d’abord un temps de latence étendu tpe, qui correspond à l’écart temporel entre : - l’instant auquel débute le traitement de la donnée Dn.u, et - l’instant auquel le résultat du traitement de la donnée Dn est disponible.

Le temps de latence étendu tpe est alors déterminé, sur la base du graphe de l’algorithme (figure 3), par la même technique que ce qui a été décrit précédemment, si ce n’est que les chemins d’exécution m ;q;u considérés relient, sur le graphe : - l’un des éléments de code k(n'u)i d’entrée de l’occurrence numéro n-u du sous-graphe de base, à - l’un des éléments de code k(n)m de sortie de l’occurrence numéro n du sous-graphe de base,

Ainsi, pour chacun de ces chemins d’exécution ;q;u , un temps de parcours t ^(1, m ; q ; u) , nécessaire pour exécuter la suite d’éléments de code formant ce chemin d’exécution (délais de transfert inclus) est déterminé conformément à la formule F7 suivante :

où les entiers p et p’, appartient à l’intervalle [0 ; u], et où le délai ôjj peut notamment correspondre à l’un des délais ô*j mentionnés précédemment.

Le temps de latence étendu tpe est ensuite déterminé comme étant égal au plus grand desdits temps de parcours t^(l, m ; q ; u) :

Le temps de latence étendu tpe ainsi déterminé est égal à la somme du temps de latence tp et du produit de la période de répétition T multipliée par le nombre entier u.

En effet : - l’écart temporel entre le début du traitement de la donnée Dn.u et le début du traitement de la donnée Dn est égal à la période de répétition T multipliée par le nombre entier u, tandis que - l’écart temporel entre le début et la fin du traitement de la donnée Dn est égal, par définition, au temps de latence tp, donc :

Aussi est-il prévu ici, pour déterminer si le temps de latence tp est inférieur au seuil de temps de latence dtspec spécifié, de comparer directement le temps de latence étendu tpe à la quantité u.T + dtspec.

Pour une valeur de u très élevée, la comparaison du temps de latence étendu tpe avec la quantité u.T + dtspec se ramène quasiment à une vérification du

fait que la vitesse d’exécution de l’algorithme est compatible avec la valeur de la période de répétition T. Or la contrainte correspondant au taux répétition imposé à l’unité de traitement (égal à 1/T) est déjà prise en compte dans la fonction de coût globale ..T, par l’intermédiaire des fonctions de coût individuelles fr.

En conséquence, pour examiner plus spécifiquement si la vitesse d’exécution de l’algorithme est compatible avec le seuil de temps de latence dtspec souhaité, une valeur petite de l’entier u, par exemple égale à 1 ou 2, est choisie en pratique.

On notera que pour u=0 on retrouve une situation dans laquelle le traitement d’une des données Dn est effectué indépendamment des résultats issus des traitements des données précédentes, comme dans l’exemple de la figure 2.

Une fois que la valeur du temps de latence étendu tpe, ou que la valeur du temps de latence tp est déterminée, la valeur de la fonction de coût additionnelle ft correspondante est déterminée.

La valeur de cette fonction de coût additionnelle est ici une fonction croissante du temps de latence étendu tpe.

Plus précisément, cette fonction de coût additionnelle dépend ici du temps de latence étendu tpe, et du temps de latence étendu limite dtspec + u.T, de la même manière que la fonction de coût individuelle fr dépend de la durée totale d’exécution tpux, et de la période de répétition T. Ainsi, cette fonction de coût additionnelle s’exprime ici conformément à la formule F10 suivante :

(F10) où le coefficient βι est positif.

En particulier, la fonction de coût additionnelle fi définie ainsi diverge lorsque le temps de latence étendu tend vers la quantité dtspec + u.T, ou dépasse cette quantité, c’est-à-dire lorsque le temps de latence tp tend vers le seuil de temps de latence dtspec spécifié ou dépasse ce seuil.

La valeur du coefficient βι est choisie, comme celle du coefficient βΓ, de manière à ajuster le caractère plus ou moins abrupte de la croissance de la fonction de coût additionnelle avec le temps de latence étendu tpe.

En outre, ajuster les valeurs des coefficients βι et βΓ l’une par rapport à l’autre permet, dans la fonction de coût globale, d’ajuster les poids respectifs :

- de la fonction de coût additionnelle, qui reflète la contrainte liée au temps de latence, et - des fonctions de coût individuelles, qui reflètent la contrainte imposée par la période de répétition T.

La même fonction de coût additionnelle f peut bien sûr être utilisée pour un algorithme dans lequel chaque donnée D-ι, D2, ... Dn est traitée indépendamment des autres (comme pour l’exemple de la figure 2), ce qui correspond au cas u=0. Dans ce cas, le temps de latence étendu tpe est remplacé, dans la formule F10, par le temps de latence tp.

Intervalles de confiance associés aux temps d’exécution τ,, r,.....τ,·

Comme indiqué précédemment, en pratique, un intervalle de confiance [Ti,min> Ti,max] peut être associé au temps d’exécution τέ, plutôt qu’une unique valeur parfaitement déterminée.

Pour déterminer si l’algorithme peut être exécuté en temps réel par l’unité de traitement, il peut alors être intéressant, notamment pour accélérer cette détermination, de prendre en compte que le temps d’exécution τέ est, a priori, forcément inférieur à sa valeur maximale Timax , et forcément supérieur à sa valeur minimale Timin .

Pour cela, il est prévu ici : - de déterminer une valeur maximale tpui,max, tpu2, max, ... tpux, max, de chaque durée totale d’exécution tpu1, tpu2, ... tpux, ainsi qu’une valeur maximale tpemax du temps de latence étendu tpe, sur la base des valeurs maximales τίΐηαχ des temps d’exécution τέ, et, le cas échant, sur la base de valeurs maximales ^ij.max des délais ôy (délais de transfert), et - lorsque la valeur maximale tpemax du temps de latence étendu tpe est inférieure à la quantité dtspec+u.T , et que les valeurs maximales tpui,maX, tpu2, max, ... tpux, max des durées totales d’exécution sont chacune inférieure à la période de répétition T, de déterminer alors que l’algorithme pourra être exécuté en temps réel par l’unité de traitement, et d’attribuer, dans un premier temps, une valeur nulle à la fonction de coût globale.

En effet, dans une telle situation, il est certain que l’algorithme pourra être exécuté en temps réel, et d’ailleurs probablement avec une marge substantielle par rapport aux contraintes précitées.

Il est également prévu, ici : - de déterminer une valeur minimale tPui,mîn, tpu2, min, ... tpux, mjn, de chaque durée totale d’exécution tpui, tpu2, ... tpux, ainsi qu’une valeur minimale tpemjn du temps de latence étendu tpe, sur la base des valeurs minimales Timin des temps d’exécution -η, et, le cas échant, sur la base de valeurs minimales àijmin des délais ôjj, et - lorsque la valeur minimale tpemin du temps de latence étendu tpe est supérieure à la quantité dtspec+u.T , ou que l’une des valeurs minimales tpui,mîn, tpu2, min, tPuX, min des durées totales d’exécution est supérieure à la période de répétition T, de déterminer alors que l’algorithme ne pourra pas être exécuté en temps réel par l’unité de traitement, et d’attribuer une valeur infinie à la fonction de coût globale.

En effet, dans une telle situation, il est certain que l’algorithme ne pourra pas être exécuté en temps réel.

Dans l’une ou l’autre des deux situations décrites ci-dessus, on peut prévoir, pour une première évaluation de l’unité de traitement et/ou du mode de répartition considéré, d’omettre le calcul des fonctions de coût individuelles et additionnelle puisque le caractère exécutable en temps réel de l’algorithme a déjà pu être déterminé.

Les autres situations correspondent quant à elles à des cas pour lesquels : - la période de répétition T tombe dans l’un des intervalles de confiance [tpux, min ; tpux, max] associés aux durées totales d’exécution, ou pour lesquels - la quantité dtspec+u.T tombe dans l’intervalle de confiance [tpemin ; tpemax] associé au temps de latence étendu tpe.

Dans ces autres situations, une évaluation plus fine du caractère exécutable en temps réel de l’algorithme est alors réalisée, en calculant les valeurs de fonctions de coût individuelles et additionnelles, comme expliqué précédemment, pour en déduire ensuite la valeur de la fonction de coût globale.

On notera par ailleurs qu’il est utile, même lorsque la valeur maximale tpemax du temps de latence étendu tpe est inférieure à la quantité dtspec+u.T , et que les valeurs maximales Îpui,max, tpu2, max, ... tpux, max des durées totales d’exécution sont chacune inférieure à la période de répétition T, de déterminer à nouveau (dans un deuxième temps) la valeur de la fonction de coût globale, sur la base des valeurs des fonctions de coût individuelles et additionnelle, pour évaluer plus finement la performance temporelle de l’unité de traitement et/ou du mode de répartition considéré.

Mise en œuvre de ladite méthode de détermination

Comme cela ressort de la description ci-dessus, la mise en œuvre de cette méthode de détermination nécessite de réaliser plusieurs estimations de durées d’exécution, de manière systématique : plusieurs durées totales d’exécution doivent être calculées, et plusieurs chemins d’exécution doivent être caractérisés.

En pratique, cette méthode est donc mise en œuvre par un ordinateur, ces différentes estimations étant réalisées de manière automatisée.

La valeur de la fonction de coût globale TH obtenue par cette méthode peut ensuite être utilisée utilement pour comparer entre elles différentes manières de répartir les éléments de code de l’algorithme dans les processeurs de l’unité de traitement, comme expliqué ci-dessous. Méthode de sélection d’un mode de répartition desdits éléments de code entre les processeurs de l’unité de traitement

La figure 5 représente schématiquement, sous la forme d’un organigramme, une telle méthode de sélection, permettant de sélectionner, parmi plusieurs tels modes de répartition M,, celui conduisant à la meilleure performance temporelle.

Selon cette méthode, une valeur de la fonction de coût globale ,H est déterminée pour chacun des modes de répartition M,. L’un de ces modes de répartition est ensuite sélectionné sur la base desdites valeurs de la fonction de coût globale.

Ici, le mode de répartition sélectionné correspond plus précisément à celui desdits modes de répartition associé à la valeur de la fonction de coût globale la plus petite.

Dans le mode de réalisation décrit ici, la sélection du meilleur mode de répartition Mœst réalisée en deux étapes : - au cours d’une première étape E1, une première valeur de la fonction de coût globale est déterminée pour chaque mode de répartition M,, et, sur la base de ces premières valeurs, N modes de répartition M, sont présélectionnés, puis - au cours d’une deuxième étape E2, une deuxième valeur de la fonction de coût globale est déterminée, pour chacun des N modes de répartition M, présélectionnés à l’étape E1, sur la base de valeurs des durées totales d’exécution tPui, tPu2, tpUX évaluées plus précisément qu’à l’étape E1.

La première étape E1 consiste à réduire le nombre de modes de répartition M, à considérer, afin d’alléger les calculs.

Cette étape E1 comprend ici une étape E10, répétée pour chaque mode de répartition M,, au cours de laquelle la première valeur de la fonction de coût globale associée au mode de répartition M,, est déterminée.

Cette étape E10 est exécutée sur la base de valeurs des temps d’exécution τέ et des délais ôjj fournies sous la forme d’intervalles de confiance. La première valeur de la fonction de coût globale .H est ainsi déterminée, à l’étape E10, comme cela a été expliqué dans la section précédente relative aux intervalles de confiances associés aux temps d’exécution τ1; τ2 , ..., τν

Plus précisément, l’étape E10 comprend une première étape E11, au cours de laquelle les valeurs maximales et minimales des durées totales d’exécution tpu1, tpu2, ... tpux, et du temps de latence étendu tpe, sont déterminées. A l’étape E12, ces valeurs maximales et minimales sont comparées à la période de répétition T, et à la quantité dtspec+u.T.

Lorsque la valeur maximale tpemax du temps de latence étendu est inférieure à la quantité dtspec+u.T , et que les valeurs maximales tpui_max, tpu2, max, tpux, max des durées totales d’exécution sont chacune inférieure à la période de répétition T, alors, l’étape E12 est suivie par une étape E13 (flèche fl1 de la figure 5), au cours de laquelle il est déterminé que la première valeur de la fonction de coût globale est nulle.

Lorsque la valeur minimale tpemin du temps de latence étendu est supérieure à la quantité dtspec+u.T , ou que l’une des valeurs minimales tpui,min, tpu2, min, tpux, min des durées totales d’exécution est supérieure à la période de répétition T, alors, l’étape E12 est suivie par une étape E14 (flèche fl2 de la figure 5), au cours de laquelle il déterminé que la première valeur de la fonction de coût globale est infinie.

Dans les autres cas, l’étape E12 est suivie par une étape E15 (flèche f!3 de la figure 5), au cours de laquelle la première valeur de la fonction de coût globale est déterminée en calculant les valeurs des fonctions de coûts individuelles fr et de la fonction de coût additionnelle puis en les sommant. Les valeurs de ces fonctions de coût sont déterminées, à l’étape E15, sur la base des valeurs moyennes des temps d’exécution τέ et des délais ôy (milieux des intervalles de confiance).

Les N modes de répartitions M, présélectionnés à l’étape E1 correspondent alors aux modes de répartitions M, qui présentent les N premières valeurs de la fonction de coût globale ./T les plus petites. A l’étape E2, pour chacun des N modes de répartition M, présélectionnés, la manière d’implémenter ce mode de répartition est examinée plus en détail.

Plus précisément, pour le mode de répartition M, considéré, il est prévu, pour chaque processeur, de déterminer les modes d’exécution envisageables pour exécuter les éléments de code attribués à ce processeur.

En effet, si plusieurs éléments de code attribués à ce processeur sont indépendants les uns des autres, il peut être envisagé soit d’exécuter ces éléments de codes les uns à la suite des autres, soit de les exécuter en parallèle (par des techniques de découpage temporel, ou « time slicing », selon la dénomination anglo-saxonne).

La durée totale d’exécution de cet ensemble d’éléments de code peut alors être différente pour le mode d’exécution en parallèle, et pour le mode d’exécution en série.

Aussi est-il prévu, à l’étape E2, de déterminer une nouvelle valeur, plus précise, de chaque durée totale d’exécution tpui, tpU2, ... tpux, en tenant compte, s’il y a lieu, des différents modes d’exécution envisageables.

Une valeur de la fonction de coût globale est alors déterminée pour chaque mode d’exécution envisageable.

Le mode d’exécution associé à la plus petite valeur de la fonction de coût globale est alors conservé, et pour le mode de répartition considéré, on détermine alors que la deuxième valeur de la fonction de coût globale est celle correspondant au mode d’exécution ainsi retenu.

Le mode de répartition M, (et le mode d’exécution associé) finalement sélectionnés à l’issu de l’étape E2 est alors celui qui présente la plus petite des deuxième valeurs de la fonction de coût globale.

Présélectionner les N modes de répartition Mj les plus performants, avant de procéder, seulement pour ces modes de répartition, à une évaluation plus précise des performances attendues (à l’étape E2), permet de réduire le temps nécessaire pour exécuter cette méthode de sélection. Cette accélération est particulièrement appréciable car le nombre de mode de répartition M, à examiner peut être très élevé. Par exemple, pour une unité de traitement comprenant 5 processeurs, et pour un algorithme dont le procédé de base (employé pour traiter chaque image) est décomposé en 8 éléments de code, 58=390 625 modes de répartition M, doivent être examinés. Méthode de sélection d’une unité de traitement

La méthode de détermination décrite précédemment peut également être employée pour sélectionner, parmi plusieurs unités de traitement, celle conduisant à la meilleure performance. A cette fin, il est prévu, pour chaque unité de traitement, de : - déterminer, pour l’algorithme considéré, l’ensemble des modes de répartition envisageables, - sélectionner le meilleur de ces modes de répartition, c’est-à-dire ici celui associé à la valeur de la fonction de coût globale la plus petite, puis - d’attribuer à l’unité de traitement la valeur de la fonction de coût globale correspondant à ce meilleur mode de répartition.

La sélection du meilleur mode de répartition peut par exemple être réalisée au moyen de la méthode de sélection décrite à la section précédente.

Il est prévu ensuite de sélectionner l’unité de traitement présentant, parmi les différentes unités de traitement considérée, la valeur de la fonction coût globale la plus petite ou l’une des plus petites (d’autres facteurs peuvent en effet également être pris en compte, typiquement le coût de fabrication de l’unité de traitement, sa consommation électrique...).

Claims (12)

1. REVENDICATIONS

   1. Méthode de détermination d’une performance temporelle d’une unité de traitement électronique exécutant un algorithme donné, - l’unité de traitement comprenant plusieurs processeurs (pu-ι, pu2, ...pux), - l’algorithme étant configuré pour traiter successivement plusieurs données (D-ι, D2, ..., Dn) représentatives chacune d’une image, deux desdites données étant fournies successivement en entrée de l’unité de traitement en étant séparées temporellement par une période de répétition (T) donnée, - l’algorithme étant mis en œuvre en exécutant, pour chacune de ces données (Di, D2, Dn), une pluralité d’éléments décodé (ki, k2, ..., kj), - l’exécution de chaque élément de code (k-ι, k2, ..., kj) étant attribuée à l’un desdits processeurs (pu-ι, pu2, ...pux), conformément à un mode de répartition (Mj) donné, la méthode étant caractérisée en ce qu’elle comprend une détermination d’une valeur d’une fonction de coût globale (.Fj représentative de ladite performance temporelle, au moyen des étapes suivantes : - pour chacun desdits processeurs (pu-ι, pu2, ...pux) : - détermination d’une durée totale d’exécution (tpui, tpu2, ... tpux) de l’ensemble des éléments de code (ki, k2, ..., kj) attribués à ce processeur, puis - détermination de la valeur d’une fonction de coût individuelle (fr) associée à ce processeur en fonction de l’écart entre ladite période de répétition (T) et ladite durée totale d’exécution (tpui, tpU2, ... tpux), et - détermination de la valeur de la fonction de coût globale (,jFj en fonction des valeurs de chacune desdites fonctions de coût individuelles (/r).
2. 2. Méthode de détermination selon la revendication 1, dans laquelle l’une au moins desdites fonctions de coût individuelles (fr) est une fonction croissante et concave de la durée totale d’exécution (tpui, tpu2, ... tpux) associée à cette fonction de coût individuelle (fr).
3. 3. Méthode de détermination selon l’une des revendications 1 et 2, dans laquelle l’une au moins desdites fonctions de coût individuelles (fr) diverge lorsque la durée totale d’exécution associée (tpui, tpU2, ... tpux) à cette fonction de coût individuelle (fr) tend vers la période de répétition (T) ou dépasse la période de répétition (T).
4. 4. Méthode de détermination selon l’une des revendications 1 à 3, dans laquelle il est prévu en outre de déterminer une valeur d’un temps de latence (tp), égal à l’écart temporel entre le début et la fin du traitement de l’une desdites données (Di, D2, ..., Dn) par ledit algorithme, et dans laquelle la valeur de la fonction de coût globale (J^) diverge lorsque ledit temps de latence (tp) tend vers un seuil de temps de latence (dtspec) préalablement spécifié, ou dépasse ce seuil de temps de latence.
5. 5. Méthode de détermination selon la revendication 4, dans laquelle ledit algorithme est configuré pour qu’un résultat du traitement d’une première desdites données (Dn_i) soit pris en compte pour traiter une deuxième desdites données (Dn) reçue ultérieurement par l’unité de traitement, et dans lequel ladite valeur du temps de latence (tp) est déterminée en tenant compte d’une durée liée à la prise en compte de ladite première donnée (Dn.-i).
6. 6. Méthode de détermination selon l’une des revendications 4 et 5, dans laquelle, le traitement de l’une desdites données (Di, D2, ..., Dn) au moyen dudit algorithme débutant par l’un desdits éléments de code (k-ι), d’entrée, et se terminant par l’un desdits éléments de code (k5), de sortie, le temps de latence (tp) est déterminé au moyen des étapes suivantes : - détermination de chaque chemin d’exécution (^j<5 ;1 , ^1,5 ;2 , ^1,5 ;3 ) menant dudit élément de code (k-ι), d’entrée, audit élément de code (k5), de sortie, - pour chacun desdits chemins d’exécution (¾ ;1 , -^1,5 ;2 , ^1,5 ; 3 ), détermination d’un temps de parcours associé, - détermination du temps de latence (tp) en fonction du plus grand desdits temps de parcours.
7. 7. Méthode de détermination selon l’une des revendications 4 à 6, dans laquelle le temps de latence (tp) est déterminé : - en fonction de temps d’exécution associés chacun à l’un desdits éléments de code, et - en fonction d’un ou plusieurs délais (ôy) associés chacun à un transfert de données réalisé au cours dudit algorithme, entre deux desdits processeurs (pu1, Pu2, Pux)·
8. 8. Méthode de détermination selon l’une des revendications 1 à 7, dans laquelle chaque durée totale d’exécution (tpu1, tpu2, ... tpux) est déterminée en fonction du temps d’exécution desdits éléments de code (ki, k2, ..., K), chaque temps d’exécution (tJ étant défini sous la forme d’un intervalle de confiance délimité par une valeur minimale (%min) et une valeur maximale (τίίηαχ) de ce temps d’exécution, et dans laquelle les valeurs des fonctions de coût individuelles (/r) sont déterminées en fonction de valeurs moyennes définies par lesdits intervalles de confiance.
9. 9. Méthode de détermination selon la revendication 8, dans laquelle il est prévu en outre de : - déterminer une valeur maximale (tpux, max) de chaque durée totale d’exécution (tpux), sur la base des valeurs maximales (τί7ηαχ) desdits temps d’exécution (τέ), - si l’une au moins des valeurs maximales (tpuXj max) des durées totales d’exécution (tpux) est supérieure à la période de répétition (T), déterminer la valeur de la fonction coût globale (J^) en fonction des valeurs des fonctions de coût individuelles (/r), ou - sinon, affecter la valeur nulle à la fonction de coût globale (J^)·
10. 10. Méthode de détermination selon l’une des revendications 8 et 9, dans laquelle il est prévu en outre de : - déterminer une valeur minimale (tpux, min) de chaque durée totale d’exécution (tpux), sur la base des valeurs minimales (Timin) desdits temps d’exécution (τέ), - si les valeurs minimales des durées totales d’exécution (tpui, tpU2, ... tpux) sont chacune inférieure à la période de répétition (T), déterminer la valeur de la fonction coût globale en fonction des valeurs des fonctions de coût individuelles (fr), OU - sinon, affecter une valeur infinie à la valeur de la fonction de coût globale (,F~)·
11. 11. Méthode de sélection d’un mode de répartition (Mj) d’éléments de code (kg k2, ..., kj) d’un algorithme de traitement de données entre plusieurs processeurs (pug pu2, ...pux) d’une unité de traitement électronique, parmi plusieurs tels modes de répartitions (Mj) distincts, dans laquelle : - pour chaque mode de répartition (Mj), une valeur d’une fonction de coût globale (.Fj est déterminée au moyen d’une méthode de détermination conforme à l’une des revendications 1 à 10, et dans laquelle - l’un des modes de répartition (Mj) est sélectionné sur la base desdites valeurs de la fonction de coût globale (,Fj.
12. 12. Méthode de sélection d’une unité de traitement électronique destinée à exécuter un algorithme, parmi plusieurs unités de traitement électronique, chaque unité de traitement comprenant plusieurs processeurs (pu-ι, pu2, ...pux), l’algorithme étant mis en œuvre en exécutant plusieurs éléments de code (kg k2, ..., kj), dans laquelle il est prévu : - pour chaque unité de traitement, de mettre en œuvre une méthode de sélection conforme à la revendication 11, et d’attribuer à l’unité de traitement la valeur de la fonction de coût globale (.Fj correspondant au mode de répartition (Mj) ainsi sélectionné, puis - de sélectionner l’une desdites unités de traitement en fonction au moins des valeurs de fonction de coût globale (.F) attribuées à chaque unité de traitement.