Architecture des systèmes hétérogènes embarqués et mobiles

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

Les processeurs basés sur l’architecture ARM

Les SoC ARM utilisent des processeurs basés sur l’architecture du même nom. Ces processeurs ont un jeu d’instructions réduit (Reduced Instruction Set Computers, RISC). Dans cette architecture, les CPU sont conçus pour exécuter un nombre réduit d’instruction de base avec pour objectif – dans la majorité des cas – d’exécuter une instruction par un cycle d’horloge. Ceci est obtenu en fixant la longueur des champs d’instructions afin de simplifier le décodage de ces dernières. En outre, ces processeurs ont un mode d’adressage simplifié avec l’architecture chargement/stockage (load/store architecture), où toutes les opérations sur les données sont exécutées uniquement sur des registres.
En plus de l’architecture RISC de base, les processeurs ARM sont aussi dotés de fonctionnalités permettant de contrôler les unités arithmétiques et logiques (UAL), le chargement et le stockage de plusieurs instructions, ainsi que l’exécution d’une instruction sur plusieurs données (Single instruction Multiple Data, SIMD). Ces améliorations apportées à l’architecture RISC de base permettent aux processeurs ARM un meilleur équilibre entre les performances, la consommation d’énergie, et la taille de la puce. Grâce à cet équilibre, les SoC à base de processeurs ARM dominent le marché des systèmes embarqués, notamment dans le secteur des systèmes mobiles, et l’Internet des Objets (Internet of Things, IoT).
Les processeurs ARM sont divisés en trois familles : Les Cortex-A, Cortex-M, et Cortex-R.
Les Cortex-A sont des processeurs d’application, généralement destinés au grand public. Ils sont conçus pour offrir des performances élevées avec une consommation d’énergie relativement faible. Comme leur nom l’indique, ces processeurs sont destinés à être utilisés en application (Smartphones, 10 État de l’Art de la Modélisation des Processeurs Embarqués et Mobiles Hétérogènes Tablettes, appareils photos, etc.). Par conséquent, les systèmes utilisant ces processeurs fonctionnent généralement sous un système d’exploitation, et sont aussi dotés d’une unité de gestion de la mémoire (MMU).
La seconde famille des processeurs ARM est celle des microcontrôleurs Cortex-M. Ces processeurs sont utilisés dans des systèmes fortement embarqués, qui nécessitent des traitements en temps réel et une consommation minime d’énergie comme les capteurs, les transmetteurs et les appareils utilisés dans l’IoT.
La dernière famille regroupe les Cortex-R. Ces processeurs sont dits déterministes en raison de leur latence d’interruption faible. Cette propriété rend ces processeurs les plus adaptés aux systèmes à temps réel et critiques. Ils sont généralement utilisés dans les systèmes de contrôle et commandes avioniques, les automates programmables industriels, et les appareils médicaux.

Les processeurs graphiques embarqués et mobiles

Un GPU, par définition, est un processeur spécialisé pour le rendu graphique. Il est utilisé pour l’accélération des opérations visuelles [26]. Les GPU existent en plusieurs familles suivant leur implémentation et leur puissance de calcul, allant des processeurs graphiques de base utilisés pour les tâches d’affichage de l’interface utilisateur, le décodage des vidéos, et les simples rendu 3D, jusqu’aux processeurs dédiés aux jeux vidéo et aux stations de travail, capables de rendre des synthèses plus complexes en 3D [23, 27].
Contrairement aux CPU conçus pour avoir la plus petite latence possible et optimisés pour le branchement et les boucles (Figure I.3a), les GPU ont été et sont toujours conçus pour le traitement des graphismes, et leur architecture est optimisée à cette fin. Par conséquent, ils sont adaptés à l’exécution d’une seule instruction sur plusieurs données (SIMD), et une seule instruction sur plusieurs fils d’exécution : (Single Instruction, Multiple Threads, SIMT). Ainsi, les GPU sont plutôt conçus pour avoir throughput maximum [23].
Le throughput est défini comme la quantité totale de travail exécutée sur un temps donné [27]. Ainsi, un processeur conçu pour délivrer un grand throughput, comme les GPU, doit être capable d’exécuter plusieurs travaux en parallèle [24]. Pour ce faire, les GPU sont dotés d’un grand nombre d’unités de calcul (Appelées : CU, ou CUDA Core, ou cœur), en comparaison avec le nombre de cœurs dans les CPU. Toutefois, le grand throughput et la parallélisation des calculs, réduisent la nécessité d’une faible latence puisque la quantité de travail est ce qui prévaut. Ainsi, la plupart des GPU fonctionnent à des fréquences d’horloge modestes comparées à celles des CPU.
La Figure I.3b explique la parallélisation des calculs et l’ordonnancement des travaux dans un GPU. Quand des travaux sont initialisés sur un GPU, ils sont organisés de sorte que ce dernier commence le premier travail et que durant le temps d’attente des données, il commence le second, et ainsi de suite jusqu’à la fin de tous les travaux. Une fois ceci fait, il reprend le premier travail dont les données sont disponibles et poursuit la tâche, et ainsi de suite. Cet ordonnancement, s’il est bien calculé, permet d’éliminer l’effet de la grande latence, parce que le processeur sera toujours occupé avec des calculs.

