Chapitre 2 automatisation de l'exploitation des résultats ...csidoc.insa-lyon.fr/these/2002/mi/chap2.pdf · Extraction des paramètres et domaine de validité du modèle d’un composant

Extraction des paramètres et domaine de validité du modèle d’un composant de puissance

CHAPITRE 2 AUTOMATISATION DE

L’EXPLOITATION DES RÉSULTATS

EXPÉRIMENTAUX ET DE SIMULATION

Wei MI

Thèse INSA de Lyon - CEGELY

47


2.1 Objectif

Dans le premier chapitre, nous avons présenté la physique des composants à semi-

conducteur et leurs comportements statiques et dynamiques. Puisque notre tâche

d’identification et de validation repose sur une confrontation entre des mesures

électriques et des simulations, nous avons besoin de concevoir un système expérimental

qui nous permette d’acquérir des données expérimentales, basé sur les circuits des

figures 1.7, 1.15 et 1.23. La comparaison doit donc être faite entre la simulation et

l’expérience. Mais la simple comparaison des courbes, au sens, par exemple, des

moindres carrés continus, n’est pas toujours opportune.

Par exemple sur la figure 2.1 nous comparons le courant mesuré et celui simulé

pendant l’ouverture d’une diode. L’écart sur les amortissements en fin de commutation

conduit à une valeur importante de la norme L2 de l’écart de simulation/expérience.

Toutefois, ces oscillations proviennent de phénomènes résiduels qui sont très difficiles à

bien modéliser et on peut finalement les considérer comme peu importantes pour

l’intérêt du modèle dans des applications de conception. Aussi, avons nous dû comparer

directement les caractéristiques par des paramètres qui décrivent les courbes transitoires,

comme IRM, VRM, tRR. Ces paramètres transitoires doivent être analysés en mesure et

en les simulation.

Figure 2.1 Comparaison du courant mesuré et de simulation de la diode PiN

pendant la commutation à l’ouverture

Wei MI


48


Aussi, nous devons développer un logiciel pour contrôler les simulations et

extraire les paramètres provenants des résultats de simulation. C’est pourquoi, une partie

non négligeable de notre travail a été axée sur la mise en place d’une méthode

d’exploitation des résultats expérimentaux et de simulation.

Nous commençons ce chapitre par l’introduction du système de test basé sur le bus

GPIB qui nous permet d’acquérir automatiquement les signaux électriques et d’extraire

des données nécessaires, indépendamment du circuit utilisé.

Deuxièmement, nous aborderons un langage orienté objet JAVA [Horstmann-99]

et deux techniques utiles à notre projet: JNI [JNI-97] nous permet le pilotage en C++ de

la carte GPIB [Asch-99]et la classe process qui permet de contrôler les processus de

simulation, indépendamment du circuit utilisé.

La dernière partie de ce chapitre sera consacrée à la description d’une méthode

pour tracer automatiquement les caractéristiques statiques des composants. Cela nous

permettra de bien illustrer le fonctionnement du système matériel et logiciel.

Wei MI


49


2.2 Pilotage: banc de mesure, piloté par un bus GPIB

En général, un système d’acquisition de données est composé d’un ordinateur,

d’un logiciel et d’une carte d’acquisition de données. On adopte une carte GPIB basée

sur la transmission de données en parallèle ce qui permet des transferts rapides [Asch-

99].

Le bus GPIB (General Purpose Interface Bus) est également appelé HP-IB

(Hewlett-Packard Interface Bus). Il sert à simplifier les interconnections entre des divers

instruments de mesure et un contrôleur/ordinateur. Les appareils de mesures sont

connectés à un ordinateur par un bus GPIB ayant une norme baptisée IEEE-488 (IEEE

Standard Digital Interface for Programmable Instrumentation) qui définit ainsi le

nombre de fils, la nature des signaux qui y circulent, leurs fonctions et leur

séquencement, l’organisation du connecteur et, plus généralement, les règles d’échanges

entre les divers matériels appelés à dialoguer. Grâce à ce bus, la réalisation d’un banc de

mesures piloté par ordinateur se réduit à une simple connexion (figure. 2.2). On peut

classer ces appareils en trois types, en fonction de leurs rôles.

