CONCEPTION ORIENTÉE OBJET D’UN CONTRÔLEUR DE ROBOThomepages.laas.fr/guiochet/telecharge/Guiochet-rapportDEA.pdf · CONTRÔLEUR DE ROBOT ... (Par exemple le logiciel GENERIS exposé

DEA Automatique Informatique Industrielle Année Universitaire 1998 – 1999

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

JÉRÉMIE GUIOCHET

EEqquuiippeess :: SSûûrreettéé ddee FFoonnccttiioonnnneemmeenntt ddeess SSyyssttèèmmeess &&

SSyyssttèèmmeess DDyynnaammiiqquueess

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


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


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

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


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


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

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

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

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

Spécification

Conception

Dépendance de l’implantation

détails- +

Indépendant Dépendant

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


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.

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.

Figure 4. Retour d'informations entre les phases

Analyse

Concept ion

Codage

Iteration n

Figure 5. Cycle de vie itératif


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.


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


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


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.

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.

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


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

calibrer() Réception et décodage des données des capteurs

Actionneur commander() Commande effective des servovalves alimentant les actionneurs

Contrôleur d'axe CalculBF() asservir()

Réception de la consigne de 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).

L'asservissement de position qu'effectue le Contrôleur d'axe est représenté en Figure 10.

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


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

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

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

Figure 11. Diagramme de classes


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.

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


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.

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 13. Diagrammes des tâches

Figure 14. Relation entre une tâche et une classe


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

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 15. Héritage simple

Figure 16. Diagramme de classes pour la conception


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


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


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


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

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

Figure 19. Diagramme de collaboration


d’activité de la Figure 18. Afin de conserver le diagramme d’état de la spécification pour la conception j’ai donc établi un deuxième modèle. Celui ci n’intègre pas de tâche de contrôle, les processus parallèles se synchronisent directement par l’envoi de messages. 3.3. Conception basée sur un contrôle distribué Le diagramme d'état de la spécification est directement interprété pour établir les diagrammes de la conception. Les deux tâches génération et commande se synchronisent donc sans passer par le contrôleur des mouvements. Comme précédemment on pourrait utiliser des files de messages, mais ici il est plus intéressant d'implanter des sémaphores. En effet de simples blocages permettent de suspendre les tâches, et les messages de fin de tâche peuvent être des sémaphores disponibles ou vides. La tâche contrôleur des mouvements sera donc celle qui initialise les objets et les deux tâches. Mais elle ne sera pas celle qui synchronise et donc ne sera pas en concurrence avec les deux autres. Diagramme d'états Seules les deux tâches en concurrence sont représentées ici. La communication se fait donc par des sémaphores notés ici sous la forme de message, par exemple SemtakeA (demande du sémaphore A). ^message correspond à l'envoie d'un message (ici la libération d'un sémaphore). /action() est l'exécution d'une méthode lors de la transition associée. [condition] bloque le système dans l'état actuel si cette condition n'est pas vraie. La Figure 20 est l'enrichissement du diagramme de spécification mais interprète les messages comme des prises et des libérations de sémaphores. SemA correspond à la fin de la génération. SemB est le début de la commande d'une nouvelle trajectoire. SemC permet de savoir s'il reste un calcul de trajectoire à effectuer.


Ce diagramme exprime bien le fait que la tâche commande est la seule à être synchronisée. En effet /Wdstart() lance le watchdog dès le début de la tâche (elle-même activée par le timeout du watchdog). Lirepoint() permet de récupérer le calcul effectué et incptr() incrémente le pointeur sur la consigne à envoyer.

