CONCEPTION ORIENTÉE OBJET D'UN CONTRÔLEUR DE ROBOT

 
DEA Automatique Informatique Industrielle
          Année Universitaire 1998 – 1999

CONCEPTION ORIENTÉE OBJET D’UN
    CONTRÔLEUR DE ROBOT

               JÉRÉMIE GUIOCHET

   Equipes : Sûreté de Fonctionnem ent des Systèm es &

                 Systèm es Dynam iques

  Responsables : Mlle Claude BARON et M. Bertrand TONDU
Chapitre 1 - Contexte de l'étude                                                                                                              2

                                                             SOMMAIRE
INTRODUCTION ........................................................................................................................... 4

CHAPITRE 1 . CONTEXTE DE L'ÉTUDE ................................................................................... 5
   1.1. CHOIX TECHNOLOGIQUES ....................................................................................................... 5
     Description de la manipulation................................................................................................. 5
     Le choix de Vxworks - Tornado............................................................................................... 6
     Utilisation de Vxworks.............................................................................................................. 6
   1.2. CHOIX MÉTHODOLOGIQUES ..................................................................................................... 6
     La représentation objet ............................................................................................................ 6
     Le choix UML........................................................................................................................... 7
   1.3. CONCLUSION ......................................................................................................................... 7
CHAPITRE 2 . DE LA SPÉCIFICATION À LA CONCEPTION.................................................... 8
   2.1. LE GÉNIE LOGICIEL ORIENTÉ OBJET ......................................................................................... 8
     Les étapes de la spécification et de la conception.................................................................. 8
     Passage de la spécification à la conception ........................................................................... 9
   2.2. LE GÉNIE UML ...................................................................................................................... 11
     La spécification ...................................................................................................................... 11
     La conception......................................................................................................................... 11
     Bilan ....................................................................................................................................... 12
   2.3. REPRÉSENTATION DES TÂCHES ET DES ÉLÉMENTS DE SYNCHRONISATION .............................. 12
     Représentation des tâches.................................................................................................... 12
     Modélisation des objets de Vxworks ..................................................................................... 13
   2.4.BILAN .................................................................................................................................... 15
CHAPITRE 3 . MODÉLISATION DU CONTRÔLEUR DE ROBOT ......................................... 16
   3.1. SPÉCIFICATION ..................................................................................................................... 16
   3.2. CONCEPTION BASÉE SUR UN CONTRÔLE CENTRALISÉ............................................................ 19
     Diagramme de classes ......................................................................................................... 20
     Diagrammes de séquence.................................................................................................... 22
     Diagramme d’activité ............................................................................................................. 23
     Diagramme de collaboration.................................................................................................. 25
     Bilan de la conception............................................................................................................ 25
   3.3. CONCEPTION BASÉE SUR UN CONTRÔLE DISTRIBUÉ .............................................................. 26
     Diagramme d'états ................................................................................................................ 26
     Diagramme de classes ......................................................................................................... 27
     Bilan de la conception............................................................................................................ 28
   3.4. COMPARAISON ...................................................................................................................... 28
CHAPITRE 4 . IMPLANTATION ET RÉSULTATS .................................................................... 30
   4.1. IMPLANTATION DE LA CONCEPTION « CENTRALISÉE » ............................................................. 30
     Synchronisation des tâches .................................................................................................. 30
     Performances du système.................................................................................................... 34
   4.2. IMPLANTATION DE LA CONCEPTION « DISTRIBUÉE » ................................................................ 35
     Implantation du parallélisme.................................................................................................. 35
     Synchronisation des tâches .................................................................................................. 37
     Performances ........................................................................................................................ 38
   4.3. BILAN ................................................................................................................................... 39
CONCLUSION ............................................................................................................................. 40

RÉFÉRENCES BIBLIOGRAPHIQUES ...................................................................................... 41
Chapitre 1 - Contexte de l'étude                                                                                                 3

                                             TABLE DES FIGURES

FIGURE 1. BANC DE LA MANIPULATION ................................................................................................ 5
FIGURE 2. MODÈLE DE DÉVELOPPEMENT EN CASCADE ....................................................................... 9
FIGURE 3. TRANSITION ENTRE LES DIFFÉRENTS MODÈLES .................................................................. 9
FIGURE 4. RETOUR D 'INFORMATIONS ENTRE LES PHASES ................................................................. 10
FIGURE 5. CYCLE DE VIE ITÉRATIF .................................................................................................... 10
FIGURE 6. DIAGRAMME DE SÉQUENCE                   ILLUSTRANT L 'UTILISATION D 'UN WATCHDOG .......................... 13

