TTEthernet et outils de simulation

TTEthernet est actuellement une technologie réseau très sollicitée par plusieurs secteurs de pointes tels que l’industrie automobile et l’aérospatiale vu la réponse qu’elle apporte aux défis auxquels sont confrontées les nouvelles applications en matière de bande passante, de fiabilité et de services temps-réels. Cependant, comme toute technologie récente, de grands efforts de modélisation, de vérification formelle et surtout de simulation sont encore requis afin de contrôler et de s’assurer des performances du nouveau protocole.

Introduction à TTEthernet 

TTEthernet ou Time-Triggered Ethernet est une extension temps-réel du protocole Ethernet standard. Elle a été spécifiée par TTTech en collaboration avec Honeywell et standardisée ensuite sous le nom SAE AS6802 (SAE, 2011) par la société SAE (Society of Automotive Engineers). Elle est conçue pour supporter la transmission de flux de données de différentes criticités temporelles au sein du même réseau.

TTEthernet fournit trois services de communication reliés à trois classes de trafic ayant des exigences temporelles différentes :

Le service à déclenchement temporel associé à la classe de trafic Time-Triggered (TT) est celui de plus haute criticité : il permet de garantir une transmission avec une faible gigue et une latence limité. Ceci est réalisable grâce au maintien d’une synchronisation globale entre les différents nœuds du réseau et au suivi, de même, d’un plan de communication globale permettant d’éviter les conflits entre les différents messages TT.

Un deuxième service de criticité moyenne est assuré par TTEthernet. Il concerne le trafic Rate Constrained (RC). Ce service garantit une bande passante de bout en bout et, contrairement au trafic TT, il est asynchrone. Sa latence maximale peut être calculée hors ligne et elle est souvent beaucoup plus élevée que la latence du trafic TT. Cela revient essentiellement au temps d’attente qu’encourent les messages RC dans les files d’attentes des commutateurs à travers le réseau.

Finalement, le trafic le moins critique est transmis selon l’approche best effort d’Ethernet, sans garantie de délai ou de réception. Cette classe de trafic est nommée également Best Effort (BE).

Structure d’un réseau TTEthernet 

Un réseau TTEthernet est composé de terminaux et de commutateurs. Les terminaux se connectent aux commutateurs avec des liaisons bidirectionnelles. Les commutateurs peuvent se connecter entre eux dans une configuration à sauts-multiples. La structure d’un réseau TTEthernet est conforme avec celle d’Ethernet commuté et suit par conséquent une topologie en étoile.

La prise en charge du mécanisme de tolérance aux fautes impose au réseau TTEthernet une organisation disjointe et redondante à concurrence de trois canaux de communication pour les implémentations actuelles. La tolérance aux fautes est requise dans les systèmes à hautesûreté tels que les avions civils et les vaisseaux spatiaux qui doivent rester fonctionnels même avec la présence d’échecs.

Les protocoles de TTEthernet 

Afin de pouvoir assurer une communication Time-Triggered, TTEthernet doit accorder une grande importance à établir et maintenir une base de temps commune entres les différents équipements du réseau tout en tenant compte des éventuels échecs qui peuvent surgir aux niveaux des commutateurs et des terminaux.

La base de temps commune est une condition nécessaire pour garantir le caractère déterministe au trafic TT et de même, satisfaire l’exigence d’une communication à faible gigue et une latence fixe. La synchronisation étroite va permettre aussi aux différents nœuds de suivre un plan de communication commun, calculé au préalable.

Pour réaliser ces objectifs, TTEthernet recourt, d’abord, au protocole startup. Ceci permet d’établir une synchronisation suite à une mise en marche ou un redémarrage. Un protocole de synchronisation d’horloges maintient la synchronisation en corrigeant périodiquement les déviations possibles d’horloges.

Enfin, un protocole de détection de cliques permet de diagnostiquer les services et de détecter les composants défaillants. Ceci permet d’isoler les éléments défaillants hors du processus de synchronisation et de résoudre certaines perturbations transitoires du réseau.

Dans tous ces protocoles, chaque nœud est assigné à un rôle particulier :
• Synchronization Masters (SM)
• Compression Masters (CM)
• Synchronization Clients (SC)

Typiquement, les SMs sont des terminaux, les CMs sont des commutateurs, alors que les SCs peuvent être, indifféremment, des commutateurs ou des terminaux.

Les SMs assurent la mise en marche du réseau et le maintien de sa synchronisation: initialement, ils débutent le protocole startup et une fois que le réseau est stabilisé, ils déclenchent périodiquement la synchronisation d’horloges afin de préserver la base de temps commune atteinte au préalable grâce au protocole startup.

Le démarrage de tous les protocoles est marqué par l’envoi de messages de contrôle PCFs. Ce sont des messages de haute priorité transportant des informations de synchronisation d’un ou plusieurs SMs vers les CMs. Chaque CM collecte les PCFs de tous les SMs dont il est connecté, il les filtre et effectue leur traitement. Un nouveau message PCF est créé et sera renvoyé par la suite à tous les nœuds du réseau.

