FR3077698A1 - Procede d'optimisation d'un systeme embarque et dispositifs associes - Google Patents

Abstract

L'invention concerne un procédé d'optimisation d'un système embarqué, le système embarqué comportant des composants, chaque composant communiquant avec un autre composant par échange d'au moins un paquet, chaque paquet comportant au moins une partie d'une donnée, l'ensemble des composants formant un réseau de communication comportant des liens, le procédé comportant au moins une étape de : - fourniture d'une exigence statistique globale pour le système embarqué, - décomposition de l'exigence statistique globale en exigences individuelles, une exigence individuelle pour chaque lien à un flux donné, et - pour chaque lien, détermination du nombre de transmissions de paquets garantissant le respect de l'exigence individuelle propre au lien considéré.

Description

Procédé d’optimisation d’un système embarqué et dispositifs associés

La présente invention concerne un procédé d’optimisation d’un système embarqué. La présente invention se rapporte également à un produit programme d’ordinateur adapté à la mise en œuvre d’un tel procédé d’optimisation. La présente invention concerne aussi un support lisible d’informations propre à mettre en œuvre le procédé d’optimisation. La présente invention se rapporte également à un système embarqué associé au procédé d’optimisation.

A titre d’exemple, dans le domaine avionique, des systèmes temps réel sont utilisés. La plupart des systèmes embarqués comporte des composants tels que des unités de calcul, des capteurs et des actionneurs, chaque composant dialoguant avec les autres à travers des dispositifs de communications. Il peut s’agir de bus de communication (tous les composants dialoguent à travers le même lien) ou de réseaux commutés comme pour l’Internet.

Dans le cas des réseaux commutés, la manière dont deux composants dialoguent est appelée protocole réseau. Chaque composant communique une donnée via des paquets qui sont des enveloppes réseaux permettant de transporter la donnée.

En pratique, un système peut être sujet à des défaillances transitoires, c’est-à-dire des erreurs de transmission de paquet réseau. Par exemple, un paquet réseau peut être corrompu à cause d’une erreur matérielle conduisant à une inversion de bit. Bien que de telles erreurs soient des événements très rares, il convient de gérer ces erreurs qui peuvent altérer l’intégrité du paquet.

Pour vérifier que le paquet arrive intact, il est connu de faire un contrôle sur l’intégrité des paquets entre un émetteur et un récepteur via des codes détecteurs ou correcteurs d’erreurs (tels qu’une somme de contrôle) ajoutés en queue. Les codes permettent dans tous les cas de détecter une erreur et éventuellement de la corriger. Dans l’hypothèse où il est détecté une erreur que le récepteur ne sait pas corriger, le paquet est détruit et une notification est éventuellement retournée à l’émetteur.

Un tel contrôle couplé à la mise en œuvre d’une retransmission du paquet dans certains cas est suffisant pour des flux de communication non critiques mais insuffisant pour les flux de communication ayant des propriétés dites temps réel. Il s’agit de garantir qu’une donnée ou plus précisément un paquet arrive à destination avant une échéance stricte. Cela suppose d’une part que le paquet arrive intact et d’autre part dans le temps imparti.

En d’autres termes, pour répondre aux problématiques de garantie d’un fonctionnement temps réel, il est souhaitable de bien gérer les erreurs transitoires de transmission pour garantir un bon fonctionnement du système temps réel.

Une technique pour gérer de telles erreurs dans un contexte temps réel est de dupliquer les communications le long de chemins disjoints. Une telle technique suppose que les erreurs de transmission sont si rares qu’une donnée en subira au plus une sur l’un des deux chemins. Si une erreur apparaît de sorte qu’une des données arrive trop tard au récepteur, alors au moins l’autre donnée arrive au récepteur à temps.

Toutefois, une telle technique implique un doublement des ressources réseau utilisées, doublement qui est la plupart du temps inutile du fait que les erreurs de transmission sont rares. De plus, une telle technique repose sur l’hypothèse qu’un des paquets arrive à destination sans erreurs, ce qui a une probabilité de ne pas être vrai.

