les données capturées sont ensuite envoyées à un autre nœud qui est chargé de l’agré- gation et de la transmission vers la station de base. Même si quelques nœuds tombent en panne, tant qu’il reste encore des nœuds opérationnels dans la zone, nous pouvons continuer à surveiller la zone malgré une perte de précision envisageable.
5.4.2/ RÉPLICATION PASSIVE
Quant à la réplication passive, nous mettons en place plusieurs nœuds aussi pour assurer la même fonctionnalité, mais seul le nœud principal est utilisé pour la réception et le traitement de tâches. Les données sont synchronisées entre le nœud principal et les nœuds de secours, c’est-à-dire que les nœuds de secours reçoivent aussi les tâches, mais ils restent inactifs tant que le nœud principal est encore opérationnel.
Lorsque le nœud principal tombe en panne, nous devons en choisir un parmi les nœuds de secours pour prendre le relais. La réplication passive est souvent considérée comme le choix optimal pour les réseaux de capteurs, car les nœuds de secours ne consomment pas beaucoup de ressource tant qu’aucune panne n’est détectée. L’application de la ré- plication passive est réalisée selon 3 phases, qui sont respectivement la détection de
5.4. TECHNIQUES DE RESTAURATION 95
pannes, la sélection du nœud principal et la distribution de service. La première phase est déjà discutée dans la section 5.3, et les 2 autres sont présentées ci-dessous.
5.4.2.1/ SÉLECTION DE NŒUD PRINCIPAL
Les nœuds sont programmés et déployés pour fournir des services, lorsqu’un nœud est en panne, il faut que nous trouvions un autre qui peut le remplacer, et le nœud sélec- tionné devient le nouveau fournisseur de services. Il existe plusieurs approches dans la littérature :
5.4.2.2/ SÉLECTION EN GROUPE
Comme la plupart des protocoles de routage basés sur le clustering [36, 35], le cluster- head est chargé de la récupération et la transmission des données collectées par les autre nœuds qui se situent dans le même cluster, et il est logique que le cluster-head consomme plus de ressources et sa pile se vide plus vite par rapport aux autres membres du cluster, notamment dans des réseaux homogènes, les cluster-heads ne détiennent pas plus de ressources que les autre membres. Lorsque le niveau d’énergie restante du cluster-head est très faible, il faut que les autres nœuds lancent un vote en prenant compte les paramètres cruciaux (énergie, distance, connexion etc.) pour choisir un nou- veau cluster-head.
5.4.2.3/ RÉAFFECTATION DE MEMBRES
À partir d’un réseau de capteurs hétérogène dont les nœuds sont regroupés en clus- ters, et où les cluster-heads déployés sont plus puissants que les membres ordinaires, nous ne changeons pas de cluster-head. Chaque membre d’un cluster doit stocker non seulement l’identifiant de leur cluster-head actuel, mais aussi celui de son cluster-head de secours. Normalement le cluster-head de secours est le cluster-head d’un autre clus- ter qui se trouve à proximité. Quand le cluster-head actuel ne peut plus fonctionner, le membre envoie une demande à son cluster-head de secours pour être réaffecté au nou- veau cluster [31].
5.4.3/ DISTRIBUTION DE SERVICES
Une fois le nouveau nœud sélectionné, il faut qu’il soit immédiatement activé, et qu’il détienne toutes les informations nécessaires pour continuer le traitement de tâches. Dans certaines applications, les nœuds déployés utilisent le même code, et les données sont synchronisées entre le nouveau et l’ancien nœud principal, il suffit alors de donner un simple message au nouveau nœud pour lui signaler le changement de rôle. Dans les autres cas, par exemple lorsque les nœuds n’ont pas assez de mémoire pour stocker le code de tout type de service, il faut donc que le code manquant soit distribué au nouveau nœud principal, et qu’il soit reprogrammé pour s’adapter à la nouvelle fonctionnalité.
96 CHAPITRE 5. TOLÉRANCE AUX PANNES DANS LES RCSF
5.4.3.1/ DISTRIBUTION DE CODES
Il s’agit de la dissémination des morceaux de code dans le réseau. Dans [56], un inter- préteur de bytecode pour Tinyos est développé et installé sur des nœuds, et les pro- grammes sont décomposés en morceaux de 24 instructions. Lorsqu’une mise à jour de code est demandée, les morceaux de code du nouveau programme sont envoyés et ins- tallés sur le nœud qui les exécute avec l’interpréteur. Cependant cette méthode demande une connexion assez fiable, car il faut que le programme à installer soit entièrement ache- miné chez son destinataire. Le nœud ne peut pas se lancer tant que le programme utilisé n’est pas correctement mis à jour.
5.4.3.2/ DISTRIBUTION DE TÂCHES
Les programmes installés sur les nœuds sont identiques et seules les données représen- tant les tâches à effectuer sont envoyées au nouveau nœud sélectionné.
Les nœuds utilisent toujours le même programme qui peut être configuré en fonction de différents besoins. Pour modifier les fonctionnalités d’un nœud, il suffit de lui fournir l’ensemble des informations de configuration pour les nouvelle tâches.
Deluge [37] est une architecture spécifiquement conçue pour la dissémination de don- nées. Les données sont représentées par des objets, qui sont sérialisés et divisés en pages de taille identique, et chacune est encore constituée d’un certain nombre de pa- quets (voir figure 5.5). Le paquet est l’unité la plus petite utilisée dans Deluge, et chacun est numéroté avec un nombre représentant la version des données qu’il contient.