3.2 Le métamodèle HDCRAM
3.2.2 Métamodèle HDCRAM
La recherche présentée précédemment sur les langages de modélisation à haut niveau s’inscrit dans notre démarche de réflexion, comme présenté dans la troisième ligne de la figure 4 résumé par la figure 3.6, et dont le but est la modélisation d’HDCRAM par un langage de haut niveau d’abstraction.
FIG. 3.6:Modélisation de HDCRAM
Le choix de la modélisation UML pour HDCRAM se justifie facilement par la nature pluridisciplinaire de la radio cognitive ainsi que l’étendue et la nature hétérogène du parc d’équipement visé. Il est en effet essentiel de fournir un modèle qui :
• ne soit pas affecté par les sauts technologique,
• permette de synthétiser les besoins de chaque corps de métier intervenant dans la conception d’équipement RC,
• permette de passer outre les contraintes des langages dédiés qui ne sont interpré- table que par des experts d’un domaine en particulier,
• permette de capitaliser les savoirs acquis.
Nous proposons dans cette section de présenter HDCRAM par différents diagrammes UML afin de mettre en avant ses fonctionnalités et ses interactions. Pour ce faire nous présenterons tout d’abord l’architecture dans sa globalité avec un diagramme de classe, puis nous présenterons comment circulent les données dans HDCRAM. Ensuite nous présenterons rapidement les interactions de HDCRAM avec son environnement puis nous détaillerons les unités ReM et CRM.
3.2 LE MÉTAMODÈLEHDCRAM
87
Modélisation HDCRAM
Afin de permettre une lecture aisée de notre architecture et d’illustrer les dépen- dances des gestionnaires hiérarchique distribués nous avons eu recours à une modélisa- tion UML de notre architecture. Cette modélisation a uniquement pour but de décrire fonctionnellement notre architecture de gestion cognitive d’un équipement radio à un ni- veau d’abstraction élevé. Le but est de définir l’ensemble des constituants nécessaires au bon fonctionnement de l’équipement.ainsi que la liste des opérations qu’ils doivent pou- voir effectuer. Dans ce sens, notre modélisation correspond à une description PIM. Cette modélisation s’appuie sur l’utilisation d’un diagramme de classe (qui est généralement reconnu comme l’élément central d’UML) et est présentée par la figure 3.7. La vue de l’architecture présentée ici est entièrement centrée sur le gestionnaire et son contrôle sur le système et met en avant les dépendances ainsi que les cardinalités entre gestionnaire.
FIG. 3.7:Métamodèle de l’architecture HDCRAM
Les classes présentes sur le coté gauche de l’architecture sont les niveaux de gestion de reconfiguration et sur la droite les niveaux de gestion cognitive. La classe Operator, présente en bas du métamodèle, est une classe parent qui regroupe l’ensemble des opéra- teurs pouvant être implantés dans l’équipement radio. La partie haute de la figure met en évidence les classes parent ReM et CRM qui illustrent la généricité des fonctionnalités des unités de gestion déployées dans l’architecture. Il est cependant important de garder à l’esprit que ces fonctionnalités seront spécialisées suivant le traitement qui sera attribué aux classes enfant.
88
UN MÉTAMODÈLE EXÉCUTABLEÀ la lecture de la figure 3.7 il apparaît sans ambiguïté possible les relations de dé- pendance entre les gestionnaires composant HDCRAM. Ainsi il est clairement établi que :
• si une unité ReM existe, alors une unité CRM peut lui être associée (et inverse- ment),
• il ne peut y avoir présence d’une entité L3 sans entité L2 pour la contrôler, • une entité CRM contrôle son entité ReM associée,
• pour une entité de niveau supérieur (CRM ou ReM) il existe de 0 à une infinité d’unités de niveau inférieur associées.
Flot de données dans HDCRAM
La figure 3.8 illustre de manière globale les flux d’informations entre unités du ges- tionnaire.
FIG. 3.8:Flux d’information dans l’architecture HDCRAM
On illustre ainsi de façon claire ce qui a été présenté par la figure 2.11 au chapitre deux à savoir
• une approche “top/down” pour caractériser l’envoi d’ordre de reconfiguration dans la partie ReM,
• une approche “bottom/up” pour illustrer la remontée de métrique dans la partie CRM,
• une approche transversale (d’une unité CRM vers son unité associée ReM) pour l’envoi d’ordre de reconfiguration décidé par un gestionnaire cognitif.
3.2 LE MÉTAMODÈLEHDCRAM
89
Relations de HDCRAM avec l’environnement
Bien qu’autonome dans sa gestion de plateforme d’exécution, l’architecture HD- CRAM réagit à son environnement afin de décider d’une reconfiguration de l’équipe- ment. HDCRAM ne définit pas de façon intrinsèque les politiques de sécurité ou d’utili- sation de spectre, nous considérons en effet que ces entités ne bénéficieraient pas d’une intégration au sein de l’architecture. Néanmoins, il faut prévoir un mode d’accès en lec- ture par HDCRAM à ces politiques afin que la solution de reconfiguration de l’équi- pement, préconisée par HDCRAM, soit en concordance avec les politiques en vigueur dans son environnement. De plus, il faut aussi prévoir l’accès en écriture à ces mêmes politiques afin de venir effectuer des modifications si besoin est. On prendra comme exemple un changement de pays ou les standards d’émission/réception changent. Dans ce cas, HDCRAM fera une demande de confirmation des politiques en vigueur et si de nouveaux paramètres lui sont envoyés il mettra le module à jour. Il est clair que cette liberté laissée à HDCRAM nécessite des précautions pour l’accès à ces règles en termes de sécurité pour ne pas perturber d’autres utilisateurs. Le diagramme 3.9 présente les relations d’HDCRAM avec son environnement.
FIG. 3.9:Diagramme des cas d’utilisation de l’architecture HDCRAM
Réaction d’une unité CRM
Afin de détailler le fonctionnement interne d’une unité de gestion cognitive, nous avons utilisé ce que l’on appel un diagramme de données-processus (process-data dia- gram) qui permet de lier le parcours d’une donnée à un ensemble de processus. Ce dia- gramme illustré par la figure 3.10 permet de faire une corrélation entre les actions né- cessaires à l’exécution d’un système cognitif (à gauche) et les différentes opérations (à droite) au sein d’un Li_CRM(U) (i pouvant prendre une valeur de 1 à 3). Les différentes
90
UN MÉTAMODÈLE EXÉCUTABLEopérations ainsi que les dépendances les reliant sont ici mise en évidence. Il est à noter que les opérations présentées ci-dessus sont utilisées par chaque niveau d’abstraction. En effet, le cycle cognitif est répété pour chaque Li_CRM(U). Néanmoins, le traitement des métriques et les actions qui en découlent offrent des répercussions différentes suivant le niveau qui les déploie.
FIG. 3.10:Représentation UML des opérations d’une unité CRM
On remarquera que la partie gauche est identique à la figure 2.12. La partie droite per- met de représenter les besoins en termes d’opération et de ressource au sein d’une entité CRM. Ainsi il apparaît qu’une unité CRM possède une unique liste d’actions lui permet- tant de définir les statégies d’actions pour la mise en place d’une reconfiguration. Cette liste d’action peut être fournie par exemple par les politiques d’utilisation du spectre en cours dans la localisation de l’équipement radio. L’unicité de cette liste d’actions permet de contraindre le gestionnaire dans ses degrés de liberté, bien entendu elle peut bénéfier de l’auto apprentissage ou encore être modifiée par une mise à jour. De même quelle que soit le nombre de métriques collectées par une unité CRM, chacune possède une priorité permettant de définir son importance dans une prise de décision de reconfiguration.
3.2 LE MÉTAMODÈLEHDCRAM
91
Réaction d’une unité ReM
De même, nous illustrons ici avec la figure 3.11 les relations entre l’interprétation d’un ordre de reconfiguration d’une unité CRM associée ou ReM de niveau supérieur et le déclenchement des processus au sein d’une unité ReM.
FIG. 3.11:Représentation UML des opérations d’une unité ReM
• Capture order : définit l’action d’acquisition d’un ordre de reconfiguration, qu’il vienne du CRMU associé ou du ReMU associé de niveau supérieur,
• Analyze order : vérifie la validité de la donnée,
• Identify a solution : Interprète l’ordre de reconfiguration en fonction des para- mètres de configuration courant,
• Schedule reconfiguration : Analyse la priorité et la répercute dans sa table d’or- donnancement des tâches,
• Execute : Exécute la reconfiguration.
Apparaît dès lors deux problématiques : la première est comment mettre en place une politique de gestion de priorité d’ordre de reconfiguration pour éviter un conflit dans un CMU entre un ordre venant de son CRU et un ordre venant du niveau supérieur. La seconde est la mise en place de moyens permettant d’éviter les boucles infinies d’opti- misation. Ces deux problèmes dépassent le cadre de cette thèse mais nécessitent une part non négligeable de travail d’exploration pour la mise en place d’un système cognitif.
92
UN MÉTAMODÈLE EXÉCUTABLEIl est à noter que les opérations présentées dans les deux diagrammes ci-dessus re- présentent une partie seulement des opérations contenues dans une unité de gestion. En effet, les opérations de type rafraîchissement des valeurs, passage de valeur, mise à jour des bibliothèques, etc. ne sont pas détaillées ici.
Résultat de la modélisation
Il est évident que cette thèse n’a pas vocation à délivrer un outil permettant la créa- tion automatique d’un équipement RC clé en main. L’outil que nous proposons ici per- met une exploration fonctionnelle visant à identifier tous les éléments de gestion qu’il est nécessaire d’intégrer dans un équipement RC. Ceci afin que cet équipement puisse supporter l’ensemble des scénarios envisagés. La liste des opérations que doivent être ca- pable d’exécuter ces éléments et les éventuelles bases de données nécessaires sont aussi identifiée grâce à l’outil. À l’échelle de cette thèse, seule une étude purement fonction- nelle était visée. Néanmoins, il est envisageable à l’avenir, de coupler cette modélisation HDCRAM avec un profile tel que le profile MARTE [101] ayant pour vocation l’aide à la Modélisation et l’Analyse des Systèmes Temps Réel et Embarqués. Bien entendu, l’in- térêt de l’intégration de ce profile se fera à un niveau d’abstraction moindre puisque ce profile permet de prendre en considération les aspects matériels de la plateforme d’exé- cution cible. Ce type d’approche est notamment retenue dans le projet MOPCOM [102] qui est un projet du “pôle de compétitivité Images & Réseaux” de la région Bretagne de trois ans (2007-2010). Ce projet a pour vocation la production d’une méthodologie com- plète ainsi que d’un environnement de développement adapté à la conception de systèmes embarqués sur des systèmes sur puce (SoC). Cet environnement de développement doit pouvoir accompagner un concepteur de système reconfigurable depuis la modélisation haut niveau de son application jusqu’à la génération automatique de code programme VHDL ou SystemC.
La force de ce métamodèle HDCRAM est qu’il n’est en rien lié uniquement aux sys- tèmes RC mais peut être utilisé pour la conception de tout équipement présentant des facultés d’auto-reconfiguration. À cet effet, aucune obligation n’a été apportée sur l’uti- lisation de tel ou tel algorithme cognitif (il peut en effet être extrêmement simpliste tout comme se révéler extrêmement complexe) ni même sur le langage servant à en définir le comportement. Suivant le domaine d’utilisation fixé, un concepteur pourra réutiliser ce métamodèle et définir (ou réutiliser) des profiles, quelque soit le domaine d’application, afin de l’accompagner jusqu’à la génération de code programme.
3.2 LE MÉTAMODÈLEHDCRAM