These Lacombe 2007

INSTITUT NATIONAL POLYTECHNIQUE DE GRENOBLE
N attribu par la bibliothque

|__|__|__|__|__|__|__|__|__|__|
T H E S E
pour obtenir le grade de
DOCTEUR DE LINP Grenoble
Spcialit : Gnie Electrique
prpare au Laboratoire de Gnie Electrique de Grenoble
dans le cadre de
lEcole Doctorale Electronique Electrotechnique Automatique Tlcommunication Signal
prsente et soutenue publiquement
par
Guillaume Lacombe
Le 29 Novembre 2007
Dfinition et ralisation dune nouvelle gnration de logiciel
pour la conception des moteurs du futur
DIRECTEUR DE THESE Albert Foggia
CO-DIRECTEUR DE THESE Yves Marechal
JURY
M. Georges Barakat , Prsident
M. Guy Friedrich , Rapporteur
M. Pascal Brochet , Rapporteur
M. Albert Foggia , Directeur de thse
M. Yves Marechal , Co-directeur de thse
M. Jean-Claude Mipo , Examinateur
M. Xavier Brunotte , Examinateur
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Table des matires
Introduction 1
I Dnition des exigences du mtier moteur 3
1 Analyse de la dmarche du concepteur 4
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Les outils dans la dmarche de conception . . . . . . . . . . . . . . . . 4
1.2.1 Les contours de lanalyse . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Les outils analytiques et le prdimensionnement . . . . . . . . 5
1.2.3 Les outils lments nis et le dimensionnement . . . . . . . . . 7
1.2.4 Loptimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Les besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.1 Dmocratiser les mthodes numriques . . . . . . . . . . . . . . 8
1.3.2 Faciliter la communication entre les dirents outils . . . . . . 9
1.3.3 Vers la capitalisation de la dmarche de conception . . . . . . . 11
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Objectif de lapplication moteur 13
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Amener la connaissance du mtier moteur dans Flux . . . . . . . . . . 13
2.2.1 La gomtrie et le maillage . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Les algorithmes mtiers . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3 Les essais normaliss . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.4 La communication . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Dvelopper une nouvelle plateforme ddie moteur . . . . . . . . . . . 15
2.3.1 Une plateforme multi-projets . . . . . . . . . . . . . . . . . . . 15
2.3.2 Une plateforme multi-outils . . . . . . . . . . . . . . . . . . . . 15
2.3.3 Notre vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Organisation du travail de thse . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1 Des bibliothques gomtriques de moteurs dans Flux . . . . . 17
2.4.2 Etendre les bibliothques la notion de laboratoire virtuel . . 17
2.4.3 Dveloppement dune nouvelle plateforme multi-projet pour la
conception des moteurs . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
i
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
TABLE DES MATIRES ii
3 La dnition des moteurs 19
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Les topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1 Les rotors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2 Les stators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.3 Des paramtres spciques . . . . . . . . . . . . . . . . . . . . 21
3.3 Les mthodes de bobinage . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1 Le bobinage imbriqu par ple . . . . . . . . . . . . . . . . . . 24
3.3.2 Le bobinage concentrique par ple . . . . . . . . . . . . . . . . 24
3.3.3 Le bobinage pas fractionnaire . . . . . . . . . . . . . . . . . . 24
3.3.4 La dnition des spires . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.5 La dnition des ttes de bobines [19] . . . . . . . . . . . . . . 25
3.3.6 La dnition de lanneau de court-circuit . . . . . . . . . . . . 32
3.4 Les matriaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.1 Stator et rotor . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.2 Aimants rotor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.3 Cage dcureuil . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4 La caractrisation des moteurs 36
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Les moteurs brushless aimants permanents . . . . . . . . . . . . . . 36
4.2.1 Les moteurs BDC . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.2 Les PMSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 La gneration de composants systme . . . . . . . . . . . . . . . . . . 38
4.3.1 Le modle par phase . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.2 Le modle dans la transformation de Park . . . . . . . . . . . . 40
4.3.3 La prise en compte damortisseurs . . . . . . . . . . . . . . . . 44
4.4 Les essais normaliss . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.1 Lessai vide . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.2 Le couple de dtente . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4.3 Lanalyse statique . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.4 Lessai en charge . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4.5 Lessai sans rotor . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.6 Lessai frquentiel . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4.7 Lessai de court-circuit . . . . . . . . . . . . . . . . . . . . . . . 65
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
II Concepts informatiques et implmentation logicielle 67
5 Modliser un mtier 68
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2 La FluxFactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2.2 La description du modle de donnes . . . . . . . . . . . . . . . 70
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
TABLE DES MATIRES iii
5.2.3 La description du modle de prsentation . . . . . . . . . . . . 73
5.2.4 La machine virtuelle . . . . . . . . . . . . . . . . . . . . . . . . 75
5.3 Les bibliothques mtier . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.3.1 Surcharger le modle du logiciel Flux . . . . . . . . . . . . . . . 76
5.3.2 Implmenter ce modle dans le language de commande de Flux 78
5.3.3 Un gnrateur de bibliothques mtiers : XBuilder . . . . . . . 84
5.3.4 Sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6 Modliser le mtier moteur dans Flux 86
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.2 Le modle UML des moteurs aimants . . . . . . . . . . . . . . . . . 86
6.2.1 Lentit moteur . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.2.2 Les topologies rotor . . . . . . . . . . . . . . . . . . . . . . . . 87
6.2.3 Les topologies stator . . . . . . . . . . . . . . . . . . . . . . . . 88
6.3 Le modle UML du bobinage . . . . . . . . . . . . . . . . . . . . . . . 90
6.3.1 Les types de bobinages . . . . . . . . . . . . . . . . . . . . . . . 90
6.3.2 Les modles de ttes de bobines . . . . . . . . . . . . . . . . . . 90
6.4 Le modle UML des matriaux . . . . . . . . . . . . . . . . . . . . . . 90
6.4.1 Le cuivre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.4.2 Les matriaux rotor et stator . . . . . . . . . . . . . . . . . . . 92
6.4.3 Les aimants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.4.4 LIHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.4.5 Les templates Python . . . . . . . . . . . . . . . . . . . . . . . 96
6.5 Le modle UML des essais normaliss . . . . . . . . . . . . . . . . . . 96
6.6 Les autres moteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7 Lapplication moteur 102
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.2 Le modle de lapplication . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.3 Larchitecture Client/Serveur . . . . . . . . . . . . . . . . . . . . . . . 103
7.4 La gestion transparente des chiers . . . . . . . . . . . . . . . . . . . . 106
7.5 Les rapports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.6 Exemple dutilisation de FluxMotor . . . . . . . . . . . . . . . . . . . 108
7.6.1 La gomtrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.6.2 Les matriaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.6.3 Les tudes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8 Autres exemples de bibliothques mtier 118
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.2 Les actionneurs linaires . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.3 Le contrle non destructif . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
TABLE DES MATIRES iv
Conclusion 123
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Table des gures
1.1 Logiciel Speed : Mthodes analytiques pour le prdimensionnement de
la partie magntique de la machine . . . . . . . . . . . . . . . . . . . . 5
1.2 Dnition mtier dun moteur sous MotorCAD . . . . . . . . . . . . . 6
1.3 Schma thermique quivalent au moteur propos dans MotorCAD (fonc-
tion des paramtres mtiers) . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Logiciel Flux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 GOT : General Optimisation Tools . . . . . . . . . . . . . . . . . . . . 8
1.6 Simulation de la commande dune machine asynchrone dans le logiciel
Portunus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.7 Commande et modle lments nis dun moteur reluctance variable 11
1.8 Amesim : Logiciel de simulation systme . . . . . . . . . . . . . . . . . 12
3.1 FluxSkewed propose deux mthodes pour linclinaison du rotor ou du
stator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Les topologies de rotor dans la bibliothque de moteur sans balais
aimants permanents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 les topologies de stator dans les bibliothques moteur . . . . . . . . . . 21
3.4 Bobinage imbriqu par ple 1 couche - Phase 1 - Moteur 24 encoches
et 2 ples - Pas du bobinage : 10 - Nombre de bobines par ples : 2 . . 26
3.5 Bobinage imbriqu par ple 1 couche - Les 3 phases - Moteur 24
encoches et 2 ples - Pas du bobinage : 10 - Nombre de bobines par
ples : 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6 Bobinage concentrique par ple 1 couche - Phase 1 - Moteur 24
encoches et 2 ples - Pas du bobinage : 11 - Nombre de bobines par
ples : 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7 Bobinage concentrique par ple 1 couche - Les 3 phases - Moteur
24 encoches et 2 ples - Pas du bobinage : 11 - Nombre de bobines par
ples : 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.8 Bobinage imbriqu par ple 2 couches - Phase 1 - Moteur 24 encoches
et 4 ples - Pas du bobinage : 5 - Nombre de bobines par ples : 2 . . 28
3.9 Bobinage imbriqu par ple 2 couches - Les 3 phases - Moteur 24
encoches et 4 ples - Pas du bobinage : 5 - Nombre de bobines par ples : 2 28
3.10 Bobinage pas fractionnaire - Phase 1 - Moteur 21 encoches et 4 ples
- Pas du bobinage : 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
v
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
TABLE DES FIGURES vi
3.11 Bobinage pas fractionnaire - Les 3 phases - Moteur 21 encoches et
4 ples - Pas du bobinage : 5 - Oset : 7 . . . . . . . . . . . . . . . . . 29
3.12 Dnition de la section des spires . . . . . . . . . . . . . . . . . . . . . 30
3.13 Reprsentation 3D des ttes de bobines . . . . . . . . . . . . . . . . . 32
3.14 Paramtrage de lanneau . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.15 Modle isotrope analytique avec contrle du coude . . . . . . . . . . . 33
3.16 Modle points par points . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1 Formes des courants et des tensions vide dans un moteur BDC . . . 37
4.2 Exemple dun rotor de moteur BDC . . . . . . . . . . . . . . . . . . . 37
4.3 Diagramme vectoriel du fonctionnement dun PMSM . . . . . . . . . . 38
4.4 Modle quivalent par phase . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5 Inductances propres et mutuelles dans un moteur ples saillants . . 41
4.6 Axes d et q du rotor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.7 Modle quivalent dans la transformation de Park . . . . . . . . . . . 43
4.8 Couple dans le modle de Park . . . . . . . . . . . . . . . . . . . . . . 44
4.9 Exemple de rotor avec cage dcureuil . . . . . . . . . . . . . . . . . . 44
4.10 Modle quivalent avec prise en compte des amortisseurs . . . . . . . . 45
4.11 Courbes des forces lectro-motrices . . . . . . . . . . . . . . . . . . . . 47
4.12 Courbe du couple de dtente . . . . . . . . . . . . . . . . . . . . . . . 48
4.13 Courbe de linduction dans lentrefer . . . . . . . . . . . . . . . . . . . 49
4.14 Dgrads de B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.15 Courbe du couple en fonction de lavance angulaire (
lec) de linduction
statorique sur le rotor . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.16 Courbe couple(courant) pour ,=120
c|cc . . . . . . . . . . . . . . . . 52
4.17 Courbes des inductances synchrones en fonction du courant pour ,=120
c|cc 52
4.18 Courbes des inductances dynamiques en fonction du courant pour ,=120
c|cc 52
4.19 Courbe couple(vitesse) pour des angles de pilotage infrieurs langle
de couple maximal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.20 Courbe couple(vitesse) pour des angles de pilotages suprieurs langle
de couple maximal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.21 Courbe couple(vitesse) avec duxage . . . . . . . . . . . . . . . . . . 54
4.22 Evolution de langle de pilotage en fonction de la vitesse pour duxage 55
4.23 Ondulations de couple obtenues lors dun essai en charge 1000 tr/min
avec courants idaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.24 Couplage circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.25 Intervalles de conductions des transistors en BDC . . . . . . . . . . . . 57
4.26 Rgulation par bande dhystrsis . . . . . . . . . . . . . . . . . . . . . 57
4.27 C120-Q1 : Les trois transistors du haut commutent pendant 120
c|cc
chacun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.28 Tous les transistors commutent pendant les 60 premiers degrs de leur
intervalle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.29 Les 6 vecteurs commands . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.30 Intervals de conduction des transitors en PMSM . . . . . . . . . . . . 60
4.31 Module de linductance oprationnelle daxe directe . . . . . . . . . . . 64
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
TABLE DES FIGURES vii
5.1 Le modle dun logiciel : description et excution avec les composants
de la FluxFactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2 Visualisation du diagramme UML dans FluxBuilder . . . . . . . . . . 70
5.3 Lentit rotor et ses attributs . . . . . . . . . . . . . . . . . . . . . . . 71
5.4 Lhritage UML pour modliser les direntes topologies . . . . . . . . 72
5.5 La mthode mesh() dans lentit moteur . . . . . . . . . . . . . . . . . 73
5.6 Bote de cration dun moteur gnre par la FluxCore partir du
modle de la Figure 5.4 . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.7 Commande python de cration dun moteur, base sur le modle de la
Figure 5.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.8 Composition de lIHM dans les logiciels de la FluxFactory. (Exemple
avec Flux) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.9 Rutilisabilit du FluxCore pour les logiciels Flux . . . . . . . . . . . . 77
5.10 Schma de principe du chargement dune extension dans la FluxFactory 78
5.11 Commande permettant de charger un contexte mtier dans Flux . . . 79
5.12 Interface ddie ltude des moteurs dans Flux . . . . . . . . . . . . 79
5.13 Template python gnre . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.14 Exemple de code dune mthode check . . . . . . . . . . . . . . . . . . 81
5.15 Exemple de code de la mthode build . . . . . . . . . . . . . . . . . . 82
5.16 Exemple de code de la mthode delete . . . . . . . . . . . . . . . . . . 83
5.17 Exemple de code de la mthode modify . . . . . . . . . . . . . . . . . 83
5.18 XBuilder : Dnition du modle de donnes et des templates python
dun contexte mtier . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1 Lentit moteur et ses attributs dans le modle de la BPM Overlay . . 87
6.2 La classication des topologies rotor dans le modle UML (4 reprsen-
tes, 36 en ralit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.3 Diagramme UML de la dnition des stators . . . . . . . . . . . . . . 89
6.4 Modle UML du bobinage dans la BPM Overlay . . . . . . . . . . . . 91
6.5 Modle UML du matriau cuivre . . . . . . . . . . . . . . . . . . . . . 92
6.6 Modle UML des matriaux de la carcasse rotor et stator . . . . . . . 93
6.7 Arbre de lextension BPM Overlay . . . . . . . . . . . . . . . . . . . . 94
6.8 Bote de dialogue de dnition dun moteur sans balais aimants . . . 95
6.9 Modles des essais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.10 Modle des rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.11 Lancement du calcul dun essai sans bobinage - Modlisation des rsul-
tats dans larbre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.12 Synthse des bibliothques moteur dveloppes . . . . . . . . . . . . . 99
6.13 Dnition dune machine asynchrone . . . . . . . . . . . . . . . . . . . 100
6.14 Exemple de machine asynchrone gnre dans Flux . . . . . . . . . . . 100
7.1 Reprsentation du bobinage sur la gomtrie du moteur . . . . . . . . 103
7.2 Reprsentation panoramique du bobinage . . . . . . . . . . . . . . . . 103
7.3 Principe du pilotage de Flux par FluxMotor . . . . . . . . . . . . . . . 104
7.4 Architecture modulaire du logiciel Flux . . . . . . . . . . . . . . . . . 106
7.5 Pilotage du logiciel Flux par FluxMotor . . . . . . . . . . . . . . . . . 107
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
TABLE DES FIGURES viii
7.6 Construction de la gomtrie dun moteur dans Flux et dans FluxMotor 109
7.7 Dnition mtier du moteur brushless rotor extrieur aimants droits 110
7.8 Dnition mtier du moteur brushless rotor extrieur aimantation
radiale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.9 Dnition dun matriau magntique pour les carcasses rotor et/ou sta-
tor dans FluxMotor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.10 Dnition dun essai vide dans FluxMotor . . . . . . . . . . . . . . . 112
7.11 Denition de lessai en charge dans FluxMotor . . . . . . . . . . . . . 112
7.12 Comparaison des fem du moteur aimants droits et du moteur aimants
courbes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7.13 Ondulations de couple obtenues par les moteurs lors dun essai en charge
avec alimentation en crneaux . . . . . . . . . . . . . . . . . . . . . . . 114
7.14 Ondulations de couple obtenues par les moteurs lors dun essai en charge
avec alimentation en courants sinusodaux . . . . . . . . . . . . . . . . 114
7.15 Comparaison des ondulations de couple obtenues pendant les deux essais115
7.16 Visualisation des dgrads de B lors de lessai en charge . . . . . . . . 115
7.17 Dnition dun essai en charge dans Flux et FluxMotor . . . . . . . . 116
8.1 Contexte ddi ltude des actionneurs linaires . . . . . . . . . . . . 119
8.2 Dnition dun capteur (Correspond au modle UML de la gure 8.4) 120
8.3 Une sonde avec une bobine emmettrice et une bobine rceptrice sur le
dfaut dune plaque . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
8.4 Partie du modle du contexte ddi au contrle non destructif (Modles
dun capteur) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Liste des tableaux
2.1 Couplage circuit pour lalimentation des phases . . . . . . . . . . . . . 14
3.1 Bobinage deux couches : Positionnnement dans lencoche adjacente
ou superpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1 Exemples de rotor de PMSM . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Hypothses et paramtres du modle par phase . . . . . . . . . . . . . 40
4.3 Hypothses et paramtres du modle dans la transformation de Park . 44
4.4 Hypothses et paramtres du modle avec prise en compte des amortis-
seurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5 Paramtres et rsultats de lessai vide . . . . . . . . . . . . . . . . . 48
4.6 Paramtres et rsultats de ltude du couple de dtente . . . . . . . . 49
4.7 Paramtres et rsultats de lessai de couple statique . . . . . . . . . . 55
4.8 Paramtres et rsultats de lessai en charge . . . . . . . . . . . . . . . 61
4.9 Essai sans rotor - Dgrad de B et lignes de champ . . . . . . . . . . . 61
4.10 Paramtres et rsultats de lessai sans rotor . . . . . . . . . . . . . . . 61
4.11 Paramtres et rsultats de lessai frquentiel . . . . . . . . . . . . . . . 64
5.1 Lattribut rotor de type entit : Association et aggregation . . . . . . . 71
6.1 Exemple de moteur BPM cr dans le contexte mtier . . . . . . . . . 95
ix
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Introduction
Les logiciels Flux, 2D et 3D, sont des logiciels de modlisation des phnomnes
lectromagntiques en deux et trois dimensions par la mthode des lments nis. Ils
sont destins au domaine du gnie lectrique pour la conception et la modlisation
de dispositifs trs varis comme les moteurs lectriques, les actionneurs, les transfor-
mateurs, le chauage par induction ou le contrle non destructif pour nen citer que
quelques uns. Leur large ventail dutilisation permet dtudier aussi bien la tte de
lecture dun enregistreur magntique que la signature magntique dun porte-avions.
Ils sont utiliss de par le monde (Europe, Etats-Unis et Asie du sud-est) par un millier
de socits et duniversits. Ces logiciels sont co-dvelopps par la socit Cedrat et le
laboratoire de gnie lectrique de Grenoble (G2ELab) et commercialiss par le groupe
Cedrat.
En 2000, Cedrat a entrepris la refonte complte de ces logiciels pour porter son
interface au niveau des standards en la matire. De plus, on a constat que les log-
icels Flux sont essentiellement utiliss par des experts dans les centres de recherche
et dveloppement et les laboratoires de recherche. Or une tendance lourde est lu-
tilisation des outils de simulation dans les bureaux dtude, condition quils soient
simples dutilisation et ddis au mtier des utilisateurs. Ainsi en 2003, Cedrat et le
G2ELab entament un programme de recherche visant dvelopper une plateforme per-
mettant la refonte des logiciels Flux, lamlioration des processus de dveloppement de
tous les logiciels de la socit Cedrat et la capacit dcliner les logiciels gnralistes
Flux, de manire dvelopper rapidement des logiciels ddis un mtier. Ce projet
a notamment t port par la thse de Yves Souchard intitule "Ralisation dune
plateforme informatique ddie au mtier du gnie lectrique autour des logiciels Flux.
Application la ralisation de logiciels mtiers" soutenue en 2005 [31].
Lapplication machine lectrique est trs prsente dans le domaine de la simulation
en gnie lectrique (A titre dexemple, elle reprsente prs de 30% du chire daaires
de Cedrat et 50% des ventes Flux). Elle se dveloppe de plus en plus dans lautomobile
(4% par an et promotion des voitures hybrides) et dans laronautique (pour diminuer
les cots oprationnels des actionneurs hydrauliques actuels). De plus, avec les r-
centes politiques nergtiques menes par la commission europenne, laugmentation
du rendement des machines lectriques, qui reprsentent 65 70% de la consommation
lectrique dans lindustrie, devient un enjeu majeur.
1
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
INTRODUCTION 2
Pour la conception de machines haut rendement, lutilisation doutils de simu-
lation puissants, permettant un dimensionnement n, est donc renforce. Cependant,
pour tre utiliss par un plus grand nombre, ces outils doivent tre plus simple dac-
cs et doivent mieux sinscrire dans la dmarche de conception. Ils doivent permettre
dobtenir rapidement les rsultats attendus et tre automatisables de manire pou-
voir dnir plus facilement des processus de dimensionnement ou doptimisation. Cest
pourquoi, dans ce contexte et dans la poursuite des travaux mens sur larchitecture
des logiciels Flux, nous proposons de dvelopper une dmarche de personnalisation des
logiciels Flux au mtier des machines lectriques. Ce travail a pour objectif damliorer
et de capitaliser notre comprhension du mtier de la conception des machines lec-
triques. Ceci an de mieux rpondre aux besoins des concepteurs et de spcier et
dvelopper un nouveau logiciel ddi. Dun point de vue gnie logiciel, ce travail doit
galement permettre de consolider la dmarche de personnalisation des logiciels Flux
un mtier an quelle garantisse une bonne volutivit du logiciel que nous allons
dvelopper et quelle soit reproductible pour dautres mtiers.
Puisque le projet demande de travailler deux aspects (lassimilation du mtier mo-
teur et la ralisation logicielle), jai choisi de dvelopper ce mmoire en deux parties.
Dans la premire partie, partir dune analyse des outils de simulation pour la concep-
tion des machines lectriques, je dnirai les fonctionnalits auxquelles le logiciel devra
rpondre. On peut donc assimiler cette partie la dnition ou la spcication du logi-
ciel. Elle est plutt ddie aux utilisateurs ou aux concepteurs de moteurs. La seconde
partie portera plus particulirement sur limplmentation logicielle. Je mintresserai
notamment aux concepts informatiques lis la personnalisation des logiciels gnra-
listes Flux en logiciels mtiers. La stratgie dveloppe dans la plateforme existante et
les nouvelles fonctionnalits qui ont t mises en place pour faciliter et dmocratiser
cette dmarche de personnalisation seront prsents. Enn je montrerai comment ces
outils ont t utiliss pour dvelopper le logiciel que nous appelerons FluxMotor.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Premire partie
Dnition des exigences du
mtier moteur
3
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Chapitre 1
Analyse de la dmarche du
concepteur
1.1 Introduction
An de mieux apprhender les attentes et les besoins pour la conception des ma-
chines lectriques, je propose de commencer ce mmoire par une analyse de la dmarche
du concepteur. Je prsenterai dans ce premier chapitre les dirents outils ou logiciels
utiliss. Jidentierai les atouts et les limitations de chacun deux an de dgager les
fonctionnalits ou les volutions que nous dvelopperons dans les logiciels Flux an
quils soient plus e!caces.
1.2 Les outils dans la dmarche de conception
1.2.1 Les contours de lanalyse
Avant tout, nous commencerons par dnir les contours du domaine de concep-
tion. En eet, le dimensionnement dun moteur comporte de nombreuses contraintes
et fait intervenir plusieurs domaines de la physique (lectromagntisme, thermique,
mcanique, lectronique). Au vu du domaine dapplication de Flux, nous limiterons
ici notre analyse la conception de la partie magntique du moteur. Nous prendrons
cependant en compte :
La temprature pour les rsistances des phases
La charge mcanique
La commande, limite de simples rgulations en courant ou en tension
La prise en compte des besoins de la conception largie sera aborde au travers de
la communication avec :
Les logiciels bass sur des mthodes analytiques pour le prdimensionnement
magntique et thermique
Les logiciels pour la conception de la commande ou la simulation systme
4
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
1. Analyse de la dmarche du concepteur 5
1.2.2 Les outils analytiques et le prdimensionnement
Fruits dannes dexprience des concepteurs, les outils analytiques capitalisent
des topologies et des mthodologies propres au mtier des machines lectriques. Ils ont
souvent une IHM (Interface Homme Machine) ddie et la prise en main est trs rapide.
Ces outils sont souvent bass sur des rseaux de reluctances pour la partie magntique.
Les calculs sont trs rapides, ce qui rend ces outils idaux pour le prdimensionnement
et le choix de structures. Cest le cas du logiciel SPEED [42] dvelopp par le SPEED
Laboratory Glasgow et commercialis par le groupe Cedrat (Figure 1.1).
Fig. 1.1 Logiciel Speed : Mthodes analytiques pour le prdimensionnement de la
partie magntique de la machine
Laspect thermique est un lment essentiel dans le processus de conception des ma-
chines. Laugmentation de la temprature entrane une augmentation des rsistances
des phases et une diminution de linduction rmanente des aimants. Elle a donc un
impact important sur les performances de la machine. Le logiciel MotorCAD [43] est
un logiciel ddi ltude thermique des machines tournantes. Il est dvelopp par
la socit MotorDesign Shropshire (Angleterre) et est galement commercialis par
le groupe Cedrat. Il est bas sur des rseaux de sources et de rsistances thermiques
qui permettent de dterminer rapidement lvolution de la temprature dans les dif-
frentes parties de la machine suite un fonctionnement en charge ou des impulsions
de courant. Il permet de dcrire de nombreux systmes de refroidissement (ailettes,
ventilations, refroidissement par coulements, ...). Il permet galement de raliser des
tudes de sensibilit sur les dirents paramtres.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 1.2 Dnition mtier dun moteur sous MotorCAD
Fig. 1.3 Schma thermique quivalent au moteur propos dans MotorCAD (fonction
des paramtres mtiers)
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
1.2.3 Les outils lments nis et le dimensionnement
Lutilisation des lments nis en lectrotechnique sest impose grce son apti-
tude rsoudre les quations de Maxwell dans des domaines de forme complexe. Elle
permet la rsolution de problmes statiques, transitoires (pas pas dans le temps)
et harmoniques ; les signaux sont supposs sinusodaux et on utilise les nombres com-
plexes. En transitoire et en harmonique, on peut coupler les lments nis de la
mcanique et associer un circuit lectrique.
Les rsultats sont prcis mais le temps de calcul est long (mme sil a beaucoup
diminu particulirement en 2D). De plus lIHM est souvent gnraliste, ce qui rend
beaucoup plus longue la dnition du calcul. Pour toutes ces raisons, les lments nis
sont plutt utiliss pour la conception de nouvelles structures, le dimensionnement
n, la caractrisation des schmas de reluctances ou la caractrisation des schmas
quivalents.
Fig. 1.4 Logiciel Flux
1.2.4 Loptimisation
De plus en plus, les concepteurs se tournent vers loptimisation. De nouvelles tech-
niques doptimisation (plan dexprience, surface de rponse, ...) permettent main-
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
tenant de raliser des optimisations utilisant les outils numriques [26] [27] [28] [29].
Mais ces techniques sont encore rserves des utilisateurs expriments.
Loptimisation intervient dans des phases de prdimensionnement ( les outils analy-
tiques trs rapides permettent dexplorer de nombreuses structures) et dans des phases
de dimensionnement n avec les outils lments nis. Le logiciel GOT dvelopp au
G2ELab et qui fait partie de la suite logicielle Flux capitalise lensemble de ces tech-
niques doptimisation.
Fig. 1.5 GOT : General Optimisation Tools
1.3 Les besoins
1.3.1 Dmocratiser les mthodes numriques
Dnir la gomtrie, le maillage et la physique dun moteur dans un logiciel gnral-
iste peut paratre long pour le concepteur. Il doit comprendre les concepts de modli-
sation du logiciel gnraliste et les utiliser pour traduire son mtier. Cette complexit
demande souvent de la formation et limite lutilisation des mthodes numriques. En
eet les concepteurs cherchent souvent vrier le rsultat de leur prdimensionnement
avec des calculs par la mthode des lments nis parce quils sont plus prcis. Cepen-
dant leur utilisation parat parfois trop onreuse pour rpondre un appel dores par
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
exemple. Les concepteurs prfrent donc, gnralement, utiliser des outils ddis plus
rapides.
Pourtant lorsquon utilise les lments nis, les tudes ralises dans un domaine
dactivit sont sensiblement les mmes. La saisie rptitive des donnes relative
une tude peut paratre une perte de temps. Des topologies de moteur et des tudes
classiques pourraient tre automatises partir de concepts mtier comme dans les
logiciels bass sur les mthodes analytiques.
1.3.2 Faciliter la communication entre les dirents outils
Les couplages entre les dirents outils utiliss lors de la conception facilitent la
vie du concepteur et vitent les erreurs. Pour les mettre en place, il est important de
partager les mmes paramtres.
Communication avec les outils analytiques
Lanalyse des outils du concepteur de machines tournantes montre que les m-
thodes analytiques et numriques sont complmentaires. Les outils analytiques sont
trs utiliss en phase de prdimensionnement. Les calculs lments nis sont souvent
ncessaires pour vrier la vracit des rsultats. Il est donc souhaitable de faciliter la
communication entre ces outils. Par exemple, limport dun moteur SPEED dans Flux
permettrait dautomatiser le passage du prdimensionnement au dimensionnement et
faciliterait laccs aux lments nis.
Couplage et cosimulation avec les logiciels de llectronique
Une fois le dimensionnement magntique de la machine eectu, les concepteurs
ralisent ensuite le dimensionnement de la commande. Pour cela ils utilisent souvent un
schma quivalent de la machine. Les paramtres de ces modles peuvent tre calculs
avec Flux pour tre ensuite utiliss par le concepteur de la commande. Cependant
les concepteurs de la commande ne sont pas toujours familis avec les outils lments
nis et les mthodes danalyse des machines lectriques permettant didentier ces
schmas. Nous pourrions donc proposer une fonctionnalit permettant dautomatiser,
partir de calculs Flux, la cration de composants informatiques, reprsentants le
schma quivalent et qui soient directement utilisables par le logiciel de la commande.
Le logiciel Portunus [41] par exemple permet de dimensionner la commande et pro-
pose une bibliothque de modles quivalents dactionneurs. Ce logiciel est dvelopp
en Allemagne par la socit Adapted Solutions. Ce logiciel sera bientt en mesure
dutiliser des composants au format VHDL-AMS (Very High Speed Integrated Hard-
ware Description Lanaguage - Analog and Mixed System) [39]. Nous pourrons donc
proposer dans Flux la gnration de composants au format VHDL-AMS representant
un schma lectrique quivalent au moteur.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 1.6 Simulation de la commande dune machine asynchrone dans le logiciel
Portunus
La commande a un impact important sur les performances relles de la machine.
Nous souhaitons donc galement crer des composants informatiques directement util-
isables dans un logiciel comme Portunus ou Simulink permettant de la simulation
simultane avec Flux (co-simulation). Ceci permettrait de voir comment la commande
se comporte non plus face un comportement de machine approximatif (schma quiv-
alent) mais de manire plus ne. De plus, alimenter le systme lments nis avec les
signaux de la commande permet davoir une vue plus raliste du taux dharmoniques
des courants et des tensions et ainsi avoir une meilleure estimation des performances de
la machine, notamment au niveau des pertes fer par exemple (qui dpendent du spec-
tre frquentiel). Un module de co-simulation entre Flux2D et Simulink existe. Notre
logiciel pourrait donc crer un composant Simulink.
Couplage avec la simulation systme
La simulation systme cherche prendre en compte le moteur dans son environ-
nement plus complet : dissipation de la chaleur, modlisation du rducteur et de la
transmission mcanique (Figure 1.8). Les schmas quivalents de machines sont gale-
ment utiliss et les concepteurs systmes, qui ne sont pas spcialiss dans lanalyse
lments nis des moteurs, rencontrent la mme di!cult dterminer les paramtres
des schmas quivalents des moteurs quils choisissent. Des sujets de ce type existent
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 1.7 Commande et modle lments nis dun moteur reluctance variable
comme par exemple le projet RNTL appel C6E2 dans lequel Cedrat participe avec
la socit LMS-Imagine qui dveloppe le logiciel Amesim (Simulation Systme). Ce
projet vise pour Cedrat coupler le logiciel Flux avec le logiciel Amesim de manire
proposer un assistant pour le calcul des paramtres des schmas quivalents.
Communication avec les outils hors conception
Enn on peut citer galement la communication avec les autres outils de la socit
du concepteur. Cest la notion de PLM (Product Life Management) qui permet no-
tamment de garder les rsultats des calculs raliss lors du processus de conception.
Ceci demande une bonne structuration des donnes du mtier.
1.3.3 Vers la capitalisation de la dmarche de conception
Capitaliser les tudes ralises lors dun projet de conception nest pas simple
aujourdhui, et les utilisateurs sont parfois amens reproduire des simulations quils
ont dj ralises lors dune conception ou dune tude antrieure. Lutilisateur doit
grer un chier par tude ou par type de calcul dans les logiciels. Une approche mtier
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 1.8 Amesim : Logiciel de simulation systme
permet de reproduire rapidement les calculs ; cependant il convient de se poser la
question de la capitalisation.
Il pourrait tre interessant pour le concepteur de pouvoir :
Visualiser et conserver les voies explores et ainsi formaliser son exprience
Rendre compte plus facilement du travail eectu (rapports automatiques, arbre
de conception, ...)
Ceci permettrait la socit de :
Formaliser la dmarche dun concepteur, son exprience et sa connaissance mtier
Capitaliser lhistorique dune conception, dune aaire donne
1.4 Conclusion
Notre analyse des outils du concepteur montre que le logiciel Flux est particulire-
ment bien adapt pour la conception de nouvelles structures de machines. Il est gale-
ment trs utilis pour vrier les rsultats du prdimensionnemnt et pour raliser un di-
mensionnement n, notamment grce sa capacit raliser des tudes paramtriques
(tudes de sensibilit sur les paramtres du moteur). Larrive de nouvelles techniques
doptimisation renforce dailleurs ce dernier point.
Cependant son utilisation est lourde et donc cote cher aux concepteurs. Il en
dcoule que lapproche mtier propose par les outils analytiques fait dfaut dans les
logiciels Flux. Enn, en partageant les mmes paramtres que les autres outils mtier,
Flux pourrait mieux sinsrer dans le processus de conception.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Chapitre 2
Objectif de lapplication moteur
2.1 Introduction
Dans le chapitre prcdent, des fonctionnalits qui permettraient de mieux adapter
le logiciel Flux la conception des machines lectriques ont t identies. Dans ce
chapitre, je prsenterai les dveloppements que nous avons dcid dentreprendre pour
rpondre ces besoins et la faon dont notre travail sest organis.
2.2 Amener la connaissance du mtier moteur dans Flux
Le premier besoin identi est dintroduire dans Flux une approche mtier. Cest
pourquoi nous voulons dvelopper une interface ddie ltude des moteurs. Lobjectif
de cette nouvelle interface est de simplier la dnition dun moteur dans Flux. De
plus, les tudes danalyse des machines lectriques souvent ralises par les concepteurs
seront proposes et automatises.
2.2.1 La gomtrie et le maillage
Dans une utilisation classique du logiciel Flux, la dnition de la gomtrie dun
moteur passe par la dnition des coordonnes des points, la dnition des lignes et des
densits de maillage. Dans lapproche mtier, nous proposons des topologies de moteur
classiques permettant dautomatiser la construction de la gomtrie et du maillage
partir de quelques paramtres mtiers. Ceci a lavantage dacclrer considrablement
le pr-processing et de masquer les notions lies aux lments nis puisque le maillage
est automatis. Cette dmarche a galement lavantage de capitaliser ltat de lart des
topologies des moteurs les plus utilises.
13
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
2. Objectif de lapplication moteur 14
2.2.2 Les algorithmes mtiers
Simuler un moteur dans Flux 2D en rgime transitoire demande lutilisateur de
dnir un circuit dans lequel il peut dcrire lalimentation des phases. Dans ce circuit
sont reprsentes les sources de courant ou de tension mais aussi les rsistances des
phases et les inductances permettant de prendre en compte linuence des ttes de
bobines (Tab 2.1). Flux, en tant que logiciel gnraliste, ne peut aider lutilisateur
dans le calcul de ces composants. Dans lapproche mtier au contraire, nous pouvons
proposer lutilisateur des mthodes de calculs analytiques permettant le calcul de ces
composants partir dune dnition mtier du moteur et de son bobinage. Dautres
algorithmes mtiers, comme des algorithmes de rpartition classique des conducteurs
dans les encoches seront proposes pour simplier la dnition du bobinage. Ces algo-
rithmes peuvent faire gagner du temps puisque le logiciel permet maintenant de faire
des calculs que lutilisateur devait faire lui mme auparavant.
Tab. 2.1 Couplage circuit pour lalimentation des phases
2.2.3 Les essais normaliss
En plus de proposer des machines prdnies et des algorithmes mtiers, nous
souhaitons capitaliser les mthodes danalyse par lments nis de ces machines.
On propose donc de dvelopper des tudes classiques prcbles. Elles permettent
dobtenir rapidement les performances et les caractristiques principales du moteur.
La construction de la physique et le paramtrage des calculs sont automatiss et les
rsultats sont directement prsents lutilisateur. Ces rsultats peuvent contenir des
valeurs, des courbes, des dgrads et animations ou encore des schmas quivalents et
des rapports. Ainsi, on masque la complexit des lments nis.
2.2.4 La communication
Cette nouvelle interface possde un modle de donne ddi la conception et
ltude des machines lectriques. Il lui est donc maintenant beaucoup plus facile
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
de communiquer avec des outils ddis comme les outils analytiques. En prsentant
des tudes prcbles, ces bibliothques capitalisent les modes danalyse des machines
lectriques et permettent de dvelopper des fonctions dexport de schmas quivalents
vers les logiciels de la simulation systme.
2.3 Dvelopper une nouvelle plateforme ddie moteur
2.3.1 Une plateforme multi-projets
Le logiciel Flux est mono-projet, cest dire quil ne peut contenir au sein du mme
projet quune seule gomtrie et une seule application physique. Dans notre recherche
de capitalisation de la dmarche du concepteur, nous souhaitons cependant :
Visualiser tous les rsultats des tudes ralises sur un moteur.
Comparer les performances de plusieurs moteurs sur un mme essai.
Nous devons donc dvelopper un logiciel multi-projet, proposant dirents types de
machines (machines synchrones, asynchrones, courant continu, reluctance variable,
etc..). Cest cette plateforme que lon appelle FluxMotor.
2.3.2 Une plateforme multi-outils
Mme si le logiciel moteur doit contenir des fonctions dimport partir des outils
analytiques et dexport vers les logiciels de la simulation systme, llaboration dune
nouvelle plateforme multi projet qui pilote Flux nous permet galement denvisager le
pilotage dautres logiciels. Piloter les dirents outils sous la mme interface comporte
de nombreux avantages :
Calculer de manire analytique ou par lments nis les tudes classiques pro-
poses / Importer le rsultat dun prdimensionnement
Comparer leurs rsultats respectifs et ainsi aider lutilisateur dnir des pro-
cessus de conception optimaux
Dnir plus simplement une optimisation partir de concepts mtiers et pouvant
faire appel tous les outils (analytiques et numriques : mthode appele Space
Mapping [28] [29])
Proposer des architectures de commandes classiques de manire automatiser
la cosimulation entre les logiciels Flux et Portunus
Proposer des tudes 2D, 3D ou Skewed (prise en compte de linclinaison des
encoches) sous la mme interface.
2.3.3 Notre vision
La modlisation mtier des paramtres, des tudes et des rsultats classiques des
moteurs permet lutilisateur de raliser plus facilement son processus de conception.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Notre objectif terme est quil puisse modliser ce processus dans notre interface et
ainsi le reproduire laide du language de commande par exemple. Pour cela il convient
que linterface suive au mieux la dmarche du concepteur. Je vais donc prsenter notre
vision moyen terme de lorganisation des contextes dans notre plateforme.
Le cahier des charges
Un premier contexte devrait proposer la denition du cahier des charges, bas sur
la modlisation des paramtres de la machine et de ses rsultats. Ainsi on pourra par
exemple contraindre lencombrement de sa machine, a!cher un niveau requis de couple
moyen une vitesse donne et exprimer lintention de minimiser les ondulations de
couple. Le concepteur pourra se restreindre une ou plusieures technologies si cela
fait partie de son cahier des charges. Suite cette description du cahier des charges,
un rapport pourra tre cr.
Le prdimensionnement
Dans ce contexte, lutilisateur devrait pouvoir tudier rapidement la faisabilit de
son cahier des charges. Pour cela il aura accs des mthodes de calcul analytique rapi-
des appliques aux solutions quil envisage (dj propose par le logiciel SPEED). Pour
laider faire un premier choix de structures, des algorithmes de prdimensionnement
et des outils doptimisation lui seront proposs. La dnition du problme doptimi-
sation, base sur lexpression des contraintes et des objectifs en partie dnis dans le
contexte cahier des charges, sera alors plus facile. A la suite de cette optimisation, une
ou plusieurs solutions lui seront proposes.
Le dimensionnement
Une fois le prdimensionnement ralis, il pourra vrier les rsultats laide de
calculs numriques et les comparer au cahier des charges. Enn des mthodes d-
tudes de sensibilit ou doptimisation numrique lui seront proposes an da!ner le
dimensionnement.
La validation
Dans la dernire partie, on propose de synthtiser le travail de conception. Pour cela
nous proposerons des outils permettant de rdiger des rapports dcrivant les solutions
envisages et les rsultats obtenus. Enn des fonctions dexport seront proposes :
Calcul de schmas quivalents et export vers des logiciels de llectronique.
Fonctionnalits dexport vers la CAO et les logiciels de mcanique.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Enn pour capitaliser lexprience et lhistorique du projet, on permettra dim-
porter dventuels rsultats de mesures sur prototype et de les comparer aux rsultats
de simulation.
2.4 Organisation du travail de thse
Lambition a!che prcdemment nous pousse dnir les premires tapes du
travail et les objectifs pour ces travaux. Lvolution de ces objectifs est dtaille ci-
aprs dans lordre chronologique.
2.4.1 Des bibliothques gomtriques de moteurs dans Flux
La premire tape de ce travail consiste dvelopper dans Flux des bibliothques
de machines lectriques. Cette tape permet dabord de simplier et dacclrer lu-
tilisation du logiciel Flux pour les concepteurs de moteurs. Grce aux logiciels des
partenaires, nous avons dj une bonne spcication des topologies existantes pour les
moteurs sans balais aimants permanents, les machines asynchrones, les moteurs
reluctance variable et les machines courant continu aimants ou stator bobin. Ce
travail ne demandera donc pas beaucoup de spcication mme si nous devons rchir
lorganisation de lIHM et la structuration des donnes. En revanche une telle ap-
proche, pour pouvoir suivre linnovation, demande des outils volutifs car de nouvelles
topologies de moteur devront tre ajoutes. De plus si nous nous interessons au mtier
du moteur dans le cadre de ces travaux, la dmarche mtier est destine stendre
dautres mtiers auxquels peut rpondre le logiciel gnraliste Flux. Nous devons
donc travailler sur une dmarche de personnalisation du logiciel Flux rutilisable pour
dautres mtiers. Enn pour encourager et acclrer le dveloppement de nombreuses
interfaces mtier, nous ferons en sorte de simplier au maximum la dmarche pour
quelle devienne accessible un utilisateur avanc de Flux.
2.4.2 Etendre les bibliothques la notion de laboratoire virtuel
Une fois ces bibliothques gomtriques en place, il sagit de les tendre la notion
de laboratoire virtuel. En fait il sagit dautomatiser les mthodes danalyse par l-
ments nis classiquement ralises sur les moteurs. Cette tape demande un travail de
spcication des mthodes danalyse et de leurs rsultats. Puisque toute ltendue des
topologies de moteurs et leur mode danalyse ne pourra pas tre implment pendant
la thse, nous avons choisi de nous concentrer sur un type de moteur, ce qui permettra
de valider la mthode. Le march a guid notre choix sur les moteurs sans balais
aimants permanents (Brushless Permanent Magnet Motor - BPM).
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
2.4.3 Dveloppement dune nouvelle plateforme multi-projet pour la
conception des moteurs
La dernire tape consiste proposer des solutions techniques et dvelopper
un prototype de la plateforme logicielle multi-projet FluxMotor. Dans un premier
temps ce prototype doit tre capable de piloter Flux et ses bibliothques moteur. Cela
demandera donc de mettre en place une architecture logicielle permettant le pilotage
de Flux. FluxMotor prsente la mme interface mtier que les bibliothques sauf quil
peut contenir plusieurs types de moteurs. De plus il permet de construire plusieurs
moteurs et de raliser plusieurs tudes dans un seul projet. La gestion des chiers
Flux est masque lutilisateur. Le prototype propose galement des solutions pour
crer des rapports dtude.
2.5 Conclusion
Dans ce chapitre, jai prsent nos axes de travail, qui sont diviss en trois tapes :
Dveloppement des bibliothques gomtriques de machines lectriques et un
couplage avec les outils analytiques. Ce travail sera prsent dun point de vue
fonctionnelle dans le chapitre 3. Il permettra de mettre en oeuvre une mthodolo-
gie de personnalisation de Flux qui sera prsente dans la seconde partie.
Dveloppement dune bibliothque complte pour ltude des moteurs sans-balais
aimants (Brushless Permanent Magnet motor - BPM). Les mthodes danalyse
des moteurs aimants et les rsultats classiques proposs par la bibliothque
seront prsents au chapitre 4.
Le dveloppement dun prototype du logiciel FluxMotor. Cette partie fait inter-
venir essentiellement des considrations informatiques et sera prsente dans la
seconde partie du mmoire.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Chapitre 3
La dnition des moteurs
3.1 Introduction
Dans ce chapitre je prsenterai plus en dtails la dnition mtier des moteurs
BPM (Brushless Permanent Magnet) que nous proposons dintgrer dans Flux2D et
FluxSkewed, logiciel Flux qui permet de prendre en compte linclinaison des encoches
(Figure 3.1). Nous envisageons galement une version 3D. Cette bibliothque permet
la dnition de la gomtrie, du maillage et du bobinage en deux dimensions de nom-
breux moteurs BPM partir de paramtres de haut niveau. Elle contient galement
la dnition des matriaux et le calcul des paramtres circuits.
Fig. 3.1 FluxSkewed propose deux mthodes pour linclinaison du rotor ou du stator
19
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
3. La dnition des moteurs 20
3.2 Les topologies
La paramtrisation des moteurs est la mme que celle utilise dans le logiciel
SPEED car notre objectif est galement de faciliter le lien entre les outils analytiques
et numriques. Elle contient une fonction dimport des moteurs SPEED dans Flux. De
plus nous travaillons pour retourner les rsultats lments nis dans le logiciel SPEED.
3.2.1 Les rotors
Dans la bibliothque BPM nous proposons des moteurs rotors intrieurs. Il existe
plusieurs familles de rotors (Figure 3.2) comme par exemple :
Les rotors aimantation radiale
Les rotors aimantation parallle
Les rotors aimants enterrs
Les rotors concentration de ux
Les rotors aimants enterrs avec cage dcureuil
Une fois que lutilisateur a fait le choix dun type daimantation, on lui propose
de choisir parmis plusieurs types denfoncement des aimants. En tout la bibliothque
contient 36 topologies de rotors. Chacune des topologies est dnie par un certain
nombre de paramtres mtiers comme lpaisseur des aimants ou sa longueur angulaire
par exemple.
Fig. 3.2 Les topologies de rotor dans la bibliothque de moteur sans balais aimants
permanents
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
3.2.2 Les stators
La dnition du stator comprend le choix de la forme dencoche et le choix de la
forme de la carcasse (Figure 3.3). On propose 12 formes dencoches et 4 formes de
carcasses. Comme pour les rotors, chaque forme dencoche est dcrite par une srie
de paramtres comme la largeur de dent ou la profondeur dencoche. La technologie
employe doit nous permettre de rajouter facilement des formes dencoches ou des
topologies de rotor. On peut dj penser quun mode dans lequel lutilisateur pourra
developper ses propres nouvelles gomtries sera dvelopp.
Fig. 3.3 les topologies de stator dans les bibliothques moteur
3.2.3 Des paramtres spciques
Cependant, nous devons ajouter cette description purement mtier du moteur
un certain nombre de paramtres lis la modlisation lments nis. Ces paramtres
ont t rduits leur strict minimum de manire en simplier lutilisation.
Coe!cient de maillage Dans lapproche mtier, la rpartition des densits de
maillage est automatise. Cependant certaines tudes demande un maillage plus dense
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
que dautres. En eet, la densit de maillage est directement lie la qualit des
rsultats et au temps de calcul que souhaite obtenir lutilisateur. Cest pourquoi nous
avons ajout un paramtre compris entre 0 et 1 pour contrler la densit gnrale du
maillage. Ce paramtre permet de ra!ner le maillage lorsque cest ncessaire ou au
contraire de lallger. On a donc rduit son plus bas niveau la dnition du maillage
pour la rendre extrmement simple et rapide.
Excentricits Le calcul par lments nis permet un calcul prcis de certains dfauts
et notamment dtudier limpact dventuelles excentricits. Cest pourquoi nous avons
introduit la possibilit de dnir des excentricits : on peut dcaler le stator et/ou le
rotor par rapport laxe de rotation du rotor. Ceci permet danalyser limpact de la
variation dentrefer sur les performances de la machine.
Les priodicits An de diminuer le temps de calcul et dconomiser de la mmoire,
il est possible dans Flux de dnir des symtries ou des priodicits. Nous avons donc
introduit la possibilit dutiliser les priodicits dans le cas o il ny a pas dexcentric-
its. Le logiciel ne trace alors quune partie de la gomtrie (
1
s gcd(Qs rohv>Qhqfrfkhv)
).
Le nombre de couches dans lentrefer Certaines tudes, notamment le calcul du
couple de dtente, demandent un maillage trs n dans lentrefer pour obtenir de bons
rsultats. On propose donc dans les bibliothques la possibilit de choisir le nombre
de couches de mailles dans lentrefer.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
La bote innie La rsolution dun problme lments nis demande la dnition
dun certain nombre de conditions aux limites. Dans Flux il est possible dimposer une
condition de champ tangent lextrieur du rotor ou de dnir une bote innie. On
peut retrouver cette fonctionnalit dans les bibliothques partir dun simple choix
entre les deux solutions.
3.3 Les mthodes de bobinage
La dnition du bobinage dans le logiciel Flux gnraliste consiste rassembler
les rgions gomtriques correpondant une phase et leur aecter un composant
du circuit externe. On indique alors le sens des conducteurs et le nombre de spires
traversant la rgion. Cette dnition est longue. Nous proposons une vision plus mtier
de la dnition du bobinage dans le cadre des bibliothques.
Mme si dun point de vue lments nis, en 2 dimensions, linduction dans len-
trefer ne dpend que de la rpartition des conducteurs dans les encoches, la dnition
des parties frontales est ncessaire pour le calcul des rsistances des phases et des in-
ductances des ttes de bobines. On dnit donc chaque phase comme une somme de
bobines dcrites par leur encoche aller, leur encoche retour et le nombre de spires. En-
suite on dnit le nombre de chemins parallles par phase. Cette dnition du bobinage
est appelle personnalise car elle permet la dnition de nimporte quel bobinage. On
associe galement cette dnition de la rpartition du bobinage, le matriau cuivre
utilis.
Cependant, pour simplier encore la denition du bobinage, nous proposons
lutilisateur des rpartitions de bobinages classiques [1] [17] que sont les bobinages
concentriques par ples, imbriqus par ple et pas fractionnaire. Ceci permet de
dnir la distribution des conducteurs partir de deux ou trois paramtres gnraux
comme le pas de bobinage ou le nombre de bobines par ple et par phases. Encore une
fois notre outil est volutif et dautres algorithmes pourraient tre implants dans le
futur (bobinage ondul, ondul rpartis, concentrique ples consquents et imbriqu
ples consquents). Enn grce cette dnition mtier, le changement du pas de
bobinage devient plus simple et plus rapide dans un processus de dimensionnement.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
3.3.1 Le bobinage imbriqu par ple
Dans le bobinage imbriqu (Figures 3.4, 3.5, 3.8, 3.9), les bobines dune mme phase
et correspondant un mme ple ont toutes le mme pas et sont dcales entre elles
dune encoche. Le pas du bobinage peut tre diamtral (cest dire gal aux nombre
dencoches sur le nombre de ples) ou raccourci. Le pas raccourci permet de rduire le
taux dharmoniques dans la fmm (Force magnto-motrice) et du mme coup diminuer
le cuivre et donc la rsistance et le cot. Une fois une phase dnie, les autres sont
obtenues par rotation de
2
3
rad c|cc dans le cas dun bobinage triphas. Le nombre de
bobines par ple peut tre dirent suivant que lon utilise un bobinage une couche
ou deux couches. Dans le cas dun bobinage deux couches on peut positionner les
conducteurs de manire superpose ou adjacente.
Tab. 3.1 Bobinage deux couches : Positionnnement dans lencoche adjacente ou
superpose
Les paramtres du bobinage imbriqu sont :
Le nombre de bobines par ple et par phase
Le pas du bobinage
Le nombre de spires par bobine
Le nombre de chemins en parallle par phase (Nombre de voies denroulement)
3.3.2 Le bobinage concentrique par ple
Ce bobinage consiste placer les bobines sur un ple en spirale (Figures 3.6, 3.7).
Il est souvent une couche. Il permet notamment de rduire le cot du bobinage (cot
du cuivre) et il est moins cher bobiner. Cependant mme sil favorise le fondamental,
il introduit un fort taux dharmoniques. Les paramtres de ce bobinage sont les mmes
que le bobinage imbriqu .
3.3.3 Le bobinage pas fractionnaire
Le nombre dencoches par ple et par phase nest pas toujours un entier, ce qui
interdit lutilisation des algorithmes classiques qui viennent dtre prsents. Nous
proposons donc un algorithme permettant de dnir ce que lon appelle le bobinage
pas fractionnaire (Figures 3.10, 3.11).
Le bobinage pas fractionnaire est dni par :
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Le pas du bobinage
Le nombre dencoches de dcalage entre deux phases (comme le nombre den-
coches par ples et par phases nest pas un entier, on ne peut pas toujours dcaler
les phases dexactement
2
3
rad c|cc).
3.3.4 La dnition des spires
On dnit la rsistivit du cuivre et la section des conducteurs et de leur isolant.
Nous proposons deux sections direntes : rectangulaires ou ciculaires.
Suite cette dnition, nous calculons le coe!cient de foisonnement du cuivre et le
coe!cient de foisonnement total. Nous proposons galement une dnition du cuivre
partir de nomenclatures comme lAmerican Wire Gage (AWG). Dautres classica-
tions pourront tre introduites par la suite. Pour valuer lors des essais limpact de la
temprature sur la rsistance de phase, la rsistivit est donne pour une temprature
et on dnit un coe!cient multiplicateur. La rsistivit est alors value comme suit :
j = j
20
[1 +c(T 20
)] (3.1)
c = 3, 9.10
33
pour le cuivre et laluminium
c = 3, 8.10
33
pour largent
3.3.5 La dnition des ttes de bobines [19]
Dans un calcul lments nis en deux dimensions, les ttes de bobines sont prises en
compte dans le couplage circuit par lintroduction dune rsistance et dune inductance
de ttes de bobines par phase. Lutilisateur peut donc dnir la longueur dune tte de
bobine et linductance par phase. Cependant nous lui proposons un certains nombre
de formules analytiques permettant de les calculer automatiquement.
Le modle de M. Liwschitz
Dans ce modle lutilisateur ne dnit que la longueur de la tte de bobine. Cepen-
dant ce modle ne sapplique qu des bobinages imbriqus deux couches.
1
WE
= 2
2
j

WE
(3.2)
avec
WE
= 0.43j
0
|
WE
/
2
u
(3.3)
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 3.4 Bobinage imbriqu par ple 1 couche - Phase 1 - Moteur 24 encoches
et 2 ples - Pas du bobinage : 10 - Nombre de bobines par ples : 2
Fig. 3.5 Bobinage imbriqu par ple 1 couche - Les 3 phases - Moteur 24 encoches
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 3.6 Bobinage concentrique par ple 1 couche - Phase 1 - Moteur 24 encoches
Fig. 3.7 Bobinage concentrique par ple 1 couche - Les 3 phases - Moteur 24
encoches et 2 ples - Pas du bobinage : 11 - Nombre de bobines par ples : 2
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 3.8 Bobinage imbriqu par ple 2 couches - Phase 1 - Moteur 24 encoches
Fig. 3.9 Bobinage imbriqu par ple 2 couches - Les 3 phases - Moteur 24
encoches et 4 ples - Pas du bobinage : 5 - Nombre de bobines par ples : 2
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 3.10 Bobinage pas fractionnaire - Phase 1 - Moteur 21 encoches et 4 ples
- Pas du bobinage : 5
Fig. 3.11 Bobinage pas fractionnaire - Les 3 phases - Moteur 21 encoches et 4
ples - Pas du bobinage : 5 - Oset : 7
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 3.12 Dnition de la section des spires
WE
: Permance des ttes de bobines (H)
: Nombre de spires en srie par phase
j : Nombre de paires de ples
/
u
: Coe!cient de raccourcissement du bobinage
j
0
: Permabilit du vide
|
WE
: Longueur dune tte de bobine (m)
Le modle de Kostenko
Dans ce modle lutilisateur ne dnit que le diamtre moyen des enroulements
statoriques. Cependant ce modle sapplique des ttes de bobines en dveloppantes
de cne et ne sera propos que pour les bobinages imbriqus.
1
WE
= 2j
0
2
j

WE
(3.4)
avec
WE
= 0.57
3 1
2
t (3.5)
WE
: Permance des ttes de bobines (H)
: Nombre de spires en srie par phase
j : Nombre de paires de ples
: Raccourcissement du pas par rapport au pas diamtral
t : Ouverture du bobinage (m), t =
G
2s
(D : diamtre moyen des enroulements)
Le modle de P.L. Alger
Encore une fois ce modle se limite aux bobinages imbriqus, cependant il est trs
utilis.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
1
WE
= j
0
:
2
f
1
1
2
) () (3.6)
avec
)(, ) =
tan
4
1
sin
+
/
2
g
/
2
u
6
1 + 0.12
2
(3.7)
: : Nombre de phases
f
: Nombre de conducteurs en srie par phase
1 : Diamtre intrieur de linduit (m)
1 : Nombre de ples
: Raccourcissement du pas
: Angle douverture des dveloppantes, en radians
/
g
: Coe!cient de distrubution
/
u
: Coe!cient de raccourcissement
Le modle de T. Miller
Ce modle a lavantage dtre applicable tous les types de bobinage. Il est propos
par Tim Miller et JR Hendershot dans "Design Brushless Permanent-Magnet Motors".
1
WE
=
:
a
2
j
0
2
1
2
ln
41
G'1
2
(3.8)
j
0
: Permabiblit du vide
: Nombre de spires en sries par bobine
: : Nombre de bobines par phases
a : Nombre de chemins en parallle
1 : Diamtre moyen des spires (m)
G'1 : Distance moyenne entre deux conducteurs dans lencoche (m) (G'1 = 0.447
s
)
: Surface dune encoche (ou dune demi encoche dans le cas dun bobinage
deux couches)
Mthode par calcul lments nis 3D
Des mthodes ont t dveloppes sur la base dune reprsentation 3D dune ex-
trmit de la machine pour le calcul des inductances des ttes de bobines [18]. Lune
delle consiste alimenter les phases et calculer lnergie emmagasine dans lair
entourant les ttes de bobines. Ces mthodes sont cependant assez lourdes mettre
en place. Les automatiser dans une interface mtier a donc un intrt fort. Cependant
cela demande le dveloppement dune bibliothque ddie la construction des ttes
de bobines en 3D, ce qui na pas t envisag pendant la thse.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 3.13 Reprsentation 3D des ttes de bobines
3.3.6 La dnition de lanneau de court-circuit
Pour les rotors aimants contenant une cage dcureuil, linuence de lanneau
est pris en compte dans le couplage circuit avec lintroduction de rsistances et din-
ductances inter-barres. La bibliothque propose le choix parmis dirents algorithmes
commes les formules de Trickey ou celles dAlger [20] [21] [22]. Elles sont bases sur
une description gomtrique de lanneau et la rsistivit du matriau utilis.
Fig. 3.14 Paramtrage de lanneau
1
idqq
= 0.365j
0
|
dqq
2
U
log
1.5
o
dqq
2
c
dq
+
G
H
+G
L
2
!!
1
idqq
=
1
idqq
2 sin
s
Q
U
2
(3.9)
1
dqq
=
Do
|
dq
o
dq
U
(3.10)
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
|
dqq
: Primtre de lanneau (m)
U
: Nombre de barres rotoriques
j
Do
: Rsistivit des barres (:)
o
dq
: Section de lanneau o
dq
= c
dq
G
H
3G
L
2
(:
2
)
3.4 Les matriaux
La dnition mtier des matriaux est proche de celle utilise dans Flux. En eet
de nombreux modles de courbes B(H) existent dj dans Flux. Cependant, on pourra
direncier, dans le cadre dune dnition mtier, les matriaux magntiques durs des
matriaux magntiques doux. De plus, alors que le calcul des pertes est ralis en post-
processing dans Flux, on poura dans lapproche mtier caractriser les pertes dans les
matriaux ds le prprocessing.
3.4.1 Stator et rotor
Dnition de la courbe B(H).
Plusieurs modles sont proposs pour dnir les courbes B(H) et correspondent
ceux dj proposs dans Flux (Figures 3.15 et 3.16).
Fig. 3.15 Modle isotrope analytique avec contrle du coude
Des outils permettant de rgler les paramtres des modles arctangentes par-
tir dune courbe points par points pourraient tre dvelopps par la suite. Certains
modles dpendant de la temprature, pourraient tre introduits. Ceci demanderait
cependant pour les essais de dnir une temprature pour chaque rgion du moteur
value partir de MotorCAD par exemple.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 3.16 Modle points par points
Les pertes fer
Les pertes fer sont values partir du modle de Bertotti lors dun calcul transis-
toire ou harmonique. Ce calcul est un calcul posteriori. Il ncessite la dnition des
coe!cients de Bertotti qui sont :
Coe!cients des pertes par hystrsis /
k
(\:T
32
:
33
)
Coe!cient des pertes classiques qui est la conductivit o (o:
31
)
Coecients des pertes par excs /
h
(\(T:
31
)
33@2
:
33
)
Epaisseur de tles d
Coe!cient de foisonnement /
i
La frquence f (celle-ci sera dduite partir du paramtrage de lessai).
La densit volumique instantane des pertes fer est value partir de la formule
(3.11) en transitoire :
d1(t) =
"
/
k
1
2
p
) +o
d
2
12
d1
dt
(t)
2
+/
h
d1
dt
(t)
3@2
#
/
i
(3.11)
Ces pertes pourront tre a!ches sous la forme de dgrads. On donnera aussi
les pertes fer sur une priode et par rgions en intgrant sur la priode et sur les
volumes. Les constructeurs donnent souvent des courbes de pertes en fonction du
niveau dinduction et de la frquence. Nous travaillerons donc sur un outil permettant
de dterminer /
k
et /
h
partir des courbes fournies par les constructeurs.
On remarque quen transitoire, on donne la frquence et donc seul le fondamen-
tal est pris en compte. Il existe cependant un modle dynamique dans Flux appel
LSModel. Cependant ce modle, qui ncessite la connaissance de la courbe de H(B,
dB/dt), demande des mesures exprimentales et encore peu de matriaux sont car-
actriss dans Flux. Nous devrons donc travailler par la suite clarier la dmarche
de caractrisation de ces matriaux, llaboration dun diteur de matriaux et
llaboration dune banque de matriaux plus complte. De plus ces calculs de pertes
sont raliss postriori et on peut ventuellement les faire apparatre dans le bilan
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
de puissance. Mais pour tre complet, il faudrait tre en mesure de prendre en compte
ces pertes pendant le calcul. Des travaux de recherche sur ce sujet ont dj t engags
au G2Elab.
Rsistivit
En plus des proprits magntiques et des pertes des matriaux, on peut dnir la
rsistivit, notamment dans le cas dun rotor massif, ce qui induira en transitoire un
calcul des courants de Foucault.
Masse volumique
On calcule les volumes des matriaux. La dnition de la masse volumique nous
permet de calculer la masse des matriaux ainsi que linertie du rotor qui pourra tre
utilise lors dun couplage avec la charge mcanique.
3.4.2 Aimants rotor
Nous avons choisi de sparer la dnition des matriaux magntiques doux de celle
des aimants puisque les modles de courbes B(H) proposs sont dirents. Cependant
les direntes proprits dnir sont les mmes (courbe B(H), coe!cients de Bertotti,
rsistivit, masse volumique).
3.4.3 Cage dcureuil
Les dimensions gomtriques de la cage sont dnies (section et anneau). Il reste
donc dnir la rsistivit du matriau.
3.5 Conclusion
Dans ce chapitre, jai prsent la faon dont nous souhaitons pouvoir dnir un
moteur dans les bibliothques ddies dans Flux en prenant lexemple de la biblio-
thque de moteur BPM. En plus dautomatiser la construction de la gomtrie, ces
bibliothques sont capables de calculer les volumes, les masses, les rsistances et les
inductances quivalentes aux parties frontales. Les technologies informatiques mises
en place pour dvelopper ces biblothques seront dveloppes dans la seconde partie.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Chapitre 4
La caractrisation des moteurs
4.1 Introduction
Maintenant quun moteur BPM (Brushless Permanent Magnet) peut tre dni
rapidement dans Flux, je vais prsenter les fonctionnalits que nous proposons pour
obtenir une valuation rapide de ses performances. Lapproche est base sur des tudes
prdnies qui permettent dobtenir directement les rsultats carctristiques du mo-
teur. Certains rsultats permettront lutilisateur dadapter le dimensionnement,
dautres lui permettront de dterminer les caractristiques lectriques quivalentes du
moteur pour une utilisation dans la simulation systme. Aprs avoir rappel les modes
de fonctionnement des moteurs BPM et les schmas quivalents utiliss pour ce type
de machine, je prsenterai les tudes que nous avons spcies.
4.2 Les moteurs brushless aimants permanents
Les moteurs BPM sont constitus dun stator, dans lequel sont placs les conduc-
teurs des phases, et dun rotor aimants. Labsence de conducteurs au rotor, contraire-
ment la machine courant continu ou la machine synchrone rotor bobin, permet
de se passer des balais. Il existe deux types de moteurs BPM, les moteurs BDC (Brush-
less Direct Current) et les moteurs PMSM (Permanent Magnet Synchronous Machine).
Leur fonctionnement et leur mode danalyse sont largement traits dans le livre de JR
Hendershot et TJE Miller [1].
4.2.1 Les moteurs BDC
Dans un moteur BDC, les phases sont alimentes par des courants en crneaux
fonctions de la position du rotor. Ce rgime de fonctionnement est trs proche de celui
de la machine courant continu sauf que les aimants tournent et la commutation dans
36
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
4. La caractrisation des moteurs 37
les conducteurs du stator est assure par llectronique. Pour maximiser le couple et
minimiser ses ondulations, on cherche avoir des tensions vides trapzodales (Figure
4.1). En ngligeant les pertes, on obtient vitesse constante un couple constant donn
par lquation 4.1.
1
OO
1 =
hp
(4.1)
1
OO
: La fem vide entre 2 phases en srie
(En BDC deux phases sont alimentes chaque instant)
1 : Le courant continu de ligne
hp
: Le couple lectro-magntique
: La vitesse mcanique
Fig. 4.1 Formes des courants et des tensions vide dans un moteur BDC
Fig. 4.2 Exemple dun rotor de moteur BDC
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
4.2.2 Les PMSM
Les PMSM sont aliments par des courants sinusodaux. Ils ont un fonctionnement
plus proche de celui de la machine synchrone classique : le rotor bobin est remplac
par un rotor aimants permanents. Dans ce cas, on cherche avoir une fem sinusodale.
La plupart des signaux sont considrs sinusodaux et on privilgie une reprsentation
vectorielle dans le repre du rotor (Figure 4.3).
Tab. 4.1 Exemples de rotor de PMSM
Fig. 4.3 Diagramme vectoriel du fonctionnement dun PMSM
4.3 La gneration de composants systme
Il existe plusieurs modles quivalents pour les moteurs BPM. Les trois les plus
couramment utiliss seront prsents ici, cest dire le modle par phase et les modles
dans la transformation de Park (premier et second ordre). Lutilisation de ces modles
dpend des hypothses que lon peut faire sur la saturation, la forme des ples et le
type dalimentation.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Dans un moteur brushless aimants permanents, les tensions aux bornes des phases
scrivent :
{\ } = [1] {1} +
d
dt
{c} (4.2)
[1] : La matrice diagonale des rsistances des phases
{c} : Le vecteur des ux traversant chaque phase
Ces ux sont composs de deux termes : le premier correspond aux ux produits
par les phases du stator et le deuxime aux ux produits par les aimants.
{c} = [1(0, {1})] {1} +
c
sp
(0, {1})
(4.3)
Chacun des termes dpend de la position du rotor et des courants qui modient
ltat de saturation de la machine. En pratique, il est di!cile dvaluer les inductances
en fonction de tous ces paramtres. On fera donc un certain nombre dhypothses.
4.3.1 Le modle par phase
En ngligeant les pertes fer par hystrsis et par courant de Foucault, et en sup-
posant que la machine est non sature, la matrice inductance et les ux produits par
les aimants ne dpendent plus de la valeur des courants. De plus si lon considre un
rotor ples lisses, les inductances ne dpendent plus de la position du rotor. Les
tensions aux bornes de chaque phases scrivent alors :
{\ } = [1] {1} + [1]
d
dt
{1} + {1} (4.4)
Le terme {1} =
g
gw
c
sp
(0)
est appel force lectro motrice (fem vide). Il