Figure 2.2 Système GPIB

Les contrôleurs, souvent des ordinateurs, commandent et supervisent les

échanges : configuration des appareils, séquencement des opérations. Il peut y avoir

plusieurs contrôleurs dans le système mais un seul est actif à la fois.

Les émetteurs (talkers) envoient des messages à destination d’autres appareils : il

s’agit d’appareils de mesure transférant leurs résultats.

Les récepteurs (listeners) reçoivent les messages envoyés par d’autres appareils.

Wei MI


50


Tous les appareils ont leurs propres adresses physiques dont la gamme est entre 0

et 30, mais leur nombre est limité à seize, y compris pour l’ordinateur.

Une carte d’extension à la norme IEEE-488, fournie par la société Keithley

Instrument Corporation, a été choisie pour dialoguer avec l’oscilloscope et les

alimentations pilotées par GPIB. Cette carte comporte un circuit d’interface

ordinateur/bus GPIB et un buffer permettant de transférer les données par 1.5M

bytes/seconde entre l’ordinateur et les appareils.

La société fournit une librairie de programmes ainsi qu’un driver universel pour

Windows. Il s’agit d’une couche logicielle permettant de programmer directement les

registres de la carte, de gérer son fonctionnement et son intégration au sein des

ressources du PC (interruptions du processeur, DMA, mémoire, etc.). C’est-à-dire, que

le logiciel driver s’occupe des détails de la programmation de bas niveau.

Pour contrôler des appareils et acquérir des données à partir de l’ordinateur, on se

trouve face à un double choix : soit on utilise un progiciel d’application spécialisé conçu

pour l’acquisition de données, par exemple LabWindows ou TestPoint, soit on

développe un progiciel à l’aide de langages généraux traditionnels. Nous avons choisi la

dernière approche, car nous devons faire des tâches similaires dans le programme de

pilotage des mesures et dans le programme d’analyse des résultats de simulation.

Donc, dans notre projet, plusieurs logiciels sont développés en langage JAVA, en

adoptant la technique JNI pour piloter la carte GPIB. Tous les instruments doivent

comporter une interface GPIB et être conforme à la norme standard IEEE-488.

Un expandeur/isolateur de bus GPIB est mis en œuvre entre l’ordinateur et les

appareils pour deux raisons :

• Pour éviter l’introduction des perturbations. En réalité, dans tous les

milieux où l’électricité et l’électronique sont utilisés, il y a présence de sources de

perturbations électromagnétiques et des appareils sensibles à ces perturbations.

Dans notre cas, les perturbations les plus importantes se composent de deux

parties. Une part elles proviennent des composants de puissance sous test avec

leurs di/dt très élevés. D’autre part, les alimentations à découpage, les sources de

tension et de courant, contribuent à la prolifération de ces perturbations

électriques.

• Pour isoler le bus côté ordinateur et le bus flottant côté oscilloscope. Afin

de mesurer des signaux électriques, il est choisi de placer la masse de

Wei MI


51


l’oscilloscope sur la borne positive de l’alimentation de tension. En effet, le câble

GPIB force les masses des différents appareils au même potentiel. Par contre, la

masse de l’ordinateur est fixée à la terre.

Avec le GPIB-120 bus expandeur, les deux systèmes de bus séparés physiquement

sont isolés électriquement en améliorant la compatibilité électromagnétique.

La structure de notre équipement est décrite par les figures 2.3 et 2.4.

Dans ce système automatique de mesure, nous utilisons une alimentation en mode

tension XANTREX "XKW300-10" et une alimentation en mode courant HP "6652A".

Un autre générateur "TOE-8704" dont la tension de sortie est très précise sert à donner

la valeur de la tension grille VGS pour les composants telles que le MOSFET et l’IGBT.

Chaque appareil électrique peut être contrôlé par le PC avec un programme développé

en JAVA.

De la même façon, un oscilloscope numérique est relié à l’ordinateur à l’aide du

bus d’interface GPIB. Nous pouvons le manipuler en envoyant des commandes à travers

le bus GPIB, de la même manière que nous manœuvrons les boutons, les bornes sur le

panneau avant. Cet appareil peut enregistrer les courbes électriques et transfère ces