Architecture des systèmes hétérogènes embarqués et mobiles 

Les performances des GPU augmentent pour chaque nouvelle architecture, en particulier celles conçues par les plus grands constructeurs tels que NVIDIA et AMD. Cette course à la performance est surtout motivée par le rôle que jouent les GPU dans l’industrie du divertissement (Jeux vidéo, conceptualisation 3D, édition et rendu des vidéos). Néanmoins, La caractérisation les GPU uniquement par leurs tâches graphiques est limitante et dépassée. En effet, les tâches des GPU dépassent désormais le monde des graphismes et les rendus vidéos, et ils sont utilisés pour les calculs scientifiques, les simulations, et dans le domaine de l’Intelligence Artificielle (IA) grâce au nombre élevé des cœurs dont ils disposent [23, 27, 28].
Il n’existe pas de classification standard pour les GPU. Toutefois, nous parlons généralement de GPU intégrés et de GPU discrets (ou dédiés). Les GPU intégrés sont des GPU disposés sur le même SoC que le CPU et ils partagent généralement la même RAM. Par contre, les GPU discrets sont le plus souvent disposés sur leur propre circuit (dit carte graphique) et ont une mémoire séparée du reste du système.
Dans les systèmes embarqués, la quasi-majorité des GPU sont intégrés. Ces derniers sont conçu pour les tâches générales d’affichage et de rendus 2D et 3D, ainsi que la lecture vidéo. Ils dominent le marché du grand public, notamment le secteur mobile (smartphone et tablette) où ils sont pratiquement les seuls à exister. L’un des plus grands avantages de ce genre de GPU est la mémoire partagée, qui permet un interfaçage facile avec les CPU. En outre, avec les outils logiciels comme l’OpenCL, ces GPU deviennent des ressources directement disponibles pour effectuer des tâches générales en plus des tâches graphiques. Ils ont aussi une consommation très faible en puissance comparée à celle des GPU dédiés, et deviennent le choix idéal pour les systèmes utilisant des batterie et les usages qui ne requiert pas une grande puissance graphique.
Les GPU intégrés les plus connus sur les systèmes embarqués – dont les smartphones et les tablettes – sont les GPU intégrés ARM et Qualcomm. ARM propose la famille de GPU Mali avec les processeurs cortex-A allant jusqu’à 16 cores [29, 30]. De son côté, Qualcomm commercialise dans les SoC Snapdragon, les GPU Adreno. Ces GPU sont ceux utilisés dans la plupart des smartphones haut de gamme [31]. En plus de ces deux compagnies, citons également Vivante, PowerVR, et NVIDIA qui propose ses GPU Tegra pour les applications embarquées et intégrées nécessitant des performances plus élevées [32, 33].

La modélisation des systèmes embarqués et mobiles

La littérature est riche de modèles consacrés aux systèmes embarqués et mobiles. Toutefois, à notre connaissance, il n’existe pas de travaux traitant le problème de la surveillance en ligne de l’état de fonctionnement des puces CPU-GPU. Ceci confirme l’originalité de notre proposition et l’intérêt de pallier ce manque. Néanmoins, certains travaux traitent de problématiques assez proches des nôtres. Par exemple, Mercati et al. [34] ont créé des modèles de puissance et de température pour les systèmes fonctionnant sous Linux et Android dans le but d’améliorer leur fiabilité [34, 35]. Ces modèles sont des modèles d’optimisation, et sont utilisés hors ligne [35]. De manière similaire, Li et al. [36] ainsi que Zhou et al. [37] ont créé des modèles pour l’estimation de la puissance et de la température afin d’optimiser les niveaux thermiques des processeurs, mais davantage pour des MPSoC hétérogènes. De plus, Dousti et al. [38] ont présenté un analyseur appelé ThermTap afin d’estimer la consommation d’énergie et la température des appareils mobiles.
La littérature regorge également de travaux traitant au moins de l’un des axes de modélisation présentés dans ce manuscrit. Dans le paragraphe qui suit, nous explorons les principaux travaux de recherches effectuées dans ces domaines, en nous limitant aux travaux effectués sur des SoC embarqués ou mobiles.

