THeSys : Tackling Heterogeneous Systems

Venir à bout des systèmes hétérogènes

THeSys est un groupe de chercheurs du laboratoire LSP (Logiciels pour la Sûreté des Procédés) du CEA, LIST, du Département Informatique de Supélec et de l'École Centrale qui travaillent en commun sur la modélisation des systèmes hétérogènes.

La conception de systèmes complexes fait intervenir différents métiers qui utilisent chacun des méthodologies et des outils de modélisation adaptés à leurs pratiques. Cette hétérogénéité des méthodes de modélisation rend difficile l'intégration des différentes parties du système et limite la portée même des méthodes. En particulier, les traitements qui prennent en charge les échanges entre un système logiciel et son environnement font largement appel à des techniques ad hoc, spécifiques à chaque type d'environnement. Ceci limite la capacité à obtenir des logiciels maintenables, réutilisables et validables, tant par la diversité des méthodologies employées que par la complexité de leurs interactions.

Un enjeu pour une meilleure maîtrise des systèmes embarqués complexes est ainsi d'élaborer un cadre formel, le plus général possible, qui permette de décrire les différentes méthodes de modélisation et la façon dont elles peuvent être combinées, et à partir de ce cadre, obtenir des méthodes de réalisation outillées et validées répondant à la variété des produits spécifiques. Un axe directeur de dissémination de ces travaux est la capacité à projeter les résultats théoriques sur les méthodologies communément employées afin de les rendre utilisables par diverses communautés.

Contact : François Terrier (CEA), Frédéric Boulanger (Supélec), Marc Aiguier (Centrale)

Introduction et vocabulaire

Modélisation Hétérogène

Les systèmes embarqués modernes contiennent couramment des sous systèmes logiciels, matériels et mécaniques. En ce sens de tels systèmes sont intrinsèquement hétérogènes. Une tentation naturelle à l’étape de la conception de tels systèmes, est de refléter cette hétérogénéité au niveau de la modélisation. En effet, selon la nature du sous-système à modéliser, il existe des langages de modélisation plus ou moins adaptés en terme d’expressivité. En suivant cette approche, on obtient une collection de modèles hétérogènes (décrits dans des langages différents) qui ne forme pas un modèle du système complet. En effet chaque modèle a sa propre sémantique induite par le langage utilisé pour le décrire, mais la collection des modèles ne définit pas la façon dont les sémantiques locales se combinent au niveau du système complet.

Pour résoudre ce problème, une solution classique est de traduire tous les modèles en d’autres modèles décrits dans un langage commun, langage dans lequel on va aussi décrire la manière dont les modèles traduits doivent être recollés sémantiquement. Le principal problème posé par ce type d’approche, hormis le problème de la correction de la traduction, est qu’il est difficile d’avoir une vision claire de la pertinence des recollements de modèles que l’on décrit dans le langage commun. En effet pour avoir une vision claire des liens entre cette « colle » décrite dans un cadre homogène et les modèles initiaux décrits dans un cadre hétérogène il faut parfaitement comprendre à la fois : tous les modèles initiaux (donc tous les langages utilisés pour les décrire), les mécanismes de traductions et le langage commun cible, et enfin évidemment les comportements attendus du système complet.

Pour essayer de contourner ce problème, d’autres approches consistent à ne pas « casser » la dimension hétérogène de la modélisation en projetant les modèles dans un cadre homogène, mais plutôt de définir un langage de recollement qui permette de prendre en compte directement des modèles hétérogènes. D’un point de vue sémantique, la différence fondamentale avec la première approche est que l’on ne traduit pas complètement chaque modèle dans un cadre commun, mais que l’on essaie uniquement d’avoir une vue partielle de la sémantique de chaque modèle : cette vue partielle doit uniquement refléter les comportements observables de chaque sous-système qui sont aussi pertinents pour définir le recollement. Le langage de recollement est alors uniquement utilisé pour décrire les interactions entre ces vues partielles des sémantiques de chaque modèle.

Le champ de recherche du groupe THeSys se situe au plan de la définition de tels langages et méthodologies associées.

Modèles de calcul et d'exécution

Les systèmes embarqués sont des systèmes réactifs (i.e. qui interagissent continûment avec leur environnement). De ce fait, il est naturel de choisir pour les modéliser les langages de description comportementale. Dans de tels langages, un modèle est décrit sous la forme d’un ensemble de processus qui interagissent les uns avec les autres. Les langages pour décrire ces processus sont généralement basés sur deux paradigmes :

• Un paradigme d’exécution pour décrire des opérations qui peuvent renvoyer des résultats mais aussi modifier l’état interne du système (comme par exemple une affectation). La définition de la sémantique des ces opérations et de leurs combinaisons fait l’objet de la sémantique d’exécution du processus.

• Un paradigme d’interaction pour décrire la sémantique d’exécution d’un système à partir des sémantiques d’exécution des différents processus qui composent le système. La sémantique des règles qui sous-tendent cette description fait l’objet de la sémantique d’interaction de processus.

