Modèle de programmation multi-coeurs sur architectures virtualisées 

Télécharger le fichier pdf d’un mémoire de fin d’études

Architecture des systèmes de divertissement du consommateur

Les systèmes de divertissement du consommateur ont été les premiers, dans le milieu des années 1920, à introduire des composants électroniques au sein des véhicules sous la forme de récepteurs radio à lampes. Si l’apparition de transistors, dans les années 1950, a contribué à l’amélioration des capacités techniques des appareils et à la di usion massive des autoradios au sein des automobiles, le concept de base a peu évolué jusqu’à la n des années 1970. L’introduc-tion des premiers systèmes de navigation dans les années 1980, puis des systèmes multimédia dans les années 2000 a changé la donne. Désormais, la façade de l’autoradio est nommée head unit et concentre 70% du code du véhicule.
Le système multimédia moderne a un rôle qui va au-delà de celui du simple autoradio : il sert d’interface entre le véhicule et le consommateur, contribuant ainsi à l’expérience utilisateur et devenant un des principaux critères de choix lors de l’achat du véhicule. Il est devenu un domaine que les constructeurs ne peuvent ni ne veulent abandonner.
A contrario des systèmes mécatroniques, où chaque constructeur dispose d’un quasi-monopole sur les solutions qu’il décide d’intégrer dans son véhicule, les systèmes de divertissement du consommateur ont, de tout temps, été soumis à la concurrence agressive des produits issus du marché de l’après-vente (« After market ») et maintenant de l’industrie du marché grand public (« Consumer markets »).

De l’autoradio aux systèmes multimédia

Des années 1920 aux années 2000, l’autoradio est le principal système de divertissement des conducteurs et passagers présent au sein des véhicules. Implantés au départ en utilisant un format propre à chaque constructeur, la mise en œuvre de la norme DIN 75490 [66] en 1984 standardise le montage des autoradios et contribue à la création d’un marché d’après-vente qui concurrence les solutions proposées par les constructeurs et équipementiers.
Les premiers systèmes de navigation apparaissent dans les années 1980-90 (GPS CARMI-NAT sur Safrane en 1995). Réservés aux véhicules haut de gamme, ils utilisent des écrans CRT couleurs pour a cher les trajets, les cartes de navigation sont stockées sur CDROM et la po-sition du véhicule est calculée en utilisant des technologies de reconnaissance cartographique (« map matching ») nécessitant un accès à des capteurs du véhicule (vitesse, accéléromètre, capteur angulaire au niveau de la direction, …) couplé aux premiers récepteurs de GPS [64]. Les volumes de ventes sont faibles et les constructeurs ont du mal à rentabiliser leurs coûts de développement et de fabrication. En mai 2000 [51], le président Clinton prend la décision d’arrêter la dégradation volontaire du service civil du GPS, qui était e ectuée pour des raisons de sécurité nationale, augmentant ainsi la précision du GPS de 100 à 10 mètres. Les systèmes de navigation, qui n’ont plus besoin des techniques de reconnaissance cartographique intégrées au véhicule pour être opérationnels, se di usent alors massivement aux utilisateurs du monde automobile sous la forme de Personal Navigation Devices issus des marchés de l’après-vente. Ils introduisent une nouvelle ergonomie associant écran plat couleur et interface tactile.
A la n des années 2000, la di usion massive des smartphones modi e les attentes des consommateurs qui souhaitent désormais pouvoir accéder aux mêmes services dans leurs voi-tures que dans leurs téléphones. Les constructeurs et équipementiers sont donc mis en concur-rence avec des acteurs du monde du marché grand public qui béné cient de gigantesques vo-lumes de production générant d’importants capitaux et qui sortent de nouveaux produits à un rythme soutenu, stimulant ainsi l’appétit insatiable des consommateurs pour de nouvelles fonctionnalités. Le système multimédia, nommé aussi IVI (in-vehicle infotainment) devient un important di érenciateur, pour les clients, lors de l’acte d’achat du véhicule. Une des raisons du succès des acteurs du monde du marché grand public réside dans la richesse de leur écosystème applicatif. Par le déploiement de marchés d’applications (Apple store, Google Play, …) couplé à la di usion de kits de développement, les éditeurs de plates-formes du marché grand public ont mis en œuvre une politique incitative pour encourager les développeurs à créer de nou-velles applications. Le nombre nal d’applications ainsi développées dépasse largement celui qui aurait pu être nancé par les fonds propres des éditeurs.
Les systèmes multimédia des véhicules modernes doivent également composer les contraintes de développement du monde de l’informatique grand public avec les contraintes du monde au-tomobile. Les nouvelles fonctionnalités introduites au sein des véhicules ne doivent pas mettre en danger le conducteur que ce soit par un manque d’ergonomie, de sûreté ou de sécurité. Le matériel utilisé dans les voitures est soumis à des contraintes physiques (Températures, Électromagnétisme, vibrations) qui sont largement plus destructrices que celles subies par les téléphones. Il doit donc être conçu et certi é [5] pour pouvoir tolérer ces contraintes ce qui entraîne une augmentation des coûts et, de fait, un allongement de sa durée d’utilisation pour le rentabiliser. En n, alors que le rythme de renouvellement des smartphones et donc des appli-cations associées est en moyenne de 2 ans [152], les constructeurs doivent garantir la pérennité de leurs produits pendant toute la durée de vie du véhicule (10 ans après le dernier véhicule sorti de chaîne soit au total une durée moyenne de 15 ans).
Face aux contraintes des systèmes multimédia, les acteurs du monde automobile sont en di culté. En e et, les solutions historiques de divertissement de l’automobile sont basées sur des systèmes propriétaires développés en propre par chaque équipementier. La prise en compte des demandes des consommateurs entraîne donc une augmentation exponentielle de la quan-tité de logiciel à produire et des coûts de développement, de validation et de test associés. Les équipementiers se retrouvent à la traîne et essayent dans une perpétuelle course de rattraper les innovations technologiques générées par l’industrie du marché grand public. Ce problème est exacerbé par le mode de fonctionnement interne à l’industrie automobile où chaque équi-pementier développe sa propre solution, et concourt contre les autres fournisseurs a n d’être sélectionné par les constructeurs automobiles pour, au nal, vendre un faible nombre de pé-riphériques. Aucun acteur du monde automobile ne dispose d’assez d’in uence pour devenir attractif et inciter les développeurs d’applications à développer pour leur solution propriétaire ce qui entraînerait une réduction de leurs coûts de développement.
Pour faire face à ces di cultés, les constructeurs et équipementiers ont créé un consor-tium nommé GENIVI Alliance qui regroupe 180 industriels a n de dé nir un standard logiciel, réutilisant des solutions libres existantes, applicable au multimédia du monde automobile.