FIGURE 7. DIAGRAMME DE SÉQUENCE ILLUSTRANT L 'UTILISATION D 'UN SÉMAPHORE.......................... 14
FIGURE 8. STRUCTURE FONCTIONNELLE D 'UN CONTRÔLEUR DE ROBOT........................................... 16
FIGURE 9. DIAGRAMME DE SÉQUENCE ILLUSTRANT L 'ACTION DU CONTRÔLEUR DES MOUVEMENTS..... 17
FIGURE 10. DIAGRAMME DE SÉQUENCE DE L 'ASSERVISSEMENT......................................................... 18
FIGURE 11. DIAGRAMME DE CLASSES ............................................................................................... 18
FIGURE 12. DIAGRAMME D'ÉTATS DE LA CLASSE CONTRÔLEUR DES MOUVEMENTS............................. 19
FIGURE 13. DIAGRAMMES DES TÂCHES............................................................................................. 20
FIGURE 14. RELATION ENTRE UNE TÂCHE ET UNE CLASSE ................................................................ 20
FIGURE 15. HÉRITAGE SIMPLE.......................................................................................................... 21
FIGURE 16. DIAGRAMME DE CLASSES POUR LA CONCEPTION ............................................................ 21
FIGURE 17. DIAGRAMME DE SÉQUENCE ILLUSTRANT LES COMMUNICATIONS INTERTÂCHES ................ 22
FIGURE 18. DIAGRAMME D'ACTIVITÉ DE LA TÂCHE CONTRÔLEUR DES MOUVEMENTS ........................... 24
FIGURE 19. DIAGRAMME DE COLLABORATION .................................................................................... 25
FIGURE 20. DIAGRAMME D'ÉTATS ..................................................................................................... 27
FIGURE 21. DIAGRAMME DE CLASSES ............................................................................................... 28
FIGURE 22. LÉGENDE DES GRAPHIQUES SUIVANTS ........................................................................... 31
FIGURE 23. COMMANDE ÉCHANTILLONNÉE PENDANT LE CALCUL D'UNE TRAJECTOIRE ....................... 32
FIGURE 24. SYNCHRONISATION ET LANCEMENT DES TÂCHES ............................................................ 33
FIGURE 25. FIN DE LA COMMANDE ET DÉBUT D 'UNE NOUVELLE GÉNÉRATION ..................................... 34
FIGURE 26. COMMANDE ÉCHANTILLONNÉE ET FIN DE LA GÉNÉRATION ............................................... 37
FIGURE 27. FIN DE LA COMMANDE D 'UN TRAJET ................................................................................ 38
Chapitre 1 - Contexte de l'étude                                                            4

                                                                    INTRODUCTION

         Les robots industriels sont généralement des machines dont l’informatique – le
contrôleur du robot – est spécifique et donc non portable à un autre robot. Or il existe une
demande à la fois industrielle et de recherche pour définir une modélisation générique d’un
contrôleur de robot. Sur le plan industriel, dans le prolongement de la notion de ‘carte
intelligente d’axe’ on vise à des architectures de contrôle de systèmes articulés indépendants de
la motorisation comme de la structure du robot. Sur le plan de la recherche, le développement
d’applications nécessitant un partage de l’environnement du robot avec son environnement
conduit à rechercher des architectures fiables et évolutives bien éloignées des architectures
figées des robots industriels dont l’environnement immédiat est interdit à l’opérateur humain.
Dans ce contexte, les méthodes de l’Informatique Industrielle pour la spécification et
conception des systèmes temps réel doit aider à cette modélisation du système complexe
qu’est un contrôleur de robot.

        Le LESIA qui développe depuis plusieurs années, au sein de son Equipe Systèmes
Dynamiques, des robots à muscles artificiels destinés à une Robotique de Service est
confronté à ce problème de la modélisation de tels contrôleurs de robots. Une thèse y est
actuellement en cours [CARc], en collaboration avec l’Equipe Sûreté de Fonctionnement des
Systèmes du LESIA, pour analyser et comparer des méthodes de spécification appliquées à
une architecture-type de contrôleur de robot. Dans le cadre de ce travail, mon DEA s’intéresse
plus particulièrement au passage de la spécification à la conception. Partant d’une spécification
faite en UML, je me suis intéressé à la conception orientée objet qui en découle, et plus
particulièrement à la modélisation des processus et de leur synchronisation.

        Le premier chapitre expose les choix du laboratoire en matériel et méthodes pour l’étude
de ce contrôleur, en particulier le langage de modélisation objet UML et le recours au noyau
temps réel Vxworks. Le deuxième chapitre introduit les principes du Génie Logiciel orienté objet
et l’apport d’UML pour la résolution des problèmes temps réel. Le troisième chapitre développe
la mise en œuvre d’UML pour concevoir le contrôleur. Le dernier chapitre est la validation des
modèles par l’implantation et l’évaluation des performances du système.
Chapitre 1 - Contexte de l'étude                                                            5

                                                                        Chapitre          1
                                                       Contexte de l'étude
L’équipe Système Dynamique du LESIA a développé une plate-forme technique basée sur
l’étude d’un robot 2 axes. Son évolution est liée aux avancées technologiques. Ce premier
chapitre expose les choix technologiques et méthodologiques récemment effectués lors de la
dernière maintenance.

1.1. Choix technologiques

Description de la manipulation

La manipulation existante au laboratoire permet de contrôler un bras à deux degrés de liberté (de
type SCARA). La rotation de chaque axe est assurée par un couple de muscles artificiels
(muscles de McKibben [TON97] ) alimentés par l’intermédiaire de servovalves (convertisseurs
intensité/pression). Le contrôleur est implanté sur un PC sous le système d'exploitation
Vxworks. Le développement du programme et la mise au point s'effectue sur une station sous
UNIX avec l’application Tornado [TOR95]. La transmission du programme compilé se fait par le
réseau (cf. Figure 1).

Figure 1.Banc de la
manipulation
Chapitre 1 - Contexte de l'étude                                                               6

Le choix de Vxworks - Tornado