Pour pallier ce dernier problème, il est connu de calculer le risque que deux paquets arrivent à destination avec une erreur. Lorsque le risque calculé est supérieur à la fiabilité voulue pour le système temps réel, le nombre de paquets retransmis est augmenté, par exemple, le même paquet est transmis trois, quatre ou cinq fois. Cela augmente d’autant le nombre de ressources impliqué dans le système.

Dans le cas de réseaux capables de retransmettre un paquet ayant subi une erreur de transmission, si la réception d’un paquet n’a pas été acquittée par le voisin après un temps d’attente, ou que ce dernier a envoyé un acquittement négatif, alors l’émetteur retransmet le paquet. Dans un tel cas, la multiplication des retransmissions est encore moins indiquée puisqu’elle n’exploite pas la présence d’un tel mécanisme de retransmission.

Toutefois, l’exploitation d’un tel mécanisme n’est pas aisée dans la mesure où la retransmission d’un paquet implique que l’émetteur a envoyé deux paquets au lieu d’un, ce qui retarde l’arrivée de la donnée complète et peut lui faire manquer l’échéance. Il existe également une probabilité plus faible qu’un train de paquets correspondant à une donnée subisse deux erreurs de transmission ou plus. L’existence d’une telle probabilité, même faible, montre que la fiabilité du système temps réel n’est pas garantie.

Pour traiter un tel problème, il est connu d’utiliser des approches probabilistes pour vérifier la conformité d’un système temps réel à une exigence statistique. L’exigence statistique à remplir correspond à la fiabilité (dénommée « reliability » en anglais) du système temps réel et plus précisément à la probabilité qu’aucune défaillance non gérée n’ait lieu durant l’intervalle de temps considéré (typiquement durée d’utilisation du système). Une telle condition est équivalente à un temps moyen entre défaillances transitoires qui est obtenu en divisant l’intervalle de temps considéré par la fiabilité souhaitée. Dans un tel cas, une défaillance correspond au cas où une donnée subit plus de retransmissions que la borne fixée.

Il est alors connu de concevoir un composant puis d’observer les propriétés statistiques du composant conçu en utilisant un modèle d’erreurs basé sur un processus de Poisson pour obtenir la probabilité que, sur la durée de vie du système, les tâches ne vont pas subir plus de retransmissions que prévu. Lorsque le critère de fiabilité n’est pas rempli, une autre architecture pour le composant est proposée puis évaluée.

Cependant, le processus itératif de conception peut être long pour obtenir un système temps réel respectant la fiabilité désirée. En outre, une telle méthode est incompatible avec une analyse incrémentale du fait que la probabilité calculée prend en compte l’ensemble des tâches mises en œuvre par le système temps réel.

Il existe donc un besoin pour un procédé d’optimisation d’un système embarqué, notamment propre à fonctionner en temps réel, qui permette d’obtenir un système embarqué avec moins de ressources impliquées tout en respectant une exigence de fiabilité et de préférence, une allocation des ressources adaptée au besoin en fiabilité.

Pour cela, la présente description porte sur un procédé d’optimisation d’un système embarqué, le système embarqué comportant des composants, chaque composant communiquant avec un autre composant par échange d’au moins un paquet, chaque paquet comportant au moins une partie d’une donnée, l’ensemble des composants formant un réseau de communication comportant des liens, le procédé comportant au moins une étape de fourniture d’une exigence statistique globale pour le système embarqué, de décomposition de l’exigence statistique globale en exigences individuelles, une exigence individuelle pour chaque lien à un flux donné, et, pour chaque lien, de détermination du nombre de transmissions de paquets garantissant le respect de l’exigence individuelle propre au lien considéré.

Suivant des modes de réalisation particuliers, le procédé d’optimisation comprend une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toutes les combinaisons techniquement possibles :

- lors de l’étape de détermination, il est supposé que les erreurs sur la transmission d’un paquet suivent une loi statistique.

