CONCEPTION « AMONT » D’UN MICROSYSTEME MULTICAPTEURS

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

Les tendances vers la miniaturisation et l’autonomie

C’est au début des années 1990 que sont posées les bases de la problématique du regroupement de plusieurs microcapteurs sur une même puce par K.D. Wise [WN91]. L’étude porte d’abord sur la compatibilité des procédés technologiques de fabrication des parties capteurs et traitement du signal. Le but est de reporter, au plus près de la partie sensible, un premier étage de traitement du signal (amplification, multiplexage, filtrage) apportant aussi une première valeur ajoutée au conditionnement du signal. Quelques années plus tard, dans les années 2000, le lancement du projet Smart Dust par K. Pister [WLL01] tente de réaliser un regroupement de microcapteurs sur une même puce. L’objectif est d’intégrer un système de traitement du signal et d’y ajouter un moyen de communication. Les thèmes abordés par cette nouvelle problématique sont de natures différentes, ils concernent principalement, du point de vue informatique, la gestion de l’énergie que consomme le système lors de son activité de calcul autonome [HSW00], l’intégration de microcapteurs variés et les moyens de communication et de transmission de l’information. Les nombreuses recherches au plan international ont conduit, dans ces trois domaines, à l’obtention d’une première génération de systèmes avancés. Plusieurs systèmes sont développés sur la même base architecturale : capteur, conditionneur de signal, traitement du signal, mémoire, communication (Figure 1-1). L’existence d’une architecture de base invite à préparer une approche spécifique de la conception. C’est une des motivations de notre étude.

Les capteurs utilisés en Génie Civil

Nous proposons de classer les capteurs utilisés en Génie Civil suivant deux catégories : une première catégorie qui regroupe les capteurs installés avant la coulée du béton sur les armatures de renfort. Ils sont donc noyés dans la masse du béton tout au long de leur vie. Une deuxième catégorie regroupe tous les capteurs qui peuvent être posés après la coulée du béton, à sa surface. Ces derniers sont utilisés pour la mesure de déformation de joints (fissuromètres), la mesure de déformation sous sollicitations (jauges de contraintes), ou la mesure de microdéplacements (extensomètres).
Nous évoquons ci-dessous les 3 principes de mesure les plus couramment employés dans ce domaine :
– Corde vibrante :
Cette mesure est basée sur l’utilisation d’une corde tendue entre deux points d’ancrage (Figure 1-12). Si cette corde est excitée par un champ électromagnétique, elle oscillera à sa fréquence propre de vibration. Toute variation de sa fréquence fondamentale témoigne d’une variation de tension. C’est en effet, cette variation de fréquence propre de vibration qui sera fonction du déplacement relatif de ces deux points d’ancrage.
– Fibre optique :
La fibre optique est utilisée comme matériau de base pour évaluer les contraintes ou les microdéplacements dans les structures. Les capteurs à fibre optique peuvent être divisés en deux familles : d’une part, les capteurs à modulation de phase, et d’autre part, les capteurs à modulation d’intensité. Nous nous intéressons ici à la première famille qui présente la plus grande précision de mesure de déplacement. Il s’agit de mesures d’interférométrie réalisées dans une cavité de Fabry- Pérot (Figure 1-13). Cette cavité est située au bout d’une longue fibre optique qui amène le signal lumineux. La déformation de cette cavité module la phase du signal réfléchi.
Ce type de capteur peut être utilisé, soit collé en surface d’armatures métalliques coulés dans le béton pour évaluer leurs états de précontrainte, soit directement coulé dans le béton après avoir été enveloppé d’un conditionnement adapté (Figure 1-14).

L’établissement du cahier des charges par les méthodes d’analyse fonctionnelle du besoin et des analogies