Pour pouvoir garantir un contrôleur facilement modifiable, portable, évolutif et observable le choix
a été fait, comme pour d'autres développements (Par exemple le logiciel GENERIS exposé au
SITEF’99 [GEN97]), d'utiliser un système implanté sur une cible que l'on pilote à partir d'un hôte
(Cf. Figure1).
La réalisation d’un système temps réel implique des contraintes et la prise en compte de
facteurs (exposés ci dessous) qui ne sont pas traités par des systèmes d’exploitation comme
UNIX ou WINDOWS.
De plus le contrôleur utilise des tâches parallèles de commande d'axes et de calcul de
trajectoire. Leader sur le marché industriel, le système d’exploitation temps réel WindRiver
Vxworks est une référence dans ce domaine [ATT97] [GEN97].
Mais il ne peut pas fournir un environnement nécessaire à des applications de développement
qui ne sont pas temps réel. C'est pour cette raison qu'il s'utilise avec un autre système
coopérant, l’hôte (cf. figure1). Le logiciel de développement d’application temps réel associé à
Vxworks s’appelle Tornado [TOR95]. Fonctionnant sous UNIX, il permet également la mise au
point à distance des applications.

Utilisation de Vxworks

La principale particularité de ce noyau est son aptitude à gérer les tâches. Ce système permet
d'initialiser, de lancer et de suspendre des tâches parallèles. En effet il crée un pseudo-
parallèlisme (pour un monoprocesseur) pouvant fonctionner, au choix, de plusieurs façons
[VXW97] : un ordonnancement prioritaire (on attribue aux tâches des niveaux de priorités) ou
une répartition équitable du temps entre toutes les tâches ("Round-Robin Scheduling").
La synchronisation est assurée par l'existence de sémaphores, de files de messages, et de
signaux. Il est possible d'utiliser d'autres fonctions comme les "watchdogs" (permettant de
limiter la durée de certaines tâches ou de créer un appel périodique de fonctions) ainsi que les
interruptions classiques à tout système.
D'autres particularités spécifiques à la gestion de réseaux existent mais nous ne les utilisons
pas pour l'instant.

1.2. Choix méthodologiques

La représentation objet

Il découle des études précédentes [CAR99b] et de la tendance actuelle que les projets temps
réel gagnent à "l'Orientation Objet". Ceci pour ses propriétés de stabilité, de facilité de
construction itérative (due au couplage faible entre les composants) et de réutilisabilité. Elle
émerge par sa capacité d'unification et d'intégration d’entités élémentaires pour obtenir un
système complexe.
C’est pour cette raison que le choix d’une modélisation Orientée Objet suivie d’une implantation
en C++ a été effectué.
Chapitre 1 - Contexte de l'étude                                                               7

Le choix UML

U.M.L. (Unified modeling Language) est un langage de modélisation orienté objet de troisième
génération. Il adapte et étend le travail de Grady Booch[BOO94], Jim Rumbaugh[OMT91] et Ivar
Jacobson [OOS92] . Ce nouvel outil unifie des langages déjà utilisés dans de nombreux
développements. Dans le cas de notre application, le choix UML a été motivé par une étude
comparative entre la démarche fonctionnelle SART et l’approche objet UML [CAR99b] pour le
cas du contrôleur de robot.
La réutilisabilté et la modifiabilité sont des qualités reconnues de cette approche. L'encapsulation
des données et des fonctions dans les classes facilite la compréhension du modèle. La
concurrence est également bien intégrée aux modèles.
Les différents diagrammes utilisés pour le développement par UML sont présentés dans le
chapitre suivant.

1.3. Conclusion
Les moyens technologiques et méthodologiques qui ont été choisis sont spécifiques au
développement d'un système temps réel. Ils sont récents et leur utilisation industrielle tend à se
développer. La maîtrise d’UML et de Vxworks en particulier a été indispensable pour effectuer les
choix de conception décrit au chapitre 3.
L'outil de spécification et de conception qu'est U.M.L. est encore en mutation. Mais ses
premières versions et son orientation vers le temps réel sont déjà utilisés dans beaucoup
d’entreprises.
De plus le passage de la conception à l'implantation en C++ est également en cours d'évolution.
Le chapitre suivant expose les problèmes du passage de la spécification à la conception d'un
point de vue génie logiciel, puis plus précisément pour UML.
Chapitre          2
                       De la spécification à la conception
Les réalisations de systèmes embarqués ou de logiciels suivent des méthodes qui conduisent à
modéliser et construire des produits de manière fiable et reproductible. L’élaboration peut subir
quelques écarts qui varieront suivant le développeur. Mais il existe des concepts fondamentaux.
Les deux premières parties de ce chapitre présentent les bases du génie logiciel orienté objet et
les particularités d’UML. Cette synthèse met en évidence les possibilités d’UML pour le
traitement des applications temps réel multitâches.
La littérature sur UML propose en effet quelques pistes pour résoudre le problème des tâches et
de leur communication mais elle ne s’attarde cependant pas à donner d’exemple concret et de
directive précise.

Lors de la modélisation de notre système, la présence de Vxworks et de tous ses outils implique
sa participation au modèle. A travers la représentation des tâches il nous faudra donc prendre
en compte les particularités de ce noyau temps réel.
Ainsi la troisième partie de ce chapitre détermine où et comment au sein du développement faire
intervenir le modèle de Vxworks pour en déduire des solutions UML.

2.1. Le génie logiciel orienté objet

Les étapes de la spécification et de la conception

