Caractéristiques des systèmes avioniques

Idéalement les expériences seraient effectuées dans un environnement avionique afin d’obtenir des résultats qui représentent bien les performances d’un intergiciel DDS dans un tel environnement. Cependant, on n’a pas accès à un environnement avionique dans notre laboratoire de recherche, donc les performances de l’intergiciel DDS sont effectuées sur des ordinateurs personnels avec le système d’exploitation Windows 7. De ce fait, on a émis l’hypothèse que les performances observées en effectuant les même tests dans un environnement avionique seraient meilleures que dans l’environnement Windows 7. Cette hypothèse se base sur l’article de (Schmidt, Deshpande et O’Ryan, 2002) dans lequel les auteurs font des tests de latence avec un intergiciel de communication RT-CORBA, et ce, avec différents systèmes d’exploitation. Les résultats de cet article montrent que la latence moyenne et la gigue obtenue avec un système d’exploitation temps réel tel que QNX et VxWorks sont plus petites que ce qui est obtenu avec un système d’exploitation Windows .

Dans ce chapitre, les métriques de performances qui seront évaluées sont la latence ainsi que le débit de données. Les performances de latence de la communication sans l’utilisation d’un intergiciel DDS sont tout d’abord mesurées. Ces performances servent de base de comparaison pour mesurer l’impact de l’utilisation d’un intergiciel DDS sur la latence d’une communication. Par la suite, un intergiciel DDS est ajouté au scénario de test et les performances de latence de la communication sont mesurées. Ces dernière sont ensuite comparées aux performances de la communication sans intergiciel ainsi qu’aux performances généralement désirées dans le domaine avionique. Finalement, des tests d’utilisation de la bande passante de l’intergiciel DDS avec différentes tailles de paquets sont effectués.

Caractéristiques de Connext Micro

Les implémentations d’intergiciel DDS ne sont pas toutes identiques, donc cette section porte sur les différentes caractéristiques propres à Connext Micro. Cette section présente les caractéristiques qui sont pertinentes à l’utilisation de Connext Micro ainsi qu’à la compréhension des résultats obtenus.

Limitations particulières de Connext Micro

Étant donné que Connext Micro est un produit qui est encore en développement, il ne supporte pas encore toutes les fonctionnalités qui sont définies dans la norme DDS.

Il est important de mentionner que Connext Micro ne supporte que le transport UDPv4. De plus, Connext Micro ne supporte pas toutes les QoS définies dans la norme DDS. Les QoS qui ne sont pas du tout supportée ainsi que celles qui ne sont supportées.

Opération de Connext Micro dans le modèle OSI 

Afin de comprendre les limitations possibles de l’intergiciel Connext Micro, une présentation de son opération sur les différentes couches du modèle OSI est présentée. Connext Micro opère sur les couches OSI suivantes: la couche application (7), la couche de présentation (6), la couche de session (5) et la couche de transport (4) (Real Time Innovation, 2013) .

De ce fait, Connext Micro doit utiliser une couche de réseau (3), une couche de liaison (2) et une couche physique (1) qu’il ne contrôle pas directement afin de fonctionner. Cela implique que les performances obtenues par Connext Micro ne sont pas entièrement sous son contrôle puisqu’elles dépendent également des limitations de ces couches. Les limitations peuvent, par exemple, être une limite de débit de données ainsi qu’une latence minimale qui est causée par les couches 1 à 3. De plus, certaines QoS offertes par Connext Micro sont également dépendantes de ces couches.

Modèle de fils d’exécution de Connext Micro

Afin de comprendre les interactions entre l’intergiciel DDS et les applications usager, une description des différents fils d’exécution (threads) utilisés par l’intergiciel est nécessaire. Les participants au domaine utilisent trois types de fils d’exécution soit les fils d’exécution de base de données, les fils d’exécution d’évènement et les fils d’exécution de réception. Il est possible de changer la priorité des différents fils d’exécution à partir des différentes QoS offertes par l’intergiciel DDS. Cette option est particulièrement utile pour les applications temps réel dans lesquelles changer la priorité des différents fils d’exécution au sein d’une application est généralement désirable afin d’obtenir les performances voulues. Cette section présente donc les différents fils d’exécution de Connext Micro.

Fil d’exécution de base de données
Ce fil d’exécution contient la base de données des informations sur les différentes entités connues par le participant au domaine. Ce type de fil d’exécution n’ayant aucun impact sur les performances des communications, il est préférable de lui allouer une faible priorité.

Fil d’exécution d’évènement
L’intergiciel DDS doit périodiquement vérifier l’état de plusieurs événements périodiques ou bien des événements activés par interruptions. Plusieurs polices de QoS utilisent ce fil d’exécution pour faire leurs vérifications tel que la police de délai d’envois/réception ainsi que la police de vivacité. De plus, la réception de données asynchrones à l’aide des récepteurs (listener) est effectuée dans le fil d’exécution d’événement. De ce fait, il important d’attribuer une haute priorité à ce fil d’exécution afin d’obtenir de faibles latences.

