Caractérisation d’une plateforme dans un cadre IDM

Télécharger le fichier pdf d’un mémoire de fin d’études

Caractérisation d’une plateforme dans un cadre IDM

Dans le cadre d’une ingénierie dirigée par les modèles, Atkinson et Kühne [17] défi-nissent une plateforme, comme étant un système permettant la réalisation des objectifs d’une application. Par cette définition, les auteurs cherchent à montrer que l’exécution n’est pas le seul objectif d’une plateforme. En effet, au sens de l’IDM, une plateforme peut être utili-sée pour des activités d’analyse, stockage de donnée ou même pour la représentation des modèles.
Dans ce même contexte, Almeida [13] introduit deux types de plateformes : plateforme abstraite et plateforme concrète. Une plateforme abstraite au sens d’Almeida est une plate-forme fictive définissant un ensemble de concepts qui peuvent ne pas avoir une implantation réelle. Dans son approche, Almeida introduit aussi une plateforme abstraite comme étant une plateforme idéale de point de vue du développeur de l’application. Cette plateforme est définie pour une utilisation précise à une phase donnée du cycle de développement (géné-ralement pour garantir l’indépendance par rapport à une plateforme d’exécution). CORTA [33] est un exemple de plateforme abstraite définit dans un cadre IDM pour la spécification des applications multi-tâches d’une façon indépendante des exécutifs temps réel. Contraire-ment à une plateforme abstraite, une plateforme concrète pour Almeida ne peut être qu’une plateforme d’exécution.
Selic [79] [78] définit une plateforme comme un ensemble de ressources qui fournit des services qui peuvent être accessibles par un ou plusieurs clients (des applications). Selic souligne ,à ce titre, qu’une plateforme au travers ses ressources et services doit être en mesure de satisfaire le besoin de l’application.
Face à cette diversité, l’OMG propose sa propre définition pour le concept de plateforme. Cette définition, dont la traduction est donnée ci-dessous, spécifie qu’une plateforme fournit un ensemble de fonctionnalités, au travers d’interfaces et des patrons d’utilisation de ces fonctionnalités.
« Une plateforme est un ensemble de sous-systèmes et de technologies qui fournissent un en-semble cohérent de fonctionnalités au travers d’interfaces et la spécification de patrons d’utilisation que chaque sous-système qui dépend de la plateforme peut utiliser sans être concerné par les détails et sur la façon dont les fonctionnalités sont implantées » [65]
En gros, une plateforme dans l’IDM est plus qu’une plateforme d’exécution. Elle est dite abstraite, si elle est définie pour une utilisation prévue, autre que l’exécution telle que l’ana-lyse ou la simulation, à un instant donné du cycle de développement. Sinon, elle est dite concrète.

Synthèse

Nous avons évoqué dans cette première partie les points clés de cette étude dans le but cadrer le contexte de nos travaux. Nous avons ainsi introduit les systèmes temps réel embar-qués. Plus précisément, nous avons fixé les hypothèses considérées dans cette étude pour la conception de ces systèmes. Nous considérons, dans cette thèse, des applications temps réel s’exécutant sur une architecture monoprocesseur et ayant comme support d’exécu-tion logiciel un système d’exploitation temps réel (RTOS). Nous avons montré que, de part leur nature, ces systèmes requièrent une étape de vérification supplémentaire par rap-port aux systèmes classiques en particulier une vérification des contraintes temporelles se basant sur des techniques d’analyse d’ordonnançabilité. Nous avons également présenté l’ingénierie dirigée par les modèles, en particulier, nous avons détaillé l’approche MDA et nous avons survolé des travaux qui ont abordés la notion de plateforme dans le cadre de l’IDM. Ces deux points constituent la base des contributions de cette thèse.

Les plateformes d’exécution

Il n’existe pas à nos jours une définition unique et précise du concept plateforme. Classi-quement, une plateforme référence la structure matérielle permettant l’exécution du logiciel. Cette vision a rapidement évolué avec la montée en niveau d’abstraction et l’apparition de la structuration en couches des plateformes [57]. Cette représentation en couches successives d’infrastructure matérielle, de système d’exploitation, de machine virtuelle et d’intergiciel rend la distinction entre l’application et la plateforme fortement liée au point de vue où l’on se place. En effet, un système d’exploitation peut être vu comme une application du point de vue d’un fournisseur de support matériel, et comme une plateforme d’exécution du point de vue d’un développeur d’applications logicielles. Par conséquent, la caractérisation d’un système comme étant une plateforme ne dépend pas de la nature du système lui-même mais plutôt de l’utilisation prévue pour ce système dans un contexte donné.
Hypothèse. Dans cette étude, nous faisons une abstraction de l’architecture matérielle et nous nous intéressons uniquement aux plateformes logicielles. En outre, nous considérons les systèmes d’exploitation temps réel (RTOS) comme plateformes d’exécution pour les appli-cations visées dans cette étude.

Représentations des plateformes d’exécution dans l’IDM

