L'objectif de ce chapitre est d'étudier les conséquences de l'intégration de services de notication sur les modèles d'implémentation et de composants logiciels. En particulier, ces services doivent fournir aux tâches applicatives des informations concernant l'état de transmission et réception des signaux produits et consommés. Concrètement, nous nous sommes intéressés à la validation de notre méthodologie, en vériant que les modèles d'implémentation et de composants logiciels restent valides dans un nouveau contexte en termes de l'ensemble de services fournis par l'intergiciel. De plus, du fait que les services proposés sont les mêmes que ceux considérés par le standard OSEK/VDX COM, nous avons voulu vérier que leur implémentation était possible dans notre contexte.
3.7.1 Services de notication à intégrer
Les services de notication intégrés à l'intergiciel sont :• un service qui indique à une tâche applicative si la transmission des valeurs d'un signal produites précédemment a respecté les contraintes de fraîcheur ou non, et
• un service qui informe une tâche applicative si une valeur d'un signal disponible pour la consom-mation respecte la contrainte de fraîcheur ou non.
Ces services sont appelés d'état de transmission et réception respectivement. Les services fournis initiale-ment par l'intergiciel (voir section 3.2) ont été modiés de manière à retourner ces états.
3.7.2 Conséquences sur le modèle d'implémentation de l'intergiciel
Les nouveaux services sont fortement liés aux services de communication introduits dans la section 3.2. Pour cette raison, nous avons pondéré la possibilité d'implémenter les services de notication en util-isant la tâche et la routine de service d'interruption (ISR) qui s'occupent de la communication. Des nouveaux types d'alarmes temporelles devraient être ajoutées au système. Néanmoins, la spécica-tion d'OSEK/VDX OS ne permet pas l'activaspécica-tion de l'ISR à partir d'une alarme temporelle. En plus, l'autre tâche de l'intergiciel perdrait son schéma d'activation périodique, rendant dicile l'analyse d'ordonnançabilité.
Nous avons alors essayé d'implémenter les services de notication en utilisant un ensemble de tâches diérent, toujours activées par des alarmes temporelles. Cette solution, dont l'implémentation serait possible sur OSEK/VDX OS, avait l'avantage de valider notre méthodologie, vu que chaque nouvelle tâche serait activée par un type d'événements diérent. Cependant, si la nouvelle tâche responsable par l'état de transmission serait préemptée en début d'exécution, alors la vérication du respect des contraintes de fraîcheur ne serait pas précise.
Il nous a semblé évident que la solution serait de diminuer le niveau de qualité de service requis. Ainsi, nous avons transformé l'ensemble de services de notication présentés dans la section 3.7.1 dans celui-ci :
• un service qui informe une tâche applicative si les valeurs d'un signal produites précédemment ont été déjà utilisées pour construire une trame ou non, et
• un service qui notie une tâche applicative si la valeur d'un signal a été mise à jour depuis la dernière consommation ou non.
Notez que cette solution valide aussi notre méthodologie. Du fait que l'ensemble de tâches de l'intergiciel sur chaque ECU n'a pas changé, le modèle d'implémentation détaillé en section 3.3 reste valable. Remar-quez toutefois que les services proposés par OSEK/VDX COM n'ont pas pu être implémentés, à cause d'une possible perte importante au niveau de la précision de la réponse oerte.
3.7.3 Conséquences sur le modèle de composants logiciels
Le modèle de composants logiciels de l'intergiciel n'est pas modié profondément. L'ensemble de classes est le même, mais certaines méthodes doivent être changées de façon à exprimer l'existence des services de notication. Ces méthodes sont facilement identiables à cause de l'utilisation des design patterns pour la construction du modèle. Les méthodes à modier appartiennent aux classes Proxy_Scheduler, Signals, et Core. La liste des méthodes modiés, bien comme les changements à eectuer, sont présentés de manière détaillée dans le chapitre 9.
3.8 Conclusion
Dans ce chapitre, nous avons résumé les contributions de notre travail qui sont présentées en détail dans la deuxième partie de ce document. Nous avons donné les grandes lignes de la méthodologie de développement des services de communication d'un intergiciel embarqué dans l'automobile. Nous avons montré que celle-ci est divisée en deux parties. La première s'occupe de spécier les modèles génériques des composants logiciels et de leur déploiement sur une plate-forme donnée. La deuxième partie présente les solutions que nous proposons pour instancier ces modèles génériques pour une application spécique. En particulier, nous montrons qu'il faut générer les paramètres temporels nécessaires à la conguration de l'intergiciel, des trames, et des tâches applicatives, de façon que toutes les contraintes sur les tâches et sur les signaux soient respectées. Nous allons ensuite entrer dans la deuxième partie de cette thèse, où cette méthodologie est présentée et chaque activité qui la compose est détaillée.
Part II
Contributions
Chapter 4
Introduction
4.1 Introduction
In chapter 1, the middleware that is proposed to be developed was introduced. In particular, some specic characteristics that the middleware must present were listed. Among them, two are enhanced in the following:
• the middleware must provide a standard set of communication services, and
• the middleware executes asynchronously from applicative tasks
The goal of this chapter is to present to the reader the set of communication services that are going to be provided by the middleware, and the methodology proposed for its development.
The communication services must allow signals to be exchanged between applicative tasks indepen-dently from their location. The methodology must rstly, permit the development of a middleware that implements the communication services in an asynchronous way. It handles signals, produced and con-sumed by applicative tasks, and handles frames, sent and received by the network controller. Secondly, it must construct the set of frames that are going to be transmitted over the network, such that, the bandwidth consumption is minimized. Finally, it has to determine conguration parameters that allow applicative tasks, the middleware itself, and the network frames to meet their deadline constraints, and signals freshness constraints to be respected.
The objective, for what concerns the implementation and deployment of the middleware, is:
• to identify a set of tasks capable of implementing the communication services,
• to express the sequences of code that will be executed by each task on each ECU, and
• to calculate the conguration parameters that will permit to attain the feasibility of the tasks while respecting the timing constraints of the signals.
At the end, one should have a middleware whose code is established and able to be generated, and whose conguration guarantees feasibility on each ECU.