Un modèle de calcul est l'ensemble des règles qui régissent les interactions des composants d'un modèle. Ces règles constituent un jeu d'axiomes que doivent satisfaire les comportements possibles du modèle, mais elles n'indiquent pas nécessairement comment calculer ces comportements, ni s'il en existe ou s'il en existe un unique.

Un modèle d'exécution est un algorithme qui permet de calculer un comportement d'un modèle en combinant les comportements de ses composants. Un modèle d'exécution peut ne calculer qu'un comportement possible parmi ceux qu'autorise un modèle de calcul. Il peut aussi exister plusieurs modèles d'exécution qui correspondent au même modèle de calcul.

L'approche de THeSys

Hétérogénéité des modèles de calculs et d’exécution

Dans le cadre de THeSys, nous nous concentrons sur une vision « modèle de calcul » de la sémantique des systèmes. Ceci est cohérent avec notre volonté de traiter des systèmes embarqués. La conception de ces systèmes combine en effet différents métiers, qui ont chacun une approche particulière, et différents supports d’exécution (matériel, logiciel s’exécutant sur différents types de processeurs), ce qui conduit à l’utilisation de nombreux modèles de calcul. De plus, ces systèmes doivent généralement fonctionner sous des contraintes de disponibilité de différentes ressources (temps, espace mémoire, énergie) qu’il faut prendre en compte dans leur modèle.

Un système hétérogène est donc un système que l’on modélise en utilisant plusieurs modèles de calcul. Un des objectifs de THeSys est de décrire formellement la notion de modèle de calcul afin de pouvoir donner un sens précis aux modèles hétérogènes, et notamment aux interactions entre modèles de calcul.

Un modèle d’un système est constitué de composants qui interagissent selon un modèle de calcul, mais chaque composant peut lui-même être considéré comme un système et être décrit par un modèle. On n’autorise généralement l’utilisation que d’un seul modèle de calcul à chaque niveau de la hiérarchie d’un modèle, même si la notion de « composant à interface hétérogène » 1) permet l’utilisation conjointe de plusieurs modèles de calcul à un même niveau. L’hétérogénéité peut donc apparaître de deux façons dans un modèle :

• différents composants du modèle utilisent différents modèles de calculs parce qu’ils sont conçus selon des approches différentes ;

• un même composant du modèle possède plusieurs modèles qui utilisent des modèles de calcul différents parcequ’ils modélisent différents aspect de ce composant.

Le second cas peut être rapproché de la modélisation par aspects et n’est pas l’objet principal de nos travaux. Notre but est de déterminer de manière précise le comportement d’un système à partir de celui de ses composants, ce qui nécessite de définir précisément les règles de leurs interactions.

Intégration des modèles de calcul

L'intégration des différents modèles de calcul utilisés dans le modèle d'un système peut se faire par projection sur un modèle d'exécution commun dont la sémantique a un niveau d'abstraction faible. Il s'agit de la méthode classique qui consiste à implémenter des modèles de calcul (par exemple, des automates à états finis et du Matlab) dans un même langage de programmation (par exemple C) pour produire une application. Une autre technique consiste à projeter un modèle de calcul sur un autre. On peut ainsi « coder » un automate sous forme de flots de données afin de ne conserver qu'un seul modèle d'exécution.

L'inconvénient de ces techniques est que l'adaptation entre les modèles de calcul est faite lors de la projection. On n'a donc plus accès au modèle d'origine lorsqu'on exécute, simule ou teste ou valide le système.

Afin d'éviter cette perte sémantique entre le modèle « idéal » défini par les concepteurs et le modèle « codé » dans l'outil de modélisation, il est nécessaire de traiter explicitement l'hétérogénéité, en précisant notamment ce qui se passe à la frontière entre deux modèles de calcul : échange de données, synchronisation du contrôle, représentation différentes du temps.

Traitement explicite de l'hétérogénéité

Actuellement, le traitement explicte de l'hétérogénéité dans les modèles se heurte à deux types de difficultés :

Nous considérons que l'adaptation entre modèles de calcul est un choix de conception qui doit apparaître explicitement dans le modèle du système. Afin de pouvoir décrire cette adaptation, il est nécessaire de décrire formellement les modèles de calcul. Un des objectifs de THeSys est de définir un méta-modèle qui permette de décrire les modèles de calcul et d'exprimer l'adaptation entre modèles de calcul sous forme d'une transformation de modèle.

Documents disponibles

État de l'art

Nous avons réalisé un état de l'art sur la modélisation hétérogène exécutable des systèmes, et comparé notre approche aux autres dans un document rédigé dans le cadre du projet Usine Logicielle du pôle de compétitivité System@tic.

Exposés de la journée Hétérogénéo du 23 avril 2007

Membres de THeSys

Chef du département Informatique de Supélec : Yolaine Bourda

Chef du service LIST/DTSI/SOL au CEA : Jan Stransky

Par ordre alphabétique :

—-

Envoyer un e-mail aux membres de THeSys

Accès au Wiki de THeSys