Le cahier des charges est le document de référence d’un projet. Il doit tout rassembler : les motivations, les idées, les exigences, les conditions d’utilisation et d’environnement, etc. Le cahier des charges a plusieurs volets :
– La description fonctionnelle du produit.
– La description physique du produit.
– Les exigences spécifiques du produit.
Nous nous sommes essentiellement intéressés, dans la démarche, aux aspects fonctionnels qui seront détaillés dans les prochains paragraphes.
Mais pour aller jusqu’au bout du prototype, il faut disposer de recommandations sur les deux autres volets. Les trois volets associés permettent au chef de projet d’organiser le travail des équipes. La tendance aujourd’hui est une organisation en processus : processus de conception, processus de conduite de projet, sûreté de fonctionnement, qualité, etc.
Dans la mise en oeuvre, cela dépend des exigences spécifiées. Dans notre cas, nous pouvons résumer les exigences à la démonstration de faisabilité des microsystèmes, dans un délai correspondant à la durée d’une thèse (Sept 2002 à Octobre 2005), sans exigences industrielles sur la qualité et la fiabilité du produit final.
Il reste donc la description physique du produit. Sur ce point, nous avons convenu de nous référer aux produits existants en apportant les innovations des produits autonomes et communicants. La base mécanique de l’extensomètre à corde vibrante de la Figure 1-12 peut donc guider nos choix terminaux d’implantation (systèmes mécaniques à deux points d’ancrage). La présentation suivante ne considère donc que les aspects fonctionnels.
Les études sont nombreuses pour aider à l’élaboration d’un cahier des charges avec deux ambitions principales :
1. Ne rien oublier,
2. Structurer le document de manière à favoriser la formalisation et le suivi des exigences.
Sur ce point (2), on trouve des travaux allant dans le sens d’une écriture encadrée par des mots clefs et par une structuration très rigoureuse du document. Cette approche paraît difficile à envisager dans le court terme car les participants à la rédaction d’un cahier des charges peuvent être nombreux et divers : difficile donc de leur faire parler un langage unique.
Notre projet a concrètement débuté sous l’impulsion d’une réunion qui a regroupé toutes les parties prenantes du projet. Si nous associons chaque personne présente à un acteur, nous pouvons alors dire que l’équipe de réunion était formée du maître d’ouvrage, et d’une équipe de concepteurs responsables de la maîtrise d’oeuvre. Cette réunion a eu pour objectif de mettre à jour les principales spécifications et propriétés attendues du système. Cette étape est un premier pas vers le cahier des charges. Nous choisissons de la scinder en deux phases pour la compréhension de la démarche. Une première phase concerne la collecte d’informations latentes que détiennent les participants et d’autre part, une deuxième phase concerne l’innovation de conception et l’aide à la génération d’idées, sur la base de la méthode des analogies. Ces deux phases peuvent être conduites séquentiellement en débutant par l’une ou l’autre. Nous avons choisi de débuter la collecte des informations pour cadrer le projet et ensuite nous avons mené la phase de discussion créative. Nous allons détailler ces deux phases dans les paragraphes suivants.
Dans la première phase, nous sommes amenés à considérer le problème de l’élicitation, qui consiste à provoquer ou déclencher la formulation d’un maximum d’informations. Cette problématique touche essentiellement les études marketing pour sonder les informations latentes d’un groupe d’individus, mais il est important de la garder en tête dans le cadre de l’ingénierie et dans les rapports d’échanges entre différents partenaires d’un même projet. Dans ce cas, les informations proviennent de chaque partie prenante du projet et concernent différents domaines d’expertise relatifs à leur culture propre. Goguen présente et discute les démarches qui peuvent être entreprises [GL93]. Nous retiendrons l’introspection, les interviews orientés, les questionnaires, les discussions. Il s’agit d’un grand nombre de méthodes qui orientent plus ou moins l’information souhaitée en proposant un cadre. De cette manière, l’information est déjà préclassée, en adéquation avec son contexte et pré-formatée pour son exploitation future. Il fait apparaître l’importance du contexte dans l’interprétation et l’appréciation des informations. Cette idée est fondamentale lorsque l’on souhaite garder le sens premier qui a été donné à l’information et ainsi limiter les risques de mauvaises interprétations. Cette idée de contexte est toujours valable une fois que l’information est formalisée, puisque le modèle ainsi créé n’est pertinent que dans un contexte bien défini par une syntaxe, des règles et des limites fixées. Cette étape concerne donc le regroupement d’informations qui sont latentes, mais qui ne demandent qu’à être extraites, formalisées et exploitées.

Formalisation du cahier des charges