- la loi statistique est une loi de Poisson.

- lors de l’étape de détermination, un processus itératif est mis en œuvre.

- lorsque le nombre de transmissions de paquets est trop élevé sur un lien, le procédé comporte une étape d’allocation de ressources supplémentaires au système embarqué.

- l’exigence statistique globale est que le temps moyen entre deux échecs pour le système est inférieur à une valeur prédéfinie.

- les liens du système embarqué sont suivant une architecture SDRN.

La présente description se rapporte également à un produit programme d’ordinateur comportant un support lisible d’informations, sur lequel est mémorisé un programme d’ordinateur comprenant des instructions de programme, le programme d’ordinateur étant chargeable sur une unité de traitement de données et adapté pour entraîner la mise en œuvre d’un procédé tel que précédemment décrit lorsque le programme d’ordinateur est mis en œuvre sur l’unité de traitement des données.

La présente description concerne aussi un support lisible d’informations mémorisant un programme d’ordinateur comprenant des instructions de programme, le programme d’ordinateur étant chargeable sur une unité de traitement de données et adapté pour entraîner la mise en œuvre d’un procédé tel que précédemment décrit lorsque le programme d’ordinateur est mis en œuvre sur l’unité de traitement des données.

La présente description se rapporte également à un système embarqué comportant des composants, chaque composant communiquant avec un autre composant par échange d’au moins un paquet, chaque paquet comportant au moins une partie d’une donnée, l’ensemble des composants formant un réseau de communication comportant des liens, le système comportant un contrôleur, le contrôleur étant propre à mettre en œuvre un procédé tel que précédemment décrit.

D’autres caractéristiques et avantages de l’invention apparaîtront à la lecture de la description qui suit de modes de réalisation de l’invention, donnés à titre d’exemple uniquement et en référence aux dessins qui sont :

- figure 1, une vue schématique d’un exemple de système permettant la mise en œuvre d’un procédé d’optimisation d’un système embarqué,

- figure 2, une représentation schématique d’un réseau suivant une architecture SDRN comportant un contrôleur propre à mettre en œuvre un contrôle d’admission, et

- figure 3, un organigramme d’un exemple mise en œuvre d’un exemple de contrôle d’admission.

Un ordinateur 10 et un produit programme d’ordinateur 12 sont représentés à la figure 1. L’interaction du produit programme d’ordinateur 12 avec le système 10 permet de mettre en œuvre un procédé d’optimisation d’un système embarqué.

Plus généralement, l’ordinateur 10 est un calculateur électronique propre à manipuler et/ou transformer des données représentées comme des quantités électroniques ou physiques dans des registres de l’ordinateur 10 et/ou des mémoires en d’autres données similaires correspondant à des données physiques dans des mémoires, des registres ou d’autres types de dispositifs d’affichage, de transmission ou de mémorisation.

L’ordinateur 10 comporte un processeur 14 comprenant une unité de traitement de données 16, des mémoires 18 et un lecteur 20 de support d’informations. L’ordinateur 10 comprend également un clavier 22 et une unité d’affichage 24.

Le produit programme d’ordinateur 12 comporte un support lisible d’informations.

Un support lisible d’informations est un support lisible par l’ordinateur 10, usuellement par l’unité de traitement de données 14. Le support lisible d’informations est un médium adapté à mémoriser des instructions électroniques et capable d’être couplé à un bus d’un système informatique.

A titre d’exemple, le support lisible d’informations est une disquette ou disque souple (de la dénomination anglaise de « floppy disk »), un disque optique, un CD-ROM, un disque magnéto-optique, une mémoire ROM, une mémoire RAM, une mémoire EPROM, une mémoire EEPROM, une carte magnétique ou une carte optique.

Sur le support lisible d’informations est mémorisé un programme d’ordinateur comprenant des instructions de programme.

Le programme d’ordinateur est chargeable sur l’unité de traitement de données 14 et est adapté pour entraîner la mise en œuvre du procédé d’optimisation.