Dans un cycle de développement basé sur les modèles, une plateforme logicielle d’exé-cution peut être représentée dune façon enfouie, implicite ou explicite.
La représentation enfouie est généralement utilisée dans les approches qui visent la gé-nération du code d’une application à travers les transformations de type modèles en texte. Dans ce cas, les caractéristiques de la plateforme sont capturées dans la transformation. On peut citer dans ce contexte l’outil OCARINA [45] qui permet la génération de code Ada ou C pour l’intergiciel PolyORB II [91] à partir d’une description AADL [68] de l’application.
La représentation implicite est basée sur la définition d’un méta-modèle de la plateforme considérée [74] [28] [51]. Ce méta-modèle est implémenté sous forme d’un profil UML ou d’un DSL (Description Specification Language) et est utilisé pour la description du modèle applicatif. Dans ce cas, la plateforme est représentée de façon implicite dans l’application.
Dans une représentation explicite, la plateforme est décrite dans un modèle indépendant de la transformation et de l’application. Dans ce cas, la génération des modèles applicatifs spécifiques à une plateforme se traduit par une transformation du type modèle en modèle ayant comme entrées : le modèle de l’application indépendant de toute plateforme et le modèle de plateforme.
Hypothèse. Afin de répondre aux principes de le MDA, dans ce travail, nous adoptons une représentation explicite des plateformes d’exécution (RTOS).
Cette dernière hypothèse exige alors la définition des modèles de plateformes d’exécu-tion (en d’autres termes des modèles des RTOS), ce qui nécessite l’utilisation d’un langage approprié adapté à nos besoins de modélisation. Cette problématique est l’objet de la partie suivante.

Modélisation des plateformes d’exécution

Selon [61], un modèle de plateforme est une représentation abstraite mais suffisamment précise d’une plateforme d’exécution. Un modèle de plateforme doit être focalisé sur les aspects de celle-ci nécessaires pour son utilisation. En effet, une plateforme d’exécution lo-gicielle peut être modélisée par exemple dans le but de conception d’une application (des-cription d’une application multi-tâches), d’analyse ou de génération de code. La précision du modèle de cette plateforme dépend fortement de l’objectif pour lequel ce modèle a été crée.
Hypothèse. Dans cette thèse, nous nous intéressons à la modélisation des plateformes d’exécution logicielles (RTOS) dans le but de permettre le déploiement d’une application sur un RTOS en assurant le respect des contraintes temporelles. Plus précisément, les modèles des plateformes considérés dans cette étude se limitent aux concepts des RTOS nécessaires pour la vérification temporelles en utilisant les techniques d’analyse d’ordonnançabilité.

Modèle de plateforme pour l’analyse d’ordonnançabilité

Dans le contexte de modélisation des plateformes logicielles, Marvie et al. [73] proposent de modéliser une plateforme selon trois vues distinctes : (a) une vue statique des ressources fournies par la plateforme (telles que les tâches logicielles pour un système d’exploitation multi-tâches), (b) une vue dynamique des traitements réalisés par la plateforme (telles que la création et l’activation d’une tâche) et (c) une vue qui traite le cycle de vie des ressources sous l’influence des traitements qui leurs sont appliqués (le cycle de vie d’une tâche est, par exemple, borné par sa création et sa destruction). Dans la même vision, Thomas [86] identifie quatre axes pour modéliser une plateforme logicielle d’exécution : (1) la caractérisation des concepts d’une plateforme (les ressources d’une plateforme)(2) la caractérisation des trai-tements (les services associées aux ressources).(3) la caractérisation des règles d’utilisation d’une plateforme (des contraintes et des patrons d’utilisation des ressources et des services offertes par une plateforme).(4) La caractérisation de comportement observable d’une plateforme (le cycle de vie d’une ressource sous l’influence des services).
Un modèle de plateforme logicielle pour l’analyse d’ordonnançabilité doit être focalisé sur les aspects de celle-ci nécessaires pour vérifier les contraintes de temps d’une applica-tion. En d’autres termes, ce modèle décrit uniquement les éléments de la plateforme qui interviennent pour la vérification temporelle. Citons quelques concepts d’une plateforme lo-gicielle d’exécution nécessaires pour la vérification temporelles des applications visées dans cette étude :
– Entité ordonnançable(Tâche) : Toute entité qui implémente les fonctions applicatives et qui est gérée par un ordonnanceur. L’ordre des priorités des tâches ainsi que leur type (périodique, sporadique, etc.) constituent les aspects de ce concept qui ont une influence direct sur les résultats d’analyse. Si le concept d’une tâche périodique n’existe pas par défaut dans un RTOS, le modèle de plateforme introduit un patron pour la description de ce dernier.
– Ordonnanceur : C’est un concept du noyau qui détermine la prochaine tâche à exé-cuter selon une politique d’ordonnancement. Cette politique ainsi que le mode de l’or-donnanceur (préemtif ou non préemptif) constituent l’ensemble des propriétés qui ca-ractérisent ce concept et qui ont un impact sur les résultats d’analyse.
– Ressource Partagée : C’est une ressource qui implémente une section critique. Cette ressource est en général protégée par un mécanisme et une politique de la file asso-ciée qui gère l’accès simultané à cette dernière (Sémaphore ou Mutex). De plus, cette ressource peut être caractérisée par un protocole de synchronisation afin d’éviter les problèmes d’inversion de priorité et inter-blocage détaillés dans 5.3.2. Le type de ce protocole a une influence sur les résultats d’analyse.
Il est clair alors qu’une description structurelle est suffisante pour l’élaboration des mo-dèles de plateformes pour l’analyse d’ordonnançabilité. Ainsi, dans cette étude, Nous nous focalisons sur le premier et le troisième axes identifiés par Thomas pour la création des mo-dèles de plateformes logicielles d’exécution. Voyons maintenant quelques exemples de lan-gage de modélisation de ces plateformes.