Fil d’exécution de réception
Ce fil d’exécution sert a désérialiser et enregistrer les paquets dans la queue de réception lors de la réception de ces derniers. De plus, il se charge également de traiter les paquets du processus de découverte. Il est possible d’avoir plusieurs de ces fils d’exécution par participants au domaine en fonction des QoS des participants, lecteurs et écrivains. Par défaut, il y a deux fils d’exécution de réception créés pour le processus de découverte et deux pour les données utilisateur. Pour faire une analogie avec les sockets UDP, il y a un fil d’exécution de réception de créé par socket UDP utilisé. Afin d’obtenir de faibles latences, il est préférable de donner une priorité élevée à ces fils d’exécution.

Réception de données avec Connext Micro 

L’intergiciel Connext Micro supporte deux méthodes d’accès aux données ainsi que trois méthodes de réception des données. Les méthodes d’accès supportées sont l’accès par lecture et l’accès par retrait. L’accès par lecture ne fait que lire la donnée dans la queue de réception et laisse cette donnée disponible pour les autres lecteurs alors que l’accès par retrait enlève la donnée de la queue de réception ce qui fait qu’aucun autre lecteur ne peut accéder à cette donnée. Seulement l’accès par retrait est abordé dans cette sous-section puisque c’est cette méthode d’accès qui a été utilisée pour l’ensemble de cette recherche.

Table des matières

INTRODUCTION 
CHAPITRE 1 REVUE DE LA LITTÉRATURE 
1.1 Systèmes avioniques
1.1.1 Caractéristiques des systèmes avioniques
1.1.2 Architectures des systèmes avionique
1.2 Consortium FACE
1.3 Domaines d’applications des intergiciels DDS
1.3.1 Diverses utilisations d’intergiciels DDS
1.3.2 Utilisation d’un intergiciel DDS en avionique
1.3.3 Évaluation des performances d’intergiciels de communication
1.4 Système automatique de contrôle de vol (AFCS)
1.4.1 Architecture d’un autopilote
1.4.2 Contrôle d’un aéronef
1.4.3 Contrôleurs pour boucles de contrôle de vol
1.4.4 Contrôleur PID
1.5 Protocole UDP/IP
1.6 Conclusion
CHAPITRE 2 ANALYSE DE LA NORME DDS 
2.1 Objectifs de la norme DDS
2.2 Paradigmes de messagerie
2.2.1 Messagerie point à point
2.2.2 Messagerie client-serveur
2.2.3 Messagerie publication/souscription
2.3 Définition d’un intergiciel DDS
2.4 Couche DCPS
2.4.1 Entités DDS
2.4.2 Configuration de l’intergiciel avec les QoS
2.5 Protocole de communication RTPS-DDS
2.5.1 Processus de découverte
2.5.2 Protocole de découverte des participants (PDP)
2.5.3 Protocole de découverte des points d’arrivée (EDP)
2.5.4 Configuration du processus de découverte
2.6 Communication entre les entités DDS
2.7 Autres intergiciels de communication
2.8 Choix de l’intergiciel DDS
2.9 Conclusion
CHAPITRE 3 CARACTÉRISATION DES PERFORMANCES DE L’INTERGICIEL 
3.1 Caractéristiques de Connext Micro
3.1.1 Limitations particulières de Connext Micro
3.1.2 Opération de Connext Micro dans le modèle OSI
3.1.3 Modèle de fils d’exécution de Connext Micro
3.1.4 Réception de données avec Connext Micro
3.2 Métriques de performances utilisées
3.3 Environnement d’expérimentation
3.4 Mesure des performances de latence
3.4.1 Requis de latence des communications en avionique
3.4.2 Mesure de la latence sans intergiciel DDS
3.4.3 Mesure de la latence avec intergiciel DDS (Réception par sondage)
3.4.4 Mesure de la latence avec intergiciel DDS (Réception asynchrone)
3.4.5 Comparaison des performances de latence
3.5 Mesure du débit de données
3.6 Conclusion
CHAPITRE 4 ÉTUDE DE CAS D’UN AFCS POUR UN BOEING 747-400 
4.1 Simulateur de vol X-Plane
4.1.1 Mécanismes d’entrées/sorties
4.1.2 Caractéristiques du Boeing 747-400
4.2 Méthodologie d’expérimentation
4.3 Conception de l’AFCS avec MatLab/Simulink
4.3.1 Environnement d’expérimentation
4.3.2 Conception du contrôleur de roulis
4.3.3 Conception du contrôleur de tangage
4.3.4 Conception du contrôleur de vitesse
4.3.5 Conception du contrôleur d’altitude
4.4 Test de l’AFCS sur des PC sans intergiciel DDS
4.4.1 Scénarios de tests
4.4.2 Analyse des résultats
4.5 Test de l’AFCS sur des PC avec intergiciel DDS
4.5.1 Conception d’un plug-in DDS pour X-Plane
4.5.2 Scénarios de tests
4.5.3 Analyse des résultats
4.6 Test de l’AFCS avec intergiciel DDS sur la plateforme FreeScale
4.6.1 Plateforme FreeScale MPC8572DS
4.6.2 Environnement de test
4.6.3 Scénario de test
4.6.4 Analyse des résultats
4.7 Conclusion
CHAPITRE 5 REDONDANCE EN UTILISANT UN INTERGICIEL DDS 
5.1 Redondance de réserve
5.2 Scénario de test
5.3 Analyse des résultats
5.4 Conclusion
CONCLUSION

Télécharger le rapport complet