Nous avons vu que pour éviter au maximum l’ambiguïté de compréhension d’un cahier des charges rédigé en langage naturel, il convient de suivre une structure et des règles de présentation.
Ce document de base reste tout de même textuel. Il est donc « humain », c’est à dire qu’il dépend d’une culture, d’un contexte, ce qui amène souvent une rédaction subjective. De nombreux travaux tentent de limiter au mieux cette ambiguïté qui s’immisce dans les spécifications. L’idée généralement suivie est d’appliquer, au plus tôt, un formalisme pour créer des modèles de représentation de haut niveau à partir desquels, il sera possible de reformuler les spécifications du cahier des charges sous une configuration formelle. Nous pourrons ensuite appliquer des procédures de vérification pour s’assurer que ces représentations de haut niveau sont conformes au cahier des charges.
Pour atteindre cet objectif, nous proposons d’établir une démarche pour aller proprement du semi-formel au formel afin de bénéficier des avantages suivants :
• avoir une représentation claire des fonctionnalités et du comportement du système,
• générer une version formelle non ambiguë et complète des spécifications de ce système,
• permettre une première analyse des fonctionnalités et du comportement du système,
• établir une première validation des spécifications.
De nombreux travaux ont été réalisés, dans cet esprit, pour l’ingénierie logicielle. Aujourd’hui, les concepts de traçabilité et de validation des spécifications à haut niveau imaginés pour l’ingénierie logicielle émergent dans le domaine de la conception de systèmes hybrides qui englobent à la fois des parties logicielles et des parties matérielles multidisciplinaires. Nous nous situons dans ce cas de figure [Mau05b].

Position du problème

Dans l’absolu, il faut considérer qu’au delà du cahier des charges tel que nous l’avons introduit au Chapitre 1, le concepteur a accès à une base de données où l’on retrouvera tous les acquis antérieurs disponibles (Figure 2-1) :
• les composants réutilisables,
• les retours d’expériences récents,
• les données expertes,, etc.
Pour permettre une conception « globale » à la fois fonctionnelle, structurelle et économique, nous ne nous intéressons, dans ces travaux, qu’aux seuls aspects fonctionnels. Nous pensons que deux approches descriptives doivent être privilégiées :
• la description hiérarchique descendante des fonctions constitutives du système,
• la logique fonctionnelle débouchant sur un ensemble de scénarios.
Evidemment, nous voulons à partir de là, converger vers une représentation selon le formalisme HiLeS, pour y appliquer une démarche de vérification à l’aide de TINA et ouvrir la voie au prototypage virtuel VHDL-AMS.

Proposition et mise en oeuvre d’une démarche de formalisation : fonctions et procédures

D’un point de vue fonctionnel, le cahier des charges doit définir clairement les objectifs fonctionnels du système tels que les entrées-sorties et les conditions d’environnement : énergie et environnement. Le système peut être complexe et il convient de rester au plus près des modes de raisonnement du concepteur.
Les vues représentatives des systèmes sont multiples, elles peuvent être : structurelles, fonctionnelles, comportementales (dynamique temporelle) ou orientées flux de données. A partir de ce point, nous proposons une approche de lecture du cahier des charges qui s’appuie sur les outils que nous développons également.
Par souci de clarté, nous avons choisi de réécrire textuellement les deux cas de description énoncés en 2.2.1 : à la fois la description statique fonctionnelle et la logique fonctionnelle aboutissant à la dynamique du système. Nous avons appelé ce document « Document de conception » [Mau04a].
La description statique définit une hiérarchie de fonctions qui se retrouve dans le plan du Document de Conception (Figure 2-3). Les « Fonctions objectifs » sont extraites du cahier des charges et deviennent des blocs.

Traçabilité des exigences

