Couverture ElectroniqueS n°127

Une étude sur l'architecture d'un mobile, effectuée par Nokia, a permis de réaliser des liens entre modèles de spécifications basés UML et architecture d'exploration non UML, sous forme de traces d'exécution. L'intégration d'outils au moyen de métamodèles implantés par Telelogic et CoFluent autorise l'emploi de modèle « use case » à la place des traces d'exécution Nota (Network-on-terminal architecture) est une architecture modulaire orientée services et centrée interconnexions qui s'adresse aux plates-formes actuelles et futures de terminaux mobiles. Développée par le centre de recherche de Nokia (Nokia Research Center, NRC), NoTA apporte une plus haute performance et une « horizontalisation » très efficace des éléments d'architecture d'un système en facilitant les processus d'intégration (encadré I). La méthode de développement qui lui est associée donne notamment l'assurance que les designs sont vérifiables pas à pas vis-à-vis des spécifications d'utilisateurs. La méthode NoTA autorise en outre une réutilisation à plusieurs niveaux.Concrètement, une plate-forme NoTA consiste en services connectés par des liens lâches et s'exécutant sur des sous-systèmes hétérogènes. Dans les systèmes basés NoTA, les communications de services et de données sont routées à travers la pile de protocoles réseau. La méthode NoTA repose sur un flot de développement de plate-forme assurant que les services, les sous-systèmes et la topologie d'interconnexion correspondent bien aux spécifications de l'utilisateur final. Elle fournit aussi des spécifications formelles réutilisables pour chaque entité de la plate-forme. Pour ce faire, l'architecture logique NoTA repose sur trois types d'éléments de base appelés « n&oelig;uds applicatifs » (AN), « n&oelig;uds de service » (SN) et « interconnexion » (Inter-connect) (figure 1).NoTA définit aussi deux grands niveaux de protocoles pour l'interconnexion, « H_IN » et « L_IN ». Le premier, « H_IN », est une pile de haut niveau qui apporte la fonctionnalité de communication aux services et applications de la plate-forme. Le second, « L_IN », est un protocole de bas niveau qui prend en charge la connexion physique entre sous-systèmes.Enfin, un sous-système NoTA comprend un ensemble de services. Il s'agit ici d'un concept architectural qui ne s'aligne pas nécessairement sur les limites d'un circuit intégré (figure 2).Intégration avec des outils « sur étagère »Dans le cadre de leurs travaux pour le projet Martes, Telelogic et CoFluent Design ont réalisé une intégration basée sur un métamodèle de leurs outils à l'aide du framework EMF (Eclipse modeling framework) et de son format Ecore.L'intégration offre une alternative intéressante pour le transfert entre outils du comportement des « use cases ». L'idée ici est de transférer le modèle « use case » exécutable en entier, au lieu de transférer sa trace d'exécution comme décrit précédemment. L'outil Telelogic Tau (2) est utilisé dans ce cadre uniquement pour le modèle applicatif. Des attributs de performance temps réel peuvent être ajoutés au modèle Tau sous forme de valeurs marquées (« tagged values ») du profil UML utilisé, et être traités en tant qu'adaptation du modèle d'application Martes. Le grand bénéfice tiré du transfert du modèle entier est que les utilisateurs sont à même de recevoir un retour du modèle d'architecture de plate-forme qui affecte potentiellement le comportement du « cas d'utilisation ».Un exemple d'étude d'un baladeur vidéo est présenté ici pour montrer comment fonctionne ce principe de transfert de modèle (figure 5). Dans cet exemple, les services sont modélisés sous forme de machines d'états dotés d'attributs de performance. Le n&oelig;ud d'application contient une machine d'états modélisant son comportement dans un « cas d'utilisation » particulier. La modélisation est faite sur deux niveaux, le niveau « use case » et le niveau service. Plusieurs use cases peuvent être examinés en changeant le n&oelig;ud d'application.La structure de niveau supérieur du modèle d'application est définie dans Tau par un diagramme de structure composite (figure 6). Le comportement des classes est modélisé sous forme de machines d'états (figure 7). La composition du use case est également créée en UML (figure 8). Les stéréotypes du profil UML mis en &oelig;uvre dans l'intégration des outils contiennent des « valeurs marquées », qui permettent d'introduire des attributs de performance utilisés par CoFluent Studio. Le modèle résultant est exécutable et peut être simulé dans Tau (figure 9).L'extension de l'outil Tau développé dans le cadre du projet Martes génère ensuite un fichier Ecore, conforme au méta-modèle défini. Ce fichier Ecore peut être importé dans CoFluent Studio, ce qui induit que la configuration de modèle d'application résultante dans CoFluent Studio a la même structure que le modèle Tau d'origine. La représentation graphique du modèle est perdue dans le transfert. Cependant, le comportement des machines d'états et les attributs de performance sont préservés. Le modèle applicatif peut alors être simulé dans CoFluent Studio (figure 10).Le modèle de plate-forme d'exécution et le modèle d'architecture système sont ensuite construits dans CoFluent Studio. Le modèle d'architecture système est généré en créant les correspondances entre éléments de l'application sur le modèle de plate-forme d'exécution (figure 11). Le modèle obtenu peut alors être simulé dans CoFluent Studio pour étudier l'impact de la plate-forme et des choix d'allocation (figure 12). (1) CoFluent Studio est un outil de modélisation graphique pour l'exploration architecturale et l'analyse de performance au niveau système. Il supporte le langage SystemC et fonctionne sous Eclipse.(2) Telelogic Tau est un environnement de développement centré modèles, basé sur UML. Il permet notamment de valider les spécifications système avant leur transmission pour implantation. Le vérificateur de modèles fournit une trace XML de l'exécution du système.I. - Un centre de recherche et un projet européen Nokia Research Center (NRC) est une division autonome de Nokia qui ne se rattache à aucune unité spécifique de développement de produit.NRC dispose de plus de 1 100 chercheurs, focalisés sur des sujets de recherche liés à la mobilité dans les domaines voix, données, gestion et communications. Dans le cadre du projet de recherche européen ITEA Martes (Model-based approach to real-time embedded systems ; www.martes-itea.org), NRC conduit une étude de terminal mobile axée sur les architectures de terminaux centrés communications et conçus pour la convergence numérique. Dans ce contexte, NRC a adopté la méthode MCSE (Méthodologie de conception des systèmes électroniques) de CoFluent Design pour la modélisation d'architecture, et utilisé CoFluent Studio comme outil de modélisation de plate-forme de terminal mobile.NRC, qui mène d'importants travaux de recherche dans le domaine des architectures de terminaux mobiles, a développé en outre un concept d'architecture orientée services appelé NoTA (Network-on-terminal architecture). La contribution de Nokia au projet Martes repose étroitement sur NoTA.II. - Les étapes d'une exploration architecturaleLes étapes d'une exploration architecturale :1.Définir le nombre et les types de sous-systèmes.2.Définir la topologie d'interconnexion entre sous-systèmes. Ceci détermine le nombre et les types de commutateurs de routage.3.Etablir les correspondances entre SN et AN et les sous-systèmes.4.Exécuter les simulations vis-à-vis des use cases d'origine.5.Analyser les résultats.6.Retourner à l'étape 3 pour optimiser l'architecture courante.7.Retourner à l'étape 1 pour essayer différentes architectures.8.Choisir le(s) cas le(s) plus optimisé(s).9.Sélectionner l'architecture virtuelle.Lorsque l'exploration des architectures avec CoFluent Studio est terminée et que le cas optimal est sélectionné, la solution d'architecture se présente ainsi :Un ensemble de sous-systèmes connectés avec une certaine topologie.Une allocation des services issus des use cases décomposés dans les sous-systèmes mentionnés.Des paramètres de performance vérifiés et affinés pour les services.Tout ce qui précède est vérifié par rapport aux use cases d'utilisateur final qui ont été donnés au départ.Tous ces éléments définissent les spécifications de chaque sous-système.

Mobiles : l’exploration d’architecture renforce une méthode « orientée service »

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure

Mobiles : l’exploration d’architecture renforce une méthode « orientée service »

Dans la même rubrique

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure