Nous détaillons dans ce paragraphe les raisons pour lesquelles il nous a semblé intéressant d’utiliser la théorie du Network Calculus pour répondre à notre problématique. Nous indiquons également pourquoi cette théorie peut s’appliquer à notre contexte, alors qu’elle a i été développée dans un contexte différent.
2.1 Intérêt de la méthode
La principale caractéristique de la méthode d’analyse de réseau proposée par Cruz est qu’elle fournit des résultats déterministes. A partir du moment où les flux qui entrent dans un réseau peuvent être modélisés par la notion d’enveloppe, et se comportent conformément à cette enveloppe, la méthode permet de fournir des bornes qui seront absolues, dans le sens où la probabilité pour qu’elles soient dépassées est nulle. Ceci provient du fait que la notion d’enveloppe ne considère pas un intervalle temporel particulier, mais plutôt tous les intervalles d’une amplitude donnée. De plus, les différentes bornes sont obtenues en considérant les extremums de quantités pour toutes ces amplitudes différentes. On s’affranchit ainsi de la notion de recherche de pire cas, qui pourrait être envisagée dans une démarche de recherche de bornes déterministes. En effet, une recherche de pire cas implique notamment l’observation d’évènements sur un intervalle particulier. On essaie généralement de particulariser l’intervalle considéré en le caractérisant par un évènement donné, par exemple l’arrivée du premier paquet d’un flux dans un élément. Ce faisant, se pose obligatoirement la question de savoir si on considère vraiment l’intervalle où se déroule le pire cas. Une démarche de pire cas se déroule donc toujours en deux phases : d’abord l’intuition du pire cas, et l’étude de celui-ci, puis la preuve que le cas considéré est bien le pire. Cette dernière partie est d’ailleurs fréquemment difficile, et l’expérience montre que l’intuition du cas pire est rarement justifiée, surtout dans des cas complexes.
La méthode de Cruz, parce qu’elle considère tous les intervalles possibles, présente donc l’avantage de fournir des bornes exactes, et avec des efforts de démonstration moindres. Or ceci est particulièrement important en vue de la certification du système avionique, qui nécessite que toute borne calculée soit soigneusement démontrée.
2.2 Applicabilité du Network Calculus
Nous avons vu qu’il n’est pas possible d’appliquer les résultats du Network Calculus à n’importe quel réseau. Les prochains paragraphes explicitent les hypothèses qui sont vérifiées pour un réseau avionique conforme à l’ARINC 664.
2.2.1 Construction d’un modèle
Comme souvent, on applique la méthode d’analyse sur un modèle du réseau. Il est bien évident que la performance globale de l’analyse dépendra de la validité et de la qualité de la démarche de modélisation. Dans un premier temps, on peut se questionner sur l’existence même d’un tel modèle du réseau. En effet, les différents éléments présentés dans les paragraphes 1.2 et 1.3 ne permettent pas de modéliser n’importe quel type de comportement. En particulier, ce sont des éléments statiques, dont les caractéristiques sont bien définies. Il est donc impossible de les utiliser pour modéliser un caractère dynamique.
Dans le cadre d’un réseau conforme à l’ARINC 664, cette limitation n’en est pas une puisque la norme impose un caractère statique du réseau, comme indiqué dans le chapitre précédent.. Il sera donc possible d’analyser le réseau avec un modèle unique, en sachant que celui-ci sera valable durant toutes les étapes de la mission de l’aéronef, aussi bien au sol qu’en vol.
Une autre question que l’on peut se poser est de savoir si on possède suffisamment de connaissances sur les différents éléments du réseau, pour permettre l’élaboration d’un modèle
réaliste. Dans le monde de l’Internet, on considère qu’il est difficile d’appliquer le Network Calculus, en partie parce qu’on ne sait pas construire un modèle d’une partie entière du réseau. Bien souvent, les équipements possèdent une grande hétérogénéité, et il n’y a pas d’entité centrale qui connaisse les caractéristiques de tous les connectés au réseau. Le cas d’un réseau avionique est très différent. En effet, il existe toujours un responsable clairement défini pour chacun des différents systèmes. Ainsi, chaque équipementier est responsable de son matériel, et l’avionneur est responsable de l’intégration de tous ces équipements dans l’aéronef. Chaque équipementier peut donc fournir un modèle de son matériel, qui sera forcément précis de par la connaissance complète du matériel par son fabricant. De même, l’avionneur sera capable de fournir un modèle précis de l’interconnexion des différents équipements, puisque c’est lui qui la définit puis la réalise. On voit donc qu’il est possible de modéliser un réseau avionique conforme à l’ARINC 664, et même que ce modèle peut être d’une très bonne précision.
2.2.2 Flux d’entrée
Une autre raison pour laquelle il est difficile d’appliquer le Network Calculus au cas de l’Internet est que le trafic qui y circule est dans la plupart des cas mal connu. De nombreuses recherches actuelles visent à créer à partir de mesures réelles un modèle de ces trafics, ou au moins à catégoriser ces flux en diverses « races » [34]. Dans le cas particulier d’architectures à qualité de service, il est possible de connaître les caractéristiques des flux qui pénètrent le réseau grâce au contrat de trafic qui est lié avec le gestionnaire du réseau lors de l’établissement de connexion (contrôle d’admission). Dans un de ces réseaux, il est possible d’appliquer les résultats du Network Calculus, comme l’a prouvé Le Boudec dans [33]. Cependant, il apparaît clairement que ce genre d’analyses ne peut être faite que dans des cas où le comportement des flux est statique : pas d’admissions de nouveau flux dans le réseau, par exemple. Ceci limite donc les possibilités offertes par cette méthode d’analyse.
Par contre, dans le cas du réseau avionique qui nous intéresse, les conditions se prêtent tout à fait à l’application de la méthode. Les flux sont connus à l’avance, puisque chaque responsable d’équipement qui désire transmettre une donnée sur le réseau doit auparavant en demander l’autorisation auprès du gestionnaire du réseau. Faute de cela, tous ses paquets seraient détruits, puisque appartenant à un flux non identifié. En effet, la norme impose pour les réseaux déterministes de vérifier dans chaque commutateur que toute trame reçue appartient bien à un flux identifié, et de détruire toutes les autres. Au moment de réaliser l’analyse, on sait donc exactement quels sont les équipements susceptibles d’émettre des données à tout moment.
De plus, pour des raisons de sécurité évoquées dans le chapitre précédent, le comportement de ces flux est connu à l’avance. Chacun d’entre eux est tenu à respecter son contrat de trafic, et les éléments du réseau se comportent de sorte que toute infraction est sanctionnée par la perte de paquets. On peut donc appliquer les résultats du Network Calculus sur une caractérisation des flux dont on est sûr qu’elle ne variera pas en cours de mission, et qu’elle décrit bien le pire comportement que puissent avoir ces flux.
A titre d’exemple, on peut considérer le cas d’un contrat de trafic de la forme : le flux n’émettra que des données qui ne feront pas déborder un dispositif de type seau percé. Dans ce cas, on sait qu’alors le flux possède pour enveloppe la droite affine de pente le débit de sortie du seau, et pour ordonnée la taille maximale de ce seau. En fait, il y a même équivalence entre ces deux propriétés.
2.2.3 Topologie du réseau et routage des flux
On a vu dans le paragraphe 1.4 que la méthode de calcul de Cruz pour un réseau entier ne s’applique que dans certains types de réseau : soit tel que la matrice d’interconnexion est
inversible, soit de type « feed-forward ». En regardant ces conditions de plus près, on peut constater qu’elles ne dépendent que de trois paramètres : la topologie des liens physiques qui relient les éléments du réseau, les enveloppes initiales de chacun des flux, et finalement la route qu’empruntent ces flux pour aboutir à leur destination.
Encore une fois, le fait que notre étude se déroule dans le cadre des réseaux avioniques va permettre d’appliquer la méthode de Cruz. En effet, dans un réseau de type Internet personne ne possède le contrôle absolu de la topologie du réseau, et pour des raisons de performance évidentes, le routage y est dynamique. Or une des caractéristiques des réseaux ARINC 664 est qu’il existe un responsable unique, qui possède tout le contrôle du réseau et des flux qui y circulent. Il peut en particulier modifier le plan de raccordement des différents composants du réseau. Il peut également décider quelle sera la route qu’emprunteront les différents flux (on rappelle que les tables de commutation sont fixes). Enfin, il peut fixer les différents contrats de trafic à un niveau qu’il considère adéquat.
On voit donc que le responsable du réseau possède toute latitude pour concevoir un réseau tel qu’il sera aisé d’y appliquer la méthode de calcul de Cruz.
On a présenté ici les raisons pour lesquelles il est possible d’appliquer le Network Calculus à un réseau avionique : il est possible d’en construire un modèle fidèle, le trafic en entrée du réseau est contraint, et la topologie et le routage y sont très adaptés à la méthode envisagée. On souligne l’importance du rôle central joué par l’avionneur, qui possède toute la connaissance du réseau ; cela constitue la principale différence avec des réseaux plus libres ou hétérogènes, tels qu’Internet où n’existe pas de contrôle central.
Nous présentons dans la partie suivante la façon d’appliquer le Network Calculus dans notre contexte.