Le fonctionnement de l’ordinateur 10 en interaction avec le produit programme d’ordinateur 12 est maintenant décrit en référence à un exemple de mise en œuvre d’un procédé d’optimisation d’un système embarqué.

Le système embarqué comportant des composants, chaque composant communiquant avec un autre composant par échange d’au moins un paquet, chaque paquet comportant au moins une partie d’une donnée (un paquet est un ensemble d’entête et d’une partie utile transportant ladite au moins une partie d’une donnée), l’ensemble des composants formant un réseau de communication comportant des liens L.

Chaque lien L est propre à être traversé par un flux de communication f permettant la circulation des paquets, et donc des données, entre les composants.

Dans le contexte décrit, le système embarqué est un système temps réel.

Le procédé comporte une étape de fourniture, une étape de décomposition et une étape de détermination.

Lors de l’étape de fourniture, il est fourni une exigence statistique globale pour le système embarqué.

L’exigence globale statistique est exprimée de la façon suivante : une probabilité p qu’une donnée (n’importe laquelle) arrive trop tard à destination à cause des erreurs de transmission pendant un intervalle de temps IT doit être inférieure ou égale à une valeur prédéfinie.

Par exemple, l’intervalle de temps IT considéré est la durée d’utilisation du réseau.

De manière analogue, l’exigence globale statistique peut s’exprimer sous forme d’un temps moyen entre deux échecs TME, un échec étant dans ce cas le fait qu’une donnée arrive trop tard à sa destination à cause des erreurs de transmission. Le temps moyen entre deux échecs TME est relié à la probabilité p et à l’intervalle de temps IT selon la relation suivante :

IT

TME = — P

Dans la suite, l’exigence globale statistique est exprimée en utilisant la notion de temps moyen entre deux échecs TME, sachant que, de manière équivalente, il est possible d’utiliser la probabilité p et l’intervalle de temps IT.

Ainsi, l’exigence globale statistique s’exprime sous la forme d’une inégalité, à savoir que le temps moyen entre deux échecs TME pour le système est inférieur à une valeur prédéfinie.

Lors de l’étape de décomposition, l’exigence statistique globale est décomposée en exigences individuelles de temps moyen entre deux échecs TME pour chaque lien L traversé par un flux de communication.

Pour cela, il est considéré que les composants du réseau sont en série en termes de défaillance : si un paquet arrive trop tard sur l’un des liens L, alors le réseau est considéré comme défaillant globalement.

Dans un cas de système à deux composants C1 et C2, cela signifie que le temps moyen entre deux échecs du système TME_système est relié à la fois au temps moyen entre deux échecs du premier composant TME_C1 et au temps moyen entre deux échecs du deuxième composant TME_C2 par la relation suivante :

1 1

TME_Sy_St$me TME_C1 TMEc2

En supposant que les deux composants sont identiques, alors le temps moyen entre deux échecs du premier composant TME_C1 est égal au temps moyen entre deux échecs du deuxième composant TME_C2 de sorte que la relation précédente devient :

TME_C1

TME_Sy_Stè_me — 7

Un tel raisonnement se généralise aisément à un nombre quelconque de composants identiques. En notant n le nombre de composants du système (n étant un nombre entier supérieur ou égal à 2) et TME_composant le temps moyen entre deux échecs de chaque composant, il est obtenu :

'Γ'ΙΙΛΓ· — TAfE_composant l m Esystème ~~

En l'occurrence, les composants du raisonnement précédent modélisent les liens L. Il vient ainsi :

TME(L) = TME_système * n_L où :

• n_L est le nombre de liens L du système, et • TME(L) désigne le temps moyen entre deux échecs pour le lien L, L étant dans ce contexte un entier compris entre 1 et n_L.

Comme expliqué précédemment, un flux de communication transite dans chaque lien L. Le flux de communication transitant dans un lien L est spécifique à celui-ci. Le flux de communication est noté f dans ce qui suit.

