Les architectures décentralisées

Que ce soit implémenté en standalone ou par un OS, l’utilisation d’un contrôleur centralisé pour l’adaptation dynamique des systèmes reconfigurables pourrait diminuer la flexibilité du contrôle et la possibilité de le réutiliser et de l’adapter à des systèmes différents. En effet, du fait de sa vue globale, l’implémentation du contrôleur centralisé devient dépendante du système ciblé, ce qui diminue les possibilités de réutilisation et de scalabilité. Une solution aux problèmes de conception liés au contrôle centralisé

peut être de décomposer le contrôle entre un ensemble de contrôleurs gérant chacun des problèmes de contrôle locaux. Cette solution favorise la réutilisation de chaque contrôleur et facilite ainsi la scalabilité du contrôle pour des systèmes de grande taille. De plus, la distribution du contrôle permet de mieux s’adapter à l’évolution constante des tailles des systèmes ciblés en évitant les problèmes de communication centralisée.

Le contrôle décentralisé des systèmes reconfigurables n’a été traité que par quelques travaux sur FPGA. Cependant, il est très utilisé dans d’autres domaines tels que les sys- tèmes mécatroniques, les systèmes robotiques, etc. Certains travaux dans ces domaines sont présentés dans cette section à côté de ceux liés au domaine des FPGAs.

Il y deux catégories de de contrôle décentralisé : celui avec des contrôleurs non- communicants et celui avec des contrôleurs communicants. La première catégorie est utilisée pour des systèmes où une décision faite par un contrôleur n’a pas d’influence sur les autres ou sur les contraintes/objectifs globaux des systèmes. Un tel système peut par exemple être composé de machines autonomes et intelligentes où les différentes configurations de chacune d’entre elles n’ont aucune impact sur les configurations des autres [134]. La seconde catégorie de contrôle est utilisée quand les contrôleurs doivent échanger leurs décisions afin de respecter les contraintes/objectifs globaux du système. Dans ce cas, une coordination entre contrôleurs est nécessaire. Le contrôle décentralisé peut être complètement distribué ou semi-distribué (hiérarchique).

3.2.2.1 Le contrôle complètement décentralisé

Dans [124] [125], une approche basée sur le contrôle distribué matériel est utilisée. Dans cette approche, chaque région du FPGA est contrôlée par un contrôleur matériel. Le rôle de ce dernier est de contrôler les tâches exécutées par la région associée. Une reconfiguration est déclenchée par le contrôleur à chaque fois qu’une tâche gérée par la région contrôlée est requise. L’avantage de cette implémentation matérielle est qu’elle permet de réduire l’impact du contrôle en termes de temps d’exécution en favorisant l’exécution parallèle du contrôle et des autres tâches de l’application. Cependant, cette approche est limitée à des problèmes de contrôle locaux et indépendants. De ce fait, les possibilités de communication ou de coordination entre contrôleurs n’est pas traitée.

Dans le projet AETHER [106] [107], un modèle général d’entités reconfigurables sur FPGA a été proposé. Chaque entité est auto-adaptative et gère un ensemble de tâches : le calcul, l’observation, le contrôle et la communication avec les autres entités. Cette approche favorise la réutilisation du contrôle puisque chaque entité a sa propre partie de contrôle. Cependant, dans l’implémentation proposée pour cette approche, la prise de décision de reconfiguration est faite en centralisé à travers un OS et le problème de coordination entre contrôleurs n’a pas été traité.

Dans DodOrg [119], une approche de contrôle distribué a été proposée pour des systèmes de calcul organique. Les systèmes ciblés sont composés de cellules de calcul matérielles implémentées sur FPGA. Chaque cellule est auto-adaptative et fournit des services de calcul, de mémoire et d’entrée/sortie et contient aussi une unité de contrôle implémentée en matériel. Pour résoudre le problème de la disponibilité d’un seul port ICAP sur FPGA, cette approche propose une technique d’accès distribué à ce port afin d’accélérer le processus de reconfiguration par rapport à un accès centralisé. Cependant,

cette approche se concentrait plus sur l’accès distribué à l’ICAP sans donner de détails sur les composants de contrôle utilisés par chaque entité (observation, décision, etc).

Le contrôle distribué des FPGA n’a été traité que par quelques travaux parmi lesquels ceux cités ci-dessus. Cependant, ces travaux ne traitent pas l’aspect coordination entre les décisions de reconfiguration. Ils présentent généralement deux modèles. Le premier modèle est le cas où les configurations partielles sont indépendantes [124] [125] [119] et n’ont pas besoin de coordination. Le deuxième modèle est le cas où la prise de décision est faite en centralisé [106] [107] bien que les autres parties (observation, reconfiguration, etc) soient distribuées.