L’ingénierie des exigences qui regroupe toutes les activités liées à l’identification, au suivi, à la gestion de l’évolution des exigences d’un projet a d’abord été déployée dans le domaine logiciel et se déploie aujourd’hui dans les sociétés produisant des systèmes matériels complexes. L’exemple qui peut être pris est celui de PSA Peugeot-Citroën qui a mis en place très récemment, depuis le milieu de l’année 1999, la première équipe d’ingénierie système [9]. Cette équipe a contribué à déployer un premier processus d’ingénierie des exigences.
Les outils d’ingénierie système s’inscrivent dans le contexte de cycle de développement en V, dans lequel, dans un premier temps les exigences sont identifiées et suivies dans la branche descendante du V, puis sont intégrées au traitement de la branche ascendante. Le principe de base de la traçabilité est d’établir des liens entre toutes les étapes de conception, ce qui correspond souvent à établir des liens inter documents et à vérifier la cohérence des exigences ou à valider un modèle à tous les stades de développement d’un projet. Le but est de garder une cohérence claire et directe entre les exigences spécifiées et les représentations du système.
D’une manière générale, les outils de traçabilité ont les fonctions suivantes :
• créer des liens inter documents,
• extraire des informations filtrées des documents texte (à l’aide de mots clefs contenu dans un lexique),
• éditer un nouveau document texte « spécialisé » (après un filtrage adapté),
• paramétrer l’état d’une exigence pour accéder à un suivi temporel de son implémentation (exemple de noms d’états associés à un lexique : en analyse, en négociation, en reformulation, référent, obsolète),
• visualiser une matrice d’impact,
• visualiser une matrice de conformité,
• visualiser une matrice de vérification.
La traçabilité permet de suivre une exigence formulée sur un cahier des charges tout au long d’un projet. Les outils de traçabilité actuels sont orientés « texte » et sont efficaces sur des documents textuels. Ils consistent à faire des liens entre des zones de textes marquées, ou des liens entre des zones de texte et des images, des graphiques, ou des tableaux qui illustrent un élément des spécifications. Il faut impérativement avoir une structuration claire du document pour faciliter l’indexation semi-automatique du document et la recherche de champs du document.
La Figure 2-7 illustre l’exemple d’un élément X que l’on retrouve dans 3 documents édités au cours d’un projet : le cahier des charges, la description du prototype et les procédures de tests.
Ces 3 documents sont représentatifs de la structure en « V » du cycle de développement. Les liens sont ici représentés par des flèches bidirectionnelles. Le marquage de l’élément X est réalisé par le biais de « drapeaux » déposés à l’endroit voulu par le concepteur après l’analyse fine du texte. La plupart des outils du commerce utilisent le langage XML (eXtensive Markup Language) comme moyen d’établir ces liens.

Harmonisation avec l’approche UML/SysML

La conception logicielle, guidée par les processus « Model Driven Design » (MDD), a été un élément de référence pour développer des outils d’aide à la modélisation haut niveau de systèmes logiciels et les étendre à la conception système. Les analyses faites par Tse et Pong [TP91], sur plusieurs langages de spécifications, permettent de définir les principales caractéristiques de ceslangages :
– Abstractions des modèles pour simplifier la représentation du système.
– Association de graphiques et de textes pour bénéficier de la simplicité de présentation des graphiques et la liberté d’expression du langage naturel.
– Cohérence des représentations maintenue après des manipulations.
– Indépendance de la conception et de la réalisation : la représentation doit être orientée vers l’expression du « quoi faire » sans prendre partie pour le « comment faire ».
Parmi les nombreuses méthodes de conception logicielles, trois d’entre elles ont su se regrouper et ajouter leurs qualités propres. D’une part, la méthode OOD [Boo93] gère la phase de conception et la construction du projet, d’autre part la méthode OOSE [Jac94] apporte les cas d’utilisation pour définir les exigences et pour l’analyse de la conception générale, et enfin, la méthode OMT [RBP91] est utile aux systèmes d’informations contenant une grande quantité de données.
La mise en commun des méthodes OOD, OMT et OOSE a permis de remodeler et d’unifier les représentations des systèmes logiciels dans une boîte à outil unique, proposée par Booch, Rumbaugh et Jacobson, appelée « Unified Modeling Language » (UML) [BRJ00]. L’essor d’UML dans le domaine des logiciels et le développement de plate-formes d’outils performants a naturellement conduit à envisager son utilisation dans l’ingénierie système. Pour cela, un effort d’adaptation et de normalisation a donné lieu à SysML (basé UML 2) en Janvier 2005 dont l’ambition est d’unifier la modélisation système et la modélisation logicielle. Cette norme pose les bases d’un langage qui ouvre une voie intéressante vers le prototypage virtuel.
En l’état, la porte d’entrée de la plate-forme HiLeS est la spécification textuelle. Il reste un pas important à franchir entre cette spécification textuelle et la représentation HiLeS tel que le signifie la flèche cerclée de noir sur la Figure 2-12. Ceci fait apparaître l’intérêt d’une démarche plus approfondie de traduction des spécifications textuelles.
Pour combler en partie ce saut, nous avons travaillé avec l’équipe Ingénierie des Systèmes et Intégration (ISI) du L.A.A.S. pour proposer une approche complète de conception système vers le prototypage virtuel, basée sur les composants [EOP05]. Elle s’appuie sur une première modélisation des spécifications par le biais de diagrammes SysML.