En outre, chaque lien L est divisé en une pluralité de canaux que le flux de communication f consomme selon un coefficient de consommation noté w_fL. Il en résulte que :

TME(L,f) = TME(L) * = TME_système *n_L*^ ^wf,L ^Wf,L où:

• n_CiL est le nombre de canaux d’un lien L du système, et • TME(L,f) désigne le temps moyen entre deux échecs pour le lien L et un flux de communication f.

En connaissant la structure du système du point de vue des échanges entre les composants, le nombre de canaux d’un lien L du système n_cL, le nombre de liens L et les coefficients de consommation w_ftL sont connus. En rappelant ici que l’exigence globale statistique qui s’exprime sous la forme d’une inégalité, à savoir que le temps moyen entre deux échecs TME pour le système est inférieur à une valeur prédéfinie, la formule précédente permet d’obtenir une valeur maximale pour le temps moyen entre deux échecs pour le lien L et un flux de communication TME(L,f). Le respect de cette relation est une exigence individuelle.

A l’issue de l’étape de décomposition, il est ainsi obtenu une exigence individuelle spécifique pour chaque lien L traversé par un flux de communication et garantissant que l’exigence globale statistique est vérifiée.

Lors de l’étape de détermination, il est déterminé, pour chaque lien, le nombre de transmissions de paquets garantissant le respect de l’exigence individuelle associé au lien.

Pour cela, une donnée est simulée comme une donnée étendue, c’est-à-dire comme la donnée répétée autant de fois que la donnée est transmise.

A titre d’exemple, pour un ensemble de paquets correspondant à une donnée qui est transmis trois fois, la taille de la donnée étendue est égale à trois fois la taille de la donnée.

Pour la suite, le nombre de paquets supplémentaires à retransmettre dans le pire cas (toujours selon l’exigence statistique) est noté K_fL alors que 6_fL est la taille totale de la donnée sans retransmission.

Le pire cas est le cas où chaque erreur de bit touche un paquet différent de la donnée, le nombre de retransmissions étant alors égal au nombre d’erreurs de bits.

Par ailleurs, le taux moyen d’erreurs de bits dans le réseau est noté BER en référence au sigle anglais renvoyant au terme anglais de « Bit Error Rate » qui signifie littéralement « taux d’erreurs de bits ».

La période minimale entre chaque envoi de donnée dans le flux est notée T_f.

Il est supposé dans l’étape de détermination que les erreurs de bits suivent une loi statistique qui est, en l’occurrence une loi de Poisson.

La loi de Poisson est une loi de probabilité discrète qui décrit le comportement du nombre d'évènements se produisant dans un intervalle de temps fixé, si ces évènements se produisent avec une fréquence moyenne ou espérance connue et indépendamment du temps écoulé depuis l'évènement précédent. Si le nombre moyen d’occurrences dans l’intervalle de temps fixé est λ (nombre réel strictement positif), alors la probabilité p(k) que k occurrences surviennent est donnée par :

p(fc) = — e^

Où :

• e désigne la fonction exponentielle, et • ! désigne la fonction factorielle.

Dans le cas considéré de l’étape de détermination, le paramètre de la loi de Poisson dans le flux f est noté Physiquement, le paramètre de la loi de Poisson est le nombre moyen de retransmissions par donnée, c’est-à-dire le nombre moyen d’erreurs de bits par donnée.

Le paramètre de la loi de Poisson _L est relié au taux moyen d’erreurs de bits BER et à la taille totale de la donnée sans retransmission df _L par la relation mathématique suivante :

2f,L = BER. Bf _l

Cela implique que l’exigence individuelle à respecter s’écrit :

En prenant en compte la loi de Poisson, il en résulte que l’exigence individuelle à respecter devient :

K_f,_L = k_eN|-------------j-.Tf > TME(L,f) _LL i!

Les retransmissions induites par ces erreurs peuvent à nouveau subir des erreurs. L’étape de détermination suppose donc d’itérer le processus précédent pour converger vers une valeur optimale du nombre de paquets supplémentaires à retransmettre dans le pire cas K_fL.