Contraintes architecturales

L’évolution des fonctionnalités intégrées au sein des systèmes multimédia s’est traduite par une augmentation en besoin de puissance de calcul, les systèmes IVI actuels des véhicules de-venant plus puissant que la plupart des calculateurs mécatroniques du véhicule. Pour faire face à cette demande, les architectures matérielles désormais embarquées au sein des calculateurs multimédia utilisent majoritairement des processeurs multi-cœurs et mettent en œuvre des techniques matérielles de maximalisation des performances (Unité de préchargement, Unité de prédiction de branchement, caches, . . . ) qui se font au détriment de la prédictibilité du ma-tériel.
Le système multimédia est également assujetti à des contraintes d’embarquabilité : taille, dissipation passive des composants, résistance aux vibrations et aux perturbations électroma-gnétiques, et à de forts impératifs de coûts. Les fabricants matériels ont donc opté pour une ap-proche COTS (Commercial O -The-Shelf ) consistant à réutiliser des architectures matérielles embarquées déjà développées pour des applications multimédia et à les décliner pour le monde automobile (Ajout de périphériques, certi cation ECM, …). A ce titre, nous avons utilisé au sein de ma thèse, la carte embarquée i.MX 6 SABRE Lite [119] une plate-forme COTS conçue pour exécuter des systèmes multimédia.
Les systèmes multimédia sont également sujets à des contraintes temps réel molles prin-cipalement liées aux temps de réponse nécessaires pour assurer l’a chage des contenus mul-timédia et la réactivité nécessaire aux interactions avec les utilisateurs. Au vu de la faiblesse des exigences ces contraintes ont des impacts minimaux sur la conception des architectures matérielles.

Tendances, limitations et solutions

Les besoins et les fonctionnalités du monde de l’automobile et du monde de l’embarqué sont en constante évolution. Or, les normes et les standards sont développés pour répondre aux évolutions passées et non aux tendances à venir. Elles font des choix techniques qui, logiques à un instant donné, peuvent ne plus être en adéquation avec les besoins futurs.
Dans cette section, nous évoquerons les évolutions prévisionnelles des besoins et fonction-nalités du monde automobile. Ensuite, nous détaillerons les limitations des architectures et standards actuellement utilisés. En n, nous proposerons des solutions pour combler les lacunes précédemment mises en évidence.

Tendances

Deux tendances se dégagent quant à l’évolution des systèmes embarqués dans les véhi-cules. Tout d’abord, nous observons une augmentation croissante du nombre de fonctionnali-tés contrôlées par le logiciel tant au sein des systèmes mécatroniques que des systèmes d’info divertissement. De plus en plus de fonctionnalités antérieurement mises en œuvre par de la mécanique ou par l’humain sont désormais suppléées ou remplacées par des logiciels. Nous constatons également que la séparation, originellement présente entre les systèmes mécatro-niques et les systèmes multimédia, tend à s’estomper. Désormais, les interfaces tactiles des systèmes multimédia se sont substituées aux interfaces mécaniques (Boutons, manettes, . . . ) contrôlées par les systèmes mécatroniques.

Une augmentation des fonctionnalités logicielles

Les systèmes mécatroniques introduits dans les années 1990 avaient pour objectif de sup-pléer aux organes mécaniques du véhicule en fournissant une assistance électrique contrôlée par du logiciel et ce, pour augmenter les performances et les fonctionnalités des produits. Le modèle économique actuel laisse à penser que cette dynamique va se poursuivre. Les véhicules haut de gamme produits par les constructeurs de luxe doivent sans cesse intégrer de nouvelles prestations supplémentaires pour justi er leur niveau de prix et se distinguer de la concurrence. Cette évolution du niveau de services se répercute in ne sur les constructeurs généralistes qui doivent, à terme, intégrer les mêmes services avec comme exigence supplémentaire un prix contenu.
Le modèle normatif actuel pousse également au développement des fonctionnalités logi-cielles. Le respect des normes européennes d’émission, dites normes EURO [40] passe par des développements logiciels de plus en plus poussés.
L’apparition des systèmes d’aide à la conduite (ADAS : Advanced Driver Assistance Systems) représente une nouvelle étape quant à l’augmentation des prestations ajoutées dans l’archi-tecture fonctionnelle. Ces systèmes qui ont été introduits dans le milieu des années 1990 [20, 45] utilisent des capteurs de l’environnement (radar, caméra, . . . ) a n d’assister le conducteur aussi bien pour l’alerter de l’apparition d’une situation accidentogène que pour le libérer de certaines tâches de conduite manuelle du véhicule. L’utilisation d’ADAS pour suppléer ou rem-placer les décisions et les actions humaines permet l’élimination des erreurs du conducteur, qui sont à l’origine de 93% [39] des accidents, engendrant une baisse des accidents de la route et un meilleur contrôle du véhicule. Les ADAS sont donc un enjeu de sécurité majeur et vont devoir être déployés sur l’ensemble des gammes de véhicules à un coût maîtrisé. En 2014, le département de la surveillance de la sécurité des transports des États Unis (NHTSA) a rendu obligatoire la présence d’une caméra de recul sur tous les véhicules de moins de 4,5t d’ici mai 2018 [96]. Le véhicule totalement autonome représente l’aboutissement des systèmes ADAS actuels. Les feuilles de route des constructeurs (Audi, BMW, Daimler, Ford, GM, Google, Kia, Mercedes-Benz, Renault-Nissan, Tesla, Toyota) prédisent l’arrivée des premiers véhicules au-tonomes, tout au moins sur une partie de leur trajet, en 2020 [18, 31, 38, 42, 44, 71, 131].
Les systèmes multimédia existants assurent un divertissement global à l’échelle de l’en-semble des passagers du véhicule. A l’heure actuelle, où une part croissante de la population française est équipée d’un smartphone, la présence d’un seul système multimédia pour tous les passagers du véhicule n’est plus su sante. Chaque passager va devoir accéder à son pro-gramme dédié d’info-divertissement et va vouloir contrôler la partie du véhicule avec laquelle il interagit physiquement.

Des systèmes de plus en plus intégrés