Différentes méthodes de développement ont été expérimentées ces dernières années. Nous
considérons dans ce chapitre deux étapes spécifiques au cycle de développement :
- la spécification
- la conception
La plupart des méthodes s’appuient sur ces étapes auxquelles on rajoute traditionnellement le
codage et les tests. En vue de l’utilisation d’UML pour notre problème nous limiterons ce travail
de DEA aux deux étapes ci-dessus. Il convient de bien les différencier.

La spécification correspond à l’analyse des besoins et à la modélisation d’un point de vue
logique du système. Il s’agit d’élaborer une structure robuste et modifiable directement liée aux
besoins. Elle s’appuie généralement sur l’analyse des cas d’utilisations (uses cases), formalisés
par Ivar Jacobson [JAC92] : Ils décrivent sous la forme d'actions et de réactions le
comportement d'un système du point de vue d'un utilisateur.
Cette étape ne prend pas en compte le choix de matériel, le langage d’implantation, les
contraintes temps réel (au sens rapidité du matériel)...[JAC 93]. Il est donc indépendant de
l’environnement d’implantation dont fait parti le noyau temps réel Vxworks (système d’exploitation
de ce système). Il faut donc faire abstraction à cette étape des problèmes de tâches et de
synchronisation.
Chapitre 2 - De la spécification à la conception                                            9

La conception permet d’adapter et affiner la structure objet pour l’environnement
d’implantation. On spécialise les concepts pour qu’ils correspondent à la sémantique de ce
milieu [JAC 93].
Interviennent ici les éléments évités précédemment. Il s’agit de donner des solutions en fonction
du milieu et de la maîtrise du développeur. Notamment on résout les problèmes des contraintes
temps réel et on prend en compte le système d’exploitation. Par exemples pour la
synchronisation des tâches Vxworks propose des sémaphores, des watchdogs, des files de
messages... qu’il convient de maîtriser pour les introduire dans cette étape.

Passage de la spécification à la conception

Le problème de la transition entre ces deux étapes s'est toujours posé aux développeurs. Il est
important de conserver la spécification lors de la conception pour obtenir un modèle robuste et
facilement modifiable. Une méthode idéale consisterait en une "cascade" de ces étapes et une
totale indépendance entre les deux (cf. Figure 2).

Figure 2. Modèle de
développement en
Cascade

                                      Spécification               Conception

Mais il est rare de rencontrer une application de cette méthode. Le modèle en cascade ne donne
des résultats satisfaisants que lorsqu'il est possible d'enchaîner les phases sans trop de
problèmes. En réalité les étapes s’enchaînent progressivement (cf. Figure 3).

Figure 3. Transition entre
les différents modèles

                             Spécification

                                                                Conception

                  Indépendant                                                  Dépendant

                                  Dépendance de l’implantation

                        -                                                        +
                                                      détails

De plus, "Le modèle d’analyse idéal doit souvent être modifié, du fait d’un environnement
d’implantation complexe, même si ce n’est pas désirable... " [JAC 93]. Les différents modèles
seront donc amenés à être régulièrement retouchés (même à contrecœur) lors de la réalisation
du système (cf. Figure 4).
Chapitre 2 - De la spécification à la conception                                           10

Figure 4. Retour
d'informations entre les
phases

                                Analyse

                                                   Conception

                                                                    Codage

De ces considérations ont été décrites des méthodes générales dites itératives (ou encore
modèle de la spirale) où l’on construit plusieurs versions du produit, en considérant les deux
points précédents. La Figure 5 illustre la façon dont s’imbriquent les trois étapes de
spécification, conception et codage à une itération du développement. On réalise ainsi plusieurs
versions du projet en cours.

Figure 5. Cycle de vie
itératif

                                  Analyse

                                              Conception

                                                           Codage

                                             Iteration n

Ainsi les étapes de spécification et conception sont bien différentes par leur définition mais le
passage ne semble pas bien défini. "Il faut passer du modèle d’analyse au modèle de
conception lorsque les conséquences de l’environnement d’implantation commencent à se faire
sentir..." [JAC93]. Nous essaierons ici de bien expliciter ce "faire sentir" pour UML. Le
paragraphe suivant montre comment par l’utilisation de plusieurs diagrammes d’UML, la
transition peut être claire et que l’on peut ainsi conserver les propriétés de la spécification.
Chapitre 2 - De la spécification à la conception                                               11

2.2. Le génie UML
S’appuyant sur des méthodes qui existent depuis plusieurs années, UML suit une démarche
identique à celle exposée dans le paragraphe précédent. Mais l’utilisation de diagrammes
permet d’appliquer des règles qui nous permettront de savoir exactement où et comment
introduire les tâches et le modèle de Vxworks.

La spécification
Elle est modélisée par ce qu'appelle P.A.Muller la Vue Logique [MUL98]. Il s'agit de représenter
les aspects statiques et dynamiques du système. Elle est structurée autour de plusieurs
diagrammes :
1. Les diagrammes des cas d'utilisation décrivent les interactions entre le système et l'utilisateur.
2. Les diagrammes de séquence montrent l'interaction entre plusieurs objets d'un point de vue
temporel.
3. Les diagrammes de collaboration décrivent la structure statique par des liens entre objets, et
le comportement à travers des envois de messages le long de ces liens. A la différence des
diagrammes de séquence, l'accent est mis sur la structure spatiale.
4. Les diagrammes de classes expriment la structure statique d'un système, en termes de
classes et de relations entre ces classes.
5. Les diagrammes d'états montrent le comportement des classes. Ils sont basés sur les
statecharts définis par Harel.
6. Les diagrammes d'activités sont des variantes des diagrammes d'états. Ils sont utilisés pour
représenter le comportement interne d'une méthode.