Une itération du processus est détaillée dans ce qui suit en sept étapes.

Lors de la première étape, la condition précédente permet d’obtenir une valeur pour le nombre de paquets supplémentaires à retransmettre dans le pire cas K_{f L}.

Dans une deuxième étape, il est calculé la nouvelle taille totale de la donnée sans retransmission e'_{f L} selon la formule suivante :

d'f,L = 0f,_L + Kf_L

Lors de la troisième étape, la nouvelle taille totale de la donnée sans retransmission e'_{f L} correspond à un nouveau flux de communication f qui consomme selon un nouveau coefficient de consommation qui est noté w'f _L.

Lors de la quatrième étape, le nouveau temps moyen TME'(L,f) entre deux échecs pour le lien L et un flux de communication f est calculé via la formule suivante :

TME'(L,f) = TME(L) * — ^w/,l

Il est également déterminé dans la cinquième étape le nouveau paramètre de la loi de Poisson via la relation :

λ'f _L = BER.B'f_L

La nouvelle exigence individuelle à respecter s’écrit alors selon la formule k_eM|----------— -Tf > TME'(L,f) ce qui permet dans une sixième étape une nouvelle ^{x e} Δ_ι=ο fi valeur pour le nombre de paquets supplémentaires à retransmettre dans le pire cas K.'_fiL.

Lors d’une septième étape, la nouvelle valeur pour le nombre de paquets supplémentaires à retransmettre dans le pire cas K’_fL (obtenue à la sixième étape) et la valeur pour le nombre de paquets supplémentaires à retransmettre dans le pire cas K_{f L} (obtenue à la première étape) sont comparées. Tant que les deux valeurs sont différentes, il est choisi de réitérer le processus.

A l’issue de l’étape de détermination, il est ainsi obtenu pour chaque lien le nombre de paquets supplémentaires à retransmettre dans le pire cas K_{f L}.

Pour une architecture donnée, le procédé permet ainsi d’obtenir le nombre de paquets à retransmettre pour chaque lien L, ce qui se traduit simplement par le fait que le paquet effectivement transmis comporte K_fiL fois la donnée à transmettre entre les deux composants via le lien L.

Le procédé force le respect de l’exigence de fiabilité au lieu de la vérifier a posteriori et permet l’allocation incrémentale des ressources réseau sous contrainte de fiabilité. Il s’agit ainsi d’une utilisation inversée de la théorie des temps moyens entre deux échecs TME pour garantir une situation statistique plutôt que l’observer. Plus précisément, la contrainte de limiter la probabilité d’échec devient un choix de conception qui n’est plus subie.

Le procédé est ainsi une approche probabiliste pour la gestion des erreurs de transmission sans redondance des communications.

Le procédé repose sur le principe de borner le nombre de paquets de retransmission que peut subir une donnée, afin d’en déduire une taille de donnée étendue équivalente dans le pire cas. C’est cette taille de donnée étendue qui est prise en compte à la place de la taille de donnée précisée dans la requête de flux. En d’autres termes, il est alloué les mêmes ressources que si la donnée était par défaut plus grande du nombre de paquets de retransmission calculés.

Par calcul, les tailles de données sont telles que la fiabilité totale du réseau sera supérieure ou égale à l’exigence de fiabilité donnée en entrée.

Le procédé garantit ainsi une gestion sûre des erreurs de transmission selon une contrainte de fiabilité sans recourir à des redondances, notamment des duplications, des communications.

Par rapport à des procédés exploitant une ou plusieurs redondances, le procédé permet une meilleure gestion des ressources réseau utilisées.

En résumé, le procédé proposé est un procédé d’optimisation d’un système embarqué, notamment propre à fonctionner en temps réel, qui permette d’obtenir un système embarqué avec moins de ressources impliquées tout en respectant une exigence de fiabilité.

Il est à noter que cette meilleure gestion des ressources réseau est totalement transparente du point de vue du matériel et des applications, aucune complexité supplémentaire n’étant impliquée.