Si la séparation fonctionnelle et architecturale, initialement mise en place entre les systèmes mécatroniques et les systèmes de divertissement, était conceptuellement légitime et concrète-ment e ective, aucun canal de communication n’existant entre les systèmes, la frontière entre les deux types de systèmes s’est peu à peu estompée. Les premiers systèmes de localisation par GPS avaient besoin d’informations issues des organes mécaniques du véhicule (Capteur d’angle de volant, de vitesse de roue, …). Dans les nouveaux véhicules, des fonctionnalités, tra-ditionnellement dévolues aux systèmes mécatroniques, sont désormais gérées par les systèmes multimédia qui contrôlent une partie des organes du véhicule (climatisation, sièges…).
L’intégration fonctionnelle des deux types de systèmes va sans doute s’accélérer. En e et, comparativement aux interfaces des systèmes IVI, les interfaces homme-machine présentes dans les systèmes mécatroniques actuels sont relativement basiques. Elles se fondent sur une combinaison bien établie d’a cheurs (tableau de bord), de boutons et de manettes pour inter-agir avec le véhicule. L’in uence des systèmes multimédia, qui fait usage d’interfaces tactiles personnalisables couplées à des projections en trois dimensions, se répercute sur les interfaces homme-machine des systèmes mécatroniques qui vont devoir o rir les mêmes fonctionnalités. L’intégration fonctionnelle est également un moyen pour les constructeurs de se di érencier des systèmes d’info-divertissement proposés par les industriels de l’électronique grand pu-blic. Dans le futur, les deux classes de systèmes vont donc partager des périphériques (Écrans, a chage tête haute, antennes intelligentes, systèmes sonores, caméra, . . . ), des composants matériels (GPU, . . . ) et des fonctionnalités logicielles (Interface homme-machine, . . . ).
On observe également des tendances d’intégration au niveau de la connectivité. Les voi-tures modernes disposent toutes de moyens de communication laires (prise OBD) et, pour certaines, de connections sans l (2G, 3G, 4G, Wi-Fi, Bluetooth). Actuellement, ces connec-tiques sont séparées, les connectiques laires étant utilisées par les systèmes mécatroniques pour le débogage et les mises à jour, et les connectiques sans l étant utilisées par les systèmes multimédia. L’arrivée de nouvelles normes de communications inter-véhicules [24] (« Vehicle to Vehicle ») ou entre véhicules et équipements d’infrastructures (« Vehicle to Infrastructure »), basées sur des technologies sans ls, à but de coopération va mettre n à cette séparation. Les deux types de systèmes vont devoir accéder aux mêmes périphériques matériels.

Limitations de l’architecture logicielle

Les standards logiciels utilisés dans le monde de l’automobile disposent de points forts et de points faibles. AUTOSAR a été conçu pour développer des applications temps réel embar-quées dans des calculateurs disposant de faible taille mémoire, de faibles ressources CPU et communiquant avec des capteurs et actionneurs rudimentaires. Le système est con guré de façon statique : toutes les structures de données utilisées sont connues, déclarées à l’avance et initialisées statiquement. Le code des di érentes couches (Applicatif, RTE, OS) est compilé en un seul binaire, déployé en ROM ou en Flash, mais n’a pas besoin d’être stocké en RAM. Si cette con guration favorise l’embarquabilité du logiciel, elle complique les mises à jour des applicatifs et de l’OS, toute mise à jour d’un élément de la con guration entraînant la mise à jour et le redéploiement du binaire sur le calculateur.
AUTOSAR n’a pas été conçu pour échanger des informations avec les périphériques relati-vement complexes que sont les caméras, radars, GPU et écrans. Il n’o re donc aucune facilité quant à la réalisation d’interfaces homme-machine utilisant l’accélération matérielle. Les in-terfaces homme-machine réalisées sous AUTOSAR sont donc développées sous la forme d’un composant logiciel nommé « Complex Device Driver », transverse aux couches dé nies dans le standard. Ce type de composant a été conçu pour encapsuler des modules logiciels dont l’in-tégration, dans le standard, n’a pas été normalisée. La création de ce type de composant est complexe, la pile graphique nécessaire à la mise en œuvre des fonctionnalités d’accélération matérielles en 3D étant particulièrement compliquée.
De la même manière, les systèmes actuels d’ADAS ne sont pas développés en utilisant une architecture intégrée, tel que proposée par AUTOSAR, mais en utilisant une architecture fédé-rée. Les capteurs d’environnement, dits « intelligents » [25] qui perçoivent et analysent l’en-vironnement, sont développés en utilisant leurs propres standards logiciels et matériels. Ils communiquent les informations obtenues au système de prise de décision qui est conforme au standard AUTOSAR. Si cette solution est fonctionnelle avec les systèmes d’ADAS actuels, elle risque de ne plus l’être avec le véhicule autonome où il va falloir traiter et fusionner des données issues de multiples capteurs. Les prototypes des véhicules autonomes utilisent Linux comme système d’exploitation [39] avec un modèle de tâches à criticité multiples qui comprend un petit nombre de tâches temps réel ordonnancées en parallèle de tâches best e ort. Si l’utili-sation de Linux comme système d’exploitation dans les véhicules autonomes, règle un certain nombre de problèmes, elle pose des problèmes de sûreté de fonctionnement.
Le standard GENIVI, basé sur Linux, a été conçu pour exécuter des applications multimédia. Il est donc parfaitement adapté pour gérer les interfaces homme-machine et utiliser le GPU. Conçu avec une architecture logicielle dynamique, facilitant ainsi les mises à jour à distance, il a été utilisé comme démonstrateur pour implanter des tableaux de bord véhicule. En revanche, la quantité de code utilisée dans le système est considérable et ne respecte pas les règles de conception et de développement [65, 129] couramment utilisées dans les systèmes critiques. La mise en place de politiques de sûreté de fonctionnement sur des systèmes tels que le tableau de bord, classi é au niveau de criticité ASIL B, est donc un dé .

Limitations de l’architecture opérationnelle

Si la séparation fonctionnelle, établie entre les systèmes mécatroniques et les systèmes de divertissement n’est plus de mise, la di érenciation dans l’architecture logicielle et matérielle est, quant à elle, restée. L’intégration entre les deux types de systèmes, développés avec des standards logiciels et des architectures de calculateurs di érents, est actuellement réalisée en utilisant une architecture fédérée. Chaque système est déployé sur des ECUs dédiées qui sont reliées par une passerelle, nommée Telecommunication Unit, assurant le ltrage des communi-cations inter-calculateurs. Si ce type d’architecture a des avantages en termes de sécurité et de sûreté de fonctionnement, elle limite le partage de ressources matérielles, tels que les écrans et le GPU, qui sont nécessaires à une intégration plus poussée. En e et, toute ressource parta-gée sur de telles architectures est allouée en exclusivité à un des calculateurs, le partage étant e ectué par le réseau, ce qui pose des problèmes de latence et de débit.