Utilisation de la méthode UML/SysML sur notre exemple

Nous allons suivre et appliquer à notre exemple les trois phases de la méthode décrite dans le paragraphe 2.2.4.
L’étape A de cette méthode rejoint nos travaux sur l’élaboration du cahier des charges par la méthode d’analyse du besoin. Nous retrouvons notamment la notion de présentation du système dans son environnement, dans le but de faire ressortir les parties du système y étant liées ou interagissant. Cette première analyse aboutit au diagramme de contexte général (étape A.3). Ce diagramme fait apparaître tous les éléments de l’environnement en liaison avec le système (Figure 2-13). La méthode des composants suggère d’identifier les acteurs (A.4) et d’en déduire un diagramme de contexte final associé (A.6). Les acteurs consistent en une abstraction des éléments en les regroupant par exemple selon les critères suivants :
– Rôle de l’élément,
– Interaction entre éléments,
– Nature des éléments,
– Etc.

Modélisation HiLeS du microsystème

Avant de présenter la modélisation du système dans HiLeS, nous allons exposer le formalisme HiLeS.

Le formalisme HiLeS

Nous présentons ici les principaux éléments qui définissent le formalisme HiLeS. Ce formalisme est le fruit des travaux successifs accès sur la théorie [Jim00] et sur le développement et l’utilisation du logiciel HiLeS [Ham05].
Ainsi, dans le contexte industriel de conception des microsystèmes pluridisciplinaires que nous avons décrit dans le chapitre précédent, la plate-forme de conception HiLeS a un double objectif : d’une part, être un outil d’aide à la conception pour l’équipe chargée de l’étude de faisabilité du système et d’autre part, être une plate-forme ouverte aux fournisseurs pour qu’ils puissent valider leur propre contribution dans le système global. Nous évoquons ici deux points importants qui sont le coeur de la problématique du prototypage virtuel ; concevoir suivant les spécifications, puis simuler et vérifier les propriétés du système.
Pour cela, HiLeS fournit les éléments de base pour décrire le système pluridisciplinaire à haut niveau. Nous avons un ensemble de blocs (structurels et fonctionnels), des canaux de communication et des réseaux de Petri qui composent la description d’un système sous HiLeS.
Les blocs et les canaux de communication permettent de présenter de manière hiérarchique la structure fonctionnelle du système alors que le formalisme des réseaux de Petri permet de modéliser les états de fonctionnement de manière formelle.

Le modèle de commande

HiLeS utilise le formalisme des réseaux de Petri ordinaires qui permettent la représentation graphique de systèmes concurrents et parallèles. Le réseau comporte trois éléments particuliers : un ensemble fini de places symbolisées par des cercles, un ensemble fini de transitions symbolisées par des tirés et un ensemble fini d’arcs orientés qui assurent la liaison d’une place vers une transition ou d’une transition vers une place.
Les places constituent la matérialisation d’une condition (état du système) alors que les transitions représentent l’événement qui modifie l’état du système. HiLeS utilise les réseaux dits ordinaires puisque le tir d’une transition est validé à la condition que les places amont soient marquées d’un jeton et seulement un.
Les arcs du réseau de Petri connectés aux blocs seront considérés comme les « connecteurs » par lesquels les processus internes au bloc sont déclenchés. Le déclenchement effectif a lieu lorsqu’un arc amène un jeton dans le bloc cible.

Représentation type dans HiLeS

A partir des éléments définis dans les paragraphes précédents, nous pouvons ainsi représenter des systèmes à très haut niveau. La Figure 2-23 illustre un système type élaboré sous HiLeS.
Ainsi, nous faisons apparaître sur la Figure 2-23.1 trois blocs structurels interconnectés par des canaux continus (in_1, in_0 et out_1), des canaux discrets (out_0) et des canaux discrets relatifs aux arcs de Petri (C1, C2, S1, S2). La Figure 2-23.2 illustre la structure interne du bloc Structural_0. Ce bloc structurel est composé d’un bloc structurel (Structural_5), un bloc fonctionnel (Functional_0) et d’un ensemble de places, de transitions et d’arcs de Petri qui forment un réseau de commande.
Nous voyons ainsi la transition entre une représentation du système par un assemblage de blocs vers une représentation fonctionnelle temporisée par le biais de réseaux de Petri. Cette construction hiérarchique peut être réalisée comme ici, dans le but de décomposer un bloc structurel, ou à l’inverse, elle peut être utilisée de manière à agréger plusieurs blocs et réseaux de commande en un bloc structurel.