courbes au PC.

Figure 2.3 Photographie du système automatique de mesure

Wei MI


52


Figure 2.4 Structure du système automatique de mesure

Wei MI


53


2.3 Technique Java

2.3.1 Généralité Java [Horstmann-99] est un langage orienté objet, multi-plate-forme, conçu pour être

facilement utilisable et maniable par une large majorité de développeurs. Développé par

Sun Microsystems, Java rassemble aujourd’hui derrière lui une large communauté

d’acteurs informatiques majeurs tels que HP,IBM, Oracle, Borland.

Quand on aborde ce langage, on met souvent en exergue:″Java est un langage simple,

orienté objet, réparti, interprété, robuste, sécurisé, indépendant de l’architecture,

portable, efficace, multithreads et dynamique″ .

Java a été choisi pour notre travail pour les raisons suivantes :

• Java est résolument basé sur la technologie objet et emprunte de nombreux

éléments au C++. En revanche, les concepteurs de Java ont supprimé les concepts

plus difficiles. Donc le code Java est plus simple et plus clair que celui de C++. En

transférant facilement du code C++ à Java, nous avons bénéficié des fonctions ou

classes matures qui se trouvent dans le programme PACTE écrit en C++ au

CEGELY.

• Java s’affranchit des plates-formes : il fonctionne en mode interprété. Nous

pouvons développer le programme sous n’importe quel système d’exploitation :

Unix, Macintosh, DOS, Windows, Linux, etc. Cet avantage nous permet de réutiliser

au maximum toutes les fonctions ou classes en diminuant la durée de

développement. Notre projet se divise en deux parties. Une partie est de mesurer les

signaux électriques et d’extraire les paramètres électriques qui représentent ces

courbes sous Windows, tandis que l’autre partie est de piloter le simulateur et

analyser les résultats sous Unix.

Le fonctionnement de Java est assuré par JVM (la machine virtuelle Java) et JDK

(le Java Dévelopement Kit) qui peuvent être installé dans les différents systèmes

d’exploitation.

Généralement, un compilateur comme C++, produit un code exécutable lié au

processeur et à la plate-forme, puisque destiné à s’exécuter directement sur un

environnement précis. Au contraire, le code binaire de Java est portable, car son code est

compilé et interprété au sein d’une machine virtuelle. Cette machine virtuelle assure la

Wei MI


54


traduction entre le ″bytecode″ et les différents systèmes sur lequel le programme est

amené à s’exécuter.

Afin de garantir la possibilité de s’exécuter sur de nombreux systèmes existants ou

à venir, la machine virtuelle définit une architecture d’exécution complète : un jeu

d’instructions précis, des registres et une pile. Il s’agit donc d’un véritable processeur

virtuel qui définit et implémente les éléments nécessaires au bon fonctionnement des

programmes Java: allocation mémoire, format des programmes Java compilés,

interpréteur, etc.

Par ailleurs, le JDK regroupe l’ensemble des éléments permettant le

développement, la mise au point et l’exécution des programmes Java. Il inclut de

nombreux outils de développement, un jeu de classes et de services et un ensemble de

spécification. Le JDK est en évolution constante, et la version courante est 1.4.

Pour faciliter le développement en Java, Borland a conçu l’outil de développement

performant appelé Jbuilder [Acremann-99] qui supporte toutes les technologies Java et

peut suivre l’évolution du JDK. En fait, il est un environnement complet incluant toutes

les fonctionnalités de développement et toutes les technologies liées à Java, qui nous

permettent de créer rapidement notre programme. Cet environnement réunit tous les

éléments indispensables au développement et à la mise au point des applications.

Comme dans tous les produits Borland, l’environnement regroupe tous les outils

nécessaires : éditeur de fichiers, concepteur visuel d’interface, gestion de projet,

compilateur, débogueur, etc.

Wei MI


55


2.3.2 JNI Pourquoi donc vouloir mélanger Java avec un autre langage, par exemple, C++

dans notre projet ?

Java est un langage conçu pour être indépendant de plate-forme. Donc il ne permet

d’accéder aux fonctionnalités spécifiques d’un système. C’est-à-dire, il n’est pas