Solutions : virtualisation sur des systèmes multi-cœurs

Les architectures matérielles actuelles utilisées par les systèmes mécatroniques ne su sent plus à atteindre le niveau de performances nécessaires à la réalisation des fonctionnalités qui se-ront implantées dans les prochains véhicules. L’utilisation d’architectures matérielles de type COTS, actuellement utilisées dans le calculateur le plus puissant du véhicule : le calculateur multimédia, permet de répondre à cette problématique tout en gardant un coût maîtrisé. Les futures architectures embarquées COTS de type « many core » qui regroupent jusqu’à 256 cœurs [92] apparaissent comme des alternatives crédibles pour remplacer ou suppléer les fu-tures architectures matérielles du monde automobile.
La virtualisation apparaît être une solution viable pour répondre à certain des problèmes rencontrés au sein de l’architecture logicielle, matérielle et opérationnelle actuellement utilisée.
Il s’agit de faire cohabiter, sur un même calculateur, des applications et des systèmes d’exploi-tation encapsulé au sein de machines virtuelles en utilisant une couche logicielle nommée hyperviseur ou moniteur de machine virtuelle qui gère l’accès au matériel. Chaque appli- catif ainsi hébergé dans une machine virtuelle, dispose de son propre ensemble de ressources dédiées et est isolé des autres applications.
Du point de vue de l’architecture matérielle, la virtualisation o re les avantages d’une ar-chitecture intégrée poussée à l’extrême. En regroupant les fonctionnalités sur un même calcu-lateur, elle permet de diminuer la congestion du réseau, les messages inter-machines virtuelles étant échangés en utilisant des techniques de mémoire partagées, de diminuer la consommation électrique et la dissipation thermique. L’utilisation d’hyperviseurs sur des architectures maté-rielle de type « many core » à de nombreux avantages. Tout d’abord, la virtualisation facilite le déploiement de systèmes d’exploitation patrimoniaux, incapable d’exploiter un grand nombre de cœurs, en partitionnant le processeur en de multiples sous domaines chacun d’entre eux contenant un nombre réduit de cœurs. L’hyperviseur peut également être utilisé pour ajouter dynamiquement des cœurs à un sous domaine qui a besoin de puissance de calcul supplémen-taire ou peut gérer la consommation énergétique en supprimant des processeurs de certains domaines et en éteignant des cœurs IDLE.
La virtualisation dispose de nombreux avantages en termes d’intégration logicielle. Elle fa-vorise la cohabitation, sur une même plate-forme, d’applicatifs issus du monde de la mécatro-nique basés sur le standard AUTOSAR, d’applicatifs issus du monde du multimédia, basé sur le standard GENIVI, et d’applicatifs développés en utilisant de nouveaux standards. Elle permet, de ce fait, de pro ter des forces et des faiblesses de chacun des écosystèmes et facilite la réutili-sation du code et l’intégration logicielle entre les standards existants. La virtualisation permet également d’exécuter plusieurs instances d’un même système d’exploitation, répondant ainsi à la problématique de personnalisation du système d’info divertissement ou chaque passager du véhicule accède à son propre système multimédia, et ce, à moindre coût. Il n’est plus en e et nécessaire d’avoir une carte par utilisateur connecté. Les systèmes actuels embarqués étant de plus en plus connectés au monde extérieur, la probabilité qu’une application ou qu’un système d’exploitation soit attaqué et compromis augmente dramatiquement. En instaurant une sépa-ration entre les services pouvant être accédés à distance et les autres systèmes, en utilisant des machines virtuelles de ltrage, l’architecture virtualisée peut être utilisée pour limiter les conséquences d’une attaque réussie sur le système.
En terme d’architecture opérationnelle le regroupement de multiples systèmes d’exploita-tion et d’applications sur une même carte facilite le partage de ressources matérielles telle que le GPU, les écrans, la connectique.

Interruptions

Les interruptions et les exceptions sont des événements issus de causes externes (Interrup-tion horloges, …) ou internes (Exécution d’une instruction privilégiée en mode utilisateur, …) au programme qui provoquent un déroutement du l d’exécution vers un autre programme nommé service d’interruption.
Dans une architecture non virtualisée, les systèmes d’exploitation enregistrent leur propre gestionnaire d’interruptions auprès du matériel. Dans une architecture virtualisée l’hypervi-seur enregistre son propre gestionnaire d’interruptions et redirige les interruptions vers les gestionnaires d’interruptions des systèmes invités, lorsque ceux-ci sont ordonnancés et que les interruptions ne sont pas masquées.
Pour diminuer le surcoût, en termes de performances, provoqués par l’indirection supplé-mentaire, la paravirtualisation autorise l’OS invité à enregistrer certains gestionnaires d’inter-ruptions directement auprès du matériel, l’hyperviseur assurant une véri cation de la routine d’interruptions pour véri er que le système invité ne tente pas d’usurper des privilèges.
La virtualisation par le matériel permet d’obtenir les mêmes performances que celles obte-nues avec un système paravirtualisé tout en diminuant la complexité d’implémentation dans le moniteur de machines virtuelles.

Périphériques