Lors de l'élaboration de ces diagrammes on respecte le choix d’indépendance du modèle par
rapport au milieu d’implantation. L'utilisateur peut être étonné du nombre de diagrammes mais
chacun illustre pourtant un aspect du système. Il y a bien sûr une redondance entre certains
mais l'utilisateur choisi ceux qui le mèneront à la conception en fonction du système et de son
expérience. L'illustration de ces diagrammes est donnée au chapitre suivant.
Il est bien sûr possible de rajouter des diagrammes comme les diagrammes Temporels de
B.P.Douglass [DOU98] qui représentent l'évolution en fonction du temps de l'état d'un système.

La conception
Cette étape fait apparaître les choix technologiques, les éléments de synchronisation,
l'organisation du logiciel. Le problème soulevé est celui de la perte des spécifications lors de
l’enrichissement des modèles pour la conception [MUL98]. La méthode proposée est la
réalisation de plusieurs vues, soient trois autres vues distinctes qui correspondent à trois
démarches du développeur toutes reliées par la vue plus globale des cas d’utilisation :
- La Vue de Déploiement décrit les ressources matérielles et l'implantation du logiciel dans ces
ressources. Elle n'utilise que le diagramme de déploiement. Elle est particulièrement importante
pour les systèmes multiprocesseurs.
- La Vue des Processus caractérise la décomposition en flots d’exécution. Les tâches et leur
synchronisation sont ici représentés. Les diagrammes de collaboration, de séquence, des
composants et d’états - transition sont enrichis par les choix de conception.
- La Vue de Réalisation développe l'organisation des modules (classes, tâches, sous
programmes, programme principal) dans l’environnement d'implantation. Elle utilise les
diagrammes des composants.
Chapitre 2 - De la spécification à la conception                                              12

La conception se caractérise donc par l'ajout de nouveaux diagrammes. Nous verrons au
chapitre 3 qu’un simple enrichissement des diagrammes de spécification ne peut mener à la
conception.

Notons que B.P.Douglass propose une autre démarche de réalisation en trois phases [DOU98]
:
- Architecturale : spécification de la quantité et de la qualité du matériel, modèle de concurrence
et stratégies de communication intertâches.
- Mécanique : Communications inter objets
- Détaillé : Implantation des structures de données et des algorithmes à l’intérieur d’une classe.

Il existe donc plusieurs méthodes de conception. Nous retiendrons ici la première approche (de
P.A.Muller) pour notre développement.

Bilan
La modélisation des tâches, pendant la conception, se situe donc dans les vues des processus
et de réalisation. Pour bien concevoir leur synchronisation on introduit donc ici les outils et les
actions de Vxworks.
Il existe d’autres diagrammes comme le diagramme des tâches [DOU98] (Cf. Figure 13) qui
permettent d’augmenter la conception.
UML à travers ses étapes de modélisation devrait donc permettre de faire un choix pour le
passage de la spécification à la conception. L’apparition des tâches devrait donc faire apparaître
pour notre cas les éléments de synchronisation. On peut noter qu’il peut exister alors une
spécification de la conception (par exemple celle des tâches), on fait alors apparaître les outils
de synchronisation du noyau temps réel.
Les diagrammes utilisés lors de la conception permettent de donner des indications quant à la
manière de modéliser les tâches et les éléments de Vxworks ceci est développé dans la partie
suivante qui expose quelques pistes de modélisation données par la littérature très récente sur
UML.

2.3. Représentation des tâches et des éléments de synchronisation
Tous s’accordent à dire [LAI97], [DOU98], [MUL98] que les tâches sont des "objets actifs"
(possédant leur propre flot de contrôle) mais peu semblent vouloir donner des exemples de
modélisation.
Ainsi il convient de bien modéliser les tâches dans les diagrammes UML puis d’introduire les
objets de Vxworks dans ces modèles.

Représentation des tâches

Les diagrammes de classe et objets peuvent montrer les tâches et les diagrammes d’états
permettent de représenter le parallélisme [DOU98]. Les diagrammes de collaboration et de
séquence montrent des scénarios spécifiques des tâches et de leurs relations avec d’autres
tâches.
Une tâche peut donc être représentée par une classe qui enrichit le modèle de spécification.
On peut noter que "aussi peu d’objets que possible doivent être au fait des contraintes portant
sur l’implantation... "[JAC93], il va donc falloir bien séparer les tâches (et leur synchronisation)
des autres classes de la spécification.

Les tâches sont donc des objets actifs, c’est à dire possédant une action de contrôle sur
d’autres classes "inactives". On peut donc parler de méthode active qui définira un processus
de contrôle. Par exemple la méthode de la tâche de commande des articulations du bras sera
asservir() (réception de la consigne, mesure de la position réelle, calcul du P.I.D. et
commande de l’actionneur). Cette méthode est en fait l'action principale de la tâche. Les tâches
Chapitre 2 - De la spécification à la conception                                             13

peuvent aussi avoir un comportement complexe nécessitant un diagramme d'état illustrant leur
activité. Le chapitre suivant expose justement ces deux points de vue à travers deux
conceptions.