possible avec Java de manipuler le driver Windows de la carte GPIB dans notre système

automatique de mesure. Toutes ces manipulations proches du système se feront donc

avec le logiciel livré en C++ par le fournisseur de la carte. Donc, il exige une interface

entre C++ et Java.

Cette interface Java permettant de lier du code natif au code Java est désignée par

le terme JNI (Java Native Interface) [JNI-97]. Une méthode native est un programme en

C++ qui peut accéder à l’information d’une classe Java. De même, une classe de Java

peut lancer une méthode native et échanger de l’information à travers JNI. Nous nous

intéressons qu’à cette dernière méthode. La figure 2.5 montre la fonctionnalité de JNI

entre C++ et Java. La figure 2.6 illustre le pilotage de la carte GPIB par cette interface.

Figure 2.5 Fonctionnalité de JNI entre C++ et Java

Figure 2.6 JNI pour piloter la carte de GPIB sous Window 98

Wei MI


56


Concrètement, à côté de Java, on construit une classe GPIBdriver.class qui

contient les méthodes générales du GPIB (figure 2.7-a)). La méthode

GPIBdriver.initialize() sert à initialiser le bus GPIB et à définir l’adresse du PC. Les

autres méthodes envoient les commandes vers le programme C++ et reçoivent les

réponses. S’il y a une erreur lors de la transmission de GPIB, on peut prendre

connaissance du type d’erreur en consultant des messages dans la classe

GPIBexception.class (figure 2.7-b)).

a) b)

Figure 2.7 les classes de JAVA pour piloter le bus GPIB

Dans le programme d’application, on construit les classes correspondant

respectivement à chaque alimentation et instrument montrées à la figure 2.8.

Figure 2.8 Hiérarchie des classes dans le programme JAVA

Wei MI


57


2.3.3 Processus

Java possède une classe appelée java.lang.Process qui représente un programme

s’exécutant de manière externe à la machine virtuelle JAVA. Un programme Java peut

communiquer avec un processus externe en utilisant des flux de la même manière qu’il

peut communiquer avec un serveur s’exécutant sur un autre ordinateur du réseau.

L’utilisation d’un objet Process est toujours dépendant de la plate-forme et rarement

portable, mais il s’avère très utile pour appeler un processus de simulation tels que

DESSIS ou PACTE. Annexe B nous donne un exemple de DESSIS.

2.4 Mesure des caractéristiques statiques du MOS/IGBT

2.4.1 Circuit de test Pour la phase d’estimation et d’identification, deux types de caractéristiques sont

exploités : des caractéristiques statiques d’une part et des caractéristiques transitoires

d’autre part.

La méthode la plus aisée pour obtenir la caractéristique statique est d’utiliser un

traceur électronique, par exemple le traceur TEKTRONIX 371A.

Malheureusement, la mesure des caractéristiques statiques pose rapidement le

délicat problème de l’auto-échauffement du composant pendant la mesure avec ce

traceur. Le phénomène de l’échauffement s’amplifie lorsque la tension est grande. Cela

peut engendrer des erreurs dans les résultats d’identification. Il est donc nécessaire de

développer une méthode pour résoudre ce problème, car notre méthode d’identification

est basée sur la comparaison entre les résultats d’expérience et des résultats de

simulation.

Le schéma de la figure 2.9 représente le circuit de test pour acquérir les

caractéristiques statiques du composant. Il comprend une source de tension E pilotée par

GPIB et une résistance de charge RC dont sa valeur dépend du courant maximal

traversant le composant sous test T2. Le circuit comporte un interrupteur IGBT

T1(BUP314) qui est commandé par un générateur d’impulsion. Le composant sous test

T2 est aussi commandé par une alimentation de tension dont la valeur de sortie est très

précise. On mesure le courant et la tension, pour T2, à l’aide d’un oscilloscope

numérique basé sur le bus GPIB. Comme T2 ne tient jamais la tension, le problème de la

Wei MI


58


saturation de l’ampliateur d’entrée de l’oscilloscope ne se pose pas. La tension vDS à

mesurer varie entre 0V et VDson.

Figure 2.9 Circuit de test pour mesurer les caractéristiques d’un composant bipolaire