Outre le CPU et la mémoire, les périphériques matériels (Cartes réseaux, GPU, écrans, …) doivent également être virtualisés. Les contraintes de performances et les modes de fonction-nement qui dépendent du type de composants virtualisés, couplés à l’hétérogénéité du matériel utilisé résulte en une importe complexité de mise en œuvre.
L’émulation peut être utilisée a n de partager les périphériques entre les di érents systèmes invités. L’hyperviseur présente, à chaque machine virtuelle, un ensemble de périphériques vir-tuels qui émulent des périphériques matériels largement utilisés. Les requêtes e ectuées par les machines virtuelles sont multiplexées et transmises aux périphériques matériels qui sont gérés par l’hyperviseur. Cette technologie appliquée en l’état aux composants complexes que sont les GPU résulte en de faibles performances.
La paravirtualisation repose sur la fourniture, aux systèmes d’exploitation invités, de pi-lotes modi és qui e ectuent des appels vers l’hyperviseur ce qui permet d’obtenir des gains de performances tout en réduisant la complexité de l’émulation. L’api VirtIO [111] a été portée au sein du noyau Linux pour faciliter l’interfaçage entre les hyperviseurs et les systèmes vir-tualisés. Néanmoins, la mise en œuvre d’une telle stratégie sur des composants matériels tels que le GPU, dont les pilotes mettent en œuvre une importante pile logicielle (librairie Open GL), est complexe.
La méthode dite du pass-through permet de garantir de bonnes performances d’accès, au détriment du partage de ladite ressource, en dédiant en exclusivité une ressource à une machine virtuelle. L’hyperviseur va alors allouer les ressources matérielles du périphérique directement au système d’exploitation invité ce qui nécessite, notamment, la présence de matériel spéci-que, tel qu’une IO-MMU, pour continuer à assurer l’isolation spatiale.
Des supports matériels ont donc été ajoutés pour augmenter les performances aussi bien dans le domaine des réseaux [34] que des processeurs graphiques [130, 132]. Le but de ces tech-nologies est de réduire voir d’éliminer totalement les appels au moniteur de machines virtuelles en les remplaçant par des appels au matériel, garantissant ainsi de bonnes performances sans modi cations logicielles dans les systèmes invités. Ces supports matériels ne sont pas actuelle-ment disponibles dans la carte que nous avons utilisée pour e ectuer nos travaux en avance de phase. Cependant, les feuilles de routes des fondeurs laissent à penser qu’elles seront ajoutées dans les futures architectures proposées pour le multimédia.

Virtualisation des systèmes embarqués

La technologie de virtualisation a initialement été industrialisée dans le monde des centres de données. Récemment, elle s’est di usée au domaine de l’informatique embarquée dont les contraintes et les exigences sont fondamentalement di érentes de celles couramment mises en œuvre dans les hyperviseurs de l’informatique des serveurs et des applicatifs.
Le cahier des charges des hyperviseurs embarqués contient des exigences [112] en termes d’embarquabilité et d’empreinte mémoire qui doit rester su samment petite a n que le code de l’hyperviseur tienne dans la mémoire des systèmes embarqués. L’impact de l’hyperviseur, tant sur les ressources matérielles de la plate-forme que sur les performances temps réel, doit également être minimisé. Le moniteur de machines virtuelles doit en plus être capable de vir-tualiser des systèmes d’exploitation temps réel en fournissant une forte isolation spatiale et temporelle. En n, les architectures couramment utilisées dans les domaines embarqués (ARM, PowerPC) doivent être supportées.
Nous pouvons observer que les fournisseurs d’hyperviseurs pour le domaine de l’embarqué [32, 63, 104, 140] utilisent massivement des hyperviseurs de type 1. Ces hyperviseurs s’exé-cutent directement sur le matériel de la machine hôte ce qui entraîne une réduction du volume de code déployé sur l’hyperviseur. Cette réduction s’accompagne de gains en terme d’embar-quabilité, l’empreinte mémoire de l’hyperviseur au sein du matériel étant réduite, ce qui permet la mise en œuvre de techniques de véri cation formelle [98] et de certi cations [63, 104] et une réduction de la Trusted computing base [123] importante pour la mise en pratique de politiques de sécurité. En outre, le concept d’hyperviseur de type 1 partage des notions communes avec les micro-noyaux [60, 123]. Les fournisseurs d’hyperviseurs [63, 98, 104] peuvent donc réutiliser une partie des concepts qu’ils ont déjà développés dans leurs produits préexistants.
Les acteurs du monde de l’embarqué ont eu tendance, dans les premières solutions de vir-tualisation, à recourir aux techniques de paravirtualisation au lieu des techniques d’émulation pour assurer de bonnes performances tout en garantissant une simplicité d’implémentation [60]. L’arrivée de la virtualisation matérielle dans les processeurs embarqués permet mainte-nant d’augmenter les performances des hyperviseurs existants [140] mais aussi d’envisager la virtualisation de systèmes non modi és.

Multi-cœurs

L’accroissement des besoins en ressources CPUs provoqué par l’augmentation des presta-tions clients a contribué à l’émergence des architectures multi-cœurs dans le monde automobile aussi bien dans la partie mécatronique que dans la partie de l’info-divertissement. Si les archi-tectures matérielles [120] du monde de la mécatronique se caractérisent par une plus forte prise en compte des caractéristiques temps réel, leurs performances sont insu santes pour exécuter des systèmes d’exploitation d’info-divertissement. La virtualisation de tels systèmes d’exploi-tation nécessite donc d’utiliser des architectures matérielles de type COTS déjà employées par le domaine du multimédia.

Modèle de programmation multi-cœurs sur architectures virtualisées

Deux modèles de programmation peuvent être utilisés pour exploiter les calculateurs multi-cœurs [41].
Dans le modèle de programmation Asymmetric Multi Processing (Figure 2.4a) chaque cœur ordonnance une instance distincte d’un système d’exploitation, chaque système s’exé-cutant de la même manière que si il était exécuté sur un seul CPU mono-cœur. Les systèmes d’exploitation peuvent communiquer entre eux de manière faiblement couplée, par exemple en utilisant des techniques de mémoires partagées. Avec le modèle de programmation Sym-metric Multi Processing (Figure 2.4b), tous les cœurs sont contrôlés par un unique système d’exploitation qui les répartit entre les ls d’exécutions de l’application qui s’exécute. Les cœurs interagissent de manière fortement couplée en utilisant des verrous pour se synchroniser (Co-hérence des caches). Les avantages du modèle de programmation AMP résident dans la possibilité de réutiliser des systèmes d’exploitation patrimoniaux mono-cœurs et d’exécuter des applications qui, par nature, ne sont pas parallélisables. En outre, l’exécution en parallèle de deux systèmes d’ex-ploitation permet d’assurer une bonne réactivité. Le modèle de programmation SMP permet d’amener les béné ces de la programmation multi-cœurs au niveau des applicatifs et autorise également une connaissance plus ne des ressources matérielles qui sont accédées concur-remment. En outre, le modèle de programmation SMP ne nécessite pas la mise en œuvre de mécanismes de synchronisation inter-partitions, des mécanismes de synchronisation devant néanmoins être déployés par le système d’exploitation au niveau applicatif.

Multi-cœurs et contraintes temps réel

Nous allons maintenant étudier l’incidence des architectures multi-cœurs sur les contraintes temps réel. Dans une première partie, nous dé nirons le concept de « composabilité », utilisé pour garantir le respect des contraintes temps réel dans les architectures opérationnelles fédé-rées et intégrées, pour ensuite illustrer la remise en cause de ce principe dans les architectures multi-cœurs.

Prédictibilité et « composabilité »

