Modélisation des systèmes temps-réel répartis embarqués pour la ...

More documents

Recommendations

Info

autre nœud Modélisation des systèmes temps-réel répartis embarqués autre nœud réseau application personnalité applicative personnalité protocolaire couche neutre personnalité protocolaire FIG. VI.2 – Organisation d’une instance de PolyORB tions sur chaque nœud local de l’application. Ces services sont les suivants : le service d’adressage enregistre les entités servants et crée les références vers ces entités pour qu’elles puissent être appelées par la suite. le service de transport crée les points d’accès pour les requêtes de connexion entrantes. le service de liaison associe un subrogé (c-à-d une entité de liaison) à une entité répartie. Il gère la qualité de service associés aux connexions. le service de représentation prend en charge la conversion des structures de données entre la représentation neutre et celle des applications ou des protocoles. le service de protocole prend en charge l’émission et la réception des requêtes. Il contrôle notamment le service de transport. le service d’activation reçoit une référence à une entité servante and lui associe l’entité correspondante. le service d’exécution alloue les ressources nécessaires à l’exécution de l’entité servante. Ces différents services sont coordonnés par un composant central, le µBroker. Le µBroker prend en charge la gestion des threads systèmes et l’ordonnancement des requêtes. Par la sélection et l’assemblage des implantations de ces différents services, et par la sélection des politiques de gestion du µBroker, il est possible d’adapter les mécanismes de traitement des requêtes, indépendamment des personnalités utilisées. VI-2.2.2 Construction d’une personnalité applicative pour AADL La couche applicative constitue l’interface entre l’application AADL en elle-même et la partie de l’exécutif décrite en AADL. Elle doit piloter les composants de l’application : elle reçoit les requêtes, en extrait les données, exécute les composants applicatifs correspondants et récupère les résultats. Dans le cadre d’une utilisation de PolyORB comme intergiciel de haut niveau pour notre exécutif AADL, la couche d’interface entre l’enveloppe applicative et l’intergiciel lui-même est matérialisée par une personnalité applicative. À chaque thread AADL nous associons un servant 104 c○ 2007 Thomas Vergnaud
Chapitre VI – Construction et configuration de l’interface avec l’intergiciel d’exécution PolyORB. Ce servant reçoit toutes les requêtes correspondant aux éléments d’interface du thread AADL. VI-2.2.3 Éléments de configuration de l’intergiciel L’architecture de PolyORB permet une grande flexibilité dans la configuration, que ce soit par le choix de personnalités adaptés ou la configuration des éléments de la couche neutre [Hugues, 2006]. Certains paramètres de configuration peuvent être déduits de l’assemblage des composants, tandis que d’autres peuvent correspondre à des propriétés AADL. Nous exposons ici comment transposer les descriptions AADL en éléments de configuration pour l’exécutif basé sur PolyORB. Politique de gestion des threads systèmes Une application stricte de la sémantique des thread AADL correspondrait à associer un thread système – c’est-à-dire une tâche de PolyORB – à chaque servant. Une telle gestion des tâches n’est pas implantée dans des intergiciels comme PolyORB, qui sont orientés sur le traitement des requêtes. Cela conduit à une interprétation différente des threads AADL. Dans une implantation basée sur un intergiciel de haut niveau tel que PolyORB, les différents threads AADL représentent un ensemble de threads du système, qui sont affectés au traitement des différentes requêtes. Parmi les différentes politiques de gestion des tâches offertes par PolyORB, la plus adaptée est la définition d’un ensemble de threads (thread pool) dont le cardinal est défini par le nombre de threads AADL instanciés dans chaque processus. Ces threads sont indifférenciés, dans la mesure où il doivent pouvoir être affectés au traitement des requêtes correspondant aux éléments d’interface de tous les threads AADL du processus considéré ; ils peuvent prendre en charge l’écoute sur le service de transport et le traitement des requêtes. Cela correspond à l’application d’une politique de contrôle des tâches équitable. PolyORB propose pour cela deux politiques, basic et leader/follower. Gestion des priorités AADL permet de spécifier une priorité dans le traitement des différents threads, au moyen de la propriété Priority définie dans l’ensemble Language_Support. Cette notion peut se traduire par un mécanisme de priorités associées aux servants de l’intergiciel, telle que définie dans l’implantation RT-CORBA de PolyORB. Sélection des personnalités protocolaires Il est nécessaire de sélectionner les protocoles à utiliser pour les communications inter-processus AADL. Les protocoles que nous considérons ici s’appliquent aux flux de données entre les processus (relevant des couches session, présentation et application du modèle OSI [Tanenbaum, 2003]), qui sont représentés par les connexions AADL. Les couches de protocole plus basses (couches liaison, réseau et transport dans le modèle OSI) concernent les bus AADL, qui modélisent des réseaux physiques. Deux stratégies peuvent être suivies pour prendre en charge la sélection des protocoles du niveau applicatif : – la mise en place de politiques de sélection de protocole en fonction des constructions architecturales. – la définition de propriétés AADL pour la spécification explicite des protocoles à utiliser ; c○ 2007 Thomas Vergnaud 105
Page 1 and 2:
École doctorale d’informatique,
Page 3:
Telle est la nature de l’esprit h
Page 6 and 7:
To validate this design process, we
Page 8 and 9:
Modélisation des systèmes temps-r
Page 10 and 11:
Page 12 and 13:
Page 14 and 15:
Page 16 and 17:
Page 18 and 19:
Page 20 and 21:
Page 22 and 23:
II-2.2.2 CORBA Modélisation des sy
Page 24 and 25:
II-2.2.3 RMI Modélisation des syst
Page 26 and 27:
Page 28 and 29:
Page 30 and 31:
Page 32 and 33:
II-4.4 Discussion Modélisation des
Page 34 and 35:
II-5.2.2 Connecteurs Modélisation
Page 36 and 37:
18 } Modélisation des systèmes te
Page 38 and 39:
Page 40 and 41:
Page 42 and 43:
Page 44 and 45:
11 end i486.AMD; 12 Modélisation d
Page 46 and 47:
Page 48 and 49:
Page 50 and 51:
Page 52 and 53:
1 system global 2 end global; 3 Mod
Page 54 and 55:
Page 56 and 57:
Page 58 and 59:
Page 60 and 61:
Page 62 and 63:
16 Modélisation des systèmes temp
Page 64 and 65:
Page 66 and 67: Modélisation des systèmes temps-r
Page 72 and 73: phase 1 phase 2 Modélisation des s
Page 84 and 85: descriptions comportementales Modé
Page 90 and 91: 17 end sp.impl; Modélisation des s
Page 102 and 103: 13 Modélisation des systèmes temp
Page 124 and 125: 10 features Modélisation des syst
Page 126 and 127: VI-3.4.6 Activation Modélisation d
Page 138 and 139: donnee (a) donnée Modélisation de
Page 144 and 145: 53 end global.impl; Modélisation d
Page 154 and 155: 15 end sspg_b; Modélisation des sy
Page 156 and 157: 1 data donnee 2 end donnee; 3 4 thr
Page 166 and 167:
Page 168 and 169:
Page 170 and 171:
Page 172 and 173:
19 use Partition; 20 Modélisation
Page 174 and 175:
23 begin Modélisation des système
Page 176 and 177:
Page 178 and 179:
VIII-3.1 Motifs AADL de base Modél
Page 180 and 181:
Page 182 and 183:
Page 184 and 185:
Page 186 and 187:
Page 188 and 189:
Page 190 and 191:
Page 192 and 193:
Page 194 and 195:
Page 196 and 197:
Page 198 and 199:
Page 200 and 201:
Page 202 and 203:
show all

Modélisation des systèmes temps-réel répartis embarqués pour la ...

Create successful ePaper yourself

Delete template?

Save as template?