Application : Le Contrôleur de Moteurs

Cette partie montre les résultats d’une application de co-conception multilangage dans le cas

d’un modèle multilangage. L’application concerne le contrôle d’un bras de robot. Ce système

peut être divisé en deux parties : les moteurs commandant le bras du robot et le contrôleur. Le

langage SDL est utilisé pour modéliser le contrôleur alors que MATLAB, ou COSSAP dans

une autre configuration, modélisent le comportement physique des moteurs. Le contrôleur du

bras du robot peut ajuster les paramètres de vitesse et de position de deux moteurs. Quatre

signaux sont échangés entre le modèle MATLAB et le modèle SDL (2 pour chaque moteurs).

Le premier signal contrôle le moteur et le second lit la position courante du bras. Le schéma de

base est représenté sur la figure 4.8a). Le bloc GENERATEUR calcule une trajectoire pour tous

les moteurs commandant le bras du robot. Le bloc CAPTEUR reçoit les positions et les transmet

au contrôleur. Le bloc contrôleur a pour rôle de donner les ordres aux moteurs seulement lorsque

c’est possible.

La spécification SDL est composée de quatre blocs comprenant six processus : un

géné-rateur, un distributeur, un contrôleur par moteur et un échantillonneur par moteur. La figure

4.8b montre la structure des processus du système du contrôleur. Le générateur produit deux

si-gnaux, un ordre et une adresse. Le distributeur renvoie l’ordre au contrôleur du moteur désigné

Applications Résultant de MUSIC : Outil de Co-conception 110

Controleur

Générateur

Echantillonneur

Moteur 2

Moteur 1

Modèle SDL Modèle mécanique

Gener Dist

Ctrl2

Ctrl1

Echant1

Echant2

Echantillonneur _M1 Position M2 Position Generateur Générateur Ord Adr Controleur Ack Pos2 Pos1 Consm1 Cosm2 Moteur 1 Consigne Moteur 2 Consigne

(a)

(b)

FIG. 4.8 – Application du contrôleur de moteurs

par l’adresse. Un processus de contrôle donne l’ordre au moteur et “scan” sa position. Quand un

moteur est sur le point de réaliser son ordre, le processus de contrôle informe le générateur qu’il

est disponible pour une nouvelle opération. Etant donné que la position est un signal continu,

chaque processus échantillonneur se charge de digitaliser les signaux.

La modélisation du comportement physique des moteurs a été réalisée dans deux

configu-rations différentes : l’une en MATLAB et l’autre en COSSAP.

Enfin, le système complet et ses interconnexions sont décrits dans un fichier de coordination

qui sert d’entrée à MCI. A ce niveau le fichier est constitué de deux blocs interconnectés par

des canaux abstraits. On utilise donc le format SOLAR pour décrire notre système à simuler.

Pour les étapes suivantes l’utilisation de MUSIC permet de générer automatiquement le fichier

de coordination pour pouvoir cosimuler avec MCI.

Dans un premier temps, il est intéressant de modéliser les moteurs en MATLAB ou en

COS-SAP et de garder la spécification SDL initiale. La première vérification consiste en la validation

du système complet dont les sous-systèmes modélisant les moteurs sont réalisés en MATLAB

ou en COSSAP. Les copies d’écran de la figure 4.9 représentent deux cosimulations de très haut

niveau d’abstraction SDL-MATLAB sur la figure a et SDL-COSSAP sur la figure b. Ce type

de modélisation et de cosimulation présente un sérieux avantage. MATLAB est très approprié

pour simuler un moteur et offre donc toutes les possibilités pour modifier les paramètres au

cours de la simulation. De plus, elle permet de séparer les moteurs de la spécification SDL, qui

est introduite dans l’outil de co-conception. Avec ce type de cosimulation, on vérifie ainsi que

la spécification réalisée à haut niveau est conforme au cahier des charges. Il est vrai que la

mo-délisation et la simulation entière du système peut se faire directement en SDL, mais certains

sous-systèmes comme la modélisation des moteurs est plus rapide à réaliser en MATLAB qu’en

SDL. C’est pourquoi, le concepteur est amené à découper sa spécification avant de la modéliser.

Applications Résultant de MUSIC : Outil de Co-conception 111

(a) (b)

FIG. 4.9 – Cosimulations à haut niveau