La prédictibilité est une des contraintes majeures des systèmes temps réel qui doivent garan-tir, en toute circonstance, le respect des échéances temporelles des di érentes tâches exécutées. La technique de calcul de pire temps d’exécution est utilisée pour e ectuer des analyses d’or-donnançabilité a n de démontrer le respect des échéances des tâches ordonnancées au sein d’un système temps réel.
La mise en œuvre de telles techniques devient particulièrement complexe lorsque des dé-pendances logicielles (Synchronisation inter-tâches …) ou matérielles (Accès concurrent à une même ressource partagée …) existent entre les di érentes tâches ordonnancées. Le calcul du WCET d’une tâche dépend alors des temps d’exécution des autres tâches exécutées.
Des solutions de partitionnement ont été proposées pour résoudre ce problème. Il s’agit de découper le système à véri er en de multiples sous-parties, indépendantes les unes des autres, qui peuvent être analysées plus facilement que si une analyse était réalisée sur l’ensemble du système. Le principe de « composabilité » formalise un tel comportent : un système est dit composable si le comportement temporel et fonctionnel d’une application est le même, indépendamment du fait qu’il y ait ou non d’autres applications exécutées sur le système.
Ce principe, qui suppose l’élimination totale des interférences entre applications, est par-tiellement respecté, par construction, dans les architectures opérationnelles fédérées, chaque prestation client disposant de son propre calculateur, la seule ressource partagée entre les fonc-tionnalités étant le réseau. L’architecture intégrée AUTOSAR [144] se réclame également du principe de « composabilité » où des composants logiciels issus de multiples fournisseurs sont testés et validés séparément puis intégrés au sein d’un même calculateur. Des politiques d’allo-cation des ressources matérielles par ordonnancement sont donc mises en œuvre pour assigner lesdites ressources aux composants logiciels.
Les architectures virtualisées embarquées qui mettent en œuvre des systèmes d’exploitation temps réel doivent donc assurer le principe de « composabilité » au moins pour les systèmes d’exploitation temps réels virtualisés. En e et, il paraît inconcevable que les systèmes d’ex- ploitation d’info-divertissement puissent temporellement perturber les applications exécutées dans le système temps réel.

Interférences

La mise en œuvre du principe de « composabilité » dépend de la capacité des architectures matérielles à fournir un système prédictible. Les architectures multi-cœurs modernes apportent des sources d’imprédictibilités additionnelles par rapport à celles des architectures mono-cœurs classiques (Section 1.1.1.3). En e et, si l’on peut dédier des unités de calculs aux di érentes applications exécutées en parallèle, il reste à traiter le problème des accès concurrents aux ressources partagées (pour des raisons de coûts, d’énergie, de taille, de communications inter-cœurs). Ainsi, chaque accès e ectué par un cœur à une ressource partagée est potentiellement mis en concurrence avec celles e ectuées par les autres cœurs. L’arbitrage est alors fait de manière implicite par le matériel, ce qui entraîne une augmentation non déterministe des temps d’exécution des applications [30]. Kotaba et al [74] ont e ectué un inventaire, que nous avons repris dans le tableau 2.1, des ressources matérielles, spéci ques aux architectures multi-cœurs modernes de type COTS, qui ajoutent des sources d’interférences temporelles additionnelles par rapport aux architectures mono-cœur.
Le problème des accès concurrents à des ressources partagées devient particulièrement cri-tique lorsque l’on aborde la ressource mémoire. En e et, la latence et la bande passante est un des facteurs majeurs qui limite la performance des processeurs. Les fondeurs ont donc mis en place une hiérarchie de mémoires, partagée entre tous les processeurs, pour essayer d’outrepas-ser ces limitations. Si les techniques de virtualisation de la mémoire (Section 2.1.2.2) permettent d’assurer l’isolation spatiale, la plupart des architectures matérielles de type COTS ne four-nissent pas de mécanismes permettant d’assurer l’isolation temporelle nécessaire au respect du principe de « composabilité ».
Par exemple, dans la gure 2.5, où un système d’exploitation multimédia est ordonnancé en parallèle d’un système d’exploitation temps réel, les temps d’exécution du système temps réel, dépendent des accès mémoire e ectués par les applications ordonnancées sur ledit sys-tème, mais aussi des accès mémoires e ectués par le système multimédia. Notons que la pro-blématique de contention au niveau du système mémoire s’applique également au modèle de programmation SMP. Le système d’exploitation temps réel multi-cœurs doit assurer le respect du principe de « composabilité » entre les ls d’exécutions ordonnancées sur plusieurs cœurs.

Hiérarchie mémoire

La mémoire primaire, nommée aussi mémoire principale, est un dispositif électronique de stockage de données directement accessible par les composants électroniques consomma-teurs de mémoire (CPU, périphériques) qui vont générer des requêtes d’accès en lecture ou en écriture pour recevoir ou sauvegarder des données.
Introduite dans les années 1970, la Random-access memory s’est imposée pour devenir le standard industriel. Elle peut être représentée sous la forme d’un ensemble de cellules mémoires connectées entre elles où chaque cellule contient un bit de données. Actuellement, les deux technologies les plus utilisées pour fabriquer les cellules mémoires sont la SRAM (Static random access memory) et la DRAM (Dynamic random access memory).
Une cellule de SRAM sauvegarde un bit de données dans deux inverseurs montés tête-bêche, chaque inverseur étant composé de deux transistors le tout étant couplé à deux transistors d’accès aux données.
Une cellule de DRAM, elle, sauvegarde un bit de données dans un condensateur qui, se-lon son état déchargé ou chargé, indique une valeur de stockage de 0 ou de 1. Un transistor supplémentaire permet l’accès à la valeur stockée dans le condensateur. Au cours du temps et selon les opérations e ectuées, le condensateur se décharge et perd la valeur sauvegardée. Un rafraîchissement périodique des cellules de la DRAM est donc nécessaire.
L’utilisation d’un condensateur désavantage la DRAM par rapport à la SRAM du point de vue des temps d’accès aux données, du fait du coût des opérations de rafraîchissement, mais l’avantage d’un point de vue coûts de fabrication et densité, le nombre de transistors dans une cellule de DRAM est supérieur à celui présent dans une cellule de SRAM.

Caractéristiques des mémoires

