3.2 Une approche architecturale matérielle pour les systèmes auto-organisés
3.2.3 La structure du flux local
La figure3.6illustre la composition d’un flux pour un système constitué de 4 entités. Un flux
est composé de plusieurs champs tels que les champs de début « BEGIN » et de fin « END ». Le critère fondamental de la constitution d’un flux est qu’il dispose d’un ou plusieurs champs permettant son identification en tant que flux, dans le but de le distinguer d’autres données cir-culant au sein du système. Hormis les champs de début et de fin, le nombre de champs dans un flux informationnel est proportionnel au nombre d’entités qu’il informe ou renseigne dans son parcours entre les entités et au sein du système. Ce parcours peut être prédéfini au cours de la conception. Le nombre de champs peut également être étendu dynamiquement en
fonc-E2
ENTITE ENTITE E3 ENTITE E4 END BEGIN ENTITE E1
E2 ETATS ID
FLUX
FIG. 3.6 – Structuration en champs d’un flux informationnel couvrant un groupement de quatre
3.2. Une approche architecturale matérielle pour les systèmes auto-organisés
tion de nouveau champ informationnel nécessaire au cours du temps et du nombre d’entités associées au flux. A chaque entité du système correspond un champ dans le flux
information-nel. Plus précisément, un champ du flux informationnel contient le numéro d’identification (ID)
de l’entité associée à ce champ et plusieurs sous-champs. Ces sous-champs sont réservés pour contenir des informations sur l’état global de fonctionnement de l’entité considérée. Le nombre de sous-champs dans un champ du flux informationnel n’est pas limité et dépend principale-ment du nombre d’états possibles qu’une entité peut prendre. Un état correspond soit à un mode
opératoire d’une entité à un instanttdonné (par exemple, une entitéEiau cours de
fonctionne-ment et d’attente de données de l’entitéEj, entité en arrêt, etc.), soit à une fonction en cours
d’exécution. Les sous-champs d’un flux informationnel peuvent contenir des informations sur la fonctionnalité d’une entité si un module de vérification de fonctionnalité est implémentée est implanté dans l’entité considérée.
MDFA MDFS VF P Ei ETATS ID
Mode de fonctionnement actuel
Présence
Mode de fonctionnement souhaité Vérification fonctionnelle
FIG. 3.7 – Structuration en sous-champs d’un flux informationnel couvrant un groupement de
quatre entités d’un système auto-organisé proposé.
La figure 3.7 illustre un exemple de structuration d’un champ du flux informationnel
cou-vrant un groupement de quatre entités d’un système auto-organisé. Dans ce cas d’exemple, chaque champ du flux informationnel, hormis les champs de DEBUT (BEGIN) et de FIN (END), sont constitués de 4 sous-champs. Le premier sous-champ, nommé PRESENCE, indique la pré-sence ou non physique d’une entité dans le système. Ainsi, si ce sous-champ contient la valeur nulle, cela signifie pour les autres entités couvertes par le même flux informationnel que cette entité sera supprimée physiquement du système et substituée par une autre entité ou module de calcul. Dans le cas d’une valeur égale à ’1’ de ce champ, cela signifie que l’entité associée à ce sous-champ au sein du système reste sur puce. Dans le cas où ce sous-champ est de valeur nulle, cette situation présente le cas le plus exigeant en terme d’auto-organisation. En effet, dans ce cas de figure, les entités voisines de l’entité considérée doivent se répartir sa fonction de calcul
au moment de sa désinstallation du système. Un autre exemple de sous-champs présenté dans la
figure3.7est le sous-champ analyse fonctionnelle VF. Ce sous-champ indique aux entités
voi-sines que l’entité associée à ce sous-champ, fonctionne correctement. Plus précisément, afin que les sous-champs d’un flux informationnel puissent contenir les informations relatives à l’exacti-tude des données fournies par une entité, chaque entité doit posséder un module de vérification
fonctionnelle en relation avec le sous-champ VF. De même que pour l’option PRESENCE, la vérification fonctionnelle présente également un cas d’exigence d’un point de vue
organisation-nel du système. En effet, si le sous-champ VF indique à travers le flux informationorganisation-nel que les données fournies par une entité sont erronées, l’entité considérée et associée à ce sous-champ doit être remplacée. En pratique, la mise en œuvre de telle procédure nécessite l’implantation de structures fonctionnelles redondantes. L’ensemble de ces sous-champs présentés dans la figure
3.7 sont considérés optionnels et leur emploi est décidé par le concepteur selon les
spécifica-tions du système auto-organisé à mettre en œuvre (définition de sous-champs complémentaires dans le flux correspondant à des optionalités à intégrer dans le système).
Les deux derniers sous-champs présentés dans la figure 3.7 sont des sous-champs relatifs
aux modes de fonctionnement d’une entité du système. Ainsi, le sous-champ MDFA contient les informations sur le mode de fonctionnement en cours d’une entité, tandis que le sous-champ
«Négociation» Non Oui Accord trouvé? MDFS <= MDFA MDFA <= MDFS Non MDFS = MDFA? Oui
FIG. 3.8 – Un extrait du graphe de contrôle du flux informationnel relatif aux requêtes de
3.2. Une approche architecturale matérielle pour les systèmes auto-organisés MDFS contient les informations sur le mode de fonctionnement futur souhaité. En général, au
cours du fonctionnement d’une entité, ces deux sous-champs contiennent des valeurs identiques, excepté dans la phase de fonctionnement de l’entité correspondant à une requête de changement de mode de fonctionnement. Cette requête est signalée par une entité à ses entités voisines par une écriture dans son sous-champ MDFS du flux informationnel. Ensuite, une phase de « négo-ciation » entre l’entité considérée et ses entités voisines s’enclenche. En fonction du résultat de cette négociation (favorable ou non), la requête de changement de mode de fonctionnement d’une entité devient ou non effective. Dans le cas où cette négociation a échoué, l’entité
initia-trice conserve son mode de fonctionnement initial. La figure3.8illustre ce procédé de demande
et de négociation de requête de changement de mode de fonctionnement d’une entité d’un sys-tème auto-organisé.
Bien qu’en apparence l’exemple du flux informationnel présenté par la figure3.6 présente
une structure statique, le concept du flux informationnel proposé est une structure dynamique dont la taille évolue en fonction du nombre d’entités associées et au cours du fonctionnement du système auto-organisé. Dans le cas de figure illustré précédemment, le flux informationnel
présenté par la figure 3.6 correspond à un flux couvrant quatre entités d’une structuration de
système, chaque entité étant caractérisée par des champs spécifiques. Plus précisément, la taille du flux informationnel proposé change et varie particulièrement, dans les situations où une en-tité doit être substituée fonctionnellement par ses enen-tités voisines. Il s’agit de la situation de fonctionnement dans laquelle les sous-champs PRESENCE ou VF ont une valeur nulle. L’in-terprétation et l’évolution d’un flux informationnel s’appuient sur des blocs locaux dans chaque entité du système nommé « descripteur » et permettant de les caractériser.