Il existe aussi un diagramme de tâches qui est un diagramme de classes composé seulement
des objets actifs et de leurs associations. Mais ici c’est la présence des éléments tels que des
watchdogs ou des sémaphores n'y est pas représenté. Ce diagramme n'apporte donc pas ici
l'expression des mécanismes de synchronisation. Il expose simplement les tâches et leur
répartition spatiale pour le cas d'une application multiprocesseurs.
Le diagramme des composants (représentation spatiale des fichiers .h et .cpp et de leur
dépendance) exprime lui aussi les tâches comme étant des sous-programmes (par des
fichiers "penchés").
Les tâches sont donc modélisables en tant qu'objets s'ajoutant aux diagrammes et en tant que
code différent d'une simple déclaration de classe. Elles sont des entités à part spécifiques au
système étudié.

Modélisation des objets de Vxworks

Il faut noter ici l’importance des diagrammes de séquence qui sont un outil très puissant de la
modélisation temps réel. Ils servent à la spécification des tâches [LAI98] mais aussi à la
conception. Deux étapes peuvent décrire leur utilisation [MUL98] : une première qui est une
description de l’interaction sans entrer dans les détails de la synchronisation et la deuxième qui
est pour un usage plus informatique.
Cette dernière est donc une représentation plus précise des interactions. Apparaissent ici les
appels de procédures, les événements discrets, les signaux entre flots d’exécution..., Il faut donc
introduire les outils du noyau.

Le choix de représentation s’est fait grâce à la notation de B.P.Douglass [DOU98].
La présence de diagrammes de conception faisant intervenir un sémaphore et un watchdog
confirme les hypothèses d’une modélisation des outils de Vxworks.

Notamment il existe deux diagrammes de séquence.

L’utilisation du watchdog est interprétée comme un service demandé à un objet watchdog qui a
une action sur le client. Ce diagramme de séquence (cf. Figure 6) montre le cas ou si le client
ne réitère pas sa demande de service après un certain temps il est réinitialisé. La modélisation
est en UML et montre l'interaction entre deux objets en fonction du temps.

Figure 6. Diagramme de
séquence illustrant
l'utilisation d'un
watchdog
Chapitre 2 - De la spécification à la conception                                         14

La Figure 7 illustre l’utilisation d’un sémaphore pour la synchronisation de tâches. Le
synchroniseur permet ici de réserver une ressource pour l'objet client. La présence d'autres
clients voulant utiliser la ressource est sous-entendue.

Figure 7. Diagramme de
séquence illustrant
l'utilisation d'un
sémaphore

On peut ainsi étendre l’utilisation du diagramme de séquence pour la modélisation de files, de
compteurs... Il sera donc ensuite nécessaire d’introduire ces éléments dans les diagrammes
d’objets et de classes. Mais tous les choix de synchronisation seront exprimés par les
diagrammes de séquence.
Chapitre 2 - De la spécification à la conception                                          15

2.4.Bilan
Les éléments de synchronisation sont donc pris en compte lors de la conception. Cette étape
correspond à des diagrammes UML précis. Nous savons donc quand et comment introduire la
modélisation des objets de Vxworks.
Les tâches sont représentées en tant qu'objets (et même classes) que l'on introduit dans les
diagrammes de spécification. Certains objets de la spécification imposant un contrôle sur
d'autres objets et un parallélisme au sein de leurs méthodes sont enrichis lors de la conception
par tous les éléments de synchronisation (objets de Vxworks). Ces derniers sont en effet des
objets instances des classes offertes par le noyau. Elles sont spécifiques au choix de ce
système d'exploitation.
Le chapitre suivant expose la spécification et la conception du contrôleur découlant des
considérations.
Chapitre          3
                      Modélisation du contrôleur de robot
Cette partie s'appuie sur les résultats de Luis Carroll de spécification de contrôleurs de robots
industriels [CAR99b] (exposés dans la partie suivante). Les diagrammes exposés sont une
version simplifiée par rapport à la thèse de Luis Carroll, pour pouvoir mieux s'intéresser au
passage de la spécification à la conception (en deuxième partie). On étudiera deux versions de
conception en vue de cerner les possibilités qu’offre le milieu d’implantation.

3.1. Spécification
L'étude que j'ai effectuée est le passage de la spécification à la conception pour la partie
contrôleur de mouvement qui constitue la partie essentielle d’un contrôleur de robot (cf. Figure
8). Cette figure est la représentation la plus générale d'un contrôleur de robot.

Figure 8. Structure
fonctionnelle d'un
contrôleur de robot

[CAR99b]
Chapitre 3 - Modélisation du contrôleur de robot                                            17

Il est important de remarquer que la génération des mouvements c’est à dire l’ensemble des
points définissant la trajectoire du bras doit se faire en ligne.
Par ailleurs, la commande des mouvements doit se faire avec une période d'échantillonnage
inférieure à 10 millisecondes.
Les diagrammes exposés dans la suite de ce chapitre ne caractérisent que la partie contrôleur
des mouvements.
En établissant différents scénarios [CAR99b] les classes principales sont identifiées :

Type d'objet                         Fonctions                   Documentation
Capteur                              mesurer()                   Réception et décodage des
                                     calibrer()                  données des capteurs
Actionneur                           commander()                 Commande       effective  des
                                                                 servovalves    alimentant les
                                                                 actionneurs