La mémoire peut être caractérisée en utilisant di érentes propriétés. La latence est utili-sée pour dé nir le temps d’accès à une donnée, la bande passante caractérise le volume de données accédées dans une période de temps et la taille mémoire détermine la quantité de données pouvant être stockées pour un coût donné. Une mémoire idéale aurait une latence et un coût nul, une capacité et une bande passante in nie. Or, les exigences qui caractérisent la mémoire idéale sont antagonistes les unes aux autres. Pour une technologie mémoire donnée, l’accroissement de la taille entraîne une augmentation du temps de décodage de l’adresse, a n de déterminer la localisation de la donnée accédée, ce qui augmente la latence. Pour une ca-pacité de mémoire donnée, la latence est déterminée par le type de technologie utilisé (SRAM, DRAM), plus elle est coûteuse plus la latence est faible. Les gains en bande passante se font par une augmentation de la fréquence mémoire, une augmentation du nombre et de la taille des bus de données ou l’utilisation de nouvelles technologies, le tout se traduisant par une augmentation des coûts.
Pour se rapprocher des caractéristiques des mémoires idéales, les concepteurs des matériels font appel à une hiérarchie mémoire (Figure 2.6) qui combine plusieurs niveaux de stockage, progressivement plus gros et lents au fur et à mesure que l’on s’éloigne du processeur. En s’assurant que la plupart des données requises par le processeur sont présents dans les niveaux de cache les plus rapides, les concepteurs réussissent à obtenir des temps d’accès et des débits moyens s’approchant de ceux de la mémoire la plus rapide tout en conservant les capacités mémoires de la mémoire la plus lente.

Politique d’allocation

La politique d’allocation des données vise à déterminer si une donnée chargée depuis le niveau de cache supérieur doit être copiée dans le cache (line ll) ou non. La politique read-allocate e ectue un line ll uniquement lorsqu’un MISS en lecture est e ectué. Lorsqu’un MISS en écriture survient, le cache n’est pas modi é et l’écriture est transmise au niveau supérieur.
La politique d’allocation write-allocate alloue une ligne de cache sur MISS en lecture ou en écriture. Cette politique est habituellement utilisée en combinaison avec la politique write-back.

Caches et multi-cœurs

La présence de caches partagés dans les architectures multi-cœurs modernes entraîne trois e ets indésirables majeurs :
— Contention temporelle : Le nombre d’accès mémoire pouvant être servis en parallèle par un cache partagé est limité et ne correspond pas forcément au nombre total de re-quêtes pouvant être émis par l’ensemble des cœurs. Lorsque ce nombre dépasse la capacité du cache à paralléliser les accès, les requêtes mémoire sont traitées séquentiellement, ce quentraîne une augmentation des latences d’accès. On parle alors de contention temporelle sur les caches.
— Contention spatiale : Ensuite, la taille du cache partagé e ectivement disponible pour une application dépend, à la fois, de la politique de remplacement des données du cache et des écritures e ectuées par les autres applications. En e et, ces dernières peuvent évincer hors du cache les données stockées par la première application, on parle alors de contention spatiale. Des interférences inter-cœurs : se produisent lorsque deux tâches exécutées sur des cœurs di érents accèdent à un même cache commun et que les accès d’une des tâches évincent les blocs mémoire de l’autre tâche augmentant ainsi son temps d’exécution. La présence d’interférences inter-cœurs entraîne une augmenta-tion considérable des pires temps d’exécution se traduisant par un surdimensionnement inacceptable des plates-formes matérielles.
— Coût du protocole de cohérence : En n, les protocoles de gestion de la cohérence des données mis en œuvre, lorsque deux consommateurs accèdent à une zone mémoire partagée, introduisent des ralentissements additionnels aussi bien sur les caches partagés que sur les caches privés des cœurs, des données du cache devant être validées et mises à jour.
La conséquence globale de ces trois e ets est une augmentation importante du pire temps d’exécution des applications exécutées sur une telle plate-forme, ces derniers dépendant du comportent des applications co-ordonnancées.
Si l’utilisation des caches, dans un contexte multi-cœurs, pose des problèmes de contention spatiale et temporelle entre les tâches exécutées en parallèle, la présence de mémoire principale de type DRAM amène des complications supplémentaires. En e et, les architectures multi-cœurs modernes ont une structure mémoire principale complexe et non uniforme.
Nous allons voir plus en détail, dans la section suivante, l’agencement de la mémoire prin-cipale de type DRAM et les impacts de cette organisation sur la « composabilité » de notre plate-forme matérielle.

Mémoire principale

La mémoire de stockage peut être modélisée sous la forme d’un ensemble de cellules connec-tées au contrôleur mémoire. Dans une implémentation 1 à N de ce modèle, l’ensemble des cellules sont connectées au contrôleur par un unique bus partagé alors que dans une implé-mentation N à N, chaque cellule est connectée au contrôleur mémoire par un bus dédié.
La première implémentation est peu coûteuse, un seul bus étant nécessaire, mais résulte en de faibles performances. Les accès à un grand tableau monolithique de cellules sont lents. Il existe une forte latence entre le moment où la requête arrive au tableau de donnée et le moment où le transfert des données commence. De plus les accès mémoires ne peuvent être parallélisés.
La deuxième implémentation diminue la latence d’accès aux données et permet de paralléli-ser les accès aux cellules pour traiter plusieurs requêtes d’accès mémoire en même temps mais est techniquement impossible et économiquement non viable, le grand nombre de bus requis entraînant une explosion des coûts et des impossibilités de placement-routage.
L’architecture de la DRAM est donc un compromis entre les deux implémentations pour garantir de bonnes performances tout en assurant des coûts maîtrisés.

Organisation de la DRAM