La modélisation de la puissance et de l’énergie consommée

Dès l’introduction des smartphones modernes en 2007, les difficultés rencontrées ont été l’esti-mation de l’autonomie [39] et la prédiction de la durée de vie restante de la batterie [40]. Face à ces appareils livrés avec une source d’énergie limitée, des développeurs ont étudié leur autonomie [41, 42] et construit des modèles de consommation de puissance [43].
La problématique majeure concernant ces appareils concerne la dualité performance consommation de puissance. Cela consiste à augmenter les performances des systèmes tout en maintenant une consommation d’énergie minimale. Ainsi, l’amélioration de l’efficacité énergétique est devenue l’ob-jectif majeur des industriels et académiciens [44, 45], ce qui explique les nombreux travaux sur le sujet [46–52]. En effet, les deux secteurs – scientifique et industriel – travaillent activement pour atteindre cet objectif [52–54]. Les solutions proposées sont variées. Les articles [55–58] proposent des solutions algorithmiques telles que l’ajustement dynamique de la tension et de la fréquence des CPU (Dynamic Voltage and Frequency Scaling, DVFS), tandis que [59, 60] s’intéressent au DVFS dans les GPU. D’autres travaux proposent la limitation de puissance consommée [49] ou des algorithmes améliorant l’utilisation des ressources ainsi que la distribution des tâches[61, 62]. Citons de plus Marz et al. [63] qui se penchent sur l’optimisation des Frameworks des applications, et Lu et al. [64] qui se focalisent sur l’amélioration de la consommation électrique des écrans et proposent des solutions techniques tels que la réduction des résolutions des écrans. Enfin, relevons les travaux proposant des études de l’influence des applications et des interactions des utilisateurs avec le système sur la consommation d’énergie [34, 65–68], parfois à l’aide d’approches statistiques à grande échelle [69, 70].
Cette problématique continue d’être étudiée afin d’améliorer la précision des modèles d’estimation, et d’intégrer les nouvelles technologies [41, 71]. En outre, avec l’émergence de l’IoT et l’omniprésence des systèmes embarqués, surtout dans les systèmes critiques, l’intérêt porté à l’étude et la modélisation de ces systèmes ne se limite plus aux systèmes mobiles, mais englobe désormais la plupart des systèmes électroniques embarqués [49, 72–74].
L’étude de la consommation d’énergie des systèmes embarqués a également permis aux chercheurs d’identifier et de résoudre des bugs entraînant une consommation excessive d’énergie [75–77], et de créer des logiciels écoénergétique (optimisés pour avoir une consommation réduite) [78]. En outre, Suarez-Tangil et al. [79] ont utilisé le profil de la puissance consommée pour la détection d’anomalie dans le système, tandis que [80] l’ont employé afin de développer une méthode pour la détection de logiciels malveillants.
Afin d’estimer ou de mesurer la puissance consommée par les systèmes embarqués ou mobiles, les concepteurs sont généralement amenés à construire des profilers. Ces derniers sont des outils permettant la collection cyclique des mesures ou l’estimation des variables désirées (dans ce cas, il s’agit de la puissance). Ils varient en complexité et en fonctions, du simple enregistreur [81] au profilers basés sur des modèles complexes capables d’estimer l’énergie consommée par les instructions [54].
Il existe trois revues principales dans la littérature détaillant les profilers et la modélisation de la puissance dans les smartphones [82, 43, 83]. La première est le travail de Hoque et al. [82], dans lequel, les auteurs présentent les différents mécanismes de mesure de l’énergie (instruments externes, capteurs internes, etc.), les types de modèles (modèles basés sur l’utilisation, les événements et l’analyse du code), les philosophies de modélisation (boîte blanche ou boîte noire) et les approches de profiling. Les auteurs ont de plus proposé une taxonomie des profilers et modèles étudiés en fonction de leur déploiement et le lieu de la construction du modèle, soit en interne sur le système, soit en externe (en de hors du système) [82].
La deuxième revue mentionne essentiellement les mêmes travaux, mais elle les examine dans l’optique de leur mise en œuvre (matérielle ou logicielle) [43], tandis que la troisième porte sur la simulation des réseaux [83].
Parmi les profilers et modèles cités dans ces revues, plusieurs relèvent de notre cadre de travail en fonction du niveau auquel ils peuvent estimer la consommation d’énergie, ainsi que leurs utilisations. Parmi ces profilers, certains sont construits par des fournisseurs de système tels que Android Power Profiler de Google [84, 85], et Trepn Profiler de Qualcomm [86]. Nous ajoutons également des travaux publiés dans la littérature tels que le célèbre PowerBooter [18], Sesame [87], DevScope [88], Eprof [89] et les modèles construits par Banerjee et al. [90] et Shye et al. [91].

