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 examinateur

Jordi CARRABINA codirecteur Jean-Pierre CHANTE codirecteur

Richard GRISEL rapporteur Xavier JORDÁ examinateur Bruno MAURICE examinateur Javier UCEDA examinateur Michel ROBERT 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: leCentre 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 deBarcelone (UAB).

La diversité des approches scientifiques et les différences culturelles etlinguistiques ont été une expérience enrichissante et passionante. Mapremiè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 dece projet. Son aide et son soutien m’ont été précieux. Je tiens à le remercierpour m’avoir encadré et permis de passer en Espagne des momentsinoubliables.

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èsependant mes nombreux séjours en Catalogne. Je garde de très bons souvenirsde 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 particulierpour leurs remarques judicieuses.

A Monsieur Nacer Abouchi, Maître de Conférence à l’Ecole de PhysiqueChimie et Electronique de Lyon (CPE), je désire exprimer toute mareconnaissance pour avoir révisé ce manuscrit et pour son aide lors de laré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¸ sadisponibilité et ses conseils précieux, en particulier concernant la commandedes machines asynchrones; sans lui, cette thèse ne serait pas ce qu’elle est.

Finalement, je tiens aussi à citer tous les chercheurs, personnels et étudiantsque j’ai rencontrés dans les différents laboratoires. Pour certains, le souvenirde la découverte de l’Espagne leur est attaché, pour d’autres, leurs conseils etles intéressantes discussions techniques m’ont permis de surmonter lesdifficultées rencontrées. A tous, ma reconnaissance est assurée. Auxadministrateurs réseaux, Denise, Josep et Ramon, j’adresse un merci à part carleur aide m’a grandement facilité la tâche. Un grand merci aussi à PascalBevilacqua pour sa collaboration au développement des cartes deprototypage.

Merci enfin à tous ceux qui, de près ou de loin, ont contribué au succès decette 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. Enmaniè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 canonperfectionné, Saphir et Wolf.Pourtant, ils pensaient visiblement à autre chose, car leurs paires d’yeuxavaient cessé d’être assorties.

Boris Vian, « L’herbe rouge »

An meine ElternA 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 251.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.2 La chaîne d’entraînement . . . . . . . . . . . . . . . . . . . . . . 26

1.2.1 Les dispositifs . . . . . . . . . . . . . . . . . . . . . . . . . 261.2.2 Les modèles pour la commande . . . . . . . . . . . . . . 30

1.3 La commande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311.3.1 Les fonctions génériques de commande . . . . . . . . . . 311.3.2 Considérations théoriques . . . . . . . . . . . . . . . . . . 35

1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2 Méthodologies d’implantation d’une fonctionnalité:état de l’art 392.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.2 Méthode courante pour la conception système . . . . . . . . . . 402.3 Implantation de la commande de machines électriques AC . . . 43

2.3.1 l’intégration applicative . . . . . . . . . . . . . . . . . . . 432.3.2 L’étude de l’intégration système . . . . . . . . . . . . . . 44

2.4 La conception mixte matériel/logiciel . . . . . . . . . . . . . . . 462.4.1 Détail de la méthode . . . . . . . . . . . . . . . . . . . . . 482.4.2 Les outils de conception mixte . . . . . . . . . . . . . . . 59

2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3 Élaboration d’une méthodologie d’implantation des commandes demoteurs AC 653.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.2 Localisation et formulation des problèmes spécifiques à la com-

mande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.2.1 Les spécifications floues . . . . . . . . . . . . . . . . . . . 673.2.2 Partitionnement et séquencement . . . . . . . . . . . . . 683.2.3 Le test fonctionnel . . . . . . . . . . . . . . . . . . . . . . 70

13

3.2.4 Résumons . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.3 Les spécifications restrictives . . . . . . . . . . . . . . . . . . . . 71

3.3.1 L’arithmétique . . . . . . . . . . . . . . . . . . . . . . . . 723.3.2 Les ressources et l’architecture système . . . . . . . . . . 72

3.4 Traitement théorique des problèmes évoqués . . . . . . . . . . . 733.4.1 Modélisation de la commande . . . . . . . . . . . . . . . 733.4.2 Spécification des temps de la commande . . . . . . . . . 743.4.3 Spécification de la précision de calcul de la commande . 743.4.4 Le test fonctionnel . . . . . . . . . . . . . . . . . . . . . . 75

3.5 Méthodologie d’intégration de la commande . . . . . . . . . . . 803.5.1 les langages de modélisation . . . . . . . . . . . . . . . . 813.5.2 Le flux de conception . . . . . . . . . . . . . . . . . . . . . 83

3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4 Implantation de la méthodologie:Solution à base de Grafcet 914.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.2 Le Grafcet comme modèle en vue de l’intégration . . . . . . . . 92

4.2.1 Rappel des principales caractéristiques du Grafcet . . . . 934.2.2 Interprétation du Grafcet . . . . . . . . . . . . . . . . . . 944.2.3 Restrictions à la modélisation par Grafcet . . . . . . . . . 984.2.4 Survol d’autres langages synchrones . . . . . . . . . . . . 99

4.3 Analyse des modèles Grafcet . . . . . . . . . . . . . . . . . . . . 1004.3.1 Partitionnement matériel/logiciel . . . . . . . . . . . . . 1004.3.2 Analyse architecturale . . . . . . . . . . . . . . . . . . . . 1004.3.3 Estimation de performances . . . . . . . . . . . . . . . . . 107

4.4 Synthèse de code . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084.4.1 Synthèse du script MATLAB . . . . . . . . . . . . . . . . 1094.4.2 Affinement des spécifications . . . . . . . . . . . . . . . . 1094.4.3 Synthèse du code VHDL . . . . . . . . . . . . . . . . . . . 1094.4.4 Synthèse de code logiciel . . . . . . . . . . . . . . . . . . 110

4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

5 Implantation du contrôle vectoriel d’un moteur asynchrone 1115.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.2 Les enjeux de la conception des systèmes de commande . . . . . 1135.3 Intégration de la commande vectorielle . . . . . . . . . . . . . . 113

5.3.1 Spécification du système de commande . . . . . . . . . . 1135.3.2 Vérification fonctionnelle . . . . . . . . . . . . . . . . . . 1215.3.3 Partitionnement et estimation . . . . . . . . . . . . . . . . 1255.3.4 Synthèse mixte . . . . . . . . . . . . . . . . . . . . . . . . 129

5.4 Résultats des test expérimentaux . . . . . . . . . . . . . . . . . . 1335.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Conclusion générale 139

14

Bibliographie 146

Annexes 146

A Définitions 147

B Exemple de commande vectorielle 151B.1 Le contrôle vectoriel . . . . . . . . . . . . . . . . . . . . . . . . . 151

B.1.1 Le modèle de la machine asynchrone . . . . . . . . . . . 152B.1.2 La commande par flux rotorique orienté . . . . . . . . . . 159

B.2 La MLI vectorielle . . . . . . . . . . . . . . . . . . . . . . . . . . . 164B.2.1 Description de l’algorithme . . . . . . . . . . . . . . . . . 164B.2.2 Calcul des instants de commutation . . . . . . . . . . . . 169B.2.3 Limites de validité de la MLI vectorielle . . . . . . . . . . 169B.2.4 Méthode de limitation . . . . . . . . . . . . . . . . . . . . 170B.2.5 Modification de la commande . . . . . . . . . . . . . . . . 170

B.3 Schéma bloc de l’algorithme de commande . . . . . . . . . . . . 171

C Paramètres du moteur 4 kW 175

D L’algorithme CORDIC 177D.1 L’algorithme CORDIC classique . . . . . . . . . . . . . . . . . . . 177D.2 Le CORDIC binaire . . . . . . . . . . . . . . . . . . . . . . . . . . 179D.3 L’algorithme CORDIC généralisé . . . . . . . . . . . . . . . . . . 181D.4 La normalisation des résultats . . . . . . . . . . . . . . . . . . . . 183D.5 Extension des limites de convergence . . . . . . . . . . . . . . . 185

D.5.1 Extension des limites de convergence de la rotation . . . 185D.5.2 Extension des limites de convergence du mode linéaire . 186D.5.3 Précision du CORDIC étendu . . . . . . . . . . . . . . . . 190

E Simulation sous Ptolemy 195

F Traitement des mesures et consignes 199F.1 Acquisition des échantillons analogiques . . . . . . . . . . . . . 199

F.1.1 Valeur des courants statoriques . . . . . . . . . . . . . . . 200F.1.2 Valeur de la consigne de couple . . . . . . . . . . . . . . . 200F.1.3 Calcul de la mesure de tension . . . . . . . . . . . . . . . 200

F.2 Mesure de la vitesse . . . . . . . . . . . . . . . . . . . . . . . . . . 201

15

16

Table des figures

1 chaîne d’entraînement électrique à moteur AC . . . . . . . . . . 22

1.1 onduleur à trois bras . . . . . . . . . . . . . . . . . . . . . . . . . 261.2 tension MLI entre deux phases du moteur avec fondamental de

tension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.3 interrupteur de puissance avec IGBT et diode . . . . . . . . . . 271.4 exemple de période de commutation avec temps mort . . . . . 281.5 moteur AC asynchrone à cage d’écureuil . . . . . . . . . . . . . 291.6 exemple de hiérarchie de commande . . . . . . . . . . . . . . . 321.7 structure de la commande . . . . . . . . . . . . . . . . . . . . . . 341.8 exemple de contrôle �

�constant . . . . . . . . . . . . . . . . . . 36

1.9 schéma de principe d’un contrôle vectoriel . . . . . . . . . . . . 37

2.1 ALU de 32 bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.2 Méthode de conception mixte générique . . . . . . . . . . . . . . 472.3 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . 482.4 Exploration de l’espace des solutions de réalisation . . . . . . . 512.5 Synthèse mixte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562.6 outils de conception testés . . . . . . . . . . . . . . . . . . . . . . 60

3.1 Méthode générique de conception mixte selon Gajski-Vahid . . 663.2 Architecture du système de commande . . . . . . . . . . . . . . 733.3 cosimulation sous MATLAB . . . . . . . . . . . . . . . . . . . . . 843.4 Flux de conception d’un système de commande . . . . . . . . . 87

4.1 Modélisation d’un branchement OU par réseau de Pétri et parGrafcet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

4.2 Exemple de modélisation par Grafcet . . . . . . . . . . . . . . . 974.3 Modèle Grafcet avec branchement ET . . . . . . . . . . . . . . . 984.4 Formalisme de condition sur une action en Grafcet . . . . . . . . 994.5 Implantation d’actions concurrentes . . . . . . . . . . . . . . . . 1034.6 Inférence de registres . . . . . . . . . . . . . . . . . . . . . . . . . 1044.7 Génération de logique combinatoire . . . . . . . . . . . . . . . . 1044.8 Implantation d’actions concurrentes . . . . . . . . . . . . . . . . 1054.9 Implantation d’un «indice matériel» . . . . . . . . . . . . . . . . 105

17

4.10 Duplication d’une fonction . . . . . . . . . . . . . . . . . . . . . 1064.11 Fusion de deux bus . . . . . . . . . . . . . . . . . . . . . . . . . . 106

5.1 Méthodologie de conception mixte . . . . . . . . . . . . . . . . . 1125.2 Banc de test de la commande du moteur asynchrone . . . . . . . 1145.3 Topographie du système de commande . . . . . . . . . . . . . . 1165.4 Schéma bloc de l’algorithme de commande . . . . . . . . . . . . 1185.5 Simulation de l’évolution des grandeurs caractéristiques du mo-

teur en fonction du temps (en s) lors d’un démarrage . . . . . . 1195.6 Défluxage du moteur (fonction du temps en s) . . . . . . . . . . 1205.7 Grandeurs caractéristiques du moteur en fonction du temps (s)

pour deux périodes d’échantillonnage différentes . . . . . . . . 1225.8 Modèle de spécification de la commande . . . . . . . . . . . . . 1235.9 Modèle de spécification du bloc MLI . . . . . . . . . . . . . . . . 1245.10 Évolution des grandeurs caractéristiques du moteur en fonction

du temps (s) pendant un démarrage:simulation du modèle decompréhension (gauche) et de spécification (droite) . . . . . . . 126

5.11 Évolution du couple et de la consigne de flux en fonction dutemps (s):simulation du modèle de compréhension (gauche) etde spécification (droite) . . . . . . . . . . . . . . . . . . . . . . . . 127

5.12 Simulation de la MLI et génération des impulsions . . . . . . . . 1285.13 Architecture de l’ASIC de commande . . . . . . . . . . . . . . . 1305.14 Diagramme des signaux du TLC0831 . . . . . . . . . . . . . . . . 1325.15 Synoptique de la carte de prototypage . . . . . . . . . . . . . . . 1345.16 Signaux de commande d’un bras de l’onduleur . . . . . . . . . . 1355.17 Temps mort en fonction de la période d’horloge . . . . . . . . . 1355.18 Courant à la sortie de l’onduleur, filtré à 50Hz . . . . . . . . . . 136

B.1 commande de la machine asynchrone dans le repère �� . . . . . 161B.2 Transformée en Z d’un processus du premier ordre régulé par

un PI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161B.3 Estimation de la constante de temps rotorique . . . . . . . . . . 164B.4 Onduleur idéal a trois bras . . . . . . . . . . . . . . . . . . . . . . 166B.5 Vecteurs de tension statorique dans le plan �� . . . . . . . . . . 167B.6 Principe de construction du vecteur de tension statorique . . . . 167B.7 Algorithme pour déterminer le secteur angulaire . . . . . . . . . 168B.8 Séquences MLI en fonction du secteur angulaire (repéré par �) . 170B.9 Méthode anti-dérive Franklin-Powell . . . . . . . . . . . . . . . 171B.10 Schéma bloc de l’algorithme de commande . . . . . . . . . . . . 173

D.1 Résultats partiels d’une rotation CORDIC simulée sur MATLAB 180D.2 Fonctions calculées par l’algorithme CORDIC généralisé . . . . 182D.3 Simulation du CORDIC (trait plein) en mode rotation par rap-

port à une rotation réelle (trait hachuré) . . . . . . . . . . . . . . 186D.4 Précision des rotations CORDIC . . . . . . . . . . . . . . . . . . 187

18

D.5 Pourcentage d’erreur commis par le CORDIC étendu sur la mul-tiplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

D.6 Simulation de la division avec le CORDIC étendu . . . . . . . . 193D.7 Erreur sur la division incluant l’erreur de quantification . . . . . 193D.8 Erreur sur la division sans l’erreur de quantification . . . . . . . 193

E.1 Schéma bloc de l’asservissement du processus . . . . . . . . . . 196E.2 Schémas blocs sous Ptolemy du système asservi . . . . . . . . . 196E.3 Schémas blocs sous Ptolemy du système asservi . . . . . . . . . 197E.4 Schémas blocs sous Ptolemy du système asservi . . . . . . . . . 197E.5 Perturbation � . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198E.6 Réponse temporelle du système asservi . . . . . . . . . . . . . . 198

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 leCentre de Génie Électrique de Lyon sur le site de l’Institut National de SciencesAppliquées (CEGELY - site INSA).

L’objectif de cette collaboration est de mettre en commun des compétencescomplémentaires afin d’étudier l’implantation des algorithmes de commandedes machines électriques AC 1.

Le projet de Recherche issu de cette collaboration a été cofinancé par leministè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éfinitionsque nous donnons de certains termes utilisés dans ce document (annexe A)afin d’éviter toute confusion.

Introduction à la mise en oeuvre des algorithmes decommande

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 ceux-ci, 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 com-mande et donc de sa mise en oeuvre. Mais ce moteur pose un certain nombrede problèmes. En dehors d’un coût important dû à sa structure complexe, cemoteur a des limitations technologiques (limitation en puissance et vitesse,création d’étincelles, usure des balais ...etc.) qui le rendent inadapté à certainesapplications (train à grande vitesse, milieu avec risque d’explosion, ...etc.).