Langages de modélisation des plateformes

Plusieurs travaux se sont intéressés à la définition de langages pour la description des plateformes pour l’exécution de logiciel. Ces langages peuvent être basés sur le langage UML, les profils UML, ou des langages spécifiques de type DSL (Domain Specific Language).
AADL
AADL (Architecture Analysis and Design Language) [68], standardisé par le SAE (So-ciety of Automotive Engineers) en 2004, est un langage de description d’architectures pour les systèmes temps réel embarqués. L’élément de base du langage AADL est le composant. Chaque composant est défini par son type et son implémentation (décrit le contenu du com-posant en termes de sous-composants, code, etc.). Les composants sont liés à travers des
Les plateformes d’exécution 21
ports et des connexions. Un port est un point d’entrée et/ou de sortie d’un composant, une connexion permet de relier deux ports. Un type de composant AADL appartient à une caté-gorie. Ces catégories sont prédéfinies et se décomposent en catégories matérielles, catégories logicielles ou catégories système. . Les quatre catégories de base pour le logiciel permettent la description d’une plateforme avec les concepts suivants : Thread (unité d’exécution concur-rente qui peut être ordonnançable), Data (structure de données qui peut être partagée par les composants), Thread group (permet de créer une hiérarchie dans les threads) et Process (un espace mémoire pour l’exécution des threads). À chaque composant on peut associer des propriétés et leur donner des valeurs. Celles-ci permettent de caractériser le composant. Certaines propriétés sont prédéfinies, c’est-à-dire qu’elles sont identifiées par un nom, un type et la liste des catégories de composants sur lesquelles elles s’appliquent. Par exemple les tâches (thread) disposent de propriétés temps-réel telles que la période, l’échéance ou la durée d’exécution. De nouvelles propriétés, et de nouveaux types de propriétés, peuvent aussi être définis par l’utilisateur et associés à tout ou partie des catégories de composants. Ce mécanisme de propriétés est un point fort d’AADL en matière d’extensibilité. Grâce à lui, toute notion spécifique au besoin de l’utilisateur peut être prise en compte dans sa descrip-tion.
Pour la modélisation des plateformes, le langage AADL ne peut pas être vu comme étant un méta-modèle de plateforme. En effet, la sémantique d’exécution des composants logiciels est clairement spécifiée dans la norme. Par contre, ce langage peut être considéré comme une plateforme abstraite. En effet, AADL permet de décrire explicitement des applications logicielles. Il est également possible de générer des modèles spécifiques à des plateformes d’exécution concrètes à partir d’une description AADL. Par exemple, dans [32] les auteurs proposent un environnement pour la génération des systèmes ARINC653 [18] à partir d’une description AADL.
Metropolis
En se basant sur l’approche Platform Based Design [75], le projet Metropolis [72] offre un cadre méthodologique pour le développement des systèmes embarqués. Le point clé de ce projet est la définition d’un méta-modèle permettant de représenter l’application, l’archi-tecture et le déploiement de l’application sur l’architecture. Ce méta-modèle est définit avec une sémantique précise permettant ainsi à l’environnement Metropolis de couvrir presque toutes les phases de cycle de développement : conception, simulation, analyse formelle et synthèse. Pour modéliser une plateforme (matérielle ou logicielle), le méta-modèle Metro-polis définit trois concepts de base : les unités d’exécution concurrente (Process), les Media qui sont utilisées pour connecter les interfaces des Process et assurer ainsi la communication des données et la synchronisation entre eux et le Quantity manager permettant de contrôler l’accès aux Media. Toutes les instances de ces concepts sont regroupées en Netlist. L’environ-nement Metropolis offre la possibilité d’exprimer, à un haut niveau, des contraintes. Ainsi, il intègre en complément des langages formels, tels que LTL (Linear Temporal Logic) ou LOC
Le méta-modèle introduit dans le cadre du projet Metropolis est un méta-modèle de pla-teforme permettant ainsi une description explicite d’une plateforme. Cependant, la généri-cité du méta-modèle de cette approche, ne facilite pas la description des plateformes dans un domaine particulier [31]. En effet, les concepts de Process et de Media sont utilisés aussi bien pour la description de l’application que pour la description de la plateforme. Ceci li-mite l’utilisation de cette approche à des fins de modélisation détaillée des ressources d’une plateforme logicielle.
TUT-Profile
TUT-profile [51] est un langage basé sur l’extension de la version 2.0 d’UML. Ce pro-fil a été proposé initialement pour la conception des systèmes temps réel embarqués et la description de l’architecture matérielle. Il a été étendu, par la suite, pour supporter la mo-délisation des plateformes logicielles d’exécution [15]. Pour ce faire, TUT-profile propose quatre concepts : SwPlatform, SwPlatformLibrary, SwPlatformComponent et SwPlatformProcess. Le premier concept, SwPlatform, caractérise une plateforme logicielle dans sa globalité. Le SwPlatformLibrary permet de décrire un package regroupant les concepts d’une plateforme. Ainsi, une plateforme logicielle est constituée d’un ensemble de librairies logicielles. Chaque concept de la plateforme logicielle est représenté par une classe et caractérisé comme étant un SwPlatformComponent. Finalement, le SwPlatformProcess est représenté par un élément typé dont le type correspond à un concept de la plateforme annoté par SwPlatformCom-ponent.
Bien que ce langage présente l’avantage d’étendre un standard (UML), il reste encore trop générique pour la modélisation détaillée des ressources d’une plateforme logicielle. En effet, toutes les ressources offertes par la plateforme sont annotées par SwPlatformComponent. Ainsi, une tâche, une ressource ou un ordonnanceur sont tous modélisés de la même façon dans ce profil. Ceci présente une limitation pour ce profil pour garantir la spécification d’un modèle décrivant les ressources d’une plateforme avec une sémantique précise.
UML-MARTE
Le profil MARTE (UML profile for Modeling and Analysis of Real Time and Embedded systems) [64], standardisé par l’OMG en août 2007, permet de modéliser des plateformes d’exécution matérielles ou logicielles à différents niveaux d’abstraction. Ce profil a remplacé le profil SPT (Schedulability, Performance and Time) [66] en assurant la couverture de tous les aspects logiciels et matériels des systèmes embarqués temps réel. L’objet de ce profil est de soutenir par une riche base d’annotations facilitant l’utilisation d’UML pour la modélisa-tion et l’analyse des systèmes temps réels embarqués. Le profil MARTE est organisé en trois paquetages principaux : « MARTE Foundations », « MARTE Design Model » et « MARTE Analysis Model ». Le premier paquetage fournit les bases du langage traitant la modélisa-tion des propriétés non-fonctionnelles du temps, des ressources génériques et des allocations
Les plateformes d’exécution 23
des systèmes embarqués temps réel. Les deux autres paquetages sont des spécialisations du premier se focalisant sur un aspect particulier : Le paquetage « MARTE Design Model » four-nit les artéfacts nécessaires pour modéliser les applications et les plates-formes d’exécution matérielles ou logicielles à différents niveaux d’abstraction. Quant au paquetage « MARTE Analysis Model », il définit les concepts nécessaires pour analyser les systèmes. En parti-culier pour la modélisation des plateformes logicielles, MARTE offre un sous profil défini dans le paquetage « MARTE Design Model » qui est SRM (Software Resource Modeling). Ce profil spécialise le sous profil GRM (Generic Resource Modeling) appartenant au paque-tage « MARTE Foundations ». SRM définit les artéfacts permettant de décrire finement trois familles de ressources logicielles : les ressources d’exécution concurrentes (comme une inter-ruption ou une tâche), les ressources d’interaction entre les entités concurrentes (comme une boîte aux lettres ou les mécanismes de sémaphore) et les ressources de gestion des entités matérielles et logicielles (comme les ordonnanceurs). Le profil SRM est organisé en quatre paquetages comme le montre la figure 2.6.