Conception et construction des profilers pour les SoC embarqués

Tous les profilers existant dans la littérature ont la tâche commune de fournir des valeurs décrivant une ou plusieurs variables telles que la consommation d’énergie [43] ou la température [9, 38], même lorsqu’ils diffèrent par leur construction ou approche. Certains prennent des mesures [81, 121] tandis que d’autres génèrent des estimations [6, 100]. Toutefois, en étudiant ces profilers, d’autres aspects communs apparaissent. Ces aspects partagés entre les profilers permettent de les classifier en sous-catégories selon les approches et choix de design utilisés.
Dans ce qui suit, en utilisant cette classification, nous détaillerons le processus de construction des profilers en plusieurs étapes où chaque étape correspond à un choix entre plusieurs approches. Nous expliquons les choix de conception à effectuer pour chacune d’elles, en commençant par la définition de l’objectif et de la mise en œuvre du profiler.

Définition de l’objectif du profiler et sa granularité

Les profilers sont conçus pour accomplir une tâche spécifique vis-à-vis d’une ou plusieurs variables. Afin de choisir la meilleure approche et la meilleure structure pour le profiling, la première étape de sa construction consiste donc à définir l’objectif principal que doit atteindre ce profiler. Les profilers d’énergie, par exemple, peuvent être utilisés pour mesurer l’énergie consommée par le système [94, 122], ou par un composant spécifique [123, 124], ainsi que pour surveiller ce système et détecter des anomalies [6, 76].
Définir l’objectif du profiler permet également de déduire le niveau de granularité nécessaire afin d’atteindre cet objectif – la granularité étant le niveau auquel le profiler peut délivrer des mesures ou générer des estimations. En reprenant les exemples du paragraphe précédent, un profiler conçu pour estimer la puissance consommée par le système possède la granularité la moins fine (niveau système) [94]. Il en est de même un modèle conçu pour détecter des intrusions de sécurité [76]. Par contre, pour la surveillance du SoC, On requiert un niveau de granularité plus fin (composants) [4, 5], et un niveau de granularité encore plus fin (application), pour un modèle dont l’objectif est d’aider les développeurs à optimiser la consommation de puissance de leurs applications [125]. La Figure I.4 montre les niveaux de granularité les plus courants dans la littérature, du moins au plus fin.

Choix des entrées du modèle