Table des matières

CHAPITRE 1 PROBLEMATIQUE SCIENTIFIQUE ET INDUSTRIELLE
1.1 Introduction
1.2 Etat de l’art des microsystèmes de surveillance
1.2.1 Les capteurs de surveillance
1.2.2 Les tendances vers la miniaturisation et l’autonomie
1.2.3 Les applications
1.2.4 Les techniques d’intégration microsystèmes
1.3 Les modes de conception microsystèmes
1.3.1 Les motivations scientifiques
1.3.2 La conception descendante selon le cycle en V
1.3.3 La plate-forme de conception HiLeS
1.4 Notre projet
1.4.1 Le contexte de l’étude
1.4.2 Les capteurs utilisés  enGénie Civil
1.4.3 L’établissement du cahier des charges par les méthodes d’analyse fonctionnelle du besoin et des analogies
1.4.4 Le plan de travail
1.5 Conclusion
CHAPITRE 2 CONCEPTION « AMONT » D’UN MICROSYSTEME MULTICAPTEURS
2.1 Introduction
2.2 Formalisation du cahier des charges
2.2.1 Position du problème
2.2.2 Proposition et mise en oeuvre d’une démarche de formalisation : fonctions et procédures
2.2.3 Traçabilité des exigences
2.2.4 Harmonisation avec l’approche UML/SysML
2.2.5 Utilisation de la méthode UML/SysML sur notre exemple
2.2.6 Bilan et recommandations
2.3 Modélisation HiLeS du microsystème
2.3.1 Le formalisme HiLeS
2.3.2 Mise en oeuvre sur l’exemple
2.3.3 Difficultés rencontrées et recommandations
2.4 La vérification sur TINA
2.4.1 L’objectif de la vérification formelle dans la plate-forme HiLeS
2.4.2 Mise en oeuvre sur l’exemple
2.4.3 Difficultés rencontrées et recommandations
2.5 Conclusion
CHAPITRE 3 LE PROTOTYPAGE VIRTUEL
3.1 Introduction
3.2 Les langages
3.3 La traduction du modèle amont en modèle VHDL-AMS
3.3.1 Application de la méthode ConPar
3.3.2 Application de la méthode des composants
3.3.3 Les approches en cours
3.4 L’agrégation fonctionnelle
3.4.1 La procédure préconisée par HiLeS : agrégation – « building blocks »
3.4.2 La question du partitionnement Hard/Soft
3.4.3 Les options dans notre exemple
3.5 Spécifications et choix des fournitures
3.6 Le prototype virtuel du système
3.6.1 La modélisation VHDL-AMS dans l’exemple
3.6.2 Les résultats de simulation
3.6.3 Tests et validations
3.6.4 Difficultés rencontrées et recommandations
3.7 Extensibilité de la méthode aux microsystèmes de surveillance
3.8 Conclusion
CHAPITRE 4 INTEGRATION, PROTOTYPAGE REEL ET VALIDATION
4.1 Introduction
4.2 Préambule
4.3 Modélisation structurale et organique
4.3.1 Description structurale et organique
4.3.2 Décision de partitionnement
4.4 Les choix d’intégration
4.5 Réalisation du microsystème
4.5.1 Les composants mécaniques utilisés
4.5.2 La sous-traitance électronique
4.5.3 Test des fournitures
4.5.4 Evaluation de la consommation
4.5.5 Intégration du microsystème
4.6 Premières mises en oeuvre et perspectives
4.7 Validation du système par comparaison au cahier des charges
4.8 Conclusion
CONCLUSION GENERALE
ANNEXES
Annexe 1 : Schéma de principe général et les principaux composants du système
Annexe 2 : Algorithme de fonctionnement du système SmartGec
Annexe 3 : Etude de la consommation du système
Annexe 4 : Codes VHDL-AMS du bloc « Analyse » de « Measure Treatment »
REFERENCES
RESUME
ABSTRACT

Télécharger le rapport complet