Plateformes cibles et processus de développement des STRE

L’objectif principal d’un processus de développement des systèmes temps réel embar-qués (STRE) est de traduire les exigences du cahier des charges (fonctionnelles et non fonc-tionnelles) en une application déployée sur une plateforme cible. Dans un cadre IDM, ce processus passe en général par trois activités, chaque activité est supportée par un type de modèle. Une activité de spécification permet de traduire les exigences et les contraintes d’une application en un modèle de spécification, une activité de conception permet d’introduire des choix architecturaux afin de décrire une réalisation possible de cette application indé-pendamment de toute plateforme dans un modèle de conception et enfin une activité de déploiement permet de rendre cette réalisation spécifique à une technologie logicielle dans un modèle d’implémentation. La plateforme d’exécution cible est prise en compte dans un tel processus lors du déploiement de la description architecturale de l’application sur une plateforme logicielle afin d’assurer son exécution.
Pour la prise en compte des contraintes temps réel, le processus de développement des STRE introduit, durant la phase de conception, une activité de vérification des propriétés temporelles. Afin de vérifier un système, il faut construire un modèle formel approprié per-mettant cette vérification. Un point clé de la construction de ce modèle porte sur l’introduc-tion de la concurrence ainsi que la sémantique d’exécution permettant son interprétation. La définition d’une sémantique d’exécution des architectures pour des raisons d’analyse néces-site une abstraction des informations liées à la plateforme logicielle d’exécution telles que la politique d’ordonnancement, l’ordre de priorité, etc. Ceci nous amène à la nécessité de prendre en compte la plateforme logicielle pour la vérification des applications temps réel.
Dans cette partie, nous nous intéressons tout d’abord à quelques travaux qui se sont fo-calisés sur la prise en compte des aspects temps-réel lors du processus de développement des STRE. En particulier, nous nous arrêtons sur la façon de prendre en compte la plateforme logicielle pour vérifier les contraintes temporelles de l’application. Ensuite, nous présentons les différentes études qui se sont intéressées au déploiement d’une application sur une pla-teforme logicielle, avant de donner le bilan de cette partie et le positionnement par rapport à ce qui existe pour introduire la contribution de cette thèse.