Comme le montre à la figure 2.10, le signal soumis à l’interrupteur T1 nous permet

d’estimer les pertes dans T2, le composant sous test. Le calcul direct de la puissance

dissipée pendant les commutations n’est pas simple. En revanche, nous pouvons calculer

la puissance moyenne sur un cycle : Section d'équation 2

0

0 2 21 ( ) ( )t T

t T TP i t vT

+= ∫ t dt (2.1)

Où iT2 et vT2 sont le courant et la tension du composant sous test,

T la durée d’impulsion.

Figure2.10 Signaux idéalisés sur T1 et T2

Wei MI


59


Evaluons la puissance dissipée dans le MOS IRF740 sur un cycle.

Avec la condition de fonctionnement : durée de l’impulsion ton=40 µs, période de

signal T = 20ms, tension maximale VR=300V, résistance de charge Rc = 10Ω, tension de

grille Vg=15V. Nous obtenons le courant

2300 3010

RT

C

VI AR

= =∼ (2.2)

La tension à l’état passant VT2ON pour l’IRF740 dans la condition ci-dessus est

égale à 25V, qui correspond à un courant 3 fois supérieur au courant nominal.

Donc, la puissance moyenne des pertes des IRF740

2 2 240 1,5( )20T T T ON

sP I V Wmsµ= × × = (2.3)

provoque une augmentation d’environ 1,5°C, d’après l’impédence thermique

transitoire fournie par les données constructeurs. Cela est donc très raisonable.

Dans la figure 2.10, tm est le point de mesure. Le logiciel nous permet de régler tm,

pour une plage de 80% à 90% du temps de conduction. Pour des valeurs de tm inférieur,

le courant iD n’est pas stable à cause de la phase transitoire dans T1 qui se sature, donc la

mesure serait erronée. Si on fait varier la tension E, on peut obtenir différentes valeurs

pour ID_on et VDS_on, ainsi on obtient la courbe de caractéristique statique à VGS fixée.

2.4.2 Logiciel

La figure 2.11 montre le flot du logiciel. Le fonctionnement ″Level 50%″ sert à

stabiliser les courbes électriques échantillonnées. De même, pour obtenir la mesure plus

précise, avant extraire les valeurs ID_on et VDS_on, on utilise une technique de

calibration, qui permet de régler la sensibilité optimale de l’amplificateur d’entrée de

l’oscilloscope.

2.4.3 Résultats Après avoir obtenu les caractéristiques statiques, on compare les résultats avec

ceux du traceur 371A. Dans les figures 2.12. et 2.13, on montre les résultats pour le

MOSFET IRF740 et l‘IGBT BUP202. On remarque que les différences sont petites

lorsque la tension de grille est petite. En revanche, l’écart augmente lorsque la tension

de grille augmente. Dans ces conditions, l’influence de l’auto-échauffement dans le

composant sous test est plus importante pour le traceur par rapport à notre méthode.

Cela montre l’intérêt du banc que nous avons développé.

Wei MI


60


Figure 2.11 Flot du logiciel de l’acquisition des caractéristiques statiques

Figure 2.12 Comparaison de charactristique statique mesuré par

deux moyens pour l’IGBT BUP202

Wei MI


61


Figure 2.13 Comparaison de charactristique statique mesuré par

deux moyens pour le MOS IRF740

2.5 Conclusion

Pour atteindre notre objectif de l’extraction de paramètres et de la determination

du domaine de validité, deux aspects de la caractérisation étaient exposées dans ce

chapitre: materiel et logiciel.

Nous avons montré l’exploitation des signaux simulés et mesurés, et nous avons

conçu un système de mesure automatique. Le langage objet orienté, JAVA, a été choisi

pour sa portabilité et sa pérenité pour réaliser le logiciel.

Nous avons donc maintenant les briques de base, logicielles et materielles pour

obtenir des caractristiques simulées et mesurées et les comparer par des analyses des

paramètres transistoires: ceux définis au chapitre 1.

Wei MI


62

Documents

Chapitre 2 automatisation de l'exploitation des résultats ...csidoc.insa-lyon.fr/these/2002/mi/chap2.pdf · Extraction des paramètres et domaine de validité du modèle d’un composant