Hoque et al. [82] indiquent que dans les systèmes embarqués et mobiles, il existe deux types d’entrées qui caractérisent l’activité des composants et des applications : les entrées basées sur l’utilisation du dit composant (utilization-based) et celles basées sur les événements (event-based). Les modèles avec des entrées basées sur l’utilisation se concentrent sur la corrélation directe entre l’utilisation d’un périphérique ou d’un composant et l’énergie consommée [82]. Pour estimer la consommation de puissance du module Wi-Fi, dans les modèle basés sur l’utilisation, on observe son débit transféré. En revanche, dans les modèles basés sur les événements, c’est plutôt l’état (activé / désactivé) du module qui est observé [127]. Néanmoins, les modèles publiés dans les travaux récents n’utilisent plus un seul type d’entrée, chacun des deux types ayant des limites [131], et utilisent plutôt une combinaison de ces derniers [5, 93, 105, 132].
Le choix des entrées dépend de deux facteurs principaux ; les données disponibles sur l’appareil (les mesures provenant des capteurs, fichiers systèmes, etc.) et la granularité souhaitée. En premier lieu, les profilers – notamment ceux basés sur des modèles – doivent au moins inclure des données provenant des composants nécessaires à la fonction du système, tels que les processeurs et les composants actifs durant le fonctionnement (écrans, communication, etc.) [83]. Chaque composant doit être décrit par au moins une variable en entrée (la fréquence pour le CPU, par exemple). Généralement, il faut plus d’une variable pour générer des estimations précise (la fréquence et la charge pour le cas du CPU, par exemple). Chen et al. [101] ont démontré, dans leur étude détaillant la consommation de puissance, comment chaque composant matériel est pris en compte dans le décompte d’énergie. En outre, Ardito et al. [81] montrent également l’écart entre les différentes générations de matériels et de technologies en terme de consommation d’énergie. Enfin, une granularité plus fine nécessite d’avantage de données pour générer des estimations correctes. Pour estimer la consommation de puissance d’une application, il est indispensable de dater son lancement et exécution, ainsi qu’enregistrer les fonctions auxquelles elle fait appel. Ceci nécessite l’utilisation des horodatages et des traces du système. Ces deux éléments sont essentiels à l’estimation de la consommation énergétique des composants logiciels, encourageant ainsi l’utilisation des séries temporelles (Timeseries) [65, 103].

Construction et implémentation du profiler

Les profilers matériels, par définition, sont conçus pour fournir des mesures et des estimations en ligne. Les profilers logiciels, quant à eux, peuvent soit fonctionner en ligne et générer des estima-tions à la volée, soit générer des estimations à partir de données collectées au préalable. Pour une étude statistique à grande échelle des profils de consommation de puissance, l’estimation hors ligne convient mieux à la tâche [133]. Toutefois, si le profiler a pour objectif de surveiller ou déboguer la consommation de l’appareil, l’estimation en ligne est une meilleure solution [134, 9]. Les modèles des profilers sont également caractérisés par l’endroit de leur construction et appren-tissage. Les modèles construits et entraînés sur l’appareil même ne requièrent aucun apprentissage ou réglage supplémentaire [18]. Ils génèrent des estimations précises et s’adaptent au profil spécifique de l’appareil [82]. Cependant, ils nécessitent une collecte de données et un temps d’apprentissage qui peut entraîner des coûts de calculs élevés. Les modèles construits et entraînés hors ligne éviteraient les inconvénients de ceux décrits plus haut [9], mais ils sont toujours spécifiques à un appareil et leur précision varie d’un appareil à l’autre [82].
La dernière catégorie regroupe les profilers hors-périphérique. Ces derniers sont construits et entraînés sur une machine secondaire, à l’exemple le Snapdragon Profiler [135]. Ces profilers four-nissent des estimations précises, notamment dans les cas de fine granularité [43], mais nécessitent un lien permanent entre l’appareil et la machine secondaire.
Choix de conception à faire :
— Approche de modélisation : Boîte blanche, grise, ou noire.
— Implémentation du profiler : Sur le système ou en dehors du système.
— Disponibilité des mesures et estimation : En-ligne ou hors-ligne.

Évaluation et mise au point du profiler

Pour les profilers basés sur des modèles, une fois ce dernier construit et entraîné, il doit être validé. En général, l’estimation des variables dans les systèmes embarqués est faite avec des modèles de régression (comme dans le cas de ce travail). Ainsi, nous nous concentrons sur la validation de ce type de modèle.
Dans cette étape, le modèle est testé en comparant ses estimation ˆy avec les mesures y. Durant cette comparaison, la qualité de l’ajustement (Goodness of fit), la précision des estimations, et analyser les résidus sont vérifiées.
La qualité de l’ajustement est une comparaison directe entre les estimations du modèle et les mesures. Généralement, elle peut être évaluée à travers la régression linéaire R des estimations et des mesures. La régression R est calculée par l’ajustement : ˆy = a y + b (I.1) où a et b sont des coefficients à déterminer (R est calculé pour le cas b = 0). Dans le cas idéal, ˆy correspond parfaitement à y, et l’on obtient R = 1. Par conséquent, en pratique, la valeur R doit se rapprocher de 1 le plus possible.

Table des matières