Le système mémoire principal se compose d’un ou de plusieurs contrôleurs mémoires, qui transmettent les requêtes issues des demandeurs (CPU, DMA, caches), vers des barrettes mé-moires (Dual Inline Memory Module) qui stockent les données.
Un canal de communication (channel) connecte de manière exclusive un contrôleur à une ou plusieurs barrettes (Figure 2.9a). Chaque contrôleur peut gérer un ou plusieurs canaux, dont les accès, totalement indépendants, peuvent être e ectués en parallèle. Un canal est composé de trois bus, le bus de commande (Unidirectionnel), le bus d’adresse (Unidirectionnel) et le bus de données (Bidirectionnel). Le contrôleur reçoit des requêtes mémoires (Lecture/Écriture de bloc de données) des demandeurs et les décompose en plusieurs commandes mémoires.
Les commandes sont transférées aux barrettes en utilisant le bus de commande tandis que le bus d’adresse est utilisé pour transférer les adresses des données accédées par la commande, le bus de donnée étant utilisé pour transférer les données résultant des commandes.
Les barrettes sont découpées en sous-ensembles nommés rank (Figure 2.9a) qui sont tous connectés au même canal. Les accès parallèles aux ranks ne sont pas autorisés, le contrôleur mémoire sélectionne donc le rank vers lequel il souhaite envoyer une commande. Un rank est composé de plusieurs puces mémoire (Figure 2.9b) qui partagent le même bus de commande et d’adresse mais disposent d’un sous ensemble réservé du bus de données. Une commande émise par le contrôleur mémoire à un rank est donc reçue et traitée par l’ensemble des puces dudit rank qui transfèrent simultanément les données requises. Une puce est composée de plusieurs bancs mémoire (Figure 2.9c) qui contiennent les données. L’ensemble des bancs mémoire d’une puce partagent le même bus de données ce qui interdit tout parallélisme de transfert entre bancs mémoire co-localisés sur une même puce. Un banc peut être représenté sous la forme d’un tableau de cellules mémoire à deux dimensions organisé en ligne et en colonne (Figure 2.9d). Une ligne de cellules supplémentaire nommée row-bu er est présente dans chaque banc. Tout accès e ectué à une cellule de données d’un banc mémoire passe nécessairement par le chargement de la ligne contenant ladite donnée dans le row-bu er. Le row-bu er peut donc être vu comme un cache write-back d’un banc mémoire, les accès e ectués à une ligne déjà présente dans le cache (row-open) se traduisant par un row-hit sont accélérés par rapport à des accès qui nécessitent de recharger une ligne fermée (row-close) et qui se traduisent par un row-miss.

Mémoire principale et multi-cœurs

L’utilisation de mémoire principale de type DRAM engendre des interférences temporelles entre les multiples cœurs de la plate-forme matérielle.
Tout d’abord la capacité du contrôleur mémoire à servir en parallèle plusieurs accès vers le système, mémoire est limitée et dépend, notamment, du nombre de canaux mémoires présents au sein du matériel. Lorsque de multiples requêtes mémoire se présentent, le contrôleur met en œuvre une politique d’arbitrage pour sélectionner les accès qui vont être prioritairement e ectués. De la politique d’arbitrage utilisée par le contrôleur mémoire dépend la prédictibilité de la plate-forme. Si l’utilisation d’une politique à temps partagé permet de borner les latences mémoire, les contrôleurs de type COTS ont tendance à utiliser des politiques visant à maximiser le débit au détriment de la prédictibilité.
La politique de placement des données utilisée par le contrôleur joue également un grand rôle. Si les politiques d’entrelacements permettent d’exploiter au maximum la bande passante mémoire elles introduisent des dépendances cachées entre les multiples consommateurs qui voient leurs données co-localisées (Cas pathologiques de banks-con icts et de row-con icts).
En n, l’utilisation d’une politique de gestion des row-bu ers de type open-row garantit de meilleures performances au détriment des pire temps d’exécutions qui peuvent se produire.

Table des matières

Contexte industriel automobile 
1.1 Systèmes du monde automobile
1.1.1 Architecture Électrique/Électronique
1.1.2 Architecture des systèmes de divertissement du consommateur
1.2 Tendances, limitations et solutions
1.2.1 Tendances
1.2.2 Limitations
1.2.3 Solutions : virtualisation sur des systèmes multi-coeurs
1.3 Conclusion
2 Introduction au problème de contention mémoire 
2.1 Virtualisation
2.1.1 Dénitions et concepts
2.1.2 Virtualisation des composants
2.1.3 Virtualisation des systèmes embarqués
2.2 Multi-coeurs
2.2.1 Modèle de programmation multi-coeurs sur architectures virtualisées
2.2.2 Multi-coeurs et contraintes temps réel
2.3 Hiérarchie mémoire
2.3.1 Caractéristiques des mémoires
2.3.2 Caches
2.3.3 Mémoire principale
3 Etat de l’art 
3.1 Approche par composants matériels
3.1.1 Classication des solutions
3.1.2 Caches processeurs
3.1.3 Contrôleur mémoire
3.1.4 Mémoire principale
3.1.5 Bus matériels
3.1.6 Conclusion
3.2 Approches globales
3.2.1 Contrôle des accès mémoire
3.2.2 Régulation des accès mémoire
3.3 Conclusion
4 Mise en évidence expérimentale du problème 
4.1 Plate-forme matérielle
4.1.1 Processeur
4.1.2 Hiérarchie mémoire de niveau 1
4.1.3 Cache L2
4.1.4 Contrôleur mémoire
4.1.5 Récapitulatif
4.2 Stratégie de partage des ressources matérielles
4.2.1 Partage des ressources CPU
4.2.2 Partage des périphériques
4.2.3 Partage de la hiérarchie mémoire
4.3 Méthode d’évaluation
4.3.1 Conguration du matériel
4.3.2 Linux
4.3.3 Benchmark : MiBench
4.3.4 Charges
4.4 Évaluation
4.4.1 Coût du partage du cache L2
4.4.2 Impact de la contention mémoire sur les temps d’exécutions
4.5 Conclusion
5 Une nouvelle approche de contrôle de la mémoire 
5.1 Approche
5.1.1 Étape hors ligne : caractérisation de la plate-forme
5.1.2 Étape en ligne : contrôle
5.2 Caractérisation de la plate-forme logicielle et matérielle
5.2.1 Phases applicatives
5.2.2 Génération de charges mémoires constantes paramétrables
5.2.3 Collecte des données
5.2.4 Traitement des données et génération des tables
5.3 Contrôle à l’exécution
5.3.1 Algorithme
5.3.2 Mesure de la consommation mémoire
5.3.3 Surveillance par échantillonnage
5.3.4 Tables embarquées
5.3.5 Suspension des applications
5.4 Evaluation
5.4.1 Surcoût à l’exécution
5.4.2 Ecacité pour des charges constantes
5.5 Conclusion
6 Analyse des causes de la sensibilité mémoire des applications temps réel 
6.1 Prolage des applications
6.1.1 Proleur mémoire
6.1.2 Classication
6.1.3 Méthodologie d’investigation des pics de bande passante mémoire
6.2 Impacts des entrée/sortie
6.2.1 Analyse du problème
6.2.2 Conclusion & solutions
6.3 Impacts du système d’exploitation
6.3.1 Analyse du problème
6.3.2 Conclusion & solutions
6.4 Impacts des algorithmes applicatifs
6.4.1 Analyse du problème
6.4.2 Conclusion & solutions
6.5 Conclusion
Bibliographie 

Télécharger le rapport complet