Les SCs ont un rôle passif aux startups et synchronisation d’horloges. Ils se contentent d’écouter la communication et de se synchroniser avec le reste du réseau à la réception d’un PCF valide.

Table des matières

INTRODUCTION 
CHAPITRE 1 TTETHERNET ET OUTILS DE SIMULATION 
1.1 Introduction
1.2 Introduction à TTEthernet
1.2.1 Structure d’un réseau TTEthernet
1.2.2 Les protocoles de TTEthernet
1.3 Environnement de simulation OMNeT++
1.3.1 Introduction à OMNeT++
1.3.2 Structure d’un modèle OMNeT++
1.3.3 Le langage de description de réseau (NED)
1.3.4 Programmation des modules simples
1.3.5 Bibliothèques
1.3.5.1 Bibliothèques de modèles
1.3.5.2 La bibliothèque de simulation
1.3.6 Architecture interne
1.4 Comparaison avec OPNET et NS
1.5 Yices
1.5.1 Architecture
1.5.2 Les solveurs
1.5.3 Utilisation de Yices
1.6 Conclusion
CHAPITRE 2 TTETHERNET : PRINCIPES ET REVUE DE LITTÉRATURE 
2.1 Introduction
2.2 Gestion de trafics TTEthernet
2.2.1 Les différents types de trafic
2.2.1.1 Trafic Time-Triggered (TT)
2.2.1.2 Trafic Rate Constrained (RC)
2.2.1.3 Trafic Best-Effort (BE)
2.2.2 Méthodes d’intégration de trafics
2.2.2.1 Préemption
2.2.2.2 Blocage en temps opportun (Timely Block)
2.2.2.3 Brassage
2.2.3 Discussion
2.3 Algorithmes de synchronisation et tolérance aux fautes
2.3.1 Synchronisation d’horloges
2.3.1.1 La fonction de permanence
2.3.1.2 La fonction de convergence à deux étapes
2.3.1.3 Protocole Startup/Restart
2.3.2 Tolérance aux fautes
2.3.2.1 Le modèle Central Gardian
2.3.2.2 Le modèle High-Integrity
2.3.3 Discussion
2.4 Les différents modèles de simulation de TTEthernet
2.4.1 Modèle de CoRE4INET
2.4.1.1 Concepts et modèles
2.4.1.2 Implémentation
2.4.2 Modèle TTEthernet pour OPNET
2.4.2.1 Modèle du terminal TTEthernet
2.4.2.2 Modèle du commutateur TTEthernet
2.4.2.3 Blocs d’injection de fautes
2.4.3 Discussion
2.5 Programmation par contraintes et planification globale de tâches dans un réseau TTEthernet
2.5.1 Programmation par contraintes
2.5.1.1 Le réseau de contraintes
2.5.1.2 Les algorithmes de filtrage
2.5.1.3 Mécanisme de propagation
2.5.1.4 Modélisation et mécanisme de recherche de solutions
2.5.1.5 Optimisation d’un problème de satisfaction de contraintes
2.5.2 Planification globale de tâches dans un réseau TTEthernet
2.5.2.1 Présentation du problème
2.5.2.2 Concepts et notions de bases
2.5.2.3 Spécification formelle des contraintes de planification TTEthernet
2.5.3 Discussion
2.6 Conclusion
CHAPITRE 3 RÉALISATION D’UN MODÈLE DE SIMULATION TTETHERNET 
3.1 Introduction
3.2 Réalisation des blocs fonctionnels du modèle TTEthernet
3.2.1 Exigences temps réel
3.2.2 Réalisation de la topologie
3.2.3 Modèle d’horloge
3.2.4 Modèle du commutateur
3.2.5 Modèle du terminal
3.3 Élaboration d’un plan de transmission global pour les trames TT
3.3.1 Identification des besoins de la simulation en termes de planification
3.3.2 Adaptation de la planification des tâches pour la simulation
3.3.2.1 Détermination de la limite temporelle des instants d’envoi
3.3.2.2 Adaptation de la contrainte de non-conflits
3.3.2.3 Autres contraintes
3.3.2.4 Génération des résultats
3.4 Conclusion
CHAPITRE 4 EXPÉRIMENTATION ET RÉSULTATS 
4.1 Introduction
4.2 Environnement de travail
4.3 Validation du comportement du système
4.3.1 Gestion de flux
4.3.1.1 Configuration et méthodologie
4.3.1.2 Résultat
4.3.2 Distribution de flux
4.3.2.1 Configuration et méthodologie
4.3.2.2 Résultat
4.3.3 Correction de l’horloge
4.4 Etude de cas : Impact de l’agencement des périodes d’envoi des trames TT sur la transmission de l’ensemble des trafics TTEthernet.
4.4.1 Configuration et méthodologie
4.4.2 Premier cas d’utilisation : Agencement contigu des send_pits
4.4.3 Deuxième cas d’utilisation: Agencement distribué des send_pits
4.4.4 Discussion des résultats
4.5 Limites et perspectives
4.6 Conclusion
CONCLUSION

Télécharger le rapport complet