Introduction générale
I État de l’Art de la Modélisation des Processeurs Embarqués et Mobiles Hétérogènes 
I.1 Introduction
I.2 Architecture des systèmes hétérogènes embarqués et mobiles
I.2.1 Les systèmes hétérogènes
I.2.2 Les SoC basés sur l’achitecture ARM
I.2.2.1 Les processeurs basés sur l’architecture ARM
I.2.2.2 Les processeurs graphiques embarqués et mobiles
I.3 La modélisation des systèmes embarqués et mobiles
I.3.1 La modélisation de la puissance et de l’énergie consommée
I.3.2 La modélisation de la température
I.4 Conception et construction des profilers pour les SoC embarqués
I.4.1 Définition de l’objectif du profiler et sa granularité
I.4.2 Choix du type de profiling et des sources de mesure
I.4.3 Modélisation
I.4.3.1 L’approche de modélisation
I.4.3.2 Choix des entrées du modèle
I.4.3.3 Construction et implémentation du profiler
I.4.4 Évaluation et mise au point du profiler
I.4.5 Analyse comparative et synthèse de méthodologie
I.5 Conclusion
II Description du Profiler et Acquisition des Données 
II.1 Introduction
II.2 Les systèmes électroniques étudiés
II.3 Objectif du profiler : Monitoring du SoC
II.3.1 Variables caractéristiques du SoC
II.3.2 Granularité du profiler
II.4 Type du profiling : Profiling logiciel
II.4.1 Instrumentation des appareils étudiés
II.4.1.1 Sources des mesures
II.4.1.2 Acquisition des variables du SoC
II.4.1.3 Acquisition des variables du système
II.4.2 Développement de l’application d’acquisition sous Android
II.4.2.1 Le service d’acquisition et enregistrement des données
II.4.2.2 L’interface graphique pour l’analyse
II.4.3 Analyses des données acquises
II.5 Conclusion
III Modélisation Incrémentale des SoC Embraqués à CPU-GPU 
III.1 Introduction
III.2 Structure de modélisation interconnectée et incrémentale
III.3 Modélisation par analyse
III.3.1 Modélisation du gouverneur de fréquence
III.3.2 Modèle de la tension
III.3.3 Modélisation du régulateur thermique
III.4 Modélisation orientée données
III.4.1 Modélisation de la puissance
III.4.1.1 Choix des entrées du modèle de la puissance
III.4.1.2 Description du modèle de puissance
III.4.1.3 Synthèse du modèle
III.4.2 Modélisation de la température du SoC
III.4.2.1 Choix des entrées du modèle de température
III.4.2.2 Description du modèle du comportement thermique
III.5 Construction et implémentation du Modèle
III.6 Synthèse des choix de conception du profiler N3
III.7 Résultats et discussion
III.7.1 Validation des modèles de la fréquence et de la tension
III.7.2 Validation du modèle de puissance
III.7.2.1 Apprentissage, validation, et test hors-ligne du modèle de puissance
III.7.2.2 Validation de l’utilisation en ligne
III.7.2.3 Évaluation et comparaison des performances
III.7.3 Validation du modèle de température
III.8 Conclusion
IV Surveillance des SoC des Systèmes Embarqués 
IV.1 Introduction
IV.2 La surveillance des systèmes embarqués dans la littérature
IV.3 Approche de surveillance
IV.4 Lieu de l’implémentation de l’algorithme de surveillance
IV.5 Génération et évaluation des résidus des variables caractéristiques
IV.5.1 Génération des résidus
IV.5.2 Évaluation des résidus
IV.5.2.1 Évaluation des résidus de la fréquence et de la tension
IV.5.2.2 Évaluation des résidus de puissance et de température
IV.5.3 Isolation des défauts
IV.6 Test et validation de l’algorithme de surveillance
IV.6.1 Défauts de contrôle
IV.6.2 Défauts matériels ou composants
IV.6.3 Défauts causés par l’environnement
IV.7 Conclusion
V Prototypage d’un Système Mécatronique pour la Modélisation et la Surveillance 
V.1 Introduction
V.2 Mise en oeuvre du prototype
V.2.1 Architecture du prototype
V.2.2 La carte de développement
V.3 Modélisation du prototype
V.3.1 Adaptation du modèle incrémental à la carte développement
V.3.2 Résultats de la modélisation de la carte de développement
V.3.2.1 Validation des modèles de fréquence et de tension
V.3.2.2 Validation du modèle de puissance
V.3.2.3 Validation du modèle de la Température
V.4 Test du prototype
V.4.1 Validation sous le fonctionnement normal
V.4.2 Branchement d’un périphérique
V.4.3 Environnement surchauffé
V.5 Conclusion
Conclusion 
Bibliographie 

Télécharger le rapport complet