Prise en compte des plateformes pour la vérification des contraintes tempo-relles des applications

Afin de permettre la vérification des contraintes temporelles lors d’un processus de dé-veloppement des STRE, certains travaux se sont orientés vers une vérification des modèles spécifiques à des plateformes d’exécution logicielles. En effet, un modèle de l’application spécifique à une plateforme logicielle définit en général une description de la réalisation de cette l’application sur la plateforme considérée. Cette réalisation exprime la concurrence et introduit une sémantique d’exécution claire permettant ainsi la vérification des contraintes temporelles de l’application. Dans ce contexte, citons le travail de Moore, présenté dans [60], qui a proposé d’étendre RT-UML Profile (UML Profile on Scheduling, Performance and Time) pour supporter l’infrastructure OSEK [6]. Dans ce travail, la plateforme OSEK est re-présentée de façon implicite au niveau méta-modèle afin de permettre la description des applications. En outre, l’auteur propose d’ajouter au profil RT-UML un sous-profil person-nalisé afin de faciliter l’analyse d’ordonnançabilité des systèmes OSEK.
La figure 2.7 donne un extrait du sous-profil OSEK pour l’analyse d’ordonnançabilité. Ce sous-profil définit les concepts nécessaires et leurs propriétés nécessaires pour vérifier qu’un système OSEK est ordonnançable. Dans [89], les auteurs proposent une approche ba-sée sur les modèles pour la conception et la vérification des systèmes OSEK afin de faciliter le développement des systèmes automobiles. Contrairement au travail précédent, ce travail se base sur une plateforme abstraite appelée SmartOSEK [94], compatible avec le standard OSEK, décrite explicitement dans un modèle. Afin de générer un modèle de l’application spécifique à OSEK, les auteurs suivent une approche MDA ; partant d’une application dé-crite avec UML et indépendante de toute plateforme et du modèle de la plateforme SmartO-SEK, les auteurs génèrent le modèle de l’application spécifique à OSEK par la définition de règles de transformation entre les concepts UML et SmartOSEK. Ainsi, l’étape de vérification des propriétés temporelles de l’application est réalisée sur ce modèle généré spécifique à la plateforme OSEK par l’intermédiaire d’un simulateur (SmartOSEK Simulator) fournit avec la méthodologie. Dans [21], les auteurs introduisent une approche pour la vérification des applications spécifiques à l’API Real-Time Java (RT-Java) [25]. Contrairement aux deux ap-proches précédemment cités, les auteurs n’optent pas pour une vérification temporelle des modèles spécifiques à RT-java, mais plutôt cherchent à assurer la traçabilité des contraintes temps réel à partir du modèle de l’application vers le code. Cette approche utilise le profile RT-UML pour annoter les modèles des applications avec les propriétés temporelles. Ensuite, elle définit des règles de mapping entre les stéréotypes et les tagged values du profil RT-UML d’une part et les concepts RT-Java d’autre part afin de propager les contraintes temps réel au niveau code. Ainsi, une analyse du code RT-Java de l’application est effectuée dans le but de vérifier si les contraintes de temps déjà propagées sont respectées. La plateforme d’analyse est représentée dans cette approche d’une façon enfouie dans les transformations permettant de générer un code analysable. D’autres travaux s’orientent vers une vérification temporelle, durant la phase de concep-tion, des modèles des applications indépendants de toute plateforme d’exécution logicielle. L’objectif de ces approches en général est la description d’une application dans un modèle d’architecture qui respecte les contraintes de temps. Pour cela, ces approches font une abs-traction de la plateforme matérielle (en supposant que celle-ci est fixe) et considèrent des hypothèses sur la plateforme logicielle pour rendre le modèle d’architecture analysable et garder en même temps l’indépendance vis-à-vis de l’implémentation. Dans ce cas, les hy-pothèses à considérer dépendent fortement de la technique d’analyse à appliquer. Parmi ces approches, notons le travail décrit dans [19], qui montre une approche pour la synthèse des modèles d’architecture à partir des blocs fonctionnels décrivant une application temps réel. L’objectif des auteurs, dans ce papier, est de générer un modèle d’architecture qui satisfait les contraintes de temps. Pour cela, ils proposent d’effectuer un test d’ordonnançabilité basé sur l’utilisation du processeur [20]. Pour cette technique d’analyse, seule une hypothèse liée à la politique d’ordonnancement est nécessaire. Ainsi, dans ce papier, les auteurs supposent que l’ordonnanceur est de type EDF (Earliest Deadline First)[93]. Dans [49][62] les auteurs cherchent aussi à générer un modèle d’architecture d’une application temps réel qui satis-fait les contraintes de temps. Pour cela, ces deux travaux utilisent une technique d’analyse basée sur le calcul d’une borne supérieure sur les temps de réponse des tâches constituant le modèle. Ainsi, afin de permettre ce type d’analyse, les auteurs dans [49] supposent qu’ils disposent d’un ordonnanceur préemptif de type priorité fixe [52]. Ils supposent aussi que l’ordre de priorité est croissant c’est-à-dire plus la valeur de priorité est grande, plus la tâche est prioritaire. Pour le calcul du temps de blocage dû à la synchronisation des tâches et qui est un facteur important dans le calcul du temps de réponse, ce travail donne une estima-tion de ce temps. En effet, selon l’application, les auteurs considèrent une hypothèse sur la valeur du temps blocage. Dans la méthodologie Optimum proposée dans [62], les auteurs supposent aussi qu’ils disposent d’un ordonnanceur préemptif de type priorité fixe [52], ce-pendant, l’ordre de priorité est décroissant dans cette approche. Pour le temps de blocage, les auteurs dans ce travail cherche à avoir une valeur plus précise que le travail précédent en essayant de calculer sa valeur. Ceci nécessite une hypothèse supplémentaire sur la plate-forme logicielle et qui correspond au protocole de synchronisation utilisé. Ce protocole est fixé à Priority Ceiling Protocol (PCP) [43] dans le cadre de cette approche.
Différentes approches sont proposées dans le but de vérifier les contraintes temporelles d’une application dans un cycle de développement des systèmes temps réel embarqués. Cette vérification nécessite une prise en compte de quelques aspects de la plateforme logi-cielle d’exécution. Pour cela, ces travaux s’orientent soit vers une vérification des modèles des applications spécifiques à une plateforme d’exécution particulière [60][89] [21], soit vers une considération des hypothèses sur la plateforme cible dans le but de rester indépendant de cette dernière et suivre la ligne de le MDA [19][49][62].Dans la partie suivante, nous al-lons introduire quelques travaux qui ont été proposées dans un cadre IDM dans le but de déployer une application sur une plateforme logicielle.