Le procédé est également compatible avec une conception du système prenant en compte d’autres critères. En effet, s’il est déterminé que le nombre de paquets à retransmettre est trop élevé, il est possible d’allouer des ressources supplémentaires, au système embarqué, typiquement des canaux de communications supplémentaires.

L’application de ce procédé à un réseau de système temps réel suivant l’architecture SDRN se fait sous forme d’une extension transparente.

Le sigle SDRN renvoie au terme anglais de « Software-Defined Real-Time Networking » qui signifie littéralement en français « Réseau temps réel défini par logiciel ».

Une telle architecture est notamment décrite dans une publication de mai 2017 de Florian Greff, Ye-Qiong Song, Laurent Ciarletta et Arnaud Samama intitulée “A Dynam/c Flow Allocation Method for the Design of a Software-Defined Real-Time Mesh Network’, 13th IEEE International Workshop on Factory Communication Systems (WFCS 2017).

La figure 2 illustre une représentation schématique d’un tel réseau suivant l’architecture SDRN. Dans l’architecture SDRN, il y a trois étages, un premier étage 30 qui est le réseau 30, un deuxième étage qui est le contrôleur 32 et un troisième étage qui est celui des applications 34.

Des échanges ont lieu depuis le réseau 30 vers le contrôleur 32 (échanges indiqués par la flèche 36), depuis le contrôleur 32 vers les applications 34 (échanges indiqués par la flèche 38), depuis le contrôleur 32 vers le réseau 30 (échanges indiqués par la flèche 40) et depuis les applications 34 vers le contrôleur 32 (échanges indiqués par la flèche 42).

Le réseau 30 communique notamment sa topologie et les pannes survenues au contrôleur 32 tandis que le contrôleur 32 indique au réseau 30 une configuration à respecter.

Le contrôleur 32 communique notamment aux applications 34 les résultats du contrôle d’admission tandis que les applications 34 indiquent au contrôleur 32 les propriétés des flux.

Le contrôleur 32 calcule la configuration en fonction du trafic actuel, des propriétés du réseau 30, des propriétés du protocole sous-jacent et de la stratégie d’optimisation. Sur la base de ces données, le contrôleur 32 analyse la façon dont le réseau 30 peut se comporter dans le pire cas, afin d’allouer les ressources du réseau 30 de sorte que le respect des contraintes temps réel des communications soit garanti.

Plus précisément, le calcul de la configuration par le contrôleur 32 est appelé contrôle d’admission. Un organigramme de mise en œuvre du contrôle d’admission est illustré par la figure 3.

Le contrôle d’admission comporte deux étapes E50 et E52.

Lors de la première étape E50, il est analysé les contraintes. La première étape prend deux entrées 54 et 56 pour obtenir deux sorties 58 et 60.

La première entrée 54 correspond aux propriétés du flux alors que la deuxième entrée 56 correspond aux propriétés du réseau 30 et aux propriétés du protocole sousjacent.

La première sortie 58 est le coefficient de consommation et la deuxième sortie 60 est le délai de saut. Un délai de saut est le délai maximal subi par un paquet du flux sur le lien entre deux commutateurs reliés par le lien, le délai étant exprimé en seconde.

La première sortie 58 et la deuxième sortie 60 sont respectivement la première entrée et la deuxième entrée de la deuxième étape E52 durant laquelle il est cherché le chemin.

La deuxième étape E52 prend également en entrée une troisième entrée 62 qui comporte la topologie, l’état du réseau 30 et la stratégie d’optimisation et renvoie dans une sortie 66 les paramètres de configuration (symbolisés par deux flèches 64 sur la figure 3), c’est-à-dire la configuration envoyée par la flèche 40.

Le contrôle d’admission illustré par la figure 3 est ainsi le cœur de l’architecture SDRN puisqu’il permet d’allouer à chaud et de façon incrémentale des flux de communication temps réel sur des réseaux embarqués.

