Approches Proposées
Chapitre 5 Approche d’ordonnancement
fiable de communication basée sur
la fragmentation variable de
données
Sommaire
5.1 Introduction . . . . 60
5.2 Présentation du problème . . . . 61
5.3 RBF-VDF : Un algorithme d’ordonnancement tolérant aux
fautes des bus de communications basé sur la fragmenta-tion variable des données. . . . . 63
5.3.1 Taux Global de défaillance du système (TGDS) . . . . 63
5.3.2 Tolérance aux fautes des processeurs par la redondance PP(Passive-Passive) : . . . . 64
5.3.3 Tolérance aux fautes des bus de communication par redon-dance Passive : . . . . 69
5.3.4 Fragmentation variable des données :. . . . 70
5.3.5 Ordonnacement tolérant aux fautes des processeurs et des bus de communication . . . . 77
5.4 Réduction de la Consommation d’énergie . . . . 80
5.5 Exemple et Simulations. . . . 81
5.5.1 Exemple . . . . 81
5.5.2 Simulations . . . . 83
5.6 Conclusion . . . . 84
Dans ce chapitre nous présentons une nouvelle technique d’ordonnancement to-lérant aux fautes pour les systèmes temps réel embarqués, l’approche d’ordonnan-cement que nous proposons est dédiée aux architectures hétérogènes multi-bus, qui prennent en entrée une description donnée du système et un ensemble d’hypothèses de fautes.
Notre solution est basée sur la fragmentation variable des données [52] [51], la redondance passive des communications et la redondance PP (passive-passive) des
tâches, ce qui permet une détection/retransmission rapide des fautes et donc une utilisation efficace de l’architecture multi-bus.
Au cœur de notre solution, une heuristique de liste d’ordonnancement basée sur le TGDS1 [91] : Taux Global de défaillance du système et la fragmentation variable des données. La taille de chaque fragment de données dépend du TGDS et donc indirectement des taux de défaillance de chaque bus λBi, ce qui permet une communication tolérante aux fautes pour un système à fiabilité maximalisée.
5.1 Introduction
Les techniques de tolérance aux fautes sont nécessaires pour s’assurer que le sys-tème continue à fournir un service correct en dépit de fautes [92] [93]. Une faute peut affecter soit le matériel soit le logiciel du système, nous avons choisi de se concen-trer sur les pannes matérielles, plus particulièrement, nous considérons les pannes des bus de communications. Un bus est une connexion multi-point, caractérisée par un support physique qui connecte tous les processeurs de l’architecture. Comme nous ciblons les systèmes embarqués avec des ressources limitées (pour des raisons de poids, encombrement, consommation d’énergie, ou les contraintes de prix), nous nous intéressons uniquement à des solutions de redondance logicielle.
Modèle Modèle Modèle de Tâches M dèl de Tâches Modèle de Tâches Modèle d’Architect re d’Architecture d Architecture Redondance Al ith Redondance Algorithme C t i t Algorithme PP (Passive
Contraintes Algorithme PP (Passive‐
Contraintes (
P i )
d’ d
d’ordonnancement d’ordonnancement Passive)
d’ordonnancement, d ordonnancement Passive)
d ordonnancement, d'Exécution et ded Exécution et de d ordonnancement tolèrent aux fautes
é l tolèrent aux fautes
Temps Réel tolèrent aux fautes
Temps Réelp Redondance Redondance Passive Passive F i Fragmentation Fragmentation bl Variable TGDS Variable TGDS O d t Ordonnancement Ordonnancement lé
Tolérant aux Fautes Tolérant aux Fautes
Figure 5.1 – Approche Proposée.
L’approche que nous proposons (Figure 5.1) est basée sur la fragmentation va-riable des données, où la taille de chaque fragment est calculer en fonction des états
5.2. Présentation du problème 61
des bus a l’aide des deux fonctions de coût TGDS et σ (schedule pressure), elle permet de tolérer une ou plusieurs fautes temporelles des processeurs et des bus de communication. Il s’agit de résoudre le problème de la recherche d’un ordon-nancement des composants logiciels du modèle de tâches GTask sur les composants matériels du modèle d’architecture GArch, qui tolère NfProc2 fautes de processeurs et NfBus3 fautes de bus de communication, tout en minimisant la longueur de l’ordon-nancement afin de satisfaire la contrainte temps réel CRt(La prédictibilité consiste à vérifier hors-ligne que les contraintes temporelles sont respectées en absence et en présence de défaillances.)
Afin de bien présenter notre solution, voici tout d’abord le modèle de fautes que nous considérons dans ce chapitre.
5.2 Présentation du problème
Le but de ce chapitre est de résoudre le problème de la recherche d’un ordon-nancement des composants logiciels du modèle de tâches GTask sur les composants matériels du modèle d’architecture GArch qui doit tolérer des fautes matérielles des processeurs et des bus de communication, tout en minimisant la longueur de l’or-donnancement dans le but de satisfaire la contrainte temps réel CRt en absence et en présence de défaillances.
Nous ne nous intéressons dans ce travail qu’aux techniques de tolérance aux fautes matérielles basées sur des solutions logicielles, plus spécifiquement aux fautes des bus de communication. Notre solution est liée aux hypothèses de défaillances définies par le modèle de fautes suivant (c’est le raffinement du modèle présenté dans2.5.3), dans lequel nous supposons que :
1. L’algorithme est fiable et sans fautes (c’est à dire que le logiciel à été validé par des techniques de tolérance aux fautes logiciels [94] [95] : model-cheking, démonstration de théorèmes, traitement des exceptions, ...)
2. Les fautes matérielles sont des fautes des processeurs et des fautes des bus de communication. La défaillance d’un bus de communication peut être partielle ou complète. La défaillance complète d’un bus est la conséquence de la dé-faillance de tous ses communications, tandis que la dédé-faillance partielles est la conséquence d’une ou plusieurs défaillance des ses communications à condition qu’au moins deux de ses communications restent actifs.
3. Le système accepte au plus NfProc fautes des processeurs et NfBus fautes de bus de communications dans un cycle d’exécution de son modèle de tâches sur son architecture, et que l’architecture comprend plus de NfBus bus.
2. NfProc= Nombre de fautes de processeurs tolérées. 3. NfBus= Nombre de fautes de bus tolérées.
4. Nous considérons seulement les fautes de bus transitoires [96], qui persistent pendant une durée limitée, ce type de fautes est beaucoup plus fréquent que d’autres. Les fautes permanentes sont un cas particulier de fautes transitoires. 5. Les processeurs et les bus de communication sont à défaillances temporelles, c’est-à-dire que les valeurs calculées par les opérateurs de calcul sont soit cor-rectes et délivrées à temps, soit corcor-rectes et délivrées trop tôt, trop tard ou infiniment tard.
Enfin, notre modèle de fautes en ce qui concerne les défaillances temporelles couvre les deux hypothèses de défaillances les plus utilisées, a savoir : hypothèse de défaillances par omission et hypothèse de silence sur défaillances [97].
Le problème de la recherche d’un ordonnancement peut être formalisé comme suit :
Les Données du problème :
• Une architecture matérielle hétérogène GArch composée d’un ensemble EProc d’opérateurs de calcul (processeurs) et d’un ensemble EBus de bus de commu-nication :
EProc = {. . . , Pi, . . .}, EBus = {. . . , Bj, . . .}
• Un modèle de tâche GTask composé d’un ensemble ETask d’opérations (tâches) et d’un ensemble EDd de dépendances de données :
ETask = {. . . , ti, . . . , tj, . . .}, EDd = {. . . , (ti → tj), . . .}
• Des caractéristiques d’exécution Ext des composants de GTask sur les compo-sants de GArch,
• Un ensemble de contraintes matérielles CHad, • Une contrainte temps réel CRt,
• Un critère de minimisation de la longueur de l’ordonnancement,
• Un nombre NfProc de fautes de processeurs et un nombre NfBus de fautes de bus de communication qui peuvent causer la défaillance du système,
L’objectif : C’est la définition d’une application App dont le rôle est d’ordon-nancer chaque tâche et chaque dépendance de données de GTask sur les processeurs et les bus de GArch l’ordonnancement est réaliser par l’affectation d’un ordre d’exé-cution ORDk d’une tâche sur un processeur, ou d’une dépendance de donnée sur un bus.
App : GTask −→ GArch
GTask i 7−→ A(GTask i) = (GArch j, ORDk)
App respecte CHad , minimise la longueur de l’ordonnancement afin de satisfaire CRt et tolérer NfProc+NfBus fautes de processeur et de bus de communication.
5.3. RBF-VDF : Un algorithme d’ordonnancement tolérant aux fautes des bus de communications basé sur la fragmentation variable des
données. 63