Dans cette section, nous procédons à une analyse des latences qui composent le délai de com- munication de bout-en-bout entre deux partitions communicantes distantes. Nous nous appuyons sur la modélication IMA introduite précédement. Cette analyse permet de déterminer les para- mètres de l’allocation temporelle ainsi que les latences qui font varier les délais de bout-en-bout. Nous définissons deux délais de bout-en-bout: le délai fonctionnel et le délai de communication, le délai de communication étant inclus dans le délai fonctionnel.
3.2.1
Délai fonctionnel de bout-en-bout
Le délai fonctionnel de bout-en-bout [52] est illustré dans la Figure 3.2. Dans cette Figure, nous considérons une communication entre une partition source Piallouée sur le CPM M`, et la partition destination Pj allouée sur le CPM Mk. La partition source émet périodiquement une occurrence du flux de message msg. La nieme occurrence émise du flux msg est notée msg
n. Le délai fonctionnel est défini par la durée qui sépare la date de création d’une donnée dmsgn et la date où cette donnée a été traitée par la partition destination. Cette donnée est par exemple créée par un capteur et parvient au module à la date dmsgn sur un port dédié. Cette donnée ne peut être lue par la partition source qu’une fois celle-ci active à la date dn.
Nous supposons ici que la lecture des données disponibles sur tous les ports du module s’effectue en début d’activation de la partition. Les données sont produites et envoyées par l’unique tâche d’une partition une fois les traitements terminés, c.à.d à la fin de l’exécution de la partition.
Figure 3.2 – Délais de bout-en-bout fonctionnel et de communication
Le délai fonctionnel se décompose en une latence de lecture dans le buffer source, de la durée d’exécution de Pi et Pj, du délai de communication dans le réseau et de la latence de lecture sur le module de destination.
Latence buffer source
Une occurrence msgndu flux de message msg est générée par un capteur connecté au module M`. Cette occurrence doit attendre l’activation de la partition Pi pour être lue dans le buffer source. Cette latence est représentée sur la Figure3.2par la différence entre la date de la prochaine activation de Pi, dn dans notre cas, et la date de la génération de la donnée, notée dmsgn.
Durée d’exécution de la source
La partition Pi est activée pour une durée de temps bi durant laquelle l’occurrence msgn demeure au niveau de Pi, jusqu’à ce qu’elle soit transmise sur le port APEX de sortie. La latence d’exécution est donc donnée par bi.
Latence réseau
La latence réseau est la durée entre le moment où l’occurrence d’un message msgn quitte le port APEX en sortie au niveau de la partition source Pi, et le moment où cette occurrence msgn arrive sur le port APEX en entrée du module destination Mk.
Chaque occurrence du flux de messages msg peut subir des délais variables dans le réseau. De ce fait, comme les réseaux embarqués sont conçus pour garantir un délai borné, nous supposons que le délai de communication, noté Li,j, entre deux partitions distantes Pi et Pj, appartient à un intervalle borné [Lmin
i,j , Lmaxi,j ], où Lmini,j est la latence réseau meilleur cas observée et Lmaxi,j est la latence réseau pire cas observée sur la communication Comi,j. La latence dans le réseau est influencée par différents facteurs. Nous pouvons citer le type de réseau, sa topologie, sa charge et son paramétrage. La latence est bornée pour chaque communication en concordance avec les études connues sur le calcul pire cas réalisé dans le contexte des réseaux embarqués avioniques (cf. [35][37] et les références détaillées dans la Section2.4).
Latence à la destination
Une fois msgn reçu au niveau du CPM destination, msgn doit attendre l’activation de sa cible. La latence à la destination, notée Ji,jest définie par la différence entre la date de la lecture de msgn par Pj et la date de son arrivée sur le port APEX du module Mk. Les occurrences de msg qui sont reçues à la partition destination ne constituent plus un flux périodique. Ceci est la conséquence de la variabilité dans le réseau de communication et des déphasages de démarrage des CPMs communicants.
Durée d’exécution à la destination
Une fois msgn lu par la partition destination Pj, il est utilisé pour les traitements de la tâche destination pour une durée d’exécution bj. Une fois la tache hébergée par Pj terminée, nous supposons que la communication fonctionnelle se termine.
3.2.2
Délai de communication de bout-en-bout
Dans ces travaux, il a été choisi de travailler avec les seules composantes du délai fonctionnel de bout-en-bout qui soient directement impactées par l’allocation temporelle réalisée dans les phases d’intégration. En effet, le choix des périodes d’exécution des partitions n’impacte pas les durée d’exécution bi et bj. Seuls Li,j et Ji,j sont conditionnés par le choix de Ti et Tj.
Nous avons donc défini le délai de communication de bout-en-bout E2Ei,j, comme la somme de la latence réseau Li,j et de la latence à la destination Ji,j. Formellement:
E2Ei,j = Li,j+ Ji,j
E2Ei,j représente le délai entre l’émission de msgn sur le port APEX d’émission de Pi et sa lecture effective par la partition destination Pj sur le module destination.
Comme il a été précisé précédemment, une partition source génère périodiquement une oc- currence de message à la fin de chacune de ses exécutions. Ces occurrences sont transmises à au moins une partition destination à travers un lien virtuel AFDX (VL). Un VL AFDX est carac- térisé par son BAG. Dans le tableau3.1, les BAGs des liens virtuels sont fixés de façon à ne pas dépasser la période de leurs partitions source. Ainsi, nous pouvons assurer qu’une occurrence de message n’est pas écartée à cause du BAG correspondant au VL qui la transporte.
La tableau 3.3 détaille les bornes sur la latences réseaux des communications de la Figure
3.1..
Lmini,j (ms) Lmaxi,j (ms)
Com1,5 2 12 Com1,8 3 15 Com1,12 1 6 Com6,13 1 6 Com7,2 2 12 Com9,3 4 20 Com10,14 2 10 Com11,4 1 5
Tableau 3.3 – Bornes sur les latences réseau
Dans ce qui suit, nous procédons à la formulation du problème d’allocation temporelle en intégrant les contraintes applicatives temps-réelles et les contraintes technologiques propres au système IMA.