La conception des systèmes temps-réel répartis embarqués

La conception des systèmes temps-réel répartis embarqués

Modéliser pour l’analyse et la génération de code

Les représentations du système sont élaborées par des formalismes différents et évoluent à des niveaux d’abstraction différents. La sémantique des constructions d’un langage de programmation utilisées pour l’implantation du système définit un niveau d’abstraction trop bas (trop de détails) qui complexifie l’exploitation du code source pour l’analyse des propriétés du système. Les formalismes dédiés à l’analyse d’un système réparti tel les réseaux de Petri (comportement) définissent des abstractions trop élevées pour permettre l’exploitation du modèle d’analyse à des fins de génération de code. Afin de renforcer la cohérence entre les modèles d’analyse et le code généré, il est donc nécessaire de déterminer une représentation intermédiaire contenant à la fois des informations pour l’analyse du système et un niveau de détail suffisant pour une démarche de génération de code efficace. Notre première problématique est donc : Comment déterminer un niveau d’abstraction “intermédiaire” limitant les transformations pour (1) diminuer la granularité du modèle et rendre les analyses réalisables et (2) augmenter la granularité du modèle et permettre une démarche de génération de code efficace ?

Analyser une représentation complète du système

Un second problème consiste à réaliser les analyses à partir d’une description complète de l’application incluant aussi bien les composants applicatifs que les composants de son exécutif. Dans le contexte des systèmes TR2E critiques, les composants de l’exécutif correspondent aux composants d’un intergiciel. L’introduction des intergiciels et des standards de répartition a simplifié la conception des applications réparties. Le développeur n’a pas à se charger des aspects dits bas-niveau, notamment liés à la communication (réception des tampons de communication, extraction des données…) et dépendants de la plate-forme d’exécution de l’application. Des routines dites de plus haut-niveau pour l’envoi et la réception des données lui sont fournies et masquent la complexité de la mise en œuvre de la répartition. La spécification des composants intergiciels dès les premières étapes de la modélisation va ainsi à l’encontre de la philosophie des modèles où l’abstraction des détails d’implantation est prépondérante lors des premières étapes d’analyse. Cependant, les ressources déclarées par l’intergiciel ont un impact sur l’architecture logicielle et l’implantation de l’application (gestion des ressources de communication, donnée partagée…). Par conséquent, il est nécessaire de prendre en compte ces ressources lors des différentes analyses (faisabilité, performance…) réalisées sur un modèle final de l’application. Notre seconde problématique est donc la suivante : Comment modéliser les composants intergiciels et à quel moment les intégrer au modèle initial pour une analyse complète du système ?

Processus de réalisation automatique et complexité

Les processus de réalisation de systèmes critiques basés sur une approche IDM automatisent les étapes d’analyse, de déploiement, de configuration et d’intégration des composants constituant l’application. Le déploiement revient à sélectionner et placer explicitement les différents constituants de l’application sur leurs emplacements physiques respectifs et préparer leur exécution (par exemple, le placement des entités responsables de l’envoi ou de la réception des messages sur un nœud). La configuration consiste à personnaliser ces composants sélectionnés en fonction des besoins et des propriétés de l’application (par exemple, l’ouverture des canaux de communication requis par un nœud donné). Enfin, l’intégration est la dernière phase de la réalisation permettant l’assemblage des différents composants (applicatifs, intergiciels et utilisateurs) qui forment l’application. Celle-ci s’effectue lors de la compilation de l’application. Cependant, les composants intergiciels sont implantés dans le langage de programmation cible et nécessitent le développement et la maintenance d’un intergiciel par générateur de code. Ceci implique un processus de génération automatique complexe, effectuant plusieurs transformations et introduisant des mécanismes supplémentaires pour assurer l’assemblage correct des composants applicatifs et des composants intergiciels. De plus, ce processus automatique peut être différent en fonction du langage de programmation cible. La seconde problématique que nous avons présentée suggère que les étapes de déploiement et de configuration soient réalisées lors de la phase de modélisation de l’application complète pour que les analyses soient effectuées sur une représentation cohérente avec l’implantation physique. Ceci limite donc la difficulté de maintenir plusieurs versions d’intergiciel et permet la simplification du processus de génération automatique en autorisant la production de l’ensemble . En revanche, nous devons être capables d’adresser différents langages de programmation cible. Notre troisième problématique est donc : Comment produire automatiquement le code de l’application en limitant le plus possible les différences entre les générateurs ?