Il sera beaucoup plus rapide de modéliser la partie mécanique (environnement extérieur) et le

reste en SDL et de cosimuler l’ensemble du système, plutôt que de tout modéliser en SDL et de

le simuler, pour ensuite le partitionner.

Dans ce type de simulation, le système est validé à très haut niveau avec son environnement

extérieur avant d’être raffiné par un outil de co-conception.

Cosimulation Non Temporelle au Niveau Architecture

Le C généré par MUSIC est un C non dédié à un processeur. Le VHDL est un VHDL

RTL qui peut directement passer à l’étape de synthèse. MUSIC génère également les modèles

directement utilisables par l’outil de cosimulation et fournit un fichier SOLAR de coordination

pour décrire les connexions des modules générés.

A ce nouveau niveau, la cosimulation C-VHDL-Environnement peut être exécutée (figure

4.10). Le modèle VHDL est simulé sur un déboggueur VHDL, l’environnement est toujours

simulé par son ou ses simulateurs appropriés (MATLAB sur la figure 4.10), et le C sera exécuté

sur la machine ou par l’intermédiaire d’un déboggueur pour analyser son exécution (l’outil

DDD ”Data Display Debugger” sur la figure). Si un modèle nécessite d’être simulé sur une

autre machine, l’utilisateur doit tout simplement éditer ce fichier de coordination et y adjoindre

le nom de la nouvelle machine désirée.

Le concepteur peut parfois avoir besoin de simuler son système avec la notion de temps

sans pour autant utiliser un modèle du processeur. Il est possible à ce niveau d’obtenir la notion

de temps par l’annotation temporelle approximative des temps d’exécution du langage C et

par adjonction d’une propriété “TIMESTEP” dans le fichier de coordination. Les fichiers C sont

recompilés en mode temps-réel, et l’outil de cosimulation synchronise les “temps semi-virtuels”

des simulateurs entre eux. Le programme C généré par MUSIC est en fait annoté en temps à

chaque passage dans la boucle de la machine d’état. Les simulateurs du modèle extérieur sont

inclus dans cette synchronisation temporelle uniquement s’ils contiennent la gestion du temps

à l’intérieur de leurs simulations (MATLAB par exemple). Ce type de cosimulation en mode

annotation permet plus souvent d’ajuster les vitesses des simulateurs entre eux, plutôt que de

permettre une vérification temporelle.

Applications Résultant de MUSIC : Outil de Co-conception 112

FIG. 4.10 – Cosimulation par exécution native

4.3.2.1 Cosimulation Temporelle au Niveau Cycle

Pour pouvoir à nouveau descendre dans les niveaux d’abstraction, l’introduction de modèles

de processeur est indispensable. Le C généré est donc modifié suivant les caractéristiques du

processeur et des ports dont il dispose pour échanger ses données. Si ces ports ne sont pas

suffi-sants, il faut ajouter des interfaces, etc.. Le “targeting”

³

permet de correctement implanter le C

généré dans un processeur. Le C obtenu est compilé par le compilateur associé au processeur et

le code binaire obtenu est inscrit dans sa mémoire. La cosimulation synchronisée de l’ensemble

processeur(s)-VHDL et de l’environnement extérieur est la dernière étape de validation avant

l’implémentation du prototype virtuel.

Cette cosimulation est synchronisée en respectant le modèle de la barrière temporelle et

permet de valider par simulation le système complet, à l’origine en SDL, à très bas niveau. La

simulation de l’environnement extérieur est toujours réalisée avec le simulateur MATLAB. La

figure 4.11) représente cette simulation avec un microcontrôleur (Intel 8051). De nombreuses

configurations ont été réalisées autour du 8051 et/ou du ST10 et de nouveaux travaux

inter-viennent également dans l’étude des performances en fonction du partitionnement des modules

matériels et logiciels sur différents processeurs.

Applications Résultant de MUSIC : Outil de Co-conception 113

FIG. 4.11 – Simulation au niveau cycle d’horloge

même machine Machine différente

C-C Proc-Proc C-C Proc-Proc

Temps d’un cycle (ms) 39.9 43.2 68.3 70.7

Nb Cycle/s 25 23 15 14

TAB. 4.1 – Temps de cosimulation

Dans le document Cosimulation multiniveaux dans un flot de conception multilangage (Page 111-115)