La notion d'historique est ici utilisée pour permettre à la tâche de revenir dans son état avant sa suspension. Diagramme de classes Les associations entre les classes ne changent pas. Ici on introduit la classe Sémaphore en plus mais le diagramme pourrait être le même que pour la version 1. Mais en vu des tests de performances j'ai retiré la classe contrôleur des mouvements, seulement représentée ici par la tâche associée. En fait le système ne nécessite pas une classe. Il suffit juste d'une tâche, un fil d'exécution, qui instancie les bons objets puis se suspend jusqu'à la fin de l'utilisation. Il a donc fallut ensuite intégrer le fait que les points de la trajectoire calculée doivent être manipulés avant d'être envoyés en consigne à la commande d'axe. C'est donc la tâche commande (comme expliqué précédemment à la Figure 20) qui gérera cette activité.

Figure 20. Diagramme d'états


Bilan de la conception Cette conception se caractérise par sa continuité avec la spécification. Elle utilise principalement des sémaphores ce qui rend le système plus rapide. Il est important de noter que par rapport à la version 1 seuls certains diagrammes ont été modifiés. Les diagrammes d'états, de séquence et de collaboration sont ceux qui caractérisent la dynamique du système, ainsi ils sont modifiés suivant les choix de synchronisation. Une étude plus précise des performances est effectuée dans le chapitre suivant. 3.4. Comparaison La version 1 assure une maîtrise forte du comportement de l’application. Le choix d’une tâche superviseur facilite la compréhension de la modélisation. De plus, ce choix contribue à la généricité de la modélisation dans le sens où seule la tâche superviseur serait concernée par des modifications ultérieures apportées au comportement de l’application. Ainsi elle peut être modifiée facilement en conservant le même modèle autour d'elle. Par la structure des classes, les flots de contrôle et de données sont bien séparés. L'échange des données, bien défini lors de la spécification, est synchronisé par les objets de la conception. La conception ne peut être qu'un enrichissement des modèles de spécification mais ici il apparaît clairement deux étages de modélisation au sein des diagrammes mêmes.

Figure 21. Diagramme de classes


Le diagramme de classes est complété par de nouveaux objets (tout comme les diagrammes d'interaction) mais le diagramme d'états n'est par interprété directement. Un nouveau diagramme a même été ajouté : le diagramme d'activité. La version 2 tente de mieux assimiler la spécification de la dynamique du système. Il est important de noter que la maîtrise du milieu, acquise par l'élaboration de la version 1, m'a permise de travailler plus rapidement et plus précisément pour la deuxième version. Celle ci fournit un modèle plus puissant par sa simplicité de réalisation que la première. En effet le diagramme d’activité exposé précédemment demande la maîtrise permanente de variables et de branchements conditionnels. On peut voir sur la Figure 18 qu’il y a 4 branchements ce qui demande du temps au logiciel lors de son exécution. Au contraire, la deuxième version fournit deux tâches ne nécessitant pas cette cascade de conditions. Une comparaison pratique des deux conceptions est faite dans le chapitre suivant qui valide par l’implantation en C++ les modèles obtenus.

30

Chapitre 4

Implantation et résultats Les deux modèles de conception étant réalisés, le choix a été fait de les implanter pour une validation. Pour avoir le temps de programmer les deux versions seules les parties de synchronisation ont été implantées. Les modèles ont donc été réalisés avec des méthodes vides pour les classes commande d'axe et génération de trajectoire. Le système n'est donc pas validé entièrement. Je me suis juste intéressé au problème de la modélisation des choix de conception pour les tâches et donc je n'ai validé que cette partie. Les problèmes du passage de la conception à l'implantation sont peu traités bien que la conception ait été influencée par les caractéristiques du C++. Ceci pour surtout concentrer l'étude sur les choix effectués et leurs résultats. Il faut noter que pour ces simulations l'hypothèse suivante a été faite : le temps de calcul en ligne est inférieur au temps de déplacement du bras d'un point initial de trajectoire au point final. Cette contrainte temps réel exprimée par l'opérateur d'Allen [MAM98] "during" (une tâche doit se finir avant la fin d'une autre) n'est donc pas prise en compte dans la conception. Seuls les tests des temps de calcul (ici non implantés) permettront de bien régler la période d'échantillonnage pour éviter une telle faute temporelle. 4.1. Implantation de la conception « centralisée » Synchronisation des tâches L'implantation en C++ de la version 1 a d'abord nécessité la réécriture des librairies C++ Vxworks. En effet les "objets" tels que les sémaphores, les tâches... n'étaient que des simples appels de procédures. Puis l'implantation des associations a pu se faire en suivant le modèle. Toute la structure du logiciel tient en fait dans la tâche contrôleur des mouvements, plus précisément dans sa machine à états (Cf. Figure 18). Elle a été programmée directement avec des branchements conditionnels ("if" et "else") en suivant le diagramme d'activité de la Figure 18. La caractérisation des points de synchronisation et la mesure des temps d'exécution du système s'est faite avec WindView, un logiciel de WindRiver permettant d'enregistrer graphiquement l'activité des tâches. Les tâches sont représentées suivant leur état par des lignes décrites dans la Figure 22. Les principaux symboles de synchronisation sont représentés.

