CONCEPTION ORIENTÉE OBJET D'UN CONTRÔLEUR DE ROBOT
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
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 TONDUChapitre 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 ...................................................................................... 41Chapitre 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 ................................................................................ 38Chapitre 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
manipulationChapitre 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 diagrammeVous pouvez aussi lire