Prise en compte des plateformes lors du déploiement des applications

Le déploiement d’une application sur une plateforme technologique consiste à générer un modèle de l’application spécifique à cette technologie. Ce modèle représente l’implé-mentation de l’application sur la plateforme considérée à un niveau plus abstrait que le code. L’approche IDM, telle que préconisée par le MDA, a fait une séparation claire entre les aspects métiers et les aspects liés à la plateforme en les décrivant dans des modèles dis-tincts. Le point fort d’une telle séparation offre la possibilité de générer plusieurs modèles spécifiques à différentes plateformes (PSM) à partir du même modèle de l’application in-dépendant de la plateforme (PIM). C’est dans ce cadre, que plusieurs approches ont été proposées dans le but d’automatiser ce déploiement en proposant des processus basés sur une prise en compte explicite de la plateforme logicielle cible. Parmi ces approches, citons le travail présenté dans [86]. Ce travail définit un cadre méthodologique pour le portage d’une application d’une plateforme à une autre en se basant sur une description explicite et commune des plateformes source et cible. Cette description est réalisée en utilisant le pro-fil SRM comme un langage pivot pour l’élaboration d’une infrastructure de transformation indépendante des plateformes. Afin de permettre le déploiement d’une application sur une plateforme logicielle, le sous profil HLAM (High Level Application Modeling) de la norme MARTE [64] est utilisé pour décrire initialement cette dernière. Ce profil autorise la des-cription des exécutions concurrentes à un haut niveau d’abstraction et peut être considérée comme une plateforme logicielle. Ainsi, le déploiement correspond à une opération de por-tage de l’application de la plateforme HLAM décrite en utilisant SRM à une autre plateforme explicitement décrite en utilisant aussi SRM. En effet, pour chaque instance du modèle de départ dont le type est stéréotypé dans la plateforme source (la plate-forme de départ qui est ici HLAM), s’il existe une ressource stéréotypée de la même façon dans la plate-forme cible (la nouvelle plate-forme sur laquelle l’application doit être déployée), cette ressource est instanciée.
Dans la même idée, le travail proposé dans [29], vise à mettre en place un environnement de déploiement d’une application sur différentes plateformes logicielles décrite en utilisant le langage RTEPML. Dans ce travail, l’auteur a également défini un ensemble de règles de transformation génériques pour automatiser le déploiement des systèmes multi-tâches. En effet, ce déploiement repose sur le principe d’intégration d’une application, décrite dans un méta-modèle de l’application, sur une plateforme explicitement décrite avec RTEPML. Ce mécanisme d’intégration consiste à générer un modèle de la plateforme enrichi des ins-tances de ressources qui mettent en œuvre l’application. L’application est alors modélisée, ou intégrée dans le modèle de la plate-forme, au travers des instances de ressources mises à contribution pour son exécution.
Le travail présenté dans [30] complète le travail présenté dans [86] en tenant compte de l’aspect comportemental lors de la description des plateformes logicielles. L’objectif de ce travail est d’automatiser le processus de déploiement d’une application multi-tâches sur une plateforme logicielle dans le but de générer un modèle détaillé de l’application spéci-fique à la plateforme permettant ainsi la génération d’un code complet. Pour cela, cette ap-proche propose des heuristiques de modélisation permettant d’offrir des modèles détaillés des plateformes logicielles d’exécution. Ces modèles détaillés sont décrits d’une manière commune par le profil SRM du standard MARTE [64]. D’autre part, cette approche définit des transformations de modèles génériques basées sur la notion des patrons de conceptions comportementaux permettant la gestion des mécanismes de communication et de synchro-nisation d’une manière indépendante de la plateforme. L’utilisation de ces patrons permet une génération automatique des aspects comportementaux liés à la plateforme dans le mo-dèle d’application spécifique à celle-ci.
Les travaux présentés dans cette partie s’intéressent plus au déploiement des applica-tions sur une plateforme d’exécution logicielle qu’aux aspects temps réel. Leur objectif est de proposer des transformations génériques permettant le déploiement d’une application sur une plateforme en suivant les principes de le MDA.