L’aspect coordination a été traité dans des domaines autres que les FPGAs tels que les MPSoC [108] [109], les réseaux sans fils [37], les systèmes multi-équipements [52] [158], etc. Deux principaux modèles de coordination entre contrôleurs ont été proposés. Le premier modèle se base sur la communication de chaque contrôleur avec tous les autres [108] [109] [37]. Pour arriver à une configuration globale satisfaisante pour tous les contrôleurs, le nombre de messages échangés peut être considérable pour un système de grande taille, ce qui pourrait avoir un impact non négligeable sur la performance du système de contrôle. Les contrôleurs de ce type doivent prendre en compte les informations (décisions/états) envoyées par tous les autres contrôleurs, ce qui peut engendrer une grande complexité de chaque contrôleur et donc une grande consommation en ressources. De plus, la vision globale de chaque contrôleur le rend dépendant du système, ce qui pourrait représenter un obstacle devant la réutilisation. Le deuxième modèle de coordination est un modèle où chaque contrôleur ne communique qu’avec ses voisins [52] [158], ce qui permet de diminuer le nombre de messages échangés entre contrôleurs ainsi que la complexité de leurs communications. Cependant, cela demande encore de chaque contrôleur d’avoir une vision sur les comportements des autres contrôleurs, ce qui pourrait les rendre dépendants du système et difficiles à réutiliser.

3.2.2.2 Le contrôle hiérarchique

Afin de minimiser le nombre de messages échangés entre contrôleurs avant d’arriver à une configuration globale satisfaisante et d’améliorer la réutilisation des contrôleurs, des approches de contrôle hiérarchique ont été proposées. Ces approches permettent de séparer les problèmes gérés par un système de contrôle en des problèmes locaux gérés par les contrôleurs du niveau inférieur et des problèmes globaux gérés par les contrôleurs du niveau supérieur, ce qui facilite la réutilisation des deux types de contrôleurs pour d’autres systèmes.

Dans [60], une approche de contrôle basée sur la coordination a été proposée pour un système électrique multi-agents. Chaque agent est responsable du contrôle de la reconfiguration d’un appareil du système. Selon ses contraintes locales (nombres de pièces à traiter par une machine, composants en panne, etc), chaque agent peut décider de reconfigurer l’appareil qu’il contrôle. Cette décision est envoyée à un agent de coordi- nation, qui grâce à sa vision globale du système vérifie si la requête peut être satisfaite directement ou si elle nécessite la reconfiguration d’autres machines. Dans ce cas, les agents des machines a reconfigurer sont informés en leur envoyant les reconfigurations

nécessaires auxquelles ils peuvent répondre par acceptation ou par refus. L’objectif de cette approche est de minimiser le nombre de messages échangés entre agents par rapport à un système complètement distribué où chaque décision de reconfiguration est envoyée à tous les agents, ce qui nécessite une connaissance de toutes les configurations possibles du système et leurs priorités par tous les agents.

Dans le projet RaaR [40] [35], une autre approche intéressante de contrôle hiérar- chique a été proposée. Elle a été implémentée sous-forme de tâches logicielles dans un système FPGA intégrant un système d’exploitation. Cette approche est basée sur une architecture à deux étages hiérarchiques. Le premier étage est un étage où un contrôleur de configuration local (LCM) est lié à chaque application exécutée par le système d’exploitation et permet de déterminer la liste de reconfigurations possibles, suite à des changements liés aux métriques considérées par l’application. Le deuxième étage contient un contrôleur de configuration global (GCM) qui prend en considération des métriques liées au système (temps d’exécution, consommation d’énergie, etc) pour sélectionner à partir des possibilités données par le LCM celle qui correspond le plus aux objectifs du système. Grâce à la séparation du contrôle entre LCM et GCM, un LCM peut être réutilisé pour une même application indépendamment des contraintes du système vu qu’il ne prend pas en compte les métriques du système. Le GCM peut être aussi facilement réutilisé, moyennant quelques modifications selon les applications implémentées, puisqu’il considère chaque application du système comme une liste de configurations possibles sans entrer dans ses détails. Cependant, l’utilisation d’un seul LCM pour gérer toute une application pourrait limiter la flexibilité et la réutilisabilité d’un LCM pour différentes applications, ce qui pourrait réduire la productivité des concepteurs de LCMs surtout pour les applications de grande taille. Pour assurer plus de flexibilité et de scalabilité, l’approche proposée dans [40] [35] pourrait être étendue pour traiter les possibilités de conflits entre les configurations choisies par les LCMs dans un système multi-applications. Dans ce cas, le GCM doit en plus de la gestion des métriques du système, gérer la coordination entre les LCMs.

Dans [33] [34], le contrôle hiérarchique a été utilisé dans le cadre de la négociation pour la répartition des tâches dans un système multi-robots. Le contrôle est assuré par des robots intelligents qui sont répartis en clusters avec des leaders de clusters communicants. Chaque leader gère la négociation entre les robots de son cluster. Les stratégies de négociation des robots d’un cluster dérive de l’objectif du leader. Les leaders négocient aussi entre eux en utilisant des stratégies dérivées de l’objectif global du système, ce qui permet d’optimiser cet objectif global et de résoudre le problème de sous-optimalité de la négociation dans un système complètement distribué. Cette approche permet donc de diviser les stratégies de contrôle entre les leaders et les autres robots, ce qui facilite la réutilisation et la scalabilité de ce modèle et diminue en même temps le nombre d’échanges nécessaires pour la négociation.