Le chapitre 4 a comme objectif de présenter l'ensemble des services de communication fournis par l'intergiciel, et les principes méthodologiques pour son développement.
3.2.1 Services de communication fournis par l'intergiciel
L'intergiciel doit orir des services permettant les échanges de signaux entre tâches applicatives distantes. Néanmoins, selon ce qui a été établi dans le chapitre 1, ces services doivent d'une part, masquer le protocole de communication utilisé, et, d'autre part, cacher la localisation des tâches applicatives qui reçoivent les signaux. L'ensemble de services de communication est composé de deux primitives accessibles aux tâches applicatives :
1. une primitive qui permet à une tâche applicative la soumission de la valeur d'un signal produit, an que l'intergiciel se charge de sa transmission, et
2. une primitive qui permet à une tâche applicative d'obtenir la dernière valeur d'un signal reçue par l'intergiciel.
Quand la primitive 1 est utilisée, la tâche applicative fournit la nouvelle valeur produite et une iden-tication du signal correspondant. Cette nouvelle valeur est sauvegardée dans l'intergiciel (en écrasant
l'ancienne), et elle sera mise en trame et transmise par l'intergiciel aux instants déterminés par la con-guration de trames (voir chapitre Concon-guration of the frames, résumé en section 3.5).
Pour utiliser la primitive 2, la tâche applicative fournit un identicateur de signal et reçoit la valeur du signal stockée dans l'intergiciel, donc la dernière valeur reçue par celui-ci. Quand une nouvelle valeur est reçue par l'intergiciel, elle écrase l'ancienne valeur. Ainsi, les tâches applicatives peuvent ou non consommer toutes les valeurs reçues, tout dépend de leur période de consommation et des intervalles de temps entre les arrivées des valeurs.
La méthodologie proposée ne considère que ces deux services, qui sont toutefois conformes aux objectifs énoncés : ils sont indépendants vis-à-vis du protocole de communication et de la localisation des tâches. D'autres services pourraient être oerts par l'intergiciel. Le chapitre Quality of Service monitoring through communication services (résumé en section 3.7) analyse, par exemple, les conséquences liées à l'intégration à l'intergiciel, de services de notication aux tâches applicatives.
3.2.2 Principes méthodologiques pour le développement de l'intergiciel
L'objectif sous-jacent nal de la méthodologie est le développement d'un système qui respecte toutes les propriétés qui lui sont imposées, en particulier les propriétés de performances. Ceci passe par une caractérisation (activation, priorité) des tâches applicatives, des tâches de l'intergiciel et des trames échangées entre les ECUs. Dans ce problème, les tâches applicatives sont données (charge CPU, règles d'activation) mais leur priorité n'est pas dénie. Nous considérons, dans ce travail, que pour leur attribuer des priorités, il faut au préalable dénir les caractéristiques des tâches qui exécutent l'intergiciel sur chaque ECU. Ces caractéristiques permettent ainsi une quantication exacte de l'interférence provoquée par l'intergiciel sur les tâches applicatives. Cependant, les caractéristiques des tâches de l'intergiciel dépendent du résultat de la conguration de trames. L'algorithme qui détermine cette conguration repose sur un calcul du pire temps de réponse pour toutes les tâches (intervalle de temps maximal entre l'activation d'une tâche et sa n d'exécution), c'est-à-dire sur un modèle de tâche applicative qui exhibe, déjà, les priorités de celles-ci. Ce raisonnement fait apparaître le fait que chaque activité élémentaire (caractérisation de tâches applicatives, caractérisation de tâches de l'intergiciel, caractérisation de trames) dépend du résultat des autres activités. Pour surmonter cette boucle d'interdépendance, nous proposons un processus de conguration, illustré à la gure 3.1et détaillé rapidement par la suite. Les principes méthodologiques de notre proposition reposent sur deux points principaux :• l'identication d'une architecture générique de l'intergiciel (nombre de tâches, règles d'activation de chaque tâche et fonctions de celles-ci),
• l'instanciation de l'architecture générique précédente pour une application et une distribution don-nées (conguration des tâches de l'intergiciel, des tâches applicatives et des trames).
La gure 3.1 représente la partie de la méthodologie qui concerne l'instanciation de l'architecture générique, c'est-à-dire le développement de l'intergiciel pour une application donnée ; le rôle de ce proces-sus est la génération des paramètres de conguration qui sont dépendants des contraintes imposées par l'application (tâches applicatives et signaux).
• La première étape de ce processus est l'activité qui congure les trames (composition, priorité, règles d'émission). Pour pouvoir attribuer des caractéristiques temporelles aux trames tout en s'assurant du respect de la fraîcheur des signaux, cette activité est conditionnée par l'architecture générique de l'intergiciel, appelée par la suite modèle d'implémentation de l'intergiciel. Ses données d'entrées sont les caractéristiques des signaux (taille, contraintes de fraîcheur) et certaines caractéristiques des tâches applicatives (règles d'activation et charge CPU). Ce problème est développé au chapitre 7 et résumé à la section 3.5.
• La deuxième étape consiste en la caractérisation complète, dans un premier temps, des tâches de l'intergiciel puis, des tâches applicatives. La caractérisation des tâches de l'intergiciel est égale-ment conditionnée par le modèle générique d'impléégale-mentation de celui-ci ; ses données d'entrée sont l'ensemble des trames congurées et faisables ainsi que les composants logiciels à déployer dans
Spécification des signaux (sur chaque ECU)
Configuration de trames Ensemble de trames faisable Ensemble de trames non faisable Configuration des tâches intergicielles Allocation de priorités Sur chaque ECU Tâches intergicielles (code généré, temps d'exécution , période d'activation, échéance relative) Ensemble de tâches applicatives et intergicielles faisables Spécification des tâches
applicatives (sur chaque ECU)
Modèle d'implémentation de l'intergiciel Modèle de composants logiciels de l'intergiciel Aucune allocation de priorités faisable États d'échéc Légende: Activité Données d'entrée et de sortie du problème chapitre 5 chapitre 6 chapitre 7 chapitre 8
ces tâches (méthodes, séquences de code). Le résultat est l'empreinte de l'intergiciel à savoir, un ensemble partiellement conguré de tâches (règles d'activation) ainsi que le code exécuté par ces tâches. Dans un deuxième temps, sont déterminées les priorités des tâches de l'intergiciel et des tâches applicatives. Le processus complet de cette étape est détaillé au chapitre 8 et résumé en section 3.6.
Le développement d'un intergiciel pour une application et une distribution données est conditionné, ainsi que nous l'avons vu ci-dessus, sur le modèle générique d'architecture de l'intergiciel (modèle d'implémentation et sur et utilise, comme donnée d'entrée, le modèle des composants logiciels de cet intergiciel tels que dé-nis, par exemple, par un diagramme de classes UML. Ces modèles permettent l'identication des tâches, des composants logiciels génériques (méthodes ou séquences de code), et l'algorithme de déploiement des composants logiciels dans les tâches. La démarche, pour obtenir ces modèles est illustrée dans la gure 3.2. Cette démarche prend en compte les hypothèses préalables à notre étude et les contraintes im-posées par le contexte d'exécution de l'intergiciel (système d'exploitation, plate-forme de communication, ...). Comment dénir une architecture générique d'un intergiciel embarqué dans l'automobile fait l'objet du chapitre 5 (résumé en section 3.3) tandis que l'identication des composants logiciels génériques est traitée au chapitre 6 (résumé en section 3.4).
Modèle d'implémentation de l'intergiciel Modèle de composants logiciels de l'intergiciel Identification de tâches Identification des composants logiciels Spécification d'OSEK/VDX OS Stratégies d'identification de tâches Fonctionnalités et événements d'activation de
l'intergiciel design patternsCatalogue de
Services de communication de l'intergiciel Légende: Activité Données d'entrée et de sortie du problème chapitre 5 chapitre 6
Figure 3.2: Identication d'une architecture de composants logiciels et de tâches de l'intergiciel.