Synthèse et discussion

Dans ce chapitre, nous avons présenté des travaux pour le développement des systèmes temps  réel embarqués. Le point clé des travaux présentés est qu’ils introduisent implicite-ment ou explicitement la notion de plateforme logicielle dans leur étude. Nous avons ainsi groupé ces travaux selon l’objectif pour lequel la plateforme logicielle a été introduite.
Le premier groupe concerne les approches qui se sont focalisées sur l’aspect temps réel. Ces approches font appel à une étape de vérification des contraintes de temps qui nécessite à son tour une prise en compte de certaines propriétés de la plateforme logicielle. Afin d’in-troduire l’aspect plateforme pour des fins d’analyse, nous avons identifié deux solutions : La première solution consiste à vérifier des modèles spécifiques à des plateformes logicielles [60][89] [21]. Quant à la deuxième, elle s’oriente vers une vérification des modèles indé-pendants des plateformes en considérant des hypothèses sur ces derniers [19][49][62]. La première solution est applicable dans le cas où une seule plateforme est visée. Néanmoins, elle est peu bénéfique dans un contexte multiplateforme. Dans un tel scénario, la vérification des contraintes de temps se fait après le déploiement ce qui contredit en quelque sorte les principes du MDA et diminue la portabilité de l’application. La deuxième solution est avan-tageuse puisqu’elle permet une vérification des contraintes de temps avant le déploiement sur une plateforme logicielle c’est-à-dire durant la phase de conception. Cette solution est plus adaptée au contexte MDA puisqu’elle permet une vérification des contraintes de temps plus tôt dans le cycle d’une part, d’autre part, elle cherche à assurer la portabilité de l’ap-plication validée. Cependant, toutes les approches qui ont adoptées cette solution ne sont pas parvenu, dans leur processus, jusqu’au déploiement de l’application validée sur une plateforme d’exécution logicielle. En effet, le déploiement de l’application sur la plateforme considérée est une tâche non triviale. Les hypothèses logicielles considérées pour vérifier les contraintes de temps de l’application durant la phase de conception peuvent être non véri-fiées pour la plateforme logicielle cible sur laquelle l’application vise à être déployée. Ainsi, le modèle de l’application spécifique à cette plateforme peut ne pas correspondre au modèle de conception initial de l’application (différentes interprétions sémantiques des deux mo-dèles) ce qui peut affecter les propriétés temporelles déjà vérifiées. Dans un tel scénario, le concepteur est obligé de reboucler pour revoir ses choix de conception. Cette opération peut se répéter plusieurs fois jusqu’à ce que l’origine du problème soit détectée. Ceci entraîne l’allongement du cycle de développement et contredit une des contraintes de conception actuelle qui est la réduction du délai de mise sur le marché (time-to-market).
Le deuxième groupe concerne les approches qui ont été proposées dans un cadre IDM dans le but de déployer une application sur une plateforme logicielle. Le point commun de ces travaux c’est de respecter le principe du MDA en faisant une séparation entre l’aspect applicatif et l’aspect plateforme. Ceci garantit la portabilité de l’application et la possibi-lité de déployer cette dernière sur différentes plateformes. Néanmoins, toutes ces approches [86][29][30] considèrent des applications temps réel non critiques, et portent moins d’atten-tion, que les approches du groupe précédent, à l’aspect temps réel. Cependant, toutes ces approches considèrent des applications multi-tâches en introduisant la notion de concur-rence et en particulier le concept de priorité. Seulement, aucune de ces approches n’a traité le problème de la sémantique liée à la priorité qui peut varier d’une plateforme à une autre. Il reste tout de même nécessaire de préserver les propriétés de l’application lors du passage des phases de conception aux phases d’implémentation. D’autre part, dans [86], l’auteur pro-pose un processus génératif pour le portage d’une application d’une plateforme à une autre. Ce travail suppose que ce portage est réalisable quel que soit la plateforme, ce qui n’est pas toujours vrai dû à la diversité des plateformes qui peuvent ne pas être caractérisées de la même façon.
Le tableau 2.2 résume cette partie en présentant une comparaison des principales ap-proches étudiées selon trois critères : l’aspect temps réel (les applications considérées par l’approche sont critiques), le déploiement (l’approche arrive jusqu’à la génération d’un mo-dèle de l’application spécifique à une plateforme) et la portabilité (l’approche propose une solution adaptée à un contexte multiplateforme).