Chapitre 4 - Implantation et résultats 31

Le premier résultat que l'on peut obtenir est le bon échantillonnage pour la commande pendant un calcul de trajectoire. La Figure 23 montre les "ticks" d'horloge et le "réveil" de la tâche commande (tcmde) toutes les 16 ms (on peut régler cette fréquence comme on le désire).

Figure 22. Légende des graphiques suivants


La tâche Commande est donc prioritaire par rapport à la tâche génération (tgene). La synchronisation se faisant par la tâche contrôleur (tctrl), celle ci est donc la plus prioritaire : Ptache controleur > Ptache commande > Ptache génération La Figure 24 illustre cet ordre de priorité. La génération est interrompue par "INT 0" (interruption du système de plus haut niveau) qui active la tâche contrôleur.

Figure 23. Commande échantillonnée pendant le calcul d'une trajectoire


On peut voir les actions de la tâche contrôleur : elle active le watchdog (qui la relancera 16 ms plus tard), réveille la tâche commande (taskActivate) puis se suspend (taskSuspend). La tâche commande est alors prioritaire, elle s'exécute, puis se suspend. Alors la génération continue. Lorsqu’un calcul de trajectoire est fini un message est envoyé dans une file et la tâche génération se suspend. La Figure 25 illustre la fin de la commande d'un trajet et le début d'une nouvelle génération de trajectoire. A partir de l'état de repos du système (idle), la tâche contrôleur s'active et reçoit le message de fin de calcul de trajectoire. Elle active alors les tâches commande et génération avant de se suspendre. C'est le début d'une nouvelle génération !

Figure 24. Synchronisation et lancement des tâches