Pour mettre en œuvre le procédé d’optimisation, le procédé comporte une étape de calcul de paramètres supplémentaires pour insérer les résultats dans le contrôle d’admission.

Les paramètres supplémentaires calculés sont le coefficient de consommation et le délai de saut.

Pour ce dernier paramètre, il est utilisé la relation suivante :

_d^) _{= d(f>i)+}^£._K/L ^ll

Où:

• pf_tL est la taille maximale d’un paquet de flux sur le lien L, cette taille s’exprimant en bit, et • C_L est la capacité du lien L, cette taille s’exprimant en bit par seconde.

Pour utiliser le procédé d’optimisation dans le contrôle d’admission, il suffit de substituer aux valeurs de la première sortie 58 et la deuxième sortie 60 les paramètres supplémentaires calculés.

Ainsi, le procédé d’optimisation est une approche probabiliste pour la prise en 5 compte des retransmissions dans le contrôle d’admission SDRN.

Le procédé correspondant alors à une extension du contrôle d’admission, ce procédé est facilement intégrable dans l’architecture SDRN et apporte un faible surcoût au temps de contrôle d’admission.

Claims (11)

1Procédé d’optimisation d’un système embarqué, le système embarqué comportant des composants, chaque composant communiquant avec un autre composant par échange d’au moins un paquet, chaque paquet comportant au moins une partie d’une donnée, l’ensemble des composants formant un réseau de communication comportant des liens, le procédé comportant au moins une étape de :

- fourniture d’une exigence statistique globale pour le système embarqué,

- décomposition de l’exigence statistique globale en exigences individuelles, une exigence individuelle pour chaque lien à un flux donné, et

- pour chaque lien, détermination du nombre de transmissions de paquets garantissant le respect de l’exigence individuelle propre au lien considéré.

2, - Procédé selon la revendication 1, dans lequel, lors de l’étape de détermination, il est supposé que les erreurs sur la transmission d’un paquet suivent une loi statistique.

3, - Procédé selon la revendication 2, dans lequel la loi statistique est une loi de Poisson.

4, - Procédé d’optimisation selon l’une quelconque des revendications 1 à 3, dans lequel lors de l’étape de détermination, un processus itératif est mis en œuvre.

5, - Procédé d’optimisation selon l’une quelconque des revendications 1 à 4, dans lequel lorsque le nombre de transmissions de paquets est trop élevé sur un lien, le procédé comporte une étape d’allocation de ressources supplémentaires au système embarqué.

6, - Procédé d’optimisation selon l’une quelconque des revendications 1 à 5, dans lequel l’exigence statistique globale est que le temps moyen entre deux échecs pour le système est inférieur à une valeur prédéfinie.

7, - Procédé d’optimisation selon l’une quelconque des revendications 1 à 6, dans lequel les liens du système embarqué sont suivant une architecture SDRN.

8, - Produit programme d’ordinateur comportant un support lisible d’informations, sur lequel est mémorisé un programme d’ordinateur comprenant des instructions de programme, le programme d’ordinateur étant chargeable sur une unité de traitement de données et adapté pour entraîner la mise en œuvre d’un procédé selon l’une quelconque des revendications 1 à 7 lorsque le programme d’ordinateur est mis en œuvre sur l’unité de traitement des données.

9. - Support lisible d’informations mémorisant un programme d’ordinateur comprenant des instructions de programme, le programme d’ordinateur étant chargeable sur une unité de traitement de données et adapté pour entraîner la mise en œuvre d’un procédé selon l’une quelconque des revendications 1 à 7 lorsque le programme

10 d’ordinateur est mis en œuvre sur l’unité de traitement des données.

10. - Système embarqué comportant des composants, chaque composant communiquant avec un autre composant par échange d’au moins un paquet, chaque paquet comportant au moins une partie d’une donnée, l’ensemble des composants

15 formant un réseau de communication comportant des liens, le système comportant un contrôleur, le contrôleur étant propre à mettre en œuvre un procédé selon l’une quelconque des revendications 1 à 7.