Contrôleur d'axe                     CalculBF()                  Réception de la consigne de
                                     asservir()                  mouvement et de la position du
                                                                 bras.      Le     calcul    de
                                                                 l'asservissement est effectué
                                                                 et envoyé pour la commande.
Génération de la trajectoire         calculer_consigne()         Le calcul des points du trajet
                                                                 est effectué.
Contrôleur des mouvements            contrôler_mouvement()       Classe chargée du contrôle
                                                                 des       instructions    de
                                                                 mouvement des axes du robot.
                                                                 Elle gère les processus de
                                                                 génération et de commande.

La communication entre ces objets se modélise par les diagrammes de séquence de la Figure
9. Le contrôleur des mouvements reçoit les consignes de la classe calcul de la trajectoire par la
méthode envoyer_resultat puis il les envoie à chaque Contrôleur d'axe avec la méthode
asservir (à une fréquence d'échantillonnage choisie).

Figure 9. Diagramme de
séquence illustrant
l'action du contrôleur des
mouvements

L'asservissement de position qu'effectue le Contrôleur d'axe est représenté en Figure 10.
Chapitre 3 - Modélisation du contrôleur de robot                                              18

Figure 10. Diagramme
de séquence de
l'asservissement

Le contrôleur d’axe reçoit la consigne et la mesure de position, il effectue ensuite le calcul de la
correction (avec un P.I.D.) avec la méthode calculBF(). Et enfin il envoie la commande vers
l’actionneur en appelant la méthode commander().

Les interactions décrites dans ces deux diagrammes permettent de déduire un diagramme de
classes simplifié.

Figure 11. Diagramme
de classes

La classe Contrôleur des mouvements doit gérer l'enchaînement des générations de trajectoire
et des commandes pour que le robot ne s'arrête pas entre deux trajectoires. Elle a un
comportement spécifique par rapport aux autres classes. UML exprime ce comportement par
l'utilisation des Statecharts qui permettent de bien représenter le parallélisme (Cf. Figure 12).
Chapitre 3 - Modélisation du contrôleur de robot                                         19

Figure 12. Diagramme
d'états de la classe
Contrôleur des
mouvements

Ces diagrammes permettent de spécifier le contrôleur sans laisser transparaître les choix
technologiques. Tous les diagrammes ne sont pas présents (les parties de sûreté de
fonctionnement et de tolérance aux fautes ne sont pas introduites dans cette présentation) mais
ceux ci sont les principaux pour passer à la conception. La conception s'attache à la
représentation des tâches et de leur synchronisation.

3.2. Conception basée sur un contrôle centralisé
Les spécificités du système sont décrites dans le chapitre "orientations technologiques". Le PC
cible utilise une carte PC30aT pour tout ce qui est communication avec les capteurs et les
actionneurs. On fait donc apparaître un objet supplémentaire qui est "carte PC30aT". Le
système d'exploitation est Vxworks (vu précédemment) qui apporte des objets comme les
tâches, les watchdogs, les sémaphores et les files de messages. Les diagrammes sont donc
augmentés de ces objets.

La détermination des tâches peut se faire suivant des heuristiques [DOU98] qui permettent
d'identifier les "threads" ou fils d'exécution. Ce sont en fait des parties de code pouvant
s'exécuter d'une façon séquentielle. On détermine ensuite les problèmes de concurrence.
Chapitre 3 - Modélisation du contrôleur de robot                                              20

Il apparaît clairement que la génération et la commande sont en concurrence (ce qui apparaît
dans le diagramme d'état Figure 12). En fait ce sont leurs méthodes principales qui sont
interprétées en tant que tâches.
La méthode de la classe contrôleur des mouvements n'est pas en concurrence directe avec
ces deux tâches. Mais le fait qu'elle gère leur fonctionnement implique un retour récurrent dans
cet objet. De plus le choix de l'implantation en objet implique que cette classe soit directement
liée à la construction et à la destruction des tâches qu'elle gère.
La version actuelle de Vxworks ne possédait pas les "options objet" (les Wrapper classes). Les
outils étaient que de simples appels à des fonctions. Il m'a fallut écrire les fichiers transformant
ces fonctions en objets pour que la conception colle à la réalité du système.

On peut visualiser les tâches par un diagramme (Figure 13) qui n'illustre pas les choix de
synchronisation mais permet d'exposer les objets actifs.

Figure 13. Diagrammes
des tâches

Il faut maintenant choisir les objets que l'on va utiliser pour satisfaire le comportement du
système, plus précisément la synchronisation des tâches.
Une première version de conception s'applique à séparer flot de contrôle et flot de données. Ce
sont les tâches qui gère l’exécution des méthodes appartenantes aux classes de la
spécification.

La tâche « contrôle des mouvements » gère la synchronisation des deux autres tâches. Elle
active ou suspend suivant une machine à état. Nous n’utilisons donc pas de sémaphores pour la
synchronisation mais il est possible de créer une file de messages pour récupérer le message
de fin de génération. Les différents scénarios sont exprimés par les diagrammes de séquence.

L'appel récursif de la commande à une période d'échantillonnage T peut se faire sous Vxworks
grâce au watchdog. Celui ci peut activer une tâche périodiquement (si celle ci se suspend).

Diagramme de classes

La représentation des tâches est possible au sein du diagramme de classes. "Chaque objet
actif (tâche) répond aux événements et répartit les actions sur ses objets agrégés" [DOU98].
Les objets instanciés ou utilisés par les tâches sont donc représentés par des classes
agrégées (cf. Figure 14).

Figure 14. Relation entre
une tâche et une classe
Chapitre 3 - Modélisation du contrôleur de robot                                               21

Il est même possible de mieux spécifier cette association en introduisant une flèche (cf. Figure
16). On représente ainsi une agrégation à navigabilité restreinte, C'est une association de type
"maître - esclave".
En pratique ces tâches ne pourraient être que des instances de la classe " VXWTaskLib.h"
(classe regroupant toutes les fonctions de Vxworks pour les tâches). Mais on peut alors créer
une classe pour chaque tâche du système héritant de la classe "VXWTaskLib.h". La relation en
UML est alors représentée par une flèche (cf. Figure 15. Héritage simple).

Figure 15. Héritage
simple

Le choix a été fait de séparer flot de contrôle et flot de données. Le modèle gagne ainsi en
généricité et en lisibilité. Les tâches en tant qu’objets actifs se synchronisent grâce à une file et
un watchdog.

On peut noter d’abord l’enrichissement du diagramme par l’ajout de la classe « Pc30aT » (Cf.
Figure 16). L’utilisation des différentes classes de Vxworks introduit dans le diagramme de
classes des associations (cf. Figure 16).

Figure 16. Diagramme
de classes pour la
conception
Chapitre 3 - Modélisation du contrôleur de robot                                          22

Diagrammes de séquence

Ce sont ces diagrammes qui permettent de concevoir la réaction du système. Ils expriment le
mieux les communications entre les tâches et les éléments de synchronisation. Le contrôleur
des mouvements effectue tous les tests relatifs aux points de synchronisation. Il gère grâce au
watchdog l’appel périodique de la tâche commande et il récupère et envoie les consignes aux
contrôleurs d’axes.
Plusieurs scénarios sont modélisés sur la Figure 17.

Figure 17. Diagramme
de séquence illustrant
les communications
intertâches
Chapitre 3 - Modélisation du contrôleur de robot                                          23

La première séquence illustre l'initialisation et le lancement de la première génération. Par la
suite les tâches de génération et de commande se suspendent lorsqu'elles ont fini leurs actions.
On suppose que la durée de la commande est inférieure à la fréquence d'échantillonnage. C'est
à dire que l'on ne crée pas de procédure d'exception, la commande est synchrone, on ne
récupère aucune information de fin de commande.
Mais pour la génération la durée est inconnue, il faut donc introduire une file de messages qui
permet de détecter très rapidement la fin du calcul.
L'ensemble des points d'une trajectoire est contenu dans une liste chaînée. La tâche contrôleur
des mouvements gère l'envoi périodique des consignes et la destruction de la liste. La méthode
incrémenter_ptr permet de passer d'une consigne à la suivante.

Diagramme d’activité

Les diagrammes d’états ne sont nécessaires que pour un petit nombre de classes : celles dont
les applications sont basées sur le contrôle [LEE98]. Le contrôleur des mouvements permet de
synchroniser les tâches parallèles de génération de trajectoire et de commande du bras. Le
diagramme d’état de la spécification peut être interprété comme le diagramme d’activité suivant
(cf. Figure 18).
Chapitre 3 - Modélisation du contrôleur de robot                                        24

Le signal fin génération correspond à la fin du calcul d'une trajectoire. Fin commande est
vrai lorsque tous les points d'une trajectoire ont été passés en consigne. Le test de la file
permet de voir s’il existe une trajectoire calculée qui n'a pas été passée en commande.

Figure 18. Diagramme
d'activité de la tâche
contrôleur des
mouvements
Chapitre 3 - Modélisation du contrôleur de robot                                            25

Diagramme de collaboration

Les interactions entre les objets peuvent aussi se représenter au moyen des diagrammes de
collaboration (Cf. Figure 19). Trois fils d'exécution apparaissent dans ce diagramme : ils sont
représentés par la présence de A, B et C en début de message. Deux types de flèches
apparaissent :

        : flot de contrôle
         : flot de données

Figure 19. Diagramme
de collaboration

On peut voir clairement sur ce diagramme l’enrichissement des modèles obtenus lors de la
spécification. En effet les objets nécessaires à la synchronisation apparaissent ici au-dessus
des objets introduits lors de la spécification (Génération de trajectoire, contrôleur des
mouvements et contrôleur d’axe).

Bilan de la conception

D'autres diagrammes sont bien sûr nécessaires mais ici seuls les principaux sont représentés.
Ils permettent de bien exposer les choix technologiques et de conception.
Cette conception s'articule autour de la tâche principale contrôleur des mouvements. Les autres
tâches ne sont en fait que des méthodes des classes génération de trajectoire et de contrôleur
d'axe.
Les flots de données et de contrôle sont bien séparés. Seules les tâches gèrent l'exécution et la
synchronisation des actions. Les autres objets reçoivent les données de calcul de trajectoire, les
consignes et les mesures des capteurs.

J’ai donc fait le choix d’un contrôle superviseur. Mais lors de cette conception je me suis aperçu
que l’élaboration des diagrammes ne pouvait s’appuyer sur la spécification notamment pour le
diagramme d’état de la Figure 12. Il m’a donc été nécessaire de concevoir le diagramme
Vous pouvez aussi lire
DIAPOSITIVES SUIVANTES ... Annuler