Les moteurs à courant alternatif (synchrones, asynchrones, à reluctance va-riable, ...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èshautes vitesses. Par contre, il faut les alimenter avec un convertisseur statiqueà tension et fréquence variables pour pouvoir envisager leur emploi en vitessevariable (cf. Fig. 1 ).

FIG. 1 – chaîne d’entraînement électrique à moteur AC

Ces vingt dernières années, les progrès simultanés dans le domaine dessemi-conducteurs de puissance, de la microélectronique et des outils de mo-délisation mathématique du comportement dynamique des machines alterna-tives, ont ouvert la voie à l’utilisation des machines AC.

Promus par l’enjeu économique que représente l’utilisation de telles ma-chines ainsi que par les avantages techniques, des efforts de Recherche im-portants ont été consacrés à la chaîne d’entraînement électrique AC. Cepen-dant, cet effort s’est porté essentiellement sur l’architecture des moteurs, l’al-gorithmie de commande, la physique du semi-conducteur et les architecturesde 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 processeursavec l’apparition des microcontroleurs puis des DSP.

Toutefois, après des années de segmentation de la Recherche dans les troisdomaines qui constituent la variation de vitesse (motorisation, conversion sta-tique et commande), deux nouvelles orientations semblent s’imposer aujour-d’hui:

1. l’étude et la conception de la chaîne d’entraînement dans son ensembleen prenant en compte les interactions des différentes parties constitu-tives,

22

2. l’attention accrue portée à la mise en oeuvre de la commande. Ce phéno-mène est dû en premier lieu au fait qu’on peut aujourd’hui estimer ma-thématiquement, avec une bonne précision, des paramètres qu’il fallaitautrefois mesurer (lorsque c’était possible). Ainsi, on peut remplacer dumatériel coûteux (capteurs) par de l’électronique bon marché ou mêmeamé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 dansces orientations.

Objectifs

L’objectif de cette thèse est double. Nous voulons d’une part, offrir au concep-teur une méthodologie et des outils lui assurant une aide lors de l’intégrationde la commande, et d’autre part, appliquer cette méthodologie en intégrant unalgorithme de contrôle vectoriel pour un moteur asynchrone. Dans cette op-tique, il s’agit de:

– prendre en compte les contraintes de la mise en oeuvre dès la phase deconception algorithmique.

– repousser les choix technologiques à un stade avancé de la conceptionafin de rester relativement indépendant de la technologie et de gagner enflexibilité 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 oeuvred’algorithmes de commande afin d’en tirer les spécificités technologiqueset définir les aspects à améliorer.

– Nous avons étudié l’état des techniques et outils employés en microélec-tronique pour la conception des systèmes complexes.

– A partir des résultats précédents, nous avons proposé une méthode adap-tée à la mise en oeuvre des algorithmes de commande .

– Finalement, nous avons adapté certains modèles et outils classiques del’automatisme (Grafcet, MATLAB / SIMULINK) aux contraintes spéci-fiques à la conception de systèmes intégrés pour permettre une implan-tation 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 structured’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éci-sons é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 ac-tuelles pour l’intégration d’algorithmes. Y sont étudiées à la fois les méthodesclassiques dont on expose les problèmes vis à vis des besoins actuels, maisaussi les méthodes plus avancées qui font l’objet de nombreux travaux et quivisent à apporter des solutions aux insuffisances des approches classiques. Unparagraphe à part est consacré aux travaux ayant étudié la mise en oeuvre desalgorithmes de contrôle. Ce paragraphe nous permet de préciser les spécificitéstechnologiques qu’il importait de garder à l’esprit pendant le développementde ce travail.

Le troisième chapitre développe une méthodologie spécifique aux algo-rithmes de contrôle des machines électriques, basée sur les méthodologies ditesde 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éo-riques originales. Puis, nous décrivons les solutions pratiques mises en oeuvreet en particulier, les modèles et outils utilisés, leur emploi étant justifié par desconsidérations techniques.

Le quatrième chapitre est consacré au Grafcet. Ce modèle classique de l’au-tomatisme y est analysé pour servir de modèle de conception système. Nous yexposons en particulier l’interprétation que nous utilisons pour permettre unemodélisation fonctionnelle des systèmes de commande. A partir de cette inter-prétation et de règles que nous exposons, le modèle est analysé systématique-ment pour en déduire les implications sur l’intégration (analyse architecturalepour l’intégration matériel et estimation de paramètres physiques). Ces ana-lyses permettent ensuite au concepteur de baser ses décisions sur des donnéestangibles.

Les modèles et méthodes ayant été analysés, nous abordons finalementdans un cinquième chapitre la mise en oeuvre d’un algorithme de commandeparticulier. Après avoir suivi la méthodologie proposée précédemment, nousexposons les résultats des mesures effectuées sur le banc d’essai.

24

Chapitre 1

Chaîne d’entraînement etfonctions génériques de lacommande

1.1 Introduction

Le thème de cette thèse est principalement l’intégration optimale de la com-mande des machines AC. Mais, sous le terme de «commande», il est possible deregrouper bien des fonctionnalités. Aussi commençons-nous dans cette thèsepar circonscrire le champ des investigations et clarifier les fonctionnalités en-visagées lors de l’intégration de la «commande».

Pour ce faire, nous allons décrire la chaîne d’entraînement et la commandedu point de vue du concepteur de systèmes intégrés, c’est à dire que nousextrairons les propriétés physiques importantes pour l’intégration de la com-mande.

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 li-mites de ces modèles du point de vue physique.

Nous décrirons également les fonctions génériques que nous considéronsfaire partie de la «commande» et parlerons de quelques algorithmes particu-lièrement répandus. Ceci nous permettra de présenter quelques éléments de lathé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înede 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 moteursAC qui, comme nous l’indiquons dans l’introduction générale, nécessitent desconvertisseurs statiques (onduleur et éventuellement redresseur) pour leur ali-mentation (cf. Fig. 1, p. 22).

L’ensemble convertisseur(s)/moteur/capteurs, auquel on peut ou non ajou-ter 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éede fréquence et d’amplitude constantes (ou du moins avec des fluctuations trèsfaibles), en une tension DC constante.

Les autres éléments de la chaîne d’entraînement sont indispensables à lacommande, nous allons donc les présenter en détail.

1.2.1.1 L’onduleur

FIG. 1.1 – onduleur à trois bras

Largement décrit dans la litérature [35][40], l’onduleur a pour tâche detransformer 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éschacun à une phase du moteur et comportant deux interrupteurs de puissance.Ces interrupteurs découpent la tension DC d’entrée en impulsions de largeurvariable; le fondamental de la décomposition en série de Fourier de ce traind’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 parla 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 plusfréquent est l’onduleur triphasé à trois ou quatre bras (cf. Fig. 1.1).

FIG. 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 com-posent, selon la puissance commutée, de GTO (Gate Turn Off), de MOS depuissance ou d’IGBT (Insulated Gate Bipolar Transistor), en parallèle avec unediode (cf. Fig. 1.3). La diode permet d’assurer la continuité du courant lors duchangement de sens de celui-ci.

FIG. 1.3 – interrupteur de puissance avec IGBT et diode

Les caractéristiques de l’onduleur sont principalement définies par ces com-posants de puissance. Ceux-ci déterminent la puissance, la tension et le cou-rant maximum commutés, la fréquence maximale de commutation et le tempsmort. Ces deux dernières caractéristiques sont particulièrement importantespour nous car elles vont beaucoup influencer la conception.

La fréquence maximale de commutation est déterminée par les temps decommutation (ouverture et fermeture du composant) des interrupteurs et parle temps mort. Sur une période de commutation, un interrupteur commute aumaximum deux fois: à l’ouverture et à la fermeture (cf. Fig. 1.4). Ces commu-tations provoquent un bruit acoustique désagréable d’où la tendance actuellede 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 fermeturede son complémentaire, dépend des temps de commutation. Plus ceux-ci sont

27

FIG. 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 influenceimportante sur l’entraînement car il provoque des non-linéarités de l’onduleuret 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écisionssur la tension de sortie comme la variation des paramètres des interrupteursavec la température de fonctionnement (temps de commutation, caractéris-tiques é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 concep-tion: 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 decouple, 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 quisupporte les bobines d’induction.

Il existe une multitude d’architectures de moteurs AC selon le principe defonctionnement retenu. On citera pour mémoire les moteurs synchrones etasynchrones, les moteurs à aimants permanents et les moteurs à reluctance,la liste n’étant pas exhaustive. Les moteurs synchrones et asynchrones restenttoutefois les plus répandus.

Le moteur synchrone possède un rotor alimenté par une tension continuece 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 nerejeter aucune puissance réactive sur le réseau. Par contre, en cas de variationbrusque du couple résistant sur l’axe du moteur, comme ce moteur ne supporteque de faibles variations de sa fréquence de rotation autour de la fréquence desynchronisme, il existe un risque de «décrochage», c’est à dire que la fréquencede rotation diminue et le moteur finit par s’arrêter.

Contrairement au moteur synchrone, le moteur asynchrone dispose d’unrotor en court-circuit, non alimenté. Dans les spires des induits du rotor cir-culent 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 vi-tesse de rotation est déterminée par le couple résistant et le couple moteur. Enré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 leréseau. Parmi les moteurs asynchrones, le moteur à cage d’écureuil est particu-lièrement répandu en raison de sa structure très simple, donc robuste et faciled’entretien (cf. Fig. 1.5).

FIG. 1.5 – moteur AC asynchrone à cage d’écureuil

Les moteurs présentent eux aussi de nombreuses non-linéarités dues au va-riations paramétriques avec la température de fonctionnement et la saturationmagné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 al-gorithmes 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 capteursde vitesse ou de flux, ils permettent de mesurer les variables physiques quenécessite la commande.

Comme les autres dispositifs, les capteurs présentent des limites de fonc-tionnement et des non-linéarités dont les concepteurs de la commande et dusystème intégré devront tenir compte.

En particulier, il est un phénomène qui n’a rien de physique mais qu’ilest 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 peutprendre un nombre infini de valeurs, doit être représentée par une variablebinaire qui ne peut prendre qu’un nombre fini de valeurs. A chaque bit, on as-sociera donc un quanta qui dépend de la dynamique de la grandeur physiqueet 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“00000000” sera affecté à ��� et “11111111” à ���. La quantifica-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 fonction-nement 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 mo-dèles complexes et pas du tout appropriés pour l’établissement de lois de com-mande. D’autre part, il existe les modèles dits extrinsèques qui reproduisentle comportement du système modélisé à partir de ses entrées/sorties. Ces mo-dèles beaucoup plus simples permettent d’établir des lois de commande. Tou-tefois, le contrôle étant réalisé sur un modèle idéal des dispositifs, il faudraqu’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 plusfamiliè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 dif-fé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 fontun 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’ondu-leur idéal de tension, c’est à dire sans pertes, avec des temps de commutationnuls et sans temps mort. En fait, l’onduleur est modélisé la plupart du tempspar un simple gain.

Toutefois, certains algorithmes permettent de compenser l’effet des tempsmorts 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 lorsde 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 correctiond’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’ac-quisition des mesures et des consignes.

Or cette acceptation restreinte du concept de commande ne nous paraît pasadapté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 seulementl’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 doitinté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ôleet se limiter à l’étude de l’intégration de ce bloc est inadapté par rapport à laréalité.

Nous préférons donc définir la fonctionnalité de la commande de la chaîne d’en-traînement comme l’ensemble des fonctions génériques indispensables au contrôle del’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âchesde commande dans une application complexe et de la place de la commande dela chaîne d’entraînement. Ceci dit, nous posons cette limitation dans le cadre decette thèse afin de montrer que la méthodologie d’intégration que nous propo-sons permet de traiter des cas réels. Nous ne prétendons pas que la commandese réduit nécessairement aux seules fonctions génériques que nous décrivonsmaintenant.

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 commandede l’onduleur

A partir de la valeur des instants de commutation de l’onduleur, du tempsmort et de la période de commutation, ces fonctions génèrent les impulsionsbinaires qui commandent les interrupteurs de puissance de l’onduleur. Lesfonctions sont purement logiques et n’intègrent à priori aucune fonction al-gorithmique.

31

FIG. 1.6 – exemple de hiérarchie de commande

32

1.3.1.2 Les fonctions algorithmiques pour le calcul des instants de commu-tation

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 commutationdes composants de puissance de l’onduleur à partir d’une consigne detension

2. le bloc de contrôle proprement dit qui assure les fonctions de régulationet asservissement des grandeurs physiques contrôlées. Toutefois, si nousnous trouvons dans un schéma de contrôle en boucle ouverte, aucunerégulation ou asservissement n’ayant lieu, ce bloc se contente de calculerles 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çuespour les mettre au format binaire du système.

Par exemple, si des mots de 8 bits sont reçus d’un CAN, il faudra ajusterla 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 surune 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 sur-veillance de conditions de fonctionnement, surveillance qui n’a rien à voiravec le contrôle du dispositif. Par exemple, sur une chaîne d’entraînement, onpeut 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 produitdans les bras de l’onduleur. Cette surveillance relève de fonctions logiques quidoivent réagir instantanément aux signaux extérieurs et avoir une priorité ab-solue 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 quicommanderont l’entraînement, et de renvoyer des mesures ou des conditionslogiques 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 élec-tronique. Mais l’interfaçage peut être beaucoup plus complexe et revêtir la

1. Modulation de Largeur d’Impulsions2. Convertisseur Analogique Numérique

33

forme d’un protocole complet de communication à travers un bus partagé parune multitude de dispositifs électroniques.

FIG. 1.7 – structure de la commande

1.3.1.6 Récapitulatif

En résumé, la «commande» se compose de sa fonctionnalité principale (lecontrôle de la chaîne d’entraînement), et de fonctions annexes. Pour les besoinsde l’intégration, nous regroupons dans la suite de ce document les fonctions de

34

commande en trois groupes:

1. les fonctions algorithmiques2. les fonctions logiques3. les protocoles de communication

Cette classification des fonctions nous sera utile lors de la spécification du sys-tème.

1.3.2 Considérations théoriques

La commande des machines AC est complexe car contrairement à la ma-chine DC, les variables d’état du système ne sont pas découplées. Autrementdit, 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 (in-tensité ou tension donnée).

Pour résoudre ce problème, on applique une transformation mathématiqueaux 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 trans-formation dite de «Concordia» [4]:

� �

��

���� ����� � ����� ���

� �� � �

� � ��

� ���� �

���

��� �

�

��

Cette transformation permet de calculer les variables d’état dans un repèredans 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 échan-tillonné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 commandealgorithmique se compose en fait de deux blocs bien distincts: le bloc de contrôleproprement dit et le bloc MLI. Pour chacun de ces blocs, il existe plusieurs stra-tégies possibles, c’est à dire en fait plusieurs algorithmes, la stratégie de chacundes blocs étant choisie indépendamment.

En ce qui concerne le bloc MLI, nous citerons pour référence la MLI inter-sective, la précalculée et la MLI vectorielle, stratégies les plus communémentemployées [23]. Chacun de ces algorithmes permet d’obtenir des caractéris-tiques différentes des tensions de sortie de l’onduleur (spectre et amplitudemaximale de la tension).

En ce qui concerne le bloc de contrôle, on peut distinguer deux familles d’al-gorithmes: les méthodes scalaires et les méthodes vectorielles [35]. Dans lesparagraphes suivants, nous présentons succinctement deux algorithmes trèsrépandus: l’algorithme scalaire en boucle ouverte dit �� constant et un algo-rithme vectoriel en boucle fermée, le FOC 3.

3. Field Oriented Control

35

FIG. 1.8 – exemple de contrôle ��

constant

L’algorithme ��

constant Cet algorithme fait partie de la famille des méthodesde contrôle scalaire. Le principe de ces méthodes est d’agir sur la fréquence etl’amplitude des courants ou tensions d’entrée afin de faire varier l’amplitudeet la vitesse de rotation des vecteurs spaciaux (flux, tension ...etc.), et donc fairevarier 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 uncouple 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 tensionqui 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 enoeuvre et ne nécessite que très peu de moyens de calcul. Pour cette raison il estencore aujourd’hui très répandu. Mais la dynamique obtenue est très faible etil 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 algo-rithmes de contrôle vectoriel permettent de faire varier non seulement l’am-plitude 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 leflux de la machine et sur le courant responsable du couple de la même façonque pour une machine à excitation séparée.

Sur la figure 1.9 nous montrons le schéma bloc d’un algorithme vectorielFOC. Ces algorithmes permettent, pour une meilleur robustesse, de tenir comptedes variations paramétriques de la commande en estimant en temps réel ces

36

FIG. 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éma-tique 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 vectorielqui nous a servi d’exemple pour cette thèse. Nous y expliquons également leprincipe 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 com-mande. Nous avons notamment insisté sur les non-linéarités des dispositifs envue 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 machinesAC. En particulier, nous avons extrait différents blocs fonctionnels en précisantla tâche de chacun d’eux.

Ayant donné une vision globale de l’application, nous allons pouvoir main-tenant nous intéresser de plus près à l’intégration système de la commande.

38

Chapitre 2

Méthodologiesd’implantation d’unefonctionnalité: état de l’art

2.1 Introduction

Selon son contenu sémantique, «l’implantation de fonctionnalité» signifiefixer ou introduire une fonctionnalité dans un support physique. Par fonction-nalité, nous désignons un fonctionnement défini par un ensemble de fonctionslogiques et algorithmiques (algorithme, automate, protocole de communica-tion, ...etc.).

Comme l’indique son contenu sémantique, implanter une fonctionnalitéconsiste bien à faire calculer les opérations et réaliser les fonctions logiquespar un système physique qui se limitera ici à un système microélectronique.

Depuis quelques années, la complexité croissante des fonctions à intégreralliée à des contraintes techniques, budgétaires et temporelles toujours plusfortes (densité d’intégration, fréquence de fonctionnement, CEM 1, consomma-tion, coût de production, temps de conception, ...etc.), ont confronté le concep-teur à des problèmes qu’il n’est plus en mesure de résoudre avec les outilsclassiques.

Face à cette réalité, particulièrement prononcée dans le domaine des appli-cations télécom et audio/vidéo, des projets de recherche ont été amorcés dansle but de rationaliser, systématiser et automatiser l’implantation de fonction-nalités.

Dans ce chapitre, nous nous proposons de faire le tour des techniques em-ployées pour la conception des systèmes intégrés et de présenter les nouveauxenjeux 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 etles enjeux des nouvelles méthodes.

Puis nous analyserons les travaux effectués sur la mise en oeuvre de com-mandes de machines électriques et les spécificités que nous avons déceléesdans ces approches.

Finalement, nous présenterons une méthodologie de conception mixte logi-ciel/matériel générique ainsi que les travaux qui s’y rapportent. Nous montre-rons comment une telle approche permet d’apporter des réponses aux besoinsactuels.

2.2 Méthode courante pour la conception système

Une grande quantité d’ouvrages traitent de la conception des circuits in-tégrés VLSI 2 [19][45][54][41]. La plupart du temps, la méthodologie en elle-même n’est guère abordée, le sujet le plus communément traité étant la concep-tion à un niveau très bas (architecture des circuits, schémas logiques, modèlesHDL 3 et synthèse logique, technologie ...etc.).

Bien qu’il soit présomptueux de parler de la méthode de conception actuelledes systèmes intégrés, il est toutefois possible de trouver des points communsdans les approches de conception. Ce sont ces points que nous allons aborderdans cette section en détaillant un peu leur contenu. Nous parlerons aussi desdifficultés qu’entrainent les nouvelles contraintes de conception ce qui nouspermettra d’introduire des notions propres aux méthodes avancées de concep-tion que nous expliquons plus loin dans ce chapitre.

Développement algorithmique: il est d’abord intéressant de noter que le pro-cessus de développement algorithmique, c’est à dire dans le cas qui nousintéresse, de l’algorithme de commande, est dissocié de l’implantation decelui-ci sur silicium. De ce fait, la conception de l’algorithme ne tient pascompte des problèmes que pose son intégration. Une fois l’algorithmeconçu, il est figé. Il n’y a pas lieu de le modifier en fonction de l’implan-tation.

Spécification du système: avant de débuter la conception du système, un ca-hier des charges est établi qui fixe les caractéristiques du circuit à réa-liser. En dehors des performances physiques (vitesse de calcul, surface,consommation ...etc.), on définit également les caractéristiques architec-turales (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.). Cettespécification du système intervient sans savoir s’il sera réellement pos-sible de remplir les conditions fixées ni si les conditions de l’étude demarché se maintiendront, si bien qu’il n’est pas rare que ces spécificationssoient modifiées au cours du développement du fait des concepteurs qui

2. Very Large Scale Integration3. Hardware Description Language

40

ne peuvent atteindre les objectifs fixés ou du fait du donneur d’ordre quivoit se modifier les conditions de son marché lors de la phase de déve-loppement du système.

Technologie: aux concepteurs du système intégré, il revient la tâche de choi-sir une cible technologique. Ce choix se fait en général à priori sur descritères plus ou moins intuitifs: intégration logiciel (processeur) pour lessystèmes lents, matériel (ASIC) pour les systèmes rapides. Parfois, descibles mixtes matériel/logiciel sont prévues dès le début, en particulier sile 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ériede problèmes liés au partitionnement du système: définition de l’architec-ture (nombre de processeurs, nombre d’ASIC, capacité mémoire, nombred’E/S,...etc.), d’un protocole de communication, du contrôle d’accès auxressources 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 versl’autre: soit la migration vers le matériel de tout ce qui n’a pas pu êtreréalisé avec le logiciel (comme par exemple la logique d’interfaçage), soitla migration vers le logiciel des tâches de surveillance (fortement séquen-tielles et lentes) pour dédier le matériel au calcul parallèle à haute outrès haute fréquence. Le premier cas correspondrait typiquement aux al-gorithmes de contrôle (électrotechnique et automatique) et le second autraitement du signal.

Vérification fonctionnelle: l’intégration système pose à tout moment le pro-blème de la vérification fonctionnelle. Il faut d’abord vérifier que ce qu’ondéveloppe correspond bien aux besoins (étape de conception algorith-mique), puis que ce qu’on a intégré correspond bien à ce qu’on vou-lait intégrer. La solution communément employée aujourd’hui est la si-mulation. Toutefois, plus le système devient complexe, et plus cette ap-proche 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, ilfaudrait simuler durant ��� � ����� soit ��� � ���années!!

Outils et modèles: en matière d’outils, les langages HDL avec leurs simula-teurs/synthétiseurs associés et le langage C avec ses compilateurs, sontaujourd’hui largement répandus, offrant une certaine «indépendance tech-nologique» au concepteur, c’est à dire la possibilité de synthétiser le mêmemodèle pour différentes technologies (fondeurs et processeurs). Ces ou-tils, associés aux outils de placement/routage, permettent aussi une auto-matisation des tâches qui supprime une partie des erreurs pouvant sur-venir à ces bas niveaux de conception et autorise le développement desystèmes dont la complexité serait impossible à traiter à la main.

41

FIG. 2.1 – ALU de 32 bits

Si les points évoqués permettent de mettre en oeuvre des systèmes de com-plexité moyenne avec des performances et des coûts satisfaisants, il n’en estplus de même pour des fonctionnalités très complexes. Face à la complexitécroissante des systèmes et aux exigences techniques, budgétaires et temporellestoujours plus contraignantes, de nouveaux enjeux apparaissent:

Traiter les spécifications floues: un des nouveaux enjeux qui ne peut pas êtretraité par une approche classique est l’utilisation de ce que nous appelle-rons les «spécifications floues4 ». Par ce terme, nous désignons toutes lesspécifications qui ne sont pas parfaitement définies au début du cycle deconception et dont la définition va dépendre des résultats intermédiairesde 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 com-posants, dépendance vis à vis d’un fondeur ou d’un fabricant, durée devie et évolution du produit, délai de conception, ...etc. Aussi, ayant à trai-ter à la fois des contraintes mal définies ou ayant changé (spécificationsfloues) et un éventail de solutions techniques très vaste en constante évo-lution, le concepteur peut être amené à vouloir tester plusieurs stratégiesd’intégration après avoir défini un modèle fonctionnel unique du sys-tè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 à lalogique du même nom

42

Automatiser le cycle de conception: l’automatisation de la conception permet-trait d’une part de réduire les délais de conception, mais aussi de traiterdes complexités que l’approche manuelle interdit et de diminuer un tauxd’erreur dû au facteur humain.

Validation des systèmes: valider le bon fonctionnement d’un circuit est im-pératif durant tout le processus de conception, surtout avant l’envoieen production. Pour s’en convaincre, il suffit de se rappeler le disfonc-tionnement du «pentium». Mais, la simulation n’étant pas en mesure detraiter les fortes complexités, il faut trouver des techniques permettantsoit d’apporter la preuve mathématique du bon fonctionnement du cir-cuit, soit d’en émuler le fonctionnement.

Comme on peut le constater, la complexité des enjeux est à la mesure des fonc-tionnalités à intégrer.

2.3 Implantation de la commande de machines élec-triques AC

Avec les progrès rapides de la microélectronique et de la technologie dessemi-conducteurs de puissance, de nouveaux résultats ont pu être obtenus enmatiè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égra-tion de la commande. Nous avons classé ces travaux en deux catégories dis-tinctes que nous étudions dans les paragraphes suivants.

Nous ne nous intéresserons toutefois qu’aux travaux ayant trait à la miseen oeuvre de commandes de machines électriques AC. Nous ne nous préoccu-perons pas des machines DC pour les raisons que nous avons évoquées dansl’introduction générale.

2.3.1 l’intégration applicative

Nous regroupons sous cette catégorie les travaux ayant intégrés une com-mande dans le but de la tester.

L’objectif affiché ici n’est pas d’intégrer la commande, mais de vérifier desproprié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èstechniques de la microélectronique.

Dans cette catégorie, nous plaçons également les travaux ayant intégré unsous-ensemble de la commande (MLI généralement) sous forme de circuit in-tégré spécifique (ASIC) [29][57]. Dans ces travaux, les auteurs traitent l’archi-tecture du circuit et justifient l’emploi des ASIC par des considérations sur lestemps de calcul et sur la flexibilité de conception. En général, la position adop-té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 cal-culera les fonctions lentes (surveillance, régulation ...etc.), et une partie matérielintégrant les fonctions rapides (calcul des impulsions MLI, fonctions logiquesd’interfaçage ...etc.).

Pour l’ensemble des travaux cités ici, aucun ne présente de justification ba-sée sur des données tangibles et chiffrées pour la méthode d’intégration choi-sie. Les justifications sont d’ordre intuitif. Par ailleurs, aucune étude n’est ef-fectuée sur la possible dégradation des performances de l’application due à lamise en oeuvre de la commande, notamment dans le cas d’une intégration enarithmétique binaire virgule fixe. Les avantages apportés par une diminutiondu temps de calcul ne sont pas étudiés non plus. Dans les justifications d’em-ploi des ASIC, l’avantage apporté semble être une donnée implicite et évidentealors que nous verrons qu’il n’en est rien.

Tous ces travaux souffrent du manque de méthode systématique pour l’in-té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 sys-tème à utiliser. Si l’intégration des algorithmes vers une cible logiciel et plusparticuliè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’im-plantation mixte a été envisagée assez rapidement [2]. Dans ce travail, la partiematériel intégrait les fonctions logiques d’interfaçage entre l’algorithme et leconvertisseur de puissance (génération des signaux de commande des compo-sants de puissance).

Dans la plupart des travaux plus récents [10][30], un réel partitionnementdu système est désormais proposé. La cible matériel (FPGA ou ASIC précarac-térisé) intègre alors toute une partie de l’algorithmie de commande en sus desfonctions d’interfaçage, c’est à dire de la génération des signaux de commandede l’onduleur. Mais, dans l’ensemble, tout ces travaux envisagent un seul par-titionnement: les fonctions de surveillance et de contrôle de position, vitesse etaccé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égra-tion d’une commande de machine synchrone. Il étudie d’une part l’architecturedu 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’ap-proche se base sur deux analyses:

– une analyse fonctionnelle du système dans laquelle il différencie la «com-mande rapprochée», c’est à dire les fonctions logiques comme la généra-tion 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 detemps 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 êtreimplantées différemment. Contrairement au études précédentes, il étend leconcept de «commande rapprochée» aux fonctions de régulation des gran-deurs électriques rapides, définissant ainsi un bloc rapide, intégré sur une ciblematériel, la «commande rapprochée», contrôlé par un bloc lent, intégré sur unecible logiciel, «la commande algorithmique».

Si l’étude fonctionnelle et physique du système est intéressante en vue del’intégration, le raisonnement menant au partitionnement nous semble erroné.La distinction entre les différents paramètres (vitesse, technologie, nature desfonctions) n’est pas claire et leur influence sur le choix de l’architecture dusystème non plus. La solution proposée en est une parmis d’autres, mais rienne prouve qu’elle soit optimale.

Un autre point intéressant du travail précédent est l’étude des avantageset inconvénients de la réduction du temps de calcul et de la période d’échan-tillonage. Nous résumons ici les conclusions car il en sera tenu compte dans lasuite de ce document:

1. la diminution du temps de calcul (ici implicitement égal à la fréquence decommutation) 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’échan-tillonage ��. Cette baisse de �� autorise une augmentation de la vitessemaximale de fonctionnement des machines tout en améliorant la qualitédu contrôle par une plus faible distortion harmonique des tensions no-tamment.

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 dela régulation lors des transitoires (augmentation qui peut amener à undébordement des variables binaires entre autre), et d’autre part, par lestemps morts qui réduisent la plage de linéarité de l’onduleur. Il conseilledans la pratique de limiter la fréquence d’échantillonage par un tempsmort égal à 5% de ��.

Cette étude est particulièrement intéressante puisqu’elle montre que diminuerle plus possible la fréquence de calcul (et d’échantillonage) n’est pas nécessai-rement souhaitable et que de toute façon, il est indispensable de définir cesconstantes en fonction de l’application.

Un autre point intéressant abordé par certains travaux est l’étude de l’in-fluence de l’arithmétique binaire sur les performances de la chaîne d’entraîne-ment. Montmasson signale qu’une telle étude a été effectuée mais n’en précisepas la technique exacte. Dans [14], Aubépart étudie ce problème par une si-mulation mixte analogique/numérique de la chaîne d’entraînement avec sacommande 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 constaterl’influence de la précision et de la quantification binaire, notons que les tra-vaux cités ne débattent pas de l’influence du séquencement et de la réalisationbinaire des opérations. N’est pas abordé non plus le problème de la vérificationfonctionnelle de l’implantation.

Pour finir, nous avons relevé dans certaines études, des propositions pourmodifier l’algorithme afin de tenir compte de l’influence de l’intégration surl’application. Ainsi dans [36], Leonhard propose de calculer le PID 7 sous formecontinue et non plus discrète pour les fréquences de calcul élevées. Une propo-sition similaire à celle qu’on trouve dans [38] où Montmasson propose des al-gorithmes pour calculer les constantes des PID en fonction des temps de calcul.Dans [31], Jordà ajoute dans sa commande un bloc de compensation du tempsde calcul sur l’estimation de l’angle des vecteurs de flux pour tenir compte dela rotation de ces vecteurs entre l’instant d’échantillonage et la fin du calcul dela commande dans son microcontroleur.

Ce qui est intéressant de constater ici, c’est que l’algorithme de commanden’est plus figé avant son intégration, mais qu’il peut subir des modifications enfonction 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 denombreux projets ont vu le jour [11][52][33][15] ce qui a donné lieu à différentesapproches méthodologiques. Nous nous baserons toutefois sur les travaux deGajski et Vahid [6][5] qui synthétisent ces méthodologies d’une façon concep-tuelle.

La conception mixte (aussi appelée conception concurrente ou «codesign» enanglais) prétend développer conjointement la partie matériel et la partie logi-ciel dans un système donné et ce à partir d’un modèle fonctionnel communde haut niveau qui permet de s’affranchir d’une spécification exacte des ca-ractéristiques finales du circuit intégré. Nous préférons d’ailleurs le terme deconception mixte à celui de conception concurrente car il ne s’agit pas seule-ment de développer le matériel et le logiciel en même temps, il s’agit surtoutde les développer ensemble et donc de faire interagir la conception de l’un et del’autre.

Lorsque nous parlons de matériel ou de logiciel, nous nous référons respec-tivement aux ASIC et aux processeurs de tous types (microcontroleur, proces-seurs standarts, DSP), le «logiciel» de ces derniers étant le programme assem-bleur 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-Analogic7. 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 à la-quelle sont associées des tâches à réaliser pour mettre en oeuvre le concept. Lacommunication entre les tâches est assurée par des modèles et les contraintesassociées. La figure 2.2 présente cette méthodologie générique sous forme degraphiques qu’on pourrait appeler «flux de modèles» (modelflow) par analo-gie aux graphes «flux de données» (dataflow). Comme on peut le voir, cetteméthodologie est itérative en raison des rebouclages des résultats de tâchessur des tâches précédentes.

FIG. 2.2 – Méthode de conception mixte générique

Dans le paragraphe suivant, nous détaillons le contenu de chaque étape etla 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èmepour des entrées données, d’autre part, comment le système doit calculer sessorties, comment il doit être fait, et finalement de définir les caractéristiques ducircuit à 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 fonctionnementdes outils associés car si la méthodologie de conception mixte prétend pouvoirtraiter des spécifications de caractéristiques plus ou moins floues, la fonction-nalité du système doit elle être définie très précisément. Plus une erreur despécification est détectée tard dans la conception, plus elle coûte cher. Malheu-reusement, l’expérience montre que c’est une étape souvent très mal traitéedans les projets de conception.

La spécification fonctionnelle est un processus itératif qui comprend l’ana-lyse 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 laspécification fonctionnelle du système.

FIG. 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 com-munication, les fonctions algorithmiques, les machines d’état) et les relationstemporelles et physiques qui existent entre elles. On va donc définir un ordred’exécution et les données transmises entre elles. Pour avoir un exemple d’unetelle 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’in-dique son nom, permet de comprendre comment fonctionne un système. Ilpeut par exemple définir les sorties du système sans préciser comment celles-cisont calculées ni indiquer des temps de fonctionnement.

Pour formaliser cette étape, de nombreux travaux ont été réalisés sur leslangages de spécification formelle. Il n’existe pas de langage «parfait» permet-tant de modéliser n’importe quel type de fonction. En fait, les langages qui sesont développés au cours du temps permettent chacun de spécifier une certaineclasse 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 parcontre pour des systèmes fortement séquentiels. Il existe encore de nombreuxautres modèles pour lesquels nous renvoyons le lecteur vers les articles perti-nents [16].

L’analyse qui a eu lieu avant permet maintenant de choisir le langage demodélisation le plus approprié pour chaque classe de fonction définie. L’utili-sation de plusieurs modèles ne doit pas être un obstacle, elle permet au contrairede faciliter la modélisation et la clarifier.

Modèle de spécification Le modèle de spécification se distingue du mo-dè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èlede spécification, prenons l’exemple d’une commande vectorielle classique demachine asynchrone.

Dans un modèle de compréhension, on définirait par exemple la commandecomme une fonction permettant de calculer les courants statoriques dans unrepère tournant ���, ��� à partir des courants de ligne ��, �� et ��; puis le cal-cul d’une régulation sur ���; puis le calcul des impulsions de commande destransistors de l’onduleur (cf. Annexe A).

Dans un modèle de spécification, on va définir exactement quelle fonctionest utilisée pour la transformation de ��, �� et �� vers ��� et ���, et quels calculssont 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 decommande des interrupteurs de puissance.

Les langages à utiliser sont les mêmes que pour le modèle de compréhen-sion. Il est d’ailleurs possible, si la fonctionnalité du système est suffisammentclaire, de se passer du modèle de compréhension.

La spécification des objectifs de conception Lors de la spécification dusystè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 indica-tions 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 defautes) 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 aucoût unitaire par rapport à une production minimale prévue, à la techno-logie 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 etde test du circuit, il est par contre plus difficile de préciser exactement lescontraintes 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éesdu système, il est possible de se contenter de «spécifications floues» qui serontreprécisées lors du cycle de conception. Par contre, rappelons que la fonction-nalité 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é estde trouver la réalisation assurant le meilleur compromis entre les différentescontraintes de conception. C’est un travail évidemment très complexe et pourlequel l’automatisation est à même d’apporter une aide appréciable au concep-teur. Mais, il est impossible d’aborder de front l’automatisation des tâches quicomposent 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 appli-cation particulière: applications audio ou vidéo, télécom, automates, ...etc. Decette manière, il est possible de restreindre les recherches à un espace de solu-tions présentant déjà des propriétés-clés, requises pour l’intégration de l’ap-plication 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 unordre qui n’est pas nécessairement celui exposé. L’exploration étant un proces-sus 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èmeet de définir les ressources à employer pour réaliser la fonctionnalité vou-lue. Cette tâche est une des plus complexes à automatiser de la méthodologieenvisagée. En effet, le nombre de composants disponibles sur le marché esttrès important. Du processeur classique aux fonctions spécifiques (contrôleur

50

FIG. 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, FPGAet 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 sebasant sur des considérations liées à l’application visée [33][15].

– la seconde limite le choix des ressources système à une bibliothèque decomposants et offre au concepteur une aide à la décision par des algo-rithmes d’allocation automatique et d’estimation de performances [6].

Le partitionnement Avant de parler du partitionnement lui-même, il estnécessaire d’introduire la notion de granularité de partitionnement. La granu-larité est le plus petit objet indivisible considéré lors du partitionnement. Parexemple, si on considère un algorithme, le plus petit objet peut être une fonc-tion, ou un ensemble de fonctions. Il importe seulement que par rapport aumodèle de spécification considéré, on soit capable de définir pour chaque ob-jet son niveau de granularité. Si on utilise un modèle VHDL par exemple, onpourrait définir arbitrairement la granularité suivante:

par ordre croissant: opération arithmétique, instruction, bloc d’ins-tructions, 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 ni-veau de granularité (appelé aussi un noeud) et de déterminer l’ordre d’exécution(scheduling) des noeuds.

8. Direct Memory Access9. Fast Fourier Transform

10. Analogique Digitale/Digitale Analogique11. Programmable Logic Array

51

Il est évident que plus le niveau de granularité choisi est fin, plus l’opéra-tion de partitionnement est complexe et longue.

Le partitionnement s’effectue sur trois types d’objets: les variables qui sontassignées à la mémoire, les traitements, c’est à dire des objets qui modifientleurs variables d’entrée (boucles, instructions conditionnelles ...etc), qui sontassignés à des ressources standards ou sur mesure, et les transferts d’informa-tion qui sont affectés à des bus.

Pour effectuer le partitionnement, les informations suivantes sont néces-saires:

– 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’orienterla recherche de solution par l’importance accordée à chaque grandeurd’optimisation.

A partir de ces informations, des algorithmes sont capables d’examiner lessolutions possibles au problème du partitionnement. Différentes techniquesexistent dont l’affectation aléatoire, le groupement hiérarchique, la migrationde 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 impor-tant de la partition. Cette information servira par la suite durant l’étape desynthè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 unemême ressource logiciel devront être exécutées séquentiellement. Idem pourune 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 desopérations dans un système temps réel:

1. soit le séquencement est statique, c’est à dire que l’ordre d’exécution estfigé à la conception.

2. soit le séquencement est dynamique. Dans ce cas, l’ordre de séquence-ment est généralement basé sur une stratégie d’allocation de priorité, leproblème étant de minimiser les temps d’attente et d’éviter le blocaged’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, nousavons supposé que le partitionnement s’effectuait directement sur le modèlede 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 mo-dèle, le concepteur a souvent recours à des fonctions dans le modèle de spécifi-cation. Mais par la suite, il n’est pas évident que pour atteindre des objectifs defréquence de traitement, un appel à fonction soit efficace. Et si l’intégration dela fonction est effectuée par un module matériel spécifique, il est possible quela contrainte budgétaire ne soit pas respectée.

La transformation consiste à examiner ce genre de problème en modifiantle modèle de départ. Elle peut être de différentes natures, c’est à dire porter surle 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 dela spécification [33]:

– Au niveau algorithmique, il est souvent possible d’implanter la même fonc-tion de différentes manières. Si on prend l’exemple d’un filtre FIR 13 , ilpeut se construire sous forme de produit ou sous forme de FFT. Cettetransformation 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 implantationsdifférentes. Par exemple, il est possible de remplacer une multiplicationde constante par une série de décalages et d’additions.

– Au niveau conception logique, il est possible de réaliser la même fonctionde diverses manières. Ainsi, pour un multiplieur par exemple, il existe denombreuses implantations qu’il est possible de choisir automatiquementen fonction des contraintes de temps et de surface imposées au multi-plieur.

Lorsque la transformation porte sur la structure de la spécification, les tech-niques 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 ins-tructions en procédure.

La plupart de ces techniques sont issues du génie informatique où ellessont couramment utilisées par les compilateurs pour optimiser les codes objets.Aujourd’hui, ces techniques sont utilisées dans de nombreux outils de CAO14

[5].

L’estimation L’estimation des performances et des grandeurs d’optimisa-tion d’un système n’est pas simple dans la mesure où il faut trouver un com-promis entre précision et vitesse d’estimation. S’il faut estimer ces variablespour plusieurs milliers de solutions, on ne peut pas se permettre des temps decalcul de l’estimation trop importants.

Or la synthèse physique d’un modèle de spécification n’est pas linéaire: parexemple, la surface totale de la partie matériel ne sera pas égale à la somme dessurfaces de tous les noeuds. Ces non-linéarités sont dues en partie aux optimi-sations auxquelles se livrent les outils de synthèse logique et les compilateurs.Elles sont dues également à des structures architecturales spécifiques commele pipeline, la mémoire cache ... etc.

Du fait de cette non-linéarité, l’estimation est plus complexe. Si on désireobtenir une estimation très fiable, il faut recourir à la synthèse et la compila-tion des codes, donc se rapprocher beaucoup de l’implantation physique. Celacoûte cher en terme de temps de calcul si bien que cette solution n’est pasréalisable dans l’optique d’une exploration itérative d’un grand nombre de so-lutions.

La stratégie actuelle est donc d’estimer les grandeurs d’optimisation pouravoir un ordre de grandeur. Ces estimations sont beaucoup plus rapides etpermettent une exploration itérative.

Différentes techniques existent, permettant de tenir compte dans une cer-taine mesure des non-linéarités. La plus répandue est l’utilisation d’une librai-rie de composants et fonctions pour lesquels les grandeurs d’optimisation sontconnus précisément [47]. Lors du partitionnement, les noeuds utilisés corres-pondent à cette librairie. L’estimateur effectue alors la somme pondérée desgrandeurs d’estimation élémentaires.

14. Conception Assistée par Ordinateur

54

D’autres techniques, basées sur le même principe peuvent être trouvéesdans [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 parla 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 deslangages de programmation traditionnels type C et des langages de des-cription matériel type VHDL.

– la synthèse logique du langage de description matériel et la compilationdu langage de programmation.

Les tâches de placement/routage et l’assemblage du code objet ne sont envisa-gées que dans la mesure où les performances du système doivent être connuesavec plus de précision. Mais on considère que la réalisation physique des cir-cuits à partir d’une netlist et d’un code objet est bien maîtrisée de nos joursdans la mesure où on ne se trouve pas à la limite technologique (p.e. tech-nologies submicroniques actuellement). Il n’en n’est pas tout à fait de mêmepour les trois tâches évoquées avant. Et même si l’automatisation des tâchesde synthèse est systématique de nos jours, elle n’est pas sans poser quelquesproblèmes.

L’affinement du modèle de spécification Lors de la génération du mo-dèle de spécification, on ne s’est pas préoccupé de la gestion des mémoires, del’allocation de l’espace adressable, de l’interfaçage entre composants ni de l’ar-bitrage de l’accès aux ressources partagées. Ceci est normal puisque ce n’estqu’à l’étape de conception suivante, l’exploration, qu’on déterminera les res-sources 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 tropde problèmes et que des techniques existent pour gérer l’arbitrage de l’accèsaux ressources partagées, il n’en est pas de même pour l’interfaçage des com-posants. Remarquons au passage que dans le cas de l’arbitrage, nous nous re-streignons au cas simple où plusieurs processus (ou dispositifs) veulent accé-der en même temps à une ressource unique. Classiquement, on résout ce pro-blè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 plusieurstypes de communication entre composants (matériel-matériel, matériel-logiciel,logiciel-logiciel) et une multitude de protocoles envisageables (protocoles asyn-chrones, par adressage mémoire, ...etc.). Le choix de l’interface dépend d’unepart du composant à interfacer (composant standart ou sur mesure) et du type

55

FIG. 2.5 – Synthèse mixte

56

de données à transmettre (mot unique, trame, flux continu, ...etc.). Il peut mêmese présenter le cas de l’interfaçage de deux composants dont les interfaces sontfigées et différentes. Dans ce cas, il faut générer la description d’un transduc-teur.

L’automatisation du choix de l’interface n’est donc pas évidente.

Synthèse de code haut niveau Le partitionnement terminé, chaque noeuddu modèle de spécification est attribué à une ressource du système et le séquen-cement statique ou dynamique est défini. A partir de ces informations, il est re-lativement aisé de générer le code correspondant à chaque noeud, les noeudsmatériels générant du code de description matériel (HDL) et les noeuds logi-ciels du code de programmation classique. A partir de l’ordre d’exécution desnoeuds, on construit le séquenceur global.

Ici, peu de problèmes se posent vu que les difficultés majeures proviennentdu 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 simu-lable et synthétisable. Or l’expérience montre qu’un code produisant de bonrésultats de synthèse est lent à la simulation et vice-et-versa. La génération decode 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écifi-cation des opérateurs de la librairie.

Synthèse logique et compilation Si les techniques de synthèse logique etde compilation sont bien maîtrisées, il est quand même intéressant de noterque la synthèse comme la compilation donne de meilleurs résultats lorsque lecode traité respecte les consignes de l’outil utilisé.

Au niveau de la synthèse logique, on obtient toujours encore de bien meilleursrésultats pour un circuit décrit par transfert de registres (RTL-level) qu’au ni-veau comportemental (behavioural description).

2.4.1.4 Test fonctionnel des modèles

Nous regroupons sous test fonctionnel trois concepts qui s’appuient surdes 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 lecomportement 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 en-tré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’uneproprié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 serajamais atteint».

– l’émulation, c’est à dire le fonctionnement du circuit sur un système deprototypage.

Le test fonctionnel intervient à plusieurs reprises dans la méthodologie. Selonles cas, que nous détaillerons maintenant, on utilise soit la simulation, soit lapreuve formelle, soit l’émulation.

Simulation La simulation est traditionnellement la méthode utilisée pourvérifier fonctionnellement un système. Mais, avec la complexité croissante desfonctionnalité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 com-binaisons des vecteurs d’entrée, deviennent inabordables. On peut faci-lement atteindre des temps de simulation CPU de plusieurs centainesd’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 communica-tion). On parle alors de système «hétérogène» [1]. Ce type de systèmesrequiert l’utilisation de simulateurs capables de «cosimuler» l’ensembledes modèles de comportement présents.

La cosimulation est aujourd’hui une réalité ce qui permet de simuler l’en-semble des systèmes et non plus des bouts séparément. Par contre, les tempsde simulation restent un problème et pour cette raison, d’autres techniques ontvu le jour.

Preuve formelle La preuve formelle permet actuellement de réaliser lestâ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 transforma-tions ont été effectuées manuellement (réalisation manuelle du schémalogique d’un opérateur). La vérification d’équivalence a lieu en généralpar rapport à un modèle de référence supposé exact.

– prouver des propriétés mathématiques d’un circuit donné. Prouver despropriétés permet de vérifier qu’une fonctionnalité souhaitée du circuitest bien assurée. On notera toutefois que la preuve formelle de propriétésmathématiques est restreinte à certaines propriétés. Ces restrictions fontqu’on ne peut pas actuellement valider exhaustivement un circuit par lapreuve 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é à unesimulation.

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 sontisomorphes pour un même ordonnancement des vecteurs d’entrée. Pour prou-ver une propriété mathématique, on réduit le graphe de départ en fonction del’hypothèse donnée (p.e. «si A vaut 1») et on examine si avec l’ensemble dessolutions 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 carselon le modèle de départ employé et la formulation des propriétés, il sera ounon possible d’obtenir les résultats attendus.

L’émulation L’émulation repose sur le principe du prototypage des cir-cuits sur des systèmes standarts. L’intérêt de prototyper un circuit intégré (enprogrammant par exemple des réseaux de FPGA interconnectés) est de profiterde 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 sontpas satisfaisants. En fait, l’émulation repose sur le même principe que la simu-lation (on examine le résultat du traitement de vecteurs d’entrée) mais avec desvitesses d’exécution bien supérieures. L’inconvénient principal de cette tech-nique est le prix des émulateurs (de l’ordre du demi million de dollars pourles plus puissants). On peut bien sûr utiliser aussi des cartes spécialisées pourl’é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 nom-breux outils de conception mixte, ou se définissant comme tels. La plupart deces outils sont en libre distribution à travers le réseau.

Nous ne prétendons pas ici faire une liste exhaustive de ces outils, maisproposer 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 publica-tions 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éthodologiede conception mixte, mais qui permettent néanmoins de réaliser certaines destâches que nous avons évoquées.

15. Boolean Data Diagram

59

FIG. 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érerl’ensemble du cycle de conception mixte.

Cette constatation nous amène à un enjeu supplémentaire non évoqué jus-qu’à présent et qui fait l’objet de la thèse de A. Kalavade [33]: l’exploration del’espace de conception.

Par cette expression, A. Kalavade exprime la nécessité pour le concepteurde choisir non seulement une solution technologique (à travers notamment l’ex-ploration de l’espace des solutions) pour implanter la fonctionnalité, mais éga-lement 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 structuresde données, le format de transfert des données entre outils et l’exécution destâches de conception.

Voyons maintenant un à un les outils testés.

Ptolemy Distribué sur le réseau (binaires et sources) par le «Department ofElectrical Engineering and Computer Sciences» de l’université de Berkeley, Ca-lifornie, Ptolemy est défini par ses concepteurs comme un outil de cosimulationde 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. Parcette notion, les auteurs définissent les méthodes algébriques à utiliser poursimuler un type de fonctionnalité donné. A chaque modèle de simulation estassocié un «domaine» donné. La cosimulation consiste à simuler ensemble dif-férents domaines au sein d’un même projet. La synthèse mixte revient au mêmecar les auteurs ont défini au sein de Ptolemy, des domaines de génération decode.

Un même projet pouvant comporter plusieurs domaines de simulation etde synthèse de code (notion d’hétérogénéité), on peut modéliser des systèmescomplexes allant du système intégré mixte (matériel et logiciel) jusqu’au réseaude poste de travail communicant par des protocoles donnés.

Par ailleurs, Ptolemy permettant de changer le domaine d’appartenanced’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 luipermettant 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 librai-ries 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éerde nouveaux domaines avec leur librairie associée. En annexe E, nous propo-sons un exemple de modélisation et simulation d’un système très simple decommande.

Dans sa distribution actuelle, Ptolemy est fortement orienté vers la modéli-sation 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 conceptionmixte de contrôleurs intégrés temps réel de systèmes réactifs, c’est à dire dessystèmes réagissant immédiatement à des évènements sur leurs entrées. Desexemples typiques de telles applications sont les autocommutateurs télépho-niques, 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 (principa-lement par le langage réactif Esterel [3]). La plupart des étapes de conceptionmixte sont effectivement supportées par Polis (cf. Fig. 2.6). Par contre, pour lacosimulation, Polis a recourt à Ptolemy, et pour la preuve formelle, à VIS.

Alta Outil commercial distribué par Alta Group, une société du groupe Ca-dence, Alta repose sur les résultats de recherche obtenus avec Ptolemy et PO-LIS. Dans sa version actuelle, seul le modèle de simulation de flot de donnéesynchrones (SDF: Synchronous Data Flow) est proposé, associé avec des do-maines 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 decomposants.

2.4.2.2 Outils spécifiques testés

Les outils que nous présentons maintenant ont une fonction très spécifiqueet peuvent servir pour exécuter une des tâches de la conception mixte. Nousne parlons que d’outils, pas de modèles.

MATLAB / SIMULINK Outil de calcul mathématique basé sur le calcul ma-triciel, MATLAB propose des bibliothèques de fonctions spécifiques pour ledéveloppement d’algorithmes de contrôle sous un environnement graphique(SIMULINK), ainsi que des algorithmes standarts pour la résolution des équa-tions différentielles. Cet outil propose également un utilitaire (DSPACE) pourla 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écisionbinaire limitée (simulation par entiers).

On ne peut évidemment pas parler d’outil de conception mixte, mais MAT-LAB / 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 performanceset caractéristiques d’un circuit après synthèse. L’utilisation de scripts pour au-tomatiser 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 rechercheest à l’origine de nombreux travaux dont les résultats se concrétisent la plupartdu temps par des outils expérimentaux. Beaucoup de ces outils sont librementdistribué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 dontnous parlons suivent tous la même méthodologie générique que nous avonsdé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 Braun-schweig (Allemagne) et VULCAN, développé à Stanford (USA).

COSMOS est un outil optimisé pour l’intégration de protocoles de com-munication. Basé sur le langage SDL, il intègre le système sur un réseau deprocesseurs ou sur une architecture mixe processeur/ASIC.

COSYMA est basé sur le langage ��, une extension du C. Son domained’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égied’intégration repose sur la migration du matériel vers le logiciel en s’appuyantsur le langage de modélisation HardwareC, autre extension du C.

D’autres projets existent sur lesquels nous ne disposons pas d’informationsprécises: LYCOS de l’Université Technique de Lyngby (Danemark), CODES deSiemens (Allemagne), TOSCA de Italtel (Italie), SynDex de l’INRIA (France),SAW de l’Université de Carnegie Mellon (USA) et COWARE de IMEC (Bel-gique).

2.5 Conclusion

Avec une complexité croissante des systèmes à intégrer et des contraintestechnologiques, temporelles et budgétaires toujours plus fortes, les approchesclassiques d’intégration ne suffisent plus. Des enjeux nouveaux comme uneflexibilité accrue de la conception permettant une modification à posteriori dela stratégie d’intégration, une exploration systématique et automatique des so-lutions 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 com-mande des machines électriques ont présenti la nécessité d’aborder la concep-tion autrement, leur approche ne permet pas de résoudre les problèmes évo-qué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 del’application d’une méthodologie d’implantation. On gardera ainsi à l’espritl’importance du choix de la fréquence de calcul du système, le problème del’arithmétique binaire à employer et du séquencement des opérations vis à visde la précision binaire, et finalement, l’intérêt qu’il peut y avoir à modifier l’al-gorithme 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 fonc-tionnalité (protocoles, algorithmes, fonctions logiques, ...etc.) de façon systé-matique. L’utilisation de modèles fonctionnels, associée aux algorithmes pourl’exploration des solutions de réalisation, permet une conception plus flexible,moins liée aux spécifications technologiques et budgétaires, et donc une concep-tion plus réactive également. Les spécifications floues ne posent plus de pro-blème puisqu’il devient possible d’affiner ces spécifications en fonction desestimations sur les performances d’intégration. En ce qui concerne les outilssupportant la méthodologie de conception mixte, nous avons vu qu’un choiximportant s’offre au concepteur, lui permettant de réaliser une grande partiedes 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 algo-rithmes de commande des machines électriques AC.

64

Chapitre 3

Élaboration d’uneméthodologie d’implantationdes commandes de moteursAC

3.1 Introduction

Dans le premier chapitre, nous avons vu que les méthodes classiques d’im-plantation de fonctionnalité, caractérisées par des spécifications figées et unefaible automatisation de la conception haut niveau, ne permettent pas de ré-soudre un certain nombre de problèmes de conception (p.e. modification desspécifications en cours de conception). Ces problèmes se posent aussi pour l’in-tégration des commandes de machines électriques (cf. 2.3).

Aussi, nous avons décidé d’employer une méthodologie de conception mixtematé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 nouspré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 ma-chines 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 lamé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 etnous localisons dans la séquence des tâches à effectuer, où appliquer lasolution théorique.

65

FIG. 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 solutionsthéoriques possibles en ayant auparavant défini quelques spécificationsrestrictives propres aux machines AC afin de limiter la complexité desproblèmes.

3. Une fois les solutions proposées, nous décrivons finalement les moyenspratiques mis en oeuvre (langages et outils), et synthétisons la méthodo-logie spécifique à la commande.

Par soucis de clarté, nous avons placé au début de chaque paragraphe princi-pal, le schéma de la méthodologie générique de conception mixte sur laquellela 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éci-fiques à la conception de systèmes intégrés de commande afin de savoir plustard sur quel modèle nous aurons travailler pour traiter le problème.

3.2.1 Les spécifications floues1

Le problème des spécifications floues n’est pas particulier à la commandedes machines électriques, mais nous aborderons ce sujet pour discuter de deuxspé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 decycles d’horloge nécessaires au calcul de toutes les opérations, et �� estla période d’horloge.

– �� � � � � � ��où �� � est la période d’échantillonnage, � �� est la période de commu-tation 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 lalogique du même nom.

67

Comme on peut le constater, certains de ces temps dépendent de l’implanta-tion. Or, on se trouve typiquement dans le cas où on va spécifier les valeursqu’on devrait idéalement atteindre (en fonction de l’application), puis on défi-nira ce qu’on peut réellement faire en fonction d’estimations sur les modèles despé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ées’applique à des modèles théoriques de la chaîne d’entraînement qui ne collentqu’imparfaitement à la réalité.

Bien des non-linéarités ne sont pas prises en compte si bien que mêmeen appliquant une commande à précision infinie au système réel, un certainnombre d’erreurs demeure sur les grandeurs contrôlées (couple, vitesse, posi-tion) 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 souventun coût non justifié, dû à une arithmétique binaire virgule flottante, beaucoupplus 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 cal-cul telle que celle-ci soit supérieure à la précision physique maximale at-teinte par la chaîne d’entraînement. Autrement dit, l’implantation de lacommande ne doit pas introduire d’erreur sur les grandeurs comman-dées.

2. nous utilisons une arithmétique virgule fixe, mais nous ne nous préoc-cupons pas de la précision de l’implantation. Dans ce cas, il faut adapterl’algorithme de commande pour compenser les erreurs sur les grandeurscommandées, introduites par l’implantation.

La deuxième solution entraîne un accroissement de la complexité algorith-mique qui signifie nécessairement un surcoût de l’implantation (soit en tempsde calcul, soit en surface silicium). La première solution nous paraît la plusappropriée.

3.2.2 Partitionnement et séquencement

Dans le cas de la commande, le problème du partitionnement et du séquen-cement des opérations se révèle délicat en raison de la précision binaire qu’ilfaut assurer.

Au début de la conception, dans l’étape de spécification, on ne sait pasencore 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 requisequ’on saura quelle arithmétique choisir.

68

Dans le cas où on utilise une arithmétique virgule fixe, l’étude de la préci-sion définira la largeur des mots binaires. Par conséquent, elle affectera aussile partitionnement qui se base sur les estimations de surface de silicium et detaille de code de programmation.

Le séquencement des opérations de calcul dans l’algorithme de commandeest é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 en-tiers 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’er-reur de codage (on suppose le diviseur sans erreur de codage), parcontre, 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 comptele problème de l’influence de la précision sur le partitionnement et vérifier parexemple qu’après l’étape de partitionnement (qui inclut le séquencement desopé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 auconcepteur 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épas-sement 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 pourun système aussi complexe que la commande d’une machine électrique, cesquestions 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 à laspé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 fonctionarithmé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 nousl’avons déjà fait remarquer précédemment, plus une erreur est découverte tarddans 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 dispo-nible.

Dans la méthodologie générique, nous travaillons essentiellement avec quatremodè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 im-portante car c’est à partir de ce modèle qu’on génère le code pour le prototy-page 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 les-quels 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èmedépend du séquencement des opérations. Prenons un exemple:

Nous voulons vérifier que l’opération �������

, avec ���� " ��� nerisque 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 restric-tives sur � et sur le nombre de bits de �.

Pour effectuer la validation du système, il faudra donc utiliser le modèle despé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’algorithmebinaire. Cette propriété n’étant pas liée à un fonctionnement temporel, maisseulement aux opérations binaires et à leur séquencement, on peut effectuerles opérations de vérification sur un modèle mathématique de l’algorithmecomme 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 donceffectuer la vérification de la précision sur le modèle qui indique le séquence-ment 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ésul-tats.

– au niveau de l’exploration des solutions, on doit se pencher sur les inter-actions entre précision binaire, allocation de ressources et séquencement.

– finalement, les modèles de spécification doivent subir différentes valida-tions 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 concep-tion mixte générique est trop complexe pour être applicable directement. Lesstratégies actuelles consistent donc à appliquer des restrictions qui spécialisentla méthode pour un type d’application donnée.

Pour l’intégration de la commande, nous allons également appliquer desrestrictions.

71

3.3.1 L’arithmétique

La première restriction concerne l’arithmétique. Afin de limiter la com-plexité que suppose d’étudier l’ensemble des possibilités de réalisation d’un al-gorithme de commande machine en mélangeant des opérateurs binaires d’arith-métiques différentes, nous limiterons l’intégration à une seule arithmétique.Nous pourrions choisir l’arithmétique virgule flottante ce qui éliminerait leproblè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 niveauprocesseur, 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écisionbinaire.

3.3.2 Les ressources et l’architecture système

L’allocation des ressources est une tâche trop complexe à traiter si l’architec-ture du système n’est pas déterminée à priori. Nous fixons donc cette architec-ture 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 bienconcrètes et complexes comme la commande des moteurs du TGV par exemplené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 affec-tée.

Dans notre cas, nous avons donc décidé d’utiliser une architecture compre-nant (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 asynchronec’est à dire signifie que les dispositifs (ASIC, DSP, mémoire) ont un fonctionne-ment interne strictement synchrone, mais que la communication entre eux estasynchrone. Ceci implique d’une part que la partie matériel devra être penséede 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 seproduire sur une carte imprimée en raison de la longueur des pistes. Il est doncpréférable de renoncer à une communication synchrone, bien que plus rapide,

72

FIG. 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 composantsqui viendraient s’ajouter pour mettre en oeuvre cette architecture (mémoires deconfiguration et de programme, matériel de test ...etc.) ou pour la spécialiser(convertisseurs AD, circuits de mesure ...etc.). Les modèles des composantsprincipaux (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 solutionsthéoriques aux problèmes spécifiques à l’intégration des systèmes de com-mande.

Nous aborderons la modélisation des systèmes, la spécification de certainesdonnées comme les temps caractéristiques ou la précision de calcul et finale-ment, nous discuterons du difficile problème de la vérification et de la valida-tion de la conception, concepts que nous avons réuni sous l’expression «testdes modèles».

3.4.1 Modélisation de la commande

La commande telle que nous l’avons définie en 1.3, comporte plusieursblocs fonctionnels. En vue de la modélisation du système, il faut déterminersa nature (flux statique ou dynamique de données [12], systèmes réactifs déter-ministes [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 concepteurde l’algorithme de contrôle. Physiquement, la période de commutation est li-mitée par la fréquence de commutation maximale des interrupteurs de puis-sance de l’onduleur et par le temps mort. Définir � �� est assez empirique. Ense basant sur les résultats de Montmasson [37], on définira � �� par rapport autemps 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 cettecontrainte, il faudra revoir soit la valeur de � ��, soit celle de � �� �.

La période d’échantillonnage �� � Elle dépend du temps de calcul du sys-tè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’estpas vraiment importante. Il suffit de connaître le temps de calcul du systèmepour déterminer en cours de développement la période d’horloge. Elle se cal-cule avec le temps de calcul divisé par le nombre de périodes d’horloge néces-saires au système pour effectuer un cycle de calcul. Pour la partie logiciel, cettefré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 oumoins de � ��. Pour une première spécification du système, il suffit donc dedé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ôledu 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 tractiond’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éo-rique nécessaire pour rester en dessous du seuil de tolérance. En fait, dans unechaî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 com-mutation 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êmementdifficile pour deux raisons:

1. La première raison est mathématique. Nous ne sommes tout simplementpas capables aujourd’hui d’établir une relation mathématique simple entreles instants de commutation et les grandeurs commandées. Tout au pluspouvons-nous simuler un modèle dégradé de la commande (en limitantla précision des variables de calcul) avec un modèle de la chaîne d’en-traînement pour vérifier que dans quelques cas particuliers, la précisionchoisie 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 non-linéarités qui limitent la précision de la commande et que nous ne sommespas capable de modéliser simplement. Donc, même si nous assurions uneprécision infinie sur la définition des instants de commutation, la gran-deur 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 deconsidé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 tempsde commutation des composants et le temps mort. Pour le moteur, il faut sesouvenir de la dérive des paramètres.

Si on prend le cas d’un onduleur de puissance moyenne (5 à 20KW) avecune fréquence de commutation d’environ 20KHz, on peut estimer que la défi-nition 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érifica-tion et à la validation fonctionnelle. Contrairement aux apparences, ces deuxtechniques ne sont pas antinomiques, mais bien, complémentaires. Alors quela 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), lapreuve formelle (validation) permet de montrer que certaines conditions cri-tiques de comportement sont toujours vraies quelques soient les vecteurs d’en-trée.

En ce qui concerne la précision, nous proposons en 3.4.4.2, p. 79, une tech-nique 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 mixtepermet d’aborder progressivement la conception, elle implique aussi que leconcepteur dispose de moyens de vérification. Selon la nature du modèle envi-sagé, la vérification recherchée n’est pas la même. Elle peut être fonctionnellepour les premiers modèles de spécification, temporelle pour les modèles phy-siques.

Au total, on peut recenser jusqu’à huit modèles différents:

1. le modèle de compréhension2. le modèle de spécification3. le modèle de spécification partitionné4. le modèle de spécification affiné5. le modèle de la partie matériel6. le modèle de la partie logiciel7. éventuellement les modèles post-synthèse et post-placement/routage

Voyons pour chacun de ces modèles les techniques de vérification à notre dis-position.

Le modèle de compréhension Comme nous l’avons déjà dit dans la formu-lation de la problématique, le modèle de compréhension est nécessairementsimulé avec le moteur afin de vérifier que les fonctions de régulation et asser-vissement sont assurées.

Il n’y a pas ici de problème particulier puisque le modèle de compréhensionpeut être un modèle mathématique sous forme d’équations qui se couplerasans 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 effec-

tuant 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 mo-dè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èmesde couplage de simulateurs analogiques avec ceux à évènements discrets sontnombreux, mais dans le cas de la commande, le problème principal est d’ordrephysique. En effet, un moteur a des constantes de temps de l’ordre de la mili-seconde 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 microse-condes. Dans le pire des cas, le système est modélisé sur la base de la périoded’horloge, de l’ordre la dizaine de nanosecondes. Cette différence énorme desordres de grandeur des temps mis en jeu entraîne des simulations extrême-ment longues et coûteuses en CPU (de l’ordre de plusieurs dizaines d’heurespour quelques secondes simulées).

Il n’est donc pas envisageable d’utiliser ce type de vérification de façonsysté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 vecteursde test arbitraires. Le modèles de référence ayant été validé auparavant, il per-met 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 simulationavec un modèle du moteur, il fallait nous placer dans un cas réel pourpouvoir vérifier la cohérence de l’évolution des grandeurs contrôlées, etpar 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 co-hérence des calculs, mais seulement de vérifier qu’un calcul est juste ounon. La réalité du cas calculé n’importe pas. Un quelconque vecteur detest fait l’affaire.

2. la réduction du temps de vérification est énorme. La simulation mixteanalogique/numérique n’étant plus nécessaire, les simulations numériquesseules sont beaucoup plus rapides. De plus, on ne calcule que quelquesvecteurs. N’oublions pas qu’il ne s’agit que d’une vérification, pas d’unevalidation.

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’estle premier développé, mais celui-ci crée une difficulté majeure. En principe, lacompréhension s’effectue sur un modèle mathématique simulé en virgule flot-tante, éventuellement en virgule fixe. Mais de toute façon, le modèle de com-préhension décrit uniquement les fonctions mathématiques à calculer, certaine-ment pas les opérations binaires qui vont effectivement avoir lieu pour calculerces fonctions. Du coup, les résultats des calculs peuvent être très différents deceux que calculera le circuit numérique en raison de la précision binaire. Com-parer le modèle de compréhension avec les modèles de spécification n’a pas desens, les résultats seront nécessairement différents.

Pour pouvoir comparer des modèles, il faut qu’ils soient équivalents enterme de précision binaire. Or cette équivalence n’est assurée qu’à partir dumoment où le séquencement et la nature des opération arithmétiques binairesne 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ù lemodèle de spécification partitionné aura été validé pour servir de modèle deréférence.

Les modèles physiques haut niveau Théoriquement, la génération des mo-dèles physiques, matériel et logiciel est automatique si bien qu’il ne devrait pasapparaî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éspour optimiser la synthèse ou la compilation. On peut également vouloir s’as-surer 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éeest 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 ex-cluait toute vérification temporelle du modèle. On a pu vérifier que le séquen-cement était correct, mais le temps n’intervenait que dans la mesure où on af-firme arbitrairement que la fréquence d’échantillonnage est respectée pour lesbesoins de la simulation avec la chaîne d’entraînement.

Que le modèle soit vérifié fonctionnellement ne signifie donc pas qu’il lesoit temporellement. On peut par exemple vouloir vérifier que l’acquisitiondes mesures s’effectue au bon moment, que le temps de calcul n’excède pasla période d’échantillonnage ...etc. Une vérification temporelle est nécessaire-ment liée à la notion de modèle physique du circuit et donc aussi à la périoded’horloge. Au moment de la génération des modèles physiques, on ne connaîtpas exactement la période d’horloge; on n’en a que des estimations qu’on doitaffiner par une estimation post-synthèse.

La vérification temporelle ne nécessite pas la simulation mixte avec la chaîned’entraînement, mais seulement la simulation de quelques vecteurs critiquespour s’assurer que les contraintes temporelles fixées par l’environnement dusystème sont respectées.

Les modèles physiques post-placement/routage Nous estimons que l’équi-valence fonctionnelle est maintenue lors des tâches de synthèse et de place-ment/routage. Les vérifications effectuées sur les modèles post-placement/routagesont plutôt d’ordre analogique (p.e. respect des contraintes de fan-in et fan-out).

Nous exceptons toutefois la vérification temporelle. Le routage introduitdes retards supplémentaires qui peuvent fausser jusqu’à 100% les estimationspost-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 dansles simulations temporelles sur les modèles physiques.

3.4.4.2 La validation fonctionnelle

La validation fonctionnelle doit nous permettre d’apporter la preuve quele 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 de-vient inférieure à ����, alors la commande arrête le moteur»), ou au contraired’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 uniquementde 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 for-melle 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 plu-sieurs blocs fonctionnels. Ces blocs reposent sur des modèles de comportementdifférents pour lesquels les techniques de preuve formelle diffèrent.

Les techniques automatisées de preuve formelle concernent les machinesd’état. Le principe est de rechercher les séquences défaillantes pour une pro-priété donnée. Par contre, nous ne connaissons pas à l’heure actuelle d’outils oude 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 (pro-tocoles, 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épassementde capacité, précision binaire).

Pour valider la commande, nous allons devoir extraire d’une part les machinesd’état de la commande, et d’autre part, le séquencement des opérations avec lechemin de données associé.

Le deuxième point important de cette technique de validation est l’emploid’une stratégie «diviser pour mieux conquérir». Cette stratégie consiste à va-lider 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 limitationdes ressources CPU nécessaires.

Examinons maintenant pour chaque type de propriété les techniques em-ployées.

Les propriétés logiques Pour la validation de ces propriétés, on a recourt auxtechniques de preuve formelle «classiques»: à partir des propriétés à vérifier etd’un modèle formel de la machine d’état, l’outil de preuve formelle déterminesi la description satisfait les propriétés données. Si ce n’est pas le cas, l’outilgé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 arith-mé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 deuxproprié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 dedonnées statiques intrinsèques à la commande (constantes, format binaire, na-ture des opérations) et des données dynamiques (opérandes, éventuellementséquencement dynamique), ce qui complique énormément la validation.

Prenons le cas d’un filtre du premier ordre numérique. Son équation dis-crè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 lenombre d’itérations.

Pour surmonter la difficulté, nous employons là encore la stratégie de «diviserpour mieux conquérir». La commande algorithmique se compose générale-ment d’un assemblage de fonctions facilement identifiables telles que des filtresnumériques, des régulateurs, des multiplications matricielles, des rotations ...etc.Pour chacune de ces fonctions prises séparément, on cherche à définir des inter-valles de variation des variables binaires d’entrée et la précision atteinte pourun format binaire donné. Pour obtenir l’intervalle de variation des variablesd’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éesde la commande algorithmique) et rechercher la fonction critique qui limite lesvariables d’entrées.

En ce qui concerne la précision de calcul, on effectue de même, mais cettefois-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 nombrede séquences, problème qui pourrait se résoudre par l’automatisation de lamé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 interve-nant dans la précision du résultat final croît. La relation entre les opérandeset la précision (lorsqu’elle existe) devient rapidement trop complexe pour êtredéterminée (cf. pour exemple l’étude de la précision du CORDIC, p. 190). Restealors 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élisa-tion utilisés, puis les outils de conception associés. Nous finissons par le flux deconception qui représente le canevas sur lequel nous avons calqué l’exempled’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èlessuccessifs de conception. Pour associer à chaque modèle un langage de concep-tion correspondant, nous nous basons sur la nature de la fonction modélisée etnon 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 peutmodéliser le système structurellement et même temporellement toujours avecle même langage. On voit qu’un même langage (VHDL en l’occurence) peutservir 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. Eneffet, chaque langage de conception a été conçu dans un but précis et son utili-sation à d’autres fins se révèle souvent complexe et peu efficace. VHDL est bienadapté à la description matérielle de systèmes électroniques digitaux. Son uti-lisation pour la modélisation fonctionnelle de systèmes en arithmétique réelleou 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 fonctionmodélisée, est préférable à la modélisation globale par un seul et même langagetout au long de la conception. Ceci implique bien sûr qu’un effort particulierdoit être consacré aux interfaces entre langages et que par conséquent, une nor-malisation des protocoles d’échange de données serait fortement souhaitable.

Examinons maintenant pour chaque niveau d’abstraction, le (ou les) lan-gage 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 duprocessus global de développement du système, entre la conception de l’algo-rithmie de commande et des fonctions logiques, et l’intégration sous forme desystème. Il est peu probable qu’une seule et même personne s’occupe de l’en-semble de la conception. Plus vraisemblable est le cas où le développement estdistribué entre des spécialistes de la commande et de l’électrotechnique, et desconcepteurs de systèmes intégrés. Il faut donc trouver une forme de représen-tation simple permettant de transmettre les informations d’un domaine versl’autre.

Pour décrire complètement la commande, nous devons représenter troistypes de fonctions:

– L’algorithme de contrôle se représente clairement sous forme de schémabloc (cf. Fig. B.10, p. 173). Cette représentation présente l’intérêt d’êtrecouramment 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 signauxassocié à un graphe type réseau de Pétri ou Grafcet.

81

– Pour les fonctions logiques, nous avons choisi d’utiliser le Grafcet en rai-son de sa simplicité d’emploi et de son adéquation à la modélisationde systèmes digitaux. Nous reviendrons au chapitre 4 sur ce langagegraphique et sur l’intérêt qu’il présente dans le cadre d’une conceptionmixte.

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ésen-ter (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 don-nées, et donc, aux algorithmes de commande dont la structure fortementséquentielle et dynamique exige aussi d’importantes ressources de calcul

– lorsque les fonctions réactives de la commande sont réduites, ce qui estsouvent le cas des systèmes de commande, le Grafcet peut être utilisé entant que modèle de machine d’état. Si la complexité de ces fonctions aug-mente, 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èsappréciable pour des systèmes de commande souvent très complexes etce qui facilite le processus d’affinement des modèles.

Malheureusement, il n’existe pas actuellement d’outil permettant de simulerun 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 simu-lable, en l’occurence le script de MATLAB.

Rappelons que les modèles de spécification sont des modèles fonctionnelsqui ne décrivent pas l’architecture du système, information qui relève du mo-dèle physique. Par conséquent, le modèle MATLAB décrit des opérations bi-naires 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éalisationphysique du système (layout et code objet). Ils décrivent le système au niveaude son exécution temporelle. Les langages à utiliser doivent pouvoir modéliserfacilement le type de dispositif employé.

Nous avons donc choisi VHDL pour la modélisation du matériel et l’assem-bleur (ou le code C lorsque le compilateur est disponible) pour le logiciel.

Nous avons préféré VHDL à Verilog (HDL développé par Cadence) carVHDL étant une norme (standart ANSI/IEEE 1076-1993), les modèles sont por-tables en simulation. C’est à dire qu’ils sont simulables sur tout simulateur res-pectant 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 langagesde conception s’est basé en partie sur les caractéristiques intrinsèques des lan-gages, mais aussi sur la disponibilité et les caractéristiques des outils de concep-tion associés. C’est notamment le cas de MATLAB qui occupe une place à partdans les choix qui ont été faits. En effet, MATLAB n’est pas un outil de déve-loppement microélectronique même s’il comprend l’utilitaire DSPACE permet-tant de générer du code C, compilable sur des DSP commerciaux, à partir d’unsché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’ilnous permet de simuler conjointement un modèle binaire du système (modèlede spécification) avec un modèle analogique du moteur (sous forme de schémabloc). De ce fait, nous pouvons simuler le système dans son environnementanalogique et vérifier ainsi que le fonctionnement est correct.

Le modèle MATLAB du système se présente sous forme de fonctions écritesen langage interprété de MATLAB, un langage similaire au C. La simulationmixte analogique/numérique s’effectue sous l’environnement SIMULINK deMATLAB qui permet de modéliser les fonctions de transfert des systèmes ana-logiques par des schémas blocs.

En ce qui concerne la simulation des modèles VHDL et leur synthèse, nousavons utilisé SYNOPSYS. Cet outil s’est imposé dans la plupart des entreprisesdéveloppant des ASIC et est reconnu pour la qualité de sa synthèse. Les simu-lateurs de SYNOPSYS supportent l’ensemble de la norme VHDL-93 et offrentun environnement de déboggage puissant.

Le choix de la technologie de prototypage s’étant porté sur Altera, nousavons utilisé également l’outil de compilation et placement/routage Maxplus2.Précédemment, des tests de prototypage avec des technologies semi-customnous ont amené à utiliser également les outils de CADENCE pour le place-ment/routage. Mais les technologies FPGA présentant plus d’intérêt pour leprototypage et assurant des fréquences de calcul suffisantes, nous n’avons paspoursuivi 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 leconstater, cette méthodologie ne diffère pas fondamentalement de celle présen-té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é fonctionnellementavec le Grafcet, puis le modèle est traduit en script MATLAB pour per-mettre une simulation fonctionnelle du système. La simulation du scriptse base de fait sur l’hypothèse de synchronisme fort.

83

La simulation fonctionnelle: La cosimulation du modèle binaire du systèmeet du modèle analogique de la chaîne d’entraînement est effectuée avecl’utilitaire SIMULINK. Afin de coupler la simulation du modèle analo-gique, nécessairement dépendant du temps, avec le script MATLAB, nousinvoquons le script à chaque période d’échantillonnage, puis nous appli-quons le résultat à la période suivante. Une fonction fait office d’interfaceen générant des signaux MLI dépendant de la fréquence d’horloge. L’éva-luation du modèle de la chaîne d’entraînement est quant à elle gérée parla méthode de résolution numérique (méthode de Gear) qui utilise unpas variable. Malheureusement, en raison de la définition des signauxMLI 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’hor-loge. De ce fait, le rapport entre la constante de temps du moteur et le pasde calcul de la simulation est le plus défavorable (de l’ordre de ���). Pouraméliorer ce rapport, il faudrait évaluer la fonction d’interface avec unpas variable. La figure 3.3, p. 84, représente le banc de simulation sousMATLAB.

FIG. 3.3 – cosimulation sous MATLAB

Partionnement/estimation: Le partitionnement et l’estimation de performancessont 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 lesestimations obtenues après synthèse ou assemblage pour affiner le parti-tionnement.

Affinement des modèles: La technique retenue ici est l’emploi d’IP 2 réutili-sables. Ces blocs, en partie configurables grâce à l’emploi de paramètresgénériques, réalisent des fonctions standarts utilisables dans différentsprojets de conception (ALU, protocoles, gestion des mémoires, gestion

84

des CAN ...etc.). Durant ce projet, nous avons développé plusieurs IPréalisant des fonctions standarts utilisables pour intégrer des systèmesde commande (ALU spécifique, processeur mathématique adapté, ges-tion de CAN ...etc.).A travers le modèle Grafcet, nous pouvons faire appel à ces IP et affinerainsi 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 basantsur des règles que nous évoquons en 4.3.2. Grâce à l’utilisation d’IP etau séquencement statique des opérations, la génération de code peut seré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 fonction-nelle. Pour la simulation, nous utilisons le banc en simulation sous MAT-LAB. Le modèle MATLAB du système étant paramétré, on peut faire va-rier la longueur des mots binaires utilisés et vérifier ainsi les propriétésde précision et d’overflow.

Test logique: Pour le test formel, nous nous contentons actuellement de véri-fier quelques propriétés critiques par des simulations des modèles VHDLavec des vecteurs d’entrée appropriés. Nous n’effectuons pas de valida-tion formelle en raison de la complexité de la tâche et du manque d’outilsapproprié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 Synop-sys. Le modèle généré est un schéma de portes logiques décrit par unenetlist en VHDL, EDIF ou Verilog. Le code C, lorsqu’il est généré au lieude l’assembleur, est compilé par un compilateur spécifique au DSP.

Émulation: L’émulation des systèmes de commande est effectuée sur des cartesde prototypage spécifiques. L’une des cartes comprend un FPGA avec lescircuits d’acquisition de mesures. L’autre reprend l’architecture décrite en3.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 desdispositifs. 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 étapede la conception. La méthodologie apparaît actuellement essentiellement ma-nuelle, mais, vue l’aspect systématique des tâches à réaliser, une automatisa-tion presque totale est envisageable.

3.6 Conclusion

La méthodologie de conception mixte étant trop complexe à appliquer dansle cas général, nous avons proposé une méthode spécifique à l’intégration dessystèmes de commande.

Après avoir formalisé les problèmes spécifiques à l’intégration de la com-mande, et situé leur traitement dans la méthodologie, nous avons proposé dessolutions théoriques pour les résoudre. Nous avons également défini des res-trictions 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 sys-tèmes de commande que nous utilisons.

86

FIG. 3.4 – Flux de conception d’un système de commande

87

Tâc

hes

Mod

èles

Out

ilsSp

écifi

cati

onm

odèl

ed

eco

mpr

éhen

sion

MA

TL

AB

mod

èle

de

spéc

ifica

tion

Gra

fcet

,dia

gram

me

de

sign

aux

Part

itio

nnem

ent/

Est

imat

ion

Gra

fcet

man

uel

Affi

nem

entd

um

odèl

eG

rafc

etm

anue

lSy

nthè

sed

eco

de

mat

érie

l/lo

gici

elV

HD

L/

asse

mbl

eur

man

uel

Synt

hèse

des

mod

èles

phys

ique

ssy

nthè

sed

eV

HD

Lve

rsE

DIF

,V

HD

Lou

Ver

ilog

SYN

OPS

YS

Plac

emen

t/ro

utag

eE

DIF

/V

erilo

gA

lter

a,C

aden

ceA

ssem

blag

eas

sem

bleu

rsp

écifi

que

aupr

oces

seur

Sim

ulat

ion

fonc

tion

nelle

MA

TL

AB

,sc

hém

abl

ocSI

MU

-L

INK

SIM

UL

INK

Test

des

prop

riét

ésm

athé

mat

ique

sM

AT

LA

Bm

anue

l,si

mul

atio

nM

AT

LA

BTe

stlo

giqu

eV

HD

L/

Gra

fcet

man

uel,

sim

ulat

ion

SYN

OPS

YS

Ém

ulat

ion

cart

esp

écifi

que

TAB. 3.1 – Synthèse des outils et langages associés à la méthodologie

88

Les solutions théoriques étant définies, nous avons décrit les solutions pra-tiques mises en oeuvre ainsi que les outils et langages utilisés. La méthodologiespécifique à l’intégration des systèmes de commande a été finalement proposéede même que des perspectives pour l’automatisation de la méthode.

89

90

Chapitre 4

Implantation de laméthodologie:Solution à base de Grafcet

4.1 Introduction

Le chapitre suivant est consacré à l’utilisation du Grafcet pour la conceptionde systèmes intégrés.

Le Grafcet n’est pas prévu pour cet usage, mais il présente des caractéris-tiques intéressantes qui nous ont amené à le choisir. Afin de l’utiliser, nous pro-posons 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 Graf-cet en trois parties.

En premier lieu, nous abordons la modélisation par Grafcet, c’est à direla sémantique (graphique et textuelle) à utiliser pour la modélisation des sys-tèmes de commande et les règles et hypothèses de fonctionnement des mo-dèles.

Puis nous proposons des techniques et des règles pour l’analyse des mo-dèles en vue de l’intégration. Nous montrons en particulier comment analyserles implications matérielles d’un graphe donné (architecture, performances) etcomment 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égra-tion

En 1966, Pétri et Holt proposent un nouvel outil, appelé «réseaux de PE-TRI», 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 au-tomaticiens. Depuis, cet outil est également utilisé en microélectronique où ilsert entre-autre à la modélisation de circuits asynchrones [24] et à la preuveformelle.

En 1977, le groupe de travail «systèmes logiques» de l’AFCET 1 met au pointle Grafcet 2, outil dérivé des réseaux de Pétri. Moins puissant, surtout en ce quiconcerne l’analysabilité, il est par contre extrêmement simple, ce qui lui a valuson succès. Depuis, ce modèle a été normalisé au plan français (norme NF CO3190) et international (norme CEI 848).

Par la suite, nous faisons appel à des notions sur les réseaux de Pétri pourdéfinir le Grafcet. Pour plus de renseignements, le lecteur pourra se reporteraux ouvrages spécialisés [28][9][48].

En dehors des aspects purement mathématiques de la modélisation des sys-tèmes physiques, l’utilisation, pour la description du modèle, de langages tex-tuels ou graphiques relève souvent du goût personnel et des habitudes. Il esttoutefois indéniable que les langages textuels génèrent souvent des descrip-tions plus simples lorsque le système décrit est essentiellement dédié au traite-ment numérique de données (data-intensive en anglais). Par contre, une descrip-tion visuelle est généralement plus efficace et plus facile à comprendre lorsquele système modélisé est dédié au contrôle d’opérations (control-intensive en an-glais). Avec le Grafcet, nous avons voulu concilier un langage graphique avecune description textuelle afin de modéliser des systèmes de commande quisont à la fois dédiés au traitement numérique et au contrôle des données d’en-trée. Pour cela, nous avons repris le formalisme graphique du Grafcet tel qu’ilest précisé dans la norme, et nous nous sommes inspirés du VHDL pour décriretextuellement les actions associées au graphe. De cette manière, nous obtenonsdes modèles simples à concevoir, faciles à comprendre en vue de la documenta-tion de la conception, et suffisamment puissants pour modéliser des systèmesdigitaux au niveau fonctionnel.

Toutefois, afin que le Grafcet soit réellement utile et ne se limite pas à un for-malisme graphique pour la spécification des systèmes, il faut définir des règlesmathématiques de fonctionnement du modèle. Pour cela, nous commençonspar décrire les caractéristiques principales du Grafcet tel qu’il est défini par lanorme, 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éta-tion pour la description de systèmes microélectroniques, problèmes que noustraitons au paragraphe 4.2.2, p. 94.

1. Association Française pour la Cybernétique Economique et Technique2. Graphe Fonctionnel de Commande Etape Transition

92

Finalement, pour assurer une modélisation sans ambiguïté et éviter des er-reurs 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 certainnombre de points:

– Le Grafcet est un graphe constitué d’Étapes, représentées par des rec-tangles, 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’in-fusionabilité» des marqueurs non plus, ni d’ailleurs la notion de conflit.Si la modélisation s’en trouve simplifiée, des imprécisions apparaissentsur la représentation du «ET» et du «OU exclusif» qui peuvent être iden-tiques.Considérons par exemple le cas des figures 4.1 (a) et 4.1 (b), p. 93, où nousmodé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

FIG. 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 res-pectivement les conditions (ou réceptivités) �� et ��. Supposons que lesdeux conditions soient réalisées en même temps. Un conflit apparaît alorspour le réseau de Pétri. Par contre, ce conflit est inexistant au niveau duGrafcet. Les transitions sont franchies simultanément, activant les étapes2 et 3 et désactivant l’étape 1. Dans cette situation, ce Grafcet modélise lecomportement logique d’un «ET».Par contre, si une seule condition se réalise, une seule transition est fran-chie, 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ésenta-tion avec le Grafcet. En tout état de cause, on peut dire que la fonctionmodélisée ici est un «OU inclusif».

– Avec la disparition de la notion de marquage disparait également la no-tion 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’étatd’activation (ou non) d’une étape d’un Grafcet. Cette propriété permetsouvent de simplifier les machines d’état, notamment pour la modélisa-tion des communications entre elles.

– Le Grafcet envisage la hiérarchisation de la conception grâce aux notionsde sous-programme et de macro-étape. Ces deux notions permettent dereprésenter l’appel à des sous-graphes par des étapes spécifiques. Dansle cas des macro-étapes, l’appel au sous-graphe s’effectue une seule foislors de l’activation de la macro-étape. Dans le cas du sous-programme, lesous-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 digi-taux 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 concep-tion de systèmes asynchrones posant trop de problèmes non résolus (métasta-bilité, test fonctionnel des modèles, test physique ...etc.), nous ne l’envisageonspas actuellement.

Pour l’interprétation du Grafcet, nous considérons deux points qui sont res-tés relativement imprécis jusqu’à présent:

1. la nature des actions associées à une étape2. les règles de fonctionnement

Pour chacun de ces points, nous examinons maintenant ce que précise la normeet comment l’adapter au cas de la modélisation de systèmes digitaux syn-chrones.

4.2.2.1 La nature des actions associées à une étape

Le Grafcet étant défini à l’origine pour les automatismes industriels, la normedéfinit la structure du système modélisé comme étant composée d’une par-tie opérative (le processus) commandée par une partie commande (l’automa-tisme). Des ordres sont émis par l’automatisme vers le processus et celui-ci ren-voie des compte-rendus. Selon la norme, les actions associées aux étapes sont lesordres é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 ni-veau 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 remarqueraqu’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 duconcept d’action, mais qui permet encore de modéliser directement un auto-mate intégré sur silicium ou une machine d’état commandant un chemin dedonnées.

En définissant le type d’actions exécutées à l’activation d’une étape, nousdevons également définir les objets sur lesquel opèrent ces actions. A ce ni-veau, nous sommes obligés de faire une digression momentanée pour parlerdes notions de concurrence, de signal, et de variable tels qu’elles sont définiespar VHDL.

Afin de modéliser l’évolution temporelle des circuits intégrés, VHDL défi-nit des objets qui sont créés au début de la simulation et qui ne sont détruitsqu’à la fin. Les signaux sont un exemple de ces objets. Un signal peut prendredes valeurs de type arbitraire, mais à chaque instant de la simulation, il prendune valeur donnée. Cette notion de permanence des objets est liée à la notionde concurrence des évènements, c’est à dire des évènements qui se produisenten même temps. L’affectation de signaux est un exemple d’opération concur-rente (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 ins-tant.

A cette notion de concurrence répond la notion de séquentialité, c’est à direl’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 desobjets concurrents. A l’intérieur des processus, il est possible de définir desvariables qui sont des objets purement séquentiels et dont la valeur n’est paslié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 conceptsproposés par VHDL pour définir les objets avec lesquels nous travaillons enGrafcet:

– 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 prennentleur 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 lesrè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 nombred’étapes doivent être actives. Cette ou ces étapes initiales sont représen-tées par un double carré.

Franchissement d’une étape: Une transition entre étapes est dite «validée» sitoutes ses étapes d’entrée sont actives. Elle sera franchie si elle est validéeet si la réceptivité qui lui est associée est vraie. Le franchissement est alorsimmédiat et obligatoire.

Évolution des étapes actives: Le franchissement d’une transition entraîne l’ac-tivation de toutes les étapes immédiatement suivantes et la désactivationde toutes les étapes immédiatement précédentes.

Évolutions simultanées: Plusieurs transitions simultanément franchissables sontsimultanément franchies.

Activation et désactivation simultanées: Si au cours du fonctionnement, unemê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 ilfaut examiner également s’il est possible de modéliser sans ambiguïté le fonc-tionnement d’un système synchrone.

Le formalisme du Grafcet permet de définir une réceptivité en incluant lascrutation d’un changement d’état d’un signal, ce qui autorise la synchronisa-tion 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 correspon-dant et le diagramme des signaux. Cet exemple montre qu’il est possible demodéliser un système synchrone en se basant uniquement sur les règles d’évo-lution du Grafcet édictées par la norme. Mais en fait, ce formalisme est trèslourd à porter et surtout très complexe à interpréter. En faisant intervenir letemps, la lecture du Grafcet devient imprécise. Dans notre exemple, commentdoit-on interpréter le chargement du registre: se charge-t-il lors de l’activationde l’étape 2, lors du franchissement de la transition ou à l’activation de l’étape3? 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’hypo-thè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 ins-tantanément à moins que leur durée ne soit précisée explicitement. En adop-tant cette hypothèse, on est amené à considérer le temps comme une séquenced’é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 validesont 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, ellessont évaluées chaque fois qu’un signal du graphe est activé, c’est à dire qu’unetransition 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

FIG. 4.2 – Exemple de modélisation par Grafcet

97

besoin d’être franchie pour que des actions soient exécutées. L’exemple de lafigure 4.3 illustre ce propos.

Les étapes 2 et 3 sont validées lorsque

FIG. 4.3 – Modèle Grafcet avec branche-ment ET

la transition �� est franchie. L’actionassociée à l’étape 2 est alors exécutéedeux fois: une fois à l’évaluation de�� et ��, puis une fois à l’évaluationde �� et ��.

L’hypothèse de synchronisme as-sure aussi la notion de concurrencepuisque deux évènements peuvent soitse produire strictement en même temps(ils sont concurrents), soit à des ins-tant différents.

Pour pouvoir utiliser l’hypothèsesimplificatrice de synchronisme fort,il faut bien sûr que la période d’hor-loge du système modélisée soit supé-rieure au chemin critique du circuit.

Un autre point problématique quiapparaît à la lecture des graphes est

la définition des signaux sur l’ensemble du temps de simulation. Rappelonsqu’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 actionest exécutée lorsqu’une étape est valide. Par conséquent, à moins d’affecter leurvaleur à tous les signaux à chaque étape, les signaux d’un graphe resteront enpartie indéfinis. Il faut donc introduire un formalisme permettant de définir lesvaleurs 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 quecertaines 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’originede problèmes de conception. En effet, pour être certain que le modèleet le système aient des fonctionnements identiques, il faut que la condi-tion 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 cegenre de condition peut être difficile à vérifier. Il est donc préférable des’abstenir d’utiliser cette structure.

98

2. Comme nous l’avons déjà indiqué en 4.2.1, p. 93, les branchements en OUdes transitions de sortie pose un problème d’analyse du modèle. Pouréviter tout risque d’erreur de fonctionnement, nous restreignons doncl’usage de cette structure au OU exclusif ce qui veut dire que les récepti-vités associées à chaque transition du OU devront être exclusives.

3. Du fait de la limitation du Grafcet à la modélisation de systèmes syn-chrones, la modélisation de fonctions purement combinatoires devra uti-liser un autre type de modèle (p.e. tableau de Karnaugh)

FIG. 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 digi-taux , principalement mené en France, a abouti au développement de langagesqu’on pourrait classifier en deux catégories:

1. Les langages optimisés pour la modélisation de systèmes de traitementdes 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égo-rie. D’un formalisme relativement complexe, ces langages restent utilisés es-sentiellement au niveau universitaire.

Les langages Esterel et Statecharts [22], par contre, ont été conçus pour lamodélisation et vérification de systèmes réactifs, c’est à dire des systèmes quiré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 in-dustriels, le contrôle de voitures, d’avions et de trains, les protocoles audio etvidé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 neserait 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 lan-gage 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], ilprésente deux interprétations. Soit le concepteur choisit de baser la simulationsur l’hypothèse de synchronisme fort, soit il fait évoluer le modèle sur la based’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 peuts’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é sion 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éres-sons au partitionnement matériel/logiciel du modèle, à l’analyse architecturalede 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 mo-dèle requiert de définir d’abord la granularité de la partition. Cette notion im-plique 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érar-chique 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 attribuantpar exemple une propriété à chaque noeud/étape. Dans l’état actuel de nosconnaissances, nous sommes partisans actuellement d’un partitionnement ma-nuel soutenu par une estimation automatique des performances. Notre opinionest 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 avanta-geusement 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 desnoeuds. Ce problème n’ayant pas fait l’objet d’une étude particulière, nousnous 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 sta-tique des opérations.

4.3.2 Analyse architecturale

Si l’architecture du système et celle du processeur sont figées, il n’en estpas de même de la partie matériel, ce qui laisse au concepteur une marge demanoeuvre pour atteindre les performances souhaitées.

100

A partir du modèle Grafcet fonctionnel du système, il est possible d’explo-rer différentes solutions architecturales. Là aussi, on se basera sur les estima-tions de performance.

Classiquement, le concepteur a le choix entre deux stratégies de dévelop-pement architectural:

1. Soit il choisit d’optimiser la surface au détriment de la fréquence de cal-cul. L’architecture la mieux adaptée est alors du type microprocesseuravec une machine d’état et un chemin de données dans lequel on réuti-lise 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 calcu-ler le plus de fonctions possibles en parallèle et de minimiser le chemincritique 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 architecturauxqui permettent au concepteur de trouver la solution la mieux adaptée à sescontraintes techniques.

L’analyse architecturale du Grafcet a deux objectifs:

1. Analyser les implications architecturales du modèle. En effet, selon legraphe utilisé pour modéliser une fonctionnalité, l’implantation sera dif-férente. Aussi, pour intégrer le système avec une certaine architecture, ilpourra être nécessaire de modifier le graphe.

2. Estimer les performances des solutions architecturales possibles à partird’un modèle Grafcet donné. Grâce à ces estimations, il est possible dechoisir l’architecture voulue.

En fait, ce que nous décrivons là n’est guère différent de ce qu’effectuent cer-tains synthétiseurs architecturaux de VHDL. Celui de Synopsys par exempleutilise un modèle VHDL fonctionnel et synthétise une architecture en essayantde remplir les contraintes imposées.

Cependant, cette approche a selon nous un défaut. L’outil n’effectue pasd’analyse architecturale à proprement parler. Il synthétise un circuit choisi par-mis 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, leconcepteur 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, ilest plus judicieux d’analyser le modèle avant la synthèse en déterminant lesimplications architecturales pour, s’il le faut, modifier la description.

101

Notre analyse architecturale se base sur quelques règles dont nous énu-mérons les principales ici en les illustrant par des exemples graphiques. Nousavons 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 oudans 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’unevaleur 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ègrentsous 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êmeou à une autre variable qui n’est pas affectée à un signal, alors cettevariable n’a pas d’implantation matérielle directe mais est analyséecomme une variable architecturale (p.e. cas d’une condition boo-léene sur une transition).

(b) Une variable déclarée comme telle sur laquelle ne s’effectue quedes 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émentet 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 fonc-tion (technique du pipeline). Voir Fig. 4.10, p. 106.

(e) Si une fonction utilise un indice matériel, on ne créera qu’une seuleinstance de la fonction avec rétroalimentation, contrôlée par une ma-chine 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éeet 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 eton 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 lesressources matérielles. Dans ce cas, on effectue une seule analysearchitecturale pour les macro-étapes affectées à une intégration ma-tériel en optimisant l’emploi des ressources.

FIG. 4.5 – Implantation d’actions concurrentes

A travers cette analyse architecturale, on s’aperçoit que pour chaque graphefonctionnel, l’application des règles que nous avons citées implique une seuleimplantation architecturale possible et par conséquent, certaines performances.Cette approche présente l’avantage que le concepteur maîtrise l’architecturede la partie matériel à travers le modèle fonctionnel du système. Par voie deconséquence, il a un accès rapide à l’établissement des performances. Pouratteindre des objectifs de performance (chemin critique, fréquence de calcul,latence, surface ...etc.), le concepteur devra simplement modifier son modèleavant d’entamer le processus de synthèse. La synthèse permettra alors d’af-finer les contraintes de performance en laissant à l’outil le choix de l’implan-tation des opérateurs arithmétiques et logiques et fonction des contraintes desynthèse (p.e. valeur du chemin critique).

Cette approche présente évidemment l’inconvénient d’obliger le concep-teur à «travailler» son modèle au lieu de laisser à un outil l’initiative du choixl’architecture. Mais, vu qu’actuellement les outils de synthèse d’architecturedéfinissent des restrictions sur les modèles fonctionnels afin d’atteindre des

103

FIG. 4.6 – Inférence de registres

FIG. 4.7 – Génération de logique combinatoire

104

FIG. 4.8 – Implantation d’actions concurrentes

FIG. 4.9 – Implantation d’un «indice matériel»

105

FIG. 4.10 – Duplication d’une fonction

FIG. 4.11 – Fusion de deux bus

106

résultats acceptables, le concepteur n’est pas libéré de toute contrainte de mo-délisation. Il nous semble donc préférable qu’il maîtrise les implications de sonmodèle.

4.3.3 Estimation de performances

Estimer les performances d’un système est complexe car la synthèse, lacompilation et le placement/routage introduisent des non-linéarités qu’il esttrès difficile de modéliser. Malheureusement, le recourt à la synthèse pour esti-mer à posteriori les performances est un processus trop lent pour être efficace.Nous avons donc décidé de recourir pour l’instant à des fonctions d’estima-tion linéaires, sachant que les résultats obtenus ne fourniront que des ordresde grandeur. Cet ordre de grandeur est néanmoins suffisant pour définir desstratégies d’intégration et choisir une architecture pour la partie matériel. Latechnique 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érentesarchitectures possibles avec la consommation de ressources matérielles qu’ellesimpliquent (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 surfaceoccupée.

Cette technique marche assez bien avec les FPGA car l’influence du rou-tage sur la surface occupée est faible. Par contre, les résultats obtenus avec destechnologies précaractérisées sont loin de la réalité en raison de la présence deslignes de métal du routage. L’intérêt des résultats est qu’ils permettent d’unepart de fixer une limite inférieure de surface que le circuit occupera et d’autrepart, ces estimations facilitent le choix entre différentes options architecturalesen comparant proportionnellement les surfaces occupées.

4.3.3.2 Estimation du chemin critique

Pour cette estimation, nous reprenons le principe utilisé pour l’estimationde surface. On détermine d’abord pour les ressources matérielles employées lechemin critique pour la technologie envisagée, puis on additionne les différentschemins 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 vaudrale chemin critique dans le système réel, mais il permettent de fixer la limite defré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 parseconde que le circuit sera capable de traiter. Il faut donc estimer le nombre depé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érioded’horloge alors que pour le logiciel, un opération dure la plupart du tempsplusieurs cycles d’horloge.

Dans le cas du matériel, la durée d’une étape est déterminée par la récepti-vité 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’évolutiontemporelle. Déterminer la durée d’une étape est possible avec une assez bonneprécision.

Dans le cas du logiciel, le calcul est plus difficile car la durée des opérationsdépend du processeur choisi. Il faut donc définir pour toutes les fonctions uti-lisées, le temps de calcul en cycles d’horloge pour avoir une estimation de ladurée d’une étape.

La durée de chaque étape étant définie, on peut rechercher le chemin leplus 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 bienque leur mise en oeuvre n’a pu être que manuelle. Bien que très simples, cestechniques restent très difficiles à mettre en oeuvre manuellement lorsque lesystème envisagé est trop complexe. Les essais que nous avons fait se sont limi-tés à quelques cas simples comme l’algorithme CORDIC classique. Pour cetteraison, nous ne sommes pas en mesure de préciser la précision des estimationsobtenues par cette technique.

4.4 Synthèse de code

Le Grafcet n’étant actuellement ni simulable ni synthétisable par faute d’ou-til, 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’assem-bleur). Dans ce paragraphe, nous traitons aussi l’affinement des modèles Graf-cet pour introduire des spécifications supplémentaires comme la gestion desmémoires ou l’arbitrage de l’accès aux ressources partagées. Ce n’est qu’à par-tir des graphes affinés qu’on génère les modèles haut niveau de description dusystè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 mo-délisation fonctionnelle du système. On simulera le modèle MATLAB notam-ment 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 desopérations du Grafcet est repris tel quel dans le code MATLAB. Les réceptivitéset les branchements des graphes sont traduits par des instructions «if ... then ...else». Les opérations binaires font appel à des fonctions MATLAB qui réalisentles calculs.

Une fois le code MATLAB généré, il est interprété directement par un appelen ligne de la fonction de plus haut niveau.

4.4.2 Affinement des spécifications

L’affinement des spécifications consiste à donner des informations structu-relles sur la mise en oeuvre de certaines opérations. Par exemple, on pourradé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 stricte-ment fonctionnelles par une série d’étapes structurelles. Pour d’autres typesde 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 af-finements structurels à partir d’indications textuelles (par exemple indiquertextuellement quelle variable stocker en RAM).

4.4.3 Synthèse du code VHDL

En reprenant quelques concepts du VHDL, nous avons facilité également latraduction des modèles vers ce langage. Nous avons néanmoins le choix entredeux approches différentes: soit on génère une description de la partie matérielen se basant sur l’analyse architecturale, soit on effectue une traduction directedu graphe.

La synthèse du code VHDL en imposant l’architecture revient à écrire lecode au niveau transfert de registre (RTL 3 ). Cette description est la plus ef-ficace en terme de synthèse actuellement. Bien que les synthétiseurs logiquessont capables de traiter les descriptions fonctionnelles (behavioural descrip-tion), les résultats de synthèse restent plus performant lorsque l’architectureest précisée. Cette différence provient essentiellement du fait que ce type dedescription permet d’optimiser chaque partie de l’architecture séparément.

Lorsqu’on effectue un traduction directe du graphe, l’outil de synthèse estobligé 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 fonctionnelsayant un même comportement en simulation ne déboucheront pas sur le mêmerésultat de synthèse. Cette incertitude sur les résultats de synthèse nous faitpré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èreque 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 lagé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 noussommes intéressés au Grafcet. Nous avons montré que ce langage graphiquepouvait remplir nos attentes en apportant de légères modifications à l’inter-prétation du fonctionnement des modèles et au formalisme textuel associé à celangage. En introduisant des restrictions de modélisation, nous limitons égale-ment 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, nousavons également vu que ceux-ci n’étaient pas adaptés à la modélisation dessystèmes de commande, ce qui justifie l’adaptation du Grafcet pour ce typed’applications.

Nous avons effectué une analyse plus poussée des implications architec-turales des modèles Grafcet lors de l’intégration sous forme matériel ce qui apermis de montrer qu’on pouvait réaliser cette analyse architecturale et les es-timations associées avant la synthèse et donc améliorer la vitesse de décisionquant au choix de l’architecture.

Au niveau des autres tâches caractéristiques de la conception mixte commele partitionnement et l’estimation de performance, nous avons proposé des so-lutions possibles et montré ainsi que le Grafcet se prête à ce type de méthodo-logie.

Finalement, nous évoquons la synthèse de code haut niveau à partir desmodèles Grafcet, tant pour la simulation fonctionnelle (MATLAB) que pour ladescription haut niveau du matériel (VHDL) et du logiciel (C ou assembleur).

110

Chapitre 5

Implantation du contrôlevectoriel d’un moteurasynchrone

5.1 Introduction

Jusqu’à présent, nous avons traité les aspects théoriques de la conceptiondes systèmes de commande. Sur la base de ces résultats, nous décrivons dansce chapitre l’intégration d’un algorithme de contrôle vectoriel de moteur asyn-chrone.

Mais avant d’aborder le sujet, il nous faut donner quelques détails sur ledéveloppement historique du projet. A l’origine, le projet avait pour but d’étu-dier 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 ense basant sur un algorithme déjà intégré sur microcontrôleur afin d’effectuerdes comparaisons. C’est au cours de ce travail que s’est imposé la nécessité deformaliser une méthodologie pour aborder la conception des systèmes de com-mande. 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’envisa-geons 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èmesde 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 asyn-chrone en se basant sur la méthodologie de conception mixte.

3. Finalement, nous montrons quelques résultats expérimentaux de tests ef-fectués sur un prototype partiel de l’ASIC de commande.

111

FIG. 5.1 – Méthodologie de conception mixte

112

Les développements théoriques relatifs aux algorithmes utilisés (algorithme decontrô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 com-mande

Nous rappelons rapidement ici les enjeux de la conception des systèmes decommande, c’est à dire les problèmes spécifiques et les objectifs généraux, afinde 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 para-mè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 lesystème ou pour l’intégrer vers différentes cibles technologiques.

– Nous devons adapter les algorithmes implantés (sans modifier la fonc-tionnalité) 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 defonctionnement 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éthodolo-gie de conception mixte. Pour cette raison, chaque paragraphe de cette partiecorrespond à une tâche de la méthodologie. Pour une meilleur compréhension,nous avons placé, dans la marge de chaque paragraphe principal, un schémade 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 moteurasynchrone de 4 KW. Ce moteur est alimenté par un onduleur dont la tensioncontinue d’entrée ���� est assurée par huit batteries au plomb connectées ensé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 fonc-tionnalités différentes:

1. L’acquisition des mesures et de la consigne: ce bloc a pour fonction degérer les convertisseurs analogique/numérique, c’est à dire de générer

113

FIG. 5.2 – Banc de test de la commande du moteur asynchrone

les signaux de commande de ces dispositifs, de stocker les données reçuset de les transmettre au bloc de traitement.

2. Le traitement des mesures et de la consigne: les données analogiques ac-quises par le bloc précédent doivent être traitées et mises au format bi-naire utilisé. Le bloc de traitement se charge de cette opération. Le détaildes opérations de traitement est explicité en annexe F.

3. l’algorithme vectoriel: c’est la fonction principale de la commande. Cetalgorithme permet de contrôler le moteur qui entraîne la chaîne de trac-tion électrique. Il reçoit en entrée les mesures au format binaire choisi etcalcule les tensions à appliquer au moteur asynchrone. On trouvera lamise 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 in-diqué en annexe, le contrôle vectoriel permet de réguler indépendam-ment le couple et le flux. La consigne de couple est donnée par une com-posante du courant statorique (��) alors que le flux dépend du courantmagnétisant ���, ce dernier étant une variable interne du système decommande.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 aucouple résistant, l’algorithme se charge de diminuer le flux (opérationdite de «défluxage») lorsque le moteur atteint sa vitesse nominale afin dene pas dépasser la puissance nominale du moteur.

114

4. L’algorithme MLI vectoriel: Cet algorithme sert d’interface algorithmiqueentre l’algorithme vectoriel et le bloc de génération des impulsions decommande de l’onduleur. L’algorithme MLI vectoriel calcule les instantsde commutation des interrupteurs de l’onduleur à partir des consignesde tension reçus de l’algorithme de contrôle vectoriel. Les équations decet algorithme sont développées en B.2, p. 164.

5. La génération des impulsions de commande de l’onduleur: la fonction dece bloc est de générer les signaux physiques de commande de l’onduleurà partir des instants de commutation que lui communique l’algorithmeMLI. C’est en quelque sorte l’interface du système de commande avec lemonde analogique.

6. La sécurité de fonctionnement: pour protéger la chaîne d’entraînementcontre des disfonctionnements destructifs, le système de commande in-clus une fonctionnalité de sécurité qui gère essentiellement l’interrup-tion du système et la génération des signaux d’erreur. On protège ainsila chaîne d’entraînement contre les court-circuits dans l’onduleur, contreune baisse excessive de la tension continue d’entrée de l’onduleur et ongè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 blocen vue de la modélisation fonctionnelle. Cette topographie n’est nullement unepréé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 phy-sique du système, nous avons résumé des spécifications physiques du systèmesachant 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 sontindiqués en annexe C.

– L’alimentation: assurée par huit batteries au plomb de 12V chacune, ellevaut au plus 96V.

– La fréquence d’échantillonnage: elle doit au moins valoir 2 KHz, soit unepériode de 500 %s.

– La fréquence de commutation: elle est au moins égale à la fréquence d’échan-tillonnage et en principe quatre fois supérieure, soit environ 8 KHz. Sil’intégration le permet, on souhaite monter jusqu’à 16 KHz, c’est à dire lafréquence de l’inaudible.

– Le temps mort: il est fixé à environ 3 %s.

115

FIG. 5.3 – Topographie du système de commande

116

– Les capteurs de courant: deux capteurs à effet Hall servent à mesurer lecourant dans les enroulements statoriques. Ils doivent être alimentés sous12V ce qui place le point de repos à 6V.

– Le capteur de vitesse: il est constitué d’un disque denté de 18 dents. Lesdents interceptent les faisceaux infrarouges de deux optocommutateursqui génèrent deux signaux carrés déphasés. Ils doivent être alimentéssous 5V.

– Le capteur de tension d’alimentation ����: il est constitué par un optocou-pleur 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 circuitsde mesure, il fallait conserver la compatibilité avec les signaux TTL en raisondes 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 ten-sions des batteries, c’est à dire au minimum 12V. Ceci est dû au fait que lacommande était prévue pour être embarquée sur un véhicule électrique danslequel 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, nousavons décrit un modèle de compréhension de l’algorithme de contrôle afind’étudier son fonctionnement. Une fois l’algorithme de contrôle maîtrisé, nousavons développé les modèles de spécification de l’ensemble des blocs de lacommande.

Le modèle de compréhension Ce modèle reprend le schéma bloc de l’algo-rithme de contrôle (cf. Fig. 5.4, p. 118). Nous avons décrit ce schéma bloc sousMATLAB et simulé le contrôle avec le modèle de Park du moteur. Les résul-tats de la simulation montrent le comportement idéal du moteur avec la com-mande vectorielle. Les figures 5.5a-c et 5.6a-c, p. 119 et p. 120, montrent desgrandeurs caractéristiques du moteur lors d’un démarrage. On observe claire-ment que le couple «suit» la consigne donnée par le courant �� (Fig. 5.6-a etFig. 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 ducourant magnétisant (Fig. 5.6-b) et du couple. La période de 0 à 0.5 secondescorrespond à l’établissement du flux. Durant ce laps de temps, aucune consignede couple n’est appliquée. Les niveaux de courant et de tension enregistrésservent à 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’échan-tillonnage sur les grandeurs caractéristiques du moteur. En effet, cette constante

117

FIG. 5.4 – Schéma bloc de l’algorithme de commande118

0 1 2 3 4 5 6 7 8 9 10−80

−60

−40

−20

0

20

40

60

80

(a) Courant statorique �� (en A)

0 1 2 3 4 5 6 7 8 9 10−100

−80

−60

−40

−20

0

20

40

60

80

100

(b) Tension sur une phase du moteur �� (en V)

0 1 2 3 4 5 6 7 8 9 100

20

40

60

80

100

120

140

160

180

200

(c) Vitesse de rotation du moteur �� (en rad/s)

FIG. 5.5 – Simulation de l’évolution des grandeurs caractéristiques du moteur en fonc-tion du temps (en s) lors d’un démarrage

119

0 1 2 3 4 5 6 7 8 9 10−10

0

10

20

30

40

50

60

70

(a) Consigne de couple ��� (en A)

0 1 2 3 4 5 6 7 8 9 100

2

4

6

8

10

12

14

(b) Courant magnétisant estimé ��� (en A)

0 1 2 3 4 5 6 7 8 9 100

5

10

15

20

25

30

35

40

(c) Couple moteur �� (en N)

FIG. 5.6 – Défluxage du moteur (fonction du temps en s)

120

est particulièrement importante pour la conception du système puisqu’à par-tir de sa valeur, on détermine le temps de calcul maximum du système ainsique l’ensemble des autres temps caractéristiques (cf. 3.2.1.1). Les figures 5.7(a-f) p. 122, montrent que la diminution de la période d’échantillonnage réduit lespics de courant et de tension.

Modèle de spécification Dans la topographie fonctionnelle du système, nousavons dégagé la nature des différentes fonctions de la commande. En dehorsde la fonction de sécurité de fonctionnement, la nature des fonctions est com-patible avec une modélisation par le Grafcet. En ce qui concerne la sécuritéde fonctionnement, la spécification fonctionnelle est suffisamment simple pourque 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 blocMLI (Fig 5.9, p. 124). Pour plus de clarté, ces modèles restent au niveau desmacro-étapes. On peut voir que le modèle de la commande reprend le modèledu 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 despécification MATLAB (traduit du Grafcet) des différents blocs.

Dans le cas de la commande, le modèle du moteur et le modèle fonctionnelbinaire du système de commande ont été cosimulés pour vérifier que la fonc-tion de contrôle était assurée. Remarquons que nous avons rencontré les pro-blèmes que nous évoquions à propos de la cosimulation analogique/numérique:pour simuler deux secondes du démarrage du moteur, environ 48 heures de si-mulation ont été nécessaires sur un pentium 133MHz. On peut comparer celaaux dix minutes que durent les cosimulations du modèle de compréhensionavec le modèle du moteur (cf. 5.3.1.5).

Ces simulations binaires du modèle de spécification de la commande, donton présente les résultats aux figures 5.10(b,d,f) et 5.11(b,d,f), utilisent des motsbinaires 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 MAT-LAB, une fonction d’interface génère les vecteurs de tension MLI à partir desinstants de commutation calculés par l’algorithme. Pour activer le modèle ana-logique du moteur sous MATLAB, il faut que ces signaux de tension soit in-dexés sur le temps. Pour cette raison, chaque point de la courbe de tensiongé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 signauxde tension étaient définis sur 100 points, ce qui correspond à une horloge de5,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

0 0.1 0.2 0.3 0.4 0.5 0.6−40

−30

−20

−10

0

10

20

30

(a) Courant �� pour 530�s (en A)

0 0.1 0.2 0.3 0.4 0.5 0.6−40

−30

−20

−10

0

10

20

30

(b) Courant �� pour 300�s (en A)

0 0.1 0.2 0.3 0.4 0.5 0.6−15

−10

−5

0

5

10

(c) Tension sur une phase �� pour530�s (en V)

0 0.1 0.2 0.3 0.4 0.5 0.6−15

−10

−5

0

5

10

(d) Tension sur une phase ��pour 300�s (en V)

0 0.1 0.2 0.3 0.4 0.5 0.60

2

4

6

8

10

12

14

(e) Courant magnétisant estimé��� pour 530�s (en A)

0 0.1 0.2 0.3 0.4 0.5 0.60

2

4

6

8

10

12

14

(f) Courant magnétisant estimé��� pour 300�s (en A)

FIG. 5.7 – Grandeurs caractéristiques du moteur en fonction du temps (s) pour deuxpériodes d’échantillonnage différentes

122

FIG. 5.8 – Modèle de spécification de la commande

123

FIG. 5.9 – Modèle de spécification du bloc MLI

124

pour ces conditions de simulation, l’équivalence fonctionnelle entre le modèlede 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 degé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 de80V. La période de commutation � �� vaut toujours 530%s mais les vecteursde tension sont définis cette fois sur 500 points.

Finalement, nous avons simulé les blocs d’acquisition et de traitement desdonné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 departitionner le système. Par contre, il est nécessaire d’effectuer les autres tâchesassocié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 laconception 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égrationde la commande ce qui doit être fait maintenant au niveau de l’allocation desressources.

Pour l’intégration sous forme matériel, nous avons décidé d’utiliser un FPGAau lieu d’une technologie semi-custom. Ce choix est dicté par la flexibilité deprototypage qu’offrent cette technologie, mais aussi par le fait qu’il est possiblede trouver actuellement des FPGA de très grande capacité tant au niveau dunombre de portes (jusqu’à 250.000 portes pour la famille Flex10k250 d’Altera)qu’au niveau fréquence d’horloge (environ 50MHz pour la famille Flex10kBd’Altera). Par ailleurs, ces dispositifs offrent la possibilité d’intégrer directe-ment des ROM et des RAM ce qui élimine la nécessité de les prévoir en boîtierexterne. Finalement, grâce à l’utilisation de VHDL pour la modélisation de lapartie matériel, il a été envisagé d’intégrer à terme le système en technologiesemi-custom après avoir effectué les tests sur FPGA. Dans l’immédiat, nousavons choisi d’utiliser un Flex10K100A d’Altera, dispositif intégrant environ100.000 portes logiques.

Au niveau des convertisseurs analogiques/digitaux, nous avons utilisé desTLC0831 de Texas Instruments.

5.3.3.2 Transformation algorithmiques

Dans cette étape, nous analysons les primitives mathématiques utiliséespour déterminer quels algorithmes binaires nous permettront de calculer ces

125

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8−80

−60

−40

−20

0

20

40

60

80

(a) Courant �� (en A)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8−80

−60

−40

−20

0

20

40

60

80

(b) Courant �� (en A) - simulationbinaire

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8−25

−20

−15

−10

−5

0

5

10

15

20

25

(c) Tension �� (en V)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8−30

−20

−10

0

10

20

30

(d) Tension �� (en V) - simulationbinaire

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8−2

0

2

4

6

8

10

12

14

(e) Vitesse de rotation �� (enrad/s)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8−2

0

2

4

6

8

10

12

14

(f) Vitesse de rotation �� (enrad/s) - simulation binaire

FIG. 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 despécification (droite)

126

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.80

2

4

6

8

10

12

14

(a) Consigne de flux ��� (en A) -simulation binaire

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.80

2

4

6

8

10

12

14

(b) Courant magnétisant estimé��� (en A)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.80

2

4

6

8

10

12

14

(c) Courant magnétisant estimé��� (en A) - simulation binaire

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8−5

0

5

10

15

20

25

30

35

(d) Couple moteur �� (en N)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8−5

0

5

10

15

20

25

30

35

40

45

(e) Couple moteur �� (en N) - si-mulation binaire

FIG. 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

0 50 100 150 200 250 300 350 400 450 5000

0.5

1

0 50 100 150 200 250 300 350 400 450 5000

0.5

1

0 50 100 150 200 250 300 350 400 450 5000

0.5

1

FIG. 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 desconsidé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ématiquessuivantes:

– 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 cosinussuivie de multiplications et d’additions.

– la division: on peut utiliser soit directement un diviseur, soit utiliser l’al-gorithme CORDIC généralisé.

– la multiplication: comme pour la division, on peut avoir recourt soit à unmultiplieur, soit utiliser l’algorithme CORDIC généralisé.

– La multiplication par des constantes: nous séparons cette opération de lamultiplication simple car la multiplication par des constantes pose desproblèmes que nous évoquons en D.4. Pour résoudre cela, nous propo-sons l’utilisation d’un algorithme de multiplication itérative, l’autre solu-tion é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 pardes opérateurs spécifiques (circuits combinatoires), soit par une séquenced’opérations (additions, soustractions ...etc.).

A ce stade de la réflexion, nous ne savons pas encore en principe quelle stra-tégie architecturale nous suivrons (calcul parallélisé ou séquentialisé). Nousverrons plus en avant que nous avons opté pour une architecture relativementséquentielle pour minimiser la surface occupée. Pour cette raison, nous avonschoisi de recourir à l’algorithme CORDIC lorsque c’était possible ainsi que lesalgorithmes séquentiels permettant de réutiliser le plus possible les ressourcesmaté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 sonttrop complexes pour apporter la preuve formelle que la précision de calcul estsuffisante (format ���� et 19 bits internes pour le CORDIC) et qu’il n’y a pasde risque de débordement. Nous avons donc effectué quelques études pour lesblocs 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édem-ment (cf. Fig 5.11 et 5.11). Nous n’apportons donc pas les preuves mathéma-tiques 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ériodesné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 dontcertaines durent plus d’une période d’horloge lorsqu’elles correspondent à desopérations effectuées par des blocs arithmétiques (CORDIC, multiplication deconstante, ALU) ou qu’elles requiert des opérations supplémentaires définiespar l’affinement du modèle (lecture/écriture de RAM, de registres ...etc.). Nousavons compté 13 multiplications par constante et 17 opérations CORDIC, cequi correspond au maximum à respectivement 208 et 323 périodes d’horloge.Certaines opération s’effectuent en parallèle (p.e. CORDIC et multiplicationpar constante) si bien que le nombre total estimé de périodes d’horloge d’unepériode de calcul de la commande est inférieur à ��� � ��� � ��� � ���. Parconséquent, on peut admettre un temps maximum de calcul de 1000 périodesd’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 etaffiner le modèle de spécification. A partir de la description affinée, on pourragé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ûtde l’ASIC et donc de la surface silicium (moins de 100.000 portes logiques). Lalimitation à cette stratégie a été de respecter la contrainte de chemin critiquefixée à 500ns.

L’analyse des primitives mathématiques a montré que beaucoup d’opéra-tions complexes pouvaient se réaliser à partir du même algorithme. Pour mi-

129

nimiser le nombre de ressources matérielles, nous avons donc utilisé l’algo-rithme CORDIC pour ces opérations. Les autres opérations (multiplication pardes constantes, opérations logiques) utilisent des algorithmes qui peuvent éga-lement s’intégrer sur une même structure matérielle. Nous avons donc égale-ment développé une ALU spécifique.

FIG. 5.13 – Architecture de l’ASIC de commande

Néanmoins, l’analyse du Grafcet montre également que certaines opéra-tions peuvent s’effectuer en même temps. Pour minimiser le temps de calcul,nous avons donc choisi une architecture globale permettant une utilisation enparallèle de l’ALU et du CORDIC.

130

Un autre point important pour l’architecture est le nombre de constanteset de variables de l’algorithme. En effet, vu leur nombre élevé, nous avonsdécidé d’allouer les variables à une RAM et les constantes à une ROM. Ce pointprésente d’ailleurs l’intérêt qu’il devient possible d’adapter l’ASIC à un autremoteur 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 encompte les caractéristiques de l’architecture. On modifie le modèle afin d’in-troduire 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 puisquele 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 au-paravant: CORDIC, ALU, génération des signaux MLI ...etc. Du coup, la syn-thèse de code VHDL à partir du modèle Grafcet de la commande s’est réduitessentiellement à la génération de la machine d’état globale qui commande lesinstances des IP.

Cette machine d’état comporte 453 états ce qui la rend plutôt illisible, contrai-rement 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 formatbinaire employé. D’autre part, le modèle VHDL de la ROM génère automa-tiquement son contenu binaire à partir des constantes caractéristiques de lacommande (paramètres électriques du moteur, temps mort, fréquence d’échan-tillonnage ...etc.). Grâce à ces paramétrisations, des modifications de certainesspécifications, comme le changement du moteur par exemple, ne posent pasde problèmes.

5.3.4.4 Vérification fonctionnelle

Pour vérifier fonctionnellement le code VHDL, nous avons opté pour unestraté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 sys-tème lui-même.

2. nous optons pour la stratégie de comparaison de modèle, c’est à dire quenous prenons le modèle fonctionnel sous MATLAB comme référence etcomparons les résultats intermédiaires pour une série de vecteurs de testarbitraires.

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 decalcul le plus long, nous avons vérifié que celui-ci n’était pas supérieur à 1000périodes d’horloge.

5.3.4.5 Vérification temporelle

Pour ce test du système, nous avons développé des modèles VHDL tempo-rels des convertisseurs analogique-digitaux, de la RAM et de la ROM, ces deuxderniers dispositifs n’étant pas synthétisés sous Synopsys, mais directementsous 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) endonnées binaires.

Lors de la simulation, le modèle de la ROM lit un fichier de constantesspécifiques de la commande (résistances, temps ...etc.) et génère le fichier desmots binaires dans un format accepté par Maxplus2. Finalement, le modèle dela RAM, lors de l’activation d’un signal, envoie son contenu vers un fichier.

FIG. 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é sousMaxplus2 d’Altera. La surface de l’ASIC est de 4480 LC 2 soit environ 89.000portes logiques. La RAM et la ROM utilisent 2582 bits de l’espace mémoiredisponible, soit un équivalent de 322 octets. Le chemin critique estimé par Al-tera vaut 230 ns.

Les estimations de Synopsys donnaient 4239 LC soit une erreur d’estima-tion de 0.05%. Le tableau 5.1 résume les estimations de surface de Synopsyspour l’ensemble des blocs de l’ASIC. Un fait notoire est l’importance relativede la machine d’état globale de l’ASIC et la taille réduite du processeur COR-DIC.

2. Logic Cells

132

Bloc surface (en LC) quota de surface occupéCORDIC 1203 28%ALU 908 22%Machine d’état 935 21%Acquisition échantillons 235 5%Génération des impul-sions de commande

472 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écia-lement conçue à cet effet. Cette carte comprend un FPGA Flex10K100A d’Al-tera, l’ensemble des circuits analogiques pour l’acquisition des mesures et dela consigne, les connecteurs et buffers pour la commande de l’onduleur, unehorloge à 50MHz et les circuits de configuration du Flex (cf. Fig 5.15). Notonsque le Flex10K100A est compatible pin à pin avec des dispositifs de la mêmefamille, mais de capacité différente, ce qui permet d’envisager de réutiliser leschéma de la carte pour des dispositifs différents. Cette option est intéressantedans l’optique de la méthodologie de conception mixte où le dispositif à utili-ser 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 decontrôle V/f a pu être testée. Cet algorithme génère la consigne de la MLI enboucle ouverte. L’intégration de la MLI et du contrôle V/f a été effectuée enutilisant les mêmes ressources matérielles et la même architecture que l’ASICde commande vectorielle. Seule la machine d’état globale diffère.

Grâce à ces tests, nous avons pu montrer le fonctionnement correct desblocs fonctionnels (CORDIC, ALU, acquisition des échantillons ...etc.) et del’architecture. Nous avons pu vérifier également que les estimations de chemincritique étaient correctes puisque l’ASIC fonctionne avec une période d’hor-loge de 320ns.

Sur les figures 5.16 et 5.17 on peut voir la mesure des deux signaux de com-mande d’un bras de l’onduleur (signaux complémentaires) ainsi que le tempsmort donné par rapport au nombre de périodes d’horloge (10 périodes).

Pour vérifier que l’onduleur était commandé correctement, nous avons fil-tré la tension de sortie de l’onduleur par un filtre RC avec une fréquence decoupure de 1KHz. Le courant filtré à 50Hz, mesuré sur la résistance (1M�), estdonné figure 5.18. Remarquons que les tests avec l’onduleur on été effectuéssous une tension réduite pour prévenir les risques de claquage des IGBT encas de court-circuit dû à un défaut de fonctionnement de l’ASIC. Cela explique

133

50 M

Hz

horl

oge

BP1

BP2

bout

ons

pous

soir

s

conn

ecte

ur d

eco

nfig

urat

ion

bitb

last

erJ13

conn

ecte

urD

B25

BP4

BP3

bout

ons

pous

soir

spo

tent

iom

etre

de c

onfi

gura

tion

EE

PRO

M E

CP1

conn

ecte

ur

0V

alim12

V

conn

ecte

urco

nnec

teur

pou

r le

choi

x du

type

de

FLE

X10

KA

banc

de

com

mut

ateu

rs

poin

ts d

e m

esur

e

1

et C

AN

en f

orm

eC

ircu

it de

mis

e

et C

AN

en f

orm

eC

ircu

it de

mis

e

et C

AN

en f

orm

eC

ircu

it de

mis

e

23

45

67

81

en f

orm

eC

ircu

it de

mis

e

de la

vite

sse

Ia Ib

Isq

PHA

Isq

Ia Ib

PHB

PHA

PHB

conf

igur

atio

n

Buf

fers

des

sign

aux

de c

omm

ande

6 bi

ts6

Ia_m

TO

P

SEN

S

Ib_m

Isq_

m

Ia_m

Ib_m

Isq_

m

TO

P

SEN

S

6 bi

ts

FIG. 5.15 – Synoptique de la carte de prototypage

134

FIG. 5.16 – Signaux de commande d’un bras de l’onduleur

FIG. 5.17 – Temps mort en fonction de la période d’horloge

135

la faible valeur du courant enregistré.

FIG. 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, nousavons montré dans ce chapitre comment intégrer la commande vectorielle d’unmoteur 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 conceptionspécifique à la commande en utilisant notamment les modèles et outils asso-ciés.

Grâce à la spécification fonctionnelle du système par le Grafcet, la plupartdes résultats des tâches de conception ne dépendent que des spécifications. Dece fait, le même modèle Grafcet de la commande peut servir pour intégrer lesystè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 élec-triques du moteur ...etc.).

Les différentes simulations fonctionnelles nous ont permis de vérifier lefonctionnement correct du systèmes et éliminer ainsi les erreurs de conception.Puis, grâce au prototypage d’une commande V/f, la validation de certainesfonctions a pu être assurée.

Afin de d’atteindre les objectifs fixés par la stratégie d’intégration (surfaceinférieure à 100.000 portes logiques, chemin critique inférieur à 500ns, préci-sion 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 êtreatteints et la commande intégrée sur une surface réduite.

Finalement, le prototypage de la MLI alimentée par un algorithme V/f apermis 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 com-mande une méthodologie et des outils lui permettant une aide à l’intégrationde la commande et dans un deuxième temps¸ appliquer la méthodologie ainsiobtenue à l’intégration d’une commande vectorielle de moteur asynchrone. Ils’agissait en effet de:

– prendre en compte les contraintes de la mise en oeuvre dès la phase deconception algorithmique.

– repousser les choix technologiques à un stade avancé de la conceptionafin de garder une relative indépendance technologique.

– d’écourter le cycle de conception grâce à une automatisation partielle destâ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 oeuvred’algorithmes de commande.

– Nous avons ensuite étudié l’état des techniques et outils employés enmicroélectronique pour la conception des systèmes complexes.

– A partir des résultats précédents, nous avons alors proposé une méthodespécifique à la mise en oeuvre des algorithmes de commande.

– Finalement¸ nous avons adapté le Grafcet aux contraintes de la concep-tion de systèmes intégrés.

Dans le premier chapitre, nous avons décrit la chaîne d’entraînement et les ca-ractéristiques physiques importantes pour le concepteur de l’intégration de lacommande. Nous avons notamment insisté sur les non-linéarités des disposi-tifs 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éci-sant le sens que nous donnons au concept de «commande» des machines AC.En particulier, nous avons extrait les différents blocs fonctionnels et nous avonsprécisé la tâche de chacun d’eux.

Dans le deuxième chapitre, nous avons analysé les méthodes actuelles pourl’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 denombreux travaux et qui visent à apporter des solutions aux insuffisances desapproches classiques.

Même si certains travaux portant sur l’intégration des algorithmes de com-mande des machines électriques ont présenti la nécessité d’aborder la concep-tion autrement, leur approche ne permet pas de résoudre les problèmes évo-qué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 del’application d’une méthodologie d’implantation. On gardera ainsi à l’espritl’importance du choix de la fréquence de calcul du système, le problème del’arithmétique binaire à employer et du séquencement des opérations vis à visde la précision binaire, et finalement, l’intérêt qu’il peut y avoir à modifier l’al-gorithme de départ pour tenir compte de la réalisation physique.

Le concept de conception mixte par contre, aborde l’intégration d’une fonc-tionnalité (protocoles, algorithmes, fonctions logiques, ...etc.) de façon systé-matique. L’utilisation de modèles fonctionnels associés aux algorithmes pourl’exploration des solutions de réalisation permet une conception plus flexible,moins liée aux spécifications technologiques et budgétaires, et donc une concep-tion plus réactive également. Les spécifications floues ne posent plus de pro-blème puisqu’il devient possible d’affiner ces spécifications en fonction desestimations sur les performances d’intégration. En ce qui concerne les outilssupportant la méthodologie de conception mixte, nous avons vu qu’un choiximportant s’offre au concepteur, lui permettant de réaliser une grande partiedes tâches automatiquement.

La méthodologie de conception mixte étant trop complexe à appliquer dansle cas général, nous avons donc proposé et étudié dans le troisième chapitreune 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 solu-tions théoriques pour les résoudre. Nous avons également défini des restric-tions au champ d’application de la méthode afin de limiter la complexité desproblèmes traités. Nous définissons en particulier l’architecture des systèmesde commande que nous utilisons.

La méthodologie étant définie¸ nous avons proposé et étudié dans le cin-quième chapitre une solution de mise en oeuvre de cette méthodologie en uti-lisant comme outil de modélisation le Grafcet.

En effet¸bien que le Grafcet présente des caractéristiques intéressantes i̧lreste 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 defonctionnement. Nous avons développé des règles et des techniques d’analysedu Grafcet permettant au concepteur de la commande de baser ses décisionssur des critères objectifs tels que les estimations de performances. L’analyse ar-chitecturale revêt une importance particulière dans la mesure où elle permetau concepteur d’étudier les implications physiques du modèle et donc de lemodifier 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 vecto-rielle de moteur asynchrone sous forme d’ASIC.

En suivant les étapes de la méthodologie, nous avons pu montrer l’effica-cité de celle-ci à résoudre des problèmes tels que la précision binaire ou lesspécifications floues. En utilisant des IP génériques paramétrisés, nous avonspu notamment accéder une certaine flexibilité dans la définition des constantescaracté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 certainesfonctions mathématiques, le CORDIC étant particulièrement intéressant parrapport aux contraintes de surface.

Finalement, nous montrons les résultats de quelques tests expérimentauxsur le prototype de la fonction de génération des impulsions MLI. Cette fonc-tion utilisant les mêmes ressources matérielles que l’ASIC de commande com-plet, le test du prototype permet de juger des prestations et du fonctionnementde l’architecture. Réalisé sur une carte spécifique, le prototype atteint les pres-tations 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 suffisam-ment exploitées lors de l’intégration de la commande vectorielle. En effet¸ lesalgorithmes de partitionnement¸ de validation fonctionnelle et d’estimation deperformances proposés ne permettent pas de traiter des fonctions complexes.Sur ces points¸ des développements algorithmiques sont prévisibles ultérieu-rement.

Par ailleurs¸ l’automatisation de la majeur partie des tâches est à envisagerafin de minimiser le risque d’erreur¸ augmenter la capacité de traitement dessystèmes complexes et diminuer les délais de développement.

141

142

Bibliographie

[1] A. Kalavade, E. A. Lee. A Hardware/Software Codesign Methodologyfor 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’in-tégration au sein de LCA. Thèse Doct. Ing. : Institut National Polytechniquede Toulouse, 1989. 187 p. 44

[3] G. Berry. Proof, Language and Interaction: Essays in Honour of Ro-bin Milner. [On-line]. Cambridge (USA) : MIT Press, 1998. TheFoundations 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 embed-ded 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 em-bedded systems. Englewood Cliffs (USA) : Prentice-Hall, 1994. 468 p. 46,51

[7] D. Gajski, F. Vahid, S. Narayan, J. Gong. Specification and design of embed-ded systems. Englewood Cliffs (USA) : Prentice-Hall, 1994. System parti-tioning, p. 187–201. 52

[8] D. Harel, A. Naamad. The STATEMATE semantics of State-charts. [On-line]. ACM trans. Soft. Eng. Method., Oct. 1996,vol 5, n�4 non paginé. [26/10/98] Available from internet:<URL: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, Nov1993, 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, vo-lume 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 lalangue française. Paris : Le Robert, 1984. 2171 p. 147

[14] F. Aubépart, C. Girerd, Y.A. Chapuis, P. Poure, F. Braun. ASIC implemen-tation of direct torque control for induction machine: functionnal valida-tion 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. Hardware-Software Co-Design of embedded systems. Boston : Kluwer Academic Pu-blishers, 1997. 289 p. 46, 51, 57

[16] F. Balarin, L. Lavagno, A. Sangiovanni-Vincentelli et al. Hardware-Software Co-Design of embedded systems. Boston : Kluwer Academic Pu-blishers, 1997. Models and representations, p. 37–134. 49

[17] F. Balarin, L. Lavagno, A. Sangiovanni-Vincentelli et al. Hardware-Software Co-Design of embedded systems. Boston : Kluwer Academic Pu-blishers, 1997. Interface synthesis and real-time operating system, p. 159–203. 52

[18] F. Balarin, L. Lavagno, A. Sangiovanni-Vincentelli et al. Hardware-Software Co-Design of embedded systems. Boston : Kluwer Academic Pu-blishers, 1997. Synthesis, p. 134–1597. 55

[19] G. De Micheli, A. Sangiovanni-Vincentelli, P. Antognetti. Design Systemfor VLSI circuits - Logic synthesis and silicon compilation. Boston : KluwerAcademic Publishers, 1987. 654 p. 40

[20] G.L. Haviland, A. Tuszynski. A CORDIC arithmetic processor chip. IEEETransactions On Computers, feb. 1980, vol C-29, n�2, p. 68–79. 183

[21] H. Kellermann, P. Hildinger, G. Brandenburg and J. Heinzl. Field orien-ted position control of a hybrid stepper motor. Sevilla (sp) : EPE confe-rence, 1995. vol 3, p. 3.908–3.913. 43

[22] D. Harel. Statecharts: a visual formalism for complex systems. Science ofcomputer programming, 1987, n�8, p. 231–274. 99

[23] J. Holtz. Pulsewidth modulation: a survey. Toledo (sp) : Power ElectronicsSpecialists 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 ofasynchronous controllers. IEICE trans. on Information and Systems, March1997, vol E80-D, n�3, p. 315–325. 92

[25] J. Hennessy, D. Patterson. Computer organization and design. The Hard-ware/software interface. San Francisco (USA) : Morgan Kaufmann Publi-shers, 1994. Chapter 4, p. 261–263. 58

144

[26] J.E. Fletcher, B.W. Williams, T.C. Green. DSP control of a synchronousreluctance 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 Hard-ware/Software Co-Design and Co-Verification. Boston : Kluwer AcademicPublishers, 1997. p. 59–87. 57

[28] J.M. Proth, X. Xiaolan. Les réseaux de Pétri pour la conception et la gestion dessystè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 techniquesfor power converters. Hawaii (USA) : IEEE IECON conference, 1993. vol2, p. 683–688. 44, 65, 72

[31] X. Jordà. Conception et réalisation d’une commande économique de couple d’unemachine asynchrone pour la traction électrique. Thèse Doct. Ing. : InstitutNational de Sciences Appliquées de Lyon, 1995. 221 p. 46, 65, 151

[32] K. Kota, J. R. Cavallaro. Numerical accuracy and harware tradeoffs forCORDIC arithmetic for special-purpose processors. IEEE Transaction onComputers, 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, Ber-keley, 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 lacommande: application à l’onduleur. Thèse Doct. Ing. : Institut National desSciences Appliquées de Lyon, 1998. 175 p. 30

[35] W. Leonhard. Control of electrical drives. 2nd edition. Berlin : SpringerVerlag, 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èseDoct. Ing. : Institut National Polytechnique de Toulouse, 1993. 174 p. 44,65, 72, 74

[38] E. Monmasson. Architecture de dispositifs de commande numérique. ThèseDoct. Ing. : Institut National Polytechnique de Toulouse, 1993. p. 147–151.Annexe A. 46

[39] N. Halbwachs, P. Caspi, D. Pilaud. The synchronous dataflow program-ming language Lustre. Another Look at Real Time Programming, Proceedingsof 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 systemperspective. 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 de-sign of an ASIC for AC drive control. Toledo (sp) : VHDL Users’s Forumin Europe, 1997. p. 51–60. 65

[44] P. Le Guernic, M. Le Borgne, T. Gauthier, C. Le Maire. Programming realtime 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 universi-taires Romanes, 1990. 553 p. 95

[47] R. Gupta, G. DeMicheli. Partitioning of functional models of synchro-nous 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) : INSAde Lyon, 1988. 142 p. Cours de Génie Electrique. 92

[49] J.M. Rétif. Systèmes asservis échantillonnés. Villeurbanne (fr) : Institut Na-tional de Sciences Appliquées, 1996. 142 p. Cours de Génie Electrique.195

[50] S.-F. Hsiao, J.-M. Delosme. Householder CORDIC algorithm. IEEE Tran-sactions On Computers, Aug. 1995, vol 44, n�8, p. 990–1000. 183

[51] S. Kleinfelft, M. Guiney, J.K. Miller, M. Barnes. Design methodologymanagement. 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 embeddedsystems, A unified Hardware/Software representation. Boston : Kluwer Aca-demic Publishers, 1996. 274 p. 46

[53] S. Kumar, J. Aylor, B.W. Johson, Wm.A. Wulf, R.D. Williams. A modelfor exploring hardware/software trade-offs and evaluating design alter-natives. In Hardware/Software Co-Design and Co-Verification. Boston : Klu-wer Academic Publishers, 1997. p. 1–21. 52, 107

[54] J.P. Uyemura. Circuit Design for CMOS VLSI. Boston : Kluwer AcademicPublishers, 1991. 480 p. 40

[55] J. E. Volder. The CORDIC trigonometric computing technique. IRE Tran-sactions 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 ICfor 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 secondecorrespond 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îne-ment 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 clas-sique, 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 doitréaliser un circuit pour obtenir le fonctionnement souhaité. Une fonctionnalitéest par exemple un circuit de reconnaissance de formes. Un tel circuit doit in-tégrer non seulement l’algorithme de traitement de l’image, mais aussi toutesles fonctions nécessaires à son intégration dans l’environnement envisagé (pro-tocoles de communication, fonctions analogiques ...etc.) et éventuellement desfonctions de surveillance et des machines d’état.

«implanter, intégrer»

1. Application Specific Integrated Circuit2. Field Programable Gate Array3. 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é au-tonome (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’in-formation (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 (processeurclassique, 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’effec-tuons 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éci-fique (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 tech-nologie (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égrationsur silicium (sous forme matériel/ASIC ou logiciel/processeur) et à la concep-tion de la carte comprenant l’ensemble des circuits analogiques et digitaux né-cessaires à la connection de celle-ci avec l’environnement dans lequel elle doitopé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 chosesabstraites)

«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 correc-tement.

149

150

Annexe B

Exemple de commandevectorielle

Dans cette annexe, nous présentons un exemple de commande vectorielled’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ésultatsexposé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’algorithmede 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 MLIvectorielle. Remarquons au passage que la stratégie MLI utilisée est complète-ment indépendante du contrôle. Nous aurions tout aussi bien pu utiliser uneMLI 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ôlerdirectement le flux et le couple à partir des courants d’alimentation commec’est le cas pour les moteurs DC à excitation séparée. En effet, en alimentantles bobinages du stator, les courants de ligne de la machine asynchrone créentun champ tournant qui induit des courants dans le rotor en court-circuit. Cescourants à leur tour créent un champ dans l’entrefer de la machine qui, ens’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èrentun modèle dynamique de la machine asynchrone, les électrotechniciens imagi-nèrent d’appliquer des transformations mathématiques aux courants de lignepour extraire des variables permettant de contrôler indépendamment le coupleet 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 sontbien connues.

La base du contrôle vectoriel est donc ce modèle dynamique de la machineasynchrone 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 ra-menée à une machine primitive caractérisée par des enroulements fictifs pseudo-stationnaires [4].

Les équations de tension des phases rotoriques et statoriques s’écriventpour 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 etd’une phase rotorique.

Quant aux flux magnétiques traversant chaque phase statorique et rotorique,ils sont décrits par:

�)������ � �*��� �������� � �+��� ����������)� ������ � �*��� ��������� � �+��� ��������

avec

�*��� �

�� ,� ,�� ,��

,�� ,� ,��,�� ,�� ,�

��

�*��� �

�� ,� ,�� ,��

,�� ,� ,��,�� ,�� ,�

��

�+��� � ,�

�� ���� ���� �

��� ���� �

���

���� ���� ���� ���� �

���

���� ���� ���� �

��� ����

��

�+��� � �+����

et

,� et ,� : respectivement les inductances propres d’une phase statorique etd’une phase rotorique.

,�� et ,�� : respectivement les inductances mutuelles entre deux phases sta-toriques et entre deux phases rotoriques.

,� : valeur maximale de l’inductance mutuelle entre phases rotoriqueset statoriques.

�� : angle de rotation du moteur mesuré entre l’axe magnétique de laphase statorique a et de la phase rotorique A.

En raisonnant sur ces équations de tension des phases rotoriques et statoriquesainsi que sur l’expression des flux magnétiques qui traversent ces phases, onobtient 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éca-nique ��

Pour palier à ce problème, on recherche des transformations linéaires des va-riables triphasées de la machine permettant de passer du repère triphasé de lamachine 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 desaxes espacés de ��

� à un repère orthogonal ��� fixe par rapport au stator. Latransformation repose sur l’équivalence magnétique du système dans les deuxrepères. En posant que l’axe a coïncide avec l’axe �, on détermine la transfor-mation 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 quela 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. Latransformation de Concordia appliquée aux variables rotoriques permet depasser du repère abc à un repère xyo, solidaire avec le rotor (c’est à dire un re-père tournant à la vitesse de rotation du moteur). Si on désire exprimer ces va-riables rotoriques triphasées dans le repère ���, il faut leur appliquer la trans-formation de Concordia puis une rotation d’angle ���. On remarquera que lescoordonnées selon l’axe o restent inchangées durant la rotation car cet axe (dithomopolaire) est commun aux repères ��� et xyo. L’expression de la rotationpour 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), onobtient 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 po-sition relative �� entre stator et rotor.

155

– la dynamique selon l’axe homopolaire est découplée de celle des autresaxes. 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 rai-son qu’on appelle souvent la transformation de Concordia, transformation3/2 puisqu’elle permet le passage d’un système triphasé vers un systèmebiphasé équivalent (les composantes homopolaires étant négligées).

L’expression du couple électromagnétique est quant à elle extraite d’une étudesur la puissance électrique totale instantanée dans la machine. En admettantque les variables homopolaires sont nulles (la machine est dite équilibrée), onobtient 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èledu 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’exprimerce modèle dans un repère tournant à la vitesse de synchronisme .�, appelé re-père ��. Nous avons déjà indiqué succinctement en 1.2.1.2 que cette vitesse étaitdé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 raisondu couple résistant qui s’exerce sur l’axe du rotor (au minimum, la résistancedue aux frottements si le moteur tourne à vide).

Pour calculer le modèle du moteur dans le repère ��, il faut appliquer latransformation de Concordia aux variables statoriques et rotoriques, puis leurappliquer 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 rota-tion constitue la transformation de Park:

�� '�

''�

�� � -

�� � ��� �

��� � ��

�

����� � ��

�

�� ��� ��� � ���

��� � ��

�

� � ������ � ��

�

����

���

���

���� '�

'�'

��

�'����� � � �'�����

B.1.1.4 Le modèle de Park

En appliquant la transformation de Park aux équations électriques du mo-teur 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 transformationvaut ��� � �� pour les variables rotoriques:

&�� � (���� � *�������

� *�������

� *�.��� � *�.���

&� � (��� � *������

� *������

� *�.���� � *�.����

&�� � � � (���� � *�������

� *�������

� *�.���� � *�.����

&� � � � (��� � *������

� *������

� *�.����� � *�.�����

)�� � *���� � *����

)� � *��� � *���

)�� � *���� � *����

)� � *��� � *���

�� ��

�-�/*� ������ � �����

L’ensemble de ces équations constituent ce qu’on appelle aussi le modèle dePark du moteur à induction.

B.1.1.5 Équations mécaniques

Un dernier point indispensable de la modélisation du moteur asynchroneest 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, frot-

tement 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 moteurasynchrone. Mais, ces équations ne sont d’aucune utilité si nous ne sommespas 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 identificationde paramètres est complexe, mais en plus, ces paramètres varient lors du fonc-tionnement de la machine si bien qu’il sera nécessaire d’introduire une pro-cédure d’identification en ligne dans l’algorithme de commande. Pour facili-ter la tâche d’identification, on effectue des hypothèses simplificatrices sur lesfuites magnétiques au niveau des circuits rotoriques et statoriques. En fait, onva ramener l’ensemble des fuites du côté du stator ce qui permet de réduire lenombre de paramètres indépendants (du modèle) à quatre.

Ainsi, si on associe respectivement les inductances *�� et *�� aux flux defuite du stator et du rotor, on considère que *�� � � si bien que l’inductance defuite 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 sim-plement:

�

��

����

�����)��)�

���� �

�����������

��.�

�����

���

�.� ������

��� ���

�����

(� � � ���

.��� (� �.�� � �

��

���������

�����)��)�

�����

����

���

�

� ���

� �� �

�����&��&�

�(B.3)

�� ��

�/ ���)�� � ���)� (B.4)

avec

�� �*�(�

(B.5)

158

- ��

�

B.1.2 La commande par flux rotorique orienté

Historiquement, l’algorithme étudié par Jordà et que nous présentons icidevait servir à la commande d’un moteur électrique pour la traction d’un petitvéhicule urbain. Pour cette raison, la stratégie de contrôle adoptée comporteuniquement un contrôle du couple de la machine. On suppose que le contrôlede 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ésen-tée dans la section précédente, est de permettre un découplage de la commandedu 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 commandevectorielle 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 rotationmécanique). En calant l’axe d sur le vecteur de flux, on contrôlera directementle flux par la composante d du courant statorique et le couple par la composanteq. La composante d jouera donc le rôle de courant d’excitation et la composanteq celui de courant d’induit.

Les équations qui lient le flux, le couple et le courant statorique découlentdu modèle de Park à quatre paramètres présenté en B.1.1.6. En effet, choisir unrepè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 courantmagnétisant, proportionnel au flux rotorique )� .

159

En analysant les équations précédentes, on peut observer les points sui-vants:

– Les équations B.8 et B.9 définissent une relation permettant de contrôlerle flux par la composante ��� du courant statorique.

– A flux constant, le couple dépend uniquement des variations de �� (équa-tion 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 deflux et de couple. On peut donc maintenant appliquer les techniques classiquesde 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 sui-vantes, 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 quileur est associée et d’un terme de couplage entre les axes d et q. On estimetoutefois 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 machineasynchrone qui néglige le retard d’application de la commande (une périoded’échantillonnage) et les retards introduits par l’onduleur (de l’ordre de la mi-croseconde). On suppose également que l’orientation de l’axe d en fonction duflux )� 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

FIG. 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’ordrezéro d’une boucle de régulation d’un processus du premier ordre continu degain K et de constante de temps 2 . Dans le tableau B.1, nous résumons lesvaleurs de ces constantes pour les trois boucles de régulation de la commande.

FIG. 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’ordrezéro sont liés à K, 2 et �� � (où �� � est la période d’échantillonnage) par lesexpressions suivantes:

� � -

��� ���

���� �

2

��

3 � ���

���� �

2

�

La fonction de transfert du processus régulé est du deuxième ordre. Le cal-cul du gain G et du zéro L est effectué tel que la réponse dynamique ait unepulsation propre . et un amortissement 4 donné. L’expression des pôles enboucle 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 derégulation de courant

1 � ��� ���� �.4 ��� �.

��� 4�

6 � ��� ���� �.4 ���

�� �.

��� 4�

Avec cette expression des pôles, on identifie les coefficients G et L:

7 �3 � �� �1

�

* �3 � �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 leflux 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, etdonc 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 enoeuvre. C’est la raison pour laquelle elle a été choisie dans cette commande.

Pratiquement, on calcule la vitesse de glissement à imposer à la machine enfonction des consignes ��� et ����:

.��� ��

��

�������

162

A partir de .��� et de la mesure de la vitesse mécanique, on calcule la pulsa-tion statorique et donc aussi l’angle ��:

.�� � .��� � .�

����� �

� �

.����8 �8

Remarquons que le calcul de .��� dépend directement de la constante detemps rotorique ��. C’est le principal inconvénient de cette méthode car unevariation de cette constante entraîne un désalignement du repère dq et donc unrecouplage entre le contrôle du flux et du couple, ce qui entraîne une erreurstationnaire et des oscillations transitoires. Il est donc indispensable d’effec-tuer une estimation en ligne de ��, ce qui augmente la charge calculatoire del’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 puissanceréactive afin d’examiner si la constante rotorique est identique dans les deuxcas. 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 decourant et tension, puis à partir des grandeurs de référence. L’écart entre lesdeux 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 et3 �� 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 entreles deux calculs de la puissance réactive devient nul. Pour estimer la valeurréelle de ��, il faut donc effectuer les deux calculs de puissance réactive, cal-culer l’écart, intégrer cet écart et ajouter le résultat à la valeur nominale de laconstante de temps rotorique � ��. Le schéma fig. B.3 reproduit cette stratégied’estimation de la constante de temps rotorique.

163

FIG. 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 instantsde commutation des interrupteurs de l’onduleur qui alimente le moteur. Leprincipe de la MLI vectorielle consiste à reconstruire le vecteur de tension sta-torique ��&� à partir de huit vecteurs de tension correspondant aux huit étatspossibles de l’onduleur. Dans le paragraphe suivant, nous allons décrire l’algo-rithme employé pour calculer les instants de commutation et définir les gran-deurs 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 unonduleur sans temps mort, retard de commutation ni distortion de la tensionde sortie. Pour un tel onduleur, il n’existe que huit configurations possiblesselon l’état de ses interrupteurs, ce qui correspond à huit combinaisons de ten-sion entre ligne soit, dans le repère ��, huit vecteurs de tension statorique ap-plicables au moteur. Le tableau B.2 résume ces combinaisons de tension. Onremarquera au passage que &�� et &�� sont les deux composantes de��&� dans leplan complexe ��:

��&� � &�� � 5&��

Sur la figure B.5, nous avons représenté les huit vecteurs de tension stato-rique dans le plan ��. On remarquera que deux des huit vecteurs (& et &�) sontnuls. Quant aux six autres, ils définissent six secteurs angulaires de �

� !��. Si onrepère ces secteurs par un indice entier �, on peut exprimer les vecteurs par lesrelations suivantes:

164

��

��

�

& ��

& ��

& ��

& ��

& ��

�� &

nom

OO

O0

00

00

0�� &

OO

F0

������

�����

0

�����

��

����

��

��!�� �

�� &

OF

O

������

�����

0

������

���

��

����

��

��!�� �

�� & �

OF

F

������

0

�����

������

����

��

����

��

��!�� �

�� & �

FO

O

�����

0

������

�����

���

��

����

��

��!� �

�� & �

FO

F

�����

������

0

�����

����

��

����

��

��!����

�� & �

FF

O0

�����

������

0

�����

��

����

��

��!� �

�� & �

FF

F0

00

00

0

�� & �

TAB. B.2 – combinaisons de vecteurs de tension d’un onduleur trois bras idéal, moteurbranché en triangle (F: fermé, O: ouvert)

165

FIG. B.4 – Onduleur idéal a trois bras

��&� �������� ��� 5

�� 9

�� 9

�

�(B.15)

���&��� �������� ��� 5

�� 9

��9

�

�(B.16)

��& ���� (B.17)

��&� ���� (B.18)

Ces huit vecteurs de tension que nous avons définis correspondent à la ten-sion statorique qu’on pourrait mesurer si les interrupteurs de l’onduleur res-taient dans un état correspondant à un vecteur donné. Mais le but de la mé-thode est d’obtenir une tension statorique quelconque. Pour cela, nous allonsappliquer sur une période de commutation un vecteur��&� pendant un temps ��puis un vecteur ���&��� pendant un temps ����. De cette manière, en moyenne, onpeut obtenir n’importe quelle tension statorique désirée. Figure B.6 montre leprincipe 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 commuta-tion:

2� ���

� ��(B.19)

Si la somme des durées d’application des vecteurs ��&� et���&��� est inférieure à� �� (������� � � ��), alors on complète la séquence par les vecteurs nuls. Levecteur reconstitué ��&� est donc une combinaison linéaire de vecteurs de base:

166

FIG. B.5 – Vecteurs de tension statorique dans le plan ��

FIG. 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

�

&��� � �������

(B.21)

���� ����� �

9

�

&��� � ���

��� �

9

�

&��� � �������

(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).

FIG. 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 instantsde commutation des interrupteurs, le problème étant qu’il est possible de dé-terminer plusieurs séquences de commutations qui correspondent aux tempscalculés. Pour un même fondamental de sortie, chaque séquence produit desharmoniques et des pertes en commutation différentes.

Dans notre exemple, nous utilisons une MLI continue avec des impulsionscentrées au milieu de la période de commutation. Ce type de modulation limitele contenu harmonique des tensions générées.

La méthode pour déterminer les instants de commutation consiste à dis-tribuer le temps d’application du vecteur nul de façon identique entre ��& et��&� . On applique donc successivement ��& , puis des vecteurs non nuls, puis ��&� ,puis des vecteurs non nuls, puis ��& . Les vecteurs non nuls sont deux vecteurssuccessifs ��&� et ���&��� dont la durée d’application est répartie symétriquementautour 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 nedoit pas commuter plus de deux fois durant la période de commutation pourminimiser les pertes de l’onduleur. La figure B.8 représente ces séquences enfonction du secteur angulaire où se trouve le vecteur de référence. A partir decette figure, il est facile de calculer les instants de commutation.

Exemple: prenons � � �. Avec �, temps d’application du vecteurnul, �"#�, instant de fermeture de l’interrupteur 8 et ��$�, instantd’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

FIG. 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 re-pré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 detension de référence au delà des limites de la MLI, l’algorithme doit pouvoir ledétecter et limiter cette consigne. Une méthode simple pour cela est de vérifierla 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 duvecteur 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 accu-

170

mulateurs) ce qui peut provoquer la limitation de la consigne de tension dela MLI. Cette limitation, assimilable à un phénomène de saturation, peut êtreproblématique pour les régulateurs PI de l’algorithme de contrôle. Pour assu-rer un fonctionnement correct, il faut ajouter aux régulateurs un système anti-saturation. 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 limi-tation définit comme suit (on utilise ici le cas de ��, il en est de même pour ���avec &��):

Si la MLI ne limite pas, le module de ��&� reste inchangé: &����� � &

�

�

Si la MLI limite, le module de ��&� est diminué: &����� � ��

�����&�

� �1

1 reste inchangé pour assurer le découplage des fonctions de transfert.

FIG. 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, surun 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’estimationde l’angle ��. En effet, cet angle est utilisé pour une rotation à l’entrée de l’al-gorithme de contrôle (transformation de Park), mais aussi à l’entrée de la MLIpour calculer la tension statorique de référence &� dans le repère ��. Entre cesdeux rotations, un certain temps de calcul s’est écoulé pendant lequel le mo-teur a continué à tourner. L’angle �� ne reste donc pas inchangé au niveau dumoteur. 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 fonc-tionnent à une fréquence d’échantillonnage beaucoup plus basse que le restede 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 paslimité à un moteur donné. Néanmoins, pour l’intégration de la commande, ilva falloir en tenir compte afin d’étudier les phénomènes liés à l’arithmétiquebinaire (précision limité, dépassement de capacité ...etc.). Dans notre cas, nousutilisons un moteur de 4 KW dont les paramètres identifiés sont donnés enannexe C. Avec ces paramètres, nous voyons que la constant de temps desfonctions 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èmesnumériques dus au sur-échantillonnage, on fixe deux constantes de temps. Unepremiè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

FIG. B.10 – Schéma bloc de l’algorithme de commande173

174

Annexe C

Paramètres du moteur 4 kW

paramètre valeur3� (kW) 4,4��� (V) 70 ()��� (A) 52�;� 0.79��� (Hz) 50

��� (t/min) 1425/ 2

(� (�) 0.211*� (H) 0.00099*� (H) 0.0147(� (�) 0.099< 0.177

)� (Wb) 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éeCORDIC 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 quela tangente inverse. L’idée développée par cette technique est d’effectuer cesopérations de façon itérative, c’est à dire de calculer par exemple la rotationpar micro-rotations successives, en utilisant des fonctions logiques simples telsque des additionneurs, des décaleurs, des registres et une ROM pour stockerles 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 vec-teur et un angle de rotation, l’algorithme calcule les coordonnées du vec-teur pivoté. Ce mode est défini par �� � �����> .

2. Le mode vectorisation: étant donné les coordonnées d’un vecteur, l’algo-rithme calcule la norme de ce vecteur et son angle par rapport à l’axe desabscisses. Ce mode est défini par �� � �����? .

Il prouve également que si

�'� �����

��������� � �#���### (D.1)

1. COrdinate Rotation DIgital Computer

177

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 � ! � := � ! ��� :

�

avec ! �

�8� � =�

: � �������

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’in-fluence de l’arithmétique binaire sur l’algorithme.

178

D.2 Le CORDIC binaire

Dans la suite de cette annexe, nous utiliserons le formalisme ���� pourdécrire le format binaire employé, avec �� le nombre de bits de la partie entièreet �� la longueur totale du mot binaire.

Ainsi que nous l’avons déjà dit, l’algorithme atteint une précision théoriquedéfinie par:

�8� � ! ��: � � � � !���

avec � le nombre total d’itérations. Cette erreur est appelée erreur d’approxi-mation et est due au nombre d’itération fini.

Supposons maintenant un vecteur &� �8��=� codé sur �� bits. La micro-rotationqui calcule le vecteur &��� �8����=��� à l’itération � est déterminée par la valeurde ���&�. 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 derotation avec une précision supérieure à �� � �� � �� n’a pas de sens. Commeles 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 tronca-ture des résultats, erreur produite par la longueur finie des mots binaires. Cetteerreur peut excéder l’erreur d’approximation lors du calcul répété des opéra-tions d’addition et de soustraction sur des mots binaire de longueur finie. Dansce 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 cal-cule l’algorithme CORDIC en mode rotation sur bus de données interne delongueur �� avec

�� � �� �� � � �

alors l’erreur de troncature reste inférieure à l’erreur d’approximation et onpeut 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 notrecas, vaut �� .

Donc, si on reprend tous les éléments avec un format binaire de ���� parexemple, il faudrait calculer théoriquement 5 itérations CORDIC. Mais pouratteindre une précision de �� , il faut en fait calculer sur un bus interne de 19bits:

�� � �� � � � �� �� � � � ���� � �

179

---

Pro

gra

mm

ed

ec

alc

ul d

efo

nc

tions

co

mp

lexe

sp

arl 'a

lgo

rithm

eC

ORD

IC--

----

----

----

----

L es

ca

lculs

sefo

ntsu

rd

es

no

mb

res

bin

aire

s--

----

----

----

-

Cho

isir

les

fonc

tions

àc

alc

ule

r(c

ec

ho

ixd

éfin

i le

mo

de

de

fonc

tionne

me

ntd

el'a

lgo

rithm

e)

sinus/

co

sinus

=>

ind

ique

r1

X*Z

=>

ind

ique

r2

rac

ine

ca

rrée

/arc

tan

=>

ind

ique

r3

Y/X

=>

ind

ique

r4

rép

onse

pa

rd

éfa

ut:

4

rép

onse

:1

Vale

urs

pa

rd

éfa

utd

es

co

nst

ante

sd

ec

alc

ul:

no

mb

red

eb

itd

eZ

:1

6no

mb

red

eb

itd

eX

Y:1

6no

mb

res

de

bits

allo

ué

sà

lap

artie

entiè

red

eZ

:1

1no

mb

res

de

bits

allo

ué

sà

lap

artie

entiè

red

eX

Y:1

1

vale

urs

du

no

mb

red

eb

itsd

eX

Ye

td

eZ

pa

rd

éfa

ut?

(y,n

)ré

po

nse

pa

rd

éfa

ut:

y

rép

onse

:

Vale

urs

pa

rd

éfa

utd

es

larg

eurs

de

che

min

de

do

nné

es:

no

mb

red

eb

itd

eZ

:1

9no

mb

red

eb

itd

eX

Y:1

9

vale

urs

du

no

mb

red

eb

itsd

uc

he

min

de

do

nné

es

de

XY

etd

eZ

pa

rd

éfa

ut?

(y,n

)ré

po

nse

pa

rd

éfa

ut:

y

rép

onse

:

vale

urs

pa

rd

éfa

utd

eX

0,Y0

etZ0

:X

0=

1Y0

=0

Z0=

0

vale

urs

de

X,Y

etZ

pa

rd

éfa

ut?

(y,n

)ré

po

nse

pa

rd

éfa

ut:

y

rép

onse

:n

Do

nne

rd

es

vale

urs

de

X0

etY0

co

da

ble

ssu

rle

no

mb

red

eb

itsin

diq

ué

(no

tta

mm

entla

pa

rtie

entiè

re).

Vale

urd

eX

0:

1

Vale

urd

eY0

:0

Do

nne

rune

vale

urd

ez0

co

mp

rise

entre

-2p

i et2

pi.

Vale

urd

eZ0

:2

*pi/3

Pre

miè

rero

tatio

nd

ePi

/2e

ffe

ctu

ée

----

-va

leurs

initi

ale

sd

eZ0

,X

0e

tY0

ain

siq

ue

X,Y

etZ

rée

ls--

---

00

00

00

00

01

00

00

11

00

00

00

00

00

00

01

00

00

00

00

00

00

00

00

00

00

00

00

00

01

.00

00

00

.00

00

02

.09

37

5

----

-Ev

olu

tion

de

Zi,X

i etYi

bin

aire

sa

insi

que

X,Y

etZ

rée

ls--

---

---

Poid

sfo

rts

etb

itd

esi

gne

àg

auc

he

---

it|Z

bin

aire

Xb

ina

ireY

bin

aire

XY

Z

-10

00

00

00

00

00

10

00

01

10

00

00

00

00

00

00

00

00

00

00

00

00

00

00

01

00

00

00

00

0.0

00

00

1.0

00

00

0.5

23

44

p0

11

11

11

11

11

11

01

11

10

11

11

11

11

11

11

00

00

00

00

00

00

00

00

00

10

00

00

00

0-1

.00

00

01

.00

00

0-0

.26

17

21

00

00

00

00

00

00

01

10

01

11

11

11

11

11

11

10

00

00

00

00

00

00

00

00

11

00

00

00

0-0

.50

00

01

.50

00

00

.19

92

21

00

00

00

00

00

00

01

10

01

11

11

11

11

11

11

11

00

00

00

00

00

00

00

00

01

10

00

00

0-0

.25

00

00

.75

00

00

.19

92

2*

21

11

11

11

11

11

11

11

01

01

11

11

11

11

11

11

00

10

00

00

00

00

00

00

00

10

11

00

00

-0.4

37

50

0.6

87

50

-0.0

42

97

21

11

11

11

11

11

11

11

01

01

11

11

11

11

11

10

11

10

10

00

00

00

00

00

00

11

01

11

00

-0.5

46

88

0.8

59

38

-0.0

42

97

*3

00

00

00

00

00

00

00

10

10

01

11

11

11

11

11

10

00

11

11

00

00

00

00

00

01

11

01

11

0-0

.44

14

10

.92

96

90

.07

81

24

00

00

00

00

00

00

00

00

10

11

11

11

11

11

11

10

00

00

01

00

00

00

00

00

01

11

00

11

0-0

.49

60

90

.89

84

40

.01

95

35

11

11

11

11

11

11

11

11

11

01

11

11

11

11

11

01

11

10

10

00

00

00

00

00

01

11

00

01

0-0

.52

34

40

.88

28

1-0

.00

78

15

11

11

11

11

11

11

11

11

11

01

11

11

11

11

11

01

11

11

11

00

00

00

00

00

01

10

11

01

1-0

.50

39

10

.85

54

7-0

.00

78

1*

60

00

00

00

00

00

00

00

00

01

11

11

11

11

11

11

00

00

01

00

00

00

00

00

00

11

01

11

10

-0.4

92

19

0.8

67

19

0.0

03

91

70

00

00

00

00

00

00

00

00

00

11

11

11

11

11

11

00

00

00

10

00

00

00

00

00

11

01

11

01

-0.4

96

09

0.8

63

28

0.0

00

00

*:

résu

ltats

de

sité

ratio

ns

de

no

rma

lisa

tion

p:

op

éra

tion

de

pré

-ro

tatio

n

FIG. D.1 – Résultats partiels d’une rotation CORDIC simulée sur MATLAB

180

Il faut donc calculer � � �� � � itérations.Figure D.1, p. 180, donne les résultats intermédiaires d’une simulation COR-

DIC 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é quipermet de calculer toutes les fonctions mathématiques classiques [56].

Même si cet algorithme n’est pas le moyen le plus rapide de calculer cer-taines des fonctions calculables, il est très intéressant de pouvoir calculer toutesces 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 fonc-

tions. Aux fonctions circulaires ( � �), définies déjà avec l’algorithme clas-sique, on ajoute maintenant les fonctions linéaires ( � �) et les fonctions hy-perboliques ( � ��). Le calcul de ces deux nouvelles classes de fonctions estpossible 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 fonction-nement de l’algorithme CORDIC. Remarquons que certaines itérations doiventêtre répétées pour � �� afin d’assurer la convergence de l’algorithme.

Mode Itérations calculées Base discrèteCirculaire � � < �� � � �%��� � �����

�����

Linéaire � � < �� � � �%��� � ���

Hyperbolique � �� < �� � ������������###����������###

�%��� � ����!����

�TAB. D.1 – Valeurs de < �� et de �%��� pour chaque mode

Pour l’algorithme CORDIC classique, Volder avait prouvé que si >, l’angleinitial, est décomposé en micro-angles tel que

181

CORDICX

Y

Z

CORDICX

Y

Z

CORDICX

Y

Z

CORDICX

Y

Z

CORDICX

Y

Z

CORDICX

Y

Z

Hyperbolic

m=-1

Linear

m=0

Circular

m=1

K[Xcos(Z)-Ysin(z)]

K[Ycos(Z)+Xsin(Z)]

0

K (X +Y )

0

Z-Arctan(y/X)

X

Y+XZ

0

X

0

Z+Y/X

K’[Xcosh(Z)-Ysinh(Z)]

K’[Ycosh(Z)+Xsinh(Z)]

0

0

Z-argth(Y/X)

Rotation mode Vectoring modedn=-sign(Y )dn=sign(Z )

k k

22 2

2 2K’ (X -Y )

FIG. D.2 – Fonctions calculées par l’algorithme CORDIC généralisé

182

> �

����

��

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 dedéduire les conditions de convergence du CORDIC. On résume ces conditionsdans le tableau D.2, p. 183, pour les modes qui nous intéressent.

rotation vectorisationCirculaire ' ���#��� # # # ��#��� # # #�

Linéaire ' ������=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éterest un problème complexe que Hsiao et Delosme proposent de résoudre parun algorithme de recuit simulé [50].

Le calcul de fonctions complexes à partir des fonctions calculées par l’algo-rithme 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’effec-tuer de deux manières:

1. soit par la multiplication par �&

2. soit en utilisant une méthode de multiplication itérative présentée parHaviland et Tunzynsky dans [20]. Cette solution consiste à décomposerla constante �

&sous forme de produit de facteurs tels que la multiplica-

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 denormalisation 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 dansle format binaire choisi.

Remarquons au passage que cette méthode de multiplication itérative a un in-térêt non négligeable pour l’intégration des algorithmes de commande. En ef-fet, ces algorithmes comportent de nombreuses multiplications par des constantes.Ces multiplications posent souvent problème lors de l’intégration en virgulefixe car les constantes en questions sont trop petites pour être codées dans leformat binaire choisi. Il en résultent de nombreuses opérations de décalagepour changer de format de données.

Or la multiplication itérative par le biais de la factorisation des constantespermet 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éedans ce format, la multiplication ��8 serait nulle avec un multiplieur normal.Mais, si 8 � ��� � �, cette multiplication devrait valoir �� 8 � �����, résultatqui 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 binairesignée vaut �8���� � �� et la précision de codage maximale est de �� . Lafactorisation de � sera donc choisie de telle manière que l’erreur sur la multi-plication soit au maximum égale à �� ce qui se traduit par:

������� � ��� �� � �8���� � ��

Cette condition est remplie avec

��� � � ����� � ���

� �� � ��

� ��� ���

�La multiplication itérative de 8 � � par ��� � donnera alors ��� � � 8 �

������ en quatre itérations.

184

D.5 Extension des limites de convergence

L’analyse des algorithme de contrôle montre que les domaines de conver-gence de l’algorithme CORDIC sont insuffisants pour les variables impliquées:

– L’opération de rotation est utilisée dans le calcul de la transformationde Park où la rotation du vecteur de tension s’effectue avec l’angle derotation du flux moteur. Cet angle varie bien entendu de ��9 à �9, soitbien plus que prévu par l’algorithme CORDIC.

– Les opération linéaires (multiplication et division) s’opèrent sur des va-riables dont la valeur maximale correspond à la valeur maximale de co-dage binaire.

Une solution serait d’utiliser l’arithmétique virgule flottante, mais comme lesopérandes restent codés en arithmétique virgule fixe, il faudrait envisager desopérations de conversion. Par ailleurs, le coût d’une implantation virgule flot-tante du CORDIC nous a parut excessif.

Nous avons donc modifié légèrement l’algorithme pour étendre les limitesde 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 uneprérotation de �

� ce qui étend les limites de convergence à:

��#�� # # #� 9

�� �#�� # # #�

9

�

�� ��� ��� � ���

L’extension à ���9� �9� est effectué ensuite en calculant l’angle '� ��9� 9�équivalent à l’angle de rotation ' si celui-ci vérifie la condition:

' ���9� � 9� � �9� �9�

Si on résume tout cela, on obtient les condition suivantes pour l’extensiondes limites de convergence:

Si �'� " 9 et ' � �, alors

'� � �9 � 9

�� ' � ' �

�9

�

Si �'� " 9 et ' " �, alors

'� � ��9 �9

�� ' � ' � �9

�

185

Ces opérations sont très faciles à réaliser, soit avec le matériel déjà existant (oncalcule la valeur absolue de ' en scrutant son MSB 2 et en calculant éventuel-lement �'� � �� '), 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 normede ce vecteur est limitée par une valeur maximale !���. Dans le cas d’une rota-tion vraie¸!��� serait égale à la valeur maximale codable dans le format binaireenvisagé¸ 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.3et D.4, p. 187, montrent la précision atteinte pour des mots au format binaire���� avec un bus interne de � bits.

−1 −0.5 0 0.5 1−1

−0.8

−0.6

−0.4

−0.2

0

0.2

0.4

0.6

0.8

1

FIG. D.3 – Simulation du CORDIC (trait plein) en mode rotation par rapport à unerotation 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 beau-coup plus complexe.

Une solution simple à première vue serait d’étendre la base discrète �� à#������ ����

$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 deconvergence augmenterait jusqu’à

%��������� �

�, valeur maximale codable dansle format ����.

2. Most Significant Bit

186

0 1 2 3 4 5 6 7−0.04

−0.03

−0.02

−0.01

0

0.01

0.02

0.03

0.04

FIG. 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éborde-

ment 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 estlimité à �� � � 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êmetechnique que pour le mode circulaire, c’est à dire de normaliser les variablesd’entrée.

L’idée de cette normalisation est de transformer le format binaire des va-riables 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 transformationdépend de la valeur des variables. En fait, on réalise une sorte de transfor-mation des variables de l’arithmétique virgule fixe vers l’arithmétique virguleflottante.

Voyons maintenant le détail des opérations à réaliser pour chaque fonc-tions.

187

D.5.2.1 Cas de la division

On commence ici par tester le signe de 8 (en scrutant son MSB). Si 8 estné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 deconvergence de l’algorithme CORDIC normal. On calcule donc directement lesité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 lagauche. 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 �� dudé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 coor-donnée = vaut maintenant:

&=� � =�

��� � �8�����

�� � ��� � ���

avec ��� le nombre total d’itérations de décalage sur = et ��� le nombretotal 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:

%��� ���

�� � � �����

'����������� � ��������%��� ���

��

� '����������� � ����������=8

(D.3)

188

4. En décalant le résultat des itérations CORDIC de ��� � �� � � bits (équa-tion D.3) et après troncature des bits additionnels du chemin interne, soitune troncature des ��� � �� bits de poids faible, on obtient le rapport �

�sur la coordonnée ':

'����������� ���

Remarque: la valeur �� est nécessairement inférieure à �� � � car une valeursupé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 lavariable ':

1. Test si ' � 8. Si c’est le cas, on permute 8 et ' pour des raisons deprécision de calcul (justification en D.5.3).

2. Test si �'� � �. Si c’est le cas, on calcule directement les itérations COR-DIC.

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:

%��� ���

�� � '����������

� =������ � 8'����������

5. En décalant =������ de � ��� � �� � � bits, et après troncature des ré-sultats, on obtient:

=������ � 8'

Remarque: La valeur de �� est toujours inférieure à �� � � car dans la cascontraire, cela signifierait que ' � � et dans ce cas, on calcule directe-ment 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. Ilnous faut donc étudier maintenant la précision atteinte par le CORDIC étendupour 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!!' �%�

�� �����!! � ��� ce qui permet de

définir une précision théorique du résultat:

���� � ' �%�

�� ����� � ���

' � ��� � %��� ���

�� � ' � ���

8 �' � ��� � =��� � 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 testde la multiplication).

190

Cependant, ce calcul ne tient pas compte des points suivant, sources d’er-reur:

1. Le changement de format initial et la correction du résultat final: en rai-son 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 paspris l’erreur de troncature introduite par la longueur finie des mots bi-naires. Cette erreur est de l’ordre de Æ�������� avec Æ � ��� � �� � �� � � et peut dans certains cas excéder 8���. En effet, avec le calcul du COR-DIC non étendu, nous n’effectuons pas de décalage final. Cette erreurreste alors inférieure à ���� . Par contre, le décalage final multiplie cetteerreur et la rend très supérieure à 8�������������.

3. l’erreur de quantification (introduite par le codage binaire de grandeursréelles): elle reste toujours inférieure à ���� et est inévitable. Pour élimi-ner cette erreur de nos simulations et mettre en évidence l’influence desautres facteurs d’imprécision, nous avons comparé des simulations COR-DIC avec la même opération effectuée sur des nombres réels obtenus parconversion des entrées binaires du CORDIC.

L’erreur globale étant très difficile à quantifier, il est toutefois facile de montrerque lorsque 8 est très supérieur à l’erreur de troncature, l’erreur maximalecommise sur le calcul d’une multiplication par l’algorithme CORDIC étenduest 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éepar 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 claire-ment que pour de faibles valeur de 8, l’erreur de troncature devient prépon-dérante.

191

−30−20

−100

1020

30

−40

−20

0

20

400

0.5

1

1.5

2

2.5

3

3.5

FIG. 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 lamultiplication, 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 correc-tion finale et l’erreur de troncature. Le décalage final étant toujours vers ladroite, la précision finale est donnée par:

����������� � ��� � ����

Figure D.6 représente une simulation de la division CORDIC étendu. Avecles figures D.7 et D.8 nous avons voulu mettre en évidence l’influence de l’er-reur de quantification.

192

00.2

0.40.6

0.81

0

2

4

6

8

100

20

40

60

80

100

120

FIG. D.6 – Simulation de la division avec le CORDIC étendu

00.2

0.40.6

0.81

0

2

4

6

8

10−8

−6

−4

−2

0

2

FIG. D.7 – Erreur sur la division incluant l’erreur de quantification

00.2

0.40.6

0.81

0

2

4

6

8

10−0.01

0

0.01

0.02

0.03

0.04

FIG. 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 simula-tion sous Ptolemy. Le système modélisé et simulé est la commande échantillon-né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éeait 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 don-née par:

��' ���'

��' �

������'��

�� ������'��

Ce processus a une constante de temps �' � �� �, ce qui correspond à unepulsation propre de .' � ����� !��. En choisissant pour le processus asserviune 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 fi-gures E.2 à E.4 représentent les schémas blocs construits dans l’environnementgraphique de Ptolemy. La courbe figure E.6 donne la réponse temporelle dusystème pour un échelon unité perturbé. La perturbation est donnée figure E.5.

FIG. E.1 – Schéma bloc de l’asservissement du processus

Clock

Const XMgraphSampler

perturbation

processus

in1

in2

in3

Regulation d’un processus du premier ordre

FIG. E.2 – Schémas blocs sous Ptolemy du système asservi

1. Synchronous Data Flow

196

Impulse Delay Filter

Generation d’une perturbation

FIG. E.3 – Schémas blocs sous Ptolemy du système asservi

IIRIIRSubAdd

XMgraphXMgraph

Regulateur et processus

regulateur processus

FIG. E.4 – Schémas blocs sous Ptolemy du système asservi

197

Signal epsilon

Set 0

Y

X

0.00

0.20

0.40

0.60

0.80

1.00

0.00 50.00 100.00 150.00 200.00

FIG. E.5 – Perturbation �

Sortie Y

Set 0

Y

X0.00

0.20

0.40

0.60

0.80

1.00

0.00 50.00 100.00 150.00 200.00

FIG. E.6 – Réponse temporelle du système asservi

198

Annexe F

Traitement des mesures etconsignes

Dans le traitement des mesures et consignes, il faut considérer deux casdifférents. D’une part, nous avons l’acquisition d’échantillons analogiques pardes convertisseurs analogique-numérique, et d’autre part, nous mesurons lavitesse 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 desconvertisseurs de 8 bits. Le traitement de ces mesures consiste à calculer lavaleur 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 analogiquedonné 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 sta-

toriques (�� et ��), la consigne de couple sous forme de la composante � ducourant 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éediffé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 descapteurs est reliée à un filtre anti-repliement et à un circuit de mise en formedes signaux analogiques qui ramène la mesure à une valeur entre 0V et 5V, lepoint de repos étant à � � ���V.

La valeur réelle des courants est donc calculée à partir de la mesure par larelation 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 connec-

tée directement au convertisseur. La consigne varie entre 0A et ��� ���. Lavaleur de ��� ��� se calcule à partir des caractéristiques du moteur donnéesen Annexe B.

Pour déterminer ��� ���, on se base sur les équations suivantes:

��� �%�*�

�� ��

�/*������

��� �3�@!�

avec ��� le courant magnétisant, %� le flux rotorique, *� l’inductance roto-rique, �� le couple moteur, / le nombre de paires de pôles, ��� le couple moteurnominal, 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 uncourant 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, laré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épha-sé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 depériodes d’horloge que dure une période du signal TOP, c’est à dire de flancde 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 formed’é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 pluslent que l’horloge. On en tient compte dans le calcul de la vitesse.

201