Contribution à l`intégration des systèmes de commande des

N° d’ordre 98 ISAL 0106
1998
THESE
présentée
DEVANT L’INSTITUT NATIONAL DES SCIENCES APPLIQUEES DE LYON
pour obtenir
LE GRADE DE DOCTEUR
FORMATION DOCTORALE : génie électrique
ECOLE DOCTORALE : Electronique, Electrotechnique, Automatique
PAR
Philippe FOUSSIER
Ingénieur INSA
Contribution à l’intégration
des systèmes de commande des machines
électriques à courant alternatif
Soutenu le
10 décembre devant la Commission d’Examen
Jury MM. Nacer ABOUCHI
Jordi CARRABINA
Jean-Pierre CHANTE
Richard GRISEL
Xavier JORDÁ
Bruno MAURICE
Javier UCEDA
Michel ROBERT
examinateur
codirecteur
codirecteur
rapporteur
examinateur
examinateur
examinateur
rapporteur
Cette Thèse a été préparée au Laboratoire CEGELY de l’INSA de LYON et au
Département d’Informatique de l’Université Autonome de Barcelone
rien
2
liste prof 1
3
liste prof 2
4
liste ecole doctorale
5
rien
6
liste formations
7
rien
8
Avant-propos
Le travail présenté ici a été réalisé au sein de trois laboratoires différents: le
Centre de Génie Electrique de l’Institut de Sciences Appliquées de Lyon
(CEGELY - INSA), le Centre National de Microelectronique de Barcelone
(CNM) et le département d’informatique de l’Université Autonome de
Barcelone (UAB).
La diversité des approches scientifiques et les différences culturelles et
linguistiques ont été une expérience enrichissante et passionante. Ma
première pensée s’adresse à tous ceux qui ont soutenu et contribué activement
à cet échange. Je tiens à leur exprimer ma profonde gratitude.
Monsieur Jean-Pierre Chante, Professeur à l’INSA de Lyon, a été à l’origine de
ce projet. Son aide et son soutien m’ont été précieux. Je tiens à le remercier
pour m’avoir encadré et permis de passer en Espagne des moments
inoubliables.
Mes plus vifs remerciements s’adressent aussi à Monsieur Jordi Carrabina,
Maître de Conférence à la UAB, pour avoir assuré la codirection de la thèse
pendant mes nombreux séjours en Catalogne. Je garde de très bons souvenirs
de nos nombreuses discussions aux sujets si variés...
Je suis honoré que Monsieur Richard Grisel¸ Professeur à l’Université
d’Amiens et Monsieur Michel Robert, Professeur à l’Université Montpellier II,
aient accepté d’être rapporteur de cette thèse. Je les remercie en particulier
pour leurs remarques judicieuses.
A Monsieur Nacer Abouchi, Maître de Conférence à l’Ecole de Physique
Chimie et Electronique de Lyon (CPE), je désire exprimer toute ma
reconnaissance pour avoir révisé ce manuscrit et pour son aide lors de la
rédaction.
Pour leur participation au Jury, je remercie Monsieur Bruno Maurice¸
Ingénieur d’application chez STM, et Monsieur Javier Uceda, Professeur à
l’Université Polytechnique de Madrid.
9
Merci aussi à Monsieur Xavier Jordá, chercheur au CNM¸ pour son aide¸ sa
disponibilité et ses conseils précieux, en particulier concernant la commande
des machines asynchrones; sans lui, cette thèse ne serait pas ce qu’elle est.
Finalement, je tiens aussi à citer tous les chercheurs, personnels et étudiants
que j’ai rencontrés dans les différents laboratoires. Pour certains, le souvenir
de la découverte de l’Espagne leur est attaché, pour d’autres, leurs conseils et
les intéressantes discussions techniques m’ont permis de surmonter les
difficultées rencontrées. A tous, ma reconnaissance est assurée. Aux
administrateurs réseaux, Denise, Josep et Ramon, j’adresse un merci à part car
leur aide m’a grandement facilité la tâche. Un grand merci aussi à Pascal
Bevilacqua pour sa collaboration au développement des cartes de
prototypage.
Merci enfin à tous ceux qui, de près ou de loin, ont contribué au succès de
cette thèse.
10
« Où sont les billes? répéta Saphir.
- J’ai une bougie qui ne donne pas, remarqua Wolf.
- Qui a gagné Waterloo ? » interjecta, sans prévenir, le sénateur Dupont,
coupant la parole à Lil.
Ce qui créa un second silence car ce n’était pas prévu au programme. En
manière de parade, les voix conjuguées de Lil et de Folavril s’élevèrent.
« Honni soit qui mal y pense... affirmèrent-elles avec un grand calme.
- Et les vaches seront ourlées au mètre, deux fois », répondirent en canon
perfectionné, Saphir et Wolf.
Pourtant, ils pensaient visiblement à autre chose, car leurs paires d’yeux
avaient cessé d’être assorties.
Boris Vian, « L’herbe rouge »
An meine Eltern
A mes parents
11
12
Table des matières
Table des matières
13
Table des figures
17
Introduction générale
21
1 Chaîne d’entraînement et fonctions génériques de la commande
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 La chaîne d’entraînement . . . . . . . . . . . . . . . . . . . .
1.2.1 Les dispositifs . . . . . . . . . . . . . . . . . . . . . . .
1.2.2 Les modèles pour la commande . . . . . . . . . . . .
1.3 La commande . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Les fonctions génériques de commande . . . . . . . .
1.3.2 Considérations théoriques . . . . . . . . . . . . . . . .
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
26
26
30
31
31
35
38
2 Méthodologies d’implantation d’une fonctionnalité:état de l’art
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Méthode courante pour la conception système . . . . . . . .
2.3 Implantation de la commande de machines électriques AC .
2.3.1 l’intégration applicative . . . . . . . . . . . . . . . . .
2.3.2 L’étude de l’intégration système . . . . . . . . . . . .
2.4 La conception mixte matériel/logiciel . . . . . . . . . . . . .
2.4.1 Détail de la méthode . . . . . . . . . . . . . . . . . . .
2.4.2 Les outils de conception mixte . . . . . . . . . . . . .
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
40
43
43
44
46
48
59
63
3 Élaboration d’une méthodologie d’implantation des commandes de
moteurs AC
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Localisation et formulation des problèmes spécifiques à la commande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Les spécifications floues . . . . . . . . . . . . . . . . . . .
3.2.2 Partitionnement et séquencement . . . . . . . . . . . . .
3.2.3 Le test fonctionnel . . . . . . . . . . . . . . . . . . . . . .
13
65
65
67
67
68
70
3.3
3.4
3.5
3.6
3.2.4 Résumons . . . . . . . . . . . . . . . . . . . . . . . . . .
Les spécifications restrictives . . . . . . . . . . . . . . . . . . .
3.3.1 L’arithmétique . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 Les ressources et l’architecture système . . . . . . . . .
Traitement théorique des problèmes évoqués . . . . . . . . . .
3.4.1 Modélisation de la commande . . . . . . . . . . . . . .
3.4.2 Spécification des temps de la commande . . . . . . . .
3.4.3 Spécification de la précision de calcul de la commande
3.4.4 Le test fonctionnel . . . . . . . . . . . . . . . . . . . . .
Méthodologie d’intégration de la commande . . . . . . . . . .
3.5.1 les langages de modélisation . . . . . . . . . . . . . . .
3.5.2 Le flux de conception . . . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Implantation de la méthodologie:
Solution à base de Grafcet
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Le Grafcet comme modèle en vue de l’intégration . . . .
4.2.1 Rappel des principales caractéristiques du Grafcet
4.2.2 Interprétation du Grafcet . . . . . . . . . . . . . .
4.2.3 Restrictions à la modélisation par Grafcet . . . . .
4.2.4 Survol d’autres langages synchrones . . . . . . . .
4.3 Analyse des modèles Grafcet . . . . . . . . . . . . . . . .
4.3.1 Partitionnement matériel/logiciel . . . . . . . . .
4.3.2 Analyse architecturale . . . . . . . . . . . . . . . .
4.3.3 Estimation de performances . . . . . . . . . . . . .
4.4 Synthèse de code . . . . . . . . . . . . . . . . . . . . . . .
4.4.1 Synthèse du script MATLAB . . . . . . . . . . . .
4.4.2 Affinement des spécifications . . . . . . . . . . . .
4.4.3 Synthèse du code VHDL . . . . . . . . . . . . . . .
4.4.4 Synthèse de code logiciel . . . . . . . . . . . . . .
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Implantation du contrôle vectoriel d’un moteur asynchrone
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Les enjeux de la conception des systèmes de commande .
5.3 Intégration de la commande vectorielle . . . . . . . . . .
5.3.1 Spécification du système de commande . . . . . .
5.3.2 Vérification fonctionnelle . . . . . . . . . . . . . .
5.3.3 Partitionnement et estimation . . . . . . . . . . . .
5.3.4 Synthèse mixte . . . . . . . . . . . . . . . . . . . .
5.4 Résultats des test expérimentaux . . . . . . . . . . . . . .
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion générale
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
71
71
72
72
73
73
74
74
75
80
81
83
86
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
91
91
92
93
94
98
99
100
100
100
107
108
109
109
109
110
110
.
.
.
.
.
.
.
.
.
111
111
113
113
113
121
125
129
133
136
139
14
Bibliographie
146
Annexes
146
A Définitions
147
B Exemple de commande vectorielle
B.1 Le contrôle vectoriel . . . . . . . . . . . . . . . .
B.1.1 Le modèle de la machine asynchrone . .
B.1.2 La commande par flux rotorique orienté .
B.2 La MLI vectorielle . . . . . . . . . . . . . . . . . .
B.2.1 Description de l’algorithme . . . . . . . .
B.2.2 Calcul des instants de commutation . . .
B.2.3 Limites de validité de la MLI vectorielle .
B.2.4 Méthode de limitation . . . . . . . . . . .
B.2.5 Modification de la commande . . . . . . .
B.3 Schéma bloc de l’algorithme de commande . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
C Paramètres du moteur 4 kW
151
151
152
159
164
164
169
169
170
170
171
175
D L’algorithme CORDIC
D.1 L’algorithme CORDIC classique . . . . . . . . . . . . . . . . . .
D.2 Le CORDIC binaire . . . . . . . . . . . . . . . . . . . . . . . . .
D.3 L’algorithme CORDIC généralisé . . . . . . . . . . . . . . . . .
D.4 La normalisation des résultats . . . . . . . . . . . . . . . . . . .
D.5 Extension des limites de convergence . . . . . . . . . . . . . .
D.5.1 Extension des limites de convergence de la rotation . .
D.5.2 Extension des limites de convergence du mode linéaire
D.5.3 Précision du CORDIC étendu . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
E Simulation sous Ptolemy
177
177
179
181
183
185
185
186
190
195
F Traitement des mesures et consignes
F.1 Acquisition des échantillons analogiques
F.1.1 Valeur des courants statoriques . .
F.1.2 Valeur de la consigne de couple . .
F.1.3 Calcul de la mesure de tension . .
F.2 Mesure de la vitesse . . . . . . . . . . . . .
15
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
199
199
200
200
200
201
16
Table des figures
1
chaîne d’entraînement électrique à moteur AC . . . . . . . . . .
22
1.1
1.2
26
1.3
1.4
1.5
1.6
1.7
1.8
1.9
onduleur à trois bras . . . . . . . . . . . . . . . . . . . . . . . . .
tension MLI entre deux phases du moteur avec fondamental de
tension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
interrupteur de puissance avec IGBT et diode . . . . . . . . . .
exemple de période de commutation avec temps mort . . . . .
moteur AC asynchrone à cage d’écureuil . . . . . . . . . . . . .
exemple de hiérarchie de commande . . . . . . . . . . . . . . .
structure de la commande . . . . . . . . . . . . . . . . . . . . . .
exemple de contrôle constant . . . . . . . . . . . . . . . . . .
schéma de principe d’un contrôle vectoriel . . . . . . . . . . . .
27
27
28
29
32
34
36
37
2.1
2.2
2.3
2.4
2.5
2.6
ALU de 32 bits . . . . . . . . . . . . . . . . . . . . . .
Méthode de conception mixte générique . . . . . . .
Spécification fonctionnelle . . . . . . . . . . . . . . .
Exploration de l’espace des solutions de réalisation
Synthèse mixte . . . . . . . . . . . . . . . . . . . . . .
outils de conception testés . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
47
48
51
56
60
3.1
3.2
3.3
3.4
Méthode générique de conception mixte selon Gajski-Vahid
Architecture du système de commande . . . . . . . . . . . .
cosimulation sous MATLAB . . . . . . . . . . . . . . . . . . .
Flux de conception d’un système de commande . . . . . . .
.
.
.
.
.
.
.
.
66
73
84
87
4.1
Modélisation d’un branchement OU par réseau de Pétri et par
Grafcet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple de modélisation par Grafcet . . . . . . . . . . . . . . .
Modèle Grafcet avec branchement ET . . . . . . . . . . . . . . .
Formalisme de condition sur une action en Grafcet . . . . . . . .
Implantation d’actions concurrentes . . . . . . . . . . . . . . . .
Inférence de registres . . . . . . . . . . . . . . . . . . . . . . . . .
Génération de logique combinatoire . . . . . . . . . . . . . . . .
Implantation d’actions concurrentes . . . . . . . . . . . . . . . .
Implantation d’un «indice matériel» . . . . . . . . . . . . . . . .
93
97
98
99
103
104
104
105
105
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
17
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.10 Duplication d’une fonction . . . . . . . . . . . . . . . . . . . . .
4.11 Fusion de deux bus . . . . . . . . . . . . . . . . . . . . . . . . . .
106
106
5.1
5.2
5.3
5.4
5.5
112
114
116
118
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
5.17
5.18
Méthodologie de conception mixte . . . . . . . . . . . . . . . . .
Banc de test de la commande du moteur asynchrone . . . . . . .
Topographie du système de commande . . . . . . . . . . . . . .
Schéma bloc de l’algorithme de commande . . . . . . . . . . . .
Simulation de l’évolution des grandeurs caractéristiques du moteur en fonction du temps (en s) lors d’un démarrage . . . . . .
Défluxage du moteur (fonction du temps en s) . . . . . . . . . .
Grandeurs caractéristiques du moteur en fonction du temps (s)
pour deux périodes d’échantillonnage différentes . . . . . . . .
Modèle de spécification de la commande . . . . . . . . . . . . .
Modèle de spécification du bloc MLI . . . . . . . . . . . . . . . .
Évolution des grandeurs caractéristiques du moteur en fonction
du temps (s) pendant un démarrage:simulation du modèle de
compréhension (gauche) et de spécification (droite) . . . . . . .
Évolution du couple et de la consigne de flux en fonction du
temps (s):simulation du modèle de compréhension (gauche) et
de spécification (droite) . . . . . . . . . . . . . . . . . . . . . . . .
Simulation de la MLI et génération des impulsions . . . . . . . .
Architecture de l’ASIC de commande . . . . . . . . . . . . . . .
Diagramme des signaux du TLC0831 . . . . . . . . . . . . . . . .
Synoptique de la carte de prototypage . . . . . . . . . . . . . . .
Signaux de commande d’un bras de l’onduleur . . . . . . . . . .
Temps mort en fonction de la période d’horloge . . . . . . . . .
Courant à la sortie de l’onduleur, filtré à 50Hz . . . . . . . . . .
B.1 commande de la machine asynchrone dans le repère . . . . .
B.2 Transformée en Z d’un processus du premier ordre régulé par
un PI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.3 Estimation de la constante de temps rotorique . . . . . . . . . .
B.4 Onduleur idéal a trois bras . . . . . . . . . . . . . . . . . . . . . .
B.5 Vecteurs de tension statorique dans le plan . . . . . . . . . .
B.6 Principe de construction du vecteur de tension statorique . . . .
B.7 Algorithme pour déterminer le secteur angulaire . . . . . . . . .
B.8 Séquences MLI en fonction du secteur angulaire (repéré par ) .
B.9 Méthode anti-dérive Franklin-Powell . . . . . . . . . . . . . . .
B.10 Schéma bloc de l’algorithme de commande . . . . . . . . . . . .
D.1 Résultats partiels d’une rotation CORDIC simulée sur MATLAB
D.2 Fonctions calculées par l’algorithme CORDIC généralisé . . . .
D.3 Simulation du CORDIC (trait plein) en mode rotation par rapport à une rotation réelle (trait hachuré) . . . . . . . . . . . . . .
D.4 Précision des rotations CORDIC . . . . . . . . . . . . . . . . . .
18
119
120
122
123
124
126
127
128
130
132
134
135
135
136
161
161
164
166
167
167
168
170
171
173
180
182
186
187
D.5 Pourcentage d’erreur commis par le CORDIC étendu sur la multiplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.6 Simulation de la division avec le CORDIC étendu . . . . . . . .
D.7 Erreur sur la division incluant l’erreur de quantification . . . . .
D.8 Erreur sur la division sans l’erreur de quantification . . . . . . .
192
193
193
193
E.1
E.2
E.3
E.4
E.5
E.6
196
196
197
197
198
198
Schéma bloc de l’asservissement du processus .
Schémas blocs sous Ptolemy du système asservi
Schémas blocs sous Ptolemy du système asservi
Schémas blocs sous Ptolemy du système asservi
Perturbation . . . . . . . . . . . . . . . . . . . .
Réponse temporelle du système asservi . . . . .
19
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
Introduction générale
Ce travail de thèse s’inscrit dans le cadre d’une collaboration entre le Département d’Informatique de l’Université Autonome de Barcelone (UAB) et le
Centre de Génie Électrique de Lyon sur le site de l’Institut National de Sciences
Appliquées (CEGELY - site INSA).
L’objectif de cette collaboration est de mettre en commun des compétences
complémentaires afin d’étudier l’implantation des algorithmes de commande
des machines électriques AC 1 .
Le projet de Recherche issu de cette collaboration a été cofinancé par le
ministère des Affaires Étrangères dans le cadre des projets Hispano-Français
«Picasso».
Avant de poursuivre, nous incitons le lecteur à se reporter aux définitions
que nous donnons de certains termes utilisés dans ce document (annexe A)
afin d’éviter toute confusion.
Introduction à la mise en oeuvre des algorithmes de
commande
Avant même de parler de la mise en oeuvre des algorithmes de commande,
introduisons d’abord le domaine de la variation de vitesse par chaîne d’entraînement électrique.
On estime dans nos pays industrialisés qu’environ 60 à 70% de l’énergie
électrique produite est consommée par les moteurs électriques et que de ceuxci, environ 20% fonctionnent en vitesse variable.
Pendant de nombreuses années, le moteur à courant continu a été privilégié pour les applications à vitesse variable en raison de la simplicité de sa commande et donc de sa mise en oeuvre. Mais ce moteur pose un certain nombre
de problèmes. En dehors d’un coût important dû à sa structure complexe, ce
moteur a des limitations technologiques (limitation en puissance et vitesse,
création d’étincelles, usure des balais ...etc.) qui le rendent inadapté à certaines
applications (train à grande vitesse, milieu avec risque d’explosion, ...etc.).
Les moteurs à courant alternatif (synchrones, asynchrones, à reluctance variable, ...etc.) ne présentent pas de telles limitations. D’un coût moindre, ils
1. Alternative Current
21
sont robustes et fiables et peuvent supporter de très fortes puissances et de très
hautes vitesses. Par contre, il faut les alimenter avec un convertisseur statique
à tension et fréquence variables pour pouvoir envisager leur emploi en vitesse
variable (cf. Fig. 1 ).
F IG . 1 – chaîne d’entraînement électrique à moteur AC
Ces vingt dernières années, les progrès simultanés dans le domaine des
semi-conducteurs de puissance, de la microélectronique et des outils de modélisation mathématique du comportement dynamique des machines alternatives, ont ouvert la voie à l’utilisation des machines AC.
Promus par l’enjeu économique que représente l’utilisation de telles machines ainsi que par les avantages techniques, des efforts de Recherche importants ont été consacrés à la chaîne d’entraînement électrique AC. Cependant, cet effort s’est porté essentiellement sur l’architecture des moteurs, l’algorithmie de commande, la physique du semi-conducteur et les architectures
de convertisseur. Quant à la mise en oeuvre de la commande, elle a surtout bénéficié des progrès de la microélectronique et de l’architecture des processeurs
avec l’apparition des microcontroleurs puis des DSP.
Toutefois, après des années de segmentation de la Recherche dans les trois
domaines qui constituent la variation de vitesse (motorisation, conversion statique et commande), deux nouvelles orientations semblent s’imposer aujourd’hui:
1. l’étude et la conception de la chaîne d’entraînement dans son ensemble
en prenant en compte les interactions des différentes parties constitutives,
22
2. l’attention accrue portée à la mise en oeuvre de la commande. Ce phénomène est dû en premier lieu au fait qu’on peut aujourd’hui estimer mathématiquement, avec une bonne précision, des paramètres qu’il fallait
autrefois mesurer (lorsque c’était possible). Ainsi, on peut remplacer du
matériel coûteux (capteurs) par de l’électronique bon marché ou même
améliorer la qualité de la commande par la modélisation mathématique.
Dans la suite de cette thèse, nous montrerons que notre travail s’inscrit dans
ces orientations.
Objectifs
L’objectif de cette thèse est double. Nous voulons d’une part, offrir au concepteur une méthodologie et des outils lui assurant une aide lors de l’intégration
de la commande, et d’autre part, appliquer cette méthodologie en intégrant un
algorithme de contrôle vectoriel pour un moteur asynchrone. Dans cette optique, il s’agit de:
– prendre en compte les contraintes de la mise en oeuvre dès la phase de
conception algorithmique.
– repousser les choix technologiques à un stade avancé de la conception
afin de rester relativement indépendant de la technologie et de gagner en
flexibilité au niveau du choix de la solution d’intégration.
– d’éliminer certaines erreurs et d’écourter le cycle de conception grâce à
une automatisation partielle des tâches.
Pour atteindre cet objectif, nous avons procédé de la manière suivante:
– Nous avons analysé les techniques employées pour la mise en oeuvre
d’algorithmes de commande afin d’en tirer les spécificités technologiques
et définir les aspects à améliorer.
– Nous avons étudié l’état des techniques et outils employés en microélectronique pour la conception des systèmes complexes.
– A partir des résultats précédents, nous avons proposé une méthode adaptée à la mise en oeuvre des algorithmes de commande .
– Finalement, nous avons adapté certains modèles et outils classiques de
l’automatisme (Grafcet, MATLAB / SIMULINK) aux contraintes spécifiques à la conception de systèmes intégrés pour permettre une implantation de la méthodologie ainsi obtenue.
Le présent document s’articule principalement autour de cinq chapitres.
Dans le premier, nous présentons l’application sur laquelle nous travaillons,
c’est à dire la commande des machines électriques AC. On y décrit la structure
d’une chaîne d’entraînement et on précise la nature de chaque élément, ses
23
caractéristiques physiques et les spécificités des modèles associés. Nous précisons également les limites de notre étude en définissant la fonctionnalité de la
«commande» et ce que nous intégrerons.
Dans le deuxième chapitre, nous exposons une analyse des méthodes actuelles pour l’intégration d’algorithmes. Y sont étudiées à la fois les méthodes
classiques dont on expose les problèmes vis à vis des besoins actuels, mais
aussi les méthodes plus avancées qui font l’objet de nombreux travaux et qui
visent à apporter des solutions aux insuffisances des approches classiques. Un
paragraphe à part est consacré aux travaux ayant étudié la mise en oeuvre des
algorithmes de contrôle. Ce paragraphe nous permet de préciser les spécificités
technologiques qu’il importait de garder à l’esprit pendant le développement
de ce travail.
Le troisième chapitre développe une méthodologie spécifique aux algorithmes de contrôle des machines électriques, basée sur les méthodologies dites
de conception mixte matériel/logiciel. Après avoir identifié les problèmes spécifiques à l’intégration de la commande, nous proposons des solutions théoriques originales. Puis, nous décrivons les solutions pratiques mises en oeuvre
et en particulier, les modèles et outils utilisés, leur emploi étant justifié par des
considérations techniques.
Le quatrième chapitre est consacré au Grafcet. Ce modèle classique de l’automatisme y est analysé pour servir de modèle de conception système. Nous y
exposons en particulier l’interprétation que nous utilisons pour permettre une
modélisation fonctionnelle des systèmes de commande. A partir de cette interprétation et de règles que nous exposons, le modèle est analysé systématiquement pour en déduire les implications sur l’intégration (analyse architecturale
pour l’intégration matériel et estimation de paramètres physiques). Ces analyses permettent ensuite au concepteur de baser ses décisions sur des données
tangibles.
Les modèles et méthodes ayant été analysés, nous abordons finalement
dans un cinquième chapitre la mise en oeuvre d’un algorithme de commande
particulier. Après avoir suivi la méthodologie proposée précédemment, nous
exposons les résultats des mesures effectuées sur le banc d’essai.
24
Chapitre 1
Chaîne d’entraînement et
fonctions génériques de la
commande
1.1 Introduction
Le thème de cette thèse est principalement l’intégration optimale de la commande des machines AC. Mais, sous le terme de «commande», il est possible de
regrouper bien des fonctionnalités. Aussi commençons-nous dans cette thèse
par circonscrire le champ des investigations et clarifier les fonctionnalités envisagées lors de l’intégration de la «commande».
Pour ce faire, nous allons décrire la chaîne d’entraînement et la commande
du point de vue du concepteur de systèmes intégrés, c’est à dire que nous
extrairons les propriétés physiques importantes pour l’intégration de la commande.
Nous aborderons les modèles des dispositifs de la chaîne d’entraînement,
utilisés par les concepteurs de la commande, en indiquant notamment les limites de ces modèles du point de vue physique.
Nous décrirons également les fonctions génériques que nous considérons
faire partie de la «commande» et parlerons de quelques algorithmes particulièrement répandus. Ceci nous permettra de présenter quelques éléments de la
théorie du contrôle afin de mieux comprendre les blocs à intégrer. Toutefois,
cette thèse n’ayant pas pour but de développer une commande particulière,
nous n’entrerons pas dans les détails.
Le chapitre s’articule autour de deux parties. La première décrit la chaîne
de traction et les modèles associés, et la deuxième présente les fonctions génériques de la commande.
25
1.2 La chaîne d’entraînement
1.2.1 Les dispositifs
Dans cette thèse, nous nous sommes limités à la commande des moteurs
AC qui, comme nous l’indiquons dans l’introduction générale, nécessitent des
convertisseurs statiques (onduleur et éventuellement redresseur) pour leur alimentation (cf. Fig. 1, p. 22).
L’ensemble convertisseur(s)/moteur/capteurs, auquel on peut ou non ajouter l’électronique de commande, forme la chaîne d’entraînement.
Le redresseur, lorsqu’il est présent, n’est pas significatif pour la commande,
son rôle étant limité à transformer en permanence une tension AC monophasée
de fréquence et d’amplitude constantes (ou du moins avec des fluctuations très
faibles), en une tension DC constante.
Les autres éléments de la chaîne d’entraînement sont indispensables à la
commande, nous allons donc les présenter en détail.
1.2.1.1 L’onduleur
F IG . 1.1 – onduleur à trois bras
Largement décrit dans la litérature [35][40], l’onduleur a pour tâche de
transformer une tension DC constante en une tension AC polyphasée de fréquence et d’amplitude variables.
L’architecture de ce convertisseur se compose de plusieurs bras, connectés
chacun à une phase du moteur et comportant deux interrupteurs de puissance.
Ces interrupteurs découpent la tension DC d’entrée en impulsions de largeur
variable; le fondamental de la décomposition en série de Fourier de ce train
d’impulsions est la tension d’alimentation sur une phase du moteur (cf. Fig.
1.2). En faisant varier la largeur des impulsions (leur amplitude étant fixée par
la tension d’alimentation DC), on peut modifier l’amplitude et la fréquence
26
du fondamental, donc de la tension d’alimentation du moteur. Le cas le plus
fréquent est l’onduleur triphasé à trois ou quatre bras (cf. Fig. 1.1).
F IG . 1.2 – tension MLI entre deux phases du moteur avec fondamental de tension
Éléments de base de l’onduleur, les interrupteurs de puissance se composent, selon la puissance commutée, de GTO (Gate Turn Off), de MOS de
puissance ou d’IGBT (Insulated Gate Bipolar Transistor), en parallèle avec une
diode (cf. Fig. 1.3). La diode permet d’assurer la continuité du courant lors du
changement de sens de celui-ci.
F IG . 1.3 – interrupteur de puissance avec IGBT et diode
Les caractéristiques de l’onduleur sont principalement définies par ces composants de puissance. Ceux-ci déterminent la puissance, la tension et le courant maximum commutés, la fréquence maximale de commutation et le temps
mort. Ces deux dernières caractéristiques sont particulièrement importantes
pour nous car elles vont beaucoup influencer la conception.
La fréquence maximale de commutation est déterminée par les temps de
commutation (ouverture et fermeture du composant) des interrupteurs et par
le temps mort. Sur une période de commutation, un interrupteur commute au
maximum deux fois: à l’ouverture et à la fermeture (cf. Fig. 1.4). Ces commutations provoquent un bruit acoustique désagréable d’où la tendance actuelle
de travailler à des fréquences de commutation dans la gamme de l’inaudible
(16 KHz), et donc d’utiliser des composants rapides.
Le temps mort sert à prévenir les risques de court-circuit sur un bras (cf.
Fig. 1.4). Ce temps, introduit entre l’ouverture d’un interrupteur et la fermeture
de son complémentaire, dépend des temps de commutation. Plus ceux-ci sont
27
F IG . 1.4 – exemple de période de commutation avec temps mort
faibles, et plus le temps mort pourra être réduit. Le temps mort a une influence
importante sur l’entraînement car il provoque des non-linéarités de l’onduleur
et donc des imprécisions sur la tension AC générée.
D’autres non-linéarités de l’onduleur génèrent également des imprécisions
sur la tension de sortie comme la variation des paramètres des interrupteurs
avec la température de fonctionnement (temps de commutation, caractéristiques électriques), phénomène difficilement modélisable et pas du tout contrôlable.
De cet onduleur, on retiendra donc deux paramètres essentiels pour la conception: la période de commutation et le temps mort.
1.2.1.2 Le moteur
Le moteur AC est l’actionneur par excellence. Il sert à la régulation de
couple, de vitesse ou de position selon l’emploi qu’on en fait.
D’une façon générale, le moteur AC est constitué d’un rotor et d’un stator,
le rotor étant la partie rotative qui entraîne l’axe et le stator la partie fixe qui
supporte les bobines d’induction.
Il existe une multitude d’architectures de moteurs AC selon le principe de
fonctionnement retenu. On citera pour mémoire les moteurs synchrones et
asynchrones, les moteurs à aimants permanents et les moteurs à reluctance,
la liste n’étant pas exhaustive. Les moteurs synchrones et asynchrones restent
toutefois les plus répandus.
Le moteur synchrone possède un rotor alimenté par une tension continue
ce qui lui permet de tourner exactement à la fréquence de synchronisme (fréquence des courants d’alimentation fois le nombre de paires de pôles) et de ne
rejeter aucune puissance réactive sur le réseau. Par contre, en cas de variation
brusque du couple résistant sur l’axe du moteur, comme ce moteur ne supporte
que de faibles variations de sa fréquence de rotation autour de la fréquence de
synchronisme, il existe un risque de «décrochage», c’est à dire que la fréquence
de rotation diminue et le moteur finit par s’arrêter.
Contrairement au moteur synchrone, le moteur asynchrone dispose d’un
rotor en court-circuit, non alimenté. Dans les spires des induits du rotor circulent des courants induits par le champ magnétique tournant du moteur.
28
Grâce à ces courants induits, un couple s’établit sur l’axe du moteur. La vitesse de rotation est déterminée par le couple résistant et le couple moteur. En
régime permanent sinusoïdal, la vitesse de synchronisme n’est jamais atteinte
(d’où le terme d’asynchrone) et le moteur rejette de la puissance réactive sur le
réseau. Parmi les moteurs asynchrones, le moteur à cage d’écureuil est particulièrement répandu en raison de sa structure très simple, donc robuste et facile
d’entretien (cf. Fig. 1.5).
F IG . 1.5 – moteur AC asynchrone à cage d’écureuil
Les moteurs présentent eux aussi de nombreuses non-linéarités dues au variations paramétriques avec la température de fonctionnement et la saturation
magnétique, et ce notamment en régime dynamique. Comme pour l’onduleur,
ces non-linéarité entraînent des erreurs sur les grandeurs commandées (couple,
vitesse ou position). Ces erreurs de commande proviennent du fait que les algorithmes de contrôle utilisent les paramètres de la machine.
1.2.1.3 Les capteurs
Les capteurs font partie intégrante de la chaîne d’entraînement car sans eux,
le contrôle serait impossible. Depuis les capteurs de courant jusqu’aux capteurs
de vitesse ou de flux, ils permettent de mesurer les variables physiques que
nécessite la commande.
Comme les autres dispositifs, les capteurs présentent des limites de fonctionnement et des non-linéarités dont les concepteurs de la commande et du
système intégré devront tenir compte.
En particulier, il est un phénomène qui n’a rien de physique mais qu’il
est tout aussi important de signaler: la quantification binaire. Par ce terme,
on désigne le fait qu’une grandeur physique par essence continue et qui peut
prendre un nombre infini de valeurs, doit être représentée par une variable
binaire qui ne peut prendre qu’un nombre fini de valeurs. A chaque bit, on associera donc un quanta qui dépend de la dynamique de la grandeur physique
et du nombre de bits de la variable binaire.
Prenons un exemple:
29
Supposons qu’on veuille mesurer un courant variant entre
et
, soit une dynamique de . La mesure est effectuée sur 8 bits,
soit valeurs possibles. Dans cette conversion, le vecteur binaire
et “11111111” à . La quantifica“00000000” sera affecté à
tion binaire sera donc de
1.2.2 Les modèles pour la commande
Pour contrôler un dispositif, il est nécessaire d’en comprendre le fonctionnement et savoir le modéliser.
Il existe deux types de modèles. D’une part les modèles de connaissance,
appelés aussi intrinsèques, propres au physicien. Ce sont souvent des modèles complexes et pas du tout appropriés pour l’établissement de lois de commande. D’autre part, il existe les modèles dits extrinsèques qui reproduisent
le comportement du système modélisé à partir de ses entrées/sorties. Ces modèles beaucoup plus simples permettent d’établir des lois de commande. Toutefois, le contrôle étant réalisé sur un modèle idéal des dispositifs, il faudra
qu’il soit capable de corriger les erreurs par rapport au comportement réel.
1.2.2.1 Le modèle du moteur
Dans le cas des machines synchrones et asynchrones qui nous sont les plus
familières, le modèle le plus communément employé est le modèle dit «vectoriel»
ou «de Park» [4]. Ce modèle est constitué de quatre équations différentielles
électriques du premier ordre, non linéaires avec la vitesse, d’une équation différentielle mécanique de rotation et de l’équation du couple électromagnétique
(cf. Annexe B).
Ce modèle implique un certain nombre de simplifications (entrefer constant,
saturation, hystérésis et courants de Foucault négligeables, ...etc.) qui en font
un modèle de la machine idéale.
1.2.2.2 Le modèle de l’onduleur
La plupart des algorithmes de contrôle reposent sur le modèle de l’onduleur idéal de tension, c’est à dire sans pertes, avec des temps de commutation
nuls et sans temps mort. En fait, l’onduleur est modélisé la plupart du temps
par un simple gain.
Toutefois, certains algorithmes permettent de compenser l’effet des temps
morts sur la tension de sortie de l’onduleur [34].
1.2.2.3 Le modèle des capteurs
A notre connaissance, les capteurs ne sont que rarement pris en compte lors
de l’établissement de l’algorithme de contrôle. L’erreur qu’ils introduisent dans
30
la boucle de contrôle est compensée par les stratégies globales de correction
d’erreur.
1.3 La commande
Dans son acceptation électrotechnique, la commande se réduit souvent à
l’algorithmie de contrôle de la chaîne d’entraînement avec éventuellement l’acquisition des mesures et des consignes.
Or cette acceptation restreinte du concept de commande ne nous paraît pas
adaptée à la réalité. Il est très rare de trouver une application se restreignant à
une chaîne d’entraînement et l’électronique de commande intégrant seulement
l’algorithme de contrôle. Dans la plupart des cas, l’entraînement n’est qu’un
élément d’une application bien plus complexe. Dans ce cas, la commande doit
intégrer également des blocs d’interfaçage, de mesure, de surveillance ...etc.
Définir la fonctionnalité de la commande comme le seul algorithme de contrôle
et se limiter à l’étude de l’intégration de ce bloc est inadapté par rapport à la
réalité.
Nous préférons donc définir la fonctionnalité de la commande de la chaîne d’entraînement comme l’ensemble des fonctions génériques indispensables au contrôle de
l’entraînement et à son intégration dans un système plus complexe.
La figure 1.6 représente notre vision de la répartition hiérarchique des tâches
de commande dans une application complexe et de la place de la commande de
la chaîne d’entraînement. Ceci dit, nous posons cette limitation dans le cadre de
cette thèse afin de montrer que la méthodologie d’intégration que nous proposons permet de traiter des cas réels. Nous ne prétendons pas que la commande
se réduit nécessairement aux seules fonctions génériques que nous décrivons
maintenant.
Dans la suite de ce document, lorsque nous utiliserons le terme de «commande»,
nous nous référerons toujours à la définition que nous en avons donné ici.
1.3.1 Les fonctions génériques de commande
1.3.1.1 Les fonctions logiques de génération des impulsions de commande
de l’onduleur
A partir de la valeur des instants de commutation de l’onduleur, du temps
mort et de la période de commutation, ces fonctions génèrent les impulsions
binaires qui commandent les interrupteurs de puissance de l’onduleur. Les
fonctions sont purement logiques et n’intègrent à priori aucune fonction algorithmique.
31
F IG . 1.6 – exemple de hiérarchie de commande
32
1.3.1.2 Les fonctions algorithmiques pour le calcul des instants de commutation
A ce niveau, il nous faut faire la différence entre deux blocs algorithmiques
(cf. Fig. 1.7):
1. le bloc MLI 1 . Ce bloc est chargé de calculer les instants de commutation
des composants de puissance de l’onduleur à partir d’une consigne de
tension
2. le bloc de contrôle proprement dit qui assure les fonctions de régulation
et asservissement des grandeurs physiques contrôlées. Toutefois, si nous
nous trouvons dans un schéma de contrôle en boucle ouverte, aucune
régulation ou asservissement n’ayant lieu, ce bloc se contente de calculer
les consignes de tension pour la MLI à partir des consignes externes.
1.3.1.3 Les fonctions d’acquisition des mesures
Ce bloc se charge de la communication avec les dispositifs de mesure (CAN 2 ,
capteur de vitesse, ...etc.) ainsi que du traitement des données binaires reçues
pour les mettre au format binaire du système.
Par exemple, si des mots de 8 bits sont reçus d’un CAN, il faudra ajuster
)
la quantification (un bit vaut 1 en codage binaire normal et non puis passer les mots au format interne des données (p.e. 12 bits entiers sur
une longueur de 16 bits).
1.3.1.4 Les fonctions logiques de surveillance
En général, sur tout dispositif physique il est nécessaire d’assurer la surveillance de conditions de fonctionnement, surveillance qui n’a rien à voir
avec le contrôle du dispositif. Par exemple, sur une chaîne d’entraînement, on
peut vouloir surveiller que la tension d’alimentation DC de l’onduleur ne dépasse pas certains seuils ou qu’aucun court-circuit ou sur-intensité se produit
dans les bras de l’onduleur. Cette surveillance relève de fonctions logiques qui
doivent réagir instantanément aux signaux extérieurs et avoir une priorité absolue sur tous les autres blocs.
1.3.1.5 Le bloc logique d’interfaçage
L’objet de ce bloc est généralement de recevoir des consignes externes qui
commanderont l’entraînement, et de renvoyer des mesures ou des conditions
logiques de fonctionnement.
Dans les cas les plus simples, l’interfaçage est inexistant ou se réduit à
quelques signaux pour communiquer directement avec un autre dispositif électronique. Mais l’interfaçage peut être beaucoup plus complexe et revêtir la
1. Modulation de Largeur d’Impulsions
2. Convertisseur Analogique Numérique
33
forme d’un protocole complet de communication à travers un bus partagé par
une multitude de dispositifs électroniques.
F IG . 1.7 – structure de la commande
1.3.1.6 Récapitulatif
En résumé, la «commande» se compose de sa fonctionnalité principale (le
contrôle de la chaîne d’entraînement), et de fonctions annexes. Pour les besoins
de l’intégration, nous regroupons dans la suite de ce document les fonctions de
34
commande en trois groupes:
1. les fonctions algorithmiques
2. les fonctions logiques
3. les protocoles de communication
Cette classification des fonctions nous sera utile lors de la spécification du système.
1.3.2 Considérations théoriques
La commande des machines AC est complexe car contrairement à la machine DC, les variables d’état du système ne sont pas découplées. Autrement
dit, il n’est pas possible de contrôler une grandeur de sortie de la machine
(couple, vitesse ou position) en faisant varier une seule grandeur d’entrée (intensité ou tension donnée).
Pour résoudre ce problème, on applique une transformation mathématique
aux variables d’état de la machine AC de manière à rendre celle-ci équivalente
à une machine DC, facile à contrôler. La transformation en question est la transformation dite de «Concordia» [4]:
Cette transformation permet de calculer les variables d’état dans un repère
dans lequel il sera facile de les découpler. Une fois découplées, on appliquera
à ces variables les techniques traditionnelles de la théorie des systèmes échantillonnés afin de les réguler et de les asservir aux consignes d’entrée.
Ainsi que nous l’avons déjà fait remarquer en 1.3.1.2, page 33, la commande
algorithmique se compose en fait de deux blocs bien distincts: le bloc de contrôle
proprement dit et le bloc MLI. Pour chacun de ces blocs, il existe plusieurs stratégies possibles, c’est à dire en fait plusieurs algorithmes, la stratégie de chacun
des blocs étant choisie indépendamment.
En ce qui concerne le bloc MLI, nous citerons pour référence la MLI intersective, la précalculée et la MLI vectorielle, stratégies les plus communément
employées [23]. Chacun de ces algorithmes permet d’obtenir des caractéristiques différentes des tensions de sortie de l’onduleur (spectre et amplitude
maximale de la tension).
En ce qui concerne le bloc de contrôle, on peut distinguer deux familles d’algorithmes: les méthodes scalaires et les méthodes vectorielles [35]. Dans les
paragraphes suivants, nous présentons succinctement deux algorithmes très
répandus: l’algorithme scalaire en boucle ouverte dit constant et un algorithme vectoriel en boucle fermée, le FOC 3 .
3. Field Oriented Control
35
F IG . 1.8 – exemple de contrôle constant
L’algorithme constant Cet algorithme fait partie de la famille des méthodes
de contrôle scalaire. Le principe de ces méthodes est d’agir sur la fréquence et
l’amplitude des courants ou tensions d’entrée afin de faire varier l’amplitude
et la vitesse de rotation des vecteurs spaciaux (flux, tension ...etc.), et donc faire
varier le couple et la vitesse de rotation du moteur.
Avec l’algorithme , on s’arrange pour faire évoluer l’amplitude et la fréquence de la tension d’alimentation du moteur tel que leur rapport reste constant,
ce qui permet de faire varier le couple du moteur et donc sa vitesse pour un
couple résistant constant.
Pour mettre en oeuvre un tel contrôle, le plus simple est de fournir la fréquence comme consigne du bloc de contrôle. Celui-ci calcule alors la tension
qui sert de consigne à son tour au bloc MLI (cf. Fig. 1.8).
Ce contrôle en boucle ouverte a le mérite d’être très simple à mettre en
oeuvre et ne nécessite que très peu de moyens de calcul. Pour cette raison il est
encore aujourd’hui très répandu. Mais la dynamique obtenue est très faible et
il n’y a pas de régulation de la grandeur de sortie (couple, vitesse ou position)
si bien que cet algorithme est inadapté pour beaucoup d’applications.
L’algorithme vectoriel FOC Contrairement aux méthodes scalaires, les algorithmes de contrôle vectoriel permettent de faire varier non seulement l’amplitude et la vitesse de rotation des vecteurs spaciaux, mais aussi leur phase.
Grâce à cela, il est possible dans certaines conditions d’agir séparément sur le
flux de la machine et sur le courant responsable du couple de la même façon
que pour une machine à excitation séparée.
Sur la figure 1.9 nous montrons le schéma bloc d’un algorithme vectoriel
FOC. Ces algorithmes permettent, pour une meilleur robustesse, de tenir compte
des variations paramétriques de la commande en estimant en temps réel ces
36
F IG . 1.9 – schéma de principe d’un contrôle vectoriel
37
paramètres.
Les performances atteintes par ce type de commande sont bien meilleures
que pour un contrôle en boucle ouverte. Par contre, la complexité mathématique des calculs à effectuer a longtemps été un frein à leur mise en oeuvre.
En Annexe B, nous présentons en détail l’algorithme de contrôle vectoriel
qui nous a servi d’exemple pour cette thèse. Nous y expliquons également le
principe mathématique des commandes vectorielles.
1.4 Conclusion
Dans ce chapitre, nous avons décrit la chaîne d’entraînement et les caractéristiques physiques importantes pour le concepteur de l’intégration de la commande. Nous avons notamment insisté sur les non-linéarités des dispositifs en
vue d’établir plus tard le degré de précision des calculs qu’il faudra atteindre.
Nous avons également clairement établi les limites de notre étude en précisant ce que nous comprenions par le concept de «commande» des machines
AC. En particulier, nous avons extrait différents blocs fonctionnels en précisant
la tâche de chacun d’eux.
Ayant donné une vision globale de l’application, nous allons pouvoir maintenant nous intéresser de plus près à l’intégration système de la commande.
38
Chapitre 2
Méthodologies
d’implantation d’une
fonctionnalité: état de l’art
2.1 Introduction
Selon son contenu sémantique, «l’implantation de fonctionnalité» signifie
fixer ou introduire une fonctionnalité dans un support physique. Par fonctionnalité, nous désignons un fonctionnement défini par un ensemble de fonctions
logiques et algorithmiques (algorithme, automate, protocole de communication, ...etc.).
Comme l’indique son contenu sémantique, implanter une fonctionnalité
consiste bien à faire calculer les opérations et réaliser les fonctions logiques
par un système physique qui se limitera ici à un système microélectronique.
Depuis quelques années, la complexité croissante des fonctions à intégrer
alliée à des contraintes techniques, budgétaires et temporelles toujours plus
fortes (densité d’intégration, fréquence de fonctionnement, CEM 1 , consommation, coût de production, temps de conception, ...etc.), ont confronté le concepteur à des problèmes qu’il n’est plus en mesure de résoudre avec les outils
classiques.
Face à cette réalité, particulièrement prononcée dans le domaine des applications télécom et audio/vidéo, des projets de recherche ont été amorcés dans
le but de rationaliser, systématiser et automatiser l’implantation de fonctionnalités.
Dans ce chapitre, nous nous proposons de faire le tour des techniques employées pour la conception des systèmes intégrés et de présenter les nouveaux
enjeux de ce domaine.
Dans un premier temps, nous verrons les problèmes posés par les méthodes
1. Compatibilité Electro-Magnétique
39
classiques de la conception vis à vis de l’intégration de fonctions complexes et
les enjeux des nouvelles méthodes.
Puis nous analyserons les travaux effectués sur la mise en oeuvre de commandes de machines électriques et les spécificités que nous avons décelées
dans ces approches.
Finalement, nous présenterons une méthodologie de conception mixte logiciel/matériel générique ainsi que les travaux qui s’y rapportent. Nous montrerons comment une telle approche permet d’apporter des réponses aux besoins
actuels.
2.2 Méthode courante pour la conception système
Une grande quantité d’ouvrages traitent de la conception des circuits intégrés VLSI 2 [19][45][54][41]. La plupart du temps, la méthodologie en ellemême n’est guère abordée, le sujet le plus communément traité étant la conception à un niveau très bas (architecture des circuits, schémas logiques, modèles
HDL 3 et synthèse logique, technologie ...etc.).
Bien qu’il soit présomptueux de parler de la méthode de conception actuelle
des systèmes intégrés, il est toutefois possible de trouver des points communs
dans les approches de conception. Ce sont ces points que nous allons aborder
dans cette section en détaillant un peu leur contenu. Nous parlerons aussi des
difficultés qu’entrainent les nouvelles contraintes de conception ce qui nous
permettra d’introduire des notions propres aux méthodes avancées de conception que nous expliquons plus loin dans ce chapitre.
Développement algorithmique: il est d’abord intéressant de noter que le processus de développement algorithmique, c’est à dire dans le cas qui nous
intéresse, de l’algorithme de commande, est dissocié de l’implantation de
celui-ci sur silicium. De ce fait, la conception de l’algorithme ne tient pas
compte des problèmes que pose son intégration. Une fois l’algorithme
conçu, il est figé. Il n’y a pas lieu de le modifier en fonction de l’implantation.
Spécification du système: avant de débuter la conception du système, un cahier des charges est établi qui fixe les caractéristiques du circuit à réaliser. En dehors des performances physiques (vitesse de calcul, surface,
consommation ...etc.), on définit également les caractéristiques architecturales (nombre d’entrées/sorties, communication avec l’environnement
...etc.) et des caractéristiques d’ordre commercial (production minimale,
prix unitaire, délai de conception, éventuellement fondeurs ...etc.). Cette
spécification du système intervient sans savoir s’il sera réellement possible de remplir les conditions fixées ni si les conditions de l’étude de
marché se maintiendront, si bien qu’il n’est pas rare que ces spécifications
soient modifiées au cours du développement du fait des concepteurs qui
2. Very Large Scale Integration
3. Hardware Description Language
40
ne peuvent atteindre les objectifs fixés ou du fait du donneur d’ordre qui
voit se modifier les conditions de son marché lors de la phase de développement du système.
Technologie: aux concepteurs du système intégré, il revient la tâche de choisir une cible technologique. Ce choix se fait en général à priori sur des
critères plus ou moins intuitifs: intégration logiciel (processeur) pour les
systèmes lents, matériel (ASIC) pour les systèmes rapides. Parfois, des
cibles mixtes matériel/logiciel sont prévues dès le début, en particulier si
le système est complexe.
Partitionnement: dès lors que le système s’avère trop complexe pour une intégration sur une cible unique, le concepteur doit faire face à toute une série
de problèmes liés au partitionnement du système: définition de l’architecture (nombre de processeurs, nombre d’ASIC, capacité mémoire, nombre
d’E/S,...etc.), d’un protocole de communication, du contrôle d’accès aux
ressources partagées, ...etc. Afin d’éviter la complexité de ces problèmes,
une stratégie communément employée est la migration d’une cible vers
l’autre: soit la migration vers le matériel de tout ce qui n’a pas pu être
réalisé avec le logiciel (comme par exemple la logique d’interfaçage), soit
la migration vers le logiciel des tâches de surveillance (fortement séquentielles et lentes) pour dédier le matériel au calcul parallèle à haute ou
très haute fréquence. Le premier cas correspondrait typiquement aux algorithmes de contrôle (électrotechnique et automatique) et le second au
traitement du signal.
Vérification fonctionnelle: l’intégration système pose à tout moment le problème de la vérification fonctionnelle. Il faut d’abord vérifier que ce qu’on
développe correspond bien aux besoins (étape de conception algorithmique), puis que ce qu’on a intégré correspond bien à ce qu’on voulait intégrer. La solution communément employée aujourd’hui est la simulation. Toutefois, plus le système devient complexe, et plus cette approche montre ses limites avec une explosion des temps de simulation.
Un exemple simple nous permet d’en mesurer l’ampleur:
Supposons qu’on veuille tester une ALU commerciale de 32 bits
(cf. Fig. 2.1). Avec 77 bits d’entrée, on aurait environ vecteurs d’entrée possibles. A raison de par vecteur, il
faudrait simuler durant soit années!!
Outils et modèles: en matière d’outils, les langages HDL avec leurs simulateurs/synthétiseurs associés et le langage C avec ses compilateurs, sont
aujourd’hui largement répandus, offrant une certaine «indépendance technologique» au concepteur, c’est à dire la possibilité de synthétiser le même
modèle pour différentes technologies (fondeurs et processeurs). Ces outils, associés aux outils de placement/routage, permettent aussi une automatisation des tâches qui supprime une partie des erreurs pouvant survenir à ces bas niveaux de conception et autorise le développement de
systèmes dont la complexité serait impossible à traiter à la main.
41
F IG . 2.1 – ALU de 32 bits
Si les points évoqués permettent de mettre en oeuvre des systèmes de complexité moyenne avec des performances et des coûts satisfaisants, il n’en est
plus de même pour des fonctionnalités très complexes. Face à la complexité
croissante des systèmes et aux exigences techniques, budgétaires et temporelles
toujours plus contraignantes, de nouveaux enjeux apparaissent:
Traiter les spécifications floues: un des nouveaux enjeux qui ne peut pas être
traité par une approche classique est l’utilisation de ce que nous appellerons les «spécifications floues 4 ». Par ce terme, nous désignons toutes les
spécifications qui ne sont pas parfaitement définies au début du cycle de
conception et dont la définition va dépendre des résultats intermédiaires
de l’intégration. Ce cas se présente souvent, et en particulier pour les spécifications non techniques: coût global du système, disponibilité des composants, dépendance vis à vis d’un fondeur ou d’un fabricant, durée de
vie et évolution du produit, délai de conception, ...etc. Aussi, ayant à traiter à la fois des contraintes mal définies ou ayant changé (spécifications
floues) et un éventail de solutions techniques très vaste en constante évolution, le concepteur peut être amené à vouloir tester plusieurs stratégies
d’intégration après avoir défini un modèle fonctionnel unique du système. Sans outils appropriés, une telle technique n’est pas envisageable.
4. Le lecteur notera que nous employons ce terme au sens propre et non par référence à la
logique du même nom
42
Automatiser le cycle de conception: l’automatisation de la conception permettrait d’une part de réduire les délais de conception, mais aussi de traiter
des complexités que l’approche manuelle interdit et de diminuer un taux
d’erreur dû au facteur humain.
Validation des systèmes: valider le bon fonctionnement d’un circuit est impératif durant tout le processus de conception, surtout avant l’envoie
en production. Pour s’en convaincre, il suffit de se rappeler le disfonctionnement du «pentium». Mais, la simulation n’étant pas en mesure de
traiter les fortes complexités, il faut trouver des techniques permettant
soit d’apporter la preuve mathématique du bon fonctionnement du circuit, soit d’en émuler le fonctionnement.
Comme on peut le constater, la complexité des enjeux est à la mesure des fonctionnalités à intégrer.
2.3 Implantation de la commande de machines électriques AC
Avec les progrès rapides de la microélectronique et de la technologie des
semi-conducteurs de puissance, de nouveaux résultats ont pu être obtenus en
matière de mise en oeuvre de la commande de machines électriques.
Mais, toujours aussi peu de travaux s’intéressent au problème de l’intégration de la commande. Nous avons classé ces travaux en deux catégories distinctes que nous étudions dans les paragraphes suivants.
Nous ne nous intéresserons toutefois qu’aux travaux ayant trait à la mise
en oeuvre de commandes de machines électriques AC. Nous ne nous préoccuperons pas des machines DC pour les raisons que nous avons évoquées dans
l’introduction générale.
2.3.1 l’intégration applicative
Nous regroupons sous cette catégorie les travaux ayant intégrés une commande dans le but de la tester.
L’objectif affiché ici n’est pas d’intégrer la commande, mais de vérifier des
propriétés particulières, étudiées avant par simulation. Ces travaux ne s’intéressent pas à l’influence de l’intégration sur l’application. Généralement d’ailleurs,
la commande est implantée sur un DSP à arithmétique binaire virgule flottante
[21][26]. Ces travaux sont typiquement ceux ayant profité des énormes progrès
techniques de la microélectronique.
Dans cette catégorie, nous plaçons également les travaux ayant intégré un
sous-ensemble de la commande (MLI généralement) sous forme de circuit intégré spécifique (ASIC) [29][57]. Dans ces travaux, les auteurs traitent l’architecture du circuit et justifient l’emploi des ASIC par des considérations sur les
temps de calcul et sur la flexibilité de conception. En général, la position adoptée est de considérer que l’intégration de la commande nécessitera à l’avenir de
43
partitionner le système entre une partie logiciel (DSP, microcontroleur) qui calculera les fonctions lentes (surveillance, régulation ...etc.), et une partie matériel
intégrant les fonctions rapides (calcul des impulsions MLI, fonctions logiques
d’interfaçage ...etc.).
Pour l’ensemble des travaux cités ici, aucun ne présente de justification basée sur des données tangibles et chiffrées pour la méthode d’intégration choisie. Les justifications sont d’ordre intuitif. Par ailleurs, aucune étude n’est effectuée sur la possible dégradation des performances de l’application due à la
mise en oeuvre de la commande, notamment dans le cas d’une intégration en
arithmétique binaire virgule fixe. Les avantages apportés par une diminution
du temps de calcul ne sont pas étudiés non plus. Dans les justifications d’emploi des ASIC, l’avantage apporté semble être une donnée implicite et évidente
alors que nous verrons qu’il n’en est rien.
Tous ces travaux souffrent du manque de méthode systématique pour l’intégration de la commande.
2.3.2 L’étude de l’intégration système
Les premiers travaux en la matière étudiaient d’abord l’architecture système à utiliser. Si l’intégration des algorithmes vers une cible logiciel et plus
particulièrement vers les processeurs spécialisés DSP ou microcontroleurs [36]
a eu la faveur de la plupart des concepteurs de systèmes de commande, l’implantation mixte a été envisagée assez rapidement [2]. Dans ce travail, la partie
matériel intégrait les fonctions logiques d’interfaçage entre l’algorithme et le
convertisseur de puissance (génération des signaux de commande des composants de puissance).
Dans la plupart des travaux plus récents [10][30], un réel partitionnement
du système est désormais proposé. La cible matériel (FPGA ou ASIC précaractérisé) intègre alors toute une partie de l’algorithmie de commande en sus des
fonctions d’interfaçage, c’est à dire de la génération des signaux de commande
de l’onduleur. Mais, dans l’ensemble, tout ces travaux envisagent un seul partitionnement: les fonctions de surveillance et de contrôle de position, vitesse et
accélération vers la cible logiciel, le calcul de la MLI vers le matériel.
Dans [37], Monmasson propose un travail très complet d’étude de l’intégration d’une commande de machine synchrone. Il étudie d’une part l’architecture
du système mais également l’influence de l’intégration sur la chaîne d’entraînement.
Un point intéressant est la justification du partitionnement adopté. L’approche se base sur deux analyses:
– une analyse fonctionnelle du système dans laquelle il différencie la «commande rapprochée», c’est à dire les fonctions logiques comme la génération des impulsions de commande des interrupteurs de puissance, de la
«commande algorithmique», c’est à dire les fonctions de régulation.
– une analyse temporelle lui faisant distinguer différentes constantes de
temps mises en jeu dans la commande des machines électriques.
44
A partir de ces analyses, Monmasson explique que «commande rapprochée»
et «commande algorithmique» étant de natures différentes, elles doivent être
implantées différemment. Contrairement au études précédentes, il étend le
concept de «commande rapprochée» aux fonctions de régulation des grandeurs électriques rapides, définissant ainsi un bloc rapide, intégré sur une cible
matériel, la «commande rapprochée», contrôlé par un bloc lent, intégré sur une
cible logiciel, «la commande algorithmique».
Si l’étude fonctionnelle et physique du système est intéressante en vue de
l’intégration, le raisonnement menant au partitionnement nous semble erroné.
La distinction entre les différents paramètres (vitesse, technologie, nature des
fonctions) n’est pas claire et leur influence sur le choix de l’architecture du
système non plus. La solution proposée en est une parmis d’autres, mais rien
ne prouve qu’elle soit optimale.
Un autre point intéressant du travail précédent est l’étude des avantages
et inconvénients de la réduction du temps de calcul et de la période d’échantillonage. Nous résumons ici les conclusions car il en sera tenu compte dans la
suite de ce document:
1. la diminution du temps de calcul (ici implicitement égal à la fréquence de
commutation) améliore la régulation des courants (grandeurs rapides).
La régulation est plus rapide et le découplage des axes et meilleur
(voir annexe B).
2. diminuer le temps de calcul permet aussi de diminuer la période d’échantillonage . Cette baisse de autorise une augmentation de la vitesse
maximale de fonctionnement des machines tout en améliorant la qualité
du contrôle par une plus faible distortion harmonique des tensions notamment.
3. la diminution du temps de calcul (et de ) est limitée par deux inconvénients. D’une part, par l’augmentation des grandeurs de commande de
la régulation lors des transitoires (augmentation qui peut amener à un
débordement des variables binaires entre autre), et d’autre part, par les
temps morts qui réduisent la plage de linéarité de l’onduleur. Il conseille
dans la pratique de limiter la fréquence d’échantillonage par un temps
mort égal à 5% de .
Cette étude est particulièrement intéressante puisqu’elle montre que diminuer
le plus possible la fréquence de calcul (et d’échantillonage) n’est pas nécessairement souhaitable et que de toute façon, il est indispensable de définir ces
constantes en fonction de l’application.
Un autre point intéressant abordé par certains travaux est l’étude de l’influence de l’arithmétique binaire sur les performances de la chaîne d’entraînement. Montmasson signale qu’une telle étude a été effectuée mais n’en précise
pas la technique exacte. Dans [14], Aubépart étudie ce problème par une simulation mixte analogique/numérique de la chaîne d’entraînement avec sa
commande numérique. Cette simulation est effectuée sur des modèles VHDL 5
5. Very high speed integrated circuit Hardware Description Language
45
fonctionnel de l’ASIC et VHDL-A 6 du moteur. S’il est intéressant de constater
l’influence de la précision et de la quantification binaire, notons que les travaux cités ne débattent pas de l’influence du séquencement et de la réalisation
binaire des opérations. N’est pas abordé non plus le problème de la vérification
fonctionnelle de l’implantation.
Pour finir, nous avons relevé dans certaines études, des propositions pour
modifier l’algorithme afin de tenir compte de l’influence de l’intégration sur
l’application. Ainsi dans [36], Leonhard propose de calculer le PID 7 sous forme
continue et non plus discrète pour les fréquences de calcul élevées. Une proposition similaire à celle qu’on trouve dans [38] où Montmasson propose des algorithmes pour calculer les constantes des PID en fonction des temps de calcul.
Dans [31], Jordà ajoute dans sa commande un bloc de compensation du temps
de calcul sur l’estimation de l’angle des vecteurs de flux pour tenir compte de
la rotation de ces vecteurs entre l’instant d’échantillonage et la fin du calcul de
la commande dans son microcontroleur.
Ce qui est intéressant de constater ici, c’est que l’algorithme de commande
n’est plus figé avant son intégration, mais qu’il peut subir des modifications en
fonction de l’intégration choisie.
2.4 La conception mixte matériel/logiciel
Ce concept a séduit beaucoup de chercheurs ces dernières années et de
nombreux projets ont vu le jour [11][52][33][15] ce qui a donné lieu à différentes
approches méthodologiques. Nous nous baserons toutefois sur les travaux de
Gajski et Vahid [6][5] qui synthétisent ces méthodologies d’une façon conceptuelle.
La conception mixte (aussi appelée conception concurrente ou «codesign» en
anglais) prétend développer conjointement la partie matériel et la partie logiciel dans un système donné et ce à partir d’un modèle fonctionnel commun
de haut niveau qui permet de s’affranchir d’une spécification exacte des caractéristiques finales du circuit intégré. Nous préférons d’ailleurs le terme de
conception mixte à celui de conception concurrente car il ne s’agit pas seulement de développer le matériel et le logiciel en même temps, il s’agit surtout
de les développer ensemble et donc de faire interagir la conception de l’un et de
l’autre.
Lorsque nous parlons de matériel ou de logiciel, nous nous référons respectivement aux ASIC et aux processeurs de tous types (microcontroleur, processeurs standarts, DSP), le «logiciel» de ces derniers étant le programme assembleur exécuté par ces processeurs.
La conception mixte est basée sur quatre concepts principaux:
– la spécification fonctionnelle
– l’exploration de l’espace des solutions de réalisation
6. VHDL-Analogic
7. Proportionnel Intégral Dérivé
46
– le test fonctionnel des modèles
– la synthèse mixte
Chacun de ces concepts correspond à une étape générique de la conception à laquelle sont associées des tâches à réaliser pour mettre en oeuvre le concept. La
communication entre les tâches est assurée par des modèles et les contraintes
associées. La figure 2.2 présente cette méthodologie générique sous forme de
graphiques qu’on pourrait appeler «flux de modèles» (modelflow) par analogie aux graphes «flux de données» (dataflow). Comme on peut le voir, cette
méthodologie est itérative en raison des rebouclages des résultats de tâches
sur des tâches précédentes.
F IG . 2.2 – Méthode de conception mixte générique
Dans le paragraphe suivant, nous détaillons le contenu de chaque étape et
la signification de chaque tâche.
47
2.4.1 Détail de la méthode
2.4.1.1 La spécification fonctionnelle
Le but de cette étape est de spécifier le mieux possible le système à réaliser,
c’est à dire de définir d’une part quelles doivent être les sorties du système
pour des entrées données, d’autre part, comment le système doit calculer ses
sorties, comment il doit être fait, et finalement de définir les caractéristiques du
circuit à réaliser.
Cette étape est particulièrement importante car de sa bonne réalisation dépend en grande partie le succès de la méthodologie et le bon fonctionnement
des outils associés car si la méthodologie de conception mixte prétend pouvoir
traiter des spécifications de caractéristiques plus ou moins floues, la fonctionnalité du système doit elle être définie très précisément. Plus une erreur de
spécification est détectée tard dans la conception, plus elle coûte cher. Malheureusement, l’expérience montre que c’est une étape souvent très mal traitée
dans les projets de conception.
La spécification fonctionnelle est un processus itératif qui comprend l’analyse du système, la modélisation et la définition des objectifs de conception.
Elle interagit avec l’étape de test fonctionnel pour assurer que les modèles présentent le comportement attendu (cf. Fig. 2.3).
Les paragraphes suivants décrivent en détail les tâches requises pour la
spécification fonctionnelle du système.
F IG . 2.3 – Spécification fonctionnelle
Analyse fonctionnelle du système Cette tâche consiste à définir les différents types de fonctions qui constituent le système (p.e. les protocoles de communication, les fonctions algorithmiques, les machines d’état) et les relations
temporelles et physiques qui existent entre elles. On va donc définir un ordre
d’exécution et les données transmises entre elles. Pour avoir un exemple d’une
telle analyse, le lecteur peut se reporter au paragraphe 5.3.1.
48
Modèle de compréhension Un modèle de compréhension, comme l’indique son nom, permet de comprendre comment fonctionne un système. Il
peut par exemple définir les sorties du système sans préciser comment celles-ci
sont calculées ni indiquer des temps de fonctionnement.
Pour formaliser cette étape, de nombreux travaux ont été réalisés sur les
langages de spécification formelle. Il n’existe pas de langage «parfait» permettant de modéliser n’importe quel type de fonction. En fait, les langages qui se
sont développés au cours du temps permettent chacun de spécifier une certaine
classe de fonction. Ainsi, les «graphes de flux de données» (dataflow graph)
sont les mieux adaptés pour les fonctions qui opèrent la même transformation
à travers le temps sur un flux de données. Les machines d’état s’imposent par
contre pour des systèmes fortement séquentiels. Il existe encore de nombreux
autres modèles pour lesquels nous renvoyons le lecteur vers les articles pertinents [16].
L’analyse qui a eu lieu avant permet maintenant de choisir le langage de
modélisation le plus approprié pour chaque classe de fonction définie. L’utilisation de plusieurs modèles ne doit pas être un obstacle, elle permet au contraire
de faciliter la modélisation et la clarifier.
Modèle de spécification Le modèle de spécification se distingue du modèle de compréhension par le fait qu’on définit maintenant comment sont générées les sorties, c’est à dire, comment est réalisé fonctionnellement le système.
Pour comprendre la différence entre modèle de compréhension et modèle
de spécification, prenons l’exemple d’une commande vectorielle classique de
machine asynchrone.
Dans un modèle de compréhension, on définirait par exemple la commande
comme une fonction permettant de calculer les courants statoriques dans un
repère tournant , à partir des courants de ligne , et ; puis le calcul d’une régulation sur ; puis le calcul des impulsions de commande des
transistors de l’onduleur (cf. Annexe A).
Dans un modèle de spécification, on va définir exactement quelle fonction
est utilisée pour la transformation de , et vers et , et quels calculs
sont effectués exactement, puis on définira le type de régulation à utiliser (p.e.
PID ou RST) et les calculs à réaliser, puis comment calculer les impulsions de
commande des interrupteurs de puissance.
Les langages à utiliser sont les mêmes que pour le modèle de compréhension. Il est d’ailleurs possible, si la fonctionnalité du système est suffisamment
claire, de se passer du modèle de compréhension.
La spécification des objectifs de conception Lors de la spécification du
système, on est aussi amené à définir les caractéristiques du circuit intégré à
concevoir. Ces caractéristiques se partagent en trois catégories:
1. les caractéristiques physiques: ce sont là les performances du système
(vitesse de calcul, consommation, temps de latence ...etc.), des indications architecturales (nombre maximal de plots imposé par le type de
49
boîtier, type de connection avec l’environnement ...etc.), et les caractéristiques analogiques (fan-in/fan-out, CEM, protection vis à vis des décharges électrostatiques, technologies résistantes au radiations ...etc.).
2. la testabilité du circuit: testabilité en fabrication (taux de couverture de
fautes) et testabilité fonctionnelle, c’est à dire la stratégie de test employée
(«scan-path», auto-test intégré ...etc.).
3. les contraintes commerciales: ce sont différentes contraintes afférentes au
coût unitaire par rapport à une production minimale prévue, à la technologie employée, au délai de conception, à l’évolution du produit ...etc.
S’il est possible de définir assez précisément les caractéristiques physiques et
de test du circuit, il est par contre plus difficile de préciser exactement les
contraintes commerciales.
Mais, un des objectifs de la méthodologie de conception mixte étant précisément de rendre la conception moins dépendante des caractéristiques spécifiées
du système, il est possible de se contenter de «spécifications floues» qui seront
reprécisées lors du cycle de conception. Par contre, rappelons que la fonctionnalité du système doit, elle, être défini très exactement.
2.4.1.2 L’exploration de l’espace des solutions de réalisation
L’exploration est une notion clé de la conception mixte. Le but recherché est
de trouver la réalisation assurant le meilleur compromis entre les différentes
contraintes de conception. C’est un travail évidemment très complexe et pour
lequel l’automatisation est à même d’apporter une aide appréciable au concepteur. Mais, il est impossible d’aborder de front l’automatisation des tâches qui
composent l’exploration en raison de la complexité du problème. Actuellement,
l’approche retenue est donc d’aborder le problème sous l’angle d’une application particulière: applications audio ou vidéo, télécom, automates, ...etc. De
cette manière, il est possible de restreindre les recherches à un espace de solutions présentant déjà des propriétés-clés, requises pour l’intégration de l’application envisagée. Un exemple est de prédéfinir l’architecture à employer
(nombre de processeurs, d’ASIC, de mémoires, de bus ...etc.).
Les tâches présentées dans les paragraphes suivants s’exécutent selon un
ordre qui n’est pas nécessairement celui exposé. L’exploration étant un processus itératif, on peut être amené à exécuter plusieurs fois ces tâches.
L’allocation L’allocation est la tâche de définir une architecture système
et de définir les ressources à employer pour réaliser la fonctionnalité voulue. Cette tâche est une des plus complexes à automatiser de la méthodologie
envisagée. En effet, le nombre de composants disponibles sur le marché est
très important. Du processeur classique aux fonctions spécifiques (contrôleur
50
F IG . 2.4 – Exploration de l’espace des solutions de réalisation
DMA 8 , FFT 9 , convertisseurs AD/DA 10 , ...etc.) en passant par les PLA 11 , FPGA
et ASIC, le choix est immense et en constante évolution.
Pour cette raison, deux stratégies sont aujourd’hui proposées:
– La première consiste à figer l’architecture et les ressources système en se
basant sur des considérations liées à l’application visée [33][15].
– la seconde limite le choix des ressources système à une bibliothèque de
composants et offre au concepteur une aide à la décision par des algorithmes d’allocation automatique et d’estimation de performances [6].
Le partitionnement Avant de parler du partitionnement lui-même, il est
nécessaire d’introduire la notion de granularité de partitionnement. La granularité est le plus petit objet indivisible considéré lors du partitionnement. Par
exemple, si on considère un algorithme, le plus petit objet peut être une fonction, ou un ensemble de fonctions. Il importe seulement que par rapport au
modèle de spécification considéré, on soit capable de définir pour chaque objet son niveau de granularité. Si on utilise un modèle VHDL par exemple, on
pourrait définir arbitrairement la granularité suivante:
par ordre croissant: opération arithmétique, instruction, bloc d’instructions, boucle, fonction, processus et entité.
L’opération de partitionnement peut se définir alors comme le fait d’allouer
(mapping) à chaque ressource système un ou plusieurs objets du plus bas niveau de granularité (appelé aussi un noeud) et de déterminer l’ordre d’exécution
(scheduling) des noeuds.
8.
9.
10.
11.
Direct Memory Access
Fast Fourier Transform
Analogique Digitale/Digitale Analogique
Programmable Logic Array
51
Il est évident que plus le niveau de granularité choisi est fin, plus l’opération de partitionnement est complexe et longue.
Le partitionnement s’effectue sur trois types d’objets: les variables qui sont
assignées à la mémoire, les traitements, c’est à dire des objets qui modifient
leurs variables d’entrée (boucles, instructions conditionnelles ...etc), qui sont
assignés à des ressources standards ou sur mesure, et les transferts d’information qui sont affectés à des bus.
Pour effectuer le partitionnement, les informations suivantes sont nécessaires:
– la granularité du partitionnement.
– les contraintes d’optimisation du système, c’est à dire les grandeurs telles
que puissance, fréquence, surface silicium ...etc. qu’il faudra optimiser.
– un modèle d’estimation de chaque grandeur d’optimisation.
– des fonctions de coût combinant les estimations pondérées des grandeurs
d’optimisation. Grâce à ces fonctions de coût, il est possible d’orienter
la recherche de solution par l’importance accordée à chaque grandeur
d’optimisation.
A partir de ces informations, des algorithmes sont capables d’examiner les
solutions possibles au problème du partitionnement. Différentes techniques
existent dont l’affectation aléatoire, le groupement hiérarchique, la migration
de groupe, les algorithmes génétiques ou le recuit simulé. Nous renvoyons là
encore le lecteur intéressé vers des publications pertinentes [7][53].
La détermination de l’ordre d’exécution des opérations est un point important de la partition. Cette information servira par la suite durant l’étape de
synthèse mixte.
Cet ordre d’exécution dépend de la partition choisie. Par exemple, des opérations concurrentes dans le modèle de spécification mais implantées sur une
même ressource logiciel devront être exécutées séquentiellement. Idem pour
une cible matériel lorsque l’opération accède à une ressource partagée (p.e.
ALU 12 ).
Il existe deux types de stratégies pour déterminer l’ordre d’exécution des
opérations dans un système temps réel:
1. soit le séquencement est statique, c’est à dire que l’ordre d’exécution est
figé à la conception.
2. soit le séquencement est dynamique. Dans ce cas, l’ordre de séquencement est généralement basé sur une stratégie d’allocation de priorité, le
problème étant de minimiser les temps d’attente et d’éviter le blocage
d’une tâche qui ne pourrait pas accéder à une ressource partagée.
Différents algorithmes existent pour réaliser cette tâche [17].
12. Arithmetic and Logic Unit
52
La transformation Dans le paragraphe consacré au partitionnement, nous
avons supposé que le partitionnement s’effectuait directement sur le modèle
de spécification. Or, si cela est vrai lors de la première itération d’exploration,
il n’en est rien lors des itérations suivantes.
En raison d’une conception souvent hiérarchique et pour clarifier le modèle, le concepteur a souvent recours à des fonctions dans le modèle de spécification. Mais par la suite, il n’est pas évident que pour atteindre des objectifs de
fréquence de traitement, un appel à fonction soit efficace. Et si l’intégration de
la fonction est effectuée par un module matériel spécifique, il est possible que
la contrainte budgétaire ne soit pas respectée.
La transformation consiste à examiner ce genre de problème en modifiant
le modèle de départ. Elle peut être de différentes natures, c’est à dire porter sur
le contenu de la spécification ou sur la structure de celle-ci.
Lorsqu’elle porte sur le contenu, elle peut s’exercer à différents niveaux de
la spécification [33]:
– Au niveau algorithmique, il est souvent possible d’implanter la même fonction de différentes manières. Si on prend l’exemple d’un filtre FIR 13 , il
peut se construire sous forme de produit ou sous forme de FFT. Cette
transformation n’est pas triviale et ne peut être traitée actuellement qu’à
la main.
13. Finite Impulse Response
53
– Au niveau fonction élémentaires, il est possible d’utiliser des implantations
différentes. Par exemple, il est possible de remplacer une multiplication
de constante par une série de décalages et d’additions.
– Au niveau conception logique, il est possible de réaliser la même fonction
de diverses manières. Ainsi, pour un multiplieur par exemple, il existe de
nombreuses implantations qu’il est possible de choisir automatiquement
en fonction des contraintes de temps et de surface imposées au multiplieur.
Lorsque la transformation porte sur la structure de la spécification, les techniques utilisées consiste à réintégrer une fonction dans le code séquentiel (to
«in-line»), fusionner des processus, aplanir une hiérarchie ou grouper des instructions en procédure.
La plupart de ces techniques sont issues du génie informatique où elles
sont couramment utilisées par les compilateurs pour optimiser les codes objets.
Aujourd’hui, ces techniques sont utilisées dans de nombreux outils de CAO 14
[5].
L’estimation L’estimation des performances et des grandeurs d’optimisation d’un système n’est pas simple dans la mesure où il faut trouver un compromis entre précision et vitesse d’estimation. S’il faut estimer ces variables
pour plusieurs milliers de solutions, on ne peut pas se permettre des temps de
calcul de l’estimation trop importants.
Or la synthèse physique d’un modèle de spécification n’est pas linéaire: par
exemple, la surface totale de la partie matériel ne sera pas égale à la somme des
surfaces de tous les noeuds. Ces non-linéarités sont dues en partie aux optimisations auxquelles se livrent les outils de synthèse logique et les compilateurs.
Elles sont dues également à des structures architecturales spécifiques comme
le pipeline, la mémoire cache ... etc.
Du fait de cette non-linéarité, l’estimation est plus complexe. Si on désire
obtenir une estimation très fiable, il faut recourir à la synthèse et la compilation des codes, donc se rapprocher beaucoup de l’implantation physique. Cela
coûte cher en terme de temps de calcul si bien que cette solution n’est pas
réalisable dans l’optique d’une exploration itérative d’un grand nombre de solutions.
La stratégie actuelle est donc d’estimer les grandeurs d’optimisation pour
avoir un ordre de grandeur. Ces estimations sont beaucoup plus rapides et
permettent une exploration itérative.
Différentes techniques existent, permettant de tenir compte dans une certaine mesure des non-linéarités. La plus répandue est l’utilisation d’une librairie de composants et fonctions pour lesquels les grandeurs d’optimisation sont
connus précisément [47]. Lors du partitionnement, les noeuds utilisés correspondent à cette librairie. L’estimateur effectue alors la somme pondérée des
grandeurs d’estimation élémentaires.
14. Conception Assistée par Ordinateur
54
D’autres techniques, basées sur le même principe peuvent être trouvées
dans [18].
2.4.1.3 La synthèse mixte
Sous ce concept général, nous regroupons trois types de tâches:
– l’affinement du modèle de spécification fonctionnelle qui se traduit par
la génération de code qui complète le modèle.
– la synthèse conjointe de code de haut niveau, c’est à dire aussi bien des
langages de programmation traditionnels type C et des langages de description matériel type VHDL.
– la synthèse logique du langage de description matériel et la compilation
du langage de programmation.
Les tâches de placement/routage et l’assemblage du code objet ne sont envisagées que dans la mesure où les performances du système doivent être connues
avec plus de précision. Mais on considère que la réalisation physique des circuits à partir d’une netlist et d’un code objet est bien maîtrisée de nos jours
dans la mesure où on ne se trouve pas à la limite technologique (p.e. technologies submicroniques actuellement). Il n’en n’est pas tout à fait de même
pour les trois tâches évoquées avant. Et même si l’automatisation des tâches
de synthèse est systématique de nos jours, elle n’est pas sans poser quelques
problèmes.
L’affinement du modèle de spécification Lors de la génération du modèle de spécification, on ne s’est pas préoccupé de la gestion des mémoires, de
l’allocation de l’espace adressable, de l’interfaçage entre composants ni de l’arbitrage de l’accès aux ressources partagées. Ceci est normal puisque ce n’est
qu’à l’étape de conception suivante, l’exploration, qu’on déterminera les ressources du système et son architecture.
Le partitionnement étant effectué, il faut donc traiter maintenant cette spécification supplémentaire du système.
Si la spécification des structures logiques pour la mémoire ne pose pas trop
de problèmes et que des techniques existent pour gérer l’arbitrage de l’accès
aux ressources partagées, il n’en est pas de même pour l’interfaçage des composants. Remarquons au passage que dans le cas de l’arbitrage, nous nous restreignons au cas simple où plusieurs processus (ou dispositifs) veulent accéder en même temps à une ressource unique. Classiquement, on résout ce problème en allouant des niveaux de priorité aux processus. Cette allocation peut
être statique ou dynamique. Nous ne nous étendrons pas plus sur ce sujet.
Le choix de l’interface entre composants est complexe. Il existe plusieurs
types de communication entre composants (matériel-matériel, matériel-logiciel,
logiciel-logiciel) et une multitude de protocoles envisageables (protocoles asynchrones, par adressage mémoire, ...etc.). Le choix de l’interface dépend d’une
part du composant à interfacer (composant standart ou sur mesure) et du type
55
F IG . 2.5 – Synthèse mixte
56
de données à transmettre (mot unique, trame, flux continu, ...etc.). Il peut même
se présenter le cas de l’interfaçage de deux composants dont les interfaces sont
figées et différentes. Dans ce cas, il faut générer la description d’un transducteur.
L’automatisation du choix de l’interface n’est donc pas évidente.
Synthèse de code haut niveau Le partitionnement terminé, chaque noeud
du modèle de spécification est attribué à une ressource du système et le séquencement statique ou dynamique est défini. A partir de ces informations, il est relativement aisé de générer le code correspondant à chaque noeud, les noeuds
matériels générant du code de description matériel (HDL) et les noeuds logiciels du code de programmation classique. A partir de l’ordre d’exécution des
noeuds, on construit le séquenceur global.
Ici, peu de problèmes se posent vu que les difficultés majeures proviennent
du bon séquencement des opérations, défini lors du partitionnement.
On notera tout de même que le code HDL généré doit être à la fois simulable et synthétisable. Or l’expérience montre qu’un code produisant de bon
résultats de synthèse est lent à la simulation et vice-et-versa. La génération de
code doit donc tenir compte de son utilisation attendue.
Deux techniques sont employées aujourd’hui pour la génération du code:
– la traduction/compilation du modèle de spécification [15]
– l’utilisation de librairies d’opérateurs avec leurs descriptions associées
[12][27]. Cette technique suppose l’utilisation dans le modèle de spécification des opérateurs de la librairie.
Synthèse logique et compilation Si les techniques de synthèse logique et
de compilation sont bien maîtrisées, il est quand même intéressant de noter
que la synthèse comme la compilation donne de meilleurs résultats lorsque le
code traité respecte les consignes de l’outil utilisé.
Au niveau de la synthèse logique, on obtient toujours encore de bien meilleurs
résultats pour un circuit décrit par transfert de registres (RTL-level) qu’au niveau comportemental (behavioural description).
2.4.1.4 Test fonctionnel des modèles
Nous regroupons sous test fonctionnel trois concepts qui s’appuient sur
des techniques fondamentalement différentes, mais dont le but est le même,
c’est à dire vérifier ou prouver qu’un circuit ou un système donné présente le
comportement défini par les spécifications.
Ces trois concepts sont:
– la simulation, c’est à dire le calcul des sorties d’un système pour des entrées données à partir d’un modèle de celui-ci.
57
– la preuve formelle, c’est à dire la vérification à partir d’un modèle qu’une
propriété du système correspondant est vraie. Un exemple de propriété
pour une machine d’état serait «si l’entrée A vaut 1, alors l’état X ne sera
jamais atteint».
– l’émulation, c’est à dire le fonctionnement du circuit sur un système de
prototypage.
Le test fonctionnel intervient à plusieurs reprises dans la méthodologie. Selon
les cas, que nous détaillerons maintenant, on utilise soit la simulation, soit la
preuve formelle, soit l’émulation.
Simulation La simulation est traditionnellement la méthode utilisée pour
vérifier fonctionnellement un système. Mais, avec la complexité croissante des
fonctionnalités à intégrer, deux problèmes se sont posés à la simulation:
1. les temps de simulation qui, lorsqu’on veut simuler l’ensemble des combinaisons des vecteurs d’entrée, deviennent inabordables. On peut facilement atteindre des temps de simulation CPU de plusieurs centaines
d’années [25].
2. la simulation de systèmes définis par plus d’un modèle de comportement
(p.e. une partie flux de données et une partie protocole de communication). On parle alors de système «hétérogène» [1]. Ce type de systèmes
requiert l’utilisation de simulateurs capables de «cosimuler» l’ensemble
des modèles de comportement présents.
La cosimulation est aujourd’hui une réalité ce qui permet de simuler l’ensemble des systèmes et non plus des bouts séparément. Par contre, les temps
de simulation restent un problème et pour cette raison, d’autres techniques ont
vu le jour.
Preuve formelle La preuve formelle permet actuellement de réaliser les
tâches suivantes:
– prouver l’équivalence de circuits issus d’une même conception. Ceci peut
être nécessaire lorsque des modifications ont été apportées à un circuit
(insertion de logique de test par exemple) ou que certaines transformations ont été effectuées manuellement (réalisation manuelle du schéma
logique d’un opérateur). La vérification d’équivalence a lieu en général
par rapport à un modèle de référence supposé exact.
– prouver des propriétés mathématiques d’un circuit donné. Prouver des
propriétés permet de vérifier qu’une fonctionnalité souhaitée du circuit
est bien assurée. On notera toutefois que la preuve formelle de propriétés
mathématiques est restreinte à certaines propriétés. Ces restrictions font
qu’on ne peut pas actuellement valider exhaustivement un circuit par la
preuve formelle.
58
L’intérêt principal de ces méthodes réside dans le fait que la preuve formelle,
lorsqu’elle est applicable, consomme très peu de puissance CPU comparé à une
simulation.
Le principe de ces techniques est d’extraire un graphe booléen (BDD 15 )
d’un modèle de circuit (netlist, modèle HDL, ...etc.), puis de réduire ce graphe.
Pour vérifier l’équivalence de deux circuits, on vérifie que leurs graphes sont
isomorphes pour un même ordonnancement des vecteurs d’entrée. Pour prouver une propriété mathématique, on réduit le graphe de départ en fonction de
l’hypothèse donnée (p.e. «si A vaut 1») et on examine si avec l’ensemble des
solutions possibles, la propriété est vérifiée (p.e. «l’état X n’est jamais atteint»).
Actuellement, la preuve formelle reste encore une affaire de spécialiste car
selon le modèle de départ employé et la formulation des propriétés, il sera ou
non possible d’obtenir les résultats attendus.
L’émulation L’émulation repose sur le principe du prototypage des circuits sur des systèmes standarts. L’intérêt de prototyper un circuit intégré (en
programmant par exemple des réseaux de FPGA interconnectés) est de profiter
de la vitesse de calcul d’un circuit spécifique tout en disposant de la possibilité
de modifier le circuit et de le reprototyper si les résultats de l’émulation ne sont
pas satisfaisants. En fait, l’émulation repose sur le même principe que la simulation (on examine le résultat du traitement de vecteurs d’entrée) mais avec des
vitesses d’exécution bien supérieures. L’inconvénient principal de cette technique est le prix des émulateurs (de l’ordre du demi million de dollars pour
les plus puissants). On peut bien sûr utiliser aussi des cartes spécialisées pour
l’émulation, mais leur puissance et leur champ d’utilisation sont limités.
2.4.2 Les outils de conception mixte
Les travaux de recherche dans ce domaine ont donné naissance à de nombreux outils de conception mixte, ou se définissant comme tels. La plupart de
ces outils sont en libre distribution à travers le réseau.
Nous ne prétendons pas ici faire une liste exhaustive de ces outils, mais
proposer un rapide survol des capacités de certains d’entre eux par rapport
à la méthodologie de conception mixte que nous avons présentée. Ce faisant,
nous distinguerons les outils que nous avons testés sur le site du CEGELY,
de ceux pour lesquels nous n’avons que des renseignements issus de publications ou d’informations présentées sur le réseau. Un paragraphe sera consacré
également aux outils qui ne se définissent pas par rapport à la méthodologie
de conception mixte, mais qui permettent néanmoins de réaliser certaines des
tâches que nous avons évoquées.
15. Boolean Data Diagram
59
F IG . 2.6 – outils de conception testés
60
2.4.2.1 Outils testés
Comme il apparaît figure 2.6, aucun outil à ce jour peut prétendre gérer
l’ensemble du cycle de conception mixte.
Cette constatation nous amène à un enjeu supplémentaire non évoqué jusqu’à présent et qui fait l’objet de la thèse de A. Kalavade [33]: l’exploration de
l’espace de conception.
Par cette expression, A. Kalavade exprime la nécessité pour le concepteur
de choisir non seulement une solution technologique (à travers notamment l’exploration de l’espace des solutions) pour implanter la fonctionnalité, mais également les modèles et outils à utiliser pour la conception.
Le choix qui s’offre est très étoffé et plusieurs auteurs [51] proposent de gérer automatiquement l’utilisation des outils, c’est à dire de gérer les structures
de données, le format de transfert des données entre outils et l’exécution des
tâches de conception.
Voyons maintenant un à un les outils testés.
Ptolemy Distribué sur le réseau (binaires et sources) par le «Department of
Electrical Engineering and Computer Sciences» de l’université de Berkeley, Californie, Ptolemy est défini par ses concepteurs comme un outil de cosimulation
de systèmes hétérogènes et de synthèse mixte [12].
Le concept de base de Ptolemy est la notion de modèle de simulation. Par
cette notion, les auteurs définissent les méthodes algébriques à utiliser pour
simuler un type de fonctionnalité donné. A chaque modèle de simulation est
associé un «domaine» donné. La cosimulation consiste à simuler ensemble différents domaines au sein d’un même projet. La synthèse mixte revient au même
car les auteurs ont défini au sein de Ptolemy, des domaines de génération de
code.
Un même projet pouvant comporter plusieurs domaines de simulation et
de synthèse de code (notion d’hétérogénéité), on peut modéliser des systèmes
complexes allant du système intégré mixte (matériel et logiciel) jusqu’au réseau
de poste de travail communicant par des protocoles donnés.
Par ailleurs, Ptolemy permettant de changer le domaine d’appartenance
d’un morceau de projet par modification de paramètre, il est relativement aisé
d’effectuer un partitionnement manuel d’un modèle à prototyper.
Pour définir le système, l’utilisateur dispose d’une interface graphique lui
permettant de créer un schéma bloc à partir d’une librairie de fonctions, propre
à chaque domaine. Ptolemy étant fourni avec les sources, les différentes librairies peuvent être modifiées et personnalisées, ce qui est particulièrement intéressant pour les domaines de génération de code. L’utilisateur peut même créer
de nouveaux domaines avec leur librairie associée. En annexe E, nous proposons un exemple de modélisation et simulation d’un système très simple de
commande.
Dans sa distribution actuelle, Ptolemy est fortement orienté vers la modélisation et le prototypage d’applications télécom, audio/vidéo et réseau.
61
Polis Distribué sur le réseau (binaires et sources) par l’université de Berkeley,
Californie, ses auteurs le définissent comme un environnement de conception
mixte de contrôleurs intégrés temps réel de systèmes réactifs, c’est à dire des
systèmes réagissant immédiatement à des évènements sur leurs entrées. Des
exemples typiques de telles applications sont les autocommutateurs téléphoniques, les robots, les automates, les contrôleurs de chaîne de production ...etc.
La modélisation des systèmes est effectuée par machine d’état (principalement par le langage réactif Esterel [3]). La plupart des étapes de conception
mixte sont effectivement supportées par Polis (cf. Fig. 2.6). Par contre, pour la
cosimulation, Polis a recourt à Ptolemy, et pour la preuve formelle, à VIS.
Alta Outil commercial distribué par Alta Group, une société du groupe Cadence, Alta repose sur les résultats de recherche obtenus avec Ptolemy et POLIS. Dans sa version actuelle, seul le modèle de simulation de flot de donnée
synchrones (SDF: Synchronous Data Flow) est proposé, associé avec des domaines de synthèse de code vers des cibles DSP et VHDL/Verilog.
Comme Ptolemy, Alta propose une interface graphique permettant de définir un système sous forme de schéma bloc à partir d’une bibliothèque de
composants.
2.4.2.2 Outils spécifiques testés
Les outils que nous présentons maintenant ont une fonction très spécifique
et peuvent servir pour exécuter une des tâches de la conception mixte. Nous
ne parlons que d’outils, pas de modèles.
MATLAB / SIMULINK Outil de calcul mathématique basé sur le calcul matriciel, MATLAB propose des bibliothèques de fonctions spécifiques pour le
développement d’algorithmes de contrôle sous un environnement graphique
(SIMULINK), ainsi que des algorithmes standarts pour la résolution des équations différentielles. Cet outil propose également un utilitaire (DSPACE) pour
la génération automatique de code C à partir des schémas blocs SIMULINK,
code C compilable sur des familles de DSP données.
Les schémas blocs peuvent être simulés en tenant compte d’une précision
binaire limitée (simulation par entiers).
On ne peut évidemment pas parler d’outil de conception mixte, mais MATLAB / SIMULINK peut être utile pour la construction d’un modèle de compréhension et pour étudier quelques propriétés binaires de l’algorithme envisagé.
SYNOPSYS Ensemble d’outils pour la simulation et la synthèse de code HDL
(VHDL ou Verilog). La synthèse peut être effectuée vers des technologies précaractérisées ou vers des FPGA. Synopsys permet d’estimer les performances
et caractéristiques d’un circuit après synthèse. L’utilisation de scripts pour automatiser les tâches de synthèse en fait un outil très performant.
62
2.4.2.3 Outils de conception mixte non testés
Comme nous l’avons déjà dit, l’intérêt provoqué par ce thème de recherche
est à l’origine de nombreux travaux dont les résultats se concrétisent la plupart
du temps par des outils expérimentaux. Beaucoup de ces outils sont librement
distribués sur le réseau, d’autres ne sont connus qu’à travers des publications.
Pour autant que nous ayons pu en juger par les publications, les outils dont
nous parlons suivent tous la même méthodologie générique que nous avons
décrite, avec quelques variantes selon l’application visée ou le problème étudié.
Parmi les outils apparaissant dans la littérature, citons COSMOS, outil développé à l’INPG de Grenoble, COSYMA, développé à l’Université de Braunschweig (Allemagne) et VULCAN, développé à Stanford (USA).
COSMOS est un outil optimisé pour l’intégration de protocoles de communication. Basé sur le langage SDL, il intègre le système sur un réseau de
processeurs ou sur une architecture mixe processeur/ASIC.
COSYMA est basé sur le langage , une extension du C. Son domaine
d’application n’est pas défini clairement dans la littérature. La stratégie d’intégration repose sur la migration du logiciel vers le matériel.
VULCAN est prévu pour l’intégration de systèmes temps réel. Sa stratégie
d’intégration repose sur la migration du matériel vers le logiciel en s’appuyant
sur le langage de modélisation HardwareC, autre extension du C.
D’autres projets existent sur lesquels nous ne disposons pas d’informations
précises: LYCOS de l’Université Technique de Lyngby (Danemark), CODES de
Siemens (Allemagne), TOSCA de Italtel (Italie), SynDex de l’INRIA (France),
SAW de l’Université de Carnegie Mellon (USA) et COWARE de IMEC (Belgique).
2.5 Conclusion
Avec une complexité croissante des systèmes à intégrer et des contraintes
technologiques, temporelles et budgétaires toujours plus fortes, les approches
classiques d’intégration ne suffisent plus. Des enjeux nouveaux comme une
flexibilité accrue de la conception permettant une modification à posteriori de
la stratégie d’intégration, une exploration systématique et automatique des solutions techniques et une vérification formelle du système, ne sont pas traités.
Même si certains travaux portant sur l’intégration des algorithmes de commande des machines électriques ont présenti la nécessité d’aborder la conception autrement, leur approche ne permet pas de résoudre les problèmes évoqués. Ces travaux nous permettent néanmoins de mettre en évidence des spécificités de l’intégration de la commande dont il faudra tenir compte lors de
l’application d’une méthodologie d’implantation. On gardera ainsi à l’esprit
l’importance du choix de la fréquence de calcul du système, le problème de
l’arithmétique binaire à employer et du séquencement des opérations vis à vis
de la précision binaire, et finalement, l’intérêt qu’il peut y avoir à modifier l’algorithme de départ pour tenir compte de la réalisation physique.
63
Le concept de conception mixte par contre, aborde l’intégration d’une fonctionnalité (protocoles, algorithmes, fonctions logiques, ...etc.) de façon systématique. L’utilisation de modèles fonctionnels, associée aux algorithmes pour
l’exploration des solutions de réalisation, permet une conception plus flexible,
moins liée aux spécifications technologiques et budgétaires, et donc une conception plus réactive également. Les spécifications floues ne posent plus de problème puisqu’il devient possible d’affiner ces spécifications en fonction des
estimations sur les performances d’intégration. En ce qui concerne les outils
supportant la méthodologie de conception mixte, nous avons vu qu’un choix
important s’offre au concepteur, lui permettant de réaliser une grande partie
des tâches automatiquement.
Compte tenu de ces avantages, il nous a paru intéressant d’adapter la méthodologie générique de conception mixte au cas de l’intégration des algorithmes de commande des machines électriques AC.
64
Chapitre 3
Élaboration d’une
méthodologie d’implantation
des commandes de moteurs
AC
3.1 Introduction
Dans le premier chapitre, nous avons vu que les méthodes classiques d’implantation de fonctionnalité, caractérisées par des spécifications figées et une
faible automatisation de la conception haut niveau, ne permettent pas de résoudre un certain nombre de problèmes de conception (p.e. modification des
spécifications en cours de conception). Ces problèmes se posent aussi pour l’intégration des commandes de machines électriques (cf. 2.3).
Aussi, nous avons décidé d’employer une méthodologie de conception mixte
matériel/logiciel. La méthode que nous avons déjà présentée (Gajski-Vahid, cf.
Fig. 3.1, p. 66) est une approche générique de conception. Le travail que nous
présentons tout au long de ce chapitre consiste en l’adaptation de cette méthode générique au cas spécifique de l’intégration de la commande des machines AC.
Cette adaptation repose essentiellement sur l’analyse de travaux antérieurs
[43][31][10][37][30]. Remarquons tout de même que nous ne modifions pas la
méthode générique, nous spécifions simplement certaines tâches pour l’intégration des systèmes de commande.
Notre approche est la suivante:
1. Nous présentons d’abord les problèmes spécifiques de la commande et
nous localisons dans la séquence des tâches à effectuer, où appliquer la
solution théorique.
65
F IG . 3.1 – Méthode générique de conception mixte selon Gajski-Vahid
66
2. Nous nous attachons dans une deuxième partie à décrire les solutions
théoriques possibles en ayant auparavant défini quelques spécifications
restrictives propres aux machines AC afin de limiter la complexité des
problèmes.
3. Une fois les solutions proposées, nous décrivons finalement les moyens
pratiques mis en oeuvre (langages et outils), et synthétisons la méthodologie spécifique à la commande.
Par soucis de clarté, nous avons placé au début de chaque paragraphe principal, le schéma de la méthodologie générique de conception mixte sur laquelle
la tâche traitée par le paragraphe apparaît en grisé.
3.2 Localisation et formulation des problèmes spécifiques à la commande
Le but de ce paragraphe est de localiser et formuler les problèmes spécifiques à la conception de systèmes intégrés de commande afin de savoir plus
tard sur quel modèle nous aurons travailler pour traiter le problème.
3.2.1 Les spécifications floues
1
Le problème des spécifications floues n’est pas particulier à la commande
des machines électriques, mais nous aborderons ce sujet pour discuter de deux
spécifications, propres à la commande:
1. les temps de la commande: temps de calcul, fréquence de commutation,
fréquence d’échantillonage et fréquence d’horloge
2. la précision de calcul de l’algorithme de contrôle
3.2.1.1 Les temps de la commande
Ces temps dépendent en fait tous les uns des autres:
– où est le temps de calcul du système, est le nombre de
cycles d’horloge nécessaires au calcul de toutes les opérations, et est
la période d’horloge.
– où est la période d’échantillonnage, est la période de commutation et un entier compris généralement entre et .
– 1. Rappelons que le terme floue est à prendre au sens littéral et qu’il n’a rien à voir avec la
logique du même nom.
67
Comme on peut le constater, certains de ces temps dépendent de l’implantation. Or, on se trouve typiquement dans le cas où on va spécifier les valeurs
qu’on devrait idéalement atteindre (en fonction de l’application), puis on définira ce qu’on peut réellement faire en fonction d’estimations sur les modèles de
spécification.
3.2.1.2 Précision de calcul
Comme nous l’avons vu en 1.2.2, la commande telle qu’elle est développée
s’applique à des modèles théoriques de la chaîne d’entraînement qui ne collent
qu’imparfaitement à la réalité.
Bien des non-linéarités ne sont pas prises en compte si bien que même
en appliquant une commande à précision infinie au système réel, un certain
nombre d’erreurs demeure sur les grandeurs contrôlées (couple, vitesse, position) par rapport à la consigne.
Idéalement, on voudrait appliquer une commande à précision très grande
(p.e. 32 bits flottant), mais dans la pratique, une telle implantation a souvent
un coût non justifié, dû à une arithmétique binaire virgule flottante, beaucoup
plus complexe à intégrer et plus coûteuse en silicium.
Il nous reste alors deux autres solutions:
1. nous utilisons une arithmétique virgule fixe et donc la commande est à
précision finie. Notre problème est alors de définir une précision de calcul telle que celle-ci soit supérieure à la précision physique maximale atteinte par la chaîne d’entraînement. Autrement dit, l’implantation de la
commande ne doit pas introduire d’erreur sur les grandeurs commandées.
2. nous utilisons une arithmétique virgule fixe, mais nous ne nous préoccupons pas de la précision de l’implantation. Dans ce cas, il faut adapter
l’algorithme de commande pour compenser les erreurs sur les grandeurs
commandées, introduites par l’implantation.
La deuxième solution entraîne un accroissement de la complexité algorithmique qui signifie nécessairement un surcoût de l’implantation (soit en temps
de calcul, soit en surface silicium). La première solution nous paraît la plus
appropriée.
3.2.2 Partitionnement et séquencement
Dans le cas de la commande, le problème du partitionnement et du séquencement des opérations se révèle délicat en raison de la précision binaire qu’il
faut assurer.
Au début de la conception, dans l’étape de spécification, on ne sait pas
encore le type d’arithmétique qu’il faudra employer. Ce n’est qu’après avoir
étudié les solutions d’intégration possibles pour atteindre la précision requise
qu’on saura quelle arithmétique choisir.
68
Dans le cas où on utilise une arithmétique virgule fixe, l’étude de la précision définira la largeur des mots binaires. Par conséquent, elle affectera aussi
le partitionnement qui se base sur les estimations de surface de silicium et de
taille de code de programmation.
Le séquencement des opérations de calcul dans l’algorithme de commande
est également affecté par la contrainte de précision. Pour illustrer le propos,
prenons un exemple simple:
Supposons un format binaire où est le nombre de bits entiers et la longueur du mot binaire.
L’erreur de codage sur un nombre est limitée par
peut donc s’écrire
où est la valeur binaire de .
Supposons maintenant l’opération en arithmétique virgule
fixe.
La division de par un nombre ne diminue pas nécessairement l’erreur de codage (on suppose le diviseur sans erreur de codage), par
contre, la multiplication par une constante supérieure à 1 augmente
à coup sûr cette erreur.
Exemple:
Supposons que nous voulions calculer . Cette opération peut
être réalisée de deux manières.
Soit nous calculons d’abord:
£ !! ! soit nous multiplions directement par 2:
!! ! Lors de la constitution de la méthodologie, il nous faudra prendre en compte
le problème de l’influence de la précision sur le partitionnement et vérifier par
exemple qu’après l’étape de partitionnement (qui inclut le séquencement des
opérations), la précision requise est assurée.
69
3.2.3 Le test fonctionnel
Lors de l’intégration de la commande, plusieurs questions se posent au
concepteur que nous formulons ici:
1. Le système intégré fonctionne-t-il comme spécifié par le cahier des charges?
2. Le système fonctionnera-t-il correctement quelque soit le vecteur d’entrée
(problèmes de blocage logique du circuit, «deadlock» en anglais, dépassement de capacité binaire, «overflow», ...etc.)?
3. La précision binaire est-elle toujours assurée?
Pour un système simple, répondre à ces questions n’est pas difficile, mais pour
un système aussi complexe que la commande d’une machine électrique, ces
questions deviennent de vrai casse-têtes.
Examinons chacune de ces questions séparément.
3.2.3.1 Adéquation à la spécification initiale
La question ici est de savoir si le système qui a été modélisé correspond à la
spécification initiale du système. Par exemple, on veut savoir si le système génère systématiquement un signal pour une condition donnée, ou si la fonction
arithmétique calculée est bien celle spécifiée dans le cahier des charges.
Cette question se pose tout au long de la conception, mais comme nous
l’avons déjà fait remarquer précédemment, plus une erreur est découverte tard
dans le cycle de conception, plus elle coûte cher. Il est donc important de répondre à cette question dès que le modèle fonctionnel du système est disponible.
Dans la méthodologie générique, nous travaillons essentiellement avec quatre
modèles fonctionnels:
–
–
–
–
le modèle de compréhension
le modèle de spécification
le modèle de spécification partitionné
le modèle de spécification affiné
La validation du dernier modèle (spécification affinée) est particulièrement importante car c’est à partir de ce modèle qu’on génère le code pour le prototypage du système.
3.2.3.2 Le système fonctionnera-t-il quelque soit le vecteur d’entrée?
Cette question revient à rechercher la preuve que le système, tel qu’il a été
modélisé, fonctionne. Autrement dit, on va rechercher les vecteurs pour lesquels le système pourrait être mis en défaut.
70
Comme précédemment, cette question doit être réglée au plus tôt. Mais,
si on étudie de près la question, on s’aperçoit que cette validité du système
dépend du séquencement des opérations. Prenons un exemple:
, avec Nous voulons vérifier que l’opération " ne
risque pas de provoquer de débordement
binaire
(overflow).
Il apparaît clairement que vérifie la propriété, alors que
ne la vérifiera que pour des conditions très restrictives sur et sur le nombre de bits de .
Pour effectuer la validation du système, il faudra donc utiliser le modèle de
spécification partitionné qui définit le séquencement des opérations.
3.2.3.3 La précision binaire des résultats est-elle assurée?
Ce problème ne relève déjà plus vraiment de la validation fonctionnelle.
On cherche ici plutôt la preuve d’une propriété mathématique de l’algorithme
binaire. Cette propriété n’étant pas liée à un fonctionnement temporel, mais
seulement aux opérations binaires et à leur séquencement, on peut effectuer
les opérations de vérification sur un modèle mathématique de l’algorithme
comme le modèle de compréhension. Mais, avec le modèle de compréhension,
seul le séquencement des opérations en arithmétique réelle est connu. Il faut donc
effectuer la vérification de la précision sur le modèle qui indique le séquencement des opérations binaires, c’est à dire le modèle de spécification partitionné.
3.2.4 Résumons
Finalement, trois problèmes spécifiques se posent au concepteur de l’intégration de la commande:
– au niveau de la spécification du système, il faut préter attention à la définition des temps de la commande et à la précision requise sur les résultats.
– au niveau de l’exploration des solutions, on doit se pencher sur les interactions entre précision binaire, allocation de ressources et séquencement.
– finalement, les modèles de spécification doivent subir différentes validations fonctionnelles et vérifications de propriétés mathématiques.
3.3 Les spécifications restrictives
Comme nous le précisons en 2.4.1.2, l’application de la méthode de conception mixte générique est trop complexe pour être applicable directement. Les
stratégies actuelles consistent donc à appliquer des restrictions qui spécialisent
la méthode pour un type d’application donnée.
Pour l’intégration de la commande, nous allons également appliquer des
restrictions.
71
3.3.1 L’arithmétique
La première restriction concerne l’arithmétique. Afin de limiter la complexité que suppose d’étudier l’ensemble des possibilités de réalisation d’un algorithme de commande machine en mélangeant des opérateurs binaires d’arithmétiques différentes, nous limiterons l’intégration à une seule arithmétique.
Nous pourrions choisir l’arithmétique virgule flottante ce qui éliminerait le
problème de la précision binaire, mais il apparaît par expérience que, l’arithmétique virgule fixe, moins coûteuse en surface silicium et moins chère au niveau
processeur, est souvent suffisante pour une intégration réussie.
Nous avons donc décidé de nous en tenir à cette dernière arithmétique,
sachant que la méthodologie proposée sera également valable pour l’arithmétique virgule flottante en supprimant les étapes liées à l’étude de la précision
binaire.
3.3.2 Les ressources et l’architecture système
L’allocation des ressources est une tâche trop complexe à traiter si l’architecture du système n’est pas déterminée à priori. Nous fixons donc cette architecture en nous basant sur des exemples d’intégration discutés dans la litérature
[57][37][30].
Il apparaît que la majorité des algorithmes de commande machine ne nécessitent pas plus d’un DSP et/ou d’un ASIC. Seules des applications bien
concrètes et complexes comme la commande des moteurs du TGV par exemple
nécessitent des moyens de calcul très supérieurs. Dans des cas comme ceux-là,
il suffit de choisir une architecture adaptée, la méthodologie n’en est pas affectée.
Dans notre cas, nous avons donc décidé d’utiliser une architecture comprenant (cf. Fig. 3.2, p. 73):
–
–
–
–
–
un DSP
un FPGA
une mémoire vive
deux bus (un bus de données et un bus d’adresse)
une horloge globale
L’architecture choisie est localement synchrone à communication asynchrone
c’est à dire signifie que les dispositifs (ASIC, DSP, mémoire) ont un fonctionnement interne strictement synchrone, mais que la communication entre eux est
asynchrone. Ceci implique d’une part que la partie matériel devra être pensée
de façon synchrone, et que le protocole à utiliser sera asynchrone.
La raison d’un asynchronisme global se trouve dans le fait que nous ne maîtrisons pas bien les décalages d’horloge (clock skew en anglais) qui peuvent se
produire sur une carte imprimée en raison de la longueur des pistes. Il est donc
préférable de renoncer à une communication synchrone, bien que plus rapide,
72
F IG . 3.2 – Architecture du système de commande
et utiliser des communications asynchrones, plus lentes mais plus robustes face
à la désynchronisation de l’horloge.
Remarquons que nous ne fixons ici que l’architecture et pas les composants
qui viendraient s’ajouter pour mettre en oeuvre cette architecture (mémoires de
configuration et de programme, matériel de test ...etc.) ou pour la spécialiser
(convertisseurs AD, circuits de mesure ...etc.). Les modèles des composants
principaux (DSP, FPGA, mémoire) sont choisis durant l’étape d’allocation.
3.4 Traitement théorique des problèmes évoqués
Dans la présente section, nous nous attachons à proposer des solutions
théoriques aux problèmes spécifiques à l’intégration des systèmes de commande.
Nous aborderons la modélisation des systèmes, la spécification de certaines
données comme les temps caractéristiques ou la précision de calcul et finalement, nous discuterons du difficile problème de la vérification et de la validation de la conception, concepts que nous avons réuni sous l’expression «test
des modèles».
3.4.1 Modélisation de la commande
La commande telle que nous l’avons définie en 1.3, comporte plusieurs
blocs fonctionnels. En vue de la modélisation du système, il faut déterminer
sa nature (flux statique ou dynamique de données [12], systèmes réactifs déterministes [3] ...etc.) afin de choisir le langage le mieux adapté.
Dans le cas de la commande, nous identifions deux types de blocs:
1. les flux statiques et dynamiques de données (algorithme de contrôle,
MLI, traitement des mesures)
2. les blocs réactifs (surveillance, interface)
73
3.4.2 Spécification des temps de la commande
En 3.2.1.1, p. 67, nous avons cité les temps spécifiques de la commande,
voyons maintenant comment fixer leur valeur.
La période de commutation Cette période est donnée par le concepteur
de l’algorithme de contrôle. Physiquement, la période de commutation est limitée par la fréquence de commutation maximale des interrupteurs de puissance de l’onduleur et par le temps mort. Définir est assez empirique. En
se basant sur les résultats de Montmasson [37], on définira par rapport au
temps mort :
#
Le temps de calcul On peut poser dans un premier temps que doit être inférieur ou égal à . Si on est pas en mesure de respecter cette
contrainte, il faudra revoir soit la valeur de , soit celle de .
La période d’échantillonnage Elle dépend du temps de calcul du système intégré. Si ce temps est inférieur à , on peut choisir .
Sinon, il faut que $ où est un entier.
La fréquence d’horloge La spécification de la fréquence d’horloge n’est
pas vraiment importante. Il suffit de connaître le temps de calcul du système
pour déterminer en cours de développement la période d’horloge. Elle se calcule avec le temps de calcul divisé par le nombre de périodes d’horloge nécessaires au système pour effectuer un cycle de calcul. Pour la partie logiciel, cette
fréquence est d’ailleurs limitée par le modèle de processeur utilisé.
Comme on peut le voir, les temps de la commande dépendent tous plus ou
moins de . Pour une première spécification du système, il suffit donc de
définir pour déduire les autres temps.
3.4.3 Spécification de la précision de calcul de la commande
Pour spécifier la précision de la commande, il faut d’abord spécifier la tolérance admise sur les grandeurs commandées. Si nous prenons le cas du contrôle
du couple, il faut préciser quelle erreur par rapport à la consigne on est prêt à
admettre. Or cette spécification va dépendre de l’application. Pour la traction
d’un train ou d’une voiture, on sera peut-être plus tolérant que pour un robot.
Une fois cette tolérance spécifiée, on veut définir la précision de calcul théorique nécessaire pour rester en dessous du seuil de tolérance. En fait, dans une
chaîne d’entraînement comme celle définie au chapitre 1, ce qui nous importe,
c’est de définir la précision qu’il faut atteindre sur le calcul des instants de commutation de l’onduleur, car c’est d’eux que dépend l’alimentation du moteur
74
et donc la valeur de la grandeur commandée (couple, vitesse ou position). Or,
définir la précision théorique sur ces instants de commutation est extrêmement
difficile pour deux raisons:
1. La première raison est mathématique. Nous ne sommes tout simplement
pas capables aujourd’hui d’établir une relation mathématique simple entre
les instants de commutation et les grandeurs commandées. Tout au plus
pouvons-nous simuler un modèle dégradé de la commande (en limitant
la précision des variables de calcul) avec un modèle de la chaîne d’entraînement pour vérifier que dans quelques cas particuliers, la précision
choisie est suffisante.
2. La deuxième raison est d’ordre physique. Comme nous l’avons déjà dit,
l’onduleur tout comme le moteur d’ailleurs, présente de nombreuses nonlinéarités qui limitent la précision de la commande et que nous ne sommes
pas capable de modéliser simplement. Donc, même si nous assurions une
précision infinie sur la définition des instants de commutation, la grandeur contrôlée n’atteindrait pas la valeur théorique prévue.
Ceci constaté, on s’aperçoit qu’à une précision théorique, on préférera une précision pratique qu’il faudra atteindre. Nous tirons cette précision pratique de
considérations sur les non-linéarités des éléments de la chaîne d’entraînement.
Pour l’onduleur, on examine la fréquence maximale de commutation, les temps
de commutation des composants et le temps mort. Pour le moteur, il faut se
souvenir de la dérive des paramètres.
Si on prend le cas d’un onduleur de puissance moyenne (5 à 20KW) avec
une fréquence de commutation d’environ 20KHz, on peut estimer que la définition des instants de commutation doit être assurée environ à % près.
3.4.4 Le test fonctionnel
Comme nous l’avons déjà vu, il faut répondre à trois questions:
1. Le système exécutera-t-il la fonctionnalité voulue?
2. Existe-t-il un vecteur d’entrée qui puisse mettre le système en défaut?
3. La précision voulue est-elle assurée pour n’importe quel vecteur?
Pour répondre aux deux premières questions, nous avons recours à la vérification et à la validation fonctionnelle. Contrairement aux apparences, ces deux
techniques ne sont pas antinomiques, mais bien, complémentaires. Alors que
la simulation (vérification) permet de s’assurer qu’un comportement souhaité
est atteint pour certains vecteurs de test (p.e. simulation d’un démarrage), la
preuve formelle (validation) permet de montrer que certaines conditions critiques de comportement sont toujours vraies quelques soient les vecteurs d’entrée.
En ce qui concerne la précision, nous proposons en 3.4.4.2, p. 79, une technique permettant de valider cette propriété.
75
3.4.4.1 La vérification fonctionnelle et temporelle
Si la multiplication des modèles dans la méthodologie de conception mixte
permet d’aborder progressivement la conception, elle implique aussi que le
concepteur dispose de moyens de vérification. Selon la nature du modèle envisagé, la vérification recherchée n’est pas la même. Elle peut être fonctionnelle
pour les premiers modèles de spécification, temporelle pour les modèles physiques.
Au total, on peut recenser jusqu’à huit modèles différents:
1.
2.
3.
4.
5.
6.
7.
le modèle de compréhension
le modèle de spécification
le modèle de spécification partitionné
le modèle de spécification affiné
le modèle de la partie matériel
le modèle de la partie logiciel
éventuellement les modèles post-synthèse et post-placement/routage
Voyons pour chacun de ces modèles les techniques de vérification à notre disposition.
Le modèle de compréhension Comme nous l’avons déjà dit dans la formulation de la problématique, le modèle de compréhension est nécessairement
simulé avec le moteur afin de vérifier que les fonctions de régulation et asservissement sont assurées.
Il n’y a pas ici de problème particulier puisque le modèle de compréhension
peut être un modèle mathématique sous forme d’équations qui se couplera
sans problème avec le modèle du moteur.
Les modèles de spécification Avec ces modèles, la tâche est plus complexe.
Pour la vérification, deux solutions s’offrent à nous:
– soit nous simulons les modèles avec le modèle du moteur.
– soit nous comparons nos modèles avec un modèle de référence en effectuant quelques simulations sur des vecteurs de test arbitraires.
Examinons ces deux stratégies.
Simulation avec le modèle du moteur Le modèle du moteur est un modèle analogique, basé sur la résolution d’équations différentielles (cf. annexe B)
alors que les modèles de spécification sont des modèles binaires. Les problèmes
de couplage de simulateurs analogiques avec ceux à évènements discrets sont
nombreux, mais dans le cas de la commande, le problème principal est d’ordre
physique. En effet, un moteur a des constantes de temps de l’ordre de la miliseconde alors que le système intégré, dans le meilleur des cas, est modélisé sur
76
la base de la période d’échantillonnage de l’ordre de la centaine de microsecondes. Dans le pire des cas, le système est modélisé sur la base de la période
d’horloge, de l’ordre la dizaine de nanosecondes. Cette différence énorme des
ordres de grandeur des temps mis en jeu entraîne des simulations extrêmement longues et coûteuses en CPU (de l’ordre de plusieurs dizaines d’heures
pour quelques secondes simulées).
Il n’est donc pas envisageable d’utiliser ce type de vérification de façon
systématique.
La comparaison de modèles Cette technique consiste à comparer différents modèles à un modèle de référence sur la base de simulations de vecteurs
de test arbitraires. Le modèles de référence ayant été validé auparavant, il permet de calculer les résultats qui devront être obtenus avec le modèle à vérifier.
Cette méthode présente deux avantages:
1. le choix des vecteurs de test est arbitraire. Dans le cas de la simulation
avec un modèle du moteur, il fallait nous placer dans un cas réel pour
pouvoir vérifier la cohérence de l’évolution des grandeurs contrôlées, et
par implication la cohérence des calculs du modèle.
Dans le cas de la comparaison, il n’est plus nécessaire de vérifier la cohérence des calculs, mais seulement de vérifier qu’un calcul est juste ou
non. La réalité du cas calculé n’importe pas. Un quelconque vecteur de
test fait l’affaire.
2. la réduction du temps de vérification est énorme. La simulation mixte
analogique/numérique n’étant plus nécessaire, les simulations numériques
seules sont beaucoup plus rapides. De plus, on ne calcule que quelques
vecteurs. N’oublions pas qu’il ne s’agit que d’une vérification, pas d’une
validation.
Toutefois, cette technique n’est pas sans problème dans le cas de la commande.
En effet, quel modèle faut-il choisir comme modèle de référence?
A priori, on serait tenté d’utiliser le modèle de compréhension puisque c’est
le premier développé, mais celui-ci crée une difficulté majeure. En principe, la
compréhension s’effectue sur un modèle mathématique simulé en virgule flottante, éventuellement en virgule fixe. Mais de toute façon, le modèle de compréhension décrit uniquement les fonctions mathématiques à calculer, certainement pas les opérations binaires qui vont effectivement avoir lieu pour calculer
ces fonctions. Du coup, les résultats des calculs peuvent être très différents de
ceux que calculera le circuit numérique en raison de la précision binaire. Comparer le modèle de compréhension avec les modèles de spécification n’a pas de
sens, les résultats seront nécessairement différents.
Pour pouvoir comparer des modèles, il faut qu’ils soient équivalents en
terme de précision binaire. Or cette équivalence n’est assurée qu’à partir du
moment où le séquencement et la nature des opération arithmétiques binaires
ne sont plus modifiées, ce qui n’est vrai qu’après le partitionnement et le séquencement du système.
77
On ne pourra donc utiliser cette technique qu’à partir du moment où le
modèle de spécification partitionné aura été validé pour servir de modèle de
référence.
Les modèles physiques haut niveau Théoriquement, la génération des modèles physiques, matériel et logiciel est automatique si bien qu’il ne devrait pas
apparaître de différence fonctionnelle avec les modèles précédents.
Cependant, il n’est pas rare qu’un concepteur retouche les codes générés
pour optimiser la synthèse ou la compilation. On peut également vouloir s’assurer que la synthèse de code s’est effectuée correctement.
Dans ce cas, la stratégie de vérification qui nous apparaît la plus appropriée
est la comparaison de modèles avec le modèle de spécification partitionné.
Jusqu’ici, nous n’avons parlé que de vérification fonctionnelle ce qui excluait toute vérification temporelle du modèle. On a pu vérifier que le séquencement était correct, mais le temps n’intervenait que dans la mesure où on affirme arbitrairement que la fréquence d’échantillonnage est respectée pour les
besoins de la simulation avec la chaîne d’entraînement.
Que le modèle soit vérifié fonctionnellement ne signifie donc pas qu’il le
soit temporellement. On peut par exemple vouloir vérifier que l’acquisition
des mesures s’effectue au bon moment, que le temps de calcul n’excède pas
la période d’échantillonnage ...etc. Une vérification temporelle est nécessairement liée à la notion de modèle physique du circuit et donc aussi à la période
d’horloge. Au moment de la génération des modèles physiques, on ne connaît
pas exactement la période d’horloge; on n’en a que des estimations qu’on doit
affiner par une estimation post-synthèse.
La vérification temporelle ne nécessite pas la simulation mixte avec la chaîne
d’entraînement, mais seulement la simulation de quelques vecteurs critiques
pour s’assurer que les contraintes temporelles fixées par l’environnement du
système sont respectées.
Les modèles physiques post-placement/routage Nous estimons que l’équivalence fonctionnelle est maintenue lors des tâches de synthèse et de placement/routage. Les vérifications effectuées sur les modèles post-placement/routage
sont plutôt d’ordre analogique (p.e. respect des contraintes de fan-in et fanout).
Nous exceptons toutefois la vérification temporelle. Le routage introduit
des retards supplémentaires qui peuvent fausser jusqu’à 100% les estimations
post-synthèse logique (pre-layout). Il est donc souhaitable d’estimer la fréquence d’horloge après le placement/routage pour reinjecter cette valeur dans
les simulations temporelles sur les modèles physiques.
3.4.4.2 La validation fonctionnelle
La validation fonctionnelle doit nous permettre d’apporter la preuve que
le circuit respecte un certain nombre de propriétés critiques. Ces propriétés
78
peuvent être spécifiques à l’application (p.e. «si la tension d’alimentation devient inférieure à , alors la commande arrête le moteur»), ou au contraire
d’ordre général (p.e. vérifier qu’il n’y a pas de blocage logique possible).
Remarquons que les techniques de preuve formelle permettent uniquement
de dire si une propriété est vraie ou non pour un circuit donné. La difficulté
réside dans le fait de définir des propriétés cohérentes.
Nous ne voulons pas ici examiner l’ensemble des techniques de preuve formelle qui existent, mais seulement nous pencher sur les problèmes spécifiques
à la commande.
Comme nous l’avons déjà expliqué, la commande peut se composer de plusieurs blocs fonctionnels. Ces blocs reposent sur des modèles de comportement
différents pour lesquels les techniques de preuve formelle diffèrent.
Les techniques automatisées de preuve formelle concernent les machines
d’état. Le principe est de rechercher les séquences défaillantes pour une propriété donnée. Par contre, nous ne connaissons pas à l’heure actuelle d’outils ou
de méthode pour la preuve formelle de propriétés mathématiques du système.
Or au niveau de la commande, nous voulons valider deux types de propriétés:
1. les propriétés logiques sur le fonctionnement des machines d’état (protocoles, fonctions logiques de surveillance, séquencement d’opérations
...etc.).
2. des propriétés arithmétiques sur l’exécution des opérations (dépassement
de capacité, précision binaire).
Pour valider la commande, nous allons devoir extraire d’une part les machines
d’état de la commande, et d’autre part, le séquencement des opérations avec le
chemin de données associé.
Le deuxième point important de cette technique de validation est l’emploi
d’une stratégie «diviser pour mieux conquérir». Cette stratégie consiste à valider hiérarchiquement le système au lieu de tout mettre à plat. L’avantage
évident est la limitation de la complexité du problème, et donc une limitation
des ressources CPU nécessaires.
Examinons maintenant pour chaque type de propriété les techniques employées.
Les propriétés logiques Pour la validation de ces propriétés, on a recourt aux
techniques de preuve formelle «classiques»: à partir des propriétés à vérifier et
d’un modèle formel de la machine d’état, l’outil de preuve formelle détermine
si la description satisfait les propriétés données. Si ce n’est pas le cas, l’outil
génère la séquence d’état et les entrées associées qui provoquent l’erreur.
Les propriétés arithmétiques Classiquement, la vérification de propriétés arithmétiques du modèle n’est pas couverte par les techniques de preuve formelle.
Nous proposons ici une technique qui doit nous permettre de vérifier deux
propriétés importantes du système de commande: le dépassement de capacité
binaire et la précision de calcul.
79
Malheureusement, on remarque que ces propriétés dépendent à la fois de
données statiques intrinsèques à la commande (constantes, format binaire, nature des opérations) et des données dynamiques (opérandes, éventuellement
séquencement dynamique), ce qui complique énormément la validation.
Prenons le cas d’un filtre du premier ordre numérique. Son équation discrète est donnée par:
&
' & ' &
' avec et deux constantes du filtre.
Une telle équation récursive est problématique pour les validations mathématiques que nous nous proposons de faire puisque la précision varie selon le
nombre d’itérations.
Pour surmonter la difficulté, nous employons là encore la stratégie de «diviser
pour mieux conquérir». La commande algorithmique se compose généralement d’un assemblage de fonctions facilement identifiables telles que des filtres
numériques, des régulateurs, des multiplications matricielles, des rotations ...etc.
Pour chacune de ces fonctions prises séparément, on cherche à définir des intervalles de variation des variables binaires d’entrée et la précision atteinte pour
un format binaire donné. Pour obtenir l’intervalle de variation des variables
d’entrée de la commande, il suffit de chaîner les fonctions selon la (ou les) séquence(s) définie(s) par la machine d’état (extraite du modèle flot de données
de la commande algorithmique) et rechercher la fonction critique qui limite les
variables d’entrées.
En ce qui concerne la précision de calcul, on effectue de même, mais cette
fois-ci en ajoutant l’imprécision générée par chaque fonction de la séquence.
En répétant l’opération pour chaque séquence, on détermine le cas le plus défavorable.
Cette méthode, applicable pour des cas simples, n’est actuellement pas gérable dans des cas complexes. Une des causes est l’augmentation du nombre
de séquences, problème qui pourrait se résoudre par l’automatisation de la
méthode. Mais la difficulté principale réside dans le fait que plus la fonction
étudiée est complexe, et plus le nombre de variables et d’opérations intervenant dans la précision du résultat final croît. La relation entre les opérandes
et la précision (lorsqu’elle existe) devient rapidement trop complexe pour être
déterminée (cf. pour exemple l’étude de la précision du CORDIC, p. 190). Reste
alors le recourt à la simulation qui n’apporte pas de preuve formelle.
3.5 Méthodologie d’intégration de la commande
En premier lieu, nous commençons par présenter les langages de modélisation utilisés, puis les outils de conception associés. Nous finissons par le flux de
conception qui représente le canevas sur lequel nous avons calqué l’exemple
d’application (cf. chapitre 5).
80
3.5.1 les langages de modélisation
Dans la méthode de conception mixte, nous avons répertorié six modèles
successifs de conception. Pour associer à chaque modèle un langage de conception correspondant, nous nous basons sur la nature de la fonction modélisée et
non sur la nature du modèle. En effet, un même langage peut servir à modéliser un système à différents niveaux d’abstraction. Un cas typique est VHDL
(ou Verilog). On peut modéliser un système fonctionnellement (en arithmétique réelle ou binaire), on peut affiner de tels modèles et finalement, on peut
modéliser le système structurellement et même temporellement toujours avec
le même langage. On voit qu’un même langage (VHDL en l’occurence) peut
servir pour les huit modèles de la méthodologie de conception mixte.
Nous considérons néanmoins qu’une telle approche n’est pas optimale. En
effet, chaque langage de conception a été conçu dans un but précis et son utilisation à d’autres fins se révèle souvent complexe et peu efficace. VHDL est bien
adapté à la description matérielle de systèmes électroniques digitaux. Son utilisation pour la modélisation fonctionnelle de systèmes en arithmétique réelle
ou pour la description de logiciel s’avère ardue et peu efficace.
Nous opinons que pour la modélisation de systèmes hétérogènes complexes,
l’utilisation de plusieurs langages spécialisés, adaptés à la nature de la fonction
modélisée, est préférable à la modélisation globale par un seul et même langage
tout au long de la conception. Ceci implique bien sûr qu’un effort particulier
doit être consacré aux interfaces entre langages et que par conséquent, une normalisation des protocoles d’échange de données serait fortement souhaitable.
Examinons maintenant pour chaque niveau d’abstraction, le (ou les) langage de modélisation employé.
3.5.1.1 Le modèle de compréhension
A ce niveau de la conception, nous nous trouvons à une étape charnière du
processus global de développement du système, entre la conception de l’algorithmie de commande et des fonctions logiques, et l’intégration sous forme de
système. Il est peu probable qu’une seule et même personne s’occupe de l’ensemble de la conception. Plus vraisemblable est le cas où le développement est
distribué entre des spécialistes de la commande et de l’électrotechnique, et des
concepteurs de systèmes intégrés. Il faut donc trouver une forme de représentation simple permettant de transmettre les informations d’un domaine vers
l’autre.
Pour décrire complètement la commande, nous devons représenter trois
types de fonctions:
– L’algorithme de contrôle se représente clairement sous forme de schéma
bloc (cf. Fig. B.10, p. 173). Cette représentation présente l’intérêt d’être
couramment utilisée en électrotechnique par les simulateurs analogiques,
ce qui facilite la cosimulation avec le modèle du moteur.
– Les protocoles se représentent le mieux par un diagramme des signaux
associé à un graphe type réseau de Pétri ou Grafcet.
81
– Pour les fonctions logiques, nous avons choisi d’utiliser le Grafcet en raison de sa simplicité d’emploi et de son adéquation à la modélisation
de systèmes digitaux. Nous reviendrons au chapitre 4 sur ce langage
graphique et sur l’intérêt qu’il présente dans le cadre d’une conception
mixte.
3.5.1.2 Les modèles de spécification
Pour l’ensemble des trois modèles de spécification (fonctionnel, partitionné
et spécification affinée), ainsi que pour les deux types de fonctions à représenter (flux de données et blocs réactifs), nous avons décidé d’utiliser le Grafcet.
Plusieurs raisons ont orienté ce choix:
– Le Grafcet est bien adapté à la modélisation des flux dynamiques de données, et donc, aux algorithmes de commande dont la structure fortement
séquentielle et dynamique exige aussi d’importantes ressources de calcul
– lorsque les fonctions réactives de la commande sont réduites, ce qui est
souvent le cas des systèmes de commande, le Grafcet peut être utilisé en
tant que modèle de machine d’état. Si la complexité de ces fonctions augmente, il est préférable d’utiliser des langages appropriés comme Esterel.
– Finalement, le Grafcet permet une conception hiérarchique ce qui est très
appréciable pour des systèmes de commande souvent très complexes et
ce qui facilite le processus d’affinement des modèles.
Malheureusement, il n’existe pas actuellement d’outil permettant de simuler
un modèle Grafcet tel que nous l’interprétons (cf. 4.2.2). Nous avons donc dû
traduire le modèle Grafcet des fonctions algorithmiques vers un langage simulable, en l’occurence le script de MATLAB.
Rappelons que les modèles de spécification sont des modèles fonctionnels
qui ne décrivent pas l’architecture du système, information qui relève du modèle physique. Par conséquent, le modèle MATLAB décrit des opérations binaires qu’effectuera le système ainsi que leur séquencement.
3.5.1.3 Les modèles physiques
Les modèles physiques représentent la dernière étape avant la réalisation
physique du système (layout et code objet). Ils décrivent le système au niveau
de son exécution temporelle. Les langages à utiliser doivent pouvoir modéliser
facilement le type de dispositif employé.
Nous avons donc choisi VHDL pour la modélisation du matériel et l’assembleur (ou le code C lorsque le compilateur est disponible) pour le logiciel.
Nous avons préféré VHDL à Verilog (HDL développé par Cadence) car
VHDL étant une norme (standart ANSI/IEEE 1076-1993), les modèles sont portables en simulation. C’est à dire qu’ils sont simulables sur tout simulateur respectant la norme, ce qui est le cas pour la plupart d’entre eux.
82
3.5.1.4 Les outils de conception
Comme nous l’avons vu au paragraphe précédent, le choix des langages
de conception s’est basé en partie sur les caractéristiques intrinsèques des langages, mais aussi sur la disponibilité et les caractéristiques des outils de conception associés. C’est notamment le cas de MATLAB qui occupe une place à part
dans les choix qui ont été faits. En effet, MATLAB n’est pas un outil de développement microélectronique même s’il comprend l’utilitaire DSPACE permettant de générer du code C, compilable sur des DSP commerciaux, à partir d’un
schéma bloc.
Le choix de cet outil est lié à l’étape de compréhension de l’algorithme et à
la vérification fonctionnelle du système. Nous détaillerons ces points en 3.5.2,
p. 83, mais ajoutons que l’intérêt principal de MATLAB réside dans le fait qu’il
nous permet de simuler conjointement un modèle binaire du système (modèle
de spécification) avec un modèle analogique du moteur (sous forme de schéma
bloc). De ce fait, nous pouvons simuler le système dans son environnement
analogique et vérifier ainsi que le fonctionnement est correct.
Le modèle MATLAB du système se présente sous forme de fonctions écrites
en langage interprété de MATLAB, un langage similaire au C. La simulation
mixte analogique/numérique s’effectue sous l’environnement SIMULINK de
MATLAB qui permet de modéliser les fonctions de transfert des systèmes analogiques par des schémas blocs.
En ce qui concerne la simulation des modèles VHDL et leur synthèse, nous
avons utilisé SYNOPSYS. Cet outil s’est imposé dans la plupart des entreprises
développant des ASIC et est reconnu pour la qualité de sa synthèse. Les simulateurs de SYNOPSYS supportent l’ensemble de la norme VHDL-93 et offrent
un environnement de déboggage puissant.
Le choix de la technologie de prototypage s’étant porté sur Altera, nous
avons utilisé également l’outil de compilation et placement/routage Maxplus2.
Précédemment, des tests de prototypage avec des technologies semi-custom
nous ont amené à utiliser également les outils de CADENCE pour le placement/routage. Mais les technologies FPGA présentant plus d’intérêt pour le
prototypage et assurant des fréquences de calcul suffisantes, nous n’avons pas
poursuivi les travaux avec CADENCE.
3.5.2 Le flux de conception
Le flux de conception a été représenté figure 3.4, p. 87. Comme on peut le
constater, cette méthodologie ne diffère pas fondamentalement de celle présentée au chapitre 2. On retrouve les étapes génériques d’une conception mixte,
mais avec en sus des opérations spécifiques à la commande.
La spécification système: Le système est d’abord spécifié fonctionnellement
avec le Grafcet, puis le modèle est traduit en script MATLAB pour permettre une simulation fonctionnelle du système. La simulation du script
se base de fait sur l’hypothèse de synchronisme fort.
83
La simulation fonctionnelle: La cosimulation du modèle binaire du système
et du modèle analogique de la chaîne d’entraînement est effectuée avec
l’utilitaire SIMULINK. Afin de coupler la simulation du modèle analogique, nécessairement dépendant du temps, avec le script MATLAB, nous
invoquons le script à chaque période d’échantillonnage, puis nous appliquons le résultat à la période suivante. Une fonction fait office d’interface
en générant des signaux MLI dépendant de la fréquence d’horloge. L’évaluation du modèle de la chaîne d’entraînement est quant à elle gérée par
la méthode de résolution numérique (méthode de Gear) qui utilise un
pas variable. Malheureusement, en raison de la définition des signaux
MLI avec une résolution égale à la période d’horloge, le pas utilisé pour
évaluer le modèle analogique est ramené au maximum à la période d’horloge. De ce fait, le rapport entre la constante de temps du moteur et le pas
de calcul de la simulation est le plus défavorable (de l’ordre de ). Pour
améliorer ce rapport, il faudrait évaluer la fonction d’interface avec un
pas variable. La figure 3.3, p. 84, représente le banc de simulation sous
MATLAB.
F IG . 3.3 – cosimulation sous MATLAB
Partionnement/estimation: Le partitionnement et l’estimation de performances
sont effectués manuellement en utilisant les techniques proposée en 4.3.1.
L’estimation de performances étant très peu précise, nous utilisons les
estimations obtenues après synthèse ou assemblage pour affiner le partitionnement.
Affinement des modèles: La technique retenue ici est l’emploi d’IP 2 réutilisables. Ces blocs, en partie configurables grâce à l’emploi de paramètres
génériques, réalisent des fonctions standarts utilisables dans différents
projets de conception (ALU, protocoles, gestion des mémoires, gestion
84
des CAN ...etc.). Durant ce projet, nous avons développé plusieurs IP
réalisant des fonctions standarts utilisables pour intégrer des systèmes
de commande (ALU spécifique, processeur mathématique adapté, gestion de CAN ...etc.).
A travers le modèle Grafcet, nous pouvons faire appel à ces IP et affiner
ainsi la spécification du système.
2. Intelectual Property
85
Synthèse de code matériel et logiciel: A partir du modèle Grafcet, nous générons les codes de description haut niveau manuellement en nous basant
sur des règles que nous évoquons en 4.3.2. Grâce à l’utilisation d’IP et
au séquencement statique des opérations, la génération de code peut se
réduire essentiellement à une machine d’état.
Test des propriétés mathématiques: Le test des propriétés citées en 3.4.4.2, p. 79,
s’effectue actuellement d’abord à la main puis par simulation fonctionnelle. Pour la simulation, nous utilisons le banc en simulation sous MATLAB. Le modèle MATLAB du système étant paramétré, on peut faire varier la longueur des mots binaires utilisés et vérifier ainsi les propriétés
de précision et d’overflow.
Test logique: Pour le test formel, nous nous contentons actuellement de vérifier quelques propriétés critiques par des simulations des modèles VHDL
avec des vecteurs d’entrée appropriés. Nous n’effectuons pas de validation formelle en raison de la complexité de la tâche et du manque d’outils
appropriés.
Synthèse des modèles physiques: A partir de la description VHDL, on génère le modèle physique de la partie matériel par synthèse avec Synopsys. Le modèle généré est un schéma de portes logiques décrit par une
netlist en VHDL, EDIF ou Verilog. Le code C, lorsqu’il est généré au lieu
de l’assembleur, est compilé par un compilateur spécifique au DSP.
Émulation: L’émulation des systèmes de commande est effectuée sur des cartes
de prototypage spécifiques. L’une des cartes comprend un FPGA avec les
circuits d’acquisition de mesures. L’autre reprend l’architecture décrite en
3.3.2, p. 72, c’est à dire un DSP, un FPGA, des mémoires vives, des bus,
les circuits d’acquisition des mesures et la logique de programmation des
dispositifs. Cette dernière carte est encore en phase de test.
Le tableau 3.1, p. 88, synthétise les outils et langages associés à chaque étape
de la conception. La méthodologie apparaît actuellement essentiellement manuelle, mais, vue l’aspect systématique des tâches à réaliser, une automatisation presque totale est envisageable.
3.6 Conclusion
La méthodologie de conception mixte étant trop complexe à appliquer dans
le cas général, nous avons proposé une méthode spécifique à l’intégration des
systèmes de commande.
Après avoir formalisé les problèmes spécifiques à l’intégration de la commande, et situé leur traitement dans la méthodologie, nous avons proposé des
solutions théoriques pour les résoudre. Nous avons également défini des restrictions au champ d’application de la méthode afin de limiter la complexité
des problèmes traités. Nous définissons en particulier l’architecture des systèmes de commande que nous utilisons.
86
F IG . 3.4 – Flux de conception d’un système de commande
87
TAB . 3.1 – Synthèse des outils et langages associés à la méthodologie
88
Test des propriétés mathématiques
Test logique
Émulation
Placement / routage
Assemblage
Simulation fonctionnelle
Tâches
Spécification
modèle de compréhension
modèle de spécification
Partitionnement / Estimation
Affinement du modèle
Synthèse de code matériel/logiciel
Synthèse des modèles physiques
MATLAB
Grafcet, diagramme de signaux
Grafcet
Grafcet
VHDL/assembleur
synthèse de VHDL vers EDIF,
VHDL ou Verilog
EDIF/Verilog
assembleur
MATLAB, schéma bloc SIMULINK
MATLAB
VHDL/Grafcet
Modèles
manuel, simulation MATLAB
manuel, simulation SYNOPSYS
carte spécifique
Altera, Cadence
spécifique au processeur
SIMULINK
manuel
manuel
manuel
SYNOPSYS
Outils
Les solutions théoriques étant définies, nous avons décrit les solutions pratiques mises en oeuvre ainsi que les outils et langages utilisés. La méthodologie
spécifique à l’intégration des systèmes de commande a été finalement proposée
de même que des perspectives pour l’automatisation de la méthode.
89
90
Chapitre 4
Implantation de la
méthodologie:
Solution à base de Grafcet
4.1 Introduction
Le chapitre suivant est consacré à l’utilisation du Grafcet pour la conception
de systèmes intégrés.
Le Grafcet n’est pas prévu pour cet usage, mais il présente des caractéristiques intéressantes qui nous ont amené à le choisir. Afin de l’utiliser, nous proposons donc une nouvelle interprétation du Grafcet et faisons quelques ajouts
à la sémantique en vigueur. Nous présentons ce travail de réflexion sur le Grafcet en trois parties.
En premier lieu, nous abordons la modélisation par Grafcet, c’est à dire
la sémantique (graphique et textuelle) à utiliser pour la modélisation des systèmes de commande et les règles et hypothèses de fonctionnement des modèles.
Puis nous proposons des techniques et des règles pour l’analyse des modèles en vue de l’intégration. Nous montrons en particulier comment analyser
les implications matérielles d’un graphe donné (architecture, performances) et
comment estimer les performances à partir du modèle.
Finalement, nous abordons la synthèse de code de description du système
à partir du Grafcet et notamment la synthèse de VHDL.
91
4.2 Le Grafcet comme modèle en vue de l’intégration
En 1966, Pétri et Holt proposent un nouvel outil, appelé «réseaux de PETRI», s’avérant particulièrement puissant pour la modélisation de systèmes.
D’abord utilisé par les informaticiens, il a été rapidement repris par les automaticiens. Depuis, cet outil est également utilisé en microélectronique où il
sert entre-autre à la modélisation de circuits asynchrones [24] et à la preuve
formelle.
En 1977, le groupe de travail «systèmes logiques» de l’AFCET 1 met au point
le Grafcet 2 , outil dérivé des réseaux de Pétri. Moins puissant, surtout en ce qui
concerne l’analysabilité, il est par contre extrêmement simple, ce qui lui a valu
son succès. Depuis, ce modèle a été normalisé au plan français (norme NF CO3
190) et international (norme CEI 848).
Par la suite, nous faisons appel à des notions sur les réseaux de Pétri pour
définir le Grafcet. Pour plus de renseignements, le lecteur pourra se reporter
aux ouvrages spécialisés [28][9][48].
En dehors des aspects purement mathématiques de la modélisation des systèmes physiques, l’utilisation, pour la description du modèle, de langages textuels ou graphiques relève souvent du goût personnel et des habitudes. Il est
toutefois indéniable que les langages textuels génèrent souvent des descriptions plus simples lorsque le système décrit est essentiellement dédié au traitement numérique de données (data-intensive en anglais). Par contre, une description visuelle est généralement plus efficace et plus facile à comprendre lorsque
le système modélisé est dédié au contrôle d’opérations (control-intensive en anglais). Avec le Grafcet, nous avons voulu concilier un langage graphique avec
une description textuelle afin de modéliser des systèmes de commande qui
sont à la fois dédiés au traitement numérique et au contrôle des données d’entrée. Pour cela, nous avons repris le formalisme graphique du Grafcet tel qu’il
est précisé dans la norme, et nous nous sommes inspirés du VHDL pour décrire
textuellement les actions associées au graphe. De cette manière, nous obtenons
des modèles simples à concevoir, faciles à comprendre en vue de la documentation de la conception, et suffisamment puissants pour modéliser des systèmes
digitaux au niveau fonctionnel.
Toutefois, afin que le Grafcet soit réellement utile et ne se limite pas à un formalisme graphique pour la spécification des systèmes, il faut définir des règles
mathématiques de fonctionnement du modèle. Pour cela, nous commençons
par décrire les caractéristiques principales du Grafcet tel qu’il est défini par la
norme, tout en indiquant les différences avec les réseaux de Pétri et les conséquences que cela entraîne sur la modélisation.
Mais, ainsi défini, on verra que le Grafcet pose des problèmes d’interprétation pour la description de systèmes microélectroniques, problèmes que nous
traitons au paragraphe 4.2.2, p. 94.
1. Association Française pour la Cybernétique Economique et Technique
2. Graphe Fonctionnel de Commande Etape Transition
92
Finalement, pour assurer une modélisation sans ambiguïté et éviter des erreurs de conception, nous proposons quelques restrictions à la norme.
4.2.1 Rappel des principales caractéristiques du Grafcet
Bien que proche des réseaux de Pétri, le Grafcet en diffère sur un certain
nombre de points:
– Le Grafcet est un graphe constitué d’Étapes, représentées par des rectangles, et de Transitions.
– A chaque Étape sont associées une ou plusieurs actions.
– A chaque Transition est associée une condition d’évolution appelée Réceptivité.
– Un Grafcet évolue par Activation des Étapes. Contrairement aux réseaux
de Pétri, la notion de marqueur n’existe pas et donc «l’indivisibilité et l’infusionabilité» des marqueurs non plus, ni d’ailleurs la notion de conflit.
Si la modélisation s’en trouve simplifiée, des imprécisions apparaissent
sur la représentation du «ET» et du «OU exclusif» qui peuvent être identiques.
Considérons par exemple le cas des figures 4.1 (a) et 4.1 (b), p. 93, où nous
modélisons le même système par un réseau de Pétri et par un Grafcet.
(a) réseau de Pétri
(b) Grafcet
F IG . 4.1 – Modélisation d’un branchement OU par réseau de Pétri et par Grafcet
Sur ces figures, et sont des transitions auxquelles sont associées respectivement les conditions (ou réceptivités) et . Supposons que les
deux conditions soient réalisées en même temps. Un conflit apparaît alors
pour le réseau de Pétri. Par contre, ce conflit est inexistant au niveau du
Grafcet. Les transitions sont franchies simultanément, activant les étapes
2 et 3 et désactivant l’étape 1. Dans cette situation, ce Grafcet modélise le
comportement logique d’un «ET».
Par contre, si une seule condition se réalise, une seule transition est franchie, activant l’étape suivant. Dans cette situation, le Grafcet modélise
93
un «OU». On voit donc qu’il peut y avoir un problème de représentation avec le Grafcet. En tout état de cause, on peut dire que la fonction
modélisée ici est un «OU inclusif».
– Avec la disparition de la notion de marquage disparait également la notion de bornage: si on réactive une étape déjà active, elle restera active.
– Contrairement aux réseaux de Pétri, le Grafcet permet de définir une réceptivité associée à une transition en faisant appel explicitement à l’état
d’activation (ou non) d’une étape d’un Grafcet. Cette propriété permet
souvent de simplifier les machines d’état, notamment pour la modélisation des communications entre elles.
– Le Grafcet envisage la hiérarchisation de la conception grâce aux notions
de sous-programme et de macro-étape. Ces deux notions permettent de
représenter l’appel à des sous-graphes par des étapes spécifiques. Dans
le cas des macro-étapes, l’appel au sous-graphe s’effectue une seule fois
lors de l’activation de la macro-étape. Dans le cas du sous-programme, le
sous-graphe est exécuté chaque fois que le sous-programme est activé.
4.2.2 Interprétation du Grafcet
Le but de notre utilisation du Grafcet est de modéliser des systèmes digitaux réalisés sous forme matériel, logiciel ou mixte. Toutefois, nous ne considérerons ici que la modélisation de systèmes strictement synchrones. La conception de systèmes asynchrones posant trop de problèmes non résolus (métastabilité, test fonctionnel des modèles, test physique ...etc.), nous ne l’envisageons
pas actuellement.
Pour l’interprétation du Grafcet, nous considérons deux points qui sont restés relativement imprécis jusqu’à présent:
1. la nature des actions associées à une étape
2. les règles de fonctionnement
Pour chacun de ces points, nous examinons maintenant ce que précise la norme
et comment l’adapter au cas de la modélisation de systèmes digitaux synchrones.
4.2.2.1 La nature des actions associées à une étape
Le Grafcet étant défini à l’origine pour les automatismes industriels, la norme
définit la structure du système modélisé comme étant composée d’une partie opérative (le processus) commandée par une partie commande (l’automatisme). Des ordres sont émis par l’automatisme vers le processus et celui-ci renvoie des compte-rendus. Selon la norme, les actions associées aux étapes sont les
ordres émis par l’automatisme, c’est à dire en fait des signaux booléens.
Notre objectif est de modéliser par le Grafcet des systèmes digitaux au niveau fonctionnel. En d’autres termes, nous voulons représenter:
1. les opérations (arithmétiques ou logiques) effectuées par le système
94
2. le séquencement de ces opérations
Ceci étant posé, on définit les actions associées à une étape comme les opérations logiques ou arithmétiques effectuées par le système. On remarquera
qu’une opération logique peut se réduire à une affectation de signal logique.
Notre définition des actions associées à une étape est une généralisation du
concept d’action, mais qui permet encore de modéliser directement un automate intégré sur silicium ou une machine d’état commandant un chemin de
données.
En définissant le type d’actions exécutées à l’activation d’une étape, nous
devons également définir les objets sur lesquel opèrent ces actions. A ce niveau, nous sommes obligés de faire une digression momentanée pour parler
des notions de concurrence, de signal, et de variable tels qu’elles sont définies
par VHDL.
Afin de modéliser l’évolution temporelle des circuits intégrés, VHDL définit des objets qui sont créés au début de la simulation et qui ne sont détruits
qu’à la fin. Les signaux sont un exemple de ces objets. Un signal peut prendre
des valeurs de type arbitraire, mais à chaque instant de la simulation, il prend
une valeur donnée. Cette notion de permanence des objets est liée à la notion
de concurrence des évènements, c’est à dire des évènements qui se produisent
en même temps. L’affectation de signaux est un exemple d’opération concurrente (lorsqu’elle n’est pas effectuée dans un bloc d’instructions séquentielles),
c’est à dire que des signaux différents peuvent changer de valeur au même instant.
A cette notion de concurrence répond la notion de séquentialité, c’est à dire
l’exécution d’instructions selon un séquencement défini. Ces instructions séquentielles sont regroupées dans des «block» ou des «process» qui sont eux des
objets concurrents. A l’intérieur des processus, il est possible de définir des
variables qui sont des objets purement séquentiels et dont la valeur n’est pas
liée à la notion de temps. Pour plus de détails, le lecteur pourra se reporter à
l’ouvrage de Aireau et al [46] sur la modélisation avec VHDL.
Pour en revenir à notre problème, nous avons décidé de reprendre les concepts
proposés par VHDL pour définir les objets avec lesquels nous travaillons en
Grafcet:
– un graphe est un objet concurrent
– nous appliquons les actions sur des signaux et variables
– les réceptivités peuvent utiliser des variables et des signaux
– les signaux sont visibles de plusieurs graphes concurrents
– l’affectation d’un signal est effectuée par un seul graphe
– les variables ne sont visibles que dans leur propre graphe et elles prennent
leur valeur immédiatement
95
4.2.2.2 Les règles de fonctionnement
Pour définir le séquencement des opérations fonctionnelles, il faut fixer les
règles d’évolution du Grafcet. La norme précise cinq règles de base:
Situation initiale: Au début du fonctionnement du graphe, un certain nombre
d’étapes doivent être actives. Cette ou ces étapes initiales sont représentées par un double carré.
Franchissement d’une étape: Une transition entre étapes est dite «validée» si
toutes ses étapes d’entrée sont actives. Elle sera franchie si elle est validée
et si la réceptivité qui lui est associée est vraie. Le franchissement est alors
immédiat et obligatoire.
Évolution des étapes actives: Le franchissement d’une transition entraîne l’activation de toutes les étapes immédiatement suivantes et la désactivation
de toutes les étapes immédiatement précédentes.
Évolutions simultanées: Plusieurs transitions simultanément franchissables sont
simultanément franchies.
Activation et désactivation simultanées: Si au cours du fonctionnement, une
même étape doit être à la fois activée et désactivée, elle reste active.
A partir de ces règles, il est possible de faire évoluer un modèle Grafcet, mais il
faut examiner également s’il est possible de modéliser sans ambiguïté le fonctionnement d’un système synchrone.
Le formalisme du Grafcet permet de définir une réceptivité en incluant la
scrutation d’un changement d’état d’un signal, ce qui autorise la synchronisation de l’exécution du graphe avec un signal d’horloge. En figure 4.2, p. 97,
nous proposons un exemple de système digital, le modèle Grafcet correspondant et le diagramme des signaux. Cet exemple montre qu’il est possible de
modéliser un système synchrone en se basant uniquement sur les règles d’évolution du Grafcet édictées par la norme. Mais en fait, ce formalisme est très
lourd à porter et surtout très complexe à interpréter. En faisant intervenir le
temps, la lecture du Grafcet devient imprécise. Dans notre exemple, comment
doit-on interpréter le chargement du registre: se charge-t-il lors de l’activation
de l’étape 2, lors du franchissement de la transition ou à l’activation de l’étape
3? Si on se réfère au diagramme 4.2-c, les trois hypothèses peuvent se justifier.
Ce genre de problèmes d’interprétation peut être évité si on adopte l’hypothèse de synchronisme fort proposée avec les langages synchrones type Esterel
[3]. Cette hypothèse suppose que les opérations du modèle s’effectuent instantanément à moins que leur durée ne soit précisée explicitement. En adoptant cette hypothèse, on est amené à considérer le temps comme une séquence
d’évènements discrets entre lesquels rien d’intéressant ne peut arriver.
Pour en revenir au Grafcet, cela signifie que les actions d’une étape valide
sont exécutées au moment où on évalue la réceptivité de la transition de sortie.
Quant aux réceptivités associées aux transitions de sortie d’étapes valides, elles
sont évaluées chaque fois qu’un signal du graphe est activé, c’est à dire qu’une
transition se produit sur ce signal. On remarquera qu’une transition n’a pas
96
(a) Système à modéliser
(b) Modèle Grafcet
(c) Diagramme des signaux
F IG . 4.2 – Exemple de modélisation par Grafcet
97
besoin d’être franchie pour que des actions soient exécutées. L’exemple de la
figure 4.3 illustre ce propos.
Les étapes 2 et 3 sont validées lorsque
la transition est franchie. L’action
associée à l’étape 2 est alors exécutée
deux fois: une fois à l’évaluation de
et , puis une fois à l’évaluation
de et .
L’hypothèse de synchronisme assure aussi la notion de concurrence
puisque deux évènements peuvent soit
se produire strictement en même temps
(ils sont concurrents), soit à des instant différents.
Pour pouvoir utiliser l’hypothèse
simplificatrice de synchronisme fort,
il faut bien sûr que la période d’horloge du système modélisée soit supéF IG . 4.3 – Modèle Grafcet avec branche- rieure au chemin critique du circuit.
Un autre point problématique qui
ment ET
apparaît à la lecture des graphes est
la définition des signaux sur l’ensemble du temps de simulation. Rappelons
qu’un signal est un objet concurrent, ce qui signifie que sa valeur doit être définie sur l’ensemble du temps de simulation. Or, nous avons dit qu’une action
est exécutée lorsqu’une étape est valide. Par conséquent, à moins d’affecter leur
valeur à tous les signaux à chaque étape, les signaux d’un graphe resteront en
partie indéfinis. Il faut donc introduire un formalisme permettant de définir les
valeurs par défaut des signaux traités.
4.2.3 Restrictions à la modélisation par Grafcet
La simplicité du Grafcet est un avantage important, mais elle peut s’avérer
également problématique lorsque l’analyse du modèle est équivoque ou que
certaines structures risquent de provoquer des erreurs de conception.
Pour cette raison, nous avons posé trois restrictions importantes à la modélisation par le Grafcet:
1. Le Grafcet permet de conditionner l’exécution d’une action associée à
une étape valide (cf. Fig. 4.4, p. 99). Cette structure peut être à l’origine
de problèmes de conception. En effet, pour être certain que le modèle
et le système aient des fonctionnements identiques, il faut que la condition soit synchrone avec l’horloge globale, ou que la condition puisse être
évaluée dans un temps nettement inférieur à la période d’horloge. Or ce
genre de condition peut être difficile à vérifier. Il est donc préférable de
s’abstenir d’utiliser cette structure.
98
2. Comme nous l’avons déjà indiqué en 4.2.1, p. 93, les branchements en OU
des transitions de sortie pose un problème d’analyse du modèle. Pour
éviter tout risque d’erreur de fonctionnement, nous restreignons donc
l’usage de cette structure au OU exclusif ce qui veut dire que les réceptivités associées à chaque transition du OU devront être exclusives.
3. Du fait de la limitation du Grafcet à la modélisation de systèmes synchrones, la modélisation de fonctions purement combinatoires devra utiliser un autre type de modèle (p.e. tableau de Karnaugh)
F IG . 4.4 – Formalisme de condition sur une action en Grafcet
4.2.4 Survol d’autres langages synchrones
Le travail sur les langages synchrones pour la conception de systèmes digitaux , principalement mené en France, a abouti au développement de langages
qu’on pourrait classifier en deux catégories:
1. Les langages optimisés pour la modélisation de systèmes de traitement
des données.
2. Les langages optimisés pour la modélisation d’automates.
Les langages Lustre [39], Argos et Signal [44] font parti de la première catégorie. D’un formalisme relativement complexe, ces langages restent utilisés essentiellement au niveau universitaire.
Les langages Esterel et Statecharts [22], par contre, ont été conçus pour la
modélisation et vérification de systèmes réactifs, c’est à dire des systèmes qui
réagissent à des stimuli externes et renvoient des signaux de sortie appropriés.
On trouve typiquement ce genre de systèmes dans le contrôle de procédés industriels, le contrôle de voitures, d’avions et de trains, les protocoles audio et
vidéo ...etc.
L’intérêt majeur de Esterel est la simplicité de la description de systèmes réactifs: en quelques lignes, il est possible de décrire un fonctionnement qu’il ne
serait possible de modéliser qu’avec un graphe de plusieurs centaines d’états.
Et cet avantage se renforce lorsque le nombre d’entrées à scruter croît. Ce langage a d’ailleurs trouvé un écho très favorable au niveau industriel.
99
Statecharts quant à lui se présente sous la forme d’un langage graphique.
Plusieurs versions de ce langage existent. Dans sa version commerciale [8], il
présente deux interprétations. Soit le concepteur choisit de baser la simulation
sur l’hypothèse de synchronisme fort, soit il fait évoluer le modèle sur la base
d’un signal d’horloge, l’hypothèse de synchronisme n’étant plus respectée.
Ces deux langages présentent malheureusement une lacune importante:
leur support pour une conception hiérarchique est très réduit, ce qui peut
s’avérer problématique pour des systèmes très complexes.
4.3 Analyse des modèles Grafcet
La modélisation d’un système par le Grafcet n’a pas beaucoup d’utilité si
on ne sait pas analyser le modèle en vue de son intégration.
Dans l’optique d’une méthodologie d’intégration mixte, nous nous intéressons au partitionnement matériel/logiciel du modèle, à l’analyse architecturale
de la partie matérielle, et à l’estimation de performances.
4.3.1 Partitionnement matériel/logiciel
Comme nous l’avons déjà indiqué en 2.4.1.2, le partitionnement d’un modèle requiert de définir d’abord la granularité de la partition. Cette notion implique une hiérarchie du système facilement identifiable (p.e. des fonctions,
procédures ou blocs d’instructions). Le Grafcet, grâce à la structure hiérarchique de ses macro-étapes et de ses fonctions, se prête fort bien à cette définition de la granularité.
A partir de ce point, le partitionnement peut être effectué en attribuant
par exemple une propriété à chaque noeud/étape. Dans l’état actuel de nos
connaissances, nous sommes partisans actuellement d’un partitionnement manuel soutenu par une estimation automatique des performances. Notre opinion
est basée sur le fait qu’un partitionnement automatique, lorsqu’il est possible,
nécessite énormément de ressources CPU là où le concepteur pourra avantageusement appliquer son expérience et sa connaissance intuitive du système.
Une fois le système partitionné, il faut déterminer l’ordre d’exécution des
noeuds. Ce problème n’ayant pas fait l’objet d’une étude particulière, nous
nous en tiendrons à ce qui a été dit en 2.4.1.2.
Lors de la mise en pratique, nous avons opté pour un séquencement statique des opérations.
4.3.2 Analyse architecturale
Si l’architecture du système et celle du processeur sont figées, il n’en est
pas de même de la partie matériel, ce qui laisse au concepteur une marge de
manoeuvre pour atteindre les performances souhaitées.
100
A partir du modèle Grafcet fonctionnel du système, il est possible d’explorer différentes solutions architecturales. Là aussi, on se basera sur les estimations de performance.
Classiquement, le concepteur a le choix entre deux stratégies de développement architectural:
1. Soit il choisit d’optimiser la surface au détriment de la fréquence de calcul. L’architecture la mieux adaptée est alors du type microprocesseur
avec une machine d’état et un chemin de données dans lequel on réutilise les mêmes ressources matérielles pour calculer différentes fonctions
(p.e. cas d’une ALU).
Appelons cette classe d’architecture des «architectures séries».
2. Soit il recherche une fréquence de calcul élevée ce qui implique de calculer le plus de fonctions possibles en parallèle et de minimiser le chemin
critique par la technique du «pipeline».
Appelons ce type d’architecture des «architectures parallèles».
Entre ces deux extrêmes se trouve une infinité de compromis architecturaux
qui permettent au concepteur de trouver la solution la mieux adaptée à ses
contraintes techniques.
L’analyse architecturale du Grafcet a deux objectifs:
1. Analyser les implications architecturales du modèle. En effet, selon le
graphe utilisé pour modéliser une fonctionnalité, l’implantation sera différente. Aussi, pour intégrer le système avec une certaine architecture, il
pourra être nécessaire de modifier le graphe.
2. Estimer les performances des solutions architecturales possibles à partir
d’un modèle Grafcet donné. Grâce à ces estimations, il est possible de
choisir l’architecture voulue.
En fait, ce que nous décrivons là n’est guère différent de ce qu’effectuent certains synthétiseurs architecturaux de VHDL. Celui de Synopsys par exemple
utilise un modèle VHDL fonctionnel et synthétise une architecture en essayant
de remplir les contraintes imposées.
Cependant, cette approche a selon nous un défaut. L’outil n’effectue pas
d’analyse architecturale à proprement parler. Il synthétise un circuit choisi parmis plusieurs solutions. Du coup cette approche est lente, bien que plus précise dans ses estimations. Si le circuit ne vérifie pas les contraintes imposées, le
concepteur doit:
– soit changer de stratégie de synthèse
– soit modifier le modèle
Il modifie donc éventuellement le modèle après la synthèse. A notre avis, il
est plus judicieux d’analyser le modèle avant la synthèse en déterminant les
implications architecturales pour, s’il le faut, modifier la description.
101
Notre analyse architecturale se base sur quelques règles dont nous énumérons les principales ici en les illustrant par des exemples graphiques. Nous
avons classé ces règles selon leur mise en oeuvre.
1. Règles pour inférer les ressources séquentielles et combinatoires:
(a) Toutes les actions concurrentes exécutées dans la même étape ou
dans des étapes activées en même temps (cas du branchement ET),
doivent être implantées en parallèle (cf. Fig. 4.5, p. 103 et Fig. 4.8,
p. 105).
(b) L’affectation d’un signal dans une étape correspond au stockage d’une
valeur dans un registre ou dans un emplacement mémoire (cf. Fig. 4.6,
p. 104).
(c) Les actions séquentielles exécutées dans une même étape s’intègrent
sous forme de logique combinatoire (cf. Fig. 4.7, p. 104).
2. Règles pour dupliquer ou réutiliser des ressources:
(a) Si une variable (déclarée comme telle) n’est affectée qu’à elle-même
ou à une autre variable qui n’est pas affectée à un signal, alors cette
variable n’a pas d’implantation matérielle directe mais est analysée
comme une variable architecturale (p.e. cas d’une condition booléene sur une transition).
(b) Une variable déclarée comme telle sur laquelle ne s’effectue que
des opérations d’incrément et de décrément est analysée comme un
«indice architectural» et n’a pas d’implantation matérielle directe.
(c) Un signal sur lequel ne s’effectue que des opérations d’incrément
et de décrément est analysé comme un «indice matériel» et s’implémente sous forme de compteur (cf. Fig. 4.9, p. 105).
(d) Si une fonction utilise un indice architectural, chaque valeur différente prise par l’indice créera une instanciation différente de la fonction (technique du pipeline). Voir Fig. 4.10, p. 106.
(e) Si une fonction utilise un indice matériel, on ne créera qu’une seule
instance de la fonction avec rétroalimentation, contrôlée par une machine d’état.
3. Règles pour la génération des BUS:
(a) Chaque registre est connecté à deux bus différents: un bus d’entrée
et un de sortie.
(b) Plusieurs bus peuvent fusionner si plusieurs signaux sont affectés à
un seul signal à des étapes non concurrentes (cf. Fig. 4.11, p. 106).
4. Traitement des macroétapes.
Ici, deux choix sont possibles:
(a) Soit on décide que chaque macro-étape a sa propre implantation et
on ne partage pas les ressources matérielles. On effectue alors une
102
analyse architecturale pour chaque macro-étape affectée à une intégration matériel.
(b) Soit on fusionne l’implantation des macro-étapes et on partage les
ressources matérielles. Dans ce cas, on effectue une seule analyse
architecturale pour les macro-étapes affectées à une intégration matériel en optimisant l’emploi des ressources.
F IG . 4.5 – Implantation d’actions concurrentes
A travers cette analyse architecturale, on s’aperçoit que pour chaque graphe
fonctionnel, l’application des règles que nous avons citées implique une seule
implantation architecturale possible et par conséquent, certaines performances.
Cette approche présente l’avantage que le concepteur maîtrise l’architecture
de la partie matériel à travers le modèle fonctionnel du système. Par voie de
conséquence, il a un accès rapide à l’établissement des performances. Pour
atteindre des objectifs de performance (chemin critique, fréquence de calcul,
latence, surface ...etc.), le concepteur devra simplement modifier son modèle
avant d’entamer le processus de synthèse. La synthèse permettra alors d’affiner les contraintes de performance en laissant à l’outil le choix de l’implantation des opérateurs arithmétiques et logiques et fonction des contraintes de
synthèse (p.e. valeur du chemin critique).
Cette approche présente évidemment l’inconvénient d’obliger le concepteur à «travailler» son modèle au lieu de laisser à un outil l’initiative du choix
l’architecture. Mais, vu qu’actuellement les outils de synthèse d’architecture
définissent des restrictions sur les modèles fonctionnels afin d’atteindre des
103
F IG . 4.6 – Inférence de registres
F IG . 4.7 – Génération de logique combinatoire
104
F IG . 4.8 – Implantation d’actions concurrentes
F IG . 4.9 – Implantation d’un «indice matériel»
105
F IG . 4.10 – Duplication d’une fonction
F IG . 4.11 – Fusion de deux bus
106
résultats acceptables, le concepteur n’est pas libéré de toute contrainte de modélisation. Il nous semble donc préférable qu’il maîtrise les implications de son
modèle.
4.3.3 Estimation de performances
Estimer les performances d’un système est complexe car la synthèse, la
compilation et le placement/routage introduisent des non-linéarités qu’il est
très difficile de modéliser. Malheureusement, le recourt à la synthèse pour estimer à posteriori les performances est un processus trop lent pour être efficace.
Nous avons donc décidé de recourir pour l’instant à des fonctions d’estimation linéaires, sachant que les résultats obtenus ne fourniront que des ordres
de grandeur. Cet ordre de grandeur est néanmoins suffisant pour définir des
stratégies d’intégration et choisir une architecture pour la partie matériel. La
technique employée pour les trois grandeurs actuellement prises en compte
(surface de silicium, chemin critique et fréquence de calcul) s’inspire de la méthode proposée par Kumar et al dans [53].
4.3.3.1 Estimation de la surface de silicium
A partir de l’analyse architecturale, nous pouvons déterminer différentes
architectures possibles avec la consommation de ressources matérielles qu’elles
impliquent (additionneurs, registres ...etc.). En effectuant des présynthèses des
éléments en question, on dispose de la surface (ou nombre de portes) occupée.
En ajoutant ces surfaces élémentaires, on peut se faire une idée de la surface
occupée.
Cette technique marche assez bien avec les FPGA car l’influence du routage sur la surface occupée est faible. Par contre, les résultats obtenus avec des
technologies précaractérisées sont loin de la réalité en raison de la présence des
lignes de métal du routage. L’intérêt des résultats est qu’ils permettent d’une
part de fixer une limite inférieure de surface que le circuit occupera et d’autre
part, ces estimations facilitent le choix entre différentes options architecturales
en comparant proportionnellement les surfaces occupées.
4.3.3.2 Estimation du chemin critique
Pour cette estimation, nous reprenons le principe utilisé pour l’estimation
de surface. On détermine d’abord pour les ressources matérielles employées le
chemin critique pour la technologie envisagée, puis on additionne les différents
chemins critiques entre deux registres en recherchant le chemin le plus long.
Là aussi, les résultats atteints sont toujours très inférieurs à ce que vaudra
le chemin critique dans le système réel, mais il permettent de fixer la limite de
fréquence maximale que peut atteindre théoriquement le circuit.
107
4.3.3.3 Estimation de la fréquence de calcul
Avec cette estimation, on cherche à déterminer le nombre d’échantillons par
seconde que le circuit sera capable de traiter. Il faut donc estimer le nombre de
périodes d’horloge nécessaire à un calcul complet.
Ce calcul est différent si on se place dans le cas du matériel ou du logiciel.
Dans le cas du matériel, une opération ne dure souvent qu’une seule période
d’horloge alors que pour le logiciel, un opération dure la plupart du temps
plusieurs cycles d’horloge.
Dans le cas du matériel, la durée d’une étape est déterminée par la réceptivité de la ou des transitions de sortie. En général, cette réceptivité est définie à
partir de signaux internes à la partie matériel dont on peut calculer l’évolution
temporelle. Déterminer la durée d’une étape est possible avec une assez bonne
précision.
Dans le cas du logiciel, le calcul est plus difficile car la durée des opérations
dépend du processeur choisi. Il faut donc définir pour toutes les fonctions utilisées, le temps de calcul en cycles d’horloge pour avoir une estimation de la
durée d’une étape.
La durée de chaque étape étant définie, on peut rechercher le chemin le
plus long dans le Grafcet du système. En ajoutant les durées de chaque étape,
on obtient une estimation du temps de calcul du système.
4.3.3.4 Mise en oeuvre
Les techniques présentées n’ont pas été programmées actuellement si bien
que leur mise en oeuvre n’a pu être que manuelle. Bien que très simples, ces
techniques restent très difficiles à mettre en oeuvre manuellement lorsque le
système envisagé est trop complexe. Les essais que nous avons fait se sont limités à quelques cas simples comme l’algorithme CORDIC classique. Pour cette
raison, nous ne sommes pas en mesure de préciser la précision des estimations
obtenues par cette technique.
4.4 Synthèse de code
Le Grafcet n’étant actuellement ni simulable ni synthétisable par faute d’outil, nous avons du traduire les graphes vers des langages simulables et synthétisables ou compilables: le script MATLAB, VHDL et le code C (ou l’assembleur). Dans ce paragraphe, nous traitons aussi l’affinement des modèles Grafcet pour introduire des spécifications supplémentaires comme la gestion des
mémoires ou l’arbitrage de l’accès aux ressources partagées. Ce n’est qu’à partir des graphes affinés qu’on génère les modèles haut niveau de description du
système (matériel et logiciel).
108
4.4.1 Synthèse du script MATLAB
La traduction du Grafcet vers MATLAB est nécessaire pour simuler la modélisation fonctionnelle du système. On simulera le modèle MATLAB notamment avec le modèle analogique du moteur.
La traduction du modèle fonctionnel Grafcet vers MATLAB est simple.
Chaque graphe est traduit vers une fonction différente. Le séquencement des
opérations du Grafcet est repris tel quel dans le code MATLAB. Les réceptivités
et les branchements des graphes sont traduits par des instructions «if ... then ...
else». Les opérations binaires font appel à des fonctions MATLAB qui réalisent
les calculs.
Une fois le code MATLAB généré, il est interprété directement par un appel
en ligne de la fonction de plus haut niveau.
4.4.2 Affinement des spécifications
L’affinement des spécifications consiste à donner des informations structurelles sur la mise en oeuvre de certaines opérations. Par exemple, on pourra
définir si une variable est stockée en RAM ou dans un banc de registre.
Au niveau du Grafcet, il faudra donc remplacer certaines étapes strictement fonctionnelles par une série d’étapes structurelles. Pour d’autres types
de spécifications structurelles, on pourra insérer des étapes dans les graphes.
Ces nouvelles étapes peuvent faire appel à des sous graphes pour, par exemple,
gérer des accès à des ressources partagées.
Cependant, ces solutions étant peu efficaces et peu élégantes, nous prévoyons d’étudier des solutions qui permettraient d’inférer par exemple les affinements structurels à partir d’indications textuelles (par exemple indiquer
textuellement quelle variable stocker en RAM).
4.4.3 Synthèse du code VHDL
En reprenant quelques concepts du VHDL, nous avons facilité également la
traduction des modèles vers ce langage. Nous avons néanmoins le choix entre
deux approches différentes: soit on génère une description de la partie matériel
en se basant sur l’analyse architecturale, soit on effectue une traduction directe
du graphe.
La synthèse du code VHDL en imposant l’architecture revient à écrire le
code au niveau transfert de registre (RTL 3 ). Cette description est la plus efficace en terme de synthèse actuellement. Bien que les synthétiseurs logiques
sont capables de traiter les descriptions fonctionnelles (behavioural description), les résultats de synthèse restent plus performant lorsque l’architecture
est précisée. Cette différence provient essentiellement du fait que ce type de
description permet d’optimiser chaque partie de l’architecture séparément.
Lorsqu’on effectue un traduction directe du graphe, l’outil de synthèse est
obligé d’effectuer l’exploration des recherches architecturales et les tests que
3. Register Transfert Level
109
nous avons effectués montrent que la qualité des résultats est fortement dépendante de la manière dont est écrite le modèle. Deux modèles fonctionnels
ayant un même comportement en simulation ne déboucheront pas sur le même
résultat de synthèse. Cette incertitude sur les résultats de synthèse nous fait
préférer actuellement la description RTL avec laquelle le résultat est assuré.
4.4.4 Synthèse de code logiciel
Grâce aux compilateurs C pour les processeurs utilisés (DSP notamment),
la génération de code a été simplifiée, le langage C étant beaucoup plus simple
à manier que l’assembleur. La génération du C s’effectue de la même manière
que la génération de code MATLAB, c’est à dire que nous traduisons la séquence des opérations par la séquence des instructions C.
Nous ne pouvons malheureusement pas développer ce sujet, les tests sur la
génération du code logiciel ayant été très réduits.
4.5 Conclusion
Afin de disposer d’un outil de modélisation puissant et simple, nous nous
sommes intéressés au Grafcet. Nous avons montré que ce langage graphique
pouvait remplir nos attentes en apportant de légères modifications à l’interprétation du fonctionnement des modèles et au formalisme textuel associé à ce
langage. En introduisant des restrictions de modélisation, nous limitons également les erreurs de conception qui pouvaient être introduites par des ambiguïtés du Grafcet.
Par la présentation d’autres langages de modélisation synchrones, nous
avons également vu que ceux-ci n’étaient pas adaptés à la modélisation des
systèmes de commande, ce qui justifie l’adaptation du Grafcet pour ce type
d’applications.
Nous avons effectué une analyse plus poussée des implications architecturales des modèles Grafcet lors de l’intégration sous forme matériel ce qui a
permis de montrer qu’on pouvait réaliser cette analyse architecturale et les estimations associées avant la synthèse et donc améliorer la vitesse de décision
quant au choix de l’architecture.
Au niveau des autres tâches caractéristiques de la conception mixte comme
le partitionnement et l’estimation de performance, nous avons proposé des solutions possibles et montré ainsi que le Grafcet se prête à ce type de méthodologie.
Finalement, nous évoquons la synthèse de code haut niveau à partir des
modèles Grafcet, tant pour la simulation fonctionnelle (MATLAB) que pour la
description haut niveau du matériel (VHDL) et du logiciel (C ou assembleur).
110
Chapitre 5
Implantation du contrôle
vectoriel d’un moteur
asynchrone
5.1 Introduction
Jusqu’à présent, nous avons traité les aspects théoriques de la conception
des systèmes de commande. Sur la base de ces résultats, nous décrivons dans
ce chapitre l’intégration d’un algorithme de contrôle vectoriel de moteur asynchrone.
Mais avant d’aborder le sujet, il nous faut donner quelques détails sur le
développement historique du projet. A l’origine, le projet avait pour but d’étudier l’intérêt des ASIC pour la mise en oeuvre des algorithmes de commande.
Un des objectifs était donc de développer un ASIC de contrôle vectoriel en
se basant sur un algorithme déjà intégré sur microcontrôleur afin d’effectuer
des comparaisons. C’est au cours de ce travail que s’est imposé la nécessité de
formaliser une méthodologie pour aborder la conception des systèmes de commande. Du projet initial, il est resté le développement de l’ASIC de commande,
mais en se basant cette fois sur la méthodologie conception mixte proposée (cf.
Fig. 5.1). Ceci explique pourquoi dans la suite de ce chapitre, nous n’envisageons pas une intégration mixte du système de commande.
Le présent chapitre s’articule autour de trois parties:
1. En premier lieu, nous rappelons les enjeux de la conception des systèmes
de commande tels qu’ils ont été analysés tout au long de cette thèse.
2. Ensuite, nous présentons l’intégration de la commande du moteur asynchrone en se basant sur la méthodologie de conception mixte.
3. Finalement, nous montrons quelques résultats expérimentaux de tests effectués sur un prototype partiel de l’ASIC de commande.
111
F IG . 5.1 – Méthodologie de conception mixte
112
Les développements théoriques relatifs aux algorithmes utilisés (algorithme de
contrôle, MLI, CORDIC) sont présentés en annexe afin d’améliorer la lisibilité
des résultats.
5.2 Les enjeux de la conception des systèmes de commande
Nous rappelons rapidement ici les enjeux de la conception des systèmes de
commande, c’est à dire les problèmes spécifiques et les objectifs généraux, afin
de montrer par la suite comment il en a été tenu compte:
– Nous devons être en mesure de traiter les spécifications floues, c’est à
dire que la conception devra être relativement indépendante de ces paramètres pour pouvoir éventuellement modifier les spécifications.
– Le développement doit être relativement indépendant de la technologie
(tant matériel que logiciel) pour pouvoir éventuellement partitionner le
système ou pour l’intégrer vers différentes cibles technologiques.
– Nous devons adapter les algorithmes implantés (sans modifier la fonctionnalité) aux contraintes imposées par la stratégie d’intégration (p.e.
minimisation du temps de calcul).
– Il faut s’assurer que le système intégré ne présente pas des erreurs de
fonctionnement dues à l’intégration.
5.3 Intégration de la commande vectorielle
L’intégration de la commande s’est effectuée sur la base de la méthodologie de conception mixte. Pour cette raison, chaque paragraphe de cette partie
correspond à une tâche de la méthodologie. Pour une meilleur compréhension,
nous avons placé, dans la marge de chaque paragraphe principal, un schéma
de la méthodologie avec une étape grisée correspondant à la tâche décrite.
5.3.1 Spécification du système de commande
5.3.1.1 Analyse fonctionnelle
Le système de commande à intégrer doit contrôler le couple d’un moteur
asynchrone de 4 KW. Ce moteur est alimenté par un onduleur dont la tension
continue d’entrée est assurée par huit batteries au plomb connectées en
série. Sur le banc d’essai, le moteur est chargé à travers son axe par une génératrice continue qui débite dans un banc de lampes (cf. Fig. 5.2).
Du système de commande que nous considérons, on peut extraire six fonctionnalités différentes:
1. L’acquisition des mesures et de la consigne: ce bloc a pour fonction de
gérer les convertisseurs analogique/numérique, c’est à dire de générer
113
F IG . 5.2 – Banc de test de la commande du moteur asynchrone
les signaux de commande de ces dispositifs, de stocker les données reçus
et de les transmettre au bloc de traitement.
2. Le traitement des mesures et de la consigne: les données analogiques acquises par le bloc précédent doivent être traitées et mises au format binaire utilisé. Le bloc de traitement se charge de cette opération. Le détail
des opérations de traitement est explicité en annexe F.
3. l’algorithme vectoriel: c’est la fonction principale de la commande. Cet
algorithme permet de contrôler le moteur qui entraîne la chaîne de traction électrique. Il reçoit en entrée les mesures au format binaire choisi et
calcule les tensions à appliquer au moteur asynchrone. On trouvera la
mise en équation de l’algorithme en B.1.2.1, p. 159.
L’algorithme utilisé régule le couple du moteur. Comme nous l’avons indiqué en annexe, le contrôle vectoriel permet de réguler indépendamment le couple et le flux. La consigne de couple est donnée par une composante du courant statorique ( ) alors que le flux dépend du courant
magnétisant , ce dernier étant une variable interne du système de
commande.
Pour augmenter ou diminuer le couple, il suffit de varier . A flux constant,
on varie donc la puissance délivrée par le moteur, et par conséquent, à
couple résistant constant, on fait varier la vitesse de rotation de l’axe.
Par contre, si la consigne de couple est trop importante par rapport au
couple résistant, l’algorithme se charge de diminuer le flux (opération
dite de «défluxage») lorsque le moteur atteint sa vitesse nominale afin de
ne pas dépasser la puissance nominale du moteur.
114
4. L’algorithme MLI vectoriel: Cet algorithme sert d’interface algorithmique
entre l’algorithme vectoriel et le bloc de génération des impulsions de
commande de l’onduleur. L’algorithme MLI vectoriel calcule les instants
de commutation des interrupteurs de l’onduleur à partir des consignes
de tension reçus de l’algorithme de contrôle vectoriel. Les équations de
cet algorithme sont développées en B.2, p. 164.
5. La génération des impulsions de commande de l’onduleur: la fonction de
ce bloc est de générer les signaux physiques de commande de l’onduleur
à partir des instants de commutation que lui communique l’algorithme
MLI. C’est en quelque sorte l’interface du système de commande avec le
monde analogique.
6. La sécurité de fonctionnement: pour protéger la chaîne d’entraînement
contre des disfonctionnements destructifs, le système de commande inclus une fonctionnalité de sécurité qui gère essentiellement l’interruption du système et la génération des signaux d’erreur. On protège ainsi
la chaîne d’entraînement contre les court-circuits dans l’onduleur, contre
une baisse excessive de la tension continue d’entrée de l’onduleur et on
gère les interruptions causées par l’utilisateur.
5.3.1.2 Topographie fonctionnelle du système
A partir de la liste des fonctions constitutives du système de commande,
on trace une topographie fonctionnelle du système qui permet de décrire les
échanges de données entre les fonctions et d’analyser la nature de chaque bloc
en vue de la modélisation fonctionnelle. Cette topographie n’est nullement une
préétude architecturale, c’est une vue abstraite du système (cf. Fig. 5.3, p. 116).
5.3.1.3 Spécifications physiques
Pour avoir une idée plus précise de la forme que prendra l’intégration physique du système, nous avons résumé des spécifications physiques du système
sachant que celles-ci pouvaient changer au cours du développement. Ces spécifications sont «floues», elles servent à donner des ordres de grandeur.
– Le moteur: sa puissance est de 4 KW. Ses paramètres caractéristiques sont
indiqués en annexe C.
– L’alimentation: assurée par huit batteries au plomb de 12V chacune, elle
vaut au plus 96V.
– La fréquence d’échantillonnage: elle doit au moins valoir 2 KHz, soit une
période de 500 %s.
– La fréquence de commutation: elle est au moins égale à la fréquence d’échantillonnage et en principe quatre fois supérieure, soit environ 8 KHz. Si
l’intégration le permet, on souhaite monter jusqu’à 16 KHz, c’est à dire la
fréquence de l’inaudible.
– Le temps mort: il est fixé à environ 3 %s.
115
F IG . 5.3 – Topographie du système de commande
116
– Les capteurs de courant: deux capteurs à effet Hall servent à mesurer le
courant dans les enroulements statoriques. Ils doivent être alimentés sous
12V ce qui place le point de repos à 6V.
– Le capteur de vitesse: il est constitué d’un disque denté de 18 dents. Les
dents interceptent les faisceaux infrarouges de deux optocommutateurs
qui génèrent deux signaux carrés déphasés. Ils doivent être alimentés
sous 5V.
– Le capteur de tension d’alimentation : il est constitué par un optocoupleur en régime linéaire alimenté sous 5V.
5.3.1.4 Spécifications technologiques
Ici aussi, les spécifications concernant la technologie à employer sont floues.
La seule contrainte est l’intégration globale du système sous forme d’ASIC.
En ce qui concerne la connection du système de commande avec les circuits
de mesure, il fallait conserver la compatibilité avec les signaux TTL en raison
des circuits discrets utilisés pour la mise en forme des mesures.
En principe, l’alimentation du système devait être générée à partir des tensions des batteries, c’est à dire au minimum 12V. Ceci est dû au fait que la
commande était prévue pour être embarquée sur un véhicule électrique dans
lequel la seule source d’énergie est le banc de batteries.
5.3.1.5 Modélisation du système
La modélisation du système s’est effectuée en deux étapes. D’abord, nous
avons décrit un modèle de compréhension de l’algorithme de contrôle afin
d’étudier son fonctionnement. Une fois l’algorithme de contrôle maîtrisé, nous
avons développé les modèles de spécification de l’ensemble des blocs de la
commande.
Le modèle de compréhension Ce modèle reprend le schéma bloc de l’algorithme de contrôle (cf. Fig. 5.4, p. 118). Nous avons décrit ce schéma bloc sous
MATLAB et simulé le contrôle avec le modèle de Park du moteur. Les résultats de la simulation montrent le comportement idéal du moteur avec la commande vectorielle. Les figures 5.5a-c et 5.6a-c, p. 119 et p. 120, montrent des
grandeurs caractéristiques du moteur lors d’un démarrage. On observe clairement que le couple «suit» la consigne donnée par le courant (Fig. 5.6-a et
Fig. 5.6-c) jusqu’à ce que la vitesse dépasse sa valeur nominale (1425 t/min) à
7s (Fig. 5.5-c). On peut voir alors la phase de défluxage avec la diminution du
courant magnétisant (Fig. 5.6-b) et du couple. La période de 0 à 0.5 secondes
correspond à l’établissement du flux. Durant ce laps de temps, aucune consigne
de couple n’est appliquée. Les niveaux de courant et de tension enregistrés
servent à maintenir le flux nominal dans la machine (Fig. 5.5-a et 5.5-b).
Toujours avec ce modèle, nous avons simulé l’influence de la période d’échantillonnage sur les grandeurs caractéristiques du moteur. En effet, cette constante
117
F IG . 5.4 – Schéma bloc de l’algorithme de commande
118
80
60
40
20
0
−20
−40
−60
−80
0
1
2
3
4
5
(a) Courant statorique
6
7
8
9
10
8
9
10
8
9
10
(en A)
100
80
60
40
20
0
−20
−40
−60
−80
−100
0
1
2
3
4
5
6
7
(b) Tension sur une phase du moteur (en V)
200
180
160
140
120
100
80
60
40
20
0
0
1
2
3
4
5
6
7
(c) Vitesse de rotation du moteur (en rad/s)
F IG . 5.5 – Simulation de l’évolution des grandeurs caractéristiques du moteur en fonction du temps (en s) lors d’un démarrage
119
70
60
50
40
30
20
10
0
−10
0
1
2
3
4
5
6
7
8
9
10
8
9
10
8
9
10
(a) Consigne de couple (en A)
14
12
10
8
6
4
2
0
0
1
2
3
4
5
6
7
(b) Courant magnétisant estimé (en A)
40
35
30
25
20
15
10
5
0
0
1
2
3
4
5
6
7
(c) Couple moteur (en N)
F IG . 5.6 – Défluxage du moteur (fonction du temps en s)
120
est particulièrement importante pour la conception du système puisqu’à partir de sa valeur, on détermine le temps de calcul maximum du système ainsi
que l’ensemble des autres temps caractéristiques (cf. 3.2.1.1). Les figures 5.7(af) p. 122, montrent que la diminution de la période d’échantillonnage réduit les
pics de courant et de tension.
Modèle de spécification Dans la topographie fonctionnelle du système, nous
avons dégagé la nature des différentes fonctions de la commande. En dehors
de la fonction de sécurité de fonctionnement, la nature des fonctions est compatible avec une modélisation par le Grafcet. En ce qui concerne la sécurité
de fonctionnement, la spécification fonctionnelle est suffisamment simple pour
que la modélisation par le Grafcet soit également possible.
Nous présentons les modèles de la commande (Fig. 5.8, p. 123) et du bloc
MLI (Fig 5.9, p. 124). Pour plus de clarté, ces modèles restent au niveau des
macro-étapes. On peut voir que le modèle de la commande reprend le modèle
du bloc MLI sous forme d’une macro-étape. Rappelons que ces modèles décrivent des opérations binaires, contrairement au modèle de compréhension.
5.3.2 Vérification fonctionnelle
Au niveau de la vérification fonctionnelle, nous avons simulé le modèle de
spécification MATLAB (traduit du Grafcet) des différents blocs.
Dans le cas de la commande, le modèle du moteur et le modèle fonctionnel
binaire du système de commande ont été cosimulés pour vérifier que la fonction de contrôle était assurée. Remarquons que nous avons rencontré les problèmes que nous évoquions à propos de la cosimulation analogique/numérique:
pour simuler deux secondes du démarrage du moteur, environ 48 heures de simulation ont été nécessaires sur un pentium 133MHz. On peut comparer cela
aux dix minutes que durent les cosimulations du modèle de compréhension
avec le modèle du moteur (cf. 5.3.1.5).
Ces simulations binaires du modèle de spécification de la commande, dont
on présente les résultats aux figures 5.10(b,d,f) et 5.11(b,d,f), utilisent des mots
binaires au format 1. La période de commutation ( ) a été fixée à
530%s, c’est à dire égale à la période d’échantillonnage. Dans le modèle MATLAB, une fonction d’interface génère les vecteurs de tension MLI à partir des
instants de commutation calculés par l’algorithme. Pour activer le modèle analogique du moteur sous MATLAB, il faut que ces signaux de tension soit indexés sur le temps. Pour cette raison, chaque point de la courbe de tension
générée correspond à un instant de temps, c’est à dire qu’implicitement, on définit la période d’horloge. Dans le cas des simulations précédentes, les signaux
de tension étaient définis sur 100 points, ce qui correspond à une horloge de
5,3%s.
Les simulations correspondantes du modèle de compréhension (arithmétique réelle) sont données aux figures 5.10(a,c,e) et 5.11(b,d). On peut voir que
1. 12 bits entiers sur une longueur de 16 bits en tout
121
30
30
20
20
10
10
0
0
−10
−10
−20
−20
−30
−30
−40
0
0.1
0.2
0.3
0.4
0.5
−40
0
0.6
(a) Courant pour 530s (en A)
10
5
5
0
0
−5
−5
−10
−10
0.1
0.2
0.3
0.4
0.5
−15
0
0.6
(c) Tension sur une phase pour
530s (en V)
14
12
12
10
10
8
8
6
6
4
4
2
2
0.1
0.2
0.3
0.4
0.5
0.3
0.4
0.5
0.6
0.1
0.2
0.3
0.4
0.5
0.6
(d) Tension sur une phase pour 300s (en V)
14
0
0
0.2
(b) Courant pour 300s (en A)
10
−15
0
0.1
0
0
0.6
(e) Courant magnétisant estimé
pour 530s (en A)
0.1
0.2
0.3
0.4
0.5
0.6
(f) Courant magnétisant estimé
pour 300s (en A)
F IG . 5.7 – Grandeurs caractéristiques du moteur en fonction du temps (s) pour deux
périodes d’échantillonnage différentes
122
F IG . 5.8 – Modèle de spécification de la commande
123
F IG . 5.9 – Modèle de spécification du bloc MLI
124
pour ces conditions de simulation, l’équivalence fonctionnelle entre le modèle
de comparaison et le modèle de spécification est assurée.
La vérification du bloc MLI a été réalisée en même temps que le bloc de
génération des impulsions pour visualiser plus facilement la cohérence des résultats (Fig. 5.12, p. 128). La consigne du bloc MLI est un vecteur de tension de
80V. La période de commutation vaut toujours 530%s mais les vecteurs
de tension sont définis cette fois sur 500 points.
Finalement, nous avons simulé les blocs d’acquisition et de traitement des
données en nous basant sur un convertisseur 8bits.
5.3.3 Partitionnement et estimation
Dans cet exemple d’application, une des spécifications initiales est d’intégrer l’ensemble de la commande sous forme matériel. Il n’y a donc pas lieu de
partitionner le système. Par contre, il est nécessaire d’effectuer les autres tâches
associées à cette étape.
Le travail s’effectue sur les modèles Grafcet des fonctions de commande.
Cela a pour conséquence que les résultats obtenus durant cette étape ne dépendent pas du modèle, mais des spécifications. On peut donc dire que la
conception est indépendante de la technologique à ce niveau.
5.3.3.1 Allocation
Jusqu’à présent, nous n’avons pas précisé de technologie pour l’intégration
de la commande ce qui doit être fait maintenant au niveau de l’allocation des
ressources.
Pour l’intégration sous forme matériel, nous avons décidé d’utiliser un FPGA
au lieu d’une technologie semi-custom. Ce choix est dicté par la flexibilité de
prototypage qu’offrent cette technologie, mais aussi par le fait qu’il est possible
de trouver actuellement des FPGA de très grande capacité tant au niveau du
nombre de portes (jusqu’à 250.000 portes pour la famille Flex10k250 d’Altera)
qu’au niveau fréquence d’horloge (environ 50MHz pour la famille Flex10kB
d’Altera). Par ailleurs, ces dispositifs offrent la possibilité d’intégrer directement des ROM et des RAM ce qui élimine la nécessité de les prévoir en boîtier
externe. Finalement, grâce à l’utilisation de VHDL pour la modélisation de la
partie matériel, il a été envisagé d’intégrer à terme le système en technologie
semi-custom après avoir effectué les tests sur FPGA. Dans l’immédiat, nous
avons choisi d’utiliser un Flex10K100A d’Altera, dispositif intégrant environ
100.000 portes logiques.
Au niveau des convertisseurs analogiques/digitaux, nous avons utilisé des
TLC0831 de Texas Instruments.
5.3.3.2 Transformation algorithmiques
Dans cette étape, nous analysons les primitives mathématiques utilisées
pour déterminer quels algorithmes binaires nous permettront de calculer ces
125
80
80
60
60
40
40
20
20
0
0
−20
−20
−40
−40
−60
−80
0
−60
0.1
0.2
0.3
0.4
(a) Courant
0.5
0.6
0.7
−80
0
0.8
(en A)
0.1
0.2
0.3
(b) Courant
binaire
25
0.4
0.5
0.6
0.7
0.8
(en A) - simulation
30
20
20
15
10
10
5
0
0
−5
−10
−10
−15
−20
−20
−25
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
−30
0
0.8
(c) Tension (en V)
0.2
0.3
0.4
0.5
0.6
0.7
0.8
(d) Tension (en V) - simulation
binaire
14
14
12
12
10
10
8
8
6
6
4
4
2
2
0
−2
0
0.1
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
−2
0
0.8
(e) Vitesse de rotation (en
rad/s)
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
(f) Vitesse de rotation (en
rad/s) - simulation binaire
F IG . 5.10 – Évolution des grandeurs caractéristiques du moteur en fonction du temps
(s) pendant un démarrage: simulation du modèle de compréhension (gauche) et de
spécification (droite)
126
14
12
10
8
6
4
2
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
(a) Consigne de flux (en A) simulation binaire
14
14
12
12
10
10
8
8
6
6
4
4
2
2
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0
0
0.8
(b) Courant magnétisant estimé
(en A)
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
(c) Courant magnétisant estimé
(en A) - simulation binaire
35
45
40
30
35
25
30
20
25
15
20
15
10
10
5
5
0
−5
0
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
−5
0
0.8
(d) Couple moteur (en N)
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
(e) Couple moteur (en N) - simulation binaire
F IG . 5.11 – Évolution du couple et de la consigne de flux en fonction du temps (s):
simulation du modèle de compréhension (gauche) et de spécification (droite)
127
1
0.5
0
0
50
100
150
200
250
300
350
400
450
500
50
100
150
200
250
300
350
400
450
500
50
100
150
200
250
300
350
400
450
500
1
0.5
0
0
1
0.5
0
0
F IG . 5.12 – Simulation de la MLI et génération des impulsions
fonctions. Le choix de l’une ou l’autre implantation binaire se base sur des
considérations de surface d’intégration, de vitesse de calcul et de complexité
de mise en oeuvre.
Le système de commande considéré utilise les primitives mathématiques
suivantes:
– la rotation: elle peut être calculée soit par l’algorithme CORDIC classique
(cf. annexe D), soit par interpolation linéaire des fonctions sinus et cosinus
suivie de multiplications et d’additions.
– la division: on peut utiliser soit directement un diviseur, soit utiliser l’algorithme CORDIC généralisé.
– la multiplication: comme pour la division, on peut avoir recourt soit à un
multiplieur, soit utiliser l’algorithme CORDIC généralisé.
– La multiplication par des constantes: nous séparons cette opération de la
multiplication simple car la multiplication par des constantes pose des
problèmes que nous évoquons en D.4. Pour résoudre cela, nous proposons l’utilisation d’un algorithme de multiplication itérative, l’autre solution étant le recourt à la multiplication classique précédée et suivie d’opérations de décalage.
– les opérations logiques (<, >, =, shift, ...etc.): elles peuvent s’intégrer soit par
des opérateurs spécifiques (circuits combinatoires), soit par une séquence
d’opérations (additions, soustractions ...etc.).
A ce stade de la réflexion, nous ne savons pas encore en principe quelle stratégie architecturale nous suivrons (calcul parallélisé ou séquentialisé). Nous
verrons plus en avant que nous avons opté pour une architecture relativement
séquentielle pour minimiser la surface occupée. Pour cette raison, nous avons
choisi de recourir à l’algorithme CORDIC lorsque c’était possible ainsi que les
algorithmes séquentiels permettant de réutiliser le plus possible les ressources
matérielles (additionneurs, registres, shifters ...etc.).
128
5.3.3.3 Précision de la commande et overflow
Le système de commande et les algorithmes auxquels on fait appel sont
trop complexes pour apporter la preuve formelle que la précision de calcul est
suffisante (format et 19 bits internes pour le CORDIC) et qu’il n’y a pas
de risque de débordement. Nous avons donc effectué quelques études pour les
blocs les plus sensibles (CORDIC et multiplication par constantes, cf. D.5.3).
Pour la commande, nous nous sommes contenté de vérifier ces propriétés à
partir des simulations du modèle de spécification, déjà présentées précédemment (cf. Fig 5.11 et 5.11). Nous n’apportons donc pas les preuves mathématiques souhaitables.
5.3.3.4 Estimation de la fréquence de calcul
A partir des modèles Grafcet, nous avons évalué le nombre de périodes
nécessaires à un cycle de calcul, c’est à dire le temps qui sépare la lecture des
échantillons du calcul des instants de commutation.
Le Grafcet fonctionnel de la commande compte une centaine d’étapes dont
certaines durent plus d’une période d’horloge lorsqu’elles correspondent à des
opérations effectuées par des blocs arithmétiques (CORDIC, multiplication de
constante, ALU) ou qu’elles requiert des opérations supplémentaires définies
par l’affinement du modèle (lecture/écriture de RAM, de registres ...etc.). Nous
avons compté 13 multiplications par constante et 17 opérations CORDIC, ce
qui correspond au maximum à respectivement 208 et 323 périodes d’horloge.
Certaines opération s’effectuent en parallèle (p.e. CORDIC et multiplication
par constante) si bien que le nombre total estimé de périodes d’horloge d’une
période de calcul de la commande est inférieur à . Par
conséquent, on peut admettre un temps maximum de calcul de 1000 périodes
d’horloge.
Selon les spécification qui fixent la période d’échantillonnage au plus à
500%s, la période d’horloge ne devra donc pas dépasser 500ns.
5.3.4 Synthèse mixte
Dans cette étape, nous allons chercher à fixer l’architecture du matériel et
affiner le modèle de spécification. A partir de la description affinée, on pourra
générer le code VHDL correspondant.
5.3.4.1 Architecture de l’ASIC
Le critère principal pour le choix architectural a été la minimisation du coût
de l’ASIC et donc de la surface silicium (moins de 100.000 portes logiques). La
limitation à cette stratégie a été de respecter la contrainte de chemin critique
fixée à 500ns.
L’analyse des primitives mathématiques a montré que beaucoup d’opérations complexes pouvaient se réaliser à partir du même algorithme. Pour mi129
nimiser le nombre de ressources matérielles, nous avons donc utilisé l’algorithme CORDIC pour ces opérations. Les autres opérations (multiplication par
des constantes, opérations logiques) utilisent des algorithmes qui peuvent également s’intégrer sur une même structure matérielle. Nous avons donc également développé une ALU spécifique.
F IG . 5.13 – Architecture de l’ASIC de commande
Néanmoins, l’analyse du Grafcet montre également que certaines opérations peuvent s’effectuer en même temps. Pour minimiser le temps de calcul,
nous avons donc choisi une architecture globale permettant une utilisation en
parallèle de l’ALU et du CORDIC.
130
Un autre point important pour l’architecture est le nombre de constantes
et de variables de l’algorithme. En effet, vu leur nombre élevé, nous avons
décidé d’allouer les variables à une RAM et les constantes à une ROM. Ce point
présente d’ailleurs l’intérêt qu’il devient possible d’adapter l’ASIC à un autre
moteur simplement en modifiant les valeurs de la ROM.
La figure 5.13 montre l’architecture issue de ces réflexions.
5.3.4.2 Affinement de la spécification
L’affinement du modèle de spécification permet maintenant de prendre en
compte les caractéristiques de l’architecture. On modifie le modèle afin d’introduire les opérations de lecture/écriture dans les registres et la RAM, la génération des adresses et la gestion du bus partagé.
On affine également le modèle du bloc d’acquisition des mesures puisque
le modèle des CAN a été défini dans l’étape d’allocation.
5.3.4.3 Synthèse du code VHDL
Pour la synthèse du code VHDL, nous avons utilisé les IP développés auparavant: CORDIC, ALU, génération des signaux MLI ...etc. Du coup, la synthèse de code VHDL à partir du modèle Grafcet de la commande s’est réduit
essentiellement à la génération de la machine d’état globale qui commande les
instances des IP.
Cette machine d’état comporte 453 états ce qui la rend plutôt illisible, contrairement au Grafcet.
L’ensemble du modèle VHDL du système est paramétrisé par des génériques indiquant notamment la largeur des chemins de données ou le format
binaire employé. D’autre part, le modèle VHDL de la ROM génère automatiquement son contenu binaire à partir des constantes caractéristiques de la
commande (paramètres électriques du moteur, temps mort, fréquence d’échantillonnage ...etc.). Grâce à ces paramétrisations, des modifications de certaines
spécifications, comme le changement du moteur par exemple, ne posent pas
de problèmes.
5.3.4.4 Vérification fonctionnelle
Pour vérifier fonctionnellement le code VHDL, nous avons opté pour une
stratégie qui repose sur deux principes:
1. nous vérifions le système par morceau («divide and conquer»), c’est à
dire que nous vérifions d’abord les IP composant le système, puis le système lui-même.
2. nous optons pour la stratégie de comparaison de modèle, c’est à dire que
nous prenons le modèle fonctionnel sous MATLAB comme référence et
comparons les résultats intermédiaires pour une série de vecteurs de test
arbitraires.
131
Avec ce principe, nous avons pu vérifier le fonctionnement du système modélisé par VHDL sans apporter toutefois de preuve formelle.
Par contre, en recherchant les vecteurs d’entrée conduisant au temps de
calcul le plus long, nous avons vérifié que celui-ci n’était pas supérieur à 1000
périodes d’horloge.
5.3.4.5 Vérification temporelle
Pour ce test du système, nous avons développé des modèles VHDL temporels des convertisseurs analogique-digitaux, de la RAM et de la ROM, ces deux
derniers dispositifs n’étant pas synthétisés sous Synopsys, mais directement
sous Maxplus2.
Le modèle des CAN repose sur les spécifications données par Texas-Instruments
(cf. Fig. 5.14, p. 132) et convertit des signaux analogiques (valeurs réelles) en
données binaires.
Lors de la simulation, le modèle de la ROM lit un fichier de constantes
spécifiques de la commande (résistances, temps ...etc.) et génère le fichier des
mots binaires dans un format accepté par Maxplus2. Finalement, le modèle de
la RAM, lors de l’activation d’un signal, envoie son contenu vers un fichier.
F IG . 5.14 – Diagramme des signaux du TLC0831
5.3.4.6 Synthèse et placement/routage
Après la synthèse par Synopsys, le placement/routage s’est effectué sous
Maxplus2 d’Altera. La surface de l’ASIC est de 4480 LC 2 soit environ 89.000
portes logiques. La RAM et la ROM utilisent 2582 bits de l’espace mémoire
disponible, soit un équivalent de 322 octets. Le chemin critique estimé par Altera vaut 230 ns.
Les estimations de Synopsys donnaient 4239 LC soit une erreur d’estimation de 0.05%. Le tableau 5.1 résume les estimations de surface de Synopsys
pour l’ensemble des blocs de l’ASIC. Un fait notoire est l’importance relative
de la machine d’état globale de l’ASIC et la taille réduite du processeur CORDIC.
2. Logic Cells
132
Bloc
CORDIC
ALU
Machine d’état
Acquisition échantillons
Génération des impulsions de commande
surface (en LC)
1203
908
935
235
472
quota de surface occupé
28%
22%
21%
5%
11%
TAB . 5.1 – Estimations de surface post synthèse logique de Synopsys
5.3.4.7 Prototypage
Le prototypage s’effectue sur une carte imprimée que nous avons spécialement conçue à cet effet. Cette carte comprend un FPGA Flex10K100A d’Altera, l’ensemble des circuits analogiques pour l’acquisition des mesures et de
la consigne, les connecteurs et buffers pour la commande de l’onduleur, une
horloge à 50MHz et les circuits de configuration du Flex (cf. Fig 5.15). Notons
que le Flex10K100A est compatible pin à pin avec des dispositifs de la même
famille, mais de capacité différente, ce qui permet d’envisager de réutiliser le
schéma de la carte pour des dispositifs différents. Cette option est intéressante
dans l’optique de la méthodologie de conception mixte où le dispositif à utiliser peut du coup être défini après la synthèse logique.
5.4 Résultats des test expérimentaux
Actuellement, seule la MLI vectorielle commandée par un algorithme de
contrôle V/f a pu être testée. Cet algorithme génère la consigne de la MLI en
boucle ouverte. L’intégration de la MLI et du contrôle V/f a été effectuée en
utilisant les mêmes ressources matérielles et la même architecture que l’ASIC
de commande vectorielle. Seule la machine d’état globale diffère.
Grâce à ces tests, nous avons pu montrer le fonctionnement correct des
blocs fonctionnels (CORDIC, ALU, acquisition des échantillons ...etc.) et de
l’architecture. Nous avons pu vérifier également que les estimations de chemin
critique étaient correctes puisque l’ASIC fonctionne avec une période d’horloge de 320ns.
Sur les figures 5.16 et 5.17 on peut voir la mesure des deux signaux de commande d’un bras de l’onduleur (signaux complémentaires) ainsi que le temps
mort donné par rapport au nombre de périodes d’horloge (10 périodes).
Pour vérifier que l’onduleur était commandé correctement, nous avons filtré la tension de sortie de l’onduleur par un filtre RC avec une fréquence de
coupure de 1KHz. Le courant filtré à 50Hz, mesuré sur la résistance (1M), est
donné figure 5.18. Remarquons que les tests avec l’onduleur on été effectués
sous une tension réduite pour prévenir les risques de claquage des IGBT en
cas de court-circuit dû à un défaut de fonctionnement de l’ASIC. Cela explique
133
F IG . 5.15 – Synoptique de la carte de prototypage
134
6
6 bits
Circuit de mise
en forme
de la vitesse
Circuit de mise
en forme
et CAN
Circuit de mise
en forme
et CAN
Circuit de mise
en forme
et CAN
connecteur
PHA
PHB
PHB
PHA
Isq
Ib
Ia
connecteur
Buffers des
DB25
signaux de commande
0V
alim
12V
connecteur
Ib
Ia
SENS
TOP
Isq_m
Ib_m
Ia_m
2
3
5
6 bits
SENS
TOP
Isq_m
Ib_m
Ia_m
4
6
7
points de mesure
1
8
50 MHz
horloge
FLEX10KA
BP4
BP1
BP2
boutons poussoirs
banc de commutateurs
BP3
boutons poussoirs
Isq
J13
connecteur de
configuration
bitblaster
1
configuration
connecteur pour le
choix du type de
EEPROM ECP1
de configuration
potentiometre
F IG . 5.16 – Signaux de commande d’un bras de l’onduleur
F IG . 5.17 – Temps mort en fonction de la période d’horloge
135
la faible valeur du courant enregistré.
F IG . 5.18 – Courant à la sortie de l’onduleur, filtré à 50Hz
5.5 Conclusion
Les méthodologies de conception ayant été définies précédemment, nous
avons montré dans ce chapitre comment intégrer la commande vectorielle d’un
moteur asynchrone en nous basant sur ces méthodologies.
Après avoir rappelé les enjeux de l’intégration d’un système de commande,
nous avons appliqué les différentes étapes de la méthodologie de conception
spécifique à la commande en utilisant notamment les modèles et outils associés.
Grâce à la spécification fonctionnelle du système par le Grafcet, la plupart
des résultats des tâches de conception ne dépendent que des spécifications. De
ce fait, le même modèle Grafcet de la commande peut servir pour intégrer le
système vers différentes cibles technologiques.
Puis, en utilisant des blocs IP paramétrisés pour la réalisation de l’ASIC,
nous avons gagné en flexibilité d’intégration, un changement de certaines spécifications étant paramétrisé (largeur des chemins de données, constantes électriques du moteur ...etc.).
Les différentes simulations fonctionnelles nous ont permis de vérifier le
fonctionnement correct du systèmes et éliminer ainsi les erreurs de conception.
Puis, grâce au prototypage d’une commande V/f, la validation de certaines
fonctions a pu être assurée.
Afin de d’atteindre les objectifs fixés par la stratégie d’intégration (surface
inférieure à 100.000 portes logiques, chemin critique inférieur à 500ns, précision des calculs suffisante), nous avons étudié en détail l’algorithme CORDIC
136
et la multiplication itérative. Grâce à ces algorithmes, les objectifs ont pu être
atteints et la commande intégrée sur une surface réduite.
Finalement, le prototypage de la MLI alimentée par un algorithme V/f a
permis de valider les estimations de chemin critique et de temps de calcul,
ainsi que l’architecture choisie et les blocs IP utilisés.
137
138
Conclusion générale
L’objectif de la thèse était double: d’une part offrir au concepteur de la commande une méthodologie et des outils lui permettant une aide à l’intégration
de la commande et dans un deuxième temps¸ appliquer la méthodologie ainsi
obtenue à l’intégration d’une commande vectorielle de moteur asynchrone. Il
s’agissait en effet de:
– prendre en compte les contraintes de la mise en oeuvre dès la phase de
conception algorithmique.
– repousser les choix technologiques à un stade avancé de la conception
afin de garder une relative indépendance technologique.
– d’écourter le cycle de conception grâce à une automatisation partielle des
tâches.
Pour atteindre ces objectifs, nous avons procédé de la façon suivante:
– Nous avons analysé les techniques employées pour la mise en oeuvre
d’algorithmes de commande.
– Nous avons ensuite étudié l’état des techniques et outils employés en
microélectronique pour la conception des systèmes complexes.
– A partir des résultats précédents, nous avons alors proposé une méthode
spécifique à la mise en oeuvre des algorithmes de commande.
– Finalement¸ nous avons adapté le Grafcet aux contraintes de la conception de systèmes intégrés.
Dans le premier chapitre, nous avons décrit la chaîne d’entraînement et les caractéristiques physiques importantes pour le concepteur de l’intégration de la
commande. Nous avons notamment insisté sur les non-linéarités des dispositifs en vue d’établir le degré de précision des calculs qu’il faudra atteindre.
Nous avons également clairement établi les limites de notre étude en précisant le sens que nous donnons au concept de «commande» des machines AC.
En particulier, nous avons extrait les différents blocs fonctionnels et nous avons
précisé la tâche de chacun d’eux.
Dans le deuxième chapitre, nous avons analysé les méthodes actuelles pour
l’intégration d’algorithmes. Nous avons étudié dans un premier temps les méthodes classiques dont on expose les problèmes vis à vis des besoins actuels
139
et dans un deuxième temps¸ des méthodes plus avancées qui font l’objet de
nombreux travaux et qui visent à apporter des solutions aux insuffisances des
approches classiques.
Même si certains travaux portant sur l’intégration des algorithmes de commande des machines électriques ont présenti la nécessité d’aborder la conception autrement, leur approche ne permet pas de résoudre les problèmes évoqués. Ces travaux nous permettent néanmoins de mettre en évidence des spécificités de l’intégration de la commande dont il faudra tenir compte lors de
l’application d’une méthodologie d’implantation. On gardera ainsi à l’esprit
l’importance du choix de la fréquence de calcul du système, le problème de
l’arithmétique binaire à employer et du séquencement des opérations vis à vis
de la précision binaire, et finalement, l’intérêt qu’il peut y avoir à modifier l’algorithme de départ pour tenir compte de la réalisation physique.
Le concept de conception mixte par contre, aborde l’intégration d’une fonctionnalité (protocoles, algorithmes, fonctions logiques, ...etc.) de façon systématique. L’utilisation de modèles fonctionnels associés aux algorithmes pour
l’exploration des solutions de réalisation permet une conception plus flexible,
moins liée aux spécifications technologiques et budgétaires, et donc une conception plus réactive également. Les spécifications floues ne posent plus de problème puisqu’il devient possible d’affiner ces spécifications en fonction des
estimations sur les performances d’intégration. En ce qui concerne les outils
supportant la méthodologie de conception mixte, nous avons vu qu’un choix
important s’offre au concepteur, lui permettant de réaliser une grande partie
des tâches automatiquement.
La méthodologie de conception mixte étant trop complexe à appliquer dans
le cas général, nous avons donc proposé et étudié dans le troisième chapitre
une méthode spécifique à l’intégration des systèmes de commande.
Après avoir formalisé les problèmes liés à l’intégration de la commande,
et situé leur traitement dans la méthodologie, nous avons proposé des solutions théoriques pour les résoudre. Nous avons également défini des restrictions au champ d’application de la méthode afin de limiter la complexité des
problèmes traités. Nous définissons en particulier l’architecture des systèmes
de commande que nous utilisons.
La méthodologie étant définie¸ nous avons proposé et étudié dans le cinquième chapitre une solution de mise en oeuvre de cette méthodologie en utilisant comme outil de modélisation le Grafcet.
En effet¸bien que le Grafcet présente des caractéristiques intéressantes¸il
reste inadapté à la conception des systèmes intégrés. Nous avons donc proposé
des ajouts à la sémantique en vigueur et modifié les règles et hypothèses de
fonctionnement. Nous avons développé des règles et des techniques d’analyse
du Grafcet permettant au concepteur de la commande de baser ses décisions
sur des critères objectifs tels que les estimations de performances. L’analyse architecturale revêt une importance particulière dans la mesure où elle permet
au concepteur d’étudier les implications physiques du modèle et donc de le
modifier en conséquence.
140
La méthodologie d’intégration étant établie¸ et dans un soucis de validation¸
nous avons achevé notre étude par la mise en oeuvre d’une commande vectorielle de moteur asynchrone sous forme d’ASIC.
En suivant les étapes de la méthodologie, nous avons pu montrer l’efficacité de celle-ci à résoudre des problèmes tels que la précision binaire ou les
spécifications floues. En utilisant des IP génériques paramétrisés, nous avons
pu notamment accéder une certaine flexibilité dans la définition des constantes
caractéristiques de l’ASIC.
Au niveau de l’étude des solutions d’intégration, nous avons étudié en détail l’algorithme CORDIC comme solution algorithmique au calcul de certaines
fonctions mathématiques, le CORDIC étant particulièrement intéressant par
rapport aux contraintes de surface.
Finalement, nous montrons les résultats de quelques tests expérimentaux
sur le prototype de la fonction de génération des impulsions MLI. Cette fonction utilisant les mêmes ressources matérielles que l’ASIC de commande complet, le test du prototype permet de juger des prestations et du fonctionnement
de l’architecture. Réalisé sur une carte spécifique, le prototype atteint les prestations espérées tant en terme de vitesse de calcul comme en surface occupée.
Bien que cette étude nous a permis de valider en partie notre approche¸
nous pensons que certaines étapes de la méthodologie ne sont pas suffisamment exploitées lors de l’intégration de la commande vectorielle. En effet¸ les
algorithmes de partitionnement¸ de validation fonctionnelle et d’estimation de
performances proposés ne permettent pas de traiter des fonctions complexes.
Sur ces points¸ des développements algorithmiques sont prévisibles ultérieurement.
Par ailleurs¸ l’automatisation de la majeur partie des tâches est à envisager
afin de minimiser le risque d’erreur¸ augmenter la capacité de traitement des
systèmes complexes et diminuer les délais de développement.
141
142
Bibliographie
[1] A. Kalavade, E. A. Lee. A Hardware/Software Codesign Methodology
for DSP applications. [On-line]. IEEE Design and Test of Computers,
Sept. 1993, p. 16–28. [16/9/1998] Available from Internet: <URL :
http://ptolemy.berkeley.edu/papers/publications.html/index.html>.
58
[2] A. Barancourt. Automate de commande rapprochée multi-machines: essai d’intégration au sein de LCA. Thèse Doct. Ing. : Institut National Polytechnique
de Toulouse, 1989. 187 p. 44
[3] G. Berry.
Proof, Language and Interaction: Essays in Honour of Robin Milner. [On-line]. Cambridge (USA) : MIT Press, 1998. The
Foundations of Esterel.
[26/10/98] Available from internet:<URL:
http://www.inria.fr/meije/esterel. 62, 73, 96
[4] J. Chatelain. Machines électriques, Tome 2. Paris : Dunod, 1983. 302 p. 30,
35, 152
[5] D. Gajski, F. Vahid, S. Narayan. Specification and design of embedded hardware-software systems. IEEE Design and Test of Computers, 1995,
vol 12, n 1, p. 53–67. 46, 54
[6] D. Gajski, F. Vahid, S. Narayan, J. Gong. Specification and design of embedded systems. Englewood Cliffs (USA) : Prentice-Hall, 1994. 468 p. 46,
51
[7] D. Gajski, F. Vahid, S. Narayan, J. Gong. Specification and design of embedded systems. Englewood Cliffs (USA) : Prentice-Hall, 1994. System partitioning, p. 187–201. 52
[8] D. Harel, A. Naamad.
The STATEMATE semantics of Statecharts.
[On-line].
ACM trans. Soft. Eng. Method., Oct. 1996,
[26/10/98] Available from internet:<URL:
vol 5, n 4 non paginé.
http://cui.unige.ch/eao/www/Visual/statecharts.html. 100
[9] R. David. Du Grafcet aux réseaux de Pétri. Paris : Hermes, 1989. 425 p. 92
[10] E. Monmasson, J.C. Hapiot, M. Grandpierre. A digital control system
based on field programmable gate array for AC drives. EPE journal, Nov
1993, vol 3, n 4, p. 227–234. 44, 65
[11] J.M. Bergé (Ed). Hardware/Software Co-Design and Co-Verification. Boston :
Kluwer Academic Publishers, 1997. 165 p. 46
143
[12] E.A. Lee et al.
The Almagest: Ptolemy 0.7 user’s manual, volume 1.
[On-line].
Berkeley : University of California,
1997.
non paginé.
[16.10.98] Available from internet:<URL:
http://ptolemy.berkeley.edu/papers/publications.html/index.html.
57, 61, 73
[13] P. Robert et al. Le Petit Robert, Dictionnaire alphabétique et analogique de la
langue française. Paris : Le Robert, 1984. 2171 p. 147
[14] F. Aubépart, C. Girerd, Y.A. Chapuis, P. Poure, F. Braun. ASIC implementation of direct torque control for induction machine: functionnal validation by power and control simulation. Münschen (d) : PCIM conference,
1998. p. 251–260. 45
[15] F. Balarin, L. Lavagno, A. Sangiovanni-Vincentelli et al. HardwareSoftware Co-Design of embedded systems. Boston : Kluwer Academic Publishers, 1997. 289 p. 46, 51, 57
[16] F. Balarin, L. Lavagno, A. Sangiovanni-Vincentelli et al. HardwareSoftware Co-Design of embedded systems. Boston : Kluwer Academic Publishers, 1997. Models and representations, p. 37–134. 49
[17] F. Balarin, L. Lavagno, A. Sangiovanni-Vincentelli et al. HardwareSoftware Co-Design of embedded systems. Boston : Kluwer Academic Publishers, 1997. Interface synthesis and real-time operating system, p. 159–
203. 52
[18] F. Balarin, L. Lavagno, A. Sangiovanni-Vincentelli et al. HardwareSoftware Co-Design of embedded systems. Boston : Kluwer Academic Publishers, 1997. Synthesis, p. 134–1597. 55
[19] G. De Micheli, A. Sangiovanni-Vincentelli, P. Antognetti. Design System
for VLSI circuits - Logic synthesis and silicon compilation. Boston : Kluwer
Academic Publishers, 1987. 654 p. 40
[20] G.L. Haviland, A. Tuszynski. A CORDIC arithmetic processor chip. IEEE
Transactions On Computers, feb. 1980, vol C-29, n 2, p. 68–79. 183
[21] H. Kellermann, P. Hildinger, G. Brandenburg and J. Heinzl. Field oriented position control of a hybrid stepper motor. Sevilla (sp) : EPE conference, 1995. vol 3, p. 3.908–3.913. 43
[22] D. Harel. Statecharts: a visual formalism for complex systems. Science of
computer programming, 1987, n 8, p. 231–274. 99
[23] J. Holtz. Pulsewidth modulation: a survey. Toledo (sp) : Power Electronics
Specialists Conference (PESC), 1992. vol 1, p. 11–18. 35
[24] J. Cortadella, M. Kishinevsky, A. Kondratyev, L. Lavagno, A. Yakovlev.
Petrify: a tool for manipulating concurrent specifications and synthesis of
asynchronous controllers. IEICE trans. on Information and Systems, March
1997, vol E80-D, n 3, p. 315–325. 92
[25] J. Hennessy, D. Patterson. Computer organization and design. The Hardware/software interface. San Francisco (USA) : Morgan Kaufmann Publishers, 1994. Chapter 4, p. 261–263. 58
144
[26] J.E. Fletcher, B.W. Williams, T.C. Green. DSP control of a synchronous
reluctance motor. Sevilla (sp) : EPE conf., 1995. vol 1, p. 1.480–1.485. 43
[27] J.M. Daveau, G.F. Marchioro, T. Ben-Ismail, A.A. Jerraya. Cosmos:
an SDL based hardware/software codesign environment. In Hardware/Software Co-Design and Co-Verification. Boston : Kluwer Academic
Publishers, 1997. p. 59–87. 57
[28] J.M. Proth, X. Xiaolan. Les réseaux de Pétri pour la conception et la gestion des
systèmes de production. Paris : Masson, 1995. 304 p. 92
[29] J.M. Retif, B. Allard. A PWM ASIC using stochastic coding. Toledo (sp) :
IEEE PESC conference, 1992. p. 587–594. 43
[30] J.M. Retif, B. Allard, X. Jorda, A. Perez. Use of ASIC’s in PWM techniques
for power converters. Hawaii (USA) : IEEE IECON conference, 1993. vol
2, p. 683–688. 44, 65, 72
[31] X. Jordà. Conception et réalisation d’une commande économique de couple d’une
machine asynchrone pour la traction électrique. Thèse Doct. Ing. : Institut
National de Sciences Appliquées de Lyon, 1995. 221 p. 46, 65, 151
[32] K. Kota, J. R. Cavallaro. Numerical accuracy and harware tradeoffs for
CORDIC arithmetic for special-purpose processors. IEEE Transaction on
Computers, July 1993, vol 42, n 7, p. 769–779. 179
[33] A. Kalavade. System-level codesign of mixed hardware-software systems.
[On-line]. PhD thesis : University of California, Dept. of EECS, Berkeley, Sept. 1995. 194 p. [16/9/1998] Available from Internet: <URL :
http://ptolemy.berkeley.edu/papers/publications.html/index.html>.
46, 51, 53, 61
[34] P. Lautier. Modélisation des convertisseurs à découpage pour la conception et la
commande: application à l’onduleur. Thèse Doct. Ing. : Institut National des
Sciences Appliquées de Lyon, 1998. 175 p. 30
[35] W. Leonhard. Control of electrical drives. 2nd edition. Berlin : Springer
Verlag, 1996. 420 p. 26, 35, 151
[36] W. Leonhard. Control of electrical drives. Berlin : Springer Verlag, 1996.
Control of Induction Motor Drives, p. 229–287. 44, 46
[37] E. Monmasson. Architecture de dispositifs de commande numérique. Thèse
Doct. Ing. : Institut National Polytechnique de Toulouse, 1993. 174 p. 44,
65, 72, 74
[38] E. Monmasson. Architecture de dispositifs de commande numérique. Thèse
Doct. Ing. : Institut National Polytechnique de Toulouse, 1993. p. 147–151.
Annexe A. 46
[39] N. Halbwachs, P. Caspi, D. Pilaud. The synchronous dataflow programming language Lustre. Another Look at Real Time Programming, Proceedings
of the IEEE, Sept. 1991, vol Special Issue, non paginé. 99
[40] N. Mohan, T.M. Undeland, W.P. Robbins. Power electronics: converters,
applications and design. New York : John Wiley & Sons, 1989. 667 p. 26
[41] N.H.E. Weste, K. Eshraghian. Principles of CMOS VLSI design, a system
perspective. New-York : Addison-Wesley, 1993. 713 p. 40
145
[42] P. Borne, G. Dauphin-Tanguy, J.P. Richard, F. Rotella, I. Zambettakis.
Analyse et régulation des processus industriels. Paris : Technips, 1993. 313 p.
171
[43] P. Foussier, J.P. Chante, X. Jordà, J. Carrabina. Methodologies in the design of an ASIC for AC drive control. Toledo (sp) : VHDL Users’s Forum
in Europe, 1997. p. 51–60. 65
[44] P. Le Guernic, M. Le Borgne, T. Gauthier, C. Le Maire. Programming real
time applications with Signal. Proceedings of the IEEE, Sept. 1991, vol 79,
n 9, p. 1305–1320. 99
[45] P. Naish, P. Bishop. Conception des ASICs. Paris : Masson, 1990. 176 p. 40
[46] R. Aireau, J.-M- Bergé, V. Olive, J. Rouillard. VHDL, du language à la
modélisation. First edition. Lausanne : Presses polytechniques et universitaires Romanes, 1990. 553 p. 95
[47] R. Gupta, G. DeMicheli. Partitioning of functional models of synchronous digital systems. In Proc. Int’l Conf. Computer-Aided Design. New-York,
USA : IEEE CS Press, 1990. p. 216–219. 54
[48] M. Richard. Réseaux de Pétri, Grafcet, Automates. Villeurbanne (fr) : INSA
de Lyon, 1988. 142 p. Cours de Génie Electrique. 92
[49] J.M. Rétif. Systèmes asservis échantillonnés. Villeurbanne (fr) : Institut National de Sciences Appliquées, 1996. 142 p. Cours de Génie Electrique.
195
[50] S.-F. Hsiao, J.-M. Delosme. Householder CORDIC algorithm. IEEE Transactions On Computers, Aug. 1995, vol 44, n 8, p. 990–1000. 183
[51] S. Kleinfelft, M. Guiney, J.K. Miller, M. Barnes. Design methodology
management. Proc. of the IEEE, Feb. 1994, vol 82, n 2, p. 231–250. 61
[52] S. Kumar, J.H. Aylor, B.W. Johson, Wm.A. Wulf. The codesign of embedded
systems, A unified Hardware/Software representation. Boston : Kluwer Academic Publishers, 1996. 274 p. 46
[53] S. Kumar, J. Aylor, B.W. Johson, Wm.A. Wulf, R.D. Williams. A model
for exploring hardware/software trade-offs and evaluating design alternatives. In Hardware/Software Co-Design and Co-Verification. Boston : Kluwer Academic Publishers, 1997. p. 1–21. 52, 107
[54] J.P. Uyemura. Circuit Design for CMOS VLSI. Boston : Kluwer Academic
Publishers, 1991. 480 p. 40
[55] J. E. Volder. The CORDIC trigonometric computing technique. IRE Transactions on Electronic Computers, Sept. 1959, n EC-8, p. 330–334. 177
[56] J.S. Walther. The unified algorithm for elementary functions. sine loco :
AFIPS Spring Joint Computing Conf., 1971. vol 38, p. 379–385. 181
[57] Y.Y. Tzou, H.J. Hsu. FPGA realization of space-vector PWM control IC
for three-phase PWM inverters. IEEE trans. on Power Electronics, nov 1997,
vol 12, n 6, p. 953–963. 43, 72
146
Annexe A
Définitions
Les termes suivants comportent deux définitions. La première correspond
à la définition du Petit Robert [13] dans son acceptation courante, la seconde
correspond au sens précis qui lui est donné dans cette thèse.
«algorithme»
1. Ensemble des règles opératoires propres à un calcul - Calcul, enchaînement des actions nécessaires à l’accomplissement d’une tâche.
2. Séquence d’opérations logiques ou arithmétiques.
«cible (target)»
1. Objectif visé.
2. Technologie à employer, c’est à dire un circuit intégré spécifique (ASIC 1
précaractérisé ou FPGA 2 ) ou un processeur standard (processeur classique, DSP 3 , microcontroleur).
«fonctionnalité»
Rôle général d’un élément. Une fonctionnalité est pour nous un terme générique pour désigner un ensemble de tâches, algorithmes et fonctions que doit
réaliser un circuit pour obtenir le fonctionnement souhaité. Une fonctionnalité
est par exemple un circuit de reconnaissance de formes. Un tel circuit doit intégrer non seulement l’algorithme de traitement de l’image, mais aussi toutes
les fonctions nécessaires à son intégration dans l’environnement envisagé (protocoles de communication, fonctions analogiques ...etc.) et éventuellement des
fonctions de surveillance et des machines d’état.
«implanter, intégrer»
1. Application Specific Integrated Circuit
2. Field Programable Gate Array
3. Digital Signal Processor
147
1. (Intégrer:) faire entrer dans un ensemble en tant que partie intégrante,
(implanter:) introduire et faire se développer d’une manière durable dans
(un nouveau milieu).
2. Action de réaliser une fonction donnée sous forme de circuit intégré autonome (matériel/ASIC ou logiciel/processeur)
«logiciel (software)»
1. techn. ensemble des travaux de logique, d’analyse, de programmation,
nécessaires au bon fonctionnement d’un ensemble de traitement de l’information (opposé à matériel). Recomm. offic. pour Software.
2. Par intégration logiciel, on se réfère au programme assembleur exécuté
par un processeur et par extension au processeur lui-même (processeur
classique, DSP, microcontroleur).
Remarque: dans la suite de ce document, nous employons le terme «logiciel»
comme nom propre. Le lecteur ne s’étonnera donc pas lorsque nous n’effectuons pas l’accord avec le terme auquel il se réfère (p.e. cible logiciel)...
«matériel (hardware)»
Par intégration matériel, on comprend une technologie circuit intégré spécifique (ASIC précaractérisé ou FPGA).
Même remarque que pour le terme «logiciel».
«méthode ou méthodologie»
1. Ensemble de démarches raisonnées, suivies, pour parvenir à un but.
2. Ensemble de tâches ordonnées et d’algorithmes que le concepteur doit
réaliser et appliquer pour parvenir à mettre en oeuvre une fonctionnalité
donnée.
«migration technologique»
Transfert d’une fonction intégrée ou prévue pour être intégrée avec une technologie (matériel ou logiciel) vers une autre technologie.
«mise en oeuvre d’une fonctionnalité»
Selon nous, la mise en oeuvre d’une fonctionnalité correspond à son intégration
sur silicium (sous forme matériel/ASIC ou logiciel/processeur) et à la conception de la carte comprenant l’ensemble des circuits analogiques et digitaux nécessaires à la connection de celle-ci avec l’environnement dans lequel elle doit
opérer.
«partitionnement»
Répartition des noeuds de la fonctionnalité entre le matériel et le logiciel.
«système»
148
1. (Robert): Appareil plus ou moins complexe, ensemble structuré (de choses
abstraites)
«valider»
1. Valide: qui présente les conditions requises pour produire son effet.
2. Certifier que le système fonctionne quelles que soient les entrées ou les
conditions physiques d’utilisation.
«vérifier»
1. Examiner (une chose) de manière à pouvoir établir si elle est conforme à
ce qu’elle doit être, si elle fonctionne correctement.
2. S’assurer que dans des cas précis et définis, le système fonctionne correctement.
149
150
Annexe B
Exemple de commande
vectorielle
Dans cette annexe, nous présentons un exemple de commande vectorielle
d’un moteur AC asynchrone que nous avons utilisé tout au long de la thèse.
Les développements algorithmiques de cette annexe reposent sur les résultats
exposés par X. Jordà dans [31] et par W. Leonhard [35].
Ainsi que nous l’avons déjà précisé dans le premier chapitre, l’algorithme
de commande est divisé en deux parties indépendantes, le contrôle et la MLI.
Dans notre exemple, la commande comporte un contrôle vectoriel et une MLI
vectorielle. Remarquons au passage que la stratégie MLI utilisée est complètement indépendante du contrôle. Nous aurions tout aussi bien pu utiliser une
MLI intersective ou précalculée, couplée au contrôle vectoriel.
Nous présenterons donc le contrôle et la MLI séparément.
B.1 Le contrôle vectoriel
Le problème du moteur asynchrone est qu’il n’est pas possible de contrôler
directement le flux et le couple à partir des courants d’alimentation comme
c’est le cas pour les moteurs DC à excitation séparée. En effet, en alimentant
les bobinages du stator, les courants de ligne de la machine asynchrone créent
un champ tournant qui induit des courants dans le rotor en court-circuit. Ces
courants à leur tour créent un champ dans l’entrefer de la machine qui, en
s’ajoutant au champ tournant du stator forme le flux tournant de la machine.
A partir des travaux, dans les années 30, de Park et Kron qui développèrent
un modèle dynamique de la machine asynchrone, les électrotechniciens imaginèrent d’appliquer des transformations mathématiques aux courants de ligne
pour extraire des variables permettant de contrôler indépendamment le couple
et le flux. Cette technique de contrôle, appelée par la suite “contrôle vectoriel”,
revient en fait à transformer la machine asynchrone AC en une machine DC
151
à excitation séparée équivalente pour laquelle les techniques de contrôle sont
bien connues.
La base du contrôle vectoriel est donc ce modèle dynamique de la machine
asynchrone que nous allons étudier maintenant.
B.1.1 Le modèle de la machine asynchrone
B.1.1.1 La transformation de Concordia
Le modèle repose sur l’hypothèse que toute machine tournante peut être ramenée à une machine primitive caractérisée par des enroulements fictifs pseudostationnaires [4].
Les équations de tension des phases rotoriques et statoriques s’écrivent
pour le stator:
&
&
&
)
)
( )
( ( et pour le rotor:
&
&
&
)
)
( )
( ( ce qui peut se résumer sous forme matricielle par:
& ( ( ) ) avec
[& ]
[ ]
[ ]
[) ]
[) ]
: tensions instantanées des phases a, b et c statoriques.
: courants instantanés des phases a, b et c statoriques.
: courants instantanés des phases A, B et C rotoriques.
: flux totaux à travers les phases a, b et c statoriques.
: flux totaux à travers les phases A, B et C rotoriques.
152
( et (
: respectivement les résistances totales d’une phase statorique et
d’une phase rotorique.
Quant aux flux magnétiques traversant chaque phase statorique et rotorique,
ils sont décrits par:
) ) * + * + avec
, , ,
* , , , , , ,
, , ,
* , , , , , ,
+ , + + et
, et ,
, et ,
,
: respectivement les inductances propres d’une phase statorique et
d’une phase rotorique.
: respectivement les inductances mutuelles entre deux phases statoriques et entre deux phases rotoriques.
: valeur maximale de l’inductance mutuelle entre phases rotoriques
et statoriques.
: angle de rotation du moteur mesuré entre l’axe magnétique de la
phase statorique a et de la phase rotorique A.
En raisonnant sur ces équations de tension des phases rotoriques et statoriques
ainsi que sur l’expression des flux magnétiques qui traversent ces phases, on
obtient les équations matricielles des tensions de phase:
* + (B.1)
( * + (B.2)
& ( Ces équations présentent deux inconvénients majeurs:
1. un nombre important de variables couplées entre elles
153
2. la dépendance des matrices + et + de l’angle de rotation mécanique Pour palier à ce problème, on recherche des transformations linéaires des variables triphasées de la machine permettant de passer du repère triphasé de la
machine réelle à un repère triphasé fixe par rapport au stator ou au rotor.
Dans le cas des variables statoriques, on va passer d’un repère abc avec des
axes espacés de à un repère orthogonal fixe par rapport au stator. La
transformation repose sur l’équivalence magnétique du système dans les deux
repères. En posant que l’axe a coïncide avec l’axe , on détermine la transformation suivante, aussi appelée transformation de Concordia:
- avec - pouvant prendre les valeurs
-
Remarquons qu’avec - , les valeurs crêtes et efficaces des variables de
phase sont identiques dans les deux repères. Remarquons aussi que pour que
la puissance instantanée soit invariante, il faut que T soit orthogonale, c’est à
.
dire
Dans le cas des variables rotoriques, on raisonne de la même manière. La
transformation de Concordia appliquée aux variables rotoriques permet de
passer du repère abc à un repère xyo, solidaire avec le rotor (c’est à dire un repère tournant à la vitesse de rotation du moteur). Si on désire exprimer ces variables rotoriques triphasées dans le repère , il faut leur appliquer la transformation de Concordia puis une rotation d’angle . On remarquera que les
coordonnées selon l’axe o restent inchangées durant la rotation car cet axe (dit
homopolaire) est commun aux repères et xyo. L’expression de la rotation
pour un vecteur z quelconque est:
'
' '
'
' '
B.1.1.2 Nouvelles équations électriques dans le repère
En appliquant les transformations que nous avons décrites (Concordia aux
variables statoriques et Concordia plus la rotation aux variables rotoriques), on
obtient de nouvelles équations électriques du moteur selon le repère :
154
&
( *
&
( *
&
( *
&
( *
*
*
*
*
&
( *
&
( *
)
)
)
)
* * * * * * * * * . * . * . * . avec
*
*
*
*
.
, ,
, ,
,
, ,
et
& , & , & : tensions des trois enroulements statoriques
& , & , & : tensions des trois enroulements rotoriques
, , : courants des trois enroulements rotoriques
*
: inductance propre cyclique rotorique
*
: inductance propre cyclique statorique
*
: inductance mutuelle cyclique entre rotor et stator
*
: inductance propre de l’enroulement homopolaire
Avec les équations ci-dessus, on remarquera que:
– les paramètres des équations différentielles ne dépendent plus de la position relative entre stator et rotor.
155
– la dynamique selon l’axe homopolaire est découplée de celle des autres
axes. Les composantes homopolaires sont d’ailleurs très souvent nulles
(par exemple pour un stator branché en étoile, et ).
Il suffit alors d’étudier les équations selon les axes . C’est pour cette raison qu’on appelle souvent la transformation de Concordia, transformation
3/2 puisqu’elle permet le passage d’un système triphasé vers un système
biphasé équivalent (les composantes homopolaires étant négligées).
L’expression du couple électromagnétique est quant à elle extraite d’une étude
sur la puissance électrique totale instantanée dans la machine. En admettant
que les variables homopolaires sont nulles (la machine est dite équilibrée), on
obtient l’expression générale du couple:
- /* où p est le nombre de paires de pôles électriques du moteur.
B.1.1.3 La transformation de Park
Alors que la transformation de Concordia permettait d’exprimer le modèle
du moteur dans un repère fixe par rapport au stator, nous verrons en B.1.2.1,
p. 159, qu’il peut être plus intéressant, pour les besoins du contrôle, d’exprimer
ce modèle dans un repère tournant à la vitesse de synchronisme . , appelé repère . Nous avons déjà indiqué succinctement en 1.2.1.2 que cette vitesse était
définie à partir de la fréquence des tensions d’alimentation et qu’elle était liée
à la vitesse de rotation maximale que le moteur n’atteignait jamais en raison
du couple résistant qui s’exerce sur l’axe du rotor (au minimum, la résistance
due aux frottements si le moteur tourne à vide).
Pour calculer le modèle du moteur dans le repère , il faut appliquer la
transformation de Concordia aux variables statoriques et rotoriques, puis leur
appliquer une rotation d’angle pour les variables statoriques, et d’angle pour les variables rotoriques.
La combinaison matricielle de la transformation de Concordia et de la rotation constitue la transformation de Park:
'
' - '
' ' '
' '
B.1.1.4 Le modèle de Park
En appliquant la transformation de Park aux équations électriques du moteur et en négligeant les composantes homopolaires, on obtient les équations
156
de la machine dans le repère . On rappelle que l’angle de la transformation
vaut pour les variables rotoriques:
&
( *
&
( *
&
( *
&
( *
)
)
)
)
*
*
*
*
* * * * * * * * - /* * . * . * . * . * . * . * . * . L’ensemble de ces équations constituent ce qu’on appelle aussi le modèle de
Park du moteur à induction.
B.1.1.5 Équations mécaniques
Un dernier point indispensable de la modélisation du moteur asynchrone
est l’équation mécanique de la machine qui en décrit le mouvement. Cette
équation s’écrit:
0
.
/
avec
0
: inertie totale des parties mobiles
: vitesse mécanique de rotation
: couple électromagnétique de la machine
: couple de charge (éventuellement nul)
: couple résistant de frottement (dû à plusieurs composantes, frottement sec, statique, fluide et avec l’air)
: coefficient de frottement fluide
157
B.1.1.6 Le modèle à quatre paramètres
Jusqu’à présent, nous avons développé les équations théoriques du moteur
asynchrone. Mais, ces équations ne sont d’aucune utilité si nous ne sommes
pas en mesure d’identifier les paramètres de ces équations, c’est à dire de déterminer concrètement la valeur de grandeurs telles que la résistance rotorique
( , statorique ( , les inductances ...etc. Or, non seulement cette identification
de paramètres est complexe, mais en plus, ces paramètres varient lors du fonctionnement de la machine si bien qu’il sera nécessaire d’introduire une procédure d’identification en ligne dans l’algorithme de commande. Pour faciliter la tâche d’identification, on effectue des hypothèses simplificatrices sur les
fuites magnétiques au niveau des circuits rotoriques et statoriques. En fait, on
va ramener l’ensemble des fuites du côté du stator ce qui permet de réduire le
nombre de paramètres indépendants (du modèle) à quatre.
Ainsi, si on associe respectivement les inductances * et * aux flux de
fuite du stator et du rotor, on considère que * si bien que l’inductance de
fuite vaut * * . Or on avait les équations sur les inductances suivantes:
*
*
* *
* *
qui deviennent avec les hypothèses simplificatrices:
*
*
*
* *
Dans le repère dq, les équations électriques du moteur deviennent alors simplement:
) )
.
(
.
(
.
&
&
/ ) ) . ) )
(B.3)
(B.4)
avec
158
*
(
(B.5)
-
B.1.2 La commande par flux rotorique orienté
Historiquement, l’algorithme étudié par Jordà et que nous présentons ici
devait servir à la commande d’un moteur électrique pour la traction d’un petit
véhicule urbain. Pour cette raison, la stratégie de contrôle adoptée comporte
uniquement un contrôle du couple de la machine. On suppose que le contrôle
de vitesse est effectué par le conducteur de la voiture avec la pédale d’accélération et la pédale de frein.
B.1.2.1 Mise en équation du contrôle
On se rappelle que le but de la modélisation du moteur asynchrone, présentée dans la section précédente, est de permettre un découplage de la commande
du flux et du couple comme c’est le cas naturellement dans la machine DC à
excitation séparée.
Pour obtenir ce résultat sur le moteur asynchrone, l’idée de la commande
vectorielle est de contrôler le courant statorique dans un repère dq tournant à
la vitesse de synchronisme (qui n’est pas, on le rappelle, la vitesse de rotation
mécanique). En calant l’axe d sur le vecteur de flux, on contrôlera directement
le flux par la composante d du courant statorique et le couple par la composante
q. La composante d jouera donc le rôle de courant d’excitation et la composante
q celui de courant d’induit.
Les équations qui lient le flux, le couple et le courant statorique découlent
du modèle de Park à quatre paramètres présenté en B.1.1.6. En effet, choisir un
repère dq tournant à . et calé sur le flux rotorique revient à poser que ) )
et ) .
De ce fait, les équations B.3 et B.4 se simplifient et deviennent:
.
( (
. *
( (
. *
)
*
/* (
) &
* *
*
.
) &
*
*
(B.6)
(B.7)
(B.8)
(B.9)
(B.10)
(B.11)
où est la constante rotorique comme définie en B.5 et est le courant
magnétisant, proportionnel au flux rotorique ) .
159
En analysant les équations précédentes, on peut observer les points suivants:
– Les équations B.8 et B.9 définissent une relation permettant de contrôler
le flux par la composante du courant statorique.
– A flux constant, le couple dépend uniquement des variations de (équation B.11).
– La relation entre tension statorique (& & ) et courant statorique ( )
est donnée par les équations B.6 et B.7.
On voit que l’effet recherché a été obtenu avec un découplage du contrôle de
flux et de couple. On peut donc maintenant appliquer les techniques classiques
de contrôle.
B.1.2.2 Le schéma de contrôle
Dans la stratégie de contrôle choisie, nous régulons les composantes et
du courant statorique. Pour cela, on utilise les fonctions de transfert suivantes, tirées des équations B.6 à B.10:
( (
( (
( (
( (
& * . . * & 1 & * . ( (B.12)
& 1 (B.13)
(B.14)
Comme on peut le constater avec les équations B.12 et B.13, les composantes
et se déterminent à partir de la composante de la tension statorique qui
leur est associée et d’un terme de couplage entre les axes d et q. On estime
toutefois que ces termes de couplage 1 et 1 peuvent être compensés.
On obtient alors en figure B.1 un schéma de commande de la machine
asynchrone qui néglige le retard d’application de la commande (une période
d’échantillonnage) et les retards introduits par l’onduleur (de l’ordre de la microseconde). On suppose également que l’orientation de l’axe d en fonction du
flux ) est parfaite.
B.1.2.3 Les régulateurs
Le schéma de commande comporte trois boucles de régulations pour ,
, et . Dans les trois cas, la fonction de transfert du processus continu est
160
F IG . B.1 – commande de la machine asynchrone dans le repère du premier ordre. Nous utiliserons des régulateurs du type proportionnel intégral (PI). La figure B.2 montre la transformée en Z avec un bloqueur d’ordre
zéro d’une boucle de régulation d’un processus du premier ordre continu de
gain K et de constante de temps 2 . Dans le tableau B.1, nous résumons les
valeurs de ces constantes pour les trois boucles de régulation de la commande.
F IG . B.2 – Transformée en Z d’un processus du premier ordre régulé par un PI
Le gain A et le pôle P du processus échantillonné par un bloqueur d’ordre
zéro sont liés à K, 2 et (où est la période d’échantillonnage) par les
expressions suivantes:
-
3
2
2
La fonction de transfert du processus régulé est du deuxième ordre. Le calcul du gain G et du zéro L est effectué tel que la réponse dynamique ait une
pulsation propre . et un amortissement 4 donné. L’expression des pôles en
boucle fermée sur le plan z (1 56 ) pour 4 vaut:
161
-
1
2
TAB . B.1 – Valeur du gain K et de la constante de temps 2 pour les trois boucles de
régulation de courant
1
6
.4 .
.4 .
4
4
Avec cette expression des pôles, on identifie les coefficients G et L:
7 * 3
3
1
1 6
7
B.1.2.4 L’orientation du repère dq
Comme nous l’avons déjà dit en B.1.2.1, p. 159, le repère dq est calé sur le
flux rotorique. En d’autres termes, l’angle entre l’axe d et l’axe , lié au stator,
vaut . Toute la stratégie de contrôle dépend du bon calage du repère dq, et
donc de la connaissance de l’angle .
Deux méthodes existent pour connaître cet angle:
1. soit la mesure directe d’une grandeur permettant le calcul direct de l’angle
(par exemple le flux ) par des capteurs à effet Hall)
2. soit l’estimation de l’angle à partir de l’équation B.10 du modèle orienté
et de la consigne de courant statorique.
Cette dernière solution est moins coûteuse en matériel et simple à mettre en
oeuvre. C’est la raison pour laquelle elle a été choisie dans cette commande.
Pratiquement, on calcule la vitesse de glissement à imposer à la machine en
fonction des consignes et :
.
162
et de la mesure de la vitesse mécanique, on calcule la pulsaA partir de .
tion statorique et donc aussi l’angle :
.
.
.
8 8
.
dépend directement de la constante de
Remarquons que le calcul de .
temps rotorique . C’est le principal inconvénient de cette méthode car une
variation de cette constante entraîne un désalignement du repère dq et donc un
recouplage entre le contrôle du flux et du couple, ce qui entraîne une erreur
stationnaire et des oscillations transitoires. Il est donc indispensable d’effectuer une estimation en ligne de , ce qui augmente la charge calculatoire de
l’algorithme de contrôle.
B.1.2.5 Estimation de
L’identification de repose sur la méthode dite de la puissance réactive
modifiée. Il s’agit en fait de comparer deux calculs différents de la puissance
réactive afin d’examiner si la constante rotorique est identique dans les deux
cas. Si la constante a varié, les deux calculs donneront des résultats différents.
Dans notre cas, nous calculons la puissance réactive à partir des mesures de
courant et tension, puis à partir des grandeurs de référence. L’écart entre les
deux calculs permettra d’estimer la valeur réelle de .
Dans un repère dq tournant à . , on calcule les puissance réactives par les
équations suivantes:
&
*
&
3
3
. * .
*
. * où 3 est la puissance réactive calculée à partir des grandeurs mesurées et
3 est la puissance réactive calculée à partir des grandeurs de référence.
L’écart entre ces deux puissances vaut:
3
) . .
* . On voit bien avec ces équations que si tend vers zéro, l’écart entre
les deux calculs de la puissance réactive devient nul. Pour estimer la valeur
réelle de , il faut donc effectuer les deux calculs de puissance réactive, calculer l’écart, intégrer cet écart et ajouter le résultat à la valeur nominale de la
constante de temps rotorique . Le schéma fig. B.3 reproduit cette stratégie
d’estimation de la constante de temps rotorique.
163
F IG . B.3 – Estimation de la constante de temps rotorique
B.2 La MLI vectorielle
Comme nous l’avons déjà dit, l’algorithme MLI sert à calculer les instants
de commutation des interrupteurs de l’onduleur qui alimente le moteur. Le
principe de la MLI vectorielle consiste à reconstruire le vecteur de tension sta& à partir de huit vecteurs de tension correspondant aux huit états
torique possibles de l’onduleur. Dans le paragraphe suivant, nous allons décrire l’algorithme employé pour calculer les instants de commutation et définir les grandeurs de référence que nécessite cet algorithme.
B.2.1 Description de l’algorithme
Figure B.4, nous représentons un onduleur idéal à trois bras, c’est à dire un
onduleur sans temps mort, retard de commutation ni distortion de la tension
de sortie. Pour un tel onduleur, il n’existe que huit configurations possibles
selon l’état de ses interrupteurs, ce qui correspond à huit combinaisons de tension entre ligne soit, dans le repère , huit vecteurs de tension statorique applicables au moteur. Le tableau B.2 résume ces combinaisons de tension. On
& dans le
remarquera au passage que & et & sont les deux composantes de plan complexe :
& & 5&
Sur la figure B.5, nous avons représenté les huit vecteurs de tension statorique dans le plan . On remarquera que deux des huit vecteurs (& et & ) sont
nuls. Quant aux six autres, ils définissent six secteurs angulaires de ! . Si on
repère ces secteurs par un indice entier , on peut exprimer les vecteurs par les
relations suivantes:
164
TAB . B.2 – combinaisons de vecteurs de tension d’un onduleur trois bras idéal, moteur
branché en triangle (F: fermé, O: ouvert)
165
F
F
F
F
F
O
O
F
O
F
O
O
O
O
O
F
F
O
F
O
F
O
F
O
0
0
0
0
0
0
0
0
0
0
0
0
&
&
&
0
0
0
0
&
0
0
&
0
! ! ! ! ! ! 0
&
&
&
&
&
&
&
&
&
nom
F IG . B.4 – Onduleur idéal a trois bras
&
&
&
&
9 9
5 9 9
5 (B.15)
(B.16)
(B.17)
(B.18)
Ces huit vecteurs de tension que nous avons définis correspondent à la tension statorique qu’on pourrait mesurer si les interrupteurs de l’onduleur restaient dans un état correspondant à un vecteur donné. Mais le but de la méthode est d’obtenir une tension statorique quelconque. Pour cela, nous allons
appliquer sur une période de commutation un vecteur & pendant un temps pendant un temps . De cette manière,
puis un vecteur &
en moyenne, on
peut obtenir n’importe quelle tension statorique désirée. Figure B.6 montre le
principe d’application. Le poids de chaque vecteur est en fait le rapport cyclique,
c’est à dire le rapport entre son temps d’application et la période de commutation:
2 (B.19)
est inférieure à
Si la somme des durées d’application des vecteurs & et &
( ), alors on complète la séquence par les vecteurs nuls. Le
& est donc une combinaison linéaire de vecteurs de base:
vecteur reconstitué 166
F IG . B.5 – Vecteurs de tension statorique dans le plan F IG . B.6 – Principe de construction du vecteur de tension statorique
167
2 & 2 & 2 &
& 2 &
(B.20)
Tout le problème est de calculer ces temps d’application et .
A partir des équations B.15 à B.20, on peut déduire les relations suivantes
qui vont nous permettre de calculer ces temps:
9
9 & &
9
9 & &
(B.21)
(B.22)
On voit que pour calculer et , on a besoin de connaître:
1. la tension statorique de référence & donnée par ses composantes & et
&
2. le secteur angulaire dans lequel se situe le vecteur statorique de référence
& , donné par l’indice 3. la période de commutation 4. la tension d’alimentation de l’onduleur Le vecteur statorique de référence & étant connu, on propose un algorithme
de recherche du secteur angulaire pour déterminer (cf. Fig. B.7).
F IG . B.7 – Algorithme pour déterminer le secteur angulaire
168
B.2.2 Calcul des instants de commutation
Une fois les durées d’application calculées, il faut déterminer les instants
de commutation des interrupteurs, le problème étant qu’il est possible de déterminer plusieurs séquences de commutations qui correspondent aux temps
calculés. Pour un même fondamental de sortie, chaque séquence produit des
harmoniques et des pertes en commutation différentes.
Dans notre exemple, nous utilisons une MLI continue avec des impulsions
centrées au milieu de la période de commutation. Ce type de modulation limite
le contenu harmonique des tensions générées.
La méthode pour déterminer les instants de commutation consiste à dis& et
tribuer le temps d’application du vecteur nul de façon identique entre & . On applique donc successivement & , puis des vecteurs non nuls, puis & ,
& . Les vecteurs non nuls sont deux vecteurs
puis des vecteurs non nuls, puis dont la durée d’application est répartie symétriquement
& et &
successifs autour du milieu de la période. Quant à l’ordre d’application de ces vecteurs,
on le détermine à partir du tableau B.2 et de la contrainte que l’interrupteur ne
doit pas commuter plus de deux fois durant la période de commutation pour
minimiser les pertes de l’onduleur. La figure B.8 représente ces séquences en
fonction du secteur angulaire où se trouve le vecteur de référence. A partir de
cette figure, il est facile de calculer les instants de commutation.
Exemple: prenons . Avec , temps d’application du vecteur
nul, "# , instant de fermeture de l’interrupteur 8 et $ , instant
d’ouverture de l’interrupteur 8 on a:
"# "# "# $ $ "# "# "# $
$
$
B.2.3 Limites de validité de la MLI vectorielle
Physiquement, il est évident que les durées d’application des vecteurs & et
ne peuvent pas dépasser la période de commutation, c’est à dire:
&
169
F IG . B.8 – Séquences MLI en fonction du secteur angulaire (repéré par )
(B.23)
Dans le cas extrême de l’égalité entre les deux membres, cette équation représente les cotés de l’héxagone (cf. Fig. B.5) pour chaque secteur.
B.2.4 Méthode de limitation
Si la consigne de l’algorithme MLI requiert l’application d’un vecteur de
tension de référence au delà des limites de la MLI, l’algorithme doit pouvoir le
détecter et limiter cette consigne. Une méthode simple pour cela est de vérifier
la propriété B.23, puis de recalculer éventuellement les temps et par les
équations suivantes:
¼
¼
(B.24)
(B.25)
¼
Avec cette limitation, le module du vecteur de tension généré & , associé
¼
¼
à et , est diminué de : , avec : par rapport au module du
vecteur de référence. Par contre, sa phase reste inchangée.
B.2.5 Modification de la commande
En cours de fonctionnement, la tension d’alimentation peut être amenée à
fluctuer (p.e. décharge de batteries dans le cas d’une alimentation par accu170
mulateurs) ce qui peut provoquer la limitation de la consigne de tension de
la MLI. Cette limitation, assimilable à un phénomène de saturation, peut être
problématique pour les régulateurs PI de l’algorithme de contrôle. Pour assurer un fonctionnement correct, il faut ajouter aux régulateurs un système antisaturation. Pour cela, on utilisera la méthode anti-dérive de Franklin-Powell
(cf. Fig. B.9)[42]. Ces systèmes anti-saturation s’appliqueront aux régulateurs
( et ( de et . Le bloc LIM de la figure B.9 contient un modèle de limitation définit comme suit (on utilise ici le cas de , il en est de même pour avec & ):
& reste inchangé: & &
Si la MLI ne limite pas, le module de ¼
¼
& est diminué: & Si la MLI limite, le module de &
1
¼
¼
1 reste inchangé pour assurer le découplage des fonctions de transfert.
F IG . B.9 – Méthode anti-dérive Franklin-Powell
B.3 Schéma bloc de l’algorithme de commande
La figure B.10 représente l’ensemble de la commande, contrôle et MLI, sur
un schéma bloc. Dans ce schéma, on remarquera la présence d’un bloc comp.
Ce bloc sert à compenser le temps de calcul de l’algorithme sur l’estimation
de l’angle . En effet, cet angle est utilisé pour une rotation à l’entrée de l’algorithme de contrôle (transformation de Park), mais aussi à l’entrée de la MLI
pour calculer la tension statorique de référence & dans le repère . Entre ces
deux rotations, un certain temps de calcul s’est écoulé pendant lequel le moteur a continué à tourner. L’angle ne reste donc pas inchangé au niveau du
moteur. La commande étant très sensible à ce paramètre, il convient de rectifier
au niveau de la deuxième rotation.
On remarquera également la présence de blocs hachurés. Ces blocs fonctionnent à une fréquence d’échantillonnage beaucoup plus basse que le reste
de l’algorithme. Pour expliquer cela, il faut en revenir aux constantes de temps
171
des fonctions de transfert de et . Jusqu’à présent, nous n’avons pas précisé quel moteur nous utilisions puisque la validité de l’algorithme n’est pas
limité à un moteur donné. Néanmoins, pour l’intégration de la commande, il
va falloir en tenir compte afin d’étudier les phénomènes liés à l’arithmétique
binaire (précision limité, dépassement de capacité ...etc.). Dans notre cas, nous
utilisons un moteur de 4 KW dont les paramètres identifiés sont donnés en
annexe C. Avec ces paramètres, nous voyons que la constant de temps des
fonctions de transfert de et , , est de l’ordre de 4 ms tandis que la
constante de temps rotorique est proche de 150 ms. Afin d’éviter des problèmes
numériques dus au sur-échantillonnage, on fixe deux constantes de temps. Une
première, , fixe la cadence de calcul des boucles de régulation rapides de
et . Une deuxième est associée à la régulation de et vaut .
172
F IG . B.10 – Schéma bloc de l’algorithme de commande
173
174
Annexe C
Paramètres du moteur 4 kW
paramètre
3 (kW)
(V)
(A)
;
(Hz)
(t/min)
/
( ()
* (H)
* (H)
( ()
<
) (Wb)
valeur
4,4
70 (
)
52
0.79
50
1425
2
0.211
0.00099
0.0147
0.099
0.177
0.18
TAB . C.1 – paramètres du moteur 4 KW
175
176
Annexe D
L’algorithme CORDIC
D.1 L’algorithme CORDIC classique
Développée en 1959 par J. Volder [55], la technique de calcul dénommée
CORDIC 1 servait à la résolution en temps réel de problèmes de navigation.
Cet algorithme calcule la rotation ou la norme d’un vecteur du plan, ainsi que
la tangente inverse. L’idée développée par cette technique est d’effectuer ces
opérations de façon itérative, c’est à dire de calculer par exemple la rotation
par micro-rotations successives, en utilisant des fonctions logiques simples tels
que des additionneurs, des décaleurs, des registres et une ROM pour stocker
les micro-angles.
L’algorithme CORDIC classique est décrit par les équations suivantes:
8
=
'
8
= = 8 '
où sont les micro-angles précalculés et stockés dans la ROM, et
avec l’indice de l’itération courante.
Dans son article, Volder présente deux modes opératoires:
1. Le mode rotation: dans ce mode, étant donné les coordonnées d’un vecteur et un angle de rotation, l’algorithme calcule les coordonnées du vecteur pivoté. Ce mode est défini par > .
2. Le mode vectorisation: étant donné les coordonnées d’un vecteur, l’algorithme calcule la norme de ce vecteur et son angle par rapport à l’axe des
abscisses. Ce mode est défini par ? .
Il prouve également que si
' ####
1. COrdinate Rotation DIgital Computer
177
(D.1)
alors après itération avec ,
8
8 ' = ' = - 8 ' = ' '
où K est le facteur d’échelle égale à
-
####
Remarquons que si on choisit le vecteur d’entrée égal à
& 8 ! :
= ! :
!
:
8 = avec
et l’angle de rotation tel que #, alors on calcule
! : 8
= - ! : '
avec une erreur absolue théorique de
8
! : ! =
! : ! et
Remarque: si ! et : , alors 8
et = .
Les équations que nous avons présenté se basent sur une arithmétique réelle.
Mais le but de cet algorithme étant une intégration digitale, il faut étudier l’influence de l’arithmétique binaire sur l’algorithme.
178
D.2 Le CORDIC binaire
Dans la suite de cette annexe, nous utiliserons le formalisme pour
décrire le format binaire employé, avec le nombre de bits de la partie entière
et la longueur totale du mot binaire.
Ainsi que nous l’avons déjà dit, l’algorithme atteint une précision théorique
définie par:
8
! : ! avec le nombre total d’itérations. Cette erreur est appelée erreur d’approximation et est due au nombre d’itération fini.
Supposons maintenant un vecteur & 8 = codé sur bits. La micro-rotation
qui calcule le vecteur & 8 = à l’itération est déterminée par la valeur
de & . Mais l’expression & n’a un sens que si . Si " , alors &
est le vecteur nul et la valeur de & n’a pas de sens.
D’autre part, la précision du calcul est déterminée par la précision de la décomposition de l’angle de rotation en micro-angles (à travers l’expression ' ). Cela signifie que pour un format binaire , décomposer l’angle de
rotation avec une précision supérieure à n’a pas de sens. Comme
les micro-angles sont définis par , la dernière micro-rotation sera
de et donc le nombre maximum d’itération est donné par ,
nombre de bits de la partie fractionnaire.
Toutefois, ce résultat ne tient pas compte de l’erreur introduite par la troncature des résultats, erreur produite par la longueur finie des mots binaires. Cette
erreur peut excéder l’erreur d’approximation lors du calcul répété des opérations d’addition et de soustraction sur des mots binaire de longueur finie. Dans
ce cas, la précision de l’algorithme n’est plus fixée par le nombre d’itérations.
Pour remédier à cela, Kota et Cavallaro ont montré en [32] que si on calcule l’algorithme CORDIC en mode rotation sur bus de données interne de
longueur avec
alors l’erreur de troncature reste inférieure à l’erreur d’approximation et on
peut atteindre une précision de bits, c’est à dire une erreur de après itérations.
Remarque: Dans cette étude, le format binaire envisagé valait . Dans notre
cas, vaut .
Donc, si on reprend tous les éléments avec un format binaire de par
exemple, il faudrait calculer théoriquement 5 itérations CORDIC. Mais pour
atteindre une précision de , il faut en fait calculer sur un bus interne de 19
bits:
179
F IG . D.1 – Résultats partiels d’une rotation CORDIC simulée sur MATLAB
180
valeurs par défaut de X0, Y0 et Z0:
X0 = 1
Y0 = 0
Z0 = 0
réponse:
valeurs du nombre de bits du chemin de données de XY et de Z par défaut?
(y,n)
réponse par défaut: y
Valeurs par défaut des largeurs de chemin de données:
nombre de bit de Z : 19
nombre de bit de XY: 19
réponse:
valeurs du nombre de bits de XY et de Z par défaut? (y,n)
réponse par défaut: y
Valeurs par défaut des constantes de calcul:
nombre de bit de Z : 16
nombre de bit de XY: 16
nombres de bits alloués à la partie entière de Z : 11
nombres de bits alloués à la partie entière de XY: 11
réponse: 1
Choisir les fonctions à calculer (ce choix défini le mode de fonctionnement de
l'algorithme)
sinus/cosinus
=> indiquer 1
=> indiquer 2
X*Z
racine carrée/arctan => indiquer 3
Y/X
=> indiquer 4
réponse par défaut: 4
--- Programme de calcul de fonctions complexes par l'algorithme CORDIC ----------------- Les calculs se font sur des nombres binaires ---------------
0000000000100000000
0000000000010000110
1111111111110111101
0000000000000110011
0000000000000110011
1111111111111110101
1111111111111110101
0000000000000010100
0000000000000000101
1111111111111111110
1111111111111111110
0000000000000000001
0000000000000000000
0000000000000000000
1111111111100000000
1111111111110000000
1111111111111000000
1111111111110010000
1111111111101110100
1111111111110001111
1111111111110000001
1111111111101111010
1111111111101111111
1111111111110000010
1111111111110000001
* : résultats des itérations de normalisation
p : opération de pré-rotation
-1
0
1
1
2
2
3
4
5
5
6
7
Z
0.52344 p
-0.26172
0.19922
0.19922 *
-0.04297
-0.04297 *
0.07812
0.01953
-0.00781
-0.00781 *
0.00391
0.00000
2.09375
1.00000
1.00000
1.50000
0.75000
0.68750
0.85938
0.92969
0.89844
0.88281
0.85547
0.86719
0.86328
0.00000
0.00000
-1.00000
-0.50000
-0.25000
-0.43750
-0.54688
-0.44141
-0.49609
-0.52344
-0.50391
-0.49219
-0.49609
1.00000
0000000000100000000
0000000000100000000
0000000000110000000
0000000000011000000
0000000000010110000
0000000000011011100
0000000000011101110
0000000000011100110
0000000000011100010
0000000000011011011
0000000000011011110
0000000000011011101
Y
0000000000000000000
----- Evolution de Zi, Xi et Yi binaires ainsi que X, Y et Z réels ------- Poids forts et bit de signe à gauche --X
it|
X binaire
Y binaire
Z binaire
0000000001000011000
----- valeurs initiales de Z0, X0 et Y0 ainsi que X, Y et Z réels -----
Première rotation de Pi/2 effectuée
Valeur de Z0 : 2*pi/3
Donner une valeur de z0 comprise entre -2pi et 2pi.
Valeur de Y0 : 0
Valeur de X0 : 1
Donner des valeurs de X0 et Y0 codables sur le nombre de bits indiqué (nottamment la partie entière).
réponse: n
valeurs de X, Y et Z par défaut? (y,n)
réponse par défaut: y
Il faut donc calculer
itérations.
Figure D.1, p. 180, donne les résultats intermédiaires d’une simulation CORDIC avec le format binaire défini ci-dessus.
Remarque: Cette simulation inclut les itérations de normalisation (cf. D.4, p. 183).
D.3 L’algorithme CORDIC généralisé
En 1971, J. Walther décrit un algorithme CORDIC légèrement modifié qui
permet de calculer toutes les fonctions mathématiques classiques [56].
Même si cet algorithme n’est pas le moyen le plus rapide de calculer certaines des fonctions calculables, il est très intéressant de pouvoir calculer toutes
ces fonctions en réutilisant toujours les mêmes ressources matérielles.
L’algorithme CORDIC généralisé est défini par les équations suivantes:
8
=
'
8 = %
= 8 %
'
%
avec et % est une base discrète.
Cet algorithme généralisé permet de définir deux nouvelles classes de fonctions. Aux fonctions circulaires ( ), définies déjà avec l’algorithme classique, on ajoute maintenant les fonctions linéaires ( ) et les fonctions hy). Le calcul de ces deux nouvelles classes de fonctions est
perboliques ( possible grâce à la définition de trois bases discrètes :
– pour – pour – ! pour La figure D.2, p. 182, et le tableau D.1, p. 181, résument ces modes de fonctionnement de l’algorithme CORDIC. Remarquons que certaines itérations doivent
afin d’assurer la convergence de l’algorithme.
être répétées pour Circulaire
Linéaire
Mode
Hyperbolique
Itérations calculées
< < < ###
###
Base discrète
% % % ! TAB . D.1 – Valeurs de < et de % pour chaque mode
Pour l’algorithme CORDIC classique, Volder avait prouvé que si > , l’angle
initial, est décomposé en micro-angles tel que
181
Rotation mode
Vectoring mode
Z
K[Xcos(Z)-Ysin(z)]
X
K[Ycos(Z)+Xsin(Z)]
Y
0
Z
K
(X 2 +Y2 )
0
Z-Arctan(y/X)
X
Y+XZ
Y
Z
0
Z
Z+Y/X
X
K’[Xcosh(Z)-Ysinh(Z)]
X
K’ (X -Y )
K’[Ycosh(Z)+Xsinh(Z)]
Y
0
Z
Y
Z
F IG . D.2 – Fonctions calculées par l’algorithme CORDIC généralisé
182
X
0
2
CORDIC
Y
CORDIC
X
CORDIC
X
dn=-sign(Yk )
CORDIC
Y
CORDIC
X
CORDIC
Hyperbolic
m=-1
Linear
m=0
Circular
m=1
dn=sign(Zk )
2
0
Z-argth(Y/X)
> alors la condition nécessaire et suffisante de convergence est donnée par
" " (D.2)
Cette condition reste valable pour l’algorithme généralisé ce qui permet de
déduire les conditions de convergence du CORDIC. On résume ces conditions
dans le tableau D.2, p. 183, pour les modes qui nous intéressent.
Circulaire
'
rotation
# # # # # # # #
'
Linéaire
vectorisation
= 8 and 8 " TAB . D.2 – Conditions de convergence des modes circulaires et linéaires
Dans le mode hyperbolique, déterminer la séquence d’itérations à répéter
est un problème complexe que Hsiao et Delosme proposent de résoudre par
un algorithme de recuit simulé [50].
Le calcul de fonctions complexes à partir des fonctions calculées par l’algorithme CORDIC généralisé est plutôt simple:
! 8 ! 8
!
!
!
8 !!
8 ! !!
8!
"
8 8
8
D.4 La normalisation des résultats
Du point de vue algorithmique, la normalisation des résultats peut s’effectuer de deux manières:
1. soit par la multiplication par &
2. soit en utilisant une méthode de multiplication itérative présentée par
Haviland et Tunzynsky dans [20]. Cette solution consiste à décomposer
sous forme de produit de facteurs tels que la multiplicala constante &
tion par un facteur puisse s’effectuer avec les ressources matérielles du
183
CORDIC. La normalisation s’effectue alors en insérant des itérations de
normalisation avant, après ou entre les itérations de l’algorithme.
La factorisation est donnée par l’expression suivante:
-
# est la longueur des mots binaires et est tel que est codable dans
le format binaire choisi.
Remarquons au passage que cette méthode de multiplication itérative a un intérêt non négligeable pour l’intégration des algorithmes de commande. En effet, ces algorithmes comportent de nombreuses multiplications par des constantes.
Ces multiplications posent souvent problème lors de l’intégration en virgule
fixe car les constantes en questions sont trop petites pour être codées dans le
format binaire choisi. Il en résultent de nombreuses opérations de décalage
pour changer de format de données.
Or la multiplication itérative par le biais de la factorisation des constantes
permet de s’affranchir de ce type de problèmes.
Prenons par exemple la multiplication d’un nombre 8 par une constante
# avec un format binaire . La constante ne pouvant être codée
dans ce format, la multiplication 8 serait nulle avec un multiplieur normal.
Mais, si 8 , cette multiplication devrait valoir 8 , résultat
qui est codable dans le format binaire .
Si maintenant est décomposé sous la forme:
La décomposition atteint une précision de # # . Avec
le format binaire choisi, la valeur maximale codable en arithmétique binaire
signée vaut 8 et la précision de codage maximale est de . La
factorisation de sera donc choisie de telle manière que l’erreur sur la multiplication soit au maximum égale à ce qui se traduit par:
8 Cette condition est remplie avec
La multiplication itérative de 8 par donnera alors en quatre itérations.
184
8 D.5 Extension des limites de convergence
L’analyse des algorithme de contrôle montre que les domaines de convergence de l’algorithme CORDIC sont insuffisants pour les variables impliquées:
– L’opération de rotation est utilisée dans le calcul de la transformation
de Park où la rotation du vecteur de tension s’effectue avec l’angle de
rotation du flux moteur. Cet angle varie bien entendu de 9 à 9 , soit
bien plus que prévu par l’algorithme CORDIC.
– Les opération linéaires (multiplication et division) s’opèrent sur des variables dont la valeur maximale correspond à la valeur maximale de codage binaire.
Une solution serait d’utiliser l’arithmétique virgule flottante, mais comme les
opérandes restent codés en arithmétique virgule fixe, il faudrait envisager des
opérations de conversion. Par ailleurs, le coût d’une implantation virgule flottante du CORDIC nous a parut excessif.
Nous avons donc modifié légèrement l’algorithme pour étendre les limites
de convergence.
D.5.1 Extension des limites de convergence de la rotation
La première opération proposée par Volder lui-même est d’effectuer une
prérotation de ce qui étend les limites de convergence à:
9
9
# # # # # # # #
L’extension à 9 9 est effectué ensuite en calculant l’angle '
équivalent à l’angle de rotation ' si celui-ci vérifie la condition:
'
9
9 9 9 9 9 Si on résume tout cela, on obtient les condition suivantes pour l’extension
des limites de convergence:
Si ' " 9 et ' , alors
' 9
9
9
' ' Si ' " 9 et ' " , alors
' 9 9
' '
185
9
Ces opérations sont très faciles à réaliser, soit avec le matériel déjà existant (on
calcule la valeur absolue de ' en scrutant son MSB 2 et en calculant éventuellement ' ' ), soit en utilisant un opérateur de valeur absolue.
L’autre point dont il faut tenir compte est la norme du vecteur d’entrée.
Pour éviter un débordement binaire lors de l’addition = 8 ¸ la norme
de ce vecteur est limitée par une valeur maximale ! . Dans le cas d’une rotation vraie¸ ! serait égale
codable dans le format binaire
à la valeur maximale
envisagé¸ c’est à dire¸ . Mais¸ comme les rotations CORDIC
sont des pseudo-rotation affectées par -¸ cette valeur maximale vaut:
! -
Les simulations par MATLAB de l’algorithme binaire étendu, figures D.3
et D.4, p. 187, montrent la précision atteinte pour des mots au format binaire
avec un bus interne de bits.
1
0.8
0.6
0.4
0.2
0
−0.2
−0.4
−0.6
−0.8
−1
−1
−0.5
0
0.5
1
F IG . D.3 – Simulation du CORDIC (trait plein) en mode rotation par rapport à une
rotation réelle (trait hachuré)
D.5.2 Extension des limites de convergence du mode linéaire
L’extension des domaines de convergence des fonctions linéaires est beaucoup plus complexe.
solution
simple à première vue serait d’étendre la base discrète à
# Une
$
avec le nombre de bits entiers et le nombre de bits de la
partie fractionnaire. Dans ce cas, la borne supérieure de chaque domaine de
% convergence augmenterait jusqu’à , valeur maximale codable dans
le format .
2. Most Significant Bit
186
0.04
0.03
0.02
0.01
0
−0.01
−0.02
−0.03
−0.04
0
1
2
3
4
5
6
7
F IG . D.4 – Précision des rotations CORDIC
Mais examinons les équations CORDIC pour le mode linéaire:
8
=
'
8
= 8 %
%
'
avec < positif ou négatif.
Si < est positif, le décalage de 8 vers la gauche produira un débordement numérique si:
8
" 8
"
Comme 8 8 , la dernière condition est équivalente à
8 " Remarque: Ce résultat suppose que le décalage maximal vers la gauche est
limité à en raison du bit de signe en arithmétique complément à
deux.
La solution proposée étant inappropriée, nous proposons de suivre la même
technique que pour le mode circulaire, c’est à dire de normaliser les variables
d’entrée.
L’idée de cette normalisation est de transformer le format binaire des variables d’entrée pour le ramener à et d’utiliser la base discrète . Mais,
pour conserver toute la précision de codage des variables, la transformation
dépend de la valeur des variables. En fait, on réalise une sorte de transformation des variables de l’arithmétique virgule fixe vers l’arithmétique virgule
flottante.
Voyons maintenant le détail des opérations à réaliser pour chaque fonctions.
187
D.5.2.1 Cas de la division
On commence ici par tester le signe de 8 (en scrutant son MSB). Si 8 est
négatif, on calcule avec 8 et on change le signe du résultat final.
Ensuite, on teste si . Si c’est le cas, on se trouve dans les limites de
convergence de l’algorithme CORDIC normal. On calcule donc directement les
itérations CORDIC et on économise le temps de la normalisation.
La normalisation est effectuée de la manière suivante:
1. Tant que le bit = vaut 0, on décale = et 8 de un bit vers la
gauche. Comme on décale les deux opérandes, le rapport reste constant
et égale à .
2. Quand le bit = passe à 1, on arrête de décaler = mais on continue
avec 8 jusqu’à ce que 8 vaille 1. On conserve la valeur du
décalage effectué sur 8 dans cette phase pour corriger le rapport final calculé par le CORDIC.
3. On effectue ensuite itérations CORDIC avec longueur du
chemin de données interne du CORDIC.
En raison des décalages sur 8 et = , l’équation CORDIC pour la coordonnée = vaut maintenant:
&
=
= 8 avec le nombre total d’itérations de décalage sur = et le nombre
total d’itérations de décalage sur 8 .
Après itérations, on a:
&
=
= 8 %
La coordonnée ' est donnée quant à elle par:
&
Après '
'
%
' itérations, on obtient:
%
' %
' 188
=
8
(D.3)
4. En décalant le résultat des itérations CORDIC de bits (équation D.3) et après troncature des bits additionnels du chemin interne, soit
une troncature des bits de poids faible, on obtient le rapport sur la coordonnée ' :
' Remarque: la valeur est nécessairement inférieure à car une valeur
supérieur signifierait que " , et donc le rapport ne serait pas
codable dans le format binaire . Le décalage final est donc toujours
à droite.
D.5.2.2 Cas de la multiplication
Nous appliquons ici le même méthode que pour la division mais avec la
variable ' :
1. Test si ' 8 . Si c’est le cas, on permute 8 et ' pour des raisons de
précision de calcul (justification en D.5.3).
2. Test si ' . Si c’est le cas, on calcule directement les itérations CORDIC.
3. Normalisation de ' : on décale ' jusqu’à ce que le bit ' vaille 1.
L’équation CORDIC devient alors:
' ' 4. Calcul des itérations CORDIC. On obtient alors:
=
'
=
%
= 8 %
' En supposant que ' , on a:
%
= 5. En décalant = de
sultats, on obtient:
= ' 8 ' bits, et après troncature des ré-
8 '
Remarque: La valeur de est toujours inférieure à car dans la cas
contraire, cela signifierait que ' et dans ce cas, on calcule directement les itérations CORDIC sans normalisation des variables d’entrée.
Par conséquent, le décalage final est toujours vers la gauche.
189
D.5.3 Précision du CORDIC étendu
En modifiant l’algorithme, nous modifions aussi la précision des résultats. Il
nous faut donc étudier maintenant la précision atteinte par le CORDIC étendu
pour les fonctions linéaires.
D.5.3.1 Cas de la multiplication
Théorème 1 L’erreur de décomposition de ' est toujours inférieure à après itérations. Autrement dit:
'
Preuve 1 La condition de convergence D.2 donne '
Comme
' '
on a
Supposons que ' Comme
.
' .
' '
on aurait
' Comme on a ' , on prouve que
'
Dans le cas de la multiplication, les itérations CORDIC donnent après itérations les résultats suivants:
8 8
%
= = %
8 ' '
!
%
Du théorème 1, on déduit que !'
définir une précision théorique du résultat:
' 8 ' ' %
%
=
!
!
ce qui permet de
' 8 ' Dans une première approximation, nous avons donc une précision de =
égale à 8 . On remarquera que puisque cette précision est proportionnelle
à 8 , il faut s’assurer que 8 soit inférieur à ' (ce qui explique le premier test
de la multiplication).
190
Cependant, ce calcul ne tient pas compte des points suivant, sources d’erreur:
1. Le changement de format initial et la correction du résultat final: en raison du décalage final à gauche ( est positif), l’erreur sur
= est en fait de 8 , cette erreur étant supérieure à 8 .
2. l’erreur introduite par la troncature: le calcul de l’erreur sur = n’a pas
pris l’erreur de troncature introduite par la longueur finie des mots binaires. Cette erreur est de l’ordre de Æ avec Æ et peut dans certains cas excéder 8 . En effet, avec le calcul du CORDIC non étendu, nous n’effectuons pas de décalage final. Cette erreur
reste alors inférieure à . Par contre, le décalage final multiplie cette
erreur et la rend très supérieure à 8 .
3. l’erreur de quantification (introduite par le codage binaire de grandeurs
réelles): elle reste toujours inférieure à et est inévitable. Pour éliminer cette erreur de nos simulations et mettre en évidence l’influence des
autres facteurs d’imprécision, nous avons comparé des simulations CORDIC avec la même opération effectuée sur des nombres réels obtenus par
conversion des entrées binaires du CORDIC.
L’erreur globale étant très difficile à quantifier, il est toutefois facile de montrer
que lorsque 8 est très supérieur à l’erreur de troncature, l’erreur maximale
commise sur le calcul d’une multiplication par l’algorithme CORDIC étendu
est donnée par:
8
avec 8 la valeur maximale codable dans le format binaire envisagé.
En effet, si 8 est très supérieur à l’erreur de troncature, c’est à dire qu’il
n’est pas trop proche de la limite de codage, alors l’erreur de calcul est limitée
par 8 . Dans ce cas, = vaut:
= 8 ' Sachant que
' 8
8
8
'
on retrouve la valeur de l’erreur maximale de calcul.
En figure D.5, nous avons représenté le pourcentage d’erreur commis par
l’algorithme CORDIC étendu pour un format binaire . On y voit clairement que pour de faibles valeur de 8 , l’erreur de troncature devient prépondérante.
191
3.5
3
2.5
2
1.5
1
0.5
0
40
30
20
20
0
10
0
−20
−10
−20
−40
−30
F IG . D.5 – Pourcentage d’erreur commis par le CORDIC étendu sur la multiplication
D.5.3.2 Cas de la division
Dans le cas de la division, on peut montrer de la même manière que pour la
multiplication, que l’erreur de décomposition = est égale à 8 . Par conséquent, le résultat final est atteint avec une précision valant:
= 8 =
8
8
Comme pour la multiplication, nous devons prendre en compte la correction finale et l’erreur de troncature. Le décalage final étant toujours vers la
droite, la précision finale est donnée par:
Figure D.6 représente une simulation de la division CORDIC étendu. Avec
les figures D.7 et D.8 nous avons voulu mettre en évidence l’influence de l’erreur de quantification.
192
120
100
80
60
40
20
0
10
8
1
6
0.8
0.6
4
0.4
2
0.2
0
0
F IG . D.6 – Simulation de la division avec le CORDIC étendu
2
0
−2
−4
−6
−8
10
8
1
6
0.8
0.6
4
0.4
2
0.2
0
0
F IG . D.7 – Erreur sur la division incluant l’erreur de quantification
0.04
0.03
0.02
0.01
0
−0.01
10
8
1
6
0.8
0.6
4
0.4
2
0.2
0
0
F IG . D.8 – Erreur sur la division sans l’erreur de quantification
193
194
Annexe E
Simulation sous Ptolemy
Nous proposons dans cette annexe un exemple de modélisation et simulation sous Ptolemy. Le système modélisé et simulé est la commande échantillonnée d’un processus du premier ordre. Cet exemple de commande a été tiré de
[49].
Le transmittance du processus proposé est donnée par:
/
/ / /
On synthétise le correcteur numérique tel que le système en boucle fermée
ait un comportement du second ordre. On choisit la période d’échantillonnage
égale à .
La transmittance en z du processus avec un bloqueur d’ordre zéro est donnée par:
' ' ' ' '
Ce processus a une constante de temps ' , ce qui correspond à une
pulsation propre de .' ! . En choisissant pour le processus asservi
une pulsation propre de . ! et un coefficient d’amortissement de
, la transmitance du processus asservi vaut:
$' ' '
' '
La transmitance du correcteur synthétisé est alors donnée par:
' '' '
'
Figure E.1, on a représenté le schéma bloc de principe de ce système.
195
Ce système a été modélisé avec Ptolemy dans le domaine SDF 1 . Les figures E.2 à E.4 représentent les schémas blocs construits dans l’environnement
graphique de Ptolemy. La courbe figure E.6 donne la réponse temporelle du
système pour un échelon unité perturbé. La perturbation est donnée figure E.5.
F IG . E.1 – Schéma bloc de l’asservissement du processus
Regulation d’un processus du premier ordre
perturbation
in1
in2
Const
in3
Sampler
processus
Clock
F IG . E.2 – Schémas blocs sous Ptolemy du système asservi
1. Synchronous Data Flow
196
XMgraph
Generation d’une perturbation
Impulse
Delay
Filter
F IG . E.3 – Schémas blocs sous Ptolemy du système asservi
Regulateur et processus
XMgraph
Add
Sub
IIR
regulateur
XMgraph
IIR
processus
F IG . E.4 – Schémas blocs sous Ptolemy du système asservi
197
Signal epsilon
Y
Set 0
1.00
0.80
0.60
0.40
0.20
0.00
X
0.00
50.00
100.00
150.00
200.00
F IG . E.5 – Perturbation Sortie Y
Y
Set 0
1.00
0.80
0.60
0.40
0.20
0.00
X
0.00
50.00
100.00
150.00
F IG . E.6 – Réponse temporelle du système asservi
198
200.00
Annexe F
Traitement des mesures et
consignes
Dans le traitement des mesures et consignes, il faut considérer deux cas
différents. D’une part, nous avons l’acquisition d’échantillons analogiques par
des convertisseurs analogique-numérique, et d’autre part, nous mesurons la
vitesse en comptant les créneaux générés par un disque denté.
F.1 Acquisition des échantillons analogiques
L’acquisition des mesures et consignes analogiques est effectuée par des
convertisseurs de 8 bits. Le traitement de ces mesures consiste à calculer la
valeur correspondante à la valeur mesurée.
La valeur binaire générée par un convertisseur de 8 bits code un entier
. Chaque bit de cette valeur binaire correspond à un incrément analogique
donné par:
avec la tension d’alimentation du convertisseur (dans notre cas, 5V).
La valeur analogique de l’échantillon acquis par le convertisseur se calcule
à partir de la valeur de incrément analogique:
Cette tension mesurée par le CAN varie entre 0V et 5V.
Les convertisseurs mesures quatre signaux analogiques: deux courants statoriques ( et ), la consigne de couple sous forme de la composante du
courant statorique dans le repère ( ), et la tension d’entrée de l’onduleur
( ). Le calcul de la valeur réelle de chaque mesure ou consigne est calculée
différemment selon le circuit de mesure utilisé.
199
F.1.1 Valeur des courants statoriques
et La mesure des courants s’effectue par des capteurs à effet Hall alimentés
sous 12V. Le courant maximal mesurable est de A. La sortie des
capteurs est reliée à un filtre anti-repliement et à un circuit de mise en forme
des signaux analogiques qui ramène la mesure à une valeur entre 0V et 5V, le
point de repos étant à V.
La valeur réelle des courants est donc calculée à partir de la mesure par la
relation suivante:
F.1.2 Valeur de la consigne de couple
La consigne de couple est générée par une simple résistance variable connectée directement au convertisseur. La consigne varie entre 0A et . La
valeur de se calcule à partir des caractéristiques du moteur données
en Annexe B.
Pour déterminer , on se base sur les équations suivantes:
%
*
/* 3
@ !
avec le courant magnétisant, % le flux rotorique, * l’inductance rotorique, le couple moteur, / le nombre de paires de pôles, le couple moteur
nominal, 3 la puissance nominale et @ ! , la vitesse de rotation nominale.
Avec les valeurs des paramètres identifiés, on obtient un courant magnétisant maximal de A, un couple nominal N/m et donc un
courant de consigne nominal A.
Le calcul de la mesure de la consigne devient alors:
F.1.3 Calcul de la mesure de tension
La mesure de la tension s’effectue par un optocoupleur en régime linéaire,
couplé directement au CAN. Dans la plage de tension qui nous intéresse, la
réponse du circuit est pratiquement linéaire.
200
La tension se calcule donc par l’équation suivante:
avec une estimation pour de et pour de F.2 Mesure de la vitesse
Dans le cas de la mesure de vitesse, nous disposons de deux signaux déphasés dont nous scrutons les flancs de montée et de descente. Le premier signal
(TOP) permet de calculer la vitesse et le second (SENS), le sens de rotation.
Le principe de calcul de la vitesse est le suivant. On compte le nombre de
périodes d’horloge que dure une période du signal TOP, c’est à dire de flanc
de montée à flanc de montée, pour mesurer le temps que dure cette période.
Puis on divise l’angle parcouru par la période de TOP. Formalisé sous forme
d’équation, on a:
@ (
avec le nombre de dents du disque et la période d’horloge.
Toutefois, comme la vitesse mesurée peut être trop lente et provoquer un
débordement du compteur, on commande celui-ci par un signal d’enable plus
lent que l’horloge. On en tient compte dans le calcul de la vitesse.
201