correspond aux tensions vide.
En supposant un bobinage correctement rparti, on peut admettre que toutes les
inductances propres (notes L) sont gales et que toutes les mutuelles (notes M) sont
aussi gales. On peut alors crire en triphas :
5
7
c
d
c
e
c
f
6
8
=
5
7
1 ' '
' 1 '
' ' 1
6
8
5
7
1
d
1
e
1
f
6
8
+
5
7
1
d
(0)
1
e
(0)
1
f
(0)
6
8
(4.5)
c
d
, c
e
, c
f
: Les ux traversant les phases a, b et c
1
d
, 1
e
, 1
f
: Les courants dans chaque phase
1
d
, 1
e
, 1
f
: Les fem vide phase-neutre
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
La somme des courants tant nulle (en fonctionnement BDC et PMSM), on a :
{\ } = 1{1} + (1 ')
d
dt
{1} + {1} (4.6)
Fig. 4.4 Modle quivalent par phase
On obtient le schma quivalent par phase de la gure 4.4 en posant 1
v
= 1'.
1
v
est alors linductance propre cyclique. Dans le cas des moteurs BDC, o deux phases
conduisent chaque instant, on donnera cependant les valeurs entre deux phases des
inductances, des rsistances et des tensions vide (4.7).
1
OO
= 2(1 ') (4.7)
1
OO
= 21
1
OO
= 21 = /
H
/
H
est appele constante de fem.
Modle par phase
Hypothses Paramtres
Machine non sature (Linarit des proprits du milieu) 1
Pas de courants de Foucault 1
v
Ples lisses 1
Les inductances propres sont gales
Les inductances mutuelles sont gales
La somme des courants est nulle
Tab. 4.2 Hypothses et paramtres du modle par phase
4.3.2 Le modle dans la transformation de Park
En rgime synchrone, on utilise plus souvent des rotors aimants enterrs ou
aimantation orthoradiale (concentration de ux) car ils permettent dobtenir une
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 4.5 Inductances propres et mutuelles dans un moteur ples saillants
force lectro-motrice sinusodale. Pour toutes ces topologies, lhypothse de rotor
ples lisses ne tient plus et les inductances varient en fonction de la position du rotor
(Figure 4.5). Pour prendre en compte leet de saillance des ples, on introduit un
terme supplmentaire dans la matrice inductance fonction de la position du rotor :
[1
v
] = [1
v0
] + [1
v2
(0)] (4.8)
Ce terme est bas sur une dcomposition en srie de fourier des inductances propres
et mutuelles qui sont fonctions priodiques de 0 (position en degrs lectriques du
rotor), de priode . En considrant uniquement le terme constant et lharmonique de
rang 2, en triphas, on a :
[1
v0
] =
5
7
1 ' '
' 1 '
' ' 1
6
8
, [1
v2
] = 1
5
7
cos(20) cos(20
2
3
) cos(20
4
3
)
cos(20
2
3
) cos(20
4
3
) cos(20)
cos(20
4
3
) cos(20) cos(20
2
3
)
6
8
(4.9)
Dans la pratique, on utilise la tranformation de Park. Cette transformation consiste
exprimer les grandeurs dans un repre daxes d et q li la position du rotor (Figure
4.6). Pour une grandeur ` quelconque, la transformation dun systme triphas dans
le modle de park est donne par :
[`
gt0
] =
2
3
5
7
cos(0) cos(0
2
3
) cos(0
4
3
)
sin(0) sin(0
2
3
) sin(0
4
3
)
1
2
1
2
1
2
6
8
[`
def
] (4.10)
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 4.6 Axes d et q du rotor
En considrant des grandeurs sinusodales, et en exprimant les tensions vide sous
la forme :
5
7
1
1
1
2
1
3
6
8
= .c
sp
5
7
sin(0)
sin
0
2
3
sin
0
4
3
6
8
(4.11)
. = j : La pulsation lectrique
j : Le nombre de paires de ples
: La vitesse du rotor
On obtient aprs transformation :
c
g
c
t
1
g
0
0 1
t

1
g
1
t
+c
sp
1
0
(4.12)
avec
1
g
= (1 ') +
3
2
1
(4.13)
1
t
= (1 ')
3
2
1
1
g
: Inductance synchrone daxe directe
1
t
: Inductance synchrone daxe en quadrature
Les quations lectriques de la machine dans le modle de Park deviennent :
\
g
= 11
g
+
dc
g
dt
.c
t
(4.14)
\
t
= 11
t
+
dc
t
dt
+.c
g
Avec lhypothse de non saturation, les inductances sont constantes et on obtient
le modle quivalent de la gure 4.7.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
\
g
= 11
g
+1
g
d1
g
dt
.1
t
1
t
(4.15)
\
t
= 11
t
+1
t
d1
t
dt
+.1
g
1
g
+.c
sp
Fig. 4.7 Modle quivalent dans la transformation de Park
Dans ce modle, le couple est donn par :
hp
= 3j
c
g
1
t
c
t
1
g
= 3j
c
sp
1
t
+ (1
g
1
t
) 1
g
1
t
(4.16)
Le premier terme est appel couple synchrone d aux aimants ("magnet align-
ment torque"). Le second, appel couple reluctant ("reluctance torque"), correspond
la variation de reluctance due la saillance des ples. Ces deux termes dpendent
de la position relative du rotor par rapport linduction statorique, mais nont pas la
mme priode (Figure 4.8).
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 4.8 Couple dans le modle de Park
Modle dans la transformation de Park
Hypothses Paramtres
Machine non sature (linarit des proprits du milieu) 1
g
Pas de courants de Foucault 1
t
Grandeurs sinusodales (PMSM) c
sp
Les inductances propres sont gales 1
Les inductances mutuelles sont gales
Tab. 4.3 Hypothses et paramtres du modle dans la transformation de Park
4.3.3 La prise en compte damortisseurs
Lorsque le rotor contient des amortisseurs ("Damper windings") comme une cage
dcureuil (Figure 4.9) ou simplement lorsque lon veut prendre en compte la rsis-
tivit des aimants et celle du circuit magntique rotor, il convient da!ner le modle
prcdent [8] [15].
Fig. 4.9 Exemple de rotor avec cage dcureuil
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
En introduisant dans les quations les courants qui circulent dans les amortisseurs
et les ux qui traversent les amortisseurs, on obtient :
5
9
9
7
c
g
c
t
c
ng
c
nt
6
:
:
8
=
5
9
9
7
1
o
+1
pg
0 1
pg
0
0 1
o
+1
pt
0 1
pt
1
pg
0 1
pg
+1
ng
0
0 1
pt
0 1
pt
+1
nt
6
:
:
8
5
9
9
7
1
g
1
t
1
ng
1
nt
6
:
:
8
+c
sp
5
9
9
7
1
0
1
0
6
:
:
8
(4.17)
1
o
: Inductance de fuite.
On ajoute galement aux quations des tensions de phases (4.14), les tensions des
amortisseurs en court circuit.
\
ng
= 0 = 1
ng
1
g
+
dc
ng
dt
(4.18)
\
nt
= 0 = 1
nt
1
t
+
dc
nt
dt
On obtient le schma quivalent de la gure 4.10.
Fig. 4.10 Modle quivalent avec prise en compte des amortisseurs
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Dans le schma 4.10, les aimants permanents sont reprsents par une source de
courant dans laxe d tel que c
sp
= 1
pg
i
i
au lieu dune source de tension dans laxe
q. Cependant on retrouve ce ux dans la source de tension .c
g
de laxe q. Les deux
reprsentations sont donc quivalentes. Les conditions dutilisation sont les mmes que
pour le modle de Park du premier ordre sauf que cette fois-ci on prend en compte les
courants de Foucault dans les amortisseurs, les aimants et le rotor massif.
Modle avec amortisseurs
Hypothses Paramtres
Machine non sature (linarit des proprits du milieu) 1
g
, 1
t
Grandeurs sinusodales (PMSM) 1
ng
, 1
nt
Les inductances propres sont gales 1, 1
ng
, 1
nt
Les inductances mutuelles sont gales c
sp
Tab. 4.4 Hypothses et paramtres du modle avec prise en compte des amortisseurs
4.4 Les essais normaliss
Nous dsignerons par essais normaliss les simulations lments nis ralises pour
ltude de ces moteurs. On peut voir ces calculs comme les essais raliss dans un lab-
oratoire virtuel permettant lutilisateur dextraire rapidement les caractristiques et
les performances de son moteur. Elles permettront notamment didentier les paramtres
des schmas quivalents. Ces tudes correspondent aux essais dcrits par les normes [3]
[4], cependant elles comportent quelques dirences. En eet ces normes ont t dites
principalement pour les machines synchrones rotor bobin. De plus les lments nis
permettent de faire abstraction de certains problmes de mesures que lon rencontre
en laboratoire. Dans notre outil mtier, elles seront automatises la demande de lu-
tilisateur partir de quelques paramtres gnraux et les rsultats seront directement
a!chs. Un des atouts supplmentaires des lments nis dans le dimensionnement
est quils permettent de visualiser les niveaux dinduction et les lignes de champ sur
la gomtrie, ce qui permet davoir une comprhension plus ne du comportement de
la machine pendant lessai.
4.4.1 Lessai vide
Lessai vide permet de dterminer les fem vides dune machine. Cet essai est
essentiel dans le dimensionnement de la machine. Dabord selon la commande, on
cherchera avoir une fem trapzodale ou sinusodale. De plus en BDC, les tensions
vides entre phases sont proportionelles la vitesse et on en dduit la constante de
fem /
H
.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
1 = /
H
(4.19)
En reprenant lquation
11 =
hp
(4.20)
On obtient
hp
= /
H
1 = /
w
1 (4.21)
La constante de fem donne donc une ide de la constante de couple. Enn ces
courbes sont souvent utilises pour lexport systme. En eet le couple tant obtenu
par le produit de la fem par le courant, on cherche souvent avoir une fem point par
point pour rendre compte des ondulations de couple dharmonique 6.
Ce calcul est ralis dans Flux en magntique transitoire sur une priode lectrique
vitesse impose et avec couplage circuit. On place des rsistances trs grandes aux
bornes des phases pour simuler un circuit ouvert et ainsi forcer les courants zro. On
obtient la force lectro-motrice en relevant les tensions aux bornes de chaque phase.
{\ } =
d
dt
{c
p
(0)}
Fig. 4.11 Courbes des forces lectro-motrices
Dans le cas dun couplage en triangle, on peut aussi mesurer le courant qui circule
dans le triangle d un ventuel dsquilibre et aux harmoniques homopolaires. Dans
le cas du couplage toile, le potentiel du neutre renseigne le concepteur sur la prsence
de composantes homopolaires. Cet essai fait galement lobjet dun calcul des pertes fer
vide. Enn, de manire optionnelle, on peut raliser une tude paramtrique faisant
varier linduction rmanente de laimant. Ce calcul supplmentaire permet de tracer
les courbes c
sp
(1
u
), /
H
(1
u
) qui peuvent tre interessantes pour le dimensionnement
des aimants.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Essai vide
Paramtres Rsultats
Nombre de pas de calcul Tensions et ux vide
Vitesse /
H
et c
sp
Connection entre les phases Pertes fer vide
Option calcul paramtrique sur 1
u
Dgrad induction et pertes fer
Lignes de champ
Tab. 4.5 Paramtres et rsultats de lessai vide
4.4.2 Le couple de dtente
Cet essai permet de calculer le couple vide. Lorsque les aimants tournent avec
le rotor et passent devant les dents du stator, ils rencontrent une reluctance variable.
Cette variation de reluctance entrane un couple de valeur moyenne nulle que lon
appelle couple de dtente ("cogging torque"). On rajoute un essai pour ce calcul
qui aurait pu tre fait pendant lessai vide, car la priode du couple de dtente
(
360
p hfd
ssfp(Q
s rohv
>Q
hqfrfkhv
)
) est dirente de la priode lectrique ce qui demande un pas
angulaire dirent. Il peut avoir un impact sur les ondulations de couple en fonction-
nement nominal et peut entrainer un bruit gnant pour certaines applications. On
cherchera donc le minimiser.
Pour obtenir ce rsultat, on ralise une tude multi-positions en magnto-statique
avec du vide dans les encoches. A chaque position, on relve le couple. Cet essai
permet galement de calculer linduction dans lentrefer et son carr donne une image
des eorts la surface des aimants et donne aussi une ide des vibrations que transmet
la machine son support.
Fig. 4.12 Courbe du couple de dtente
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 4.13 Courbe de linduction dans lentrefer
Couple de dtente
Paramtres Rsultats
Discrtisation de la courbe Courbe du couple de dtente.
Induction dans lentrefer
Niveaux dinduction
Lignes de champ
Tab. 4.6 Paramtres et rsultats de ltude du couple de dtente
4.4.3 Lanalyse statique
Lanalyse statique consiste raliser un calcul en magnto-statique un point de
charge donn. Ce calcul permet dtudier le couple statique, mais aussi de calculer les
inductances de la machine. Le point de charge peut tre dni pour un fonctionnement
en BDC ou en PMSM.
En BDC, deux phases tant alimentes chaque instant. On dnit alors :
le courant nominal 1
la position du rotor ,
En PMSM, o les phases sont parcourues par des courants sinusodaux, on dnit :
la position du rotor (
: cca)
lamplitude des courants 1
langle de dcalage , (
c|cc) entre laxe d du rotor et linduction statorique

A partir du calcul des ux dans les phases, on obtient linductance 1
v
du modle
par phase (4.22).
1
v
=
c
1
c
sp1
1
1
(4.22)
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
c
sp1
: Flux traversant la phase 1 vide (d aux aimants). Il se dduit de lessai
vide ou peut tre rvalu partir dun calcul prliminaire 1 = 0.
c
1
: Flux total traversant la phase 1 (contribution des aimants et des courants)
1
1
: Courant dans la phase 1
Les Flux sont obtenus en intgrant le potentiel vecteur sur les surfaces traverses
par les conducteurs.
ZZ
l
+
1
d,
+
ZZ
l3
2
d,
3
1
et
2
: Les potentiels vecteurs
+
et
3
: Les surfaces orientes traverses par la bobine
En PMSM, en projettant les ux et les courants sur les axes d et q du rotor, on
obtient les inductances dans la transformation de Park (4.23).
1
g
=
c
g
c
sp
1
g
(4.23)
1
t
=
c
t
1
t
Fig. 4.14 Dgrads de B
Ce calcul permet donc de dterminer le modle quivalent au moteur dans la trans-
formation de Park. Cependant pour tudier ces dirents paramtres, on propose
lutilisateur de faire varier lamplitude des courants et/ou langle de dcalage. On peut
ainsi obtenir des surfaces de rponses comme
hp
(1, ,), 1
g
(1, ,) et 1
t
(1, ,).
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Etude avec variation de langle de pilotage
En PMSM, on fait varier langle , pour un courant donn. On obtient alors la
courbe de couple en fonction de ,. Cette courbe met en vidence la prsence ou non
dun couple reluctant et permet de dterminer langle correspondant au couple maxi-
mal (Figure 4.15).
Fig. 4.15 Courbe du couple en fonction de lavance angulaire (
lec) de linduction
statorique sur le rotor
Etude avec variation du paramtre courant
Varier lamplitude des courants permet de tracer la courbe de couple en fonction du
courant et de visualiser leet de la saturation sur le couple (Figure 4.16). On en dduit
la constante de couple /
w
=
Khp
L
. De plus on peut valuer linuence de la saturation
sur la valeur des inductances (Figure 4.17). De manire valuer correctement le
comportement dynamique de la machine, les concepteurs de la commande cherchent
souvent avoir une bonne connaissance des inductances dynamiques, qui traduisent
la capacit dune variation de courant fournir du ux . Elles ont la mme valeur en
rgime linaire que les inductances statiques, mais sont direntes en rgime satur
(Figure 4.18).
1
0
v
=
c
1
1
1
(4.24)
1
0
g
=
c
g
1
g
(4.25)
1
0
t
=
c
t
1
t
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 4.16 Courbe couple(courant) pour ,=120
c|cc
Fig. 4.17 Courbes des inductances synchrones en fonction du courant pour
,=120
c|cc
Fig. 4.18 Courbes des inductances dynamiques en fonction du courant pour
,=120
c|cc
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Courbe du couple en fonction de la vitesse
A partir des courbes du couple et des inductances statiques en fonction du courant
et de lavance angulaire, on peut valuer les courbes de couple(vitesse). En eet, lon-
duleur dlivre une tension qui est limite par son alimentation en tension continue.
Lorsque la vitesse augmente, les tension vides augmentent et la commande, rgule
en courant, ne peut plus dlivrer la tension permettant ltablissement du courant
requis pour obtenir le couple voulu. Cette tension maximale dpend donc de la tension
continue et de la stratgie de commande. Une fois la tension maximale atteinte, lorsque
la vitesse augmente, le courant et donc le couple diminuent.
On peut tracer la courbe couple(vitesse) partir dune valeur de tension maximale
et de la courbe couple(courant). En eet considrant une tension maximale (\
max
),
pour une vitesse donne, en reprenant les quation du modle de Park, on peut con-
sidrer, en rgime tabli, que :
\
g
= 11
g
.c
t
(4.26)
\
t
= 11
t
+.c
g
La tension est donc limite par
q
\
2
g
+\
2
t
6 \
max
(4.27)
En partant dun courant nominal, on peut crire un algorithme qui augmente pro-
gressivement la vitesse. Pour une vitesse donne, on regarde si le courant nominal peut
tre atteint. Si la condition (4.27) nest pas respecte, on diminue le courant progres-
sivement. Une fois la condition respecte, on obtient la valeur du courant maximum et
le couple partir de la courbe de couple/courant. A la n de lalgorithme on obtient
la courbe de couple/vitesse. Cette courbe peut tre obtenue pour dirents angles de
pilotage (Figures 4.19 et 4.20).
Fig. 4.19 Courbe couple(vitesse) pour des angles de pilotage infrieurs langle de
couple maximal
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 4.20 Courbe couple(vitesse) pour des angles de pilotages suprieurs langle
de couple maximal
On constate sur ces deux courbes (Figures 4.19 et 4.20) que lon retrouve langle de
pilotage maximal. En eet pour des angles de pilotage faibles, la courbe couple(vitesse)
augmente avec langle. Une fois langle de pilotage maximal atteint, on constate que
sur la plage de vitesse courant constant, le couple diminue. Cependant, pour ces
angles, la plage de vitesse est augmente. Ce phnomne est li au fait que lon ra-
joute une composante au courant dans laxe direct qui soppose laimantation des
aimants et donc qui diminue la fem, ce qui permet datteindre des vitesses plus grandes.
Cependant cette zone de fonctionnement comporte des risques de dsaimantation des
aimants que lon peut contrler en visualisant le dgrad du champ H. Une stratgie de
commande appele duxage consiste justement rester angle de pilotage maximal
sur la plage courant constant. Une fois cette vitesse obtenue, on garde cette fois ci
le mme module du courant mais on augmente langle de pilotage. Par algorithme,
on peut obtenir, partir de la courbe couple(position), la courbe couple(vitesse) avec
duxage (Figures 4.21, 4.22).
Fig. 4.21 Courbe couple(vitesse) avec duxage
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 4.22 Evolution de langle de pilotage en fonction de la vitesse pour duxage
Ces courbes couple(vitesse) permettent donc de dimensionner les inductances pour
obtenir une plus grande plage de vitesse et pour discuter de lintrt ou non dutiliser
une stratgie de duxage. Cependant elles sont bases sur la connaissance du couple
statique et du schma quivalent (inductances). Laugmentation de la vitesse et donc
de la frquence peut entraner une augmentation des pertes qui ne sont pas prises en
compte dans ce calcul. Pour une meilleure valuation de ces courbes, il est ncessaire
de raliser une succession dessais en charge direntes vitesses.
Static analysis
Paramtres Rsultats
Alimentation BDC ou PMSM
hp
(1, ,)
En BDC : 1 et , c
1>2>3>g>t
(1, ,)
En PMSM : 1, , et 0 1
v>g>t
(1, ,)
Variation du paramtre 1 1
0
v>g>t
(1, ,)
Variation du paramtre , Constante de couple
Limitation en tension de londuleur
hp
() avec et sans deuxage
Limitation en courant Modles quivalents par phase
Essai vide ou axes d et q et dans la transformation de Park
Tab. 4.7 Paramtres et rsultats de lessai de couple statique
4.4.4 Lessai en charge
Cest lessai en rgime nominal. Il consiste raliser un calcul en transitoire sur
une priode lectrique vitesse impose avec alimentation des phases. Il permet de
visualiser les ondulations de couple et de faire un bilan de puissance pour le calcul du
rendement. Plusieurs types de commandes sont proposes lutilisateur. Ce sont les
mmes que celles proposes dans le logiciel analytique SPEED de notre partenaire. Il
y a des commandes pour les moteurs PMSM et pour les moteurs BDC. On propose
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
dalimenter les phases avec signaux idaux ou avec rgulation du courant en fonction
de la position. Lorsque les signaux ne sont pas idaux, on utilise un onduleur dans
le couplage circuit et la limite en tension est prise en compte. La rgulation amne
de nouvelles harmoniques dans les signaux et permet de mieux valuer le rendement.
Cependant ces commandes demandent un grand nombre de pas de calcul.
Commandes BDC
Courants idaux On alimente les phases avec des courants en crneaux idaux
(Figure 4.1). Lutilisateur dnit lamplitude et le dphasage. Par dfaut, le courant
commence circuler dans la phase 1 0 =30
c|cc o 0 est la position du rotor par

rapport laxe de la phase 1. Cette commande peut tre utilise quelque soit le nombre
de phases. La courbe de la Figure (4.23) met en vidence les ondulations de couple
dharmonique 6, lies la forme de la fem.
Fig. 4.23 Ondulations de couple obtenues lors dun essai en charge 1000 tr/min
avec courants idaux
Rgulation du courant par bande dhystrsis En utilisant cette commande,
on cherche reprsenter londuleur. Ceci permet de prendre en compte la limitation
en tension et une forme plus relle des courants. On modlise donc londuleur dans le
couplage circuit (Figure 4.24). Les intervalles de conduction des transistors en BDC
sont reprsents la gure 4.25. De manire rguler le courant, pendant chaque
intervalle de 60
c|cc o deux transistors conduisent, lun au moins des transistors doit

commuter. La commutation est ralise de manire ce que les courants de ligne
suivent la rfrence en courant dans une certaine bande dhystrsis (Figure 4.26).
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 4.24 Couplage circuit
Fig. 4.25 Intervalles de conductions des transistors en BDC
Fig. 4.26 Rgulation par bande dhystrsis
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Comme dans chaque priode de 60
c|cc deux transistors peuvent commuter, on

propose plusieures stratgies :
Lorsque trois transistors seulement peuvent commuter (les trois du haut Q1,
Q3, Q5 ou les trois du bas Q2, Q4, Q6), alors chaque transistor doit commuter
pendant une priode de 120
c|cc. Si ce sont les transitors du haut on appelera la

stratgie de commande C120-Q1, si ce sont les transistors du bas on lappelera
C120-Q6.
Lorsque tous les transistors peuvent commuter, chaque transistor commute pen-
dant 60
c|cc. La commutation peut se drouler pendant les 60 premiers degrs

de lintervalle de conduction du transistor, ou pendant les 60 derniers. Si ce sont
les 60 permiers, on appele la stratgie C60-Q1, si ce sont les derniers, on appelle
la stratgie C60-Q6.
Fig. 4.27 C120-Q1 : Les trois transistors du haut commutent pendant 120
c|cc
chacun
Fig. 4.28 Tous les transistors commutent pendant les 60 premiers degrs de leur
intervalle
Chaque commutation des transistors correspond une commutation de la diode qui
lui est associe. Par exemple lorsque Q1 souvre pendant son interval de conduction,
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
la diode D4 conduit le courant. La commutation des transistors est calcule chaque
nouveau pas de calcul. Pour viter que le courant dpasse la bande dhystrsis, il est
donc important davoir un nombre de pas de calcul su!sants.
Tension MLI Sil ny a pas de capteur de courant, on peut utiliser une consigne
en tension ralise laide dune modulation de largeur dimpulsions. Dans ce cas
lutilisateur dnit la frquence des crneaux et la dure de conduction dans chaque
crneau.
Commandes PMSM
Courants idaux On alimente les phases avec des courants sinusodaux idaux,
lutilisateur dnit le nombre de pas de calculs, lamplitude des courants et lavance
angulaire de linduction statorique sur laxe d du rotor. Dans ce cas la limitation en
tension de londuleur nest pas prise en compte.
Rgulation du courant par bande dhystrsis Les courants sont rguls in-
dpendamment dans chaque phase pour suivre la rfrence sinusodale. Lutilisateur
dnit le nombre de pas de calculs, lamplitude des courants, lavance angulaire, la
bande dhystrsis et la limite en tension de londuleur. Comme les courants sont
rguls indpendamment, on nassure pas que la somme des courants est nulle chaque
instant.
Rgulation du courant par le contrle du vecteur tension Dans ce cas le
courant est rgul en commutant le vecteur tension. En PMSM, chaque instant,
trois transistors conduisent. Les vecteurs tensions rsultats sont reprsents Figure
4.29.
Fig. 4.29 Les 6 vecteurs commands
A partir de la rfrence en courant Iref1, Iref2, Iref3, la rgulation du vecteur
tension se droule comme suit :
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Si I1 Iref1 :
Si I2 Iref2 :
Vecteur Q456
Sinon :
Si I3 Iref3 :
Vecteur Q234
Sinon :
Vecteur Q345
Sinon :
Si I2 Iref2 :
Si I3 Iref3 :
Vecteur Q612
Sinon :
Vecteur Q561
Sinon :
Vecteur Q123
Pour cette commande, lutilisateur dnit lamplitude des courants, lavance angu-
laire de linduction statorique sur le rotor, la frquence de commutation et la limite en
tension de londuleur.
Six tapes Dans cette stratgie les transistors sont conducteurs pendant 180
con-
scutifs (Figure 4.30). Trois transistors conduisent chaque instant.
Fig. 4.30 Intervals de conduction des transitors en PMSM
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Essai en charge
Paramtres Rsultats
Commande Ondulations de couple
Vitesse Courants et tensions
Bilan de puissance
Pertes fer
Rendement
Lignes de champs
Dgrad Induction et pertes fer
Tab. 4.8 Paramtres et rsultats de lessai en charge
4.4.5 Lessai sans rotor
Cet essai permet de dterminer linductance de fuite du stator, mises part les
fuites de ttes de bobines qui ont dj t values de manire analytique. Cette in-
ductance est utilise dans le modle de Park lorsque les aimants sont modliss par
une source de courant. Ltude consiste raliser un calcul en magnto-statique ro-
tor enlev (les rgions du rotor sont assimiles de lair). On alimente les phases en
triphas et on calcule lnergie dans tout le domaine. On obtient linductance de fuite
partir de \ =
3
2
11
2
[16].
Tab. 4.9 Essai sans rotor - Dgrad de B et lignes de champ
Essai sans rotor
Paramtres Rsultats
Amplitude des courants Inductance de fuite
Dgrad induction
Lignes de champ
Tab. 4.10 Paramtres et rsultats de lessai sans rotor
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
4.4.6 Lessai frquentiel
Cet essai, que lon peut retrouver dans les normes sous le nom de "StandStill Fre-
quency Response", a pour objectif de raliser une analyse frquentielle des inductances
synchrones an didentier les paramtres du modle dans la transformation de Park
du second ordre. Ce modle permet de prendre en compte la prsence damortisseurs ou
les courants de Foucault qui se dveloppent dans les aimants ou un rotor massif. Pour
le calcul dans Flux, on ralise une simulation en magnto-harmonique paramtrique en
faisant varier la frquence entre 1mHz et 1kHz. Deux phases sont alimentes avec une
tension simusodale damplitude \ = 5%\
q
et on aligne successivement laxe d et q du
rotor avec la phase A pour dterminer respectivement les inductances oprationnelles
daxe q et d.
Comme la simulation est ralise en magnto-harmonique, linduction rmanente
de laimant nest pas prise en compte. On peut cependant utiliser linitialisation en
magnto-statique pour prendre en compte leet de saturation des aimants. Lorsque
laxe q du rotor est align avec la phase A, on dduit linductance oprationnelle 1
g
(j)
des quations suivantes crites dans la transforme de Laplace .
7(j) =
\ (j)
1(j)
= 2(1+j1
g
(j)) (4.28)
On trace ensuite les diagramme de bode des inductances oprationnelles 1
g
(j) et
1
t
(j).
Pour identier les paramtres du modle de Park au second ordre partir de
linductance oprationnelle, il faut reprendre les quations de ce modle (4.14), (4.17),
(4.18). On pose :
1
G
= 1
o
+1
pg
(4.29)
1
T
= 1
o
+1
pt
1
NG
= 1
pg
+1
ng
1
NT
= 1
pt
+1
nt
A partir des quations (4.18), on peut exprimer 1
ng
en fonction de 1
g
(4.30).
1
ng
=
1
pg
1
ng
+j1
NG
1
g
(4.30)
1
nt
=
1
pt
1
nt
+j1
NT
1
t
En remplaant ces expressions dans lquation des phases (4.14), on obtient :
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
\
g
= 11
g
+j1
g
(j)1
g
.1
t
(j)1
t
(4.31)
\
t
= 11
t
+j1
t
(j)1
t
+.1
g
(j)1
g
+.c
p
Les expressions des inductances oprationnelles sont donnes par les quations
(4.32).
1
g
(j) = 1
G
(1 +t
g
j)
(1 +t
g0
j)
(4.32)
1
t
(j) = 1
T
(1 +t
t
j)
(1 +t
t0
j)
avec
t
g
=
1
NG
1
ng
1
1
2
pg
1
G
1
NG
(4.33)
t
g0
=
1
NG
1
ng
t
t
=
1
NT
1
nt
1
1
2
pt
1
G
1
NT
!
t
t0
=
1
NT
1
nt
t
g
: Constante de temps subtransitoire longitudinale en court-circuit
t
g0
: Constante de temps subtransitoire longitudinale circuit ouvert
t
t
: Constante de temps subtransitoire transversale en court-circuit
t
t0
: Constante de temps subtransitoire transversale circuit ouvert
De plus on dnit :
A
g
= .1
G
= . (1
o
+1
pg
) (4.34)
A
g
= .1
G
1
1
2
pg
1
G
1
NG
A
t
= .1
T
= . (1
o
+1
pt
)
A
t
= .1
T
1
1
2
pt
1
T
1
NT
!
A
g
: Ractance synchrone longitudinale
A
g
: Ractance subtransitoire longitudinale
A
t
: Ractance synchrone transversale
A
t
: Ractance subtransitoire transversale
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Cette expression thorique des inductances oprationnelles donne le diagramme de
bode suivant :
Fig. 4.31 Module de linductance oprationnelle daxe directe
Sur le diagramme de bode rsultat de la simulation, on identie les ractances et
les constantes de temps. Les paramtres du modle se dduisent des quations (4.35).
1
pg
=
A
g
.
1
o
(4.35)
1
ng
=
1
2
pg
t
g0
t
g
1
ng
= t
g0
1
ng
1
pg
On notera que linductance de fuite 1
o
est calcule partir de lessai sans rotor et
le courant dexcitation i
i
partir de lessai vide.
StandStill Frequency Response
Paramtres Rsultats
Discrtisation logarithmique Diagrammes de bodes 1
g
(j) et 1
t
(j)
Initialisation en magnto-statique Ractances synchrones et subtransitoires
Constantes de temps
Schma quivalent dq_dampers
Niveaux dinduction et Lignes de champ
Tab. 4.11 Paramtres et rsultats de lessai frquentiel
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
4.4.7 Lessai de court-circuit
Cet essai permet de simuler un court circuit entre les trois phases la suite dun
essai vide. Il permet dobserver lintensit des courants de court-circuit et dvaluer les
risques de dsaimantation des aimants. Concrtement on passe les valeurs des grandes
rsistances aux bornes de chaques phases de lessai vide des valeurs trs petites.
Lexpression des courants de court-circuit nous est donne partir de la thorie des
rgimes transitoires des machines synchrones (4.36) [2]. Pour les machines synchrones
rotor bobin, cet essai est souvent ralis en diminuant le courant dexitation. Avec
les moteurs aimants permanents, cet ajustement nest pas possible. Il y a donc ici
un intrt simuler les dfauts ventuels et tudier les risques de dsaimantation des
aimants.
i
D
= 1
1
A
g
+
1
A
1
A
g
exp
t
t
cos(.t +0
0
) (4.36)
+
1
2
exp
t
t
d
1
A
g
+
1
A
cos(0
0
) +
1
A
1
A
cos(2.t +0
0
)
t
d
=
2A
g
A
t
.1(A
g
+A
t
)
0
0
: Angle entre laxe d du rotor et la phase A au moment du court-circuit.
i
E
et i
F
sont obtenus en remplaant 0
0
par 0
0

2
3
et 0
0

4
3
.
4.5 Conclusion
Dans ce chapitre nous avons montr quen proposant lutilisateur des tudes clas-
siques des moteurs BPM on peut simplier lutilisation des logiciels Flux et capitaliser
du savoir-faire. Les tudes proposes permettront lutilisateur de dimensionner un
moteur et de le caractriser rapidement. Lessai vide permet de dimensionner la
machine pour obtenir la forme et la constante de fem (proportionnelle la constante
de couple) voulues. Avec ltude du couple statique, on dtermine langle de charge
maximal et on peut obtenir une estimation des courbes couple(vitesse). Lessai en
charge permet de vrier le couple et ses ondulations pour quelques points de fonc-
tionnement. Le calcul des inductances permet de dterminer les circuits quivalents
pour une utilisation dans la simulation systme. Pour des moteurs avec armortisseurs,
on peut utiliser lessai frquentiel. Dautres modles quivalents pourront tre rajouts
dans lavenir, je pense notamment des modles qui prennent en compte les pertes
fer par lintroduction dans le circuit quivalent dune rsistance [14] [7].
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Dans cette partie, la personnalisation du logiciel Flux que nous mettons en place
pour lanalyse des moteurs BPM a t prsente. Des outils quivalents seront dvelop-
ps pour dautres types de machines comme les machines asynchrones, les machines
courant continu aimants et les moteurs reluctance variable. La stratgie est base
sur la capacit dnir dans Flux un moteur, ses mthodes danalyses et ses rsultats
de manire mtier. Dans la seconde partie je montrerai comment ont pu tre raliss
ces dveloppements dans Flux pour quils soient volutifs et rutilisables.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Deuxime partie
Concepts informatiques et
implmentation logicielle
67
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Chapitre 5
Modliser un mtier
5.1 Introduction
Dans la premire partie, partir dune analyse des outils du concepteur de moteurs,
les fonctionnalits dun nouveau logiciel ddi la conception des machines tournantes
ont t dnies. Ce logiciel a pour but de faciliter et acclrer laccs aux mthodes
lments nis pour la simulation des machines lectriques. Pour cela, il prsente une
IHM ddie qui intgre les paramtres et les concepts manipuls par le concepteur
(comme les topologies de moteurs, les caractristiques et les performances classiques
dun moteur). Il doit galement faciliter le lien avec les autres outils de la conception :
il est coupl avec les outils analytiques du prdimensionnement et permet de crer des
composants pour la simulation systme. Enn il permet de capitaliser les dimension-
nements et les tudes ralises pendant le processus de conception, et propose de les
synthtiser sous forme de rapports. Dans cette partie, nous nous interesserons son
implmentation logicielle et aux concepts lis la ralisation de logiciels mtier.
Pour comprendre comment ce dveloppement sest mis en place, je prsenterai dans
ce chapitre la plateforme logicielle existante Cedrat et au G2ELab pour la gnration
de logiciels mtier. Mon objectif ici nest pas de faire une description exhaustive de son
fonctionnement. Je vais cependant essayer, en me plaant dun point de vue utilisateur,
de dgager ses principales fonctionnalits et ses atouts. Pour des informations plus
dtailles, je me rfre la thse de Yves Souchard [31]. Enn les outils que nous
avons dvelopps dans cette plateforme pour personnaliser le logiciel gnraliste Flux
un mtier seront prsents.
5.2 La FluxFactory
5.2.1 Principe
Cedrat et le G2ELab ont commenc en 2002 un projet appel FluxLab visant
dvelopper une plateforme pour la cration de logiciels mtiers. Cette plateforme, ap-
68
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
5. Modliser un mtier 69
pelle FluxFactory, a pour but de diminuer drastiquement les cots de dveloppement
et de maintenance des logiciels de simulation et de garantir leur volutivit. La plate-
forme dveloppe est base sur lide que lon peut modliser un logiciel plutt que le
coder. On peut retrouver cette notion dans la littrature sous le nom de Model Driven
Architecture (Architecture pilote par modle) [30] [33] [34].
La plateforme est constitue de deux composants :
FluxBuilder qui est un logiciel permettant de dcrire le modle dun logiciel et
de le sauvegarder sous forme de chier.
La FluxCore qui est une machine virtuelle. Elle interprte un modle dcrit dans
FluxBuidler et excute le logiciel correspondant. Le logiciel excut contient dj,
sur la base du modle, une IHM complte, un langage de commande et la gestion
de la base de donnes (cration/dition/destruction de donnes, sauvegarde,...).
Fig. 5.1 Le modle dun logiciel : description et excution avec les composants de la
FluxFactory
Cette architecture est particulirement bien adapte la ralisation de logiciels
mtier. La ralisation dun logiciel mtier demande de repenser compltement linter-
face et les concepts manipuls, or cette plateforme permet de crer une interface sans
avoir la coder. Le seul code rside dans limplmentation des algorithmes mtier.
Pour mieux comprendre ce fonctionnement gnral, je prsenterai de manire plus
prcise la faon de dnir un modle dans FluxBuilder.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
5.2.2 La description du modle de donnes
Le diagramme UML :
Pour dcrire un logiciel, on commence dabord par la dnition de son modle de
donnes. Ce modle de donnes correspond la description des objets qui pourront
tre manipuls par lutilisateur. Dans le monde du gnie logiciel, le formalisme UML
(Unied Modelling Language) [32] est reconnu et trs utilis. Notamment grce au
diagramme de classes, il permet de dnir un modle de donnes structur, maintenable
et volutif. Cest donc sur la base de ce formalisme que lon peut dcrire et visualiser
un modle de donne dans FluxBuilder.
Fig. 5.2 Visualisation du diagramme UML dans FluxBuilder
Les entits et les attributs :
Dans FluxBuilder, une entit dcrit un objet ou une partie dun objet que lutil-
isateur pourra manipuler dans le logiciel de simulation. Elle contient un nom et des
attributs. Ces attributs dcrivent la structure des paramtres de lobjet. Prenons lex-
emple du modle dun logiciel mtier moteur. Il nous faut dcrire comment lutilisateur
pourra dnir un moteur dans le logiciel. Le moteur est constitu dun rotor et dun
stator. Il nous faut donc dnir une entit pour chacun de ces objets. Lentit "Ro-
tor" par exemple permet de dcrire les paramtres que devra renseigner lutilisateur
pour dnir le rotor dun moteur. Les attributs de lentit "Rotor" sont : le nombre
de ples, le rayon extrieur ou le rayon de larbre (Figure 5.3). Ils portent un nom et
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
peuvent tre de dirents types : certains sont des entiers (Integer), dautres des rels
(Double) ou des chanes de caractres (String). Certains sont de cardinalit multiple :
un attribut peut tre de type tableau de rels par exemple.
Fig. 5.3 Lentit rotor et ses attributs
Certains attributs peuvent tre des entits que le dveloppeur a dcrit prcdem-
ment. Lentit "Moteur" par exemple contient un attribut de type "Rotor". Un attribut
de type entit peut tre li de deux faons direntes : par association ou par agrga-
tion. Prenons lentit "Moteur" qui a un attribut "Rotor". Dans le cas de lagrgation,
la dnition du rotor est interne celle du moteur. Dans le cas de lassociation, la
dnition du rotor est externe celle du moteur, cest dire que lutilisateur peut
dnir de manire indpendante un rotor et ensuite lassocier un moteur (Tableau
5.1).
Tab. 5.1 Lattribut rotor de type entit : Association et aggregation
Lhritage :
Les entits peuvent galement avoir des attributs de type entit abstraite. Une
entit abstraite est une entit qui nest pas en soit compltement dnie. En eet,
elle se drive en plusieurs sous-types qui eux sont des entits concrtes. Par exemple,
lentit "Rotor" est abstraite et se dcline en plusieurs topologies de rotor qui sont
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
concrtes, cest dire que lon peut tracer. Lentit abstraite "Rotor" contient des
attributs gnriques qui sont communs toutes les topologies comme le nombre de
ples. Lentit concrte drive, par exemple "Rotor aimants enterrs", contient
des paramtres spciques cette topologie comme lenfoncement des aimants. Cette
dclinaison est appele hritage en UML. On dit que lentit "Rotor aimants enterrs"
hrite de lentit "Rotor". Le diagramme de la Figure 5.4 illustre lvolutivit du
modle de donne et donc du logiciel dvelopper. En eet, pour ajouter une nouvelle
topologie de rotor, il su!t dajouter une entit drivant de lentit rotor.
Fig. 5.4 Lhritage UML pour modliser les direntes topologies
Les mthodes et les commandes :
Sur chaque objet on peut dnir des mthodes. Ces mthodes modlisent des com-
portements de lobjet et sont des commandes que lon peut lui associer. Par exemple,
sur lobjet moteur, on peut ajouter des mthodes comme "Mailler()" (Figure 5.5). Le
modle de donne contient galement la description des commandes que lon retrouvera
dans les menus et les barres dicnes du logiciel que lon cherche dcrire. Ces comman-
des sont dcrites par un nom et des arguments. Par exemple, la commande "Import
moteur SPEED" contient un argument qui est lemplacement du chier SPEED
importer.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 5.5 La mthode mesh() dans lentit moteur
5.2.3 La description du modle de prsentation
Le modle de donnes dcrit donc les concepts mtiers qui seront manipuls par
lutilisateur. Ce modle de donnes conditionne normment lIHM du logiciel de si-
mulation. La FluxCore se propose daller plus loin. Etant base sur des composants
informatiques rutilisables et congurables, elle permet de lancer automatiquement le
logiciel correspondant au modle dcrit. Pour cela, la description UML a t enrichie.
En plus du nom dune entit ou dun attribut, le dveloppeur dcrit son label anglais et
franais et son nom dans le langage de commande. Enn, le dveloppeur peut associer
chaque attribut ou entit une image et du texte pour dnir une aide contextuelle.
La machine virtuelle est alors capable dinterprter ce modle et de le retranscrire sous
forme de botes de dialogue et de commandes textuelles. Par exemple en reprenant le
modle trs simple de la gure 5.4, lhritage UML qui correspond un choix nces-
saire de topologie de rotor est traduit automatiquement par la machine virtuelle dans
lIHM par un bouton de choix (Figure 5.6). On retrouve galement les paramtres du
modle. Dans le modle dune entit, il est galement possible de dnir des onglets
dans lesquels on pourra ranger les attributs.
Toute application construite avec la FluxFactory bncie immdiatement dun
langage de commande. Comme pour les botes de dialogues, ce langage est construit
sur la base du modle de donnes. Le langage utilis est le python. Ce language est trs
utilis pour le script et permet aussi la programmation objet. Toute action ralise de
manire graphique peut donc galement tre ralise laide dune commande python
(Figure 5.7). Aujourdhui, pour tre pilotable, un logiciel se doit davoir un langage de
commande. Lavoir moindre cot constitue un rel atout.
Une fois le modle dcrit, FluxBuilder propose galement au dveloppeur dorgan-
iser lIHM de son application. La description du modle de donnes et des commandes
et donc des botes de dialogue nest pas su!sante, il faut maintenant dcrire com-
ment ces botes seront accessibles dans linterface du logiciel. Puisque la plateforme
est ddie la gnration de logiciels de simulation, linterface graphique se prsente
toujours de la mme faon. Ainsi la FluxFactory propose au dveloppeur un certain
nombre de composants qui constitueront linterface de son logiciel et dans lesquels il
pourra placer son modle de donnes :
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 5.6 Bote de cration dun moteur gnre par la FluxCore partir du modle
de la Figure 5.4
Fig. 5.7 Commande python de cration dun moteur, base sur le modle de la
Figure 5.4
Un arbre qui permet de crer, modier ou dtruire des objets correspondant aux
entits du modle de donnes.
Des menus permettant daccder aux mthodes des objets qui se trouvent dans
larbre.
Des menus et des barres dicnes pour accder aux commandes dcrites dans le
modle de donnes.
Des contextes dutilisation qui ont chacun leur propre organisation de larbre et
des menus.
Une fentre pour copier et excuter le langage de commande.
La dernire chose dcrire est le mode de reprsentation des donnes. Ceci peut
tre ralis par ce que lon a appel des a!cheurs. Il en existe plusieurs : la fentre
graphique (reprsentant la gomtrie, le maillage, les dgrads, etc...), les courbes, les
rapports, les modles UML. Ceux ci sont cods une fois pour toute dans la factory
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 5.8 Composition de lIHM dans les logiciels de la FluxFactory. (Exemple avec
Flux)
et le dveloppeur peut dcider de reprsenter via ces a!cheurs les donnes qui seront
cres par lutilisateur. Dans le cas de la fentre graphique, le dveloppeur peut choisir
des formes quil souhaite reprsenter (comme des points, des lignes, des faces, des
dgrads). En plus de dnir une forme, il indique o trouver les coordonnes de ces
formes : directement dans les attributs dune entit ou dans un algorithme dont il
spcie lemplacement. Cest la mme chose pour les courbes, le dveloppeur ajoute
un a!cheur courbe dans un contexte. Ensuite il spcie dans le modle de donnes o
il peut trouver les donnes relatives ses courbes.
5.2.4 La machine virtuelle
Une fois le modle dcrit (aucune ligne de code na encore t crite), il est inter-
prt par la machine virtuelle qui le traduit dans le logiciel de simulation souhait.
Celui-ci contient dj :
Une IHM complte
La possibilit de crer, modier ou dtruire des objets
La persistance des donnes (sauvegarde et ouverture de projet)
La gestion du langage de commande
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
La reprsentation des donnes dans des a!cheurs de graphiques 2D et 3D, de
courbes, etc...
On comprend immdiatement que tout le code rside dans la machine virtuelle. Ce
code est certes plus complexe quun code classique du fait de sa gnricit mais il est
cod une seule fois pour tous les logiciels. Cette mthode a donc plusieurs avantages :
Le processus de dveloppement est fortement diminu puisquun grand nombre
de services et de composants sont dj cods et sont congurables par modle.
Lvolutivit du logiciel est assure grce une bonne structuration des donnes.
Cette mthode de dveloppement est un vritable atout dans lapproche mtier.
Sur la base des paramtres dun mtier, on peut immdiatement visualiser lin-
terface du logiciel. Ds la phase de spcication logicielle, face un expert du
mtier qui nest pas forcment famili avec les concepts UML, on peut lui mon-
trer lIHM et ainsi alimenter la discussion. En fait, FluxBuilder devient un outil
de spcication avec le client ou lexpert mtier.
Cependant, ce stade du dveloppement, la manipulation des objets dans le logiciel
ne correpond qu de la cration, modication et destruction de donnes. Les objets
nont pas encore de comportement mtier. De mme les commandes que lon peut
retrouver dans les menus ou les barres dicnes apparaissent mais ne produisent aucun
eet. Cest pourquoi FluxBuilder permet de gnrer des templates (en Java ou en For-
tran) qui correspondent au modle de donnes et aux commandes. En remplissant ces
templates, le dveloppeur crit les algorithmes mtiers ncessaires au fonctionnement
complet du logiciel. Ces templates sont gnres en marge du code de la FluxCore car
elles correspondent un code spcique quon appelle surcharge (Figure 5.9). Cette
phase constitue la seule phase de codage la main pour le dveloppeur. Elle a donc t
fortement rduite par rapport une approche plus traditionnelle. Cest sur ce principe
que Flux a t compltement refondu avec une implmentation des donnes en Fortran
(langage historique de Flux). Cest galement sur ce principe qua t dveloppe lin-
terface du logiciel doptimisation GOT. Cette fois limplmentation a t ralise en
Java pour la richesse et la robustesse de ce language object. Il est amusant de noter que
FluxBuilder lui aussi est construit sur ce principe, cest dire quil se dcrit lui-mme !
5.3 Les bibliothques mtier
5.3.1 Surcharger le modle du logiciel Flux
La FluxFactory permet donc de gnrer rapidement de nouveaux logiciels de si-
mulation. Cependant cette dmarche demande encore un certain niveau de comp-
tences informatiques. Dans lapproche mtier, cest dabord le logiciel Flux que nous
souhaitons personnaliser. Ceci an de rendre son utilisation plus rapide et plus simple
pour un mtier donn. Devant le nombre de mtiers auxquels le logiciel Flux peut
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 5.9 Rutilisabilit du FluxCore pour les logiciels Flux
rpondre, on peut penser que de nombreuses personnalisations devront tre dvelop-
pes dans lavenir. Cest pourquoi nous souhaitons mettre en place une dmarche de
personnalisation du logiciel Flux qui soit la plus simple et la plus rutilisable possible.
Lidal serait de permettre un utilisateur expriment de Flux de mettre en place
lui-mme la personnalisation de Flux lie son mtier.
Personnaliser le logiciel Flux signie introduire dans le logiciel de nouveaux objets.
Ces objets ont un comportement plus complexe que les objets standards de Flux et
permettent dautomatiser un enchainement de tches dans Flux souvent rptes par
lutilisateur. Dans le cas des moteurs lectriques, des objets proposent des topologies de
moteur et automatisent leur construction dans le logiciel. Le maillage est automatique
et des mthodes danalyse classiques sont proposes.
Flux tant construit sur le principe de la FluxFactory, il est dcrit par un modle.
Pour personnaliser Flux et lenrichir de nouveaux objets, nous devons donc enrichir
le modle de Flux, existant. En ajoutant dans le modle de Flux le modle des ob-
jets moteurs, des tudes et des rsultats et en les plaant dans larbre dun nouveau
contexte ddi, on pourra, suite une commande, ouvrir ce contexte et prsenter
lutilisateur de Flux une toute nouvelle interface ddie ltude des moteurs. Cepen-
dant, cette solution nest pas encore tout fait satisfaisante. En eet, avec la stratgie
prsente, le modle du logiciel Flux pourrait devenir trs important et di!cilement
maintenable. De plus, souhaitant donner accs cette dmarche de personnalisation
au plus grand nombre, le dveloppement des interfaces mtier ne doit pas se situer au
niveau du modle de Flux qui relve du domaine rserv des dveloppeurs de Flux.
Nous proposons donc que le modle ddi un mtier soit dcrit sparment et charg
dynamiquement dans Flux.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 5.10 Schma de principe du chargement dune extension dans la FluxFactory
Nous avons cr dans Flux un contexte vide et une commande permettant de
charger un modle mtier et de le placer dans ce contexte vide. Une fois le modle
mtier choisi par lutilisateur (Figure 5.11), le nouveau contexte est ouvert et une nou-
velle interface apparat avec de nouveaux objets ddis ltude des moteurs (Figure
6.7). Ainsi la description dun modle peut se faire sparment et nest plus lie au
dveloppement du logiciel Flux. Cette notion de modle mtier que lon peut charger
dans Flux est appele contexte mtier. A tout moment, on peut quitter le contexte
mtier et retourner dans un contexte de Flux pour des possibilits de gomtries,
dtudes ou dexploitations illimites.
5.3.2 Implmenter ce modle dans le language de commande de Flux
Pour dnir le comportement dans Flux des nouveaux objets mtier, nous de-
vons galement prvoir une implmentation de leur modle. Cette implmentation
sera charge dans Flux en mme temps que le modle mtier. Elle contiendra la de-
scription de lenchainement des commandes Flux raliser partir des valeurs des
objets mtiers crs pour automatiser la construction de la gomtrie, eectuer une
tude ou a!cher des rsultats. Toujours parce que nous souhaitons que le dveloppe-
ment de ces extensions soient accessibles au plus grand nombre, nous avons introduit
dans la FluxFactory une implmentation des objets mtiers dans le langage de com-
mande de Flux savoir Python. En eet, Flux tant construit suivant le principe de la
FluxFactory, toute action dans le logiciel est reproductible laide dune ligne de script
Python, ce langage est donc idal pour dcrire le comportement des objets mtier. De
plus, ce langage est bien connu des utilisateurs avancs de Flux, qui nauront ainsi pas
de problmes pour dvelopper leur propres extensions.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 5.11 Commande permettant de charger un contexte mtier dans Flux
Fig. 5.12 Interface ddie ltude des moteurs dans Flux
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Les templates
Aprs avoir dni le modle de lextension, on gnre des templates python. Une
classe python est cre par entit prsente dans larbre. Nous avons souhait une
structuration des templates la plus simple possible. Ces classes sont composes de
quatre mthodes remplir en Python permettant dassocier un comportement (cest
dire des commandes Flux) la cration, modication et destruction des objets mtiers
(Figure 5.13).
Fig. 5.13 Template python gnre
La mthode check(model) Appele par la FluxCore avant chaque cration ou
modication dun objet mtier, la mthode check() vrie si les valeurs des paramtres
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
renseigns par lutilisateur (qui sont fournis en argument de la mthode dans lobjet
model ) sont corrects et nintroduisent pas de problmes. Une erreur avec un message
expliquant le ou les paramtres qui posent problme peut tre a!che lutilisateur et
la cration ou la modication de lobjet nest pas ralise. Pour les objets moteur, cette
mthode contient un ensemble de rgles gomtriques assurant une bonne construc-
tion. Elles vrient notamment que les ctes indiques nentrainent pas dintersection
de ligne ou dincohrences comme un rayon de larbre plus grand que le rayon ex-
trieur du rotor. Ces rgles sont trs importantes car elles assurent lutilisateur un
bon fonctionnement du logiciel et le guident quant aux erreurs qui surviennent. Pour
le dveloppement des objets moteur, pour sassurer que ces rgles dnissent correcte-
ment lensemble des moteurs traables, nous avons mis en place des procdures de
tests alatoires qui remplissent la bote moteur et tente de construire la gomtrie. Si
la gomtrie ne se trace pas et quaucun message derreur nest apparu, on dtecte
quil manque une rgle de gomtrie.
Fig. 5.14 Exemple de code dune mthode check
La mthode build(model) Cette mthode contient le code Python des actions
raliser dans Flux la cration de lobjet. Pour les objets moteur, cette mthode
contient le code python permettant de construire la gomtrie et le maillage du moteur
partir des valeurs des paramtres contenus dans model. Si le nombre de lignes de
code est important, une mthode comme build() peut faire appel dautres mthodes
ou dautres objets Python crs par le dveloppeur. On peut donc structurer le code
Python et ainsi le rendre plus lisible et plus maintenable (Figure 5.15).
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 5.15 Exemple de code de la mthode build
La mthode delete() Cette mthode contient le code Python des actions raliser
dans Flux pour la destruction dun objet. Pour les objets moteur, il sagit de dtruire
la gomtrie cre en dtruisant par exemple, le repre de dnition de la gomtrie
(Figure 5.16).
La mthode modify(model, changes) Cette mthode contient le code raliser
lors dun changement de paramtres. Bien sr lapproche la plus simple pour grer une
modication consiste dtruire et reconstruire lobjet en faisant appel successivement
aux mthodes delete() et build(). Cependant, la FluxCore fournit galement en argu-
ment lobjet changes qui contient les demandes de changements lmentaires qui ont
t souhaits. Ainsi on peut modier de manire plus ne la gomtrie. On peut par
exemple simplement modier la valeur dun paramtre gomtrique au lieu de tout
reconstruire an doptimiser le temps du changement (5.17).
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 5.16 Exemple de code de la mthode delete
Fig. 5.17 Exemple de code de la mthode modify
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Les commandes
Des templates pour les commandes sont galement gnres. Elles se prsentent
sous la forme dun chier qui contient une fonction Python correspondant la com-
mande et ses arguments.
5.3.3 Un gnrateur de bibliothques mtiers : XBuilder
Le modle dun contexte mtier est beaucoup plus lger que celui dune applica-
tion complte. En eet le modle est limit la description du modle de donnes
mtier, des commandes, des menus et de larbre qui seront chargs dans le contexte
vide de Flux prvu cet eet. Il est inutile de dcrire des a!cheurs ou un modle
graphique puisquils existent dans Flux. Cest pourquoi un logiciel spcique, appel
XBuilder, a t dvelopp pour dcrire ces modles mtiers. Bas sur les comptences
de FluxBuilder, ce logiciel est beaucoup plus simple daccs et ne contient que les
informations strictement ncessaires. Il bncie galement dun diteur Python pour
remplir les templates sous une seule interface de dveloppement (Figure 5.18). Cedrat
envisage de commercialiser ce logiciel prochainement, ce qui permettra de proposer
aux utilisateurs avancs de Flux de dvelopper leur propre personnalisation de Flux.
5.3.4 Sauvegarde
Pour avoir une intgration totale de ces objets mtiers dans un projet Flux nous
avons travaill sur la sauvegarde de ces objets. Au chargement dun contexte mtier,
un objet est cr. Celui-ci contient lemplacement du modle et du code correspondant
au contexte mtier. De plus la sauvegarde, les objets mtiers crs sont srialiss et
stocks dans cet objet. Ainsi louverture dun projet on charge de manire habituelle
le projet Flux, ensuite on lit lobjet ce qui permet de recharger le contexte et de
dsrialiser les objets mtiers.
5.4 Conclusion
Jai donc prsent brivement le fonctionnement de la plateforme logicielle Flux-
Factory. Elle permet, par la dnition dun modle bas sur le langage UML, de gnrer
rapidement linterface et la gestion des donnes dun logiciel de simulation. Elle per-
met galement une implmentation java ou fortran des donnes. Le logiciel Flux est
construit sur ce principe. Cette plateforme assure nos logiciels, la rduction des cots
de dveloppement et de maintenance et une bonne volutivit.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 5.18 XBuilder : Dnition du modle de donnes et des templates python dun
contexte mtier
Pour rpondre au besoin de personnalisation du logiciel Flux, toujours dans lop-
tique de simplier et dacclrer son utilisation, nous avons dvelopp la notion de
contexte mtier. Ce dveloppement a consist ajouter dans Flux une commande
permettant de charger dynamiquement un modle mtier. Cette fonctionnalit ajoute
dans Flux de nouveaux objets et construit une nouvelle interface mieux adapte un
mtier prcis. De plus nous avons introduit dans la FluxFactory la possibilit dimpl-
menter ces objets mtier dans le langage de commande de Flux (Python) et ainsi de
dcrire les actions raliser dans Flux la manipulation de ces nouveaux objets. Grce
au logiciel XBuilder le dveloppement dun contexte mtier est relativement simple et
devient accessible un utilisateur avanc. Le dveloppement dune IHM ddie util-
isant la puissance de calcul de Flux nest plus rserve aux seuls dveloppeurs de Flux,
ce qui devrait faciliter la cration dun grand nombre de personnalisations mtier dans
lavenir.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Chapitre 6
Modliser le mtier moteur dans
Flux
6.1 Introduction
Aprs avoir prsent le principe de la FluxFactory et le dveloppement ralis
sur la notion de contextes mtier, nous pouvons maintenant envisager la faon dont
va se mettre en place le dveloppement du logiciel FluxMotor. La premire tape
est de personnaliser Flux au mtier de la conception et de lanalyse des moteurs.
Pour cela nous avons dvelopp des contextes mtier pour dirents types de moteurs.
Certains ont t commercialiss pour leur partie gomtrique. Dans ce chapitre je
prsenterai la mise en place du contexte ddi ltude des moteurs brushless aimants
et notamment le modle de donnes ralis partir de la spcication prsente dans
la premire partie.
6.2 Le modle UML des moteurs aimants
6.2.1 Lentit moteur
Dans un premier temps lobjectif de ce contexte est de permettre lutilisateur de
crer des gomtries de moteurs aimants dans Flux partir de paramtres gnraux.
Pour dnir quels sont ces paramtres, nous avons cr dans le modle une entit
MotorBPM dont une partie du modle est reprsent Figure 6.1. Cette entit regroupe
les paramtres gnraux du moteur comme la longueur dentrefer (GAP) ou la longueur
de fer (stack_length). Lentit MotorBPM contient galement des champs lis une
dnition lments nis comme la densit de maillage (mesh_factor) ou le paramtrage
de la bote innie (InniteBox) comme on a pu le spcier dans la premire partie.
Pour dcrire les topologies de rotor, de stator, le modle de bobinage ou lexistence
ou non dexcentricits, lentit moteur contient des champs de type entit abstraite.
86
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
6. Modliser le mtier moteur dans Flux 87
Ces entits sont Rotor, Stator, Winding et Excentricity. Elles se drivent en plusieurs
sous-types qui dnissent les paramtres des direntes topologies.
Fig. 6.1 Lentit moteur et ses attributs dans le modle de la BPM Overlay
6.2.2 Les topologies rotor
Nous avons vu dans la premire partie que les rotors aimants se dclinent en
plusieurs familles de topologies, et en dirents enfoncements des aimants au sein de
chaque famille. Lentit Rotor se drive donc en sous-types correspondants aux dif-
frentes familles de rotor. Ces sous-types contiennent le champ magnetType de type
entit abstraite qui se drive en plusieurs sous-types correspondants aux enfoncements
des aimants. Une petite partie de ce modle est reprsente Figure 6.2. On peut gale-
ment retrouver dans lentit Rotor, les matriaux fer (Core), aimant (Magnet) et le
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
matriau de larbre (Shaft) en association, ce qui signie que les matriaux seront
dnis de manire spare et utilisables par dirents moteurs.
Fig. 6.2 La classication des topologies rotor dans le modle UML (4 reprsentes,
36 en ralit)
6.2.3 Les topologies stator
La modlisation UML dun stator est reprsente Figure 6.3. Lentit Stator pos-
sde des champs gnraux comme le nombre dencoches (NSLOTS) ou la prsence ou
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
non de dents bifurques (statorConguration). Lentit abstraite Stator se drive en
plusieurs sous-types correspondant aux direntes formes dencoches (StatorSquare,
StatorPllSlot, StatorRound). Chacune des formes dencoches possde ses propres para-
mtres (SD : slot depth/profondeur dencoche, SO : slot opening/ouverture dencoche,
etc...). Lentit Stator comporte galement un champ de type LamShape ("Lamina-
tion shape") reprsentant la forme de la carcasse et qui se dcline en plusieurs formes
(Circle : circulaire ; RectRound : rectangulaire avec extrmits arrondies).
Fig. 6.3 Diagramme UML de la dnition des stators
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
6.3 Le modle UML du bobinage
6.3.1 Les types de bobinages
Le modle UML du bobinage est reprsent Figure 6.4. On retrouve dans ce mo-
dle la possibilit de choisir un bobinage personnalis ou classique avec la prsence des
entits CustomWinding et ClassicalWinding qui hritent de lentit Winding. Avec
un bobinage personnalis, on dnit chacune des phases (WindingPhase) constitues
de bobines (WindingCoil ) dnies par une encoche aller, une encoche retour et un
nombre de spires. Avec un bobinage classique, on a le choix dun type de bobinage
(WindingType) qui peut tre un bobinage imbriqu (LapWinding), concentrique (Con-
centricWinding) ou pas fractionnaire (FracSlotWinding). A la construction dun
bobinage classique, on value le tableau des phases, cest pourquoi lentit Classical-
Winding possde un attribut WindingPhase, mais cet attribut est calcul par pro-
gramme et non fourni par lutilisateur. Les attributs values par programme sont
marqus dun underscore. Ainsi on peut noter les attributs _Rstack, _Rend et _Lend
dans lentit Winding qui stockent les rsistances de phases et inductances de ttes de
bobines qui seront calcules par le logiciel.
6.3.2 Les modles de ttes de bobines
La dnition du modle utilis pour le calcul des ttes de bobines est reprsent par
lattribut de type EndWindingModel. Il se dcline en cinq sous-types correspondant
aux modles prsents dans la premire partie (Alger, Kostenko, etc...).
6.4 Le modle UML des matriaux
Les matriaux peuvent tre dcrits de manire indpendante. Dans le modle, les
entits qui dcrivent la dnition des matriaux hritent toutes de lentit MotorMa-
terial. Cette entit contient un attribut mass qui reprsente la masse volumique. Il
permettra notamment de calculer linertie du rotor.
6.4.1 Le cuivre
Lentit Copper hrite, comme tous les matriaux, de lentit MotorMaterial. Deux
entits hritent de lentit cuivre : CopperAWG et CopperUserValue. Dans un cas on
dnit le cuivre en choisissant le numro dune bobine de lAmerican Wire Gage (dont
la classication sera donne dans une image daide), dans lautre on dnit une rsis-
tivit, un coe!cient de temprature et une section. La section peut tre circulaire ou
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 6.4 Modle UML du bobinage dans la BPM Overlay
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
rectangulaire (ce qui est modlis par la prsence des entits CircularCopperSection et
RectangularCopperSection) et on dnit lpaisseur de lisolant (modlis par le champ
insulator_thickness). Les coe!cients de foisonnement seront valus la construction
du moteur et stocks dans les champs _ll_factor et _copper_ll_factor de lentit
Winding (Figure 6.4).
Fig. 6.5 Modle UML du matriau cuivre
6.4.2 Les matriaux rotor et stator
Le modle UML des matriaux utiliss pour les carcasses rotor et stator est reprsent
par lentit Core Figure 6.6. Lentit Core a un attribut proprit B(H) (CoreProp-
ertyBh) et un attribut proprit J(E) (MaterialPropertyJe). Plusieurs modles de
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
courbes B(H) sont proposs. On dnit galement les coe!cients de Bertotti pour
le calcul des pertes fer dans lentit BertottiIronLosses.
Fig. 6.6 Modle UML des matriaux de la carcasse rotor et stator
6.4.3 Les aimants
Le modle des aimants est trs proche de celui des matriaux de la carcasse. Cepen-
dant, les modles de courbes B(H) proposs sont dirents.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
6.4.4 LIHM
Une fois le modle UML dcrit, les paramtres dun moteur et des matriaux sont
dnis. Pour amliorer linterface, nous avons ajout des icnes sur les entits, des
pages daide sur les attributs et rangs certains attributs dans des onglets. De plus
nous avons dni dans XBuilder un modle darbre, dans lequel nous avons plac
lentit MotorBPM et un rpertoire Matriaux dans lequel nous avons plac les entits
Copper, Core, Magnet, etc...
On peut charger ce modle dextension dans Flux. Le logiciel interprte ce modle
et fait apparatre un nouveau contexte dans le quel on retrouve larbre dcrit. En
cliquant dans larbre on peut par exemple crer un moteur. La bote de dialogue de
cration de moteur apparat alors. Cette bote correspond au modle de donnes dcrit
dans XBuilder.
Fig. 6.7 Arbre de lextension BPM Overlay
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 6.8 Bote de dialogue de dnition dun moteur sans balais aimants
Tab. 6.1 Exemple de moteur BPM cr dans le contexte mtier
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
6.4.5 Les templates Python
Cette IHM permet de crer des objets moteur et matriaux, mais nimplique au-
cune action dans le logiciel Flux. Nous avons donc ralis une implmentation Python
des comportements mtier. Pour lobjet MotorBPM, la template dcrit les actions
permettant de tracer la gomtrie, de dnir les densits de maillage et daecter les
rgions. Pour les matriaux, les templates crent un matriau Flux correspondant aux
paramtres rentrs par lutilisateur. Certains paramtres sont valus. Ainsi on calcule
dans les templates python les valeurs des composants circuit (rsistances des phases,
inductances des ttes de bobines).
6.5 Le modle UML des essais normaliss
Le contexte mtier permet donc pour le moment lutilisateur de dnir son moteur
et ses matriaux, ce qui implique la construction de sa gomtrie et de son maillage dans
Flux. Une fois ce moteur construit nous chercherons raliser des tudes sur ce moteur.
Pour faciliter lutilisation, nous souhaitons proposer des tudes prcbles qui ont t
dcrites dans la premire partie. Nous avons donc dni, dans le modle, des entits
dnissant les paramtres de ces essais. Toutes ces entits hritent de lentit Test qui
contient la mthode run() permettant dautomatiser laectation de la physique et
de lancer le calcul. Une partie du modle des essais qui reprend la spcication de la
premire partie est reprsente Figure 6.9.
Fig. 6.9 Modles des essais
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
En plus dautomatiser le calcul, nous souhaitons faciliter lexploitation des rsul-
tats. Nous avons donc modlis les exploitations standards comme la fem induite, le
couple de dtente ou les schmas quivalents. A la n dun calcul ces rsultats sont
crs automatiquement par les templates python. A partir de larbre lutilisateur peut
a!cher ou cacher les rsultats. Ces rsultats font rfrence au Moteur et lessai qui
ont permis de le calculer. Toutes les entits rsultats hritent de lentit Result (Figure
6.10). Cette entit contient deux mthodes. La mthode show() permet da!cher un
rsultat. La mthode addToReport() permet dajouter la synthse de ce rsultat dans
un rapport.
Fig. 6.10 Modle des rsultats
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 6.11 Lancement du calcul dun essai sans bobinage - Modlisation des rsultats
dans larbre
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
6.6 Les autres moteurs
Bases sur les mmes principes que la bibliothque de moteurs sans balais aimants
permanents (BPM), dautres bibliothques moteur ont t dveloppes pendant la
thse. Il sagit de bibliothques gomtriques pour les machines asynchrones, les ma-
chines courant continu aimants, les machines reluctances variables.
Dans le cadre dun projet de recherche nomm Arema, dont Valo est le leader et
auquel Cedrat participe, une bibliothque complte comprenant la dnition mtier
dun moteur gries et ses mthodes danalyse est dveloppe. Pour ces travaux, la
partie CAO est trs importante, de mme que la qualit du maillage et la possibilit
de rsoudre de gros problmes avec prise en compte des courants de Foucault. La
ralisation dune bibliothque pour les machines BPM 3D ux axial est envisage. Les
bibliothques 3D peuvent reprsenter un rel atout. Les outils analytiques se limitent
souvent au 2D et la qualit du logiciel gnraliste lments nis ncessaire pour faire
tourner ces simulations de moteurs en 3D est importante. Enn cest en 3D que les
problmes sont les plus longs et les plus di!ciles dcrire, lapproche mtier est donc
dautant plus intressante.
Fig. 6.12 Synthse des bibliothques moteur dveloppes
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 6.13 Dnition dune machine asynchrone
Fig. 6.14 Exemple de machine asynchrone gnre dans Flux
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
6.7 Conclusion
Dans ce chapitre jai prsent la faon dont on a structur les donnes du contexte
ddi ltude des moteurs brushless aimants. Il permet la dnition dun objet
moteur. Une fois le moteur dni, des objets correspondants aux tudes prcbles
peuvent tre dnies par lutilisateur. A la n du calcul dune tude, les rsultats
sont directement visualisables via une simple mthode. Une dernire mthode permet
lajout des donnes dans un rapport, mais cette fonctionnalit sera explique plus en
dtail dans le prochain chapitre.
Avec la technologie des contextes mtier, nous avons donc rpondu notre objectif
de personnalisation de Flux au mtier moteur. Son utilisation est plus simple et plus
rapide. De plus, Flux est maintenant capable de dialoguer facilement avec des logiciels
ddis au mtier du moteur, puisquil partagent avec eux les mmes paramtres mtier.
Une fonction dimport dun moteur dni dans le logiciel SPEED a donc pu tre
dveloppe facilement dans Flux. Cette fonction lit les paramtres dun moteur dans
SPEED et cre une ligne python permettant la construction du moteur dans le contexte
ddi.
Cependant, cette mthodologie nest pas su!sante la ralisation dun logiciel
moteur. En eet le logiciel Flux est mono-projet, ce qui veut dire quil ne peut grer
dans un projet quune seule gomtrie et une seule application physique. Les objets du
contexte tant internes au projet Flux, lutilisation est limite la construction dun
seul moteur et au calcul dune seule tude.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Chapitre 7
Lapplication moteur
7.1 Introduction
Les contextes mtier dvelopps pour les machines tournantes rendent le logiciel
Flux plus facile de prise en main. Son utilisation ne ncessite pas de connaissances par-
ticulires en lments nis. Lintroduction dun modle ddi aux machines lectriques
rend aise la communication avec les autres outils de la conception. Grce limport
SPEED, on peut rapidement passer dune tude de prdimensionnement une tude
lments nis. Cependant, Flux et ses bibliothques ne permettent lautomatisation
que dun moteur et dune tude par projet. Or le concepteur cherche caractriser un
moteur compltement et donc raliser plusieurs tudes. De plus il cherche comparer
les performances respectives de plusieurs dimensionnements ou types de machines.
Cest pour rpondre toutes ces attentes que nous proposons le dveloppement
de FluxMotor. Ce nouveau logiciel est capable de capitaliser les rsultats de plusieurs
tudes ralises sur dirents moteurs. Il utilise Flux en tant que serveur de calcul et
masque la complexit lie la gestion des projets Flux. Le dveloppement dun tel
logiciel comporte plusieurs tapes que je prsenterai dans ce chapitre :
Cration du modle de FluxMotor avec FluxBuilder et validation de son inter-
face.
Mise en place dun serveur de calcul Flux.
Ecriture dun gestionnaire de serveur Flux.
Rcupration des rsultats.
7.2 Le modle de lapplication
FluxMotor contrairement aux contextes mtier constitue un nouveau logiciel. Il a
donc t construit avec FluxBuilder. Son modle de donnes est bas sur ceux des
contextes ddis aux moteurs dans Flux. Pour le complter, nous avons labor un
modle graphique proche de celui de Flux. Il permet de reprsenter la gomtrie, le
102
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
7. Lapplication moteur 103
Fig. 7.1 Reprsentation du bobinage sur la gomtrie du moteur
Fig. 7.2 Reprsentation panoramique du bobinage
maillage ou les dgrads qui seront rccuprs partir de Flux. Des reprsentations
graphiques spciques au bobinage des moteurs ont galement t ajoutes (Figures
7.1, 7.2). Le logiciel FluxMotor bncie galement de la!cheur courbe et un a!cheur
rapport a t introduit.
7.3 Larchitecture Client/Serveur
Une fois le modle de donnes dni et linterface graphique valide, nous devons
implmenter ces objets en java de manire leur donner un comportement. Pour les
objets moteur, le principe de lalgorithme consiste piloter Flux de manire ce quil
ouvre le contexte ddi correspondant et quil cre le moteur. Une fois le moteur cr
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 7.3 Principe du pilotage de Flux par FluxMotor
dans Flux, FluxMotor recupre les informations graphiques. Au lancement dun calcul
cest le mme principe : FluxMotor pilote Flux pour lancer le calcul et rcupre les
rsultats. Puisque FluxMotor bncie du mme modle que les contextes moteur de
Flux, la ligne de commande Python permettant de crer un moteur est la mme dans
les deux logiciels. Le pilotage de Flux consiste donc simplement lui envoyer les lignes
python de cration dun moteur ou de lancement dun calcul.
Pour permettre cette implmentation du modle de FluxMotor nous devons donc
dvelopper un serveur Flux rpondant deux services fondamentaux qui sont :
Interprter et excuter une ligne Python
Retourner les rsultats
Maintenant que les services sont dnis, nous devons choisir une architecture et
une technologie de communication. Pour cela, nous devons rappeler que le dveloppe-
ment dun serveur Flux sera rutilis par dautres logiciels mtier et par des logiciels
doptimisation comme GOT. En eet ces logiciels peuvent demander de nombreux
calculs Flux et nous devons anticiper le besoin de faire du calcul distribu, cest
dire rpartir les calculs sur un parc dordinateurs sur lesquels tournent des serveurs
Flux. Cest pourquoi nous avons choisi dutiliser une architecture Client/Serveur. Dans
cette architecture deux programmes tournent en mme temps : le programme Client
(FluxMotor) qui est demandeur de services, et le programme serveur (Flux) qui ralise
des services et retournent le rsultat au client. Ces programmes peuvent communiquer
entre eux en local (sur une mme machine) ou distance (via un rseau). La technolo-
gie utilise est le RMI (Remote Method Invocation)[35] qui est fournie dans le langage
de programmation Java.
Cette architecture doit rpondre plusieures exigences :
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Elle doit tre volutive, cest dire quelle doit tre capable de supporter les
volutions futures du logiciel comme lintroduction de nouveaux services.
Elle doit galement permettre le pilotage des autres logiciels bass sur le principe
de la FluxFactory (Flux2D, Flux3D, Inca, GOT, etc...)
Le serveur Flux ne prsente pas dinterface grahique.
Elle doit ncessiter le moins de modications possibles sur le code actuel. Elle
doit notamment permettre de continuer dvelopper en parallle Flux en lo-
cal et Flux en Client/Serveur. Autrement dit le choix entre un fonctionnement
client/serveur ou local doit se faire au lancement du logiciel.
An de prsenter larchitecture Client/Serveur mise en place, je dois dabord prsen-
ter larchitecture du logiciel Flux. Cette architecture est primordiale puisque cest elle
qui doit voluer en client/serveur. Cest pour une meilleure maintenance, une meilleure
lisibilit du programme et donc une meilleure volutivit que le logiciel Flux, et plus
particulirement le FluxCore, est architectur en modules regroupant chacune des
fonctionnalits spciques (Figure 7.4). Un module est un ensemble de composants
partageant le mme espace de nommage. Tout module possde une frontire avec le
monde extrieur bien dnie et limite.
Les modules du FluxCore existant aujourdhui sont :
Le Frontal (le bureau) : Ce module est responsable de la!chage graphique.
Le GUI Generator (GUI = Graphic User Interface) : Ce module soccupe
de la construction de fentres graphiques (a!ches ensuite par le frontal)
Le TUI Interpreter (TUI = Textual User Interface) : Ce module inter-
prte les saisies ralises par lutilisateur dans les botes et les lignes de comman-
des python
Le Kernel (le noyau) : Ce module supervise lapplication et gre la base de
donnes
Dautres modules sont quant eux plus spciques lapplication Flux (ils se
trouvent dans la surcharge) :
Le Modeler 3D : Il gre les visualisations 3 dimensions de Flux
La Physique : Il contient les quations de la physique
Le Solver : Il ralise les calculs pour la rsolution
On constate galement, la Figure 7.4, lutilisation de deux bases de donnes pour
lapplication : la mta base qui contient le modle du logiciel, et la base de donnes
projet , correspondant aux donnes cres par lutilisateur.
Les modules communiquent entre eux via un bus. Chacun dentre eux est de-
mandeur (client) de services et fournisseur (serveur) de services. On peut distinguer
cependant la notion de services et de notications. Dans le cas de la notication, un
module envoie une information un ou des modules sans attendre de valeur de retour.
Au dmarrage de Flux, les modules se lancent puis se connectent au bus qui fait lui
mme les liaisons entre les demandeurs et les fournisseurs dun mme service ou dune
mme notication.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 7.4 Architecture modulaire du logiciel Flux
A partir de cette architecture et pour raliser le logiciel FluxServeur, nous devons
adapter le programme de lancement de Flux au fonctionnement Serveur. Dabord,
le module frontal qui constitue la!chage graphique nest daucune utilit. Nous ne
lancerons donc pas ce module au dmarrage de Flux en mode Serveur. Cela naectera
pas le fonctionnement des autres modules, car le module frontal nest pas fournisseur
de services (il est seulement noti ou demandeur de services). De plus, nous devons
ajouter un module capable de rpondre aux deux services fondamentaux du serveur
Flux que nous avons identis. Nous avons donc dvelopp un nouveau module appel
ProxyServeur. Ce module donne accs aux deux services du serveur sur un port de
la machine. Au dmarrage, ce module se connecte galement sur le bus de manire
rediriger vers le TUI Interpreter et le Kernel chacun des services quil ore. Grce
ces dveloppements le logiciel Flux peut tre lanc en tant que serveur et propose
les deux services spcis. Pour faciliter le pilotage de Flux, nous avons galement
dvelopp un code Java qui sert de poigne pour le logiciel Client (Handle) et qui
masque la complexit du code dappel distance des services proposs par le serveur
Flux (Figure 7.5). Cette architecture est volutive puisque nous pouvons facilement
ajouter de nouveaux services dans le module ProxyServeur et dans la poigne Client.
De plus elle est applicable toutes les logiciels construits partir de la FluxFactory.
7.4 La gestion transparente des chiers
Une fois le serveur Flux en place, nous pouvons commencer limplmentation du
modle du logiciel FluxMotor. Cette implmentation consiste envoyer au serveur Flux
les lignes de commande Python de cration de moteur et du lancement dun calcul.
Cependant, comme FluxMotor permet de construire plusieurs moteur et de raliser
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 7.5 Pilotage du logiciel Flux par FluxMotor
plusieurs tudes sur chacun deux, nous devons implmenter une gestion des projets
Flux. Sous le projet FluxMotor, on sauvegarde un chier par gomtrie de moteur et
un chier par tude. Ainsi ldition dun moteur ou la!chage des rsultats dun
essai, on pourra rouvrir sur le serveur le projet Flux correspondant. Grce cette
mcanique, la gestion des chiers Flux est compltement masque lutilisateur et il
peut conserver sous un mme projet FluxMotor lensemble des tudes quil a ralis
pendant la conception.
7.5 Les rapports
Puisque lapplication FluxMotor permet de conserver les direntes tudes ralises
pendant la conception, nous avons souhait travailler sur la prsentation des donnes et
notamment sur la notion de rapport automatique. Pour que ces rapports puissent tre
utilisables et modiables par lutilisateur, nous devons gnrer des rapports dans des
formats standards comme word, open o!ce, pdf ou html. Cette notion de rapport doit
tre rutilisable pour toute personnalisation mtier de Flux. Ainsi lapproche mtier
permet de raliser rapidement une tude et de gnrer un rapport.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Dans FluxMotor, la notion de rapport se prsente sous la forme dune mthode
"ajouter au rapport" applicable chacun des objets crs par lutilisateur. Pour im-
plmenter cette mthode, une premire solution consiste coder, pour chacun des
objets, lcriture directe dun chier au format html ou word xml. Cependant cette
mthode est di!cilement modiable et nest pas accessible lutilisateur. De plus ce
code ne prote pas lensemble des logiciels de la FluxFactory.
Cest pourquoi nous avons choisi dutiliser une technologie appele transformation
xml [37]. Cette technique est divise en deux partie. Dans un premier temps, une
mthode dexport permet dcrire sous forme xml [36] nimporte quel objet cr par
lutilisateur. Ce chier xml contient toutes les donnes sources ncessaires au rapport
et les balises correspondent au modle de lobjet. A cet export xml on peut associer
une feuille de style au format xsl. Cette feuille de style dnit le format de sortie et la
faon dont se prsente les donnes dans le rapport. Ainsi un module de transformation
xml permet de gnrer le rapport. Les formats de sortie proposs par la transformation
xml sont le format txt, html et xml document. Le format xml document [38] est un
standard xml permettant de dcrire assez simplement un document. Il est beaucoup
plus simple par exemple que les formats xml word ou open o!ce. De plus, des modules
open source permettent partir dun chier xml document de gnrer du word, du
latex, de lopen o!ce ou du pdf.
Cet export xml a t dvelopp dans la FluxCore. Il est donc prsent dans Flux-
Motor mais aussi dans Flux et ses contextes mtiers. Avec cette technologie, introduire
la notion de rapport automatique dans un logiciel de la FluxFactory ou dun contexte
mtier consiste crire une feuille de style pour la mise en forme des donnes. Le code
est donc extrieur au code du logiciel. De plus cette feuille de style peut tre rem-
place si un utilisateur souhaite avoir sa propre feuille de style. Ainsi il peut mettre
ses rapports la norme des documents de sa socit par exemple.
7.6 Exemple dutilisation de FluxMotor
Aprs avoir prsent les dirents dveloppements qui ont t entrepris pour Flux-
Motor, je propose maintenant de les illustrer rapidement au travers dun cas dappli-
cation :
La socit Cedrat Technologie participe un projet europen appel MuFly. Elle
aide travers des mesures et des tudes dterminer le moteur qui entrainera lhlice
dun petit hlicoptre avec camra embarque. Ces travaux pourront dailleurs donn
lieu des tudes de conception pour amliorer les performances des moteurs existant.
Ce projet a donn lieu des simulations lments nis dont une partie constituera
ici notre cas dapplication. Lobjectif est de comparer rapidement les performances de
deux moteurs brushless rotor extrieur. Ces deux moteurs ont le mme stator mais
la forme des aimants au rotor dire (Figures 7.7 et 7.8). Pour discuter de linuence
des aimants, un essai vide sera dabord simul pour chacun des deux moteurs avant
de passer lessai en charge.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
7.6.1 La gomtrie
Grce une dnition mtier des moteurs, base sur le choix des topologies et le
rglage des paramtes associs, les gomtries sont cres en quelques secondes dans
FluxMotor. La dnition mtier du bobinage propose des algorithmes qui calculent
la rpartition des bobines dans les encoches. Dans le cas prsent, les moteurs ont 12
ples et 9 encoches. On utilise donc lalgorithme de bobinage pas fractionnaire. Deux
paramtres su!sent alors dnir le bobinage :
le pas du bobinage qui est gal 1 (bobinage par dent)
le dcalage entre les phases qui ici est gal 2 encoches (pour une bonne rpar-
tition spatiale des phases on utilise souvent la formule : o)):ct =
2
3

Qvorwv
Qsrohv
+
/
2WQvorwv
Qsrohv
, / = 1, 2, 3, ...)
Cette dnition mtier permet de crer deux projets Flux qui contiennent dj :
la gomtrie du moteur, le maillage et la rpartition des rgions. Par rapport une
utilisation classique de Flux, plusieurs tches ont t automatises, ce qui reprsente
un gain de temps non ngligeable pour lutilisateur (Figure 7.6).
Fig. 7.6 Construction de la gomtrie dun moteur dans Flux et dans FluxMotor
7.6.2 Les matriaux
Une fois les gomtries dnies, lutilisateur dnit les matriaux des carcasses
rotor et stator (Figure 7.9), des aimants et du l de cuivre utilis pour le bobinage (le
nombre de spires par bobines est renseign dans la dnition mtier de la rpartition
du bobinage).
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 7.7 Dnition mtier du moteur brushless rotor extrieur aimants droits
Fig. 7.8 Dnition mtier du moteur brushless rotor extrieur aimantation radiale
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 7.9 Dnition dun matriau magntique pour les carcasses rotor et/ou stator
dans FluxMotor
7.6.3 Les tudes
Dans FluxMotor, les essais que lon peut raliser sur un moteur sont des objets
manipulables par lutilisateur et donc rapidement dnis (Figures 7.10 et 7.11)
Lessai vide
Aprs avoir dni les matriaux, trois paramtres su!sent dnir lessai vide.
Ces paramtres sont :
La vitesse
Le nombre de pas de temps calculs sur la priode lectrique
Le type de connexion entre les phases (toile ou triangle)
Une fois lessai cr, on peut lappliquer un moteur, ce qui lance automatiquement
le calcul sur le serveur Flux. A la n du calcul, les rsultats attendus comme la fem
sont directement accessibles dans larbre. Le mme essai est ensuite appliqu lautre
moteur. FluxMotor permettant de conserver les rsultats sous un mme projet, on
peut comparer les fem des deux moteurs (Figure 7.12).
On constate que la fem du moteur aimants courbes (en noir la gure 7.12) a une
plus grande amplitude, ce quoi on pouvait sattendre puisque le volume des aimants
est plus important. Elle est de forme plus trapzodale que la fem aimants droits. Le
moteur aimants courbes devrait donc avoir un meilleur couple moyen lors de lessai
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 7.10 Dnition dun essai vide dans FluxMotor
Fig. 7.11 Denition de lessai en charge dans FluxMotor
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 7.12 Comparaison des fem du moteur aimants droits et du moteur aimants
courbes.
en charge. Le moteur aimants droits ayant une fem pratiquement sinusodale devrait
tre mieux adapt un fonctionnement en rgime synchrone.
Lessai en charge
Passons maintenant lessai en charge. Deux essais seront raliss vitesse nomi-
nale :
Lun avec une alimentation des phases en courants en crneaux (fonctionnement
BDC)
Lautre avec une alimentation des phases en courants sinusodaux (fonction-
nement PMSM)
La mme amplitude des courants sera utilise dans les deux essais.
Les paramtres ncessaires la dnition dun essai en charge (Fig 7.11) sont :
Le nombre de calculs raliss sur la priode lectrique
La vitesse
La forme des courants et leur amplitude
Le type de branchement entre phases (toile ou triangle)
Comme pour lessai vide, on compare les rsultats obtenus par les deux moteurs.
Les rsultats obtenus conrment le fait que le moteur aimants courbes a un couple
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 7.13 Ondulations de couple obtenues par les moteurs lors dun essai en charge
avec alimentation en crneaux
Fig. 7.14 Ondulations de couple obtenues par les moteurs lors dun essai en charge
avec alimentation en courants sinusodaux
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 7.15 Comparaison des ondulations de couple obtenues pendant les deux essais
Fig. 7.16 Visualisation des dgrads de B lors de lessai en charge
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
moyen en charge plus important que le moteur aimants droits. Cependant il entrane
des ondulations de couple plus fortes. Avec une alimentation sinusodale, les couples
moyens sont lgrement plus faibles, mais les ondulations de couple diminuent encore
pour le moteur aimants droits.
A travers ces quelques calculs, on constate que lapproche mtier facilite lutilisation
et rduit le temps de ralisation dune tude (Figure 7.17). La dnition du calcul de
lessai en charge dun moteur en lments nis qui prenait presque deux heures dans
une utilisation classique de Flux (en comptant la dnition de la gomtrie) prend
maintenant moins de 5 minutes. De plus, conserver les rsultats de plusieures machines
lors des essais permet de faciliter la comparaison des performances et aide capitaliser
la connaissance mtier.
Fig. 7.17 Dnition dun essai en charge dans Flux et FluxMotor
Pendant une phase de conception, ce gain de temps peut tre utilis par le con-
cepteur pour explorer plus de solutions. Le paramtrage mtier permet de changer
rapidement des paramtres discrets comme la topologies du rotor ou le nombre den-
coches du stator.
On peut penser que cette approche facilitera galement la dnition mtier dun
problme doptimisation. Sur ce sujet une thse va commencer cette anne. Le travail
devrait consister, dans un premier temps, dvelopper de nouveaux algorithmes dans
le logiciel doptimisation GOT. Ces algorithmes devraient permettre de construire
des surfaces de rponse plus facilement exploitables en utilisant la connaissance de
modles analytiques simples des dispositifs tudis. Dans un deuxime temps, ces outils
doptimisation seront intgrs dans des logiciels mtier tels que FluxMotor.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
7.7 Conclusion
Dans ce chapitre, les travaux raliss sur le superviseur FluxMotor ont t prsen-
ts. Ce logiciel pilote Flux et capitalise lensemble des tudes ralises pendant une
conception sous un seul projet. Le logiciel devrait proposer par la suite dautres types
de machines. Cette architecture permet galement denvisager le pilotage dautres lo-
giciels et des bibliothques de machines 3D (machines gries, moteur Flux axial,
calcul 3D des inductances des ttes de bobines) pourront tre introduites. Cela nous
permettra aussi de proposer des mthodes doptimisation. Nous envisageons denrichir
le modle du logiciel FluxMotor de manire ce quil puisse proposer la dnition dun
problme doptimisation de manire mtier, cest dire base sur la modlisation des
paramtres mtier du moteur et de ses rsultats. Loptimisation sera alors ralise par
pilotage du logiciel doptimisation GOT (logiciel de la FluxFactory). Ce travail fera
lobjet dune nouvelle thse.
Enn ces travaux ont eu un intrt pour Flux, puisquune architecture Client/Serveur
a t dveloppe et permet un logiciel extrieur de piloter le logiciel Flux distance
ou en local via une API Java simple.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Chapitre 8
Autres exemples de
bibliothques mtier
8.1 Introduction
Les technologies mises en place avec les contextes mtiers et le pilotage de Flux
en Client/Serveur sont rutilisables pour dautres mtiers et facilitent la dmarche
de couplage avec un autre logiciel mtier. Dans la premire tape, Flux sapproprie le
langage du logiciel mtier. Ensuite le couplage devient plus facile, puisquil constitue de
la simple lecture/criture de donnes de haut niveau. La dmarche de personnalisation
du logiciel Flux dans le cadre du projet FluxMotor a donc pu tre rutilise pour
dautre projets.
8.2 Les actionneurs linaires
Dans le cadre dun stage de master ralis au G2Elab et en partenariat avec Schnei-
der, le prototype dun contexte ddi ltude des actionneurs linaires a t dvelopp
(Figure 8.1). Cette bibliothque permet la denition dactionneurs simples comme des
contacteurs en U, E, etc... des noyaux plongeurs, des dclencheurs. Des tudes per-
mettent dautomatiser le calcul des courbes de force en fonction du courant et de la
tension pour un export sous forme de tables vers les logiciels de la simulation systme.
Une tude permet denchainer plusieurs calculs transitoires pour dterminer lechelon
de tension minimal qui permet la fermeture du contacteur, ceci par un processus de
dichotomie. Cette dmarche pourrait tre relativement longue avec une manipulation
la main de Flux. A ces actionneurs simples, Schneider envisage dajouter leurs propres
produits. Les performances et caractristiques de leurs produits pourront ainsi tre
rapidement retrouves. De mme leur comportements dans un nouvel environnement
pourra tre tudi plus facilement grce lexport vers la simulation systme.
Du point de vue de Schneider, une telle application reprsente de nombreux avan-
tages :
118
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
8. Autres exemples de bibliothques mtier 119
Fig. 8.1 Contexte ddi ltude des actionneurs linaires
Lutilisation de Flux est plus simple et plus e!cace (Les di!cults dutilisation
sont caches derrire linterface mtier pour des utilisateurs non spcialistes)
Elle acclre la recherche de solutions techniques (La dnition dun dispositifs
et dune tude est automatise)
Elle aide la modlisation pour lapproche systme (Des exports vers les logiciels
de la simulation systme sont prdnis)
Elle capitalise de la connaissance (sur les dispositifs et sur les mthodes danalyse
par lments nis)
La spcication a t ralise Schneider. Le stagiaire a ensuite pu se former
XBuilder et Flux au G2ELab et a dvelopp un prototype. Cela illustre bien
lintrt de disposer de XBuilder pour raliser rapidement des contextes mais aussi
pour les faire voluer en interne avec ses propres produits (qui sont soumis une
certaine condentialit).
8.3 Le contrle non destructif
CIVA [44] est un logiciel mtier pour le contrle non destructif. Il propose un
module ultra sons, et un module courants de Foucault par des mthodes de calcul semi
analytiques. CIVA est dvelopp par le CEA et commercialis par le groupe Cedrat.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Dans le cadre du projet Mutsic, Cedrat a ralis un prototype permettant le calcul par
lments nis des tudes du module courants de Foucault. Pour faciliter le couplage
avec Flux, un contexte mtier qui contient le mme modle de dnition des donnes
que CIVA a t dvelopp. Le modle mtier contient la denition dune pice, dun
dfaut, des capteurs constituant la sonde, puis du dplacement et de lalimentation
de la sonde. Ensuite pour raliser le couplage avec CIVA, Flux est utilis comme
serveur de calcul et larchitecture client/serveur prsente dans le chapitre prcdent
est rutilise.
Grce aux contextes mtiers ce projet a t une russite et a donn lieu un
nouveau projet plus ambitieux appel PLAYA. Cet exemple illustre les possibilits
quorent lapproche mtier pour se coupler avec dautres logiciels.
Fig. 8.2 Dnition dun capteur (Correspond au modle UML de la gure 8.4)
Fig. 8.3 Une sonde avec une bobine emmettrice et une bobine rceptrice sur le dfaut
dune plaque
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Fig. 8.4 Partie du modle du contexte ddi au contrle non destructif (Modles
dun capteur)
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
8.4 Conclusion
Dautres exemples dapplication mtier ont t prsentes dans ce chapitre. Leur
dveloppement a t facilit par lintroduction dans Flux de la notion de contexte
mtier. Avec le logiciel XBuilder, les utilisateurs peuvent dvelopper leurs propres
contextes mtier ou simplement complter des contextes existant.
Les contextes mtier sont particulirement bien adapts pour des travaux ou des
calculs rptitifs et permettent de diminuer le temps de dnition dun problme. De
plus Flux devient plus accessible et peut tre utilis par des personnes peu ou pas
familires avec les lments nis.
Cette technologie a galement facilit le couplage de Flux avec dautres logiciels.
Dabord Flux peut obtenir le mme modle de donnes et donc les mmes param-
tres par le dveloppement dun contexte mtier. Ensuite, avec le dveloppement du
FluxServeur, Flux peut tre pilot en client/serveur et recevoir les lignes python con-
tenant la valeur des paramtres mtier. Cest ce qui a t fait avec les logiciels CIVA
et FluxMotor.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Conclusion
Les logiciels de calcul par lments nis se sont imposs pour la conception des
machines lectriques. Ils permettent une valuation plus prcise des performances de
la machine et de son rendement. Cependant leur interface gnraliste demande souvent
du temps pour la dnition du problme et de la formation, ce qui limite encore leur
utilisation. Le travail eectu a vis mieux intgrer le logiciel Flux dans le processus
de conception des machines lectriques.
Ce travail a aboutit la ralisation de contextes ddis aux machines lectriques
dans Flux. Mme si le travail sest concentr sur les machines sans balais aimants
permanents, le dveloppement a commenc pour les machines asynchrones, les ma-
chines courant continu et les machines gries. On envisage de continuer avec les
moteurs reluctance variable et les moteurs ux axial.
Pour des utilisateurs non spcialistes, ces contextes donnent accs aux mthodes
de calcul par lments nis travers une dnition mtier du problme rsoudre
plus simple et plus rapide. Ils acclrent galement dans une phase de conception la
recherche dune solution technique. De plus ils capitalisent une certaine connaissance
du mtier moteur et proposent lutilisateur un certain nombre de topologies et de
mthodes danalyses classiques des machines lectriques. Enn lintroduction de mo-
dle de donnes mtier permet un couplage avec les autres logiciels de la conception.
Une fonction dimport de moteurs SPEED a t dveloppe et permet de passer plus
facilement du prdimensionnement au dimensionnement. De plus les tudes classiques
permettent lidentication des schmas quivalents des moteurs, et un export au format
VHDL-AMS vers les logiciels de la simulation systme est prvu.
Le prototype dun logiciel ddi la conception des moteurs appel FluxMotor a t
dvelopp. Il utilise Flux et ses contextes ddis comme serveur de calcul et des outils
pour la visualisation du bobinage ou la gnration de rapports ont t raliss.Grce
une approche multi-projet, lutilisateur peut capitaliser lensemble des moteurs tudis
et les rsultats obtenus pendant le processus conception. Larchitecture propose pour
ce logiciel prvoit le pilotage dautres logiciels utiles la conception. Dans un premier
temps, les outils doptimisation seront tudis. En eet ces outils sont de plus en plus
utiliss pendant la conception mais sont encore di!ciles daccs. FluxMotor proposera
une dnition mtier et donc plus simple du problme doptimisation. Bas sur une ar-
chitecture client/serveur, il pourra distribuer les calculs ncessaires loptimisation sur
plusieures machines. Cependant loptimisation sur des modles numriques pose encore
123
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
CONCLUSION 124
des problmes de cot et des modles compacts type surface de rponse sont souvent
utiliss. Grce notre environnement mtier, on pourra tudier des mthodes utilisant
la connaissance de modles analytiques simples pour amliorer la construction des sur-
faces de rponse. Ces travaux sur loptimisation devraient nous amener rchir
la modlisation du processus de conception et la capitalisation de lhistorique du di-
mensionnement. Llaboration dun modle commun pour les logiciels moteur (partage
des mme paramtres) et les divers couplages entre logiciels devraient conduire une
interface unique pour la conception des machines lectriques.
La mthodologie de personnalisation du logiciel Flux dveloppe dans le cadre de
ce projet moteur est rutilisable pour dautres mtiers. La notion de contexte mtier
chargeable dynamiquement propose lutilisateur dintroduire de nouveaux objets
dans Flux et une nouvelle interface. Ces contextes ont lavantage de simplier lutil-
isation du logiciel Flux. De plus ils capitalisent de la connaissance mtier. Ils nous
aident galement mieux comprendre le mtier des utilisateurs et ainsi mieux an-
ticiper leurs attentes. Avec le dveloppement de XBuilder, il est maintenant possible
pour un expert Flux de dvelopper sa propre personnalisation. Ceci devrait faciliter le
dveloppement de nombreuses interfaces mtier dans lavenir. Grce ce gnrateur
dapplications mtier et larchitecture pilote par modle, une grande partie du code
est factoris dans la machine virtuelle. Ainsi, malgr une probable augmentation du
nombre de logiciels mtiers, le cot de maintenance est matris. Enn cette approche
facilite le couplage de Flux avec les autres logiciels puisquelle permet de partager le
mme modle de donne. Ceci devrait permettre de mieux insrer le logiciel Flux dans
des PLM (Product Life Management) par exemple.
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
Bibliographie
[1] Design of Brushless Permanent-Magnet Motors
J.R. Hendershot Jr., TJE Miller (1994)
[2] Guy Seguier, Francis Novotel,
Electrotechnique Industrielle, Technique et Documentation, 1996
Standards
[3] IEEE Standard 115-1995
"Test Procedures for Synchronous Machines"
[4] Commission Electrotechnique Internationale (CEI), Publication 34-4, 1985
"Machines lectriques tournates. Partie 4 : Mthodes pour la dtermination
partir dessais des grandeurs des machines synchrones."
Modles quivalents et calcul des paramtres
[5] Jacek F. Gieras, Ezio Santini, Mitchell Wing, "Calculation of synchronous re-
actances of Small Permanent-Magnet Alternating-Current Motors : Comparison
of Analytical Approach and Finite Element Method with Measurements", IEEE
Transaction on Magnetics, vol 34, no 5, September 1998
[6] Hans-Peter Nee, Louis Lefevre, Peter Thelin, Juliette Soulard
"Determination of d and q Reactances of Permanent-Magnet Synchronous Motors
Without Measurements of the Rotor Position"
IEEE Transactions on Industry Applications, vol 36, no5 September/October 2000
[7] Fidel Fernandez, Aurelio Garcia-Cerrada, Roberto Faure
"Determination of Parameters in Interior Permanent-Magnet Synchronous Motors
With Iron Losses Without Torque Measurement"
IEEE Transactions on Industry Applications, vol 37, no 5, Spetember/October
2001
[8] P. Zhou, M. A. Rahman, M. A. Jabbar, Field Circuit Analysis of Permanent
Magnet Synchronous Motors
IEEE Transactions on Magnetics, vol 30, no 4, July 1994
125
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
BIBLIOGRAPHIE 126
[9] Bernd Klckl, Measurements Based Parameter Determination of Permanent Mag-
net Synchronous Machines,
Diploma Thesis, Graz University of Technology, 2001
[10] A. B. Dekordi, A. M. Gole, T. L. Maguire,
"Permanent Magnet Synchronous Machine Model for Real-Time Simulation"
International Conference on Power Systems Transients (IPST05), Paper IPST05-
159, Montreal June 2005
[11] Tomy Sebastian, Gordon R. Slemon
"Transient Modeling and Performance of Variable-Speed Permanent-Magnet Mo-
tors"
IEEE Transactions on Industry Applications, vol 25, no 1, January/February 1989
[12] Stefan Henneberger, Uwe Pahner, Kay Hameyer, Ronnie Belmans
"Computation of a Highly Saturated Permanent Magnet Synchronous Motor for
a Hybrid Electric Vehicule"
IEEE Transactions on Magnetics, vol 33, no 5, Spetember 1997
[13] Y.-K. Chin, J. Soulard, "Modeling of Iron Losses in Permanent Magnet Syn-
chronous Motors with Field-Weakening Capabiblity for Electric Vehicules
International Journal of Automotive Technology, vol 4, no 2, p 87-94, 2003
[14] Longya Xu, Xingyi Xu, Thomas A. Lipo, Donald W. Novotny,
"Vector Control of a Synchronous Reluctance Motor Including Saturation and
Iron Losses"
IEEE Transactions on Industry Applications, vol 27, no 5, September/October
2001
[15] Julius Luukko, "Direct Torque control of permanent magnet synchronous ma-
chines - analysis and implementation"
Lappeenranta University of Technology, Finland, 2000
[16] Albert Foggia,
"Mthodes de calcul des inductances de fuites",
Techniques de lingnieur, trait gnie lectrique, D3 440, 2-1999
Bobinage
[17] Jacques Saint-Michel, "Bobinage des machines tournantes courant alternatif"
Techniques de lingnieur, trait gnie lectrique, D3 420
[18] Flux 3D application technical paper, End winding characterization
[19] Stphanie Richard, "Etude lectromagntique des parties frontales des alterna-
teurs en rgime permanents et transitoires"
Thse de doctorat, Institut National Polytechnique de Grenoble, 1994
[20] P.L. Alger, "Induction Machines - Their Behaviour and Uses",
Gordon and Breach, Science publisher inc., New York, 1970
[21] S. Williamson, M.C. Begg,
"Calculation of the resistance of induction motor end rings",
IEEE Proceeding, Part B, vol 133, 1986
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
BIBLIOGRAPHIE 127
[22] P. Trickey, "Induction motor ring width",
IEEE Trans. Amer. Inst. Elect. Eng., vol 55, pp. 144-150, 1936
Duxage
[23] Shigeo Morimoto, Tomohiro Ueno, Masayuki Sanada, Yoji Takeda, Takao Hirasa,
"Variable Speed Drive System of Interior Permanent Magnet Synchronous Motors
for Constant power Operation"
PCC Yokohama, TH0406-9/93
[24] Nicola Bianchi, Silverio Bolognani,
"Parameters and Volt-Ampere Ratings of a Synchronous Motor Drive For Flux-
Weakening Applications",
IEEE Transactions on Power Electronics, vol 12, no 5, Spetember 1995
[25] Ayman M. EL-Refaie, Donald W. Novotny, Thomas M. Jahns,
"A Simple Model For Flux Weakening in Surface PM Synchronous Machines
Using Back-to-Back Thyristors"
IEEE Power Electronics Letters, vol 2, no 2, June 2004
Optimisation
[26] Laurent Jolly, M. A. Jabbar, Liu Quinghua
"Design Optimization of Permanent Magnet Motor Using Response Surface
Methodology and Genetics Algorithms"
IEEE Transactions on Magnetics, vol 41, no 10, October 2005
[27] Jean-Louis Coulomb, "Optimisation", chapitre 8 de "Electromagntisme et prob-
lmes coupls", "Electromagntisme et lments nis 3D", EGEM, Hermes, 2002
[28] J. W. Bandler, Q. S. Cheng, S. A. Darkoury, A. S. Mohamed, M. H. Bakr, K.
Madsen, Jacob Sondergaard,
"Space Mapping : The State of the Art",
IEEE Transactions microwave Theory tech., vol 52, no 1, January 2004
[29] A. Kechroud, "Association dun modle prcis mais coteux et dun modle
approch mais rapide pour acclrer loptimisation dune soupape magntique",
Mmoire Master 2 Recherche, G2Elab, 2006
Informatique
[30] Yves Marchal, "Vers une nouvelle gnration de logiciels de simulation pour
llectromagntisme et les disciplines connexes",
Habilitation diriger des recherches, Institut National Polytechnique de Grenoble,
2001
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
BIBLIOGRAPHIE 128
[31] Yves Souchard, "Ralisation dune plate-forme informatique ddie au mtier du
gnie lectrique autour des logiciels Flux. Application la ralisation de logiciels
mtiers."
Thse de doctorat, Institut National Polytechnique de Grenoble 2005
[32] Unied Modeling Language, V2.0, http ://www.uml.org
[33] Model Driven Architecture, http ://www.omg.org/mda
[34] Meta Object Facilities, V1.4, http ://www.omg.org/mof
[35] Remote Method Invocation,
http ://java.sun.com/javase/technologies/core/basic/rmi/index.jsp
[36] XML en concentr, ditions Oreilly, 2005
[37] XSL Transformation, http ://www.w3.org/TR/xslt
[38] Extensible StyleSheet Language (XSL), http ://www.w3.org/TR/xsl
[39] IEEE Standard VHDL-AMS Reference Manual, IEEE Std 1076.1-1999, IEEE,
1999
Logiciels
[40] Flux, a nite element simulation environment for Electrical Engineering,
http ://www.cedrat.com
[41] Portunus, a system simulation software dedicated to control command,
http ://www.adapted-solutions.com
[42] SPEED, Scottish Power Electronics ans Electric Drives consortium,
Speed Laboratory, Glasgow, Scotland, http ://www.speedlab.co.uk
[43] MotorCAD, http ://www.motor-design.com/
[44] CIVA, htttp ://www-civa.cea.fr
Publications
[45] G. Lacombe, Y. Soucahrd, C. Chantrel, E. LeCathelinais, G. Jrme, X. Brunotte,
Y. Marechal, J. Wallace, D. Dorell,
"Benets of Model Driven Architecture for simulation software design, applica-
tion for dedicated motor tool"
Conference on the computation of Electromagnetic Fields, Compumag 2005,
Shenyang, Liaoning, China, june 2005
[46] G. Lacombe, A. Foggia, Y. Marechal, X. Brunotte,
"From general nite element software to engineering-focused software"
International Symposium on Electric and Magnetic Fields, EMF 2006, Aussois,
France, june 2006
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8
BIBLIOGRAPHIE 129
"Innovating engineering-focused software solution on rotating electrical machines"
International Conference on Electrical Machine, ICEM 2006, Chania, Crete
[48] G. Lacombe, A. Foggia, Y. Marechal, X. Brunotte, P. Wendling,
"From general nite element simulation software to engineering-focused software,
Example for brushless permanent magnet motor design"
IEEE Transactions on magnetics, vol 43, no 4, april 2007
"Innovating engineering-focused software for rotating electrical machines design"
Recent Advances in Aerospace Actuation Systems and Components, Toulouse,
France, june 2007
t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8

Rsum :
Les logiciels Flux sont des logiciels de modlisation des phnomnes lectromagntiques par la
mthode des lments finis. Ils sont particulirement bien adapts pour lanalyse fine des machines
lectriques tournantes. Cependant leur interface gnraliste rend la dfinition dun calcul assez longue
ce qui limite leur utilisation. Les travaux prsents proposent de faire une analyse du mtier de la
conception des machines tournantes, de manire dfinir et raliser un nouveau logiciel ddi, bas
sur les capacits de calcul de Flux . En capitalisant un certains nombre de concepts mtier comme des
topologies de moteur ou des mthodes danalyses classiques, ce logiciel donne un accs plus simple
et plus rapide aux outils numriques dans le processus de conception des moteurs. De plus, les
concepts informatiques utiliss ont permis llaboration dune mthodologie de personnalisation du
logiciel Flux rutilisable pour dautre mtiers et accessible un utilisateur avanc.

Mots cls :
Logiciel de simulation mtier, Conception des machines lectriques, Elments finis, Architecture
pilote par modle.

Abstract:
Flux is finite element software for electromagnetic simulation. It is well-adapted for accurate
analysis of electrical rotating machine. However its use is still limited by a generalist point of view in
the graphical user interface and a long computations definition time. Our work proposes to analyse
electrical machine design process, and then to define and realize a new dedicated software based on
Flux computation capabilities. This software capitalizes dedicated concepts like motor topologies or
classical methods of analysis and gives an easier and faster access to numerical methods in the design
process of electrical machine. This paper also deals with the programming concepts used for the
development of this dedicated software. Thanks to this work, the process to customize Flux software
is reusable for other jobs and can be used by an advanced user of Flux.

Keywords:
Engineering-focused software, Rotating electrical machine design, Finite Elements, Model
Driven Architecture.

t
e
l
-
0
0
2
6
5
7
5
5
,

v
e
r
s
i
o
n

1

-

2
0

M
a
r

2
0
0
8

These Lacombe 2007

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

These Lacombe 2007

Încărcat de

Drepturi de autor:

Formate disponibile

INSTITUT NATIONAL POLYTECHNIQUE DE GRENOBLE

N attribu par la bibliothque

est appel force lectro motrice (fem vide). Il

c|cc) entre laxe d du rotor et linduction statorique

c|cc o 0 est la position du rotor par

c|cc o deux transistors conduisent, lun au moins des transistors doit

c|cc deux transistors peuvent commuter, on

c|cc. Si ce sont les transitors du haut on appelera la

c|cc. La commutation peut se drouler pendant les 60 premiers degrs

S-ar putea să vă placă și