Performances du système On peut tout d'abord noter que le noyau Vxworks fonctionne avec plusieurs tâches système qui interagissent au milieu du fonctionnement du contrôleur. La Figure 24 et la Figure 25 permettent de caractériser le temps d'initiation, c'est le temps requit pour entrer complètement dans la tâche contrôleur : tinitiation = 92 µs Le temps total avant l'exécution de la commande (influe sur la précision de l'asservissement) est de : tTotal = 243 µs. Ce temps caractérise aussi la rapidité de la machine à état du contrôleur. La lecture de messages, l'activation des autres tâches sont des fonctionnalités de Vxworks qui sont de l'ordre de la microseconde. Ils n'ont donc pas d'influence sur le système. L'échantillonnage de la commande est prévu être de 10 ms. Il faut donc pour un sept axes que la commande ne dépasse pas 1.4 ms. En se basant sur une milliseconde on assure le fait qu'il faille laisser du temps pour la génération de la commande. Le rapport entre le temps total avant l'asservissement et le temps disponible à la commande est donc de un quart. Il faut donc savoir combien de temps la commande prend s'exécuter. Les tests avec les méthodes implantées par Luis Carroll donnent des mesures de temps qui permettent de choisir cette conception.

Figure 25. Fin de la commande et début d'une nouvelle génération


En effet nous avons noté que la commande de deux axes ne dépassait jamais les 15 µs. Ce qui laisse du temps pour piloter 7 axes. Admettons qu'il faille quatre fois plus de temps (comme pour huit axes), la commande prendrait donc 4*15µs+250µs = 310µs. Entre deux commandes d'axe (toutes les 10 ms) il faut 0.31 ms pour la commande. On peut donc implanter cette solution sans aucun risque de faute temporelle. La génération ne dépasse jamais 50 ms. Pour un échantillonnage de 10 ms cela fait 6 consignes au maximum. Or pour un trajet même très court le nombre de points reste élevé. Ceci permet de confirmer l'hypothèse faite précédemment : le calcul de la trajectoire sera toujours fini avant la fin de la commande. 4.2. Implantation de la conception « distribuée » L'implantation de cette deuxième version a permis de bien comprendre la puissance de la modélisation objet. En effet les objets déjà instanciés ont pu être utilisés très facilement. Seule la synchronisation a été modifiée, ainsi les objets du système de cette deuxième version sont les mêmes que ceux de la première. Implantation du parallélisme Cette solution est plus "compacte" que la première, au sens où seules deux tâches sont à implanter. Le diagramme d'états de la Figure 20 peut être codé directement. Il faut donc programmer deux tâches qui gèrent les sémaphores. Afin de ne pas surcharger le code peu significatif a été remplacé par des étoiles dans l'extrait de programme suivant.

**** tâche de génération ***

int tachegenerer (void){while(1)

{semTake(semB,WAIT_FOREVER);if (semTake(semC,NO_WAIT)==OK)

{*** appel de la génération ****semGive(semA);}

}

La génération se fera que lorsque les sémaphores semA et semB seront libres. Sinon la tâche se suspend.


L'utilisation de ces sémaphores réduit considérablement le code. En effet l'état d'une tâche n'est pas à spécifier : le seul fait d'attendre un sémaphore implique sa suspension. Le noyau se charge donc d'une partie de code qui est invisible pour le concepteur. L'utilisation d'options particulières de Vxworks comme le NO_WAIT dans le test de sémaphore permet de ne pas suspendre la tâche. Il s'agit d'un simple test. Le système se lance par la création et l'activation de ces deux tâches grâce à une autre tâche: la tâche contrôleur. On voit que pour la génération il n'est pas nécessaire d'introduire une machine à état (comme le switch), ce sont les fonctionnalités de Vxworks qui introduisent l'état de suspension.

int tachecommande (void){*** instanciations et déclarations) ****while(1)

{monchien.start(sysClkRateGet()/100,init,0);

switch (etat) {case ATTENTE :

if (semTake(semA,NO_WAIT)==OK){etat=COMMANDE;***appel de lirepoint()***semGive(semB);}

else ***asservissement constant***;break;

case COMMANDE :matache_commande.pcontroleur_d_axe->asservir();***incrémenter le pointeur sur la consigne***if (pointeur==NULL)

{etat=ATTENTE;}

break;

default:return(ERROR);break;

}matache_commande.suspend();}

}

************ Tache commande **********


Synchronisation des tâches La synchronisation est représentée sur les graphiques par des drapeaux qui symbolisent la prise ou la libération des sémaphores. La Figure 26 illustre la commande périodique et la fin d'un calcul de trajectoire. Le drapeau noir représente ici (on le voit en agrandissant fortement) semGiveA et semTakeB , qui signifient fin de génération et attente de la fin commande. Le sémaphore B n'étant pas disponible le système passe dans l'état de repos idle. Le système des priorités des tâches est le même que précédemment.

La Figure 27 caractérise la fin de la commande d'un trajet et le début d'un autre. Une nouvelle génération est aussi lancée.

Figure 26. Commande échantillonnée et fin de la génération


Les deux premiers drapeaux caractérisent semTakeA (fin de génération est vrai, le calcul a été effectué), et semGiveB (c'est le début de la commande d'une nouvelle trajectoire). Ainsi la tâche génération peut prendre le sémaphore B (troisième drapeau), et le sémaphore C (qui représente le fait qu'il reste des calculs a effectuer). Les deux tâches se synchronisent donc très bien et rapidement (quelques microsecondes). La périodicité est respectée et le système n'est pas surchargé pour laisser le temps au calcul de se faire. Performances Ce choix de conception apporte donc une simplicité d'implantation mais aussi une amélioration des performances temporelles. Ainsi on note un temps d'initiation de 90 µs (plus de deux fois moins que précédemment). Ce qui est voisin du temps d'une interruption système (65 µs). Le fait de ne plus passer par une tâche de contrôle réduit bien sûr ce temps mais l'utilisation des sémaphores est aussi bénéfique. La réduction de code amène ainsi le système à une meilleure réponse.

Figure 27. Fin de la commande d'un trajet


4.3. Bilan Comme nous l’avons vu au chapitre 3, la Version 2 fournit un modèle plus puissant que celui de la Version1. Il est plus naturel et exploite mieux les possibilités de Vxworks. Le chapitre 4 démontre qu’il est aussi plus rapide (bien que ceci ne soit pas nécessaire). L’implantation est plus simple et découle directement du statechart de la spécification. Les deux tâches principales peuvent être rapidement modifiées pour la commande d’un bras à plusieurs axes de plus la forte corrélation entre modèles et implantation assure une maintenance facile. Ce modèle, comme le précédent, peut facilement évoluer vers la commande de plusieurs axes, il assure ainsi la généricité. Les tests montrent que les fautes temporelles sont impossibles car la marge est très grande. Mais pour obtenir un système réellement sécuritaire il faudrait prévoir des routines en cas de fautes matérielles. Le système d’arrêt d’urgence que j’ai implanté (l’appui d’une touche détruit toutes les tâches du programme) ne suffit pas pour un arrêt critique du bras dans un milieu humain. En effet le dégonflement des muscles livre le bras à sa propre inertie. Il existe bien sûr d’autres points important de la Sûreté de Fonctionnement qu’il faudrait traiter pour valider le modèle.

40

Conclusion Ce mémoire de DEA s’inscrit dans une réflexion sur l’application des méthodes de l’Informatique Industrielle au développement de contrôleurs de robots industriels. Grâce au recours aux méthodes de spécification/conception spécifiques des systèmes temps-réel, on vise un développement plus rigoureux et plus générique des contrôleurs de robots. Cette rigueur et cette généricité dans le développement nous apparaissent, notamment, nécessaires à la définition de contrôleurs de robots de service destinés à travailler en environnement ouvert et soumis, par conséquent, à une forte contrainte de sécurité. Dans ce cadre de recherche, nous nous sommes plus particulièrement intéressés au problème du passage de la spécification à la conception. Partant d’une spécification-type de contrôleur de robot industriel, développée en UML – thèse de Luis Carroll en cours d’achèvement au LESIA – nous avons élaboré sa conception orientée objet. Afin de mieux cerner cette problématique, nous avons comparé deux conceptions différentes issues de la même spécification. La première, que l’on peut qualifier de conception par contrôle centralisé, favorise la généricité en mettant en valeur une tâche superviseur. Elle écarte, cependant, le concepteur d’une stricte interprétation du diagramme d’états. C’est, pourquoi, nous l’avons comparée à une seconde conception que l’on peut qualifier de conception par contrôle distribué, qui assure un lien étroit entre spécification et conception. Les deux conceptions ont été validées expérimentalement sur le contrôleur du prototype de robot à 2 axes actionnés par muscles artificiels, défini autour du noyau temps réel Vxworks. La deuxième version par ses caractéristiques temporelles et sa puissance de modélisation apparaît être la meilleure solution.

Ce travail devrait se poursuivre dans le cadre d’une thèse visant au développement d’un contrôleur de robot anthropomorphe à 7 axes. Du point de vue de la conception, le passage de la structure à 2 axes à la structure à 7 axes devrait nous permettre de valider la fiabilité et la généricité de notre démarche. Par ailleurs, des aspects de sûreté de fonctionnement seront intégrés à la conception en vue de valider le fonctionnement du bras anthropomorphe dont le comportement devra prendre en compte la présence humaine dans son environnement.

41

Références bibliographiques

[ATT97] A. ATTOUI, «Les Systèmes Multi-Agents et le Temps Réel», Editions Eyrolles, Paris, 1997.

[BOO94] G.BOOCH, «Object-Oriented Analysis and Design with Applications » Benjammin/Cumming, 1994.

[CAR98] L. CARROLL, B. TONDU, C. BARON, J-C. GEFFROY, «Comparison of two significant Development Methods applied to the Design of Real-Time Robot Controllers», 4th International Conference on Probabilistic Safety Assessment and Management (PSAM), vol. 3, pp.2067-2072, Springer, New York, USA, September 1998.

[CAR99a] L. CARROLL, B. TONDU, C. BARON, J-C. GEFFROY, «UML Framework for the Design of Real-time Robot Controllers», Euro-Par, Toulouse, Septembre 1999, à paraître.

[CAR99b] L. CARROLL, B. TONDU, C. BARON, J-C. GEFFROY, «Analyse comparative de méthodes de spécification d'un controleur de robot industriel», soumis au journal Européen des systèmes Automatisés.

[CAR99c] L. CARROLL «Développement d’un Contrôleur Temps Réel Sûr de Fonctionnement pour un Environnement Interactif entre le Robot et l’Opérateur», Thèse prévue pour septembre 1999.

[DOU98] B.P.DOUGLASS, «Real Time UML , Developing Efficient Object For Embedded Systems», Addison-Wesley Longman, 1998.

[GEN97] E.R.MORALES, «GENERIS : the EC-JRC Generalised Software Control System for Industrial Robots», EC-JOINT Research Centre , 1998.

[JAC93] I.JACOBSON, «Le Génie Logiciel Orienté Objet», Addison-Wesley, 1998.

[JAC92] I.JACOBSON, «Object-oriented Software Engineering, A Use Case Driven Approach», Editions Addison-Wesley , 1992.

[LAI97] M.Lai «UML , la notation unifiée de modélisation objet», Editions Masson, 1997.

[LEE98] R.C.lee, W.M.Tepfenhart «UML and C++. A practical guide to object oriented development», Simon & Schuster Macmillan, 1998.

[MAM98] Z.MAMMARI, «Expression et dérivation des contraintes temporelles dans les applications temps réel», APII-JESA, vol. 32, n° 5-6, pp. 609-644, 1998.

[MUL98] P.A.MULLER, «Modélisation objet avec UML», Editions Eyrolles France, 1997.

[OMT91] J.RUMBAUGH, «Object-Oriented Modeling and Design», Prentice Hall, 1991.

[OOS92] I.JACOBSON, «Object-Oriented Software Engineering», Addison-Wesley, 1992.

[TON97] B.TONDU, Pierre Lopez «The McKibben and its use in actuating robot-arms showing similarities with human arm behavior », Industrial Robot, vol. 24, n° 6, pp.432-439, 1997.

[TOR95] «User's Guide : Tornado1.0 (UNIX version) », Wind River Systems ,1995.

[VXW97] «Vxworks Programmer's Guide, 5.3.1 », Wind River Systems, 1997.

Documents

CONCEPTION ORIENTÉE OBJET D’UN CONTRÔLEUR DE ROBOThomepages.laas.fr/guiochet/telecharge/Guiochet-rapportDEA.pdf · CONTRÔLEUR DE ROBOT ... (Par exemple le logiciel GENERIS exposé