Table des matières

Liste des tableaux
1 Introduction 
1.1 Contexte
1.2 Problématique
1.3 Contributions
1.4 Organisation du document
2 État de l’art 
2.1 Introduction
2.2 Domaine de l’étude
2.2.1 Les systèmes temps réel embarqués
2.2.1.1 Mise en œuvre des systèmes temps réel embarqués
2.2.1.2 Vérification des applications temps réel embarquées
2.2.2 Ingénierie Dirigée par les modèles (IDM)
2.2.2.1 Modèles, méta-modèles et transformations de modèles
2.2.2.2 Approche MDA
2.2.2.3 Caractérisation d’une plateforme dans un cadre IDM
2.2.3 Synthèse
2.3 Les plateformes d’exécution
2.3.1 Représentations des plateformes d’exécution dans l’IDM
2.3.2 Modélisation des plateformes d’exécution
2.3.2.1 Modèle de plateforme pour l’analyse d’ordonnançabilité
2.3.2.2 Langages de modélisation des plateformes
2.3.3 Synthèse
2.4 Plateformes cibles et processus de développement des STRE
2.4.1 Prise en compte des plateformes pour la vérification des contraintes temporelles des applications
2.4.2 Prise en compte des plateformes lors du déploiement des applications
2.4.3 Synthèse et discussion
2.5 Conclusion
3 DRIM : un processus pour le déploiement multiplateforme des applications temps réel 
3.1 Introduction
3.2 Contribution à la prise en compte explicite des plateformes logicielles pour l’analyse
3.2.1 Modèles de plateformes de point de vue analyse dans l’IDM
3.2.2 Identification des besoins pour une plateforme abstraite d’analyse
3.3 Processus DRIM
3.3.1 Vue d’ensemble du processus DRIM
3.3.2 La phase de refactoring
3.4 Conclusion
4 Méthodologie de modélisation dans DRIM 
4.1 Introduction
4.2 Description du langage de modélisation
4.2.1 Le méta-modèle DRIM : un méta-modèle pour la description des plateformes logicielles
4.2.2 Le profil DRIM : une extension du profil MARTE
4.2.2.1 Implantation du méta-modèle DRIM dans un profil UML
4.2.2.2 Identification des concepts pour la modélisation des applications dans DRIM
4.3 Règles méthodologiques de modélisation
4.3.1 Les règles de modélisation de plateformes
4.3.1.1 Les règles liées aux éléments UML
4.3.1.2 Les règles de stéréotypage
4.3.2 Les règles de modélisation des applications temps réel
4.4 Conclusion
5 Mise en œuvre du processus DRIM 
5.1 Introduction
5.2 Évaluation de faisabilité du déploiement
5.2.1 Test de l’ordonnanceur
5.2.2 Test des ressources partagées
5.2.3 Identification des tests pour la notion de priorité
5.2.3.1 Test des niveaux de priorité distincts
5.2.3.2 Test des niveaux de priorité égaux
5.2.3.3 Test de priorité dynamique
5.3 Génération et validation des modèles d’implémentation
5.3.1 Phase de Portage
5.3.1.1 Définition des règles de correspondance
5.3.1.2 Principe de portage
5.3.2 Phase de validation du Portage
5.4 Phase de refactoring
5.4.1 NPAP : Un patron pour une nouvelle assignation des valeurs des priorités
5.4.2 DPMP : Un patron pour la fusion des tâches de priorités distinctes
5.4.3 EPMP : Un patron pour la fusion des tâches de priorités égales
5.4.4 SRMP : Un patron pour la fusion des ressources partagées
5.5 Conclusion
6 Évaluations et expérimentations 
6.1 Introduction
6.2 Contexte
6.2.1 Qompass-Architect
6.2.2 Définition des critères d’évaluation
6.3 Étude de cas : Application de Contrôle de Robot
6.3.1 Aperçu global sur le système étudié
6.3.2 Spécification de l’application de contrôle de robot
6.3.2.1 Fonctionnement
6.3.2.2 Contraintes temps réel
6.3.3 Modélisation de l’application de contrôle de robot
6.3.3.1 Description fonctionnelle : Diagramme de structure composite 115
6.3.3.2 Description comportementale : Diagramme d’activité
6.3.4 Génération d’un modèle de conception initial pour l’application de contrôle de robot
6.4 Résultats et discussion
6.4.1 Déploiement de l’application sur un RTOS qui peut varier
6.4.2 Déploiement de l’application sur un RTOS fixe
6.5 Conclusion
7 Conclusion et perspectives 
7.1 Bilan
7.2 Perspectives
Liste des Publications
Bibliographie

Télécharger le rapport complet