# Développement logiciel pour le contrôle commande multiaxe réactif

Pierre Laguillaumie

<figure><img src="image_1.png" /></figure>

## To cite this version:

Pierre Laguillaumie. Développement logiciel pour le contrôle commande multiaxe réactif: Du contrôle bas niveau au jumeau numérique connecté. Mécanique [physics.med-ph]. Université de Poitiers - Faculté des Sciences Fondamentales et Appliquées, 2023. Français. NNT: tel-04409449

HAL Id: tel-04409449

https://theses.hal.science/tel-04409449

Submitted on 22 Jan 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
UNIVERSITE DE POITIERS
ÉCOLE DOCTORALE MIMME

THÈSE

pour obtenir le grade de

Docteur de l'Université de Poitiers

Faculté des Sciences Fondamentales et Appliquées

Diplôme National - Arrêté du 25 mai 2016

Présentée par

Pierre LAGUILLAUMIE

Développement logiciel pour le
contrôle commande multaxe réactif

Du contrôle bas niveau au jumeau numérique connecté

Thèse dirigée par Jean-Pierre GAZEAU et Vincent PADOIS,

soutenue le le 7 septembre 2023

Jury :

Président : Emmanuel GROLLEAU - ISAE-ENSMA

Rapporteurs : Stéphane CARO - CNRS (LS2N)
Charles LESIRE-CABANIOLS - ONERA

Directeurs : Jean-Pierre GAZEAU - CNRS (Pprime)
Vincent PADOIS - Inria

Examinatrice : Aurélie CLODIC - CNRS (LAAS)
<figure><img src="image_3.png" /></figure>
# Table des matières

<table><tr><td>1 Approches et outils du contrôle robotique</td><td>5</td></tr><tr><td>1.1 De la robotique industrielle à la robotique collaborative</td><td>6</td></tr><tr><td>1.1.1 Robustesse de l'application robotique</td><td>8</td></tr><tr><td>1.1.2 Sécurisation de l'interaction</td><td>9</td></tr><tr><td>1.2 Architectures de contrôle en robotique</td><td>10</td></tr><tr><td>1.2.1 Classification des architectures de contrôle</td><td>11</td></tr><tr><td>1.2.2 Vers une architecture idéale</td><td>13</td></tr><tr><td>1.2.3 Architectures de contrôle industrielles</td><td>13</td></tr><tr><td>1.3 Intergiciels pour le contrôle en robotique</td><td>19</td></tr><tr><td>1.3.1 Classification des intergiciels</td><td>20</td></tr><tr><td>1.3.2 A quels enjeux répondent les intergiciels de robotique?</td><td>26</td></tr><tr><td>1.3.3 Synthèse des intergiciels en robotique</td><td>26</td></tr><tr><td>1.4 Présentation de trois middlewares emblématiques</td><td>37</td></tr><tr><td>1.4.1 Orocos</td><td>37</td></tr><tr><td>1.4.2 RT-Middleware</td><td>40</td></tr><tr><td>1.4.3 ROS</td><td>41</td></tr><tr><td>1.4.4 ROS 2.0</td><td>43</td></tr><tr><td>1.4.5 Limites de la communication basée sur ROS pour le contrôle multirobot</td><td>44</td></tr><tr><td>1.5 Environnement logiciel intégré</td><td>46</td></tr><tr><td>2 Contrôle-commande unifié</td><td>49</td></tr><tr><td>2.1 État des lieux des systèmes de contrôle-commande de machines</td><td>49</td></tr><tr><td>2.1.1 Un écosystème vaste et en pleine transition</td><td>50</td></tr><tr><td>2.1.2 Des architectures matérielles hétérogènes distribuées</td><td>51</td></tr><tr><td>2.1.3 Systèmes industriels temps-réel selon la norme IEC61131</td><td>56</td></tr><tr><td>2.1.4 Standardisation logicielle de la génération de mouvement</td><td>64</td></tr><tr><td>2.2 rtrmac : un outil de développement de systèmes de contrôle-commande temps-réel</td><td>68</td></tr><tr><td>2.2.1 Structure de la bibliothèque</td><td>70</td></tr><tr><td>2.2.2 Axe de mouvement générique</td><td>75</td></tr><tr><td>2.3 Une démarche d'unification du développement logiciel</td><td>85</td></tr><tr><td>2.3.1 Usage optimal des composants matériels</td><td>85</td></tr><tr><td>2.3.2 Mise en œuvre d'algorithmes complexes</td><td>89</td></tr><tr><td>2.4 Conclusion</td><td>93</td></tr><tr><td>3 Développement d'une architecture personnalisable de contrôle de systèmes mécaniques</td><td>95</td></tr><tr><td>3.1 Contrôle commande multiaxe industriel : des approches antagonistes</td><td>98</td></tr><tr><td>3.1.1 Démarches de standardisation du pilotage multiaxe</td><td>100</td></tr><tr><td>3.1.2 Conclusion</td><td>107</td></tr><tr><td>3.2 Proposition d'une architecture logicielle pour le contrôle de mécanismes</td><td>109</td></tr><tr><td>3.2.1 Implémentation d'une solution robotique générique</td><td>109</td></tr></table>
<table><tbody><tr><td>3.2.2</td><td>Décomposition hiérarchique du contrôle-commande</td><td>111</td></tr><tr><td>3.2.3</td><td>Intégration dans la bibliothèque rtrmac</td><td>112</td></tr><tr><td>3.2.4</td><td>Définition des espaces de travail</td><td>112</td></tr><tr><td>3.2.5</td><td>Intégration de bibliothèques tierces</td><td>114</td></tr><tr><td>3.3</td><td>Pilotage des mécanismes</td><td>115</td></tr><tr><td>3.3.1</td><td>Description du couplage moteurs - articulations</td><td>117</td></tr><tr><td>3.3.2</td><td>Applications</td><td>118</td></tr><tr><td>3.4</td><td>Pilotage des robots</td><td>123</td></tr><tr><td>3.5</td><td>Illustration : contrôle-commande d'un robot sériel 2R</td><td>124</td></tr><tr><td>3.5.1</td><td>Description de la partie mécanisme</td><td>127</td></tr><tr><td>3.5.2</td><td>Description de la partie robot</td><td>127</td></tr><tr><td>3.5.3</td><td>Modèle cinématique</td><td>128</td></tr><tr><td>3.5.4</td><td>Pilotage dans l'espace opérationnel</td><td>128</td></tr><tr><td>3.5.5</td><td>Suivi d'une consigne interpolée dans l'espace opérationnel</td><td>131</td></tr><tr><td>3.5.6</td><td>Conclusion</td><td>138</td></tr><tr><td>4</td><td>Du jumeau numérique aux cartes embarquées</td><td>139</td></tr><tr><td>4.1</td><td>Conception de jumeaux numériques fidèles</td><td>139</td></tr><tr><td>4.1.1</td><td>Jumeau numérique : concept et définitions</td><td>139</td></tr><tr><td>4.1.2</td><td>Particularisation du jumeau numérique pour les machines de production</td><td>145</td></tr><tr><td>4.2</td><td>Démonstrateur numérique pour l'éducation</td><td>146</td></tr><tr><td>4.3</td><td>Création du modèle robotique d'un robot sous actionné</td><td>150</td></tr><tr><td>4.3.1</td><td>Présentation du préhenseur Seahand</td><td>150</td></tr><tr><td>4.3.2</td><td>Description du système</td><td>152</td></tr><tr><td>4.4</td><td>Développement du contrôle commande et implémentation</td><td>156</td></tr><tr><td>4.4.1</td><td>Architectures de contrôle-commande</td><td>156</td></tr><tr><td>4.4.2</td><td>Développement du logiciel de pilotage</td><td>159</td></tr><tr><td>4.4.3</td><td>Implémentation du contrôle-commande sur le prototype</td><td>161</td></tr><tr><td colspan="2">Annexes</td><td>167</td></tr><tr><td colspan="2">A Gestionnaire de mécanisme : phases de préparation</td><td>169</td></tr><tr><td colspan="2">B Main Seahand : modélisation</td><td>173</td></tr><tr><td>B.1</td><td>Mécanisme</td><td>173</td></tr><tr><td>B.2</td><td>Robot</td><td>176</td></tr><tr><td colspan="2">Bibliographie</td><td>181</td></tr></tbody></table>
Introduction

Ce travail s'inscrit dans une démarche globale de conception de systèmes mécatroniques. Cette activité est centrale dans les travaux de l'équipe RoBioSS de l'Institut Pprime depuis une vingtaine d'années.

Entre 2000 et 2010, l'équipe RoBioSS a développé des démonstrateurs de recherche pour la robotique humanoïde, pour la manipulation ou qui présentaient des architectures mécaniques innovantes. La figure 1 présente des exemples de systèmes réalisés à cette époque. Sur le plan de l'architecture de commande, chaque système était équipé d'une solution technologique différente pour le calculateur comme pour les étages de puissance. Pour les exemples de la figure,

— le petit système locomoteur Tidom était équipé d'un automate programmable industriel (PLC) et de cartes électroniques embarquées Maxxon,

— la main LMS avait un contrôleur de mouvement standalone (sans automate complémentaire) permettant de piloter seize axes moteurs,

— la commande du robot d'impression sur grandes dimensions était réalisée avec du matériel National Instruments.

Cette situation rendait difficile le maintien en condition opérationnelle et l'amélioration des systèmes ainsi que le partage des algorithmes qui étaient développés dans plusieurs langages et exécutés sur des cibles différentes.

<figure><img src="image_4.png" /><figcaption>FIGURE 1 – Systèmes robotiques conçus avec des parties commandes hétérogènes.</figcaption></figure>

Dans la décennie suivante, l'équipe a pris la décision de concevoir les parties commandes des nouveaux dispositifs avec des composants industriels standards et a entamé la création d'un environnement de développement logiciel à partir duquel tous les logiciels pourraient être réalisés. Cette évolution s'est accompagnée d'une diversification des centres d'intérêts scientifiques abordés par l'équipe. La figure 2 présente les exemples les plus caractéristiques de cette deuxième génération de systèmes : ORHRO, robot humanoïde de grande taille, le Delthaptic, une interface à retour haptique à grand espace de travail, un banc de caractérisation des arcs de compétition (un projet CREPS et FFTA), la main RoBioSS à seize degrés de liberté, le robot COMAU Racer3 du projet Harry2, lauréat de l'appel à projets COVR et Shiva, un dispositif d'apprentissage du geste humain.

Tous ces dispositifs sont basés sur la bibliothèque de contrôle multiaxe de l'équipe, mais chaque dispositif a un logiciel de commande différent.

Le travail présenté dans ce mémoire porte sur l'extension de ce travail d'unification du développement logiciel à l'aspect contrôle de robot. Le contexte de cette évolution est une accélération
<figure><img src="image_5.png" /><figcaption>FIGURE 2 – Systèmes conçus avec des composants de contrôle-commande standards.</figcaption></figure>

du nombre et de la diversité des systèmes robotiques et des bancs de test à réaliser, avec des contraintes de temps de développement exigeantes. Le développement d'un nouveau système doit être compatible avec la durée d'une thèse de doctorat. La figure 3 présente les dispositifs fonctionnels ou en cours de développement dont les logiciels ont été développés dans le cadre de mes travaux de thèse.

Ainsi la question scientifique traitée ici porte sur la conception d'une architecture logicielle permettant de contrôler des systèmes robotiques ou multiaxes en interaction avec un environnement dynamique. Cette propriété est partagée par tous les dispositifs réalisés dans l'équipe, qu'ils soient des bancs d'essais, des ergomètres, des mains robotiques pour la manipulation fine ou la préhension avec évaluation des efforts d'interaction ou des systèmes téléopérés ou évoluant en environnement variable ou incertain.

Les contraintes de conception que nous avons retenues sont les suivantes :

- Le système de contrôle-commande doit être réactif, surveiller en permanence l'environnement du robot et réagir aux changements détectés dans un délai qui permet de réaliser ses tâches ou de les interrompre de façon sûre. Notre domaine d'application se limite à celui de systèmes déterministes présentant un fonctionnement temps réel à l'échelle de temps de la millisecorde.

- Une deuxième contrainte porte sur le choix de minimiser les développements électriques spécifiques et de construire les armoires de commande à partir de composants d'automatisme général.

- Une troisième exigence porte sur la possibilité de transférer les résultats obtenus vers des applications industrielles. Cette exigence se traduit par l'adoption des standards industriels actuels de l'Industrie 4.0 ; elle a également des conséquences sur la décomposition fonctionnelle du logiciel pour que le développement puisse être partagé avec des programmeurs de différents niveaux de compétence.

Cet objectif et ces contraintes nous ont conduit à proposer une démarche de conception logicielle différente des principales méthodes existant dans la littérature et des outils offerts par
les solutions industrielles. Cette approche structurée part du constat que, pour construire un système réactif et déterministe, il est nécessaire de bien connaître le fonctionnement et les performances atteignables par les calculateurs et les cartes de puissance. Pour exploiter au mieux ces composants, nous avons choisi d'intégrer une partie importante des fonctions de pilotage des robots dans les automates programmables ou les PC industriels qui sont toujours présents dans la chaîne de commande des machines de production.

Le premier chapitre de ce manuscrit présente un état de l'art des intergiciels de robotique et présente le cahier des charges retenu pour la réalisation de notre environnement logiciel de contrôle multiaxe. Le deuxième chapitre introduit la bibliothèque *rtrmac* et une méthode de développement d'objets logiciels pour les systèmes de contrôle-commande industriels qui pilotent des axes de mouvement. La partie suivante décrit la démarche mise en place pour étendre cette bibliothèque à la coordination multiaxe orientée robotique. Enfin, le quatrième chapitre présente des exemples du développement logiciel de dispositifs complexes qui peuvent présenter plusieurs calculateurs et sont associés à des jumeaux numériques.

<figure><img src="image_6.png" /><figcaption>FIGURE 3 – Systèmes développés avec une architecture logicielle unifiée.</figcaption></figure>
# Liste des principales publications scientifiques

## Revues internationales avec comité de rédaction

- *Lower Limb Sensor-to-Segment Calibration for Joint Kinematics Analysis With Inertial Measurement Units: Is There an Ideal Method?* L. Pacher, C. Chatellier, P. Laguillaumie, R. Vauzelle, L. Fradet. IEEE Sensors Journal, vol. 22, no. 22, pp. 22148-22160, 15 Nov. 15, 2022, doi: 10.1109/JSEN.2022.3209883.

- *ORHRO: OPEN Robotics Humanoid RObot - from a mechanical retrofit to a new real time industrial controller based walking robot*. A. Eon, J. Gastebois, P. Laguillaumie, P. Vulliez, P. Seguin, J. P. Gazeau. Computer Methods in Biomechanics and Biomedical Engineering. (2019) 22 :sup1, S502-S504 DOI: 10.1080/10255842.2020.1714997

- *RTRobMultiAxisControl: A Framework for Real-Time Multiaxis and Multirobot Control*. H. Fischer, M. Vulliez, P. Laguillaumie, P. Vulliez, J. P. Gazeau. IEEE Transactions on Automation Science and Engineering. (2019) doi:10.1109/TASE.2018.2889813

- *Focus on the mechatronics design of a new dexterous robotic hand for inside hand manipulation*. P. Vulliez, J. Gazeau, P. Laguillaumie, H. Mnyusiwalla, P. Seguin. Robotica, Vol. 36(8), 1206-1224. (2018) doi:10.1017/S0263574718000346

## Conférences internationales avec comité de sélection

- *Learning an arm movement on a mechatronic device: influence of visual feedbacks occurrence*. R. Crolan, A. Eon, Pierre Laguillaumie, A. Decatoire, C. Scotto, Y. Blandin. ACAPS (2021)

- *Proprioceptive contribution to learning an elbow flexion-extension task*. R. Tisserand, M. Vaurs, A. Decatoire, A. Eon, P. Laguillaumie, C. Scotto, Y. Blandin. ACAPS (2021)

- *Comparison of calibration methods for accelerometers used in human motion analysis*. A. Nez, L. Fradet, P. Laguillaumie, T. Monnet, P. Lacouture. Proc. of the 22nd Congress of the European Society of Biomechanics (2016)

## Liste des brevets et dépôts logiciels

### Brevets déposés

- *Brevet n°2010813 du 22/10/2020 pour : « Dispositif de rééducation, d'entraînement ou de préparation physique »,* CNRS, Université de Poitiers. Inventeurs : A. Decatoire, A. Eon, P. Laguillaumie

- *Brevet n°1914606 du 17/12/2019 pour "Préhenseur marin sensible en efforts",* CNRS. Inventeurs JP. Gazeau, P. Vulliez, P. Laguillaumie, C. Mizera

- *Brevet n°1909724 du 04/09/2019 pour « Main robotique »,* CNRS. Inventeurs : JP. Gazeau, P. Vulliez, P. Laguillaumie, C. Mizera

Dépôt du logiciel : « RTRobMultiAxisControl » à l'Agence de Protection des Programmes, 19 juillet 2018. IDDN. FR.001.300012.000.S.P.2018.000.31235.
# Approches et outils du contrôle robotique

La robotique industrielle est apparue au début des années 1960 avec la mise en œuvre du premier robot industriel à 6 axes chez General Motors [Nof 1999]. Le robot « Unimate » a été installé en 1961 dans l’usine de Trenton, dans le New Jersey. L’application consistait pour le robot à sortir des pièces fraîchement embouties de la presse à chaud et à les plonger dans un bain de refroidissement. Sur ce modèle, la robotique industrielle s’est ensuite largement développée jusqu’au début des années 2000, dans tous les domaines de l’industrie. Le robot industriel a ainsi remplacé massivement l’être humain pour la plupart des travaux pénibles et répétitifs. Du point de vue de la sécurité, ces robots industriels spécialisés pour une tâche donnée opèrent dans une cellule fermée hors de portée de l’humain en environnement connu, les seuls risques existants étant les défaillances techniques ou les erreurs humaines [Järvinen 1995], [Nagamachi 1986].

Au début des années 2000, cette association « Homme-robot » a été complétée avec l’ap-
partition d’une nouvelle robotique non industrielle : la robotique de service et, en général, la
robotique d’assistance humaine [Haidegger 2013]. La différenciation entre les robots industriels
et les robots de service est basée sur leur domaine d’application. Grâce aux progrès de la techno-
logie des capteurs et contrairement aux robots industriels, les robots de service peuvent opérer
dans l’environnement de travail des humains et peuvent interagir avec eux. La norme ISO 13482
définit ainsi la robotique de service comme suit : « Robot qui effectue des tâches utiles pour les
humains ou les équipements à l’exclusion d’une application d’automatisation industrielle ». Cette
définition particulièrement large réunit des applications aussi diverses que l’assistance à domicile
avec le robot aspirateur Roomba ou la tondeuse à gazon, le domaine militaire avec la plateforme
de télémanipulation mobile PackBot, la santé avec le robot de chirurgie laparoscopique Da Vinci
et le robot semi-humanoïde Pepper de SoftBank Robotics.

Parallèlement au développement de la robotique de service, une autre forme de robotique est en cours de développement. Il s’agit de la robotique collaborative, qui a pour objectif de permettre au robot d’interagir avec les travailleurs en production ou simplement de partager le même espace de travail. Les robots collaboratifs se distinguent de la robotique de service par leur domaine d’utilisation. La proximité des humains et des robots implique une probabilité plus élevée d’apparition de situations pouvant entraîner des blessures humaines [Caputo 2013] et l’intégration de ces nouvelles technologies sur les lignes de production est toujours un challenge scientifique et technique actuel.

Les travaux relatifs à ce mémoire s’inscrivent dans cette dynamique de coopération et de contrôle des composants de l’environnement de production. Ils portent sur les robots et d’une manière générale les machines, les systèmes polyarticulés actionnés avec un nombre d’axes élevé.

La première section de ce chapitre présente les évolutions récentes de la robotique industrielle pour prendre en compte des possibilités d’interaction avec des opérateurs humains. La partie
suivante distingue les différentes architectures de contrôle robotique et les composants matériels associés. Les principaux environnements logiciels conçus pour permettre une conception générique des logiciels de pilotage de robots sont ensuite passés en revue. Finalement, je présente le cahier retenu pour la réalisation d'un nouvel environnement logiciel intégré pour le pilotage de machines multiaxes.

## 1.1 De la robotique industrielle à la robotique collaborative

L'objectif de la robotique collaborative est d'associer les capacités de l'homme et du robot au sein d'un espace de travail partagé ou collaboratif. Cette union permet de combiner les qualités de chacun pour assister les opérateurs au poste de travail. Les atouts du robot sont les suivants : il peut produire des efforts importants et accompagner la manipulation de charges lourdes; sa précision est de l'ordre de 0,05 mm et il est capable de travailler sans s'arrêter. Quant à l'humain, sa dextérité, sa flexibilité et sa capacité à prendre des décisions lui permettent de s'adapter à une grande variété de tâches et d'événements imprévus.

[Briquet-Kerestedjian 2019] distingue trois types d'interaction Humain - robot, en fonction de la distance entre eux et du type d'informations échangées :

- *L'interaction Homme-robot à distance*, téléopération ou télémanipulation, désigne les applications dans lesquelles un humain opère le robot à distance (dans le cas de la téléopération nucléaire ou chirurgicale) ou avec un décalage temporel dû à la durée d'échange des informations entre les deux agents (par exemple, dans le cas de robots d'exploration).

- *L'interaction cognitive Homme-robot* traite des facteurs sociaux et cognitifs qui définissent les échanges entre les robots et les humains. Ces échanges sont réalisés de façon verbale (commandes vocales, reconnaissance vocale, traitement du langage naturel) ou non verbale (reconnaissance de gestes, suivi du regard de la tête et des yeux, activité des bio-signaux).

- *L'interaction physique Homme-robot* est caractérisée par la proximité spatiale entre le robot et l'opérateur qui partagent un espace de travail commun, appelé espace de collaboration. Dans ce cas, l'opérateur a la possibilité d'entrer en contact physique avec le robot en fonctionnement, pour réaliser des tâches ensemble ou que le robot fournisse une assistance physique complémentaire.

Ainsi, et à titre d'exemple, la robotique collaborative offre un compromis entre l'assemblage manuel, et l'assemblage entièrement robotisé. Ces avantages et inconvénients sont mis en lumière dans [Fryman 2012].

Le développement de cette nouvelle technologie est régi par les normes internationales de sécurité ISO 10218-1 et ISO 10218-2 qui spécifient les exigences de sécurité relatives à la conception des robots industriels et des systèmes robotiques, respectivement. Elles présentent quatre types d'opérations collaboratives (figure 1.1), à savoir : l'arrêt nominal de sécurité (mode 1), le guidage manuel (mode 2), la surveillance de la vitesse et de la séparation humain-robot (mode 3), la limitation de la puissance et de la force (mode 4) [Villani 2018].

Les trois premiers modes de collaboration ne nécessitent pas nécessairement l'utilisation d'un robot collaboratif. Dans ce cas, la sécurité de l'homme repose sur des dispositifs de sécurité qui garantissent que le robot est arrêté à proximité de l'homme (modes 1 et 3) ou que le mouvement du robot est lié à une entrée de commande directe de l'homme (mode 2). Ces modes utilisent des composants de sécurité et exigent de mettre en œuvre une méthodologie de développement
du logiciel de sécurité qui doivent garantir qu'il n'y a pas contact direct inattendu entre le robot et l'homme.

<figure><img src="image_7.png" /><figcaption>FIGURE 1.1 – Les quatre modes de collaboration humain-robot</figcaption></figure>

Le terme *cobot* est associé au mode de collaboration limité en puissance et en force (mode 4). Avec ce mode, le contact entre le robot et l'opérateur est possible, que ce soit intentionnellement ou non. Ce type de collaboration nécessite que le robot soit capable de percevoir les forces d'interaction avec l'environnement. Le contact doit être parfaitement compris et contrôlé afin de minimiser les risques.

La figure 1.2 présente des robots collaboratifs de référence, dotés de capacités de détection des forces, de 6 ou 7 degrés de liberté et d'une charge utile pouvant atteindre 25 kg. La plupart des robots collaboratifs sont dotés de fonctions intégrées qui garantissent les exigences de sécurité ci-dessus [El Zaatari 2019].

<figure><img src="image_8.png" /><figcaption>FIGURE 1.2 – Principaux cobots commercialisés : Franka Production 3 ©Franka Emika, LBR iiwa ©Kuka, CRX-10 ©Fanuc, UR16 ©Universal Robot, APAS ©Bosch, AURA ©Comau.</figcaption></figure>

A titre d'exemple, les robots LBR iiwa et Franka Emika sont équipés de capteurs de couple en sortie de réducteur sur les sept axes. L'évaluation des couples articulaires des robots d'Universal Robot est basée sur la détection du courant de l'actionneur et l'ajout d'un capteur de force à l'effecteur final permet au robot d'interagir en toute sécurité avec l'homme. Certains robots industriels sont équipés de capteurs complémentaires pour étendre leurs domaines d'usage : le robot COMAU AURA est équipé de capteurs tactiles pour détecter les contacts [Hoshi 2006], le robot BOSCH APAS possède une peau capacitive qui détecte la proximité d'un humain et s'arrête avant le contact.

Deux enjeux essentiels se dessinent aujourd'hui dans la mise en œuvre d'applications robotiques en environnement ouvert exploitant ces modes de collaborations avec des robots industriels
et/ou collaboratifs : la sécurisation de l'interaction entre le robot et son environnement et la robustesse de l'application.

## 1.1.1 Robustesse de l'application robotique

L'émergence de la robotique collaborative ne signifie pas la fin de la robotique industrielle. Les deux types de robotique vont coexister et travailleront ensemble afin de résoudre les problèmes de flexibilité et de personnalisation du flux de production.

Un besoin de flexibilité accrue pour de nouvelles applications industrielles impose de développer des applications robotiques avec un contrôle multirobot en temps réel dans un environnement ouvert et dynamique. Potentiellement ces applications peuvent impliquer des robots industriels, des robots collaboratifs et des humains dans une zone de travail partagée pour lesquelles un haut niveau de coordination et d'interopérabilité peut être requis.

Un tel défi ne peut être relevé que si tous les composants mécatroniques du processus de production sont connectés et capables de communiquer de manière sûre. La chaîne des composants logiciels doit également être à même d'implémenter des mécanismes de communication et de coordination pour garantir le déterminisme du comportement de l'application robotique, sa sûreté de fonctionnement tout en sécurisant les interactions entre les robots et les humains dans un environnement dynamique.

Dans ce contexte, on peut définir la robustesse d'un système de contrôle-commande par l'association de plusieurs propriétés :

- il doit participer à garantir la stabilité du système qu'il contrôle,

- il doit être tolérant vis à vis des variations et des perturbations de l'environnement,

- il doit être réactif aux erreurs : il doit être capable de détecter et de gérer les erreurs qui surviennent, qu'elles soient dues à des défaillances de la partie opérative ou à des usages non prévus du logiciel. Il devrait être doté de mécanismes de détection d'erreurs, de techniques de diagnostic et de stratégies de récupération pour minimiser les conséquences des erreurs qui se produisent en production.

Dans le contexte du contrôle-commande, on peut définir la stabilité d'un système comme sa capacité à assurer ses fonctions sans discontinuité et sans danger sur toute sa durée de vie, quelques soient les sollicitations extérieures rencontrées.

Il s'agit d'être en mesure de pouvoir supprimer les défaillances à même de mettre l'application robotique en défaut. La suppression des défaillances implique d'être en mesure de sécuriser le fonctionnement de l'application robotique.

Les robots sont susceptibles de connaître des défaillances dues à des problèmes de matériel, de logiciel ou de communication. Ainsi dans la littérature sur les réseaux complexes et le contrôle multirobot, de nombreuses approches ont été proposées pour aborder le maintien de la communication avec des groupes de robots mobiles effectuant des tâches données. Les défaillances successives, en particulier pour les robots jouant un rôle central dans la topologie du réseau, peuvent conduire à un service inopérant ou réduit, ce qui a conduit au développement de méthodes originales pour assurer la continuité de service [Jakel 2011], [Ji 2007]. Des approches de contrôle ou de conception résilientes sont également développées pour permettre la récupération des états de défaillance. Dans ce contexte, on peut citer des travaux concernant les robots vo-lants [Briod 2014], souples [Tolley 2014], auto-configurables [Yim 2007] et mobiles [Zhang 2017]. Dans [Portugal 2021], afin de contribuer à la résilience des robots, les auteurs mettent l'accent
sur la nécessité de proposer une architecture modulaire, dans laquelle tous les composants ont des interfaces standard pour interagir entre eux et rendre le système globalement résilient. La résilience se distingue de la robustesse par la définition proposée dans [Zhang 2010], la résilience y est définie par « la capacité du système à poursuivre son fonctionnement au niveau souhaité lorsqu'il subit un dommage partiel ».

Sur la base de ces définitions, nous cherchons, à travers nos développements, à contribuer à rendre les applications robotiques robustes par rapport aux contraintes fortes liées à la dynamique de l'environnement. En particulier, nous travaillons à garantir la stabilité de leurs performances pour des dispositifs pouvant impliquer un nombre élevé de systèmes polyarticulés actifs (axes pilotés, machines, robots).

1.1.2 Sécurisation de l'interaction

On peut classifier les stratégies de sécurisation de l'interaction robot-environnement en deux catégories comme illustré par la figure 1.3. Ces stratégies sont envisageables pour éviter d'attenter à l'intégrité physique des personnes, ou a minima, de réduire les risques de blessures ou leur gravité. On distingue ainsi [Ikuta 2003] :

— les stratégies de pré-collision qui visent en temps réel soit à anticiper la collision, soit à réduire la force de l'impact,

— les stratégies de post-collision qui visent à réduire les conséquences de l'impact.

<figure><img src="image_9.png" /><figcaption>FIGURE 1.3 – Classification des stratégies de prévention des risques dans la collaboration homme-robot, selon [Ikuta 2003].</figcaption></figure>

On observe ainsi que la stratégie de contrôle complète le travail sur le design de la partie
opérative, dans la mise en œuvre d'une stratégie de pré-collision. Dans ce cas, l'objectif est de minimiser la quantité de mouvement et la raideur des éléments qui vont se percuter. La stratégie de contrôle contribue dans une moindre mesure dans la mise en œuvre d'une stratégie de post-collision : le temps de réaction du système de contrôle ne permettra pas au robot de modifier son comportement durant les instants suivant l'impact, mais peut diminuer les effets de l'écrasement des membres du sujet humain.

La stratégie de conception est donc prépondérante dans la mise en œuvre d'une stratégie de post-collision. Il s'agit dans ce contexte de proposer des approches de conception [De Santis 2008] permettant de diminuer les conséquences de l'impact telles que :

- l'allègement de la structure du robot et un design avec une enveloppe externe du robot adaptée évitant les arêtes vives [Park 2011], l'évaluation de l'ergonomie du cobot et son application au design de ce dernier [Maurice 2017];

- le développement de peaux passives [Ulmen 2010], [Pang 2021], [Cheng 2019];

- le développement d'actionneurs à raideur variable [Tonietti 2005] et plus généralement à impédance variable [Vanderborght 2013].

La stratégie de contrôle est déterminante pour prévenir toute situation de risque associée au mouvement du robot dans son environnement. De nombreuses stratégies ont ainsi été implémentées pour sécuriser l'interaction robot-environnement en amont. La perception de l'environnement est essentielle dans ce contexte. Classiquement le robot mobile est équipé de capteurs de proximité (infrarouges, lasers, capacitifs, à ultrasons) qui sont exploités pour produire une planification réactive du mouvement en fonction de l'évolution dynamique de l'environnement [Laconte 2019]. La perception partielle de l'environnement propre à cette technologie limite souvent leur utilisation à proximité de l'humain avec l'utilisation de grilles d'occupation 2D de l'environnement [Hoffmann 2016]. D'autres travaux récents relatifs à la collaboration hommerobot proposent d'équiper les opérateurs de marqueurs passifs sur leur vêtement de travail en exploitant des caméras dédiées à la capture de mouvement pour capter finement l'ensemble des mouvements de l'opérateur [Laconte 2021]. De nombreux travaux récents s'appuient sur l'utilisation de capteurs permettant une perception 3D de l'environnement (LiDAR, caméras Time of Flight, caméras RGB-D) [Otani 2018], [Fuseiller 2019].

Pour réaliser ces stratégies de contrôle de sécurisation de l'interaction du robot, il est essentiel de pouvoir les implémenter et les déployer dans un environnement logiciel et une architecture de contrôle intégrés. Il faut à la fois assurer une continuité entre les différents niveaux de contrôle d'une cellule robotisée et sécuriser le processus de perception-action.

## 1.2 Architectures de contrôle en robotique

L'architecture de contrôle d'un système robotique est la clé de voûte de la qualité du comportement de l'application robotique et de la qualité de réalisation de la tâche visée. Depuis l'émergence du premier robot industriel en 1961, la littérature n'a eu de cesse de proposer des architectures de contrôle spécifiques à un domaine (robotique mobile, robotique aérienne, robotique collaborative), d'essayer de les classer, de proposer des solutions dites ouvertes, modulaires, généralisables à tout type d'application. Il apparaît encore aujourd'hui que la variété des propositions ne permet pas encore d'adresser l'un des enjeux fondamentaux d'une application robotique : garantir le processus élémentaire de perception-action.

Pour cela, il nous semble nécessaire de répondre aux exigences suivantes :
- prendre en compte la dynamique de l'environnement,

- sécuriser l'interaction du robot avec l'environnement,

- coordonner le contrôle de plusieurs robots ou machines au sein d'un même système automatisé,

- pouvoir implémenter des stratégies de contrôle de la littérature comme la commande robuste, par exemple.

Les enjeux propres au développement d'une architecture de contrôle robotique sont alors les suivants :

- interopérabilité entre les composants matériels d'une cellule robotique : robots, machines, dispositifs de perception,

- gestion temporelle déterministe du comportement de l'application robotique,

- ouverture de l'environnement de développement s'appuyant sur des langages de programmation non propriétaires,

- facilitation du transfert hors du cadre académique, industrialisation et passage en production.

La proposition d'architecture de contrôle que nous développons dans ce mémoire dépasse voulontairement le simple processus de perception-action d'un seul robot. Une application robotique peut en effet comporter une variété de robots agissant de manière coordonnée afin de converger vers un objectif conjoint au sein d'une même cellule.

Dans la suite de cette section, nous distinguons les différents types d'architectures de contrôle de machines avant d'illustrer les solutions proposées par plusieurs fabricants de robots.

### 1.2.1 Classification des architectures de contrôle

Le paradigme « sense-plan-act » [Siciliano 2008], [Murphy 2000] illustré par la figure 1.4 décrit le rôle dévolu à l'architecture de contrôle. Il s'agit ainsi de :

- percevoir l'état du système et de l'environnement en exploitant les capteurs proprioceptifs et extéroceptifs mis en œuvre au sein de la cellule robotique,

- traiter les informations de perception afin de déterminer les actions à produire,

- produire les actions déterminées par l'envoi des consignes résultantes aux actionneurs.

<figure><img src="image_10.png" /><figcaption>FIGURE 1.4 – Le paradigme « sense-plan-act ».</figcaption></figure>

Pour répondre aux enjeux de ce paradigme, la littérature s'est attachée à proposer des architectures et à les classifier ; l'objectif étant finalement d'essayer d'effectuer un découpage fonctionnel du processus de perception-traitement-action. On distingue ainsi plusieurs types de classifications de ces architectures avec des qualificatifs différents qui doivent être définis, afin de les distinguer. On considère généralement trois types d'organisation de ces architectures
[Russell 2010], [Passama 2014] :

— les architectures hiérarchiques ou délibératives,

— les architecture réactives ou comportementales,

— les architecture hybrides.

### 1.2.1.1 Les architectures hiérarchiques ou délibératives

Par architecture hiérarchique, on entend généralement une structuration de l'architecture en programmes ou modules distincts assurant une fonctionnalité. Ces programmes communiquent entre eux d'une manière prévisible et prédéterminée. Cette hiérarchisation se traduit par des contraintes temporelles différentes entre les modules et classiquement par une décomposition en trois couches :

— une couche décisionnelle qui planifie l'enchaînement des actions relatives à la tâche robotique spécifiée, cette couche est également qualifiée de couche délibérative [41] dans la mesure où elle doit proposer des solutions pour produire des tâches parfois complexes en termes de planification;

— une couche exécutive qui supervise l'exécution des actions;

— une couche fonctionnelle ou bas niveau, en liaison directe avec la couche physique (capteurs et actionneurs).

Cette structuration en trois couches permet d'identifier des temporalités différentes entre les couches qui peuvent aller de quelques minutes sur la couche décisionnelle, à quelques millisecondes de temps de cycle pour la couche fonctionnelle.

### 1.2.1.2 Les architectures réactives ou comportementales

L'architecture réactive est directement inspirée du vivant. Le principe est de pouvoir définir sur la base d'informations capteurs spécifiques des comportements spécifiques. A noter que ces comportements peuvent être facilement décrits dans des machines d'état dédiées. On peut citer les travaux de Brooks [Brooks 1986] qui font référence pour ces architectures. Dans cette architecture de contrôle, des comportements ou règles sont définis à différents niveaux de contrôle. Pour exemple le premier niveau met en œuvre l'évitement d'obstacles; le deuxième niveau met en œuvre un déplacement vers un point particulier ... À chaque cycle d'exécution, des règles sont activées en fonction de l'état actuel du robot et des entrées des capteurs. Parmi les règles activées, le niveau de contrôle d'une règle détermine sa priorité : la règle de plus haut niveau est déclenchée. Dans la plupart des cycles, une règle de bas niveau est activée, alors que, plus rarement, une règle de niveau supérieur est activée.

### 1.2.1.3 Les architectures hybrides

L'architecture hybride associe architecture hiérarchique et architecture réactive et vise à accroître le temps de réaction du robot à l'aide de comportements prédéfinis. On peut citer l'exemple de l'architecture du robot autonome AuRA [Arkin 1997], qui résume l'esprit propre à ces architectures. L'architecture du robot AuRA traite le problème de la planification comme deux systèmes distincts qui s'interfacent l'un avec l'autre : un planificateur global et un planificateur local réactif. On peut faire l'analogie avec l'homme; en effet des preuves psychologiques et neurophysiologiques de la coexistence de deux systèmes de planification distincts chez l'homme
sont rapportées dans [Norman 1986], ce qui a inspiré les roboticiens dans la mise en œuvre de telles architectures.

Parmi ces architectures de contrôle, nombreuses sont celles proposées dans le contexte de la navigation de robots mobiles dans des environnements non structurés avec des contraintes fortes de coordination et de prise en compte de la dynamique de l'environnement.

### 1.2.2 Vers une architecture idéale

D'autres approches de classification sont proposées dans la littérature. Ainsi dans [Mouad 2014], les auteurs classifient les architectures de contrôle selon un autre point de vue. Ils choisissent en effet d'opposer :

- d'une part, les architectures de contrôle centralisées versus les architectures distribuées,

- d'autre part, les architectures de contrôle cognitives versus les architectures réactives.

Cette proposition de classification et la très grande variété des publications relatives à des architectures de contrôle robotique spécifiques à chaque application illustre clairement la nécessité de réaliser une décomposition fonctionnelle très fine des différentes fonctionnalités, tâches et sous-tâches requises dans le développement d'une application robotique.

Les questions de la hiérarchisation, de la concurrence entre les tâches, de l'implémentation de modes de contrôle réactifs ou cognitifs, de la temporalité des tâches et du déterminisme temporel associé, de la distribution des tâches sur plusieurs cibles ou de la centralisation du contrôle doivent pouvoir être adressées dans un cadre architectural plus large d'un point de vue logiciel offrant davantage de flexibilité et d'ouverture que les architectures proposées pour contrôler un ensemble de robots.

Sur la base des architectures existantes, l'architecture de contrôle « idéale » d'une application robotique doit ainsi permettre à la fois :

- de hiérarchiser les tâches et de leur affecter des niveaux de priorité,

- de définir des temporalités différentes entre les tâches,

- de pré-définir des tâches spécifiques,

- de distribuer les tâches sur plusieurs cibles (PC, automates programmables ou microcontrôleurs);

- d'offrir une communication temps réel entre tous les composants matériels et logiciels (tâches, sous-tâches) de l'application.

### 1.2.3 Architectures de contrôle industrielles

La production d'une architecture logicielle de contrôle pour la robotique ne peut être envisagée sans prendre en compte les contraintes propres au transfert hors du cadre purement académique. Pour ce faire, nous rappelons les caractéristiques associées aux contrôleurs des robots industriels et à leur mise en œuvre. La norme ISO 8373:2012 2 fournit une spécification du vocabulaire lié aux robots et composants robotiques, en faisant référence à l'industrie. Un robot y est défini comme un « manipulateur multi-application reprogrammable commandé automatiquement, programmable sur trois axes ou plus, qui peut être fixé sur place ou mobile, destiné à être utilisé dans des applications d'automatisation industrielle ».

Le robot est constitué d'une partie « opérationnelle » ou « opérative » qui réalise la tâche et d'une partie « décisionnelle » ou « commande » qui contrôle la partie opérative.
La partie opérationnelle est constituée de la structure mécanique du robot, des actionneurs, de l'instrumentation proprioceptive (codeurs intégrés, mesures de couple) et extéroceptive (caméras, télémètres, efforts d'interaction), de l'effecteur (torche de soudage, préhenseur, pistolet de peinture, ...).

La partie décisionnelle ou commande assure la gestion du pilotage des axes et leur régulation à partir des consignes transmises depuis l'interface de programmation. La figure 1.5 présente un contrôleur industriel standard. Il s'agit d'une baie Fanuc R30iB qui contient un calculateur principal, une carte de sécurité, des cartes de puissance pour l'alimentation des moteurs et un périphérique d'interaction avec l'utilisateur (teach pendant).

<figure><img src="image_11.png" /><figcaption>FIGURE 1.5 – Contrôleur de robot industriel 6 axes.</figcaption></figure>

La baie R1C de Comau (cf. Figure 1.6) permet de commander la gamme des petits robots sériels quatre et six axes. Elle intègre, dans un encombrement très réduit un PC industriel, un automate de sécurité, deux contrôleurs de mouvement à trois axes chacun, une carte de communication pour protocole Ethernet industriel et une carte électronique intégrant des fonctions de sécurité (cf. Figure 1.6). Contrairement à l'armoire de commande Fanuc, celle-ci est constituée de composants industriels standards (à l'exception de la carte de sécurité).

Il est possible de constituer une partie commande de robots à partir de composants standards. Cette approche permet une mise à l'échelle simplifiée d'une cellule robotique puisque le calculateur principal peut être mutualisé pour piloter plusieurs robots des axes de mouvement complémentaires. A titre d'exemple, la figure 1.7 montre les architectures matérielles des armoires de commande de deux dispositifs utilisés par l'équipe RoBioSS. La première contrôle un robot industriel 6 axes, la seconde un groupe de deux robots 6 axes entraîné par un axe linéaire. Certains constructeurs utilisent le terme de « robotique ouverte » pour désigner cette solution
<figure><img src="image_12.png" /><figcaption>FIGURE 1.6 – Composants de la baie Comau R1C.</figcaption></figure>

qui permet de piloter des architectures mécaniques différentes avec des armoires de commande composées de composants électroniques d'usage général.

<figure><img src="image_13.png" /><figcaption>FIGURE 1.7 – Architectures matérielles de l'armoire de commande de la cellule robotique du projet HARRY2 (gauche) et de la cellule SMALA (droite).</figcaption></figure>

Pour résumer, le contrôleur d'un robot industriel intègre généralement les composants suivants :

- les contrôleurs d'axes : les contrôleurs d'axes permettent d'asservir les actionneurs du robot avec les boucles de contrôle associées (régulation en cascade classique d'une boucle de régulation avec régulateur de courant, régulateur de vitesse et régulateur de position) s'appuyant sur la mesure de courant interne aux actionneurs et la mesure des codeurs
intégrés aux actionneurs. Généralement un contrôleur d'axes assure la régulation d'un, deux ou trois axes en fonction des solutions matérielles choisies ;

- un automate programmable industriel (PLC) : le PLC permet d'assurer le contrôle coordonné des axes en position et en vitesse aussi bien dans l'espace articulaire que dans l'espace opérationnel. Il intègre les machines d'état permettant de gérer les différents modes de marche et d'arrêt du robot ;

- la gestion de la sécurité : cette gestion est généralement assurée par une carte de sécurité ou un automate de sécurité associant des composants de sécurité (barrière matérielle ou immatérielle, arrêts d'urgence, interrupteurs de sécurité, relais de sécurité,...) de manière à prendre en compte toute demande d'arrêt ou tout fonctionnement imprévu. Les caractéristiques des éléments de sécurité varient selon le niveau d'interactivité nécessaire entre l'homme et le robot. Ces différents éléments de sécurité sont mentionnés dans la norme NF EN ISO 10218-2. En fonction de l'application robotique et de l'analyse des risques associée, différents éléments de sécurité peuvent être actifs selon le mode de fonctionnement du robot ;

- un ordinateur de type PC avec environnement Windows ou Linux permettant de gérer l'interface homme-machine avec l'utilisateur et intégrant l'environnement de programmation (IDE) propre au constructeur ;

- un boîtier d'apprentissage, panneau de contrôle ou « Teach Panel » qui permet à l'opérateur de piloter directement le robot en mode manuel dans l'espace articulaire ou opérationnel, d'effectuer un certain nombre d'opérations de configuration (apprentissage des repères outil, des repères de travail, calibration, ...) ou d'arrêter le robot.

Au niveau logiciel, l'architecture de contrôle repose sur :

- les contrôleurs d'axes configurés logiciellement en fonction des contraintes applicatives : les mouvements des axes sont ainsi pilotés à travers un bus de communication temps réel depuis le PLC. L'architecture logicielle du PLC offre un fonctionnement temps réel dur avec un déterminisme temporel strict basé généralement sur un système d'exploitation temps réel tel que VxWorks, ou plus récemment des versions de Linux pour le temps-réel. L'implémentation des tâches cycliques périodiques de bas niveau au sein du PLC permet :

- de gérer les différents modes de déplacements des axes en implémentant généralement les fonctionnalités propres au standard PLCopen Motion Control,

- les différents modes de déplacement du robot dans l'espace articulaire, dans l'espace opérationnel avec l'implémentation des modèles cinématiques direct et inverse,

- l'interprétation des lignes de commande issues du programme dans le langage robot du fabricant.

- Le programme propre à l'application est quant à lui mis en œuvre au sein généralement d'un PC intégré au contrôleur. Le développeur dispose d'une suite logicielle permettant le développement des programmes applicatifs, leur débogage et leur simulation. La réalisation des programmes utilisateurs est réalisée avec un langage de programmation proprietary (Fanuc KAREL, Stäubli Val3, KUKA KRL, ABB RAPID) ou avec un langage standard pour certains cas spécifiques (Java pour le Kuka IIWA). Dans ce contexte, l'absence de standard pour la programmation des robots industriels est un facteur limitant dans le développement d'applications multirobots multifabricants. Plusieurs stratégies sont en train d'émerger pour lever cette difficulté. Ce point sera développé dans le chapitre 3.1.1.
Un point important dans le choix d'un robot est la possibilité de pouvoir accéder au contrôleur du robot depuis une ligne de communication externe afin de l'intégrer dans une machine ou une ligne de production. Les modes d'accès au contrôleur du robot varient d'un fabricant à l'autre; en fonction du bus de communication (temps réel ou non) proposé, du type d'accès offert (régulateur en position par exemple), du temps de cycle propre au protocole implémenté, les performances obtenues peuvent être extrêmement variables. Le tableau 1.1 illustre quelques exemples de caractéristiques relatives à l'accès à des contrôleurs de robots industriels et collaboratifs.

**Universal Robot** A titre d'exemple, les robots collaboratifs du fabricant Universal Robot offrent un accès à leur contrôleur depuis une communication TCP/IP et via les scripts de commande URScript avec un temps de cycle de l'ordre de 100ms. En l'occurrence, même si le temps de cycle du contrôleur de position interne des robots UR est de 8ms, l'accès à l'intergiciel de pilotage ROS implémenté sur un ordinateur distant devient problématique car il existe un délai de 170ms entre la réception de la consigne et la position actuelle retournée [Ravn 2014], [Andersen 2015]. Plusieurs travaux ont été proposés dans la littérature exploitant ce mode de communication sous ROS pour de la téléopération [Wieczorek 2020], [Omarali 2017]. Une analyse de l'erreur entre la position souhaitée et la position réelle est fréquemment utilisée pour évaluer la qualité du contrôle téléopéré; l'erreur étant liée à la vitesse, des mouvements plus rapides entraînent une erreur de position plus importante. Aussi une évaluation du délai entre la pose commandée et la pose réelle offre un meilleur indicateur de la qualité du contrôle [Park 2016]. Ainsi dans [Wieczorek 2020], les auteurs observent un délai de 350ms entre pose commandée et pose réelle dans la réalisation d'une ligne droite avec un robot UR5. Dans [Omarali 2017], les auteurs relèvent l'impossibilité de recopier le mouvement humain acquis par un système de capture du mouvement en raison du délai entre pose commandée et pose réelle à travers les drivers ROS ou Matlab [de Gier 2015] mis en œuvre; ce constat a conduit les auteurs à développer une commande prédictive avec un horizon de prédiction de 500ms. On note également la latence de 50ms évoquée dans la documentation technique de Shadow Robotics [Company 2021] dans l'envoi d'une commande au bras manipulateur UR10e exploitant un contrôleur CB3 et une communication Ethernet à travers l'intergiciel ROS. Pour autant, dans [Fritsche 2015], les auteurs estiment qu'un délai pouvant atteindre 800ms est acceptable dans le contexte de leur application. Ces résultats illustrent le fait que l'accès au contrôleur industriel des robots collaboratifs Universal Robot à des fins de commande externe offre une variété de possibilités, que ce soit via ROS et URScripts, via Matlab et URControl ou via C-API au niveau logiciel, via TCP/IP Real Time, via TCP/IP Socket, via Modbus TCP ou via Profinet/Ethernet IP au niveau de la communication [Ponsà Cobas 2020]. Toutefois à la lecture des travaux exploitant ces différents modes d'accès, les résultats et performances obtenus varient de manière significative et démontrent la difficulté d'uniformiser l'accès aux modes de contrôle du robot depuis un contrôleur externe avec du déterminisme temporel dans le comportement du robot.

**Kuka** On peut également citer les travaux relatifs au contrôle des robots industriels Kuka; plusieurs interfaces logicielles ont été développées par différents laboratoires afin de s'interfacer avec les différentes familles de contrôleurs Kuka. La boîte à outils Kuka Control Toolbox (KCT) présentée dans [Chinello 2011], propose une collection de fonctions MATLAB permettant le contrôle du mouvement des robots industriels Kuka. A travers cette interface de programmation sous
par les chercheurs, ces performances, le manque de robustesse et de standardisation de l'accès aux contrôleurs industriels posent question. Ces quelques exemples illustrent clairement la complexité de l'uniformisation de l'accès aux contrôleurs industriels existants dans le contexte d'applications robotiques multirobots et multifabricants.

<table><caption>TABLE 1.1 – Exemples d'accès distants aux contrôleurs industriels de robots.</caption><thead><tr><td>Fabricant / baie de commande</td><td>Communication / période [ms]</td><td>Temps réel ?</td><td>Type d'accès</td></tr></thead><tbody><tr><td>Stäubli / Unival open controller</td><td>POWERLINK / 2</td><td>oui</td><td>Accès au régulateur de position</td></tr><tr><td>Universal Robot / CB2</td><td>TCP/IP / 100</td><td>non</td><td>Envoi - réception de scripts (URScripts)</td></tr><tr><td>Kuka / LBR4+</td><td>UDP - FRI, horodatage trames UDP / 1</td><td>non</td><td>Accès aux modes de contrôle articulaire, cartésien, impédant articulaire, impédant cartésien</td></tr><tr><td>Kuka / KRC4</td><td>TCP/IP - RSI / 10</td><td>non</td><td>Accès aux variables de contrôle internes au contrôleur</td></tr></tbody></table>

Dans le contexte de l'usine du futur où l'interopérabilité est un enjeu majeur, on conçoit que l'absence de standard de communication temps réel entre des robots de différents fabricants, que le fait d'avoir des modes d'accès différents aux boucles de contrôle des robots est de nature à limiter fortement le développement d'applications nécessitant un haut niveau de synchronisation entre les machines/les robots et une prise en compte de la dynamique de l'environnement pour des applications robotiques collaboratives impliquant à la fois des robots industriels (modes collaboratifs 1 à 3 de la norme ISO 10218, cf. § II) et des robots collaboratifs (modes collaboratifs 4 de la norme ISO 10218, cf. § II).

## 1.3 Intergiciels pour le contrôle en robotique

Comme nous l'avons évoqué dans la section précédente, la robotique industrielle avec une offre de robots, de contrôleurs et un environnement logiciel dédié répond aujourd'hui à la plupart des contraintes industrielles classiques propres à la production de tâches répétitives dans un environnement généralement fermé et parfaitement connu et invariant dans sa configuration.

En l'occurrence, dès lors qu'il faut intégrer des contraintes supplémentaires : interfacer des composants de nature différente avec les contrôleurs (capteurs de vision, d'efforts, interfaces haptiques, gants de données, préhenseurs évolués, contrôleurs externes, ...), développer une application robotique logicielle avec du déterminisme temporel dans l'ordonnancement, gérer l'exécution de l'ensemble des tâches de l'application répartie sur plusieurs cibles en adressant une grande variété de composants, il devient indispensable de pouvoir offrir une architecture logicielle capable de répondre à ces enjeux.

Le besoin de faire communiquer des applications s'exécutant sur plusieurs machines à travers
un réseau est apparu très tôt et a conduit au début des années 90, à l'apparition des premiers
middlewares ou intergiciels. On pourra retenir la définition proposée dans [Bakken 2001] pour
définir un middleware : « A layer of software above the operating system but below the applica-
tion program that provides a common programming abstraction across a distributed system » ;
c'est-à-dire une couche logicielle située entre système d'exploitation et programme d'application
qui permet de proposer un cadre commun pour la programmation d'applications distribuées à
travers le réseau sur plusieurs machines ou processeurs.

Dans ce contexte de nombreuses propositions d'intergiciels ont vu le jour dans la communauté
robotique académique et industrielle afin de permettre le développement logiciel d'applications
robotiques complexes et distribuées.

1.3.1 Classification des intergiciels

L'intergiciel est une solution aujourd'hui communément admise pour faciliter le développement d'applications distribuées hétérogènes. Le choix d'un intergiciel particulier devient ainsi une question de conception essentielle : comme il n'existe pas de solution de distribution « unique », ce choix n'est pas neutre et peut influencer profondément la conception finale et les performances d'une application. Avant de présenter les caractéristiques des intergiciels dédiés aux applications robotiques, il est important de rappeler les différentes classes d'intergiciels en fonction des mécanismes utilisés pour communiquer entre les composants :

- *Transactions Processing* : cette classe concerne l'exécution de transactions mettant en œuvre un mécanisme simple de coopération entre les clients, les serveurs et les systèmes de gestion des bases de données. Elle garantit le fait que la tâche est correctement récupérée en cas de défaillance et que la base de données reste cohérente même en cas d'arrêt et d'exécution incomplète. Des protocoles en deux ou trois phases sont mis en œuvre pour sécuriser ces transactions. Elle est clairement orientée vers les bases de données et ne rentre donc pas dans le cadre du sujet qui nous intéresse ;.

- *Remote Procedure Calls (RPC)* : cette classe de middleware distribue l'exécution de
routines sur un réseau.

- *Object Request Broker (ORB)* : cette classe permet de distribuer et de partager les objets d'une application sur des réseaux hétérogènes ; elle constitue le cœur de l'architecture CORBA, assurant les communications et les synchronisations entre objets.

- *Message Oriented Middleware (MOM)* : cette classe permet aux applications distribuées de communiquer et d'échanger des données en envoyant et en recevant des messages.

- *Service Oriented Middleware (SOM) / Entreprise Service Bus (ESB)* : cette classe de middlewares permet de proposer une approche de développement orientée services basée sur l'architecture SOA (Service Oriented Architecture) avec l'objectif de rendre ces services accessibles et disponibles à travers des modèles et protocoles standards.

1.3.1.1 Middleware de type RPC

Une procédure RPC [Birrell 1983] représente une action déclenchée par un programme afin d'exécuter une sous-routine dans un autre processus, généralement sur un autre ordinateur partagé en réseau. Cette procédure est développée comme s'il s'agissait d'un appel de sous-routine local, sans la complexité de l'interaction à distance. Cela peut être vu comme une
architecture client-serveur où le client est le processus qui appelle l'exécution du sous-programme distant.

Ce type de middleware permet ainsi aux procédures d'une application d'appeler des procé-
dures d'applications distantes comme s'il s'agissait d'appels locaux. Un middleware RPC offre
ainsi la possibilité de mettre en œuvre facilement des procédures RPC par la génération du code
logiciel « Stub » côté client et du code logiciel équivalent côté serveur « Skeleton », et il permet
également la transformation de la représentation en mémoire d'un objet en un format de données
adapté au stockage ou à la transmission entre différentes parties d'un programme informatique
ou d'un ordinateur à un autre (« Marshalling / Unmarshalling » des données). Ce code logiciel
exécutable « Stub » permet de gérer la procédure distante côté client et de récupérer localement
le résultat de l'exécution distante du code logiciel exécutable « Skeleton » sur le serveur.

<figure><img src="image_14.png" /><figcaption>FIGURE 1.8 – Les différentes étapes d’un appel de procédure RPC.</figcaption></figure>

Comme illustré sur la figure 1.8, l'appel d'une procédure RPC est initié par le client via le code logiciel exécutable « stub » qui envoie un message de demande à un serveur distant connu (étapes 1 à 5) pour exécuter une procédure spécifiée via le code exécutable logiciel « Skeleton ». Le serveur distant répond avec le résultat de l'exécution (étapes 6 à 10) et l'application poursuit son traitement. Il est important de noter que les procédures RPC sont synchrones; ainsi le plus grand inconvénient est la possibilité que l'appel de procédure distante échoue à cause de problèmes de réseau imprévisibles [Qilin 2010].

L'intergiciel de type RPC met en œuvre un mécanisme de liaison qui localise les procédures distantes et les met à la disposition de l'appelant de manière transparente. Traditionnellement, ce type d'intergiciel traite les programmes basés sur des procédures; il comprend désormais également des composants basés sur des objets.

1.3.1.2 Middleware de type ORB

Un middleware de type ORB (Object Request Broker) repose sur la notion de bus logiciel [Chacko 2013]. ORB permet ainsi la communication entre deux programmes se situant sur des machines différentes en ayant l'impression que l'appel reste local. Un courtier de message (Broker) est mis en œuvre pour gérer l'interaction entre le client et le serveur. L'architecture d'ORB la plus connue est CORBA (Common Object Request Broker Architecture). CORBA [Pope 1998] est né du consortium OMG (Object Management Group), créé en 1989 et composé d'environ 800
entreprises (Sun, Oracle, IBM, Hewlett Packard, IBM) avec l'objectif de faire émerger des stan-
dards pour l'intégration d'applications distribuées hétérogènes et la réutilisation de composants
logiciels.

<figure><img src="image_15.png" /><figcaption>FIGURE 1.9 – Middleware de type ORB : architecture OMA (gauche), principe de l'ORB (droite).</figcaption></figure>

Cette norme a été définie par l'OMG de 1990 (rédaction du guide relatif à l'architecture OMA (figure 1.9) : Object Management Architecture) à 1991 (spécification de CORBA V1.1 basée sur l'OMA). Au sein de l'architecture CORBA, tout est basé sur la notion d'objet. CORBA a été développé dans le but de permettre une interconnexion et une communication des logiciels entre eux, même s'ils sont implémentés sur des systèmes hétérogènes ou dans des langages différents. Le principe de fonctionnement client-serveur s'appuie sur le fait que le client demande au Broker l'exécution d'un service (demande d'exécution d'une méthode sur un objet). A l'issue de cette demande, le Broker identifie un serveur capable de fournir le service et il transmet la requête au serveur identifié (cf. figure 1.9).

1.3.1.3 Middleware de type MOM

Les MOM assurent une communication distribuée entre plusieurs machines et applications
avec un mode d'échange client-serveur asynchrone entre émetteur et récepteur. Ce modèle non
bloquant permet de résoudre un grand nombre de limitations propres aux middleware RPC. Les
participants à un système basé sur MOM ne sont pas obligés de bloquer et d'attendre l'envoi d'un
message. Après l'envoi d'un message, ils sont autorisés à poursuivre le traitement, ce qui permet
la livraison de messages lorsque l'expéditeur ou le destinataire n'est pas actif ou disponible pour
répondre au moment de l'exécution. L'envoi de messages dont la livraison peut prendre plusieurs
minutes est ainsi possible, contrairement à des mécanismes tels que RPC.

Tous les MOM proposent ainsi un mécanisme de communication où les clients envoient des
messages avec leurs demandes d'exécution de service à un ou plusieurs serveurs à travers le
réseau avec en retour le résultat de l'exécution [Pope 1998]. On distingue toutefois deux classes
de MOM avec des mécanismes différents pour le relais des messages :

- Les MOM basés sur les files d'attente : les MOM basés sur les files d'attente sont basés sur une architecture un-à-un comme le montre la figure 1.10. L'application réceptrice possède une file d'attente où elle stocke tous les messages reçus de toutes les applications clientes. Elle traite ensuite ces messages selon la méthode FIFO (First In First out).
<figure><img src="image_16.png" /><figcaption>FIGURE 1.10 – Les deux classes de MOM : MOM basés sur file d'attente (gauche) et sur un courtier de messages (droite).</figcaption></figure>

— Les MOM basés sur un mécanisme « Publish/Subscribe » ou mode par Publication/Abonnement : ce MOM Publish/Subscribe fournit une architecture dans laquelle les messages sont acheminés par un courtier en messages ou « Message broker ». Les récepteurs doivent s'abonner avant de recevoir des messages. Comme le montre la figure 1.10, la principale différence avec un MOM basé sur une file d'attente est l'architecture qui permet aux messages d'être acheminés via un courtier en messages et qui permet aux messages d'être reçus par tous les récepteurs abonnés.

Les MOM peuvent également inclure des fonctionnalités telles que la persistance et la réplication des messages et ils peuvent fournir des performances de qualité de service (QoS) [Capra 2001].

### 1.3.1.4 Middleware de type SOM / ESB

Le middleware de type SOM [Al-Jaroodi 2012] (Service Oriented Middleware) est une catégorie d'intergiciels basée sur une architecture orientée services (SOA). SOA (Service Oriented Architecture) est un modèle architectural de conception au sein duquel les composants d'application fournissent des services à d'autres composants via un protocole de communication sur un réseau.

Les principes sous-jacents à SOA sont indépendants de tout fournisseur, produit ou technologie. Un service doit mettre en œuvre au moins une action spécifique, comme par exemple la demande de la valeur d'un capteur, la mise à jour de la configuration d'une mission ou la modification des paramètres de l'environnement. Un middleware de type SOM est conçu comme un ensemble de services qui peuvent être utilisés pour faciliter le développement, l'exécution et la gestion des applications orientées services. Il s'insère comme les autres middlewares entre les principaux acteurs du SOC (Service Oriented Computing) à savoir les fournisseurs de services, les développeurs de services et les consommateurs de services.

SOM est ainsi composé de trois principaux composants : un fournisseur de services, un demandeur de services et un registre. Cette architecture permet aux fournisseurs de services de déployer facilement leurs composants et de publier leur présence dans le registre, afin que les
demandeurs de services puissent ensuite y accéder. Un mécanisme est par ailleurs mis en œuvre pour permettre la découverte des services publiés. SOM propose également une abstraction des services hétérogènes afin d'homogénéiser la manière d'y accéder.

Les communications peuvent être établies aussi bien en mode synchrone, qu'en mode asynchrone. La figure 1.11 représente une vue de l'architecture SOA propre à un middleware de type SOM, en partant des données, en passant par la couche d'abstraction des données, les services de données, les services, les couches d'orchestration et enfin la surveillance et la gestion des événements [Chitic 2018].

Les intergiciels SOA fournissent des mécanismes pour découvrir et localiser les services disponibles. Cela permet aux applications de trouver dynamiquement les services dont elles ont besoin. Ils incluent généralement des mécanismes de gestion des politiques qui permettent de spécifier des règles et des contraintes concernant l'utilisation des services (authentification, autorisation, confidentialité ou qualité de service).

<figure><img src="image_17.png" /><figcaption>FIGURE 1.11 – L'architecture SOA qui fonde les intergiciels de type SOM et ESB d'après [Chitic 2018].</figcaption></figure>

ESB est un autre type de middleware qui s'appuie sur l'architecture logicielle SOA pour la communication entre composants [Schmidt 2005]. Son modèle de communication est dérivé du modèle client-serveur et s'appuie sur un paradigme de bus logiciel. La principale différence entre ESB et SOM est l'absence de courtier central, ce qui rend l'ESB plus flexible et plus évolutif.

Comme le montre la figure 1.12 [Chitic 2018], ESB est capable de permettre à des composants hétérogènes de communiquer à l'aide de divers formats de stockage/transmission de données (marshalling) tels que JavaScript Object Notation (JSON) ou Simple Object Access Protocol (SOAP).

Les classes d'intergiciels présentées illustrent les architectures logicielles mises en œuvre afin de faciliter la distribution de composants logiciels sur des systèmes, des réseaux hétérogènes en
<figure><img src="image_18.png" /><figcaption>FIGURE 1.12 – Communication entre composants hétérogènes basée sur ESB.</figcaption></figure>

permettant la communication et l'interaction entre ces composants.
1.3.2 A quels enjeux répondent les intergiciels de robotique ?

Les robots développés aujourd'hui en recherche intègrent une grande variété de composants matériels et logiciels développés dans des langages variés et reposant à la fois sur des standards et des protocoles de communication différents. Ces robots sont amenés à évoluer de plus en plus dans des environnements ouverts et dynamiques, à coordonner leurs actions avec d'autres robots, ce qui induit naturellement le développement d'applications logicielles avec des besoins de perception multimodale, partagée entre plusieurs robots, un traitement temps réel de la perception afin de produire en sortie une commande sûre et adaptée aux contraintes applicatives.

Pour faciliter le développement de ces applications logicielles, les intergiciels de robotique
offrent une couche d'abstraction entre le système d'exploitation et l'application permettant à
la fois de gérer cette forte hétérogénéité matérielle et logicielle et également ces besoins élevés
d'operopérabilité.

Les intergiciels de robotique doivent ainsi composer avec les caractéristiques du robot d'une part, et les besoins propres à l'application d'autre part afin de répondre aux enjeux suivants [Mohamed 2009] :

— simplifier le développement des applications robotiques avec des API (Application Pro-
gramming Interface) dédiées pour encourager la réutilisation et l'intégration ;

— accompagner la communication et l'interopérabilité entre composants et entre robots ;

— fournir des services et fonctions de haut niveau permettant de produire des tâches impli-
quant la collaboration entre robots ;

— fournir une couche d'abstraction logicielle permettant d'unifier et de simplifier l'accès aux composants afin de masquer la complexité propre à leur accès bas niveau et à leur hétérogénéité ;

— fournir des services permettant d'accéder en temps réel à d'autres systèmes (capteurs sans fils, serveurs, ...);

— proposer des services de base pour la robotique (planification, cartographie, saisie, loca-
lisation, ...) afin de proposer l'accès aux fonctions et algorithmes associés les plus com-
munément utilisés ;

— offrir également des mécanismes d'auto-récupération, d'auto configuration et d'auto-adaptation afin de s'adapter à un environnement dynamique [Valle 2013].

La contrepartie d'avoir une couche d'abstraction masquant l'hétérogénéité des capteurs et des actionneurs est que le logiciel de commande est plus complexe. Il peut être aussi plus sujet aux défaillances, particulièrement dans le contexte de l'implémentation de schémas de contrôle multiaxe ou multirobot pouvant nécessiter un fonctionnement cyclique périodique avec des temps de cycle courts.

1.3.3 Synthèse des intergiciels en robotique

Les intergiciels de robotique ont largement été développés et étudiés dans la littérature
[Chitic 2018], [Mohamed 2009], [Mohamed 2008], [Elkady 2012]. Ils sont parfois désignés sous
les termes « framework », « middleware », « plateforme logicielle » dans la littérature. Il est
difficile aujourd'hui d'appréhender les différences entre les nombreuses propositions d'intergi-
ciels existantes, hormis le fait que certaines propositions sont clairement orientées vers certains
domaines cibles, tels que la robotique mobile avec le contrôle de flottes de robots [Kramer 2007].
Pour essayer d'extraire les contributions les plus significatives du domaine nous nous sommes
appuyés sur les mêmes critères que [Chitic 2018] en basant notre synthèse sur les intergiciels les plus cités et sur la nécessité de pouvoir prendre en compte un environnement multirobot. Ces intergiciels dédiés à la robotique s’appuient pour certains sur les types de middleware introduits précédemment.

On recense dans la table 1.2, les middlewares les plus connus qui ont évolué pour certains depuis leur création. Pour compléter les éléments présentés dans ce tableau, on peut observer une grande variété de propositions pour répondre à ces enjeux relatifs aux développements d'applications logicielles robotiques. La plupart de ces propositions d'intergiciels ont émergé pour permettre aux laboratoires fondateurs ou entreprises de pouvoir uniformiser et accompagner le développement de leurs propres plateformes robotiques avec un souci de standardisation du code, de réutilisation et d'interopérabilité entre les différents composants mis en œuvre (capteurs, actionneurs, ...), avec également un besoin de simulation. On note également que les travaux relatifs aux intergiciels depuis quelques décennies n'ont pas conduit à de nouvelles propositions pertinentes depuis une dizaine d'années. En effet les intergiciels cités ont évolué avec des extensions, des travaux associés pour certains et l'adhésion d'une communauté a finalement permis d'assurer leur déploiement à une échelle plus large ; c'est le cas du middleware ROS qui est aujourd'hui devenu le middleware de référence dans le domaine de la robotique.

Dans [Chishiro 2009] les auteurs présentent l'extension OpenRTMaist pour RT-Middleware afin d'y intégrer des fonctionnalités de contrôle temps réel dur ; cette extension est souvent présentée à tort comme un middleware. De la même manière, Pyro ou Python Robotics [Blank 2005] est finalement une extension du middleware Player [Kranz 2006]. Il existe de nombreuses bibliothèques pour Pyro qui fournissent des services robotiques spécifiques déployés parallèlement sous Player. L'intergiciel est compatible avec les robots mobiles Pioneer, Sony Aibo et tous les robots supportés par Player/Stage. Le langage de programmation Python a contribué à son déploiement important dans le domaine de l'éducation.

On observe également que Orocos [Bruyninckx 2001], RT-Middleware [Ando 2005], Babel [Kwak 2006], IRSP [Fernandez 2006], Miro [Kruger 2006] s’appuient sur CORBA (Common Object Request Broker). OpenRTM-aist et OPRoS mettent en œuvre la norme de l’OMG pour standardiser la gestion des composants : le Robot Technology Component Standard de l’OMG. Pour autant un certain nombre d’intergiciels ont fait un choix différent, ce qui explique aussi probablement leur difficulté à s’imposer auprès d’une plus large communauté d’utilisateurs.

Un point important pour classer et comparer ces middlewares est de définir des critères permettant d'objectiver leurs performances et leurs capacités à répondre aux enjeux de la section 1.3.2. [Calisi] proposent une classification des middlewares existants (cf. table 1.3) s'appuyant en premier lieu sur la manière dont les tâches sont implémentées et sur la manière de partager des informations entre les tâches.

Une autre comparaison intéressante est proposée dans [Jang 2010] qui s'appuie sur un certain nombre de critères tels que les OS supportés, middleware de type RPC ou non, tolérance aux fautes, temps réel, cf. table 1.4. Les critères retenus valorisent OPRoS qui remplit tous les critères retenus, hormis un aspect essentiel relatif au temps réel. Les auteurs notent ainsi que OPRoS ne supporte pas l'ordonnancement temps réel et que l'exécution périodique de composants logiciels souffre de variations temporelles dues à l'ordonnancement non temps réel.

[Chitic 2018] choisit d'évaluer huit intergiciels de référence en s'appuyant sur trois groupes de critères : l'architecture, l'infrastructure et l'usage.
**Architecture** Comme illustré sur la figure 1.5, pour évaluer le premier groupe de critères propres à l'architecture, l'auteur considère trois sous-critères : *Overhead* qui correspond à la charge de calcul induite par le middleware, liée aux ressources logicielles nécessaires pour instancier le middleware avec les services associés ; *Vendor locking* correspond aux systèmes d'exploitation supportés ; et *Robustness to Failures*, qui considère la possibilité de redémarrer automatiquement le middleware en cas de défaut ou d'avoir un mode dégradé inhibant certains services. Avec cette grille de lecture, les middleware ROS et Player sont clairement avantagés.

**Infrastructure** Le second groupe de critères illustré sur la figure 1.6 s'intéresse aux caractéristiques techniques de l'intergiciel. Cinq sous-critères sont considérés : *MM* (Management and Monitoring) évalue la possibilité d'avoir une interface de gestion et de suivi de l'exécution des composants, services instanciés ; *MCS* (Multi-robot Coordination Services), la possibilité d'intégrer la coordination multirobot ; *SOTS* (Scheduled Operations and Tasks Services), la possibilité d'ordonnancer des tâches dans le middleware ; *DDSS* (Durable Data Storage Services), la possibilité de sauvegarder des informations propres aux capteurs, aux messages, et *COM* (COMmunication) considère la manière de communiquer entre les composants logiciels distribués.

Le sous-critère MM valorise ROS et MRDS car ROS intègre de manière native tous les outils nécessaires au développement et un tableau de suivi auquel il est possible d'accéder à distance et qui permet de monitorer tous les paramètres de l'application ; de même MRDS adossé à l'IDE Microsoft Visual Studio offre tous les outils de monitoring et débogage. Pour autant l'auteur aurait pu mettre au même niveau Player/Stage, MARIE et Pyro qui intègrent une interface graphique permettant de contrôler, visualiser les composants et leur état.

**Coordination multirobot** Le sous-critère MCS montre une des faiblesses de tous ces middlewares qui est de ne pas intégrer de manière native la coordination multi-robots ; en effet ROS, Miro, MRDS, Orca, MARIE et Pyro laissent l'application gérer cette coordination au niveau supérieur. Pour le sous-critère SOTS, la plupart des middlewares délèguent l'ordonnancement des tâches au système d'exploitation, et généralement à Linux qui reste l'OS le plus répandu ; pour MRDS il est géré par l'ordonnanceur de Windows. Seul le middleware MARIE intègre la possibilité en interne de gérer l'ordonnancement de tâches et services. Pour le sous-critère DDSS, seul le middleware ROS offre des services de stockage. Pour autant, il est possible avec Player/Stage, MRDS, Orca et Pyro de sauvegarder dans des fichiers texte, de même pour MIRO, MARIE et Carmen de sauvegarder dans des fichiers XML (Extensible Markup Language).

Le sous-critère COM est un critère essentiel. On distingue naturellement les communications synchrones et asynchrones, tous les middlewares ne permettent pas les communications synchrones en raison de leur conception interne. Pour Player/Stage, Pyro la méthode de communication repose sur des connexions directes via socket. Pour MARIE et MIRO, les échanges sont gérés via CORBA. Pour Carmen, elle est basée uniquement sur IPC. MRDS et ROS supportent à la fois la communication synchrone et asynchrone. MRDS utilise le protocole DSSP (Decentralized Software Services Protocol) basé sur SOAP et le protocole HTTP (Hypertext Transfer Protocol) pour établir les échanges entre les services. ROS prend en charge la communication synchrone via les services, la communication asynchrone via les topics, les messages structurés utilisant un langage de description d'interface (IDL) spécifique. ROS et MRDS supportent des protocoles standards comme TCP et HTTP.
**Usage** Pour terminer l'analyse de [Chitic 2018], l'auteur évoque un dernier groupe de critères relatifs à l'usage. Quatre sous-critères sont ainsi définis : *DLC* (Deployment and Life-Cycle) qui considère les outils utilisés pour faciliter, tester, accompagner le développement ; *PM* (Programming Model) considère le type de programmation (blocs séquentiels, sur évènements, ...); *CDIS* (Code and Data Integration Services) considère la possibilité d'intégrer de nouvelles fonctions, de nouveaux services via des API; EPI (Extension Points and Interfaces) fait référence aux services très demandés. On observe que la plupart des middlewares satisfont au sous-critère DLC, car ils utilisent des outils de compilation standards tels CMake (catkin sous ROS s'appuie sur CMake) et ils offrent également la possibilité de se connecter à des environnements de simulation comme Gazebo. Naturellement Microsoft sort du lot avec son IDE Visual Studio qui offre toutes les fonctionnalités nécessaires sur l'ensemble des critères. De même pour la programmation, plusieurs langages sont supportés avec naturellement un avantage pour les langages plus proches du système tels C, C++, C# et plusieurs modèles de programmation synchrones, asynchrones également qui permettent de coder les comportements attendus sous formes de séquences, sur évènements ou avec des machines d'états. Pour le sous-critère CDIS, tous les middlewares offrent une architecture modulaire facilitant l'intégration et la réutilisation du code. De la même manière, ils offrent tous une variété de services liée généralement au domaine applicatif pour lequel ils ont été initialement développé. Pour autant ROS est aujourd'hui le grand gagnant, car il fédère la plus large communauté d'utilisateurs, qui contribue fortement au développement de nouveaux services dans tous les champs applicatifs de la robotique. L'analyse de ces trois grilles conduit ainsi l'auteur à mettre en avant ROS et en second lieu MRDS dans un contexte visé qui est celui de la mise en œuvre de flottes de robots.

De nombreuses autres grilles de lecture ont été proposées qui recoupent ces critères, par exemple [Mohamed 2008] ou [Mohamed 2009]. Les auteurs de ces différentes analyses convergent vers la même conclusion. Aucun des middlewares évoqués ne permet aujourd'hui d'adresser tous les enjeux et contraintes applicatives de tout système robotique.

Pour la plupart de ces middlewares, on peut relever les manques suivants qui sont préjudiciables dès lors que l'on souhaite contrôler de manière robuste plusieurs robots, machines multiaxes dans une cellule de production et plus généralement dans l'usine où évoluent en temps réel des robots, des humains, des machines potentiellement en interaction :

- les middlewares présentés sont orientés robotique et non orientés machine : les robots sont en effet amenés à être intégrés dans des cellules de production où leurs mouvements peuvent être coordonnés avec d'autres machines, portiques multiaxes;

- les middlewares n'intègrent pas de manière native le déterminisme temporel de l'application du plus bas niveau au plus haut niveau : il devient alors difficile de garantir la réalisation de stratégies de contrôle mises en œuvre avec des temps de cycle préalablement définis pour chaque tâche;

- les middlewares ne permettent pas d'assurer un haut niveau de coordination de plusieurs machines multiaxes, plusieurs robots dans le contexte de la réalisation d'une tâche conjointe : une telle coordination implique une communication temps réel dur entre l'ensemble des tâches qui peuvent être distribuées sur plusieurs processeurs à travers un réseau de machines, de robots coordonnés;

- les standards industriels mis en œuvre par les fabricants de robots, de machines, par les spécialistes de l'automation ne sont pas pris en compte dans les middlewares présentés ce qui explique probablement en partie, la difficulté de transférer ces middlewares hors
des laboratoires de recherche;

— l'intergiciel, par définition placé entre l'OS et le programme utilisateur, implique une rupture dans la continuité du développement applicatif.

Pour compléter cette analyse des middlewares existants, nous choisissons de présenter plus en détail trois middlewares qui nous semblent emblématiques parmi ceux cités précédemment, afin de mieux apprécier les caractéristiques inhérentes à ces intergiciels.
<table><caption>TABLE 1.2 – Principaux intergiciels de robotique.</caption><thead><tr><td>Publ.</td><td>Intergiciel</td><td>Laboratoire</td><td>Architecture et caractéristiques</td></tr></thead><tbody><tr><td>2001</td><td>Orocos<br/>[Bruyninckx 2001]</td><td>Université<br/>Catholique de<br/>Louvain, Belgique</td><td>Développement d'applications basées sur des composants de contrôle en temps réel configurables et interactifs. Largement utilisé dans la communauté robotique.</td></tr><tr><td>2003</td><td>CARMEN<br/>[Montemerlo 2003]</td><td>Carnegie Mellon<br/>University, USA</td><td>Écrit en C, repose sur une architecture à 3 niveaux. Le 1er niveau fournit une abstraction matérielle pour les capteurs et autres composants. Le 2nd niveau offre des services (navigation, localisation, suivi d'objets, planification) du mouvement. Le 3ème niveau est l'application utilisateur et s'appuie sur les données provenant des couches inférieures et une communication IPC (Inter-Process Communication).</td></tr><tr><td>2004</td><td>MissionLab<br/>[Endo 2004]</td><td>Mobile Robot<br/>Laboratory,<br/>Georgia Tech,<br/>USA</td><td>Système de planification de mission basé sur une architecture de commande hybride délibérative et réactive pour les robots mobiles autonomes.</td></tr><tr><td>2004</td><td>Webots<br/>[Michel 2004]</td><td>Cyberbotics Ltd,<br/>spin off EPFL,<br/>Suisse</td><td>Environnement de prototypage pour modéliser, simuler et programmer un robot mobile.</td></tr><tr><td>2005</td><td>RT-Middleware<br/>[Ando 2005]</td><td>AIST, Tsukuba,<br/>Japon</td><td>Approche basée sur l'intégration de fonctions de systèmes robotiques par une gestion modulaire de composants logiciels basée sur CORBA.</td></tr><tr><td>2005</td><td>Orca<br/>[Brooks 2005]</td><td>Institut für<br/>Technische<br/>Informatik,<br/>Lübeck, Allemagne</td><td>Intergiciel open source pour le développement de systèmes à base de composants.</td></tr><tr><td>2006</td><td>Clarity<br/>[Nesnas 2006]</td><td>Jet Propulsion<br/>Laboratory, USA</td><td>Architecture embarquée de contrôle multicouche gérant l'exécution, la planification de tâches de navigation mobile autonome (application spatiale sur le Mars Rover).</td></tr><tr><td>2006</td><td>WURDE<br/>[Heckel 2006]</td><td>Washington<br/>University, USA</td><td>Architecture basée sur 4 niveaux d'abstractions : communications inspirées de CORBA, interfaces, applications et systèmes. Application en robotique mobile.</td></tr><tr><td>2006</td><td>Babel [Kwak 2006]</td><td>University of<br/>Malaga, Espagne</td><td>Système de développement composé d'outils pour l'implémentation, l'exécution, le débogage et la maintenance d'applications robotiques. Support de CORBA.</td></tr></tbody></table>
<table><thead><tr><td>Publ.</td><td>Intergiciel</td><td>Laboratoire</td><td>Architecture et caractéristiques</td></tr></thead><tbody><tr><td>2006</td><td>IRSP [Fernandez 2006]</td><td>Intelligent Robotics Lab, Séoul, Corée du Sud</td><td>Architecture basée sur CORBA avec 4 modules : créateur, assembleur, simulateur et exécuteur de composants fonctionne sous Linux.</td></tr><tr><td>2006</td><td>RIK [Bruemmer 2006]</td><td>Idaho National Laboratory, USA</td><td>Architecture à 4 niveaux : API, couche d'abstraction, comportements de robots réactifs et délibératifs, gestion asynchrone de comportements.</td></tr><tr><td>2006</td><td>YARP [Metta 2006]</td><td>LIRA-Lab, DIST, Univ. of Genova, Italie et MIT, USA</td><td>Support de communication interprocessus, traitement d'images, hiérarchie de classes et réutilisation du code sur plateformes matérielles variées. Orienté robotique humanoïde. Implémentation sous Windows, Linux et QNX6.</td></tr><tr><td>2006</td><td>Player [Kranz 2006]</td><td>Université de Munich, Allemagne</td><td>Les atouts de Player sont le serveur de devices, les langages de programmation supportés, le protocole de transport basé sur les sockets, la modularité et l'implémentation en open-source.</td></tr><tr><td>2006</td><td>Miro [Kruger 2006]</td><td>Chemnitz University of Technology, Allemagne</td><td>Architecture distribuée, orientée objet, destinée à favoriser l'intégration de logiciels hétérogènes, la modularité et la portabilité des applications robotiques. Basé sur CORBA.</td></tr><tr><td>2007</td><td>Marie [Côté 2007]</td><td>Université de Sherbrooke, Canada</td><td>Environnement logiciel intégré pour la robotique mobile et autonome. Créé en C++ Communication basée sur ACE (Adaptive Communication Environment) et sur un composant logiciel médiateur appelé Mediator Design Pattern (MDP) permettant aux composants logiciels de se connecter.</td></tr><tr><td>2008</td><td>OpenRDK [Calisi]</td><td>Universita di Roma, Italie</td><td>Architecture multi-processus associée à un partage de données et une communication inter-modules de type tableau noir. Implémentation sous Linux, OS X.</td></tr><tr><td>2008</td><td>MRDS [Johns 2008]</td><td>Microsoft, USA</td><td>Middleware sous Windows avec 4 composants : un runtime d'exécution (CCR), des services logiciels décentralisés (DSS), un langage de programmation visuel (VPL) et un langage de programmation visuel (VSE).</td></tr><tr><td>2009</td><td>SmartSoft [Schlegel 2012]</td><td>University of Applied Sciences, Ulm, Allemagne</td><td>Architecture basée modèle permettant de créer le squelette du code applicatif à partir du modèle.</td></tr></tbody></table>
<table><thead><tr><td>Publ.</td><td>Intergiciel</td><td>Laboratoire</td><td>Architecture et caractéristiques</td></tr></thead><tbody><tr><td>2009</td><td>OPROS<br/>[Jang 2010]</td><td>IT Convergence<br/>Technology<br/>Research Lab.,<br/>Daejeon, Corée du<br/>Sud</td><td>La plateforme de composants de robots propose un modèle de composants, un outil de création de composants, et un moteur d'exécution de composants.</td></tr><tr><td>2010</td><td>Aseba<br/>[Magnenat 2011]</td><td>EPFL, Suisse</td><td>Architecture distribuée de contrôle basée évènements pour les robots complexes. Différence avec les autres middlewares : temps-réel dur et implémentation possible sur microcontrôleurs.</td></tr><tr><td>2010</td><td>OpenJAUS<br/>[Galluzzo 2010]</td><td>Département de la<br/>Défense, USA</td><td>Architecture pour les systèmes sans pilotes. Standard de communication ouvert pour soutenir l'interopérabilité des systèmes robotiques dans l'armée. Le SDK OpenJAUS est un ensemble de bibliothèques C/C++ qui fournit une interface de programmation abstraite (API).</td></tr><tr><td>2010</td><td>ORCCAD<br/>[Arias 2010]</td><td>Inria, France</td><td>Conception de contrôleurs de robots basée sur la théorie du contrôle et des évènements discrets.</td></tr><tr><td>2010</td><td>MRPT<br/>[Claraco 2010]<br/>[Rodríguez 2016]</td><td>Machine<br/>Perception &<br/>Intelligent<br/>Robotics Lab.,<br/>Univ. of Malaga,<br/>Espagne</td><td>Librairie dédiée à la robotique mobile aujourd'hui intégrée à l'intergiciel ROS.</td></tr><tr><td>2010</td><td>ROS<br/>[Cousins 2010]</td><td>Stanford Artificial<br/>Intelligence<br/>Laboratory, USA</td><td>ROS est aujourd'hui le middleware de référence avec 3 points forts : la communication inter-composants, des outils intégrés pour le développeur, un grand nombre de librairies disponibles.</td></tr></tbody></table>
<table><caption>TABLE 1.3 – Résumé des différents frameworks de robotique, d'après [Calisi]</caption><thead><tr><td>Intergiciel</td><td>Concurrence</td><td>Partage d'information</td><td>Outils</td><td>Usages</td></tr></thead><tbody><tr><td>Orocos</td><td>Callbacks, threads</td><td>Ports de données sans verrouillage (CORBA)</td><td>Surveillance à distance, journalisation</td><td>Composants bas niveau</td></tr><tr><td>Orca</td><td>Processus</td><td>ICE</td><td>Surveillance à distance, journalisation</td><td>Robots mobiles</td></tr><tr><td>CARMEN</td><td>Processus</td><td>IPC</td><td>Journalisation, visualisation</td><td>Cartographie et navigation</td></tr><tr><td>OpenRTM</td><td>Threads</td><td>CORBA</td><td>GUI de configuration</td><td>Robotique générale</td></tr><tr><td>MRDS</td><td>Processus</td><td>HTTP/DSSP via DSS</td><td>Simulateur 3D</td><td>Robotique générale</td></tr><tr><td>Player</td><td>Serveur de threads</td><td>Client / serveurs, propriétaire sur TCP</td><td>Simulateurs 2D et 3D</td><td>Composants bas niveau</td></tr><tr><td>Clarity</td><td>Threads et processus</td><td>basé sur ACE</td><td>-</td><td>Spatial</td></tr><tr><td>MARIE</td><td>Processus</td><td>Basé sur ACE, ouverte sur protocoles tiers</td><td>GUI de configuration</td><td>Connexion entre frameworks</td></tr><tr><td>MIRO</td><td>Processus</td><td>CORBA</td><td>Journalisation</td><td>Robots mobiles</td></tr><tr><td>OpenRDK</td><td>Threads</td><td>Mémoire partagée, TCP / UDP propriétaire</td><td>Surveillance à distance, journalisation</td><td>Robots mobiles</td></tr></tbody></table>
<table><caption>TABLE 1.4 – Comparaison des plateformes logicielles pour la robotique, d'après [Jang 2010].</caption><thead><tr><th>Intergic.</th><th>Open source</th><th>OS</th><th>Appel RPC</th><th>Env. simu.</th><th>Tol. fautes</th><th>Temps-réel</th></tr></thead><tbody><tr><td>Orocos</td><td>Oui</td><td>Linux</td><td>Oui</td><td>Non</td><td>Non</td><td>Oui</td></tr><tr><td>MRDS</td><td>Non</td><td>Win</td><td>Oui</td><td>Oui</td><td>Non</td><td>Non</td></tr><tr><td>Player</td><td>Oui</td><td>Win<br/>Linux</td><td>Non</td><td>Oui</td><td>Non</td><td>Non</td></tr><tr><td>MARIE</td><td>Oui</td><td>Linux</td><td>Oui</td><td>Oui</td><td>Non</td><td>Non</td></tr><tr><td>MIRO</td><td>Oui</td><td>Linux</td><td>Oui</td><td>Non</td><td>Non</td><td>Non</td></tr><tr><td>RT-Middle.</td><td>Oui</td><td>Win<br/>Linux</td><td>Oui</td><td>Non</td><td>Non</td><td>Non</td></tr><tr><td>ROS</td><td>Oui</td><td>Linux</td><td>Oui</td><td>Oui</td><td>Non</td><td>Non</td></tr><tr><td>OPRoS</td><td>Oui</td><td>Win<br/>Linux</td><td>Oui</td><td>Oui</td><td>Oui</td><td>Non</td></tr></tbody></table>

<table><caption>TABLE 1.5 – Comparaison d'intergiciels de référence selon [Chitic 2018], partie 1 : architecture.</caption><thead><tr><th>Intergiciel</th><th>Overhead</th><th>Vendor locking</th><th>Robustness to failures</th></tr></thead><tbody><tr><td>Player</td><td>+</td><td>Linux Windows</td><td>+</td></tr><tr><td>ROS</td><td>+</td><td>Ubuntu Debian<br/>Windows MacOS</td><td>+</td></tr><tr><td>Miro</td><td>- CORBA</td><td>Linux</td><td>+</td></tr><tr><td>MRDS</td><td>- DDS et CCR</td><td>Windows</td><td>+</td></tr><tr><td>MARIE</td><td>- composants<br/>additionnels</td><td>Linux</td><td>+</td></tr><tr><td>Orca</td><td>- ICE</td><td>Linux</td><td>+</td></tr><tr><td>CARMEN</td><td>-</td><td>Red Hat SuSE</td><td>+</td></tr><tr><td>Pyro</td><td>-</td><td>Linux</td><td>-</td></tr></tbody></table>
<table><caption>TABLE 1.6 – Comparaison d'intergiciels de référence selon [Chitic 2018], partie 2 : infrastructure.</caption><thead><tr><th>Intergiciel</th><th>Management & monito-ring</th><th>Multi-robot coordination services</th><th>Scheduled operations and task services</th><th>Durable data storage services</th><th>Communication</th></tr></thead><tbody><tr><td>Player</td><td>~</td><td>+</td><td>~</td><td>~</td><td>~</td></tr><tr><td>ROS</td><td>+</td><td>+</td><td>~</td><td>+</td><td>+</td></tr><tr><td>Miro</td><td>-</td><td>+</td><td>~</td><td>~</td><td>~</td></tr><tr><td>MRDS</td><td>+</td><td>+</td><td>~</td><td>~</td><td>+</td></tr><tr><td>MARIE</td><td>~</td><td>+</td><td>+</td><td>~</td><td>~</td></tr><tr><td>Orca</td><td>-</td><td>+</td><td>~</td><td>~</td><td>~</td></tr><tr><td>CARMEN</td><td>-</td><td>-</td><td>~</td><td>~</td><td>~</td></tr><tr><td>Pyro</td><td>~</td><td>+</td><td>~</td><td>~</td><td>~</td></tr></tbody></table>

<table><caption>TABLE 1.7 – Comparaison d'intergiciels de référence selon [Chitic 2018], partie 3 : usages.</caption><thead><tr><th>Intergiciel</th><th>Deployment and life cycle</th><th>Programming model</th><th>Code and data integration services</th><th>Extension points and interfaces</th></tr></thead><tbody><tr><td>Player</td><td>~</td><td>~</td><td>+ déplacement des composants pendant l'exécution</td><td>+ accès par API</td></tr><tr><td>ROS</td><td>+ Catkin Gazebo</td><td>+ programmation synchrone et asynchrone</td><td>+ roslaunch rosrun</td><td>+</td></tr><tr><td>Miro</td><td>+ compilateur IDL Gazebo</td><td>- CORBA</td><td>~</td><td>+</td></tr><tr><td>MRDS</td><td>+ Visual Studio</td><td>+ C#</td><td>+ VPL</td><td>+</td></tr><tr><td>MARIE</td><td>-</td><td>~</td><td>+</td><td>+</td></tr><tr><td>Orca</td><td>+ CMake</td><td>+ plusieurs langages de programmation</td><td>~</td><td>+</td></tr><tr><td>CARMEN</td><td>~</td><td>~</td><td>~</td><td>+</td></tr><tr><td>Pyro</td><td>+ Gazebo</td><td>~</td><td>+</td><td>+</td></tr></tbody></table>
1.4 Présentation de trois middlewares emblématiques

Les trois middlewares retenus Orocos, RT-Middleware et ROS rassemblent parmi les midd-
lewares présentés précédemment une large communauté de chercheurs au niveau international
et ils sont emblématiques dans leur conception et dans leur philosophie des enjeux associés à
leur démarche de développement. Les fondateurs de ces middlewares montrent également la dy-
namique des acteurs internationaux impliqués sur ces sujets, en Europe pour Orocos, au Japon
pour RT-Middleware, aux Etats-Unis pour ROS avec l'objectif de fédérer une large communauté
au-delà des laboratoires fondateurs de ces middlewares.

1.4.1 Orocos

Le projet Orocos [Bruyninckx 2001], [Garcia 2013] est né en 2000 avec le principe original de développer un environnement logiciel gratuit permettant de contrôler les robots. La motivation de Herman Bruyninckx, à l'origine du projet, était de faciliter l'utilisation des logiciels de contrôle spécifiques à chaque robot. Le projet a été développé en partenariat avec trois partenaires académiques : la KU (Katholieke Universiteit) à Louvain en Belgique, le LAAS (Laboratoire d'Analyse et d'Architecture des Systèmes) à Toulouse en France et enfin l'Institut Royal de Technologie KTH (Kungliga Tekniska högskolan) à Stockholm en Suède.

Orocos a été développé pour offrir les caractéristiques suivantes :

— un environnement open source,

— un environnement flexible et modulaire,

— un environnement facile à prendre en main,

— un environnement indépendant des constructeurs de robot.

Orocos [Bruyninckx 2003] s'appuie sur le standard ORB, propre aux middlewares basés sur CORBA pour assurer la communication entre plusieurs composants logiciels. Pour construire une application robotique, Orocos s'appuie ainsi sur quatre bibliothèques C++ et une boîte à outils :

— le Real-Time Toolkit qui fournit l'infrastructure et les fonctionnalités pour construire une application robotique en C++;

— la librairie KDL (Kinematics and Dynamics Library) qui gère les calculs cinématiques et dynamiques sur des chaines cinématiques en temps réel,

— la librairie OCL (Orocos Component Library) qui fournit des composants de commande prêts à l'emploi,

— la librairie BFL (Bayesian Filtering Library) qui fournit des fonctions de filtrage comme les filtres de Kalman et les filtres à particules,

— La librairie rFSM (Reduced Finite State Machine), une implémentation de machines à états finis en langage de scripts Lua.

Une application robotique basée sur Orocos est ainsi construite en agrégeant des composants logiciels et en définissant les modes d'interaction de ces composants. La figure 1.13 illustre l'architecture d'un composant logiciel de la librairie OCL. Le composant résultant est instancié et exécuté via un moteur d'exécution. Le fonctionnement du moteur d'exécution s'appuie sur la lecture de messages gérés au sein d'une file d'attente et sur le statut de la tâche implémentée grâce à la classe TaskContext. Cette classe gère le composant logiciel sous forme de tâche depuis sa configuration basée sur la lecture d'un fichier XML, jusqu'à son exécution et son arrêt. La figure
1.13 résume les communications intercomposants qui permettent de construire une application basée sur Orocos en exploitant un modèle de communication utilisant CORBA.

<figure><img src="image_19.png" /><figcaption>FIGURE 1.13 – Gestion de composants logiciels sous Orocos. Haut : architecture d'un composant logiciel, bas : classe `TaskContext`, gestion de la tâche associée au composant.</figcaption></figure>
Un point fort d'Orocos est le fait qu'il s'appuie sur un standard de communication qui exploite CORBA, ce qui offre la possibilité de mettre en œuvre des communications synchrones entre les composants d'une application logicielle distribuée.

<figure><img src="image_20.png" /><figcaption>FIGURE 1.14 – Architecture d'une application robotique sous Orocos.</figcaption></figure>

La construction d'une application temps réel distribuée sur plusieurs cibles est possible avec Orocos. Elle requiert d'implémenter Orocos en exploitant d'une part, l'extension Xenomai sous Linux pour obtenir des fonctionnalités temps réel dur et d'autre part, des bus de communication temps réel entre les cibles concernées. Pour autant, les seuls exemples proposés dans la littérature relative à Orocos sont basés sur une communication UDP ou TCP/IP, ce qui ne permet pas de garantir du déterminisme temporel.

Le projet Orocos était initialement financé en 2001 avec le soutien d'un projet européen. A la fin du projet en 2003, une version d'Orocos avec un contrôle simplifié de la position et de la vitesse d'un bras manipulateur composé de 6 degrés de liberté était disponible. L'Institut KTH a continué ce développement par la suite en développant ORCA. La différence entre ORCA et Orocos réside dans le fait qu'ORCA s'appuie sur le middleware ICE (Internet Communication Engine) [Henning 2004] en lieu et place de CORBA, jugé trop difficile à mettre en œuvre et moins ouvert en termes de programmation [Henning 2008]. Orocos a néanmoins continué à être utilisé et mis en œuvre pour accompagner le développement des applications logicielles robotiques du LAAS.

Il est important de noter qu'aujourd'hui Orocos peut être intégré à ROS, ce qui contribue à pérenniser les développements existants sous Orocos auprès d'une communauté plus large. En effet, les deux middlewares montrent un certain nombre de similitudes dans leurs concepts. Une couche de translation permet ainsi de faire le pont entre les concepts et caractéristiques associées propres aux deux middlewares comme illustré sur la table 1.8. Les dernières mises à jour à ce sujet datent de 2020.
<table><caption>TABLE 1.8 – Concepts communs entre Orocos et ROS.</caption><thead><tr><td>Concept</td><td>Fonctionnalité Orocos</td><td>Fonctionnalité ROS</td></tr></thead><tbody><tr><td>Communication par flux de données</td><td>Data ports</td><td>Topics</td></tr><tr><td>Terminal de données sortantes</td><td>Output port</td><td>Publisher</td></tr><tr><td>Terminal de données entrantes</td><td>Input port</td><td>Subscriber</td></tr><tr><td>Service</td><td>Operation</td><td>Service</td></tr><tr><td>Action</td><td>Action</td><td>Action</td></tr><tr><td>Structure de données</td><td>Typekit</td><td>Message</td></tr><tr><td>Variables partagées</td><td>Property, attribute, constant</td><td>Parameter</td></tr><tr><td>Entité de calcul</td><td>Orocos process, component</td><td>Node</td></tr></tbody></table>

### 1.4.2 RT-Middleware

RT-Middleware (RT pour Robot Technology) [84] est issu du projet NEDO (New Energy and industrial technology Development Organisation) initié en 2002 avec le soutien de l'industriel Matsushita et de la JARA (JApan Robot Association). Dans ce contexte, il visait à adresser aussi bien une utilisation industrielle, qu'une utilisation plus académique.

Comme Orocos, il s'appuie sur le modèle CORBA. RT-Middleware est d'abord une plate-forme commune pour les robots, basée sur la technologie des objets distribués. Le développement d'une application robotique s'appuie ainsi sur la création, la gestion de composants logiciels en interaction nommés RT-components. Les objectifs de RT-middleware restent identiques à ses concurrents, il s'agissait de démocratiser l'utilisation de robots grâce à des développements efficaces et facilités. Sa force réside dans sa modularité et sa capacité à être utilisé sur différentes plateformes.

Pour ce faire, RT-Middleware s'appuie sur une architecture hiérarchisée à trois niveaux pour la gestion des composants matériels. Le plus bas niveau concerne les moteurs, les capteurs et les contrôleurs. Le niveau intermédiaire concerne les systèmes de vision et les algorithmes de traitement associés, les robots manipulateurs et les robots mobiles. Le niveau le plus élevé concerne une cellule complète telle que par exemple, un robot humanoïde avec ses capteurs proprioceptifs et un système de vision.

Au sein d'RT-Middleware, la gestion des éléments robotiques, tels que les actionneurs, est affectée à des composants nommés RT-component, et l'ensemble de la gestion du système robotique est construite en connectant ces composants. Cette architecture distribuée aide les développeurs à réutiliser les éléments robotiques et ainsi à augmenter la fiabilité du système robotique avec des objets de référence pour chaque composant (actionneur, capteur, robot...).

Le cœur de RT-Middleware réside dans l'architecture du composant RT-Component illustrée sur la figure 1.15. On note que chaque composant RT-Component a un port entrées-sorties pour communiquer avec les autres composants. Chaque port a un type spécifique et les ports qui ont le
<figure><img src="image_21.png" /><figcaption>FIGURE 1.15 – Le composant RT-Component sous RT-Middleware.</figcaption></figure>

même type peuvent être connectés entre eux. Le fonctionnement d'un composant RT-Component est également géré par une machine d'état interne. On note ainsi les états du composant suivants : CREATED, INACTIVE, ACTIVE et ERROR. Ces états et le comportement du composant sont contrôlés à chaque instant par le contexte d'exécution propre à chaque développement robotique.

La dernière extension de RT-Middleware est OpenRTM-aist. Il s'agit d'une plate-forme logicielle développée sur la base du standard RT-middleware. OpenRTM-aist a été développée par le National Institute of Advanced Industrial Science and Technology qui a contribué également à la définition du standard RT-middleware au Japon. La dernière version stable disponible écrite dans les langages de programmation C++, Java, Python a été mise à jour en 2019. Elle est disponible sous Windows, Linux, macOS, VxWorks, TOPPERS(ITRON), QNX.

### 1.4.3 ROS

Le middleware ROS est aujourd'hui le middleware qui fédère la plus large communauté au niveau national et international. Il se décline en deux versions ROS 1.0 et ROS 2.0.

#### 1.4.3.1 ROS 1.0

ROS est l'acronyme de Robot Operating System; il a été initialement développé dès 2007 par Stanford Artificial Intelligence Laboratory dans le cadre du projet Stanford AI Robot STAIR. A partir de 2008, la société américaine Willow Garage poursuit le développement de ROS pour accompagner le développement du robot mobile collaboratif PR2 [104]. Le succès de ROS, midd-
leware open source et gratuit est directement lié à la communauté importante de contributeurs qui l'utilisent et contribuent à son développement.

Comme évoqué précédemment, ROS offre quatre points clés à l'origine de son succès :

- la communication inter-composants, c'est-à-dire la possibilité de connecter de nombreux composants logiciels en exploitant des nœuds, quelle que soit la répartition des nœuds sur le réseau;

- les outils de développement : ROS offre de nombreux outils d'analyse, de débogage, et d'affichage pour construire une application robotique (l'interface graphique 3D rviz pour afficher un environnement robotique, une carte de navigation, l'interface graphique rqt_graph pour analyser le graphe d'applications et les flots de données, rosbag pour rejouer des séquences topics, rqt une interface de contrôle incrémentale, ...);

- les librairies disponibles : ROS propose aussi bien des librairies pour la vision, que pour la construction d'environnements, la planification de mouvements, la planification de tâches ou le contrôle;

- la communauté très importante et grandissante des utilisateurs et contributeurs.

ROS s'appuie sur trois concepts fondateurs illustrés sur la figure 1.16 :

- les Nodes ou nœuds : un node est un exécutable qui utilise ROS pour communiquer avec d'autres nodes;

- les Topics : les nodes peuvent publier des messages sur un topic, aussi bien que souscrire à un topic pour recevoir des messages;

- ROSMaster : c'est le processus cœur, il comprend un serveur de noms et permet de mettre les différents nœuds en contact pour qu'ils puissent communiquer.

<figure><img src="image_22.png" /><figcaption>FIGURE 1.16 – Schéma de fonctionnement de ROSMaster.</figcaption></figure>

Si on fait l'analogie avec les middlewares de type ORB (section 1.3.1.2), ROSMaster joue le rôle de broker ; de ce fait, la configuration réseau est simple et ne nécessite pas de spécifier une adresse IP ou un port pour faire interagir deux nœuds ensemble.

Pour illustrer l'implémentation des nœuds qui implémentent les programmes dans une application robotique, on peut citer l'exemple du pilotage d'un robot mobile : un nœud pourra être affecté à la perception avec la gestion du scrutateur laser, un nœud pourra assurer le contrôle des moteurs, un nœud pourra assurer la reconstruction de l'environnement...

La communication entre les différents nœuds peut être réalisée à l'aide de messages et de topics de manières asynchrone. Un message est simplement une structure et les types standards
de variables sont supportés (float, integer, boolean, ...). La communication se fait alors sur le principe publish/subscribe comme pour les middlewares de type MOM (section 1.3.1.3). Un nœud qui partage l'information la publie sur un topic, puis si un nœud est intéressé par cette dernière, alors il s'abonne à ce topic. Plusieurs nœuds peuvent publier ou s'abonner sur un même topic. Les nœuds publiant l'information ne savent pas à quel nœud bénéficieront ces données.

<figure><img src="image_23.png" /><figcaption>FIGURE 1.17 – Communication entre nœuds sous ROS : services et topics.</figcaption></figure>

Un autre moyen de communiquer entre deux nœuds s'appuie sur les services, ce qui permet d'installer une communication synchrone entre nœuds. Contrairement aux topics qui sont un moyen de communication flexible, les services fonctionnent sur un principe de question/réponse et permettent d'échanger des données uniquement entre deux nœuds. La figure 1.17 illustre ces principes propres à la communication sous ROS.

### 1.4.4 ROS 2.0

ROS 2.0 [KAY et al., 2016] a été développé depuis 2007 pour répondre à certaines limites de ROS 1.0, concernant notamment :

- la mise en oeuvre simultanée de plusieurs robots en s'appuyant sur des standards;

- la possibilité de gérer un fonctionnement temps réel dur inter-processus et inter-machines;

- la robustesse et la qualité des distributions ou comment passer du développement en laboratoire à des applications dans le monde réel.

Pour répondre à ces nouvelles contraintes, ROS 2.0 a totalement modifié sa manière de communiquer. ROS 2.0 s'appuie ainsi sur le middleware DDS (Data Distribution Service); DDS permet d'assurer le transport sur un principe publish/subscribe similaire à ROS 1.0. Toute-fois ce standard géré par l'OMG (Object Management Group) est évolutif, temps réel fiable et interopérable. Il est en l'occurrence utilisé sur Android [Computing 2012]. Avec ces modifications importantes au niveau de la communication, il était difficile pour les développeurs de faire évoluer simplement ROS 1.0 vers ROS 2.0 en conservant la compatibilité ascendante en raison des modifications structurelles requises. ROS 2.0 n'est donc pas compatible avec ROS 1.0. Pour terminer cette présentation de ces trois middlewares de référence nous avons établi le tableau de la figure 1.9 qui reprend leurs principales caractéristiques.
<table><caption>TABLE 1.9 – Tableau de synthèse, comparaison des principaux intergiciels.</caption><thead><tr><th>Intergiciel</th><th>Techno. com.</th><th>Temps-réel dur</th><th>Installation et développement</th><th>Structure du projet</th></tr></thead><tbody><tr><td>RT-Middleware</td><td>CORBA</td><td>non</td><td>Nécessite RTC-Daemon pour la gestion des composants RTC, programmation en C++, Java ou Python</td><td>Trois couches :<br>1 moteurs, capteurs<br>2 vision, traitement d'image<br>3 modélisation robot</td></tr><tr><td>Orocos</td><td>CORBA</td><td>oui (si Xenomai)</td><td>Orogen (langage pour la gestion des composants). Nécessite RTT pour la gestion des composants avec langage de script</td><td>Trois bibliothèques (composants, cinématique et dynamique, filtres bayésiens).</td></tr><tr><td>ROS</td><td>MOM RPC</td><td>non</td><td>Nécessite ROS-Run pour la gestion des nodes et topics. Programmation C++, Java, Python</td><td>12 versions, 7 versions non maintenues, 1600 packages et modules (robots, périph., capteurs, planification)</td></tr><tr><td>ROS 2.0</td><td>MOM RPC</td><td>oui (si Xenomai)</td><td>Nécessite ROS-Run pour la gestion des nodes et topics. Programmation C++, Java, Python.</td><td>Nombre de packages limité.</td></tr></tbody></table>

### 1.4.5 Limites de la communication basée sur ROS pour le contrôle multirobot

Pour valider notre choix de développer une méthodologie de développement alternative à l'usage d'un middleware nous avons évalué les performances de l'intergiciel ROS dans le contexte des travaux menés dans l'équipe RoBioSS : le contrôle-commande multiaxe étendu au contrôle multirobot [Fischer 2019].

Dans de nombreuses applications robotiques, ROS est généralement implémenté sur des PC standards avec des systèmes d'exploitation non temps réel. Il nous a semblé utile de chercher les limites de cette architecture. La version testée du middleware était ROS INDIGO sous le système d'exploitation Linux Ubuntu 14.04 sur un PC Intel Quad Core i7 (CPU M620 2.7GHz, 4Go RAM). Pour évaluer la faisabilité du contrôle dynamique multi-robots avec ROS, nous avons conçu un dispositif expérimental comprenant deux robots et des réseaux à haut débit basés sur Ethernet. Un haut niveau de coordination est nécessaire pour assurer le déterminisme temporel et la robustesse d'une cellule multirobot. Pour notre évaluation, nous avons utilisé les dispositifs suivants (figure 1.18) :

- Composant 1 : un PC industriel (B&R Automation PC910) qui contrôle un robot Comau Racer 3 et ses périphériques (préhenseur et capteurs) via le bus de terrain POWERLINK;

- Composant 2 : un PLC industriel (B&R Automation X20CP1586) qui contrôle un robot Kuka iiwa équipé d'un bus de terrain EtherCAT.

L'objectif du test était de connecter ces deux composants complexes via l'intergiciel ROS afin
qu'ils partagent leurs états respectifs à une fréquence adaptée à la coopération : des valeurs objectif de 2ms et 20ms ont été choisies.

<figure><img src="image_24.png" /><figcaption>FIGURE 1.18 – Architecture utilisée pour l'évaluation de la communication ROS.</figcaption></figure>

### Communication basée sur ROS
Pour mesurer la cohérence de la communication, nous avons choisi une application échangeant des données à un seul nombre entier : le composant 2 a besoin de connaître en permanence l'état d'un capteur associé au composant 1. Le composant 1 envoie périodiquement les données d'un capteur au composant 2 par le biais de nœuds et de topics ROS. Le composant 2 reçoit les données du capteur (points rouges sur la figure) et le temps de transfert est évalué. Les essais menés avec ROS ont révélé le fait que la communication entre les deux composants n'est pas déterministe quelle que soit la période. De plus, certaines données sont perdues si la fréquence d'échange est élevée.

Pour évaluer ROS2, nous avons utilisé la même architecture : un nœud par composant. Dans notre cas, le premier nœud reçoit des données et les publie sur le topic. Le second s'abonne au sujet et envoie des données via la communication UDP. A une période de 2ms, aucun message n'est perdu mais certains échanges présentent une période de plusieurs périodes.

Ces essais, réalisés en 2019 au moment de la mise en service de ROS2, ne sont certainement plus représentatifs du niveau de performance actuel de l'intergiciel. [Park 2020] a, par exemple, évalué les améliorations obtenues par le passage de ROS à ROS2 installés sur des distributions Linux avec le patch Preempt RT, qui modifie le système d'ordonnancement des tâches du système d'exploitation. Les auteurs mesurent une faible latence de nœuds ROS2 exécutés périodiquement et un respect de la priorité des tâches compatible avec leur application. Cependant, le développement soutenu du framework logiciel ros2_control montre qu'il est nécessaire d'appeler beaucoup d'attention au développement de tâches de contrôle-commande pour lesquelles les exigences de comportement temps-réel sont essentielles. Plus récemment, [Varillon 2021] propose
la création d'une bilbiothèque complémentaire nommée *Corail* qui attribue aux tâches ROS2 un comportement déterministe. Cette bibliothèque prend en charge la création des fils d'exécution (threads), leur synchronisation et le respect des priorités entre tâches.

L'intergiciel ROS2 est aujourd'hui l'intergiciel robotique de référence, il est adapté à un grand nombre d'applications robotiques en proposant un très grand nombre de services, aussi bien en termes de composants matériels compatibles, qu'en termes d'algorithmes disponibles. Cependant, le cahier des charges retenu pour l'environnement logiciel de nos dispositifs, présenté dans le chapitre suivant, nous a conduit à choisir une stratégie différente.

## 1.5 Vers un environnement logiciel intégré de contrôle multiaxe

Comme pour ROS, le succès d'une nouvelle proposition d'environnement logiciel pour le contrôle en robotique dépendra de sa capacité à pouvoir le transférer hors du laboratoire au près d'une large communauté. Plus précisément nous souhaitons, contribuer au développement d'applications de contrôle de machines multiaxes.

A la différence des intergiciels évoqués, nous préférerons utiliser le terme d'environnement logiciel intégré pour le contrôle multiaxe. L'idée centrale est de placer le contrôle-commande robotique au plus près des contrôleurs de mouvement, sur des cibles dont le comportement déterministe est garanti.

Dans [Gerkey 2002], les auteurs développent MURDOCH, une nouvelle méthode d'allocation dynamique des tâches basée sur le principe « publish/subscribe » déjà évoqué, et ils optimisent le temps d'exécution des tâches. Dans [Sandholm 1993] et [Ramos 1996], l'importance de la gestion des contraintes de temps avec l'utilisation du protocole Contract Net est soulignée. Nous pensons comme les auteurs qu'il est nécessaire de garantir le temps d'achèvement et une communication robuste pour obtenir une coopération entre des robots opérant dans des environnements dynamiques. A titre d'exemple, une méthode d'allocation dynamique des tâches pour des groupes de robots [Parker 1998] ne sera pas assez efficace pour assurer un haut niveau de synchronisation et un comportement déterministe si les robots ne mettent pas en œuvre un échange de données en temps réel ou si leurs contrôleurs ne donnent pas un accès en temps réel aux boucles de contrôle de bas niveau (boucles de contrôle de position, de vitesse ou de couple). L'objectif de notre proposition est d'unifier l'accès aux ressources des robots à partir du contrôleur industriel de la cellule robotique.

Actuellement, la programmation des machines industrielles repose sur la norme IEC 61131 de programmation des automates qui est une alternative à l'utilisation extensive de langages propriétaires pour chaque marque de robot. L'efficacité et la robustesse des logiciels de contrôle des machines et des processus sont également accrues par une communication en temps réel entre les contrôleurs de mouvement et les contrôleurs de robot. Malheureusement, le protocole Ethernet temps réel dur n'est pas une option disponible sur la plupart des armoires de commande des principaux fabricants de robots industriels.

Il s'agit ainsi de trouver un compromis entre la performance, la fonctionnalité et la standardisation pour avoir une solution appropriée. Il existe trois types de stratégies de développement. La première consiste à développer des programmes étroitement couplés au matériel. Grâce à cela, de hautes performances sont attendues, mais le programme ne peut pas être réutilisé, donc le coût et le temps du prochain développement ne seront pas réduits. La seconde consiste à développer de nombreuses fonctionnalités, ce qui est utile mais au détriment de la performance ; c'est
le cas des intergiciels existants. La dernière se concentre sur la standardisation et la réutilisation
des composants du projet.

Une particularité de notre proposition est de ne pas dissocier les deux mondes que sont la robotique et l'automation ; le développement des machines multiaxes et celui des robots peuvent être abordés avec la même approche, d'autant plus qu'ils sont souvent associés, couplés au sein d'une même cellule de production. Notre proposition vise à proposer une nouvelle approche du développement des cellules de production automatisées associant robots et machines multiaxes.

Pour répondre aux enjeux et contraintes évoqués, nous choisirons d’appuyer le développement
de notre solution logicielle de contrôle multiaxe sur les caractéristiques suivantes :

- Respect et extension du standard IEC 61131. Les langages largement disponibles du standard IEC 61131-3 peuvent être complétés avec des tâches et des bibliothèques réalisées en C++ pou réaliser des composants logiciels réutilisables ;

- Respect du standard PLCopen Motion Control : ce standard fournit toutes les fonctions monoaxes utiles et permet d'utiliser des configurations matérielles de n'importe quel fabricant du monde de l'automation (Siemens, Beckhoff, Rockwell, Schneider, B&R ...) avec également une forte implication des fabricants de robots (ABB, Stäubli, Yaskawa) ;

- Usage des protocoles de communication temps réel dur [EPSG 2016] : POWERLINK IEEE 61158 et EtherCAT répondent tous deux à ces contraintes. L'utilisation de protocoles Ethernet industriels est la clé de voûte de notre proposition temps-réel. Par exemple, le standard open source POWERLNK établit une communication en temps réel, avec une période ajustable, entre les composants d'automatisation ou les CPU et il respecte le standard Ethernet IEEE 802.3 sans accès modifié au média Ethernet.

- Une implémentation possible sur une variété de plateformes :

— des machines de type PC sous Linux ou Windows,

— des automates industriels,

— des microcontrôleurs.

- Une architecture avec une distribution modulable des composants logiciels et des boucles de contrôle de bas niveau associées en fonction des ressources matérielles disponibles.

- Un mode de simulation intégré permettant de simuler le comportement réel de l'applica-
tion avant exécution.

- Un lien haute-fidélité entre machine réelle et machine virtuelle exploitant la simulation intégrée.

- La possibilité de s'interfacer facilement avec l'environnement logiciel intégré de contrôle multiaxe : cela permettra par exemple de développer des packages sous ROS permettant d'accéder aux fonctionnalités de l'application robotique développée avec notre environnement.

Avec la partie 1, nous souhaitions positionner le cadre de nos travaux dans un contexte où de
nombreux développements ont été conduits, aussi bien sur les architectures de commande d'une
manière générale, que dans le contexte des intergiciels propres au domaine de la robotique.

Nous avons pu démontrer à travers l'état de l'art proposé sur ces sujets, qu'un certain nombre
de points ne sont pas adressés aujourd'hui par les propositions existantes. L'ouverture des robots
dans un environnement de production autrefois cloisonné, avec des contraintes d'interaction
avec d'autres machines actionnées et l'humain a modifié ces dernières années, les enjeux relatifs
à l'accompagnement de la mutation de l'outil production. Les besoins de flexibilité, d'agilité
accrus associés à la sûreté de fonctionnement et la sécurisation de l'interaction nous ont amené
à proposer un nouvel environnement logiciel intégré de contrôle multiaxes que nous présentons
dans la suite de ce mémoire.

Le chapitre suivant introduit la bibliothèque *rtrmac* qui définit le modèle de composants logiciels que nous utilisons et les briques logicielles élémentaires qu'elle fournit. Je présente ensuite la démarche de création de nouveaux composants sur des exemples qui seront nécessaires pour la création de logiciels de contrôle-commande de systèmes mécatroniques.

Le troisième chapitre décrit l'extension de la bibliothèque au pilotage multiaxe de mécanismes et de robots.

Enfin, le dernier chapitre illustre l'adaptabilité de la méthode que nous avons développée sur des exemples de réalisation. Ceux-ci vont de l'informatique embarquée pour le contrôle d'un dispositif mécatronique, à l'association étroite du contrôle-commande à un jumeau numérique pour proposer une solution complète qui couvre plusieurs étapes du cycle de vie du logiciel.
# Vers un système de contrôle-commande unifié

Le domaine d'intérêt de notre étude se limite à la conception de systèmes cyber physiques partageant les caractéristiques suivantes :

- le système doit présenter un comportement déterministe en contrôlant un nombre important de sorties et en réagissant à de nombreuses entrées,

- il doit pouvoir s'intégrer dans des ensembles plus vastes, en coopérant avec d'autres systèmes ou avec des opérateurs humains et en s'intégrant dans un système d'information (supervision, gestion de ligne de production, d'usine),

- le système doit pouvoir réagir à des perturbations extérieures et interagir avec un environnement dont l'évolution doit être prise en compte,

- le système est composé de constituants électroniques et électrotechniques intégrés dans des produits industriels répondant aux exigences des standards du domaine de l'automation industrielle.

Nous présentons dans un premier temps les exigences des standards nécessaires à la mise en œuvre de notre solution de développement de systèmes de contrôle commande. Puis nous décrivons les principes de la bibliothèque logicielle qui structure nos projets logiciels. Pour terminer, je présente la méthodologie associée à cette bibliothèque. Pour cela, je crée de nouveaux d'objets logiciels qui sont utiles pour le contrôle-commande robotique présenté dans le chapitre trois.

## 2.1 État des lieux des systèmes de contrôle-commande de machines

Le choix de se placer dans le cadre d'usage des technologies de l'automation industrielle couvre un ensemble de secteurs applicatifs qui dépasse le cadre initial des machines de production de l'industrie manufacturière. En effet, on retrouve ces composants (automates programmables industriels, cartes d'entrées-sorties, contrôleurs de mouvement) dans les domaines suivants (la liste n'est pas exhaustive) :

- la production et la gestion de l'énergie,

- l'industrie navale,

- la robotique agricole, les engins de chantier et de travaux publiques,

- les parcs d'attraction,

- l'automatisation des bâtiments,

- les bancs de tests et équipements scientifiques,

- les équipements médicaux.

Toutes ces applications partagent les exigences de durabilité et de robustesse des équipements, de comportement déterministe des systèmes et donc des applications logicielles, des exigences
que ce document soit sous-titré « Securing the future of German manufacturing industry », ce concept a été adopté par le secteur industriel mondial.

Dix ans plus tard, ce travail de prospective est en train de se mettre en place et provoque des modifications importantes dans la conception et la mise en œuvre des machines et l'organisation industrielle. Cependant, l'évolution ou la migration des installations existantes semble difficile à réaliser et les sites de production présentent généralement une très forte hétérogénéité matérielle à tous les niveaux : machines, composants, logiciels et réseaux de communication.

De même, la composition des équipes techniques des bureaux d'études, de méthode et de maintenance n'a pas vraiment évolué et les compétences des acteurs de la conception, de l'exploitation et du maintien en conditions opérationnelles des outils de production est en retard par rapport à la disponibilité sur le marché de ces nouvelles technologies.

Pourtant, dès 2011, le rapport [Kagermann 2013] soulignait l'importance de la formation et de l'accompagnement des acteurs de la chaîne de production industrielle en citant :

> Industrie 4.0 will radically transform workers' job and competence profiles. It will therefore be necessary to implement appropriate training strategies and to organise work in a way that fosters learning, enabling lifelong learning and workplace-based [continuing professional development]. [...] It is likely that Industrie 4.0 will significantly transform job and skills profiles as a result of two trends. Firstly, traditional manufacturing processes characterised by a very clear division of labour will now be embedded in a new organisational and operational structure where they will be supplemented by decision-taking, coordination, control and support service functions. Secondly, it will be necessary to organise and coordinate the interactions between virtual and real machines, plant control systems and production management systems.

Dans ce contexte de pression très forte sur les organisations pour intégrer des évolutions technologiques dans des usines présentant une très grande disparité matérielle et des équipes aux compétences en cours de mutation, nous avons retenu comme contrainte de développement l'usage de composants de contrôle-commande disponibles sur tous les équipements actuels mais qui disposent de puissance de calcul suffisantes pour intégrer des algorithmes de commande issus de la recherche en robotique.

Les sections suivantes présentent les possibilités et les limites du matériel et du modèle logiciel associé à partir desquels nous proposerons notre contribution au développement de systèmes de contrôle-commande.

### 2.1.2 Des architectures matérielles hétérogènes distribuées

Les lignes de production et les machines industrielles sont des architectures distribuées selon plusieurs aspects. Elles présentent :

- une distribution spatiale des composants électroniques qui vise à rapprocher les blocs d'entrées-sorties des capteurs ou des préactionneurs pour minimiser la longueur de câblage, les risques de défaillance et les perturbations électromagnétiques

- une décomposition fonctionnelle hiérarchique depuis des fonctions « bas niveau » qui traitent les informations issues des capteurs jusqu'à des fonctions de traitement d'information au niveau d'un site de production,
— une distribution fonctionnelle entre de nombreux calculateurs et processeurs, avec, parfois des stratégies de redondance,

— une hétérogénéité entre composants de différents fournisseurs qui échangent des informations à travers plusieurs protocoles de communication.

La figure 2.1 présente deux machines dont les architectures mécaniques sont différentes d'une machine mais qui réalisent la même fonction : ranger des sacs ou des cartons en couches empilées sur une palette. L'une d'entre elles réalise la fonction de palettisation avec une partie opérative spécifique à cette tâche, la seconde exploite un robot industriel qui prend en charge la fonction technique de manipulation et de placement de chaque sac. Ces machines sont développées de façon autonome, mais sont destinées à être intégrées dans une ligne de production. Leurs parties commandes devront interagir avec celles des machines amont et aval (dans le sens du flux de production) et avec un contrôleur industriel en charge de la gestion de la ligne.

<figure><img src="image_25.png" /><figcaption>FIGURE 2.1 – Exemples de cellules de production. Gauche : palettiseur à couches CETEC, détail : intégration dans une ligne de production. Droite : palettiseur SIDEL intégrant un bras de robot sériel. (©CETEC, ©NEWTEC BAG, ©Sidel).</figcaption></figure>

Le logiciel de contrôle-commande d'une installation automatisée est réparti sur un nombre important de calculateurs et son développement est réparti entre les programmeurs de plusieurs entreprises qui prennent en charge la réalisation :

— de fonctions bas niveau intégrées dans les composants matériels,

— de fonctions de contrôle ou de mise à disposition d'information dans les sous-systèmes,

— de coordination et de gestion des modes de fonctionnement au niveau de l'intégration des sous-systèmes dans une machine ou une ligne de production,

— d'interfaçage avec les logiciels de gestion de production et de gestion d'usine.

Cette situation correspond à la décomposition traditionnelle de la pyramide de l'automation, un modèle de séparation et de description des logiciels présents dans un système de production défini par l' International Society of Automation (USA) en 1995 et porté dans la norme IEC62264-1 en . Ce modèle, illustré sur la figure 2.2 fait apparaître plusieurs niveaux qui affinent la distinction entre les couches opérationnelle (OT ou Operational Technology) et informationnelle (IT, Information Technology) :

— Niveau 0 : *Processus de production*. Ce niveau regroupe les informations échangées à haute fréquence avec la partie opérative : données provenant des capteurs et ordres adressés aux
<figure><img src="image_26.png" /><figcaption>FIGURE 2.2 – Pyramide de l'automation, d'après [Foundation 2021] et [Katti 2020].</figcaption></figure>

préactionneurs. Les traitements logiciels sont embarqués dans les cartes d'entrées-sorties ou les processeurs des contrôleurs de mouvement ou des systèmes de régulation.

- Niveau 1 : *Détection et traitement*. Les actionneurs et les capteurs du niveau 0 sont connectés à des automates programmables. Ces dispositifs exécutent périodiquement, en continu, des programmes qui traduisent le fonctionnement séquentiel attendu des équipements.

- Niveau 2 *Contrôle et supervision*. Le système SCADA, pour système de contrôle et d'ac- quisition de données se trouve à ce niveau.

- Niveau 3 *Opérations de fabrication et gestion*. À ce niveau, les fonctions de gestion sont exécutées par un service de planification. Les logiciels MES (Manufacturing Execution System) sont utilisés pour générer des ordres de production, qui permettent aux opéra- teurs des services de production, de logistique et de qualité de savoir ce qu'il faut produire et quand il faut le faire.

- Niveau 4 *Planification des activités et logistique*. Les applications logicielles de cet étage sont la planification des ressources de l'entreprise (ERP) et la gestion du cycle de vie des produits (PLM). Les informations générées et disponibles à ce niveau sont utilisées par d'autres services de l'entreprise que le service production : ressources humaines, ser- vices financiers, contrôle de gestion, achats, maintenance, par exemple. Dans le modèle traditionnel, c'est également la zone d'échange possible avec des systèmes d'information externalisés.

Ces différents niveaux sont associés à des réseaux de communication différents. Les réseaux
de la zone *operation technology* ont des exigences de robustesse aux perturbations extérieures, de garantie des temps d'échange d'information et de disponibilité de service élevée, les réseaux IT doivent s'intégrer, de façon sécurisée dans le réseau informatique de l'entreprise, fournir des bandes passantes élevées, mais avec un cadre temporel moins contraint.

La décomposition logicielle du logiciel de contrôle d'une machine est réalisée selon deux
directions :

— une répartition entre composants : machines, sous-ensembles, actionneurs ou capteurs à capacité de traitement embarquée, passerelles de communication,

— une séparation par niveaux d'abstraction qui part de la couche la plus proche du matériel pour rejoindre la gestion machine et la liaison avec l'étage de supervision et de gestion de production.

Cette fragmentation du logiciel est également associée au partage de responsabilités entre les entreprises qui fournissent les sous-ensembles, aux intégrateurs et aux clients finaux qui prennent en charge le suivi logiciel en phase de production, avec un niveau d'assistance demandée aux sous-traitants qui varie en fonction des ressources disponibles chez l'exploitant.

Sur le plan de la formation et de la culture des différents acteurs, il est possible d'effectuer une distinction entre les automaticiens qui interviennent sur le niveau machine et le service d'informatique industrielle qui prend en charge les développements logiciels à partir des composants de supervision. Cependant, avec l'évolution des pratiques et des outils accompagnant la mise en place de l'approche Industry 4.0, la frontière entre les deux approches est de plus en plus floue. Certains systèmes de contrôle-commande peuvent en effet intégrer des traitements de type « intelligence artificielle » déportés dans le cloud. Inversement, les systèmes de supervision peuvent, via les nouveaux protocoles de communication, interagir directement avec les composants matériels.

Face à la variété de composants disponibles sur le marché, le secteur de l'automation industrielle a cherché à mettre en place une possibilité d'interopérabilité, c'est-à-dire de pouvoir faire fonctionner des composants matériels de fournisseurs différents avec le minimum de développements spécifiques pour l'opérateur et sans perte de fonctionnalités. Dans le cadre de notre étude, cette recherche d'interopérabilité passe par l'usage de réseaux et de protocoles de communication standards.

2.1.2.1 Réseaux industriels temps-réel

Dans le domaine de la commande de processus à dynamique élevée, l'extension du com-
portement déterministe des logiciels exécutés sur des cibles temps-réel est obtenu par l'usage
de protocoles de communication industriels temps-réels. Pour avoir une bande passante élevée,
les protocoles modernes sont à support Ethernet. Certains protocoles propriétaires sont utilisés
pour la communication entre composants d'un même fournisseur (les réseaux X2X pour B&R
Automation ou Mechatronics pour Yaskawa), mais l'interopérabilité recherchée par les fabri-
cants de machine passe par l'usage de l'une des technologies majeures du marché, EtherCAT,
POWERLINK, SERCOS III ou PROFINET IRT. Ces solutions concurrentes utilisent des tech-
niques différentes pour surveiller et garantir la périodicité des échanges entre les composants
d'un réseau de communication. Elles ont des exigences différentes sur la topologie matérielle du
réseau, des niveaux de performances différents (en termes de robustesse aux perturbations et de
période minimale d'échange) et des gammes variables de composants qui les mettent en œuvre,
mais tous sont adaptés à la gamme d'applications couvertes par notre étude.

Pour les développements en cours dans l'équipe RoBioSS, le réseau de communication temps-réel utilisé est POWERLINK, développé initialement par B&R Automation puis par l'association EPSG (Ethernet Powerlink Standardisation Group). C'est un standard open source basé sur le protocole Ethernet classique, il n'est pas conditionné à l'usage de cartes de communication spécifiques [EPSG 2016]. Un PLC a le rôle de chef d'orchestre (ou Managing Node, dans la terminologie du standard) et organise un échange périodique d'informations avec les Controlled Nodes, les autres composants présents sur le réseau qui, dans un cycle d'échange, sont interrogés successivement et envoient une réponse accessible à tous les nœuds. Dans la bande passante complémentaire aux échanges périodiques, il est possible d'échanger des informations non prioritaires par une communication Ethernet classique. Le protocole POWERLINK, comme les autres protocoles industriels identifiés précédemment, permet également d'échanger des informations de sécurité entre composants de la chaîne de sécurité.

### 2.1.2.2 Vers un mécanisme d'échange d'informations universel ?

Dans le cadre des exigences de la mise en œuvre du concept d'Industrie 4.0, l'adoption d'un cadre d'échange d'informations entre tous les composants de la chaîne de production est impératif. Le standard retenu pour cela est OPC-UA, un ensemble de technologies dont le développement est organisé par l'association internationale OPC Foundation. Cette solution permet l'évolution du modèle de la pyramide de l'automation vers le concept d'un réseau industriel étendu, tel que présenté par OPC Foundation et illustré sur la figure 2.3.

Ce concept soutient une décomposition fonctionnelle non hiérarchisée, pour la collecte et le traitement de l'information, mais pas spécifiquement pour la partie contrôle-commande qui nécessite toujours un partage de tâches et de responsabilités clairs. Cependant, cette exigence d'accès de tous les composants matériels les place tous dans la zone d'action de l'Information Technology. Ceci rend possible l'accès direct aux informations utiles à une fonction donnée mais impose des contraintes matérielles et organisationnelles fortes en termes de cybersécurité et de partage de bande passante entre des communications dont la criticité et la période d'échange sont très variables.

Le niveau d'adoption d'OPC UA par les acteurs de l'automatisme et de l'information industrielle en fait un composant indispensable dans le cadre du développement d'un logiciel de contrôle-commande. Pour l'instant, la possibilité d'échanger des informations non temps-réel sont implémentées, ou disponibles dans de nombreux composants. L'ajout de fonctionnalités de surveillance des temps d'échanges d'information est en cours de standardisation, dans le cadre des travaux du groupe Field Exchange de la Fondation OPC. L'objectif est d'ajouter les fonctionnalités de la technologie TSN (Time Sensitive Network) dans la couche de réseau du modèle de communication pour atteindre des exigences de temps-réel dur à une période garantie d'échange d'informations entre composants de 10ms.

En complément de l'intérêt d'OPC UA pour garantir l'operérabilité des composants, cette technologie apporte également des fonctionnalités de :

- sécurité, avec l'intégration de techniques de chiffrement et d'authentification,

- extensibilité, c'est-à-dire que de nouvelles versions d'OPC-UA peuvent ajouter de nouvelles fonctions sans affecter les applications existantes. Il est également prévu de pouvoir ajouter de nouveaux protocoles de communication ou de chiffrement,
<figure><img src="image_27.png" /><figcaption>FIGURE 2.3 – Le remplacement de la pyramide de l’automation par un réseau industriel universel, d’après [Foundation 2021].</figcaption></figure>

- choix du mode de communication (client / serveur ou publish / subscribe),

- modélisation des informations et des processus. OPC UA permet d'ajouter des méta-données aux données échangées et de modéliser les processus pilotés. Le standard offre également la possibilité aux logiciels clients d'explorer et de découvrir les données acces-sibles fournies par le serveur.

Ce dernier point s'accompagne de la possibilité pour des secteurs d'activités ou des groupes de fournisseurs de développer des exigences complémentaires, appelées *Companion Specifications*. Parmi celles-ci, on peut noter *OPC UA Information Model for IEC 61131-3* rédigée avec PLCopen pour définir la communication entre PLC et *OPC UA for Robotics*, document établi avec l'association VDMA (l'association allemande qui regroupe les entreprises du secteur de la mécanique) qui vise à modéliser les fonctionnalités d'un robot industriel en vue de pouvoir l'intégrer dans un système de production quel que soit le fabricant.

### 2.1.3 Systèmes industriels temps-réel selon la norme IEC61131

Le développement de nos systèmes mécatroniques se place donc dans le cadre de l'usage des composants standards du secteur de l'automation industrielle. Les calculateurs utilisés répondent aux exigences de la norme IEC61131 qui définit les contraintes auxquelles ces composants doivent répondre et définissent un cadre logiciel qui permet de simplifier le développement des systèmes de contrôle-commande temps-réel basés sur ces architectures.
### 2.1.3.1 Exigences matérielles

Les calculateurs industriels pour le secteur de l'automation ont suivi les évolutions de l'industrie des composants électroniques tout en conservant les exigences propres à ces composants définies il y a plus de trente ans.

Un automate programmable industriel moderne présente les caractéristiques suivantes :

- une puissance de traitement élevée : les systèmes PLC modernes sont dotés de processeurs identiques à ceux des composants électroniques d'usage général,

- l'aptitude à contrôler un nombre important d'entrées-sorties via une grande variété de bus de communication,

- une conception modulaire qui permet à la fois la personnalisation des équipements et leur évolution au cours de la vie du produit,

- l'aptitude à la mise à l'échelle des installations, ce qui permet de mutualiser une grande partie du développement pour des gammes de machines différentes,

- un cadre de développement logiciel indépendant du fournisseur de matériel avec la mise à disposition impérative de plusieurs langages de programmation et la possibilité d'en proposer d'autres,

- une robustesse et une fiabilité des composants élevées, le matériel est conçu pour résister à des environnements industriels difficiles caractérisés par des perturbations électromagnétiques, des vibrations, de la poussière, des variations de température importantes,

- la mise à disposition d'outils de diagnostics intégrés, pour le développement logiciel, la mise en service et le maintien en condition opérationnelle des machines.

Les spécifications définies par la norme IEC61131 permettent des réalisations très différentes. L'exigence de comportement déterministe des calculateurs se traduit par des solutions concurrentes basées sur des versions adaptées de différents systèmes d'exploitation :

- des solutions propriétaires, comme Siemens S7 Operating System, pour les PLCs Siemens,

- VxWorks, un système temps-réel utilisé dans les applications critiques (présent sur les PLC B&R Automation),

- Linux, avec des extensions temps-réel. Ce sont des solutions qui permettent le partage de ressource entre des tâches temps-réel avec du développement logiciel généraliste (OS présents sur le matériel Keba et Bosch Rexroth, par exemple),

- Windows, avec des mécanismes préemptifs qui permettent aux tâches de contrôle d'avoir un comportement temps-réel (une partie des contrôleurs Beckhoff)

- FreeBSB, une solution alternative pour certains contrôleurs entrée de gamme Beckhoff.

Les nouveaux composants matériels permettent également d'exploiter des mécanismes d'hydroviseur et de faire cohabiter un système d'exploitation généraliste (ou GPOS, General purpose Operating System), qui va prendre en charge la gestion de l'IHM ou des fonctions IT, avec un runtime temps-réel (RTOS, Real Time Operating System) qui exécute les tâches de contrôle-commande.

Les exigences de fonctionnement des automates programmables définies dans la norme fournissent au développeur d'applications un système d'exploitation qui garantit une application déterministe des tâches et offre la possibilité d'avoir une exécution parallèle des tâches sans confier au développeur la charge de mettre en œuvre le développement de tâches concurrentes.

La figure 2.4 illustre l'exécution des tâches vue par le développeur. Il dispose de classes de tâches dans lesquelles il peut affecter les tâches résultant de la décomposition fonctionnelle du
logiciel. Ces classes de tâches sont associées à un niveau de priorité d'exécution et à une période d'exécution réglable. Le système d'exploitation fournit un ordonnanceur qui alloue le travail du processeur aux différentes tâches en fonction de leur priorité et contrôle la durée d'exécution des tâches pour garantir les périodes d'exécution exigées. En cas de charge de travail excessive, l'exécution des tâches utilisateurs s'arrête et le système redémarre. La phase d'exécution périodique est précédée d'une phase d'initialisations successives des programmes réalisée au démarrage de l'automate qui n'est pas contrainte temporellement.

L'environnement d'exécution fournit également un mécanisme unique de partage d'information entre tâches et entre les cartes d'entrées-sorties et les tâches utilisateurs. Le développeur est responsable du choix des périodes d'exécution des classes de tâches et de l'affectation des programmes aux classes de tâches en relation avec la dynamique des évènements auxquels le système automatisé doit répondre et avec la puissance de traitement du composant matériel qu'il a choisi. En échange, il bénéficie d'un cadre de développement d'applications concurrentes très simplifié.

<figure><img src="image_28.png" /><figcaption>FIGURE 2.4 – Fonctionnement multitâche d'un PLC : répartition de la charge du processeur.</figcaption></figure>

### 2.1.3.2 Cadre du modèle logiciel

Le modèle logiciel des automates programmables industriels est défini dans la partie IEC61131-3, *Automates programmables - Partie 3 : Langages de programmation*. L'élément de plus haut niveau est appelé *configuration*. Une configuration décrit la structure matérielle d'un système de contrôle commande qui contient des cartes d'entrées sorties et des ressources de traitement (automates ou PC industriels) qui sont capables d'exécuter des programmes.
Ces ressources sont utilisées par des tâches, qui invoquent l'exécution de composants logiciels. Ces derniers sont appelés Program Organization Units (POU) ou unités d'organisation de programme. La norme IEC61131-3 en définit trois types : les programmes, les blocs fonctionnels et les fonctions.

Les programmes sont les unités d'organisation de programme de plus haut niveau, ils peuvent être écrits dans n'importe lequel des langages de programmation de la norme. Chaque programme peut utiliser des fonctions et exécuter des instances de blocs fonctionnels. Les programmes sont exécutés par les tâches, ils peuvent accéder aux variables d'entrées-sorties, à des variables globales et ont leur propre espace mémoire.

Le type de POU le plus courant est le bloc fonctionnel. Il s'agit de segments de code réutilisables qui possèdent un espace mémoire qui leur est associé et qui contient des variables de portée différentes (variables d'entrée, de sortie, d'entrée-sortie et variables internes).

Les fonctions, dans le modèle logiciel des automates, sont des sous-programmes qui n'ont pas d'espace mémoire associé et qui ne peuvent retourner que l'un des types de base (booléen, entier ou nombre à virgule flottante).

La figure 2.5 présente l'un des blocs fonctionnels défini par le standard. Il s'agit du bloc temporisation retardée, TON (Timer on Delay). Il possède deux variables de type entrée et deux variables de type sortie. Il doit être appelé à chaque exécution du programme dans lequel il est utilisé. Ses variables d'entrée sont de deux types :

- PT contient l'information du délai de retard, c'est une entrée de type *paramètre* ou *asynchrone* : elle doit être définie au moins une fois ou peut être changée occasionnellement,

- IN contient l'information booléenne qui déclenche la temporisation à son activation et qui doit rester vraie jusqu'au déclenchement de la sortie. C'est une variable *synchrone* qui doit être actualisée à tous les cycles, avant l'appel du bloc fonctionnel.
<figure><img src="image_29.png" /><figcaption>FIGURE 2.5 – Interface et chronogrammes de fonctionnement du bloc fonctionnel standard TON.</figcaption></figure>

### 2.1.3.3 Démarche de structuration du développement logiciel

Comme présenté précédemment, dans le modèle logiciel de la norme IEC 61131, le principal outil d'organisation logicielle est le bloc fonctionnel. En 2017, PLCopen a publié un guide méthodologique pour la création de bibliothèques dans le secteur de l'automation. Ce document est construit à partir d'un retour d'expérience sur les différents standards préalablement publiés par l'association. Ce travail de synthèse a fait apparaître les propriétés nécessaires pour régir le comportement d'un tel composant logiciel dans le contexte d'une exécution périodique.

Les blocs fonctionnels ont vocation à être exécutés à tous les cycles de fonctionnement de la classe de tâches du programme dans lequel ils sont appelés. Ils ont naturellement deux états : un état d'inaction et un état où ils réalisent leur fonction (pour rappel, un bloc fonctionnel est semblable à une classe à une seule fonction). Ce comportement est proche de celui de l'activité associée à une tâche dont un exemple d'organisation du cycle de vie est présenté figure 2.6. Les blocs fonctionnels peuvent être activés ou désactivés. Un troisième état peut être utilement ajouté : il s'agit d'un état d'erreur où le bloc fonctionnel, bien que passé en état actif, ne peut pas réaliser la fonction qui lui est associée. Le programme, ou bloc fonctionnel, qui exécute l'instance de bloc fonctionnel en situation d'erreur peut agir sur la cause de l'erreur, désactiver le bloc fonctionnel et le réactiver.

Un aspect central du document « PLCopen compliant libraries » porte sur la définition d'interfaces unifiées pour l'activation du bloc fonctionnel et le retour d'information sur son état courant. Les premiers standards de l'association PLCopen avaient produit des solutions d'inter-faces cohérentes au sein d'un standard mais non unifiées. La figure 2.7 présente deux exemples
<figure><img src="image_30.png" /><figcaption>FIGURE 2.6 – Machines d'états du cycle de vie d'une activité [Bruyninckx 2023].</figcaption></figure>

de blocs fonctionnels. Le bloc `MC Moving Absolute` est un des blocs fondamentaux du standard PLCopen Motion Control. Il permet de réaliser un mouvement depuis une situation courante (position, vitesse, accélération) vers un point d'arrêt défini par l'entrée `Position` avec une loi de commande à vitesse et accélération saturées, définies par les valeurs des entrées `Velocity`, `Acceleration` et `Deceleration`.

<figure><img src="image_31.png" /><figcaption>FIGURE 2.7 – Exemple d'interfaces de blocs fonctionnels des standards PLCopen Motion Control [Gotha 2011] et Safety Software [PLCopen 2018].</figcaption></figure>

L'activation de l'entrée `Execute` provoque le démarrage de la fonction qui prend en charge la génération d'une consigne de position. La sortie `Busy` est mise à `True` dès que la fonction commence à être réalisée. Lorsque la destination est atteinte, `Busy` est désactivée et `Done` passe à `True`. Si un autre mouvement est requis, la sortie `CommandAborted` passe à `True`. Si une erreur se produit lors du passage des paramètres ou en cours de mouvement, la sortie `Error` s'active et un identifiant d'erreur est affecté à la sortie `ErrorID`. La remise à faux de l'entrée `Execute` fait sortir la machine d'états du bloc des états correspondants à l'activation des sorties `Done`, `CommandAborted` et `Error`.

Le bloc fonctionnel présenté comme exemple du standard PLCopen Safety est celui qui prend en charge un bouton d'arrêt d'urgence, il s'agit du bloc `SF_EmergencyStop`. L'interface du bloc fait apparaître deux types de variables, les types communs à la programmation d'automatismes,
BOOL, par exemple, et des types associés à la réalisation des fonctions de sécurité, SAFEBOOL pour
cet exemple. Les entrées Activate et Reset sont présentes dans tous les blocs du standard. L'état
de fonctionnement du bloc est décrit par les sorties Ready et DiagCode.

<figure><img src="image_32.png" /><figcaption>FIGURE 2.8 – Machine d'états générique d'un bloc fonctionnel PLCopen Safety software [PLCopen 2018].</figcaption></figure>

La figure 2.8 décrit la machine d'états générique d'un bloc fonctionnel du standard de logiciels
de sécurité. Au démarrage de la tâche qui exécute une instance de ce bloc, celle-ci est placée
dans l'état Idle et la sortie Ready s'active. La mise à vrai de l'entrée Activate passe le bloc en
situation d'initialisation et DiagCode = 8000. Si une erreur apparaît, la machine d'états passe
en état d'erreur et l'identité de l'erreur est renseignée dans la sortie DiagCode. Dans le cas
contraire, le bloc va alterner entre des états opérationnels dont dépendent les valeurs des sorties
de sécurité. La sortie DiagCode permet d'identifier l'état en cours.

Finalement, l'analyse de ces premiers standards a permis de définir un nombre fini de modèles
de comportement de blocs fonctionnels et une solution d'interface unifiée a été choisie dans la
proposition du document PLCopen Compliant Libraries.

Le comportement d'un bloc fonctionnel destiné à une application d'automatisme appartient
à l'une des deux catégories suivantes :

— un actionnement déclenché par l'activation d'une entrée : ce sont les blocs de type Edge-Trigerred (référencés par ETrig par la suite),

— une autorisation de fonctionnement accordée ou refusée par l'état d'une entrée booléenne pour les blocs de type Level-Controlled (LCon).

Dans le premier cas, l'entrée qui commande l'activation du bloc fonctionnel et le début de
la prise en charge de sa fonctionnalité est nommée Execute, dans le second cas, elle s'appelle
Enable. L'interface de sortie présente les différentes informations suivantes :

— *Busy* : le bloc fonctionnel est actif et réalise la fonctionnalité attendue,

— *Done* : si un état d'achèvement est présent, le bloc fonctionnel l'a atteint et a terminé son travail,

— *Error* : le bloc fonctionnel a rencontré une erreur pendant sa phase d'initialisation ou sa phase d'exécution et il ne travaille plus.

— dans ce cas, la sortie *ErrorId* contient une valeur entière permettant d'identifier l'erreur.

La figure 2.9 présente l'interface et la machine d'état qui régit le comportement d'un bloc de type Edge-triggered.

<figure><img src="image_33.png" /><figcaption>FIGURE 2.9 – Interface et machine d'états générique d'un bloc fonctionnel de type Edge-triggered.</figcaption></figure>

L'analyse de PLCopen a fait émerger un nombre de types de fonctionnement de base limités, toutes les fonctionnalités à développer dans un logiciel de contrôle-commande peuvent être décrites par l'un de ces modèles. Par rapport aux deux types de base (ETrig et LCon), les variantes portent sur :

— La présence d'une entrée d'interruption : *Abort*, qui après un état transitoire *ABORTING*, place le bloc fonctionnel en arrêt dans l'état *ABORTED* jusqu'à ce que l'entrée *Execute* soit remise à FALSE.

— La possibilité de limiter la durée de l'état actif avec l'entrée *TimeOut*. Si le bloc fonctionnel reste dans l'état *EXECUTING* plus longtemps que cette durée, il passe en *ERROR* avec une erreur de type *TimeOut*.

— La possibilité de limiter le temps d'exécution de la méthode cyclique du bloc fonctionnel
à la durée définie dans l'entrée `TimeLimit` pour contrôler la charge demandée au processeur : si l'exécution du bloc fonctionnel dure plus longtemps, elle doit s'interrompre pour reprendre au cycle suivant.

La figure 2.10 présente deux exemples de variantes de modèles de fonctionnement. Les éléments en rouge correspondent aux modifications par rapport aux modèles ETrig et LCon de base. Le premier bloc possède l'entrée `Abort` qui permet d'interrompre son fonctionnement. Le second ajoute les fonctionnalités de limite du temps d'exécution au cours d'un cycle (la condition `Time limit`) et de surveillance du temps de traitement de la fonctionnalité (`Time out`).

<figure><img src="image_34.png" /><figcaption>FIGURE 2.10 – Interfaces et machines d'états génériques de blocs fonctionnels de types Edge-trigerred with abort et Level-controlled with time limit and time out.</figcaption></figure>

### 2.1.4 Standardisation logicielle de la génération de mouvement

Le développement des logiciels de pilotage d'axes par des contrôleurs de mouvement a fait l'objet d'un travail de standardisation de PLCopen, dès le début des années 2000 (la publication de la première partie du standard date de novembre 2001). Cette approche a permis le développement d'un très grand nombre de solutions d'entraînement électrique avec des technologies différentes mais qui pouvaient être mises en œuvre avec des calculateurs industriels d'autres marques et avec un développement de la partie logicielle générique et facilement modifiable d'une marque à l'autre.

Le terme « contrôleur de mouvement » est utilisé ici pour désigner le *servodrive* où préacttionneur intelligent qui réalise l'adaptation de puissance permettant d'alimenter un actionneur électrique en réalisant les boucles d'asservissement courant - vitesse - position.
Le standard PLCopen Motion Control a été adopté par tous les acteurs de l'automation industrielle. Ce document est composé de plusieurs parties :

- Partie 1 : blocs fonctionnels pour le motion control. Cette partie regroupe les parties 1 et 2 de la première version du standard, la version 2.0 a été publiée en mars 2011.

- Partie 3 : directives utilisateurs, cette partie présente des cas d'usage des blocs fonctionnels de la bibliothèque.

- Partie 4 : mouvement coordonné. Ce document décrit l'approche et les blocs fonctionnels pour le pilotage d'architectures de type robotique, il est actuellement en cours de révision et son contenu est détaillé dans la chapitre 3.1.1 de ce manuscrit.

- Partie 5 : procédures de prises d'origine

- Partie 6 : extensions pour les systèmes hydrauliques.

### 2.1.4.1 Structure du standard

Le standard PLCopen Motion Control décrit un mode de contrôle des préactionneurs de motorisation électrique indépendant du matériel et impose aux constructeurs de fournir un ensemble de blocs fonctionnels qui donnent accès aux fonctions élémentaires de préparation et de génération des mouvements. Les interfaces et les comportements de ces blocs fonctionnels sont également imposés et ils doivent pouvoir être implémentés dans les langages de la norme IEC61131-3. Les fournisseurs de matériel peuvent ajouter des fonctions propriétaires complémentaires.

Le lien entre un bloc fonctionnel et l'actionneur qui lui est associé est créé par le passage de l'adresse d'une structure dont le type dépend du fournisseur de matériel. La notion d'« axe » utilisée dans ce standard décrit le mouvement d'un degré de liberté d'un mécanisme, en relation avec un moteur par un système de transformation de mouvement à loi proportionnelle. Il ne s'agit donc pas nécessairement du contrôle direct de l'arbre moteur ou du chariot d'un moteur linéaire, mais il peut décrire le mouvement de la sortie d'un réducteur ou un mouvement de translation, si la chaîne de transmission présente une transformation entre un mouvement de rotation et un mouvement de translation. L'environnement de programmation permet d'associer cette variable à un composant matériel, de paramétrer les limites admissibles de l'axe et éventuellement la description de la chaîne de transformation de mouvement. Il offre également au développeur les outils permettant de configurer et de régler les paramètres de régulation du contrôle en position réalisé par le contrôleur de mouvement.

Les blocs fonctionnels disponibles se partagent en deux catégories :

- les blocs fonctionnels d'administration (MC_Power, MC_Home, MC_ReadStatus, ...),

- les blocs de mouvement (MC MovingAbsolute, MC_Halt, MC_TorqueControl, ...).

Les principales fonctions réalisées sont les suivantes :

- Préparation de l'axe :

- MC_Power : démarrage et arrêt de l'étage de puissance,

- MC_Home : « prise d'origine », mise en référence du capteur de position par rapport à la position physique de l'axe,

- Information : MC_ReadStatus : état de la machine d'états PLCopen Motion Control,

- Modification du mouvement :

- MC MovingAbsolute : déplacement vers une position absolue,

- MC MovingVelocity : accélération/décélération puis déplacement à vitesse constante,
- `MC_Halt`: arrêt contrôlé,

- `MC_TorqueControl`: application d'un couple constant atteint avec une rampe de couple,

- Coordination d'axes :

- `MC_GearIn`: activation d'un couplage constant (rapport de vitesses imposé) de l'axe contrôlé avec un axe maître,

- `MC_CameIn`: engagement d'une came électronique entre l'axe contrôlé avec un axe maître. Une relation polynomiale périodique relie alors la position de l'axe suiveur à celle de l'axe maître, comme le réaliserait une came mécanique.

### 2.1.4.2 Diagramme d'états PLCopen Motion Control

Le diagramme d'états décrit sur la figure 2.11 est une couche d'abstraction de l'état réel de l'axe. Il définit le comportement de l'axe lorsque plusieurs blocs fonctionnels de contrôle des mouvements sont activés « simultanément ». Cette combinaison de profils de mouvement est utile pour construire un profil plus complexe ou pour gérer les exceptions au sein d'un programme. La règle de base est que les commandes de mouvement sont toujours prises de manière séquentielle, même si l'automate a la capacité d'effectuer un véritable traitement parallèle. Ces commandes agissent sur le diagramme d'état de l'axe, qui se trouve toujours dans l'un des états définis, suivant une logique d'abandon de la fonction en cours ou de stockage dans un tampon des nouvelles commandes. Toute commande de mouvement qui provoque une transition change l'état de l'axe et, par conséquent, modifie la façon dont le mouvement actuel est réalisé.

<figure><img src="image_35.png" /><figcaption>FIGURE 2.11 – Machine d'états d'un axe selon PLCopen Motion Control.</figcaption></figure>
Les différents états sont définis de la façon suivante :

- **Disabled**. Le contrôleur du lecteur est désactivé.

- **Standstill**. Le contrôleur de mouvement n'exécute actuellement pas de mouvement et est prêt à générer des commandes de positionnement.

- **Homing**. Le contrôleur exécute une procédure de prise d'origine.

- **ErrorStop**. Le contrôleur est à l'arrêt après une erreur.

- **Stopping**. L'entraînement arrête le mouvement actif.

- **Discrete Motion**. Le contrôleur exécute un mouvement vers une position cible. Le mouvement a donc une fin définie.

- **Continuous Motion**. Le contrôleur exécute un mouvement sans position cible, le mouvement n'a pas de fin définie.

- **Synchronized Motion**. L'axe est couplé à un autre axe.

### 2.1.4.3 Blocs fonctionnels de mouvement

Le bloc fonctionnel de mouvement le plus utilisé est le bloc `MC Moving Absolute`. S'il est activé dans un état dans lequel son activation est valide, il prend la main sur la réalisation du mouvement interrompt l'exécution d'un éventuel bloc fonctionnel en cours d'utilisation et organise le déplacement de l'axe vers une position d'arrêt définie par une position absolue et des niveaux de vitesse et d'accélération maximale admissibles.

Depuis la version 2.0 du standard *Function blocks for motion control*, les blocs de mouvement ont une entrée complémentaire qui va décrire la situation d'interruption d'une fonction de mouvement par une autre. Avec l'entrée `BufferMode` le bloc fonctionnel peut conserver son fonctionnement standard d'abandon du mouvement en cours et de reprise par un autre à partir de la situation position - vitesse - accélération courante ou temporiser la prise en charge de la seconde fonction de mouvement. Dans ce dernier cas, il est possible de choisir la transition entre les mouvements lorsque le premier est terminé (position ou vitesse objectives atteintes, suivant les cas). L'entrée `BufferMode` peut prendre les valeurs suivantes :

- `MCABORTING`: fonctionnement par défaut : prise en compte immédiate de la nouvelle commande

- `MCBUFFERED`: déclenchement du second mouvement lorsque le premier est terminé

- `MCBLENDING_LOW` ou `MCBLENDING_HIGH`. La transition entre mouvements s'effectue à la vitesse minimale / maximale entre les valeurs des deux blocs fonctionnels.

- `MCBLENDING_PREVIOUS` ou `MCBLENDING_NEXT`. La transition entre mouvements s'effectue à la valeur de vitesse du premier ou du deuxième bloc fonctionnel.

Lorsqu'un autre mode que le mode `MCABORTING` est choisi, la génération de profil de mouvement ne peut plus être réalisée par le contrôleur de mouvement et est prise en charge par l'automate. Le contrôleur de mouvement passe en suivi de consigne de position cyclique.

Ce principe de fonctionnement qui prévoit la possibilité de mémoriser une nouvelle commande de mouvement et d'en retarder l'action diminue l'aptitude du programme à avoir un comportement déterministe mais sera repris dans la partie du standard portant sur la coordination multiaxe dans l'objectif de générer des trajectoires à partir de mouvements élémentaires (cf. partie 3.1.1.1).
<figure><img src="image_36.png" /><figcaption>FIGURE 2.12 – Exemple de fonctionnement de l'entrée BufferMode pour l'enchaînement de deux blocs fonctionnels MCrimMoveAbsolute.</figcaption></figure>

2.2 rtrmac : un outil de développement de systèmes de contrôle-
commande temps-réel

Pour répondre à la demande de la réalisation de logiciels de contrôle-commande pour de
nouveaux dispositifs mécatroniques, l'équipe RoBioSS a développé un framework logiciel nommé
rtrmac, selon l'acronyme de Real-Time Robotic MultiAxis Control. Les premières versions ont été
réalisées par Philippe Vulliez, dans la décennie 2010 [Vulliez 2019], [Fischer 2019]. Ce framework
est plus précisément une bibliothèque logicielle extensible qui comporte les fonctions nécessaires
à la réalisation complète d'un système de contrôle-commande multiaxe orienté robotique. Il a
fait l'objet d'une démarche de protection industrielle de la part du CNRS sous la forme d'un
dépôt à l'agence de protection des programme en juillet 2018 [Vulliez 2018].

Les évolutions de cette bibliothèque ont accompagné le développement des systèmes méca-
troniques par l’équipe au cours des vingt dernières années. Le point de départ de la création
de cette solution était la décision de mettre en œuvre des composants de contrôle commande
industriels standards pour réaliser la partie commande des nouveaux robots ou bancs d’essais.
Les bénéfices attendus de ce choix stratégique étaient les possibilités :

— d'exploiter des systèmes temps réels durs avec les fonctionnalités des systèmes d'exploi-
tation de PLC présentés au chapitre 2.1.3,

— d'avoir des composants robustes avec une haute disponibilité,

— de minimiser le besoin de développement de cartes électroniques spécifiques,
- de standardiser, en interne, la méthodologie de développement logiciel et de créer des bibliothèques réutilisables entre projets pour accélérer la conception logicielle et exploiter plus facilement les algorithmes implémentés dans l'équipe.

La première version du framework était rédigée en langage IEC Structured Text, la deuxième en C et la troisième, en cours de développement, en C++. Ces changements sont permis par l'évolution des environnements de programmation automate qui permettent de plus en plus de développer des briques logicielles en C++ en conservant la compatibilité avec les langages pour automates.

Une partie de travaux de recherche s'inscrivent dans l'extension de la bibliothèque rtrmac au développement d'interfaces de nouveaux capteurs et au pilotage de groupes d'axes dans l'objectif d'unifier la démarche de conception de la couche coordination multiaxe de nos nouveaux dispositifs mécatroniques. Cette approche est détaillée dans le chapitre 3 de ce document.

Avant l'intégration de ces nouvelles fonctionnalités, j'ai mis en œuvre la bibliothèque rtrmac dans le cadre du développement de plusieurs dispositifs. A titre d'exemple, il est possible de citer la remise à jour du système de contrôle du système locomoteur du robot humanoïde de grande taille, ORHRO, qui a fait l'objet du travail de thèse de doctorat de Jérémy Gastebois [Gastebois 2017]. Ce robot à quinze degrés de liberté a une armoire de commande comportant un automate programmable industriel et huit contrôleurs de mouvement standard, de marque B&R Automation.

<figure><img src="image_37.png" /><figcaption>FIGURE 2.13 – Robot humanoïde ORHRO et schéma de l'architecture de commande.</figcaption></figure>

Dans le cadre de ce projet, nous avons exploité la possibilité de mettre à l'échelle la partie commande et le logiciel, comme présenté au chapitre 2.1.2 : le développement d'un algorithme
de stabilisation posturale a été réalisé et implémenté sur une jambe avant d'être intégré dans la commande du système complet, deux jambes et torse.

Un second exemple permet de montrer la versatilité du framework *rtrmac*. Il s'agit du développement de logiciels de contrôle de bancs de test d'arc et de flèches exploités dans le cadre des travaux de thèse de doctorat d'Andrian Kuch (cf. figure 2.14). Pour ces projets, la partie *génération de mouvement* était plus simple à réaliser, mais les architectures retenues permettent de fusionner simplement les mesures issues des contrôleurs de mouvement et des capteurs complémentaires.

<figure><img src="image_38.png" /><figcaption>FIGURE 2.14 – Banc de test de flèches, CAIPS (CREPS de Boivre), FFTA.</figcaption></figure>

Les deux principes fondamentaux de cette bibliothèque sont la définition d'un cadre de création de classes adaptées à une exécution périodique sur des cibles temps-réel industrielles et la création d'un axe robotique qui permet d'abstraire un comportement unifié quelle que soit la technologie d'entraînement électrique utilisée.

### 2.2.1 Structure de la bibliothèque

Le principe central de la construction de la bibliothèque *rtrmac* est de garantir à toutes les classes qu'elle contient un mécanisme permettant de :

- Vérifier la validité des paramètres des fonctions et de contrôler les situations d'actualisation des paramètres.

- Interrompre le fonctionnement des objets en cas d'apparition d'une erreur, d'identifier l'erreur et de transmettre l'information de la situation d'erreur à l'unité logicielle qui
exécute l'objet. Ce mécanisme permet de mettre en œuvre une stratégie de sortie des situations d'erreur.

— Suivre un comportement unifié pendant l'exécution cyclique de la méthode principale.

Cette approche met en application les exigences détaillées dans les paragraphes précédents :

1. Exécution des programmes dans un système d'exploitation temps-réel industriel,

2. Possibilité de pouvoir utiliser les langages de la norme IEC 61131-3 dans le reste du projet logiciel,

3. Respect des recommandations PLCopen pour la réalisation de bibliothèques de blocs fonctionnels.

Le deuxième point de cette liste impose une communication entre programmes par l'intermédiaire de structures d'échange compatibles avec les exigences de la norme de programmation des automates. Ce fonctionnement par flux de données sera utilisé de façon identique au sein d'une même tâche et entre programmes, un exemple sera présenté figure 2.23 lorsque nous présenterons l'implémentation de la régulation des axes électriques.

Les première et troisième exigences sont satisfaites en créant des classes :

— dont la méthode principale est destinée à être exécutée de façon périodique et doit implémenter l'une des machines d'états de la recommandation PLCopen,

— et qui présentent les entrées de déclenchement et d'inhibition et les sorties d'informations génériques.

Dans la suite de ce document, pour désigner ce groupe de classes permettant d'obtenir un fonctionnement similaire à un bloc fonctionnel, on utilisera le terme générique *unité d'organisation logicielle*.

Pour mettre en œuvre ce principe, la création d'une nouvelle unité d'organisation logicielle requière la création de deux classes : la classe qui va réaliser périodiquement la fonctionnalité attendue et une classe d'assistance qui va vérifier la validité des paramètres renseignés. Ces deux classes doivent hériter de deux classes de base abstraites génériques `RbFbAbstractParam<CParam>` qui définit le comportement d'une classe de contrôle-commande et `RbParam<Paramalin>` qui met en place le mécanisme de contrôle d'une structure de paramètres.

La classe `RbFbAbstractParam` est une classe abstraite qui implémente la structure générale d'une tâche de contrôle-commande, elle possède une méthode centrale `Cyclic` qui, comme pour un bloc fonctionnel du modèle IEC 61131 doit être exécutée à tous les cycles automate. Elle a pour membres principaux une instance de la classe de gestion de paramètres génériques `RbParam` et une instance d'une horloge système qui peut contrôler la durée d'exécution de la tâche.

Dans la méthode cyclique, est implémentée une version abstraite des machines d'états recommandées par le document *PLCOpen Compliant Librairies* et présentées au chapitre 2.1.3.3. La classe `RbFbAbstractParam` est dérivée une première fois pour définir un comportement de type `Level Controlled` ou `Edge Triggered`. Les différentes options comme la présence d'une entrée d'abandon (`Abort`) ou la surveillance de la durée de l'état `Executing` sont également implémentées. La seule modification par rapport au diagrammes d'états de la recommandation PLCopen est l'ajout d'un état `Enabling` qui permet de passer plusieurs cycles automate dans la phase d'initialisation et de partir dans l'état d'erreur, si nécessaire, sans passer par l'état de travail normal (`Executing`) (cf. figure 2.15).

La figure 2.16 présente l'implémentation du mécanisme de définition des modèles de comportements de blocs fonctionnels. La classe `RbFbAbstractParam` est une classe abstraite et gé-
<figure><img src="image_39.png" /><figcaption>FIGURE 2.15 – Diagramme d'états d'un bloc fonctionnel de type Edge-triggered with Abort dans la bibiothèque rtrmac.</figcaption></figure>

<figure><img src="image_40.png" /><figcaption>FIGURE 2.16 – Classe de base RbFbAbstractParam et quelques classes dérivées.</figcaption></figure>

nérique : elle dépend du *template* d'une classe d'un type indéfini qui sera particularisé lors de la création d'une classe fille. La classe RbParam qui lui est associée est également une classe tem-
plate : elle dépend d'un type variable qui sera particularisé lorsque l'implémentation fournira la structure de paramètre de la classe fille.

La classe `RbFbAbstractParam` implémente la machine d'états et l'interface les plus complètes. Elle est dérivée en classes également abstraites qui codent les différents comportements et interfaces présentés dans le document *PLCopen Compliant Libraries*.

Les données membres de la classe de base sont les entrées-sorties génériques (`Execute`, `Done`, `Error` ...), la classe de vérification de paramètres, la période d'exécution de la classe de tâches dans laquelle la tâche sera exécutée. Elle présente plusieurs méthodes importantes : `Cyclic()` est la méthode principale qui s'exécute périodiquement, les méthodes `SetParam()` et `UpdateParam()` définissent les situations où la structure de paramètres est prise en compte pour la première fois ou mise à jour par la suite. Les méthodes abstraites `rbEnabling`, `rbExecuting()`, `rbAborting()`, `Done()`, `Error()` sont à redéfinir dans les classes dérivées. Elles sont exécutées dans les différents états de la machine d'états et implémentent le comportement des nouvelles unités d'organisation de programme.

Les classes dérivées de premier niveau sont également des classes abstraites. Elles ajoutent aux méthodes de la classe de base les méthodes spécifiques aux entrées-sorties utiles, par exemple `SetAbort()` ou `SetTimeLimit()` qui régissent l'activation de l'entrée `Abort` et l'affectation d'une valeur à l'entrée `TimeLimit` d'une classe du type *rising edge triggered with abort and time limit* (`ETrigATl`). Enfin, ces modèles de classe existent avec ou sans la classe de vérification de paramètres associée (ce sont les variantes `RbClasseX` et `RbClasseXParam`).

### 2.2.1.1 Contrôle des paramètres

La classe `RbParam<Paramalin>` met en place le mécanisme de contrôle de la structure `Paramalin` contenant les paramètres spécifiques de la nouvelle unité d'organisation logicielle par l'intermédiaire d'une méthode abstraite `Verify`, à particulariser dans les classes dérivées. L'objectif de cette classe est de vérifier l'intégrité des paramètres renseignés et la compatibilité de leurs valeurs par rapport à leur usage dans les algorithmes. En particulier, il faut contrôler que les adresses utilisées dans les passages par référence sont valides et que les valeurs des paramètres ne vont pas provoquer de division par zéro. Ces deux erreurs provoquent en effet une défaillance qui provoque l'arrêt d'un contrôleur industriel. La classe `RbFbAbstract` définit les situations où ces paramètres peuvent être initialement définis ou mis à jour et exécute à nouveau la méthode de vérification. Si celle-ci échoue, l'objet passe dans l'état `ERROR` et l'identifiant de l'erreur est attribué à la sortie `ErrorID`.

### 2.2.1.2 Exemple

La figure 2.17 présente un exemple de construction d'une unité d'organisation logicielle. Il s'agit d'une brique de base de la bibliothèque `rtrmac` dont la fonction est de convertir la valeur entière retournée par une carte d'entrée analogique en valeur numérique correspondant à l'unité de travail choisie. Par exemple, si la carte d'entrée est reliée à une sonde de température, la sortie `S_ana` retournera la valeur de la température en °C à partir de l'entier `N_ana` fourni à chaque cycle par la carte d'entrée. Il est également possible d'obtenir les dérivées première et seconde de la grandeur mesurée avec une fonction de dérivation filtrée.

L'unité d'organisation de programme est composée de trois nouveaux types utilisateurs :
— la structure `RbAnalogInputParamalin` qui contient les paramètres spécifiques de l'unité logicielle : gain, option de calcul des dérivées et valeurs des constantes des filtres de dérivation,

— la classe `RbAnalogInputParam` hérite de la classe `RbParam` et implémente la fonction abstraite de vérification de la compatibilité des paramètres, et retourne l'un des nouveaux identifiants en cas d'erreur,

— la classe `RbAnalogInput` hérite de la classe `RbLConCParam` qui lui attribue le modèle de comportement level-controlled continuous (l'état Done n'est jamais atteint) avec une structure de paramètres à vérifier. La classe implémente les méthodes `RbEnabling()` à `RbError()` pour particulariser son fonctionnement dans les différents états de la machine d'états générique.

<figure><img src="image_41.png" /><figcaption>FIGURE 2.17 – Implémentation de l'unité d'organisation logicielle RbAnalogInput et bloc fonctionnel équivalent.</figcaption></figure>
### 2.2.2 Axe de mouvement générique

La seconde fonctionnalité centrale de la bibliothèque rtrmac est la possibilité de contrôler de façon unifiée un grand nombre de solutions technologiques d'entraînement électrique. Cette propriété est obtenue en deux temps :

- l'ensemble des blocs fonctionnels du standard PLCopen Motion Control, partie 1 est exécuté au sein d'une unité d'organisation de programme qui coordonne l'action des blocs élémentaires, sélectionne les modes de pilotage utiles à un logiciel de pilotage robotique et fournit des interfaces permettant à d'autres unités fonctionnelles de prendre le contrôle des actionneurs,

- les interfaçages avec les différents types d'équipements de pilotage moteur sont réalisés par des classes spécialisées qui interagissent directement avec l'unité fonctionnelle de gestion d'axe de telle sorte que l'utilisateur n'ait pas besoin de prendre en compte la solution d'entraînement lorsqu'il développe son logiciel de pilotage. La prise en compte d'une architecture de contrôle particulière se résume au renseignement des paramètres fonctionnels utiles.

#### 2.2.2.1 Abstraction du type d'entraînement électrique

Si l'on se place dans le cadre d'usage de systèmes d'entraînement avec une exigence de maîtrise du positionnement, il faut que l'ensemble formé du calculateur industriel et des cartes électroniques permettant l'adaptation de puissance pour la motorisation prenne en charge les fonctions suivantes :

- génération de la consigne instantanée de position à partir de la fonction choisie (déplacement vers une position d'arrêt absolue ou relative ou évolution vers une vitesse objectif),

- asservissement en position,

- asservissement en vitesse,

- asservissement en couple ou courant.

Suivant la topologie matérielle utilisée, ces différentes fonctions peuvent être réalisées par les préactionneurs ou rester à la charge du contrôleur principal. La figure 2.18 présente les différentes architectures matérielles qui peuvent être prises en charge par la bibliothèque rtrmac. Sur la figure, la topologie la plus basse correspond à l'utilisation d'un contrôleur de mouvement qui prend en charge l'essentiel de la génération de mouvement et n'échange avec l'automate que les ordres de haut niveau définis par l'usage des blocs fonctionnels PLCopen Motion Control. En conséquence, plus les cartes de contrôle sont simples, plus la charge de travail du calculateur augmente.

Pour pouvoir transférer de plus en plus de fonctions au contrôleur de mouvement, la bibliothèque rtrmac implémente la structure de régulation en cascade présente dans les contrôleurs de mouvement industriels présentée figure 2.19. Les suffixes _ref et _cons et _feed font référence aux grandeurs de référence (issue de la génération de trajectoire), de consigne et d'anticipation, respectivement. Si une partie des boucles de régulation sont réalisées par les composants matériels (boucles de courant et de vitesse, par exemple dans le cas d'un variateur de vitesse), l'automate réalise le reste du schéma de régulation.

Ces quatre topologies sont complétées par une configuration de simulation pour laquelle la régulation est supposée parfaite et la position atteinte est constamment égale à la position de
<figure><img src="image_42.png" /><figcaption>FIGURE 2.18 – Topologies d’axes asservis en position et répartition des fonctions suivant les architectures.</figcaption></figure>

<figure><img src="image_43.png" /><figcaption>FIGURE 2.19 – Schéma simplifié de l’architecture de régulation en position des axes électriques, d’après B&R Automation Help.</figcaption></figure>

consigne. Cette option est très importante dans le développement de la bibliothèque rtrmac puisqu’elle va permettre :
- de réaliser en avance et de tester le logiciel de commande d'une application pour laquelle la configuration matérielle n'est pas encore connue,

- de construire un axe virtuel qui sera contrôlé de façon identique aux axes réels,

- et de contrôler des axes ou des systèmes robotiques externes pour lesquels l'ensemble de la régulation est réalisée par la baie de commande du robot.

L'unification de ces différentes topologies est réalisée dans un objet logiciel qui contient les classes `RbMcAxe`, `RbMcAxeConfigParam` et la structure `RbMcAxeConfigParamalin`, comme présenté sur la figure 2.20. Il traduit la topologie d'axe virtuel (c'est-à-dire que la régulation est parfaite) et peut être dérivé pour mettre en place les schémas de régulation associés aux différentes topologies. Cet objet logiciel implémente également la machine d'états PLCopen Motion Control (MC) de la figure 2.11. Pour toutes les topologies, des classes complémentaires permettent de simuler le comportement des parties opératives.

La structure `RbMcAxeConfigParamalin` contient des éléments communs à toutes les topologies et des sous-structures associées aux différents composants du schéma de régulation qui ne sont nécessaires que dans certaines topologies.

<figure><img src="image_44.png" /><figcaption>FIGURE 2.20 – Classes participant à la régulation d'axe.</figcaption></figure>

Une sélection des blocs fonctionnels du standard est réalisée sous la forme de classes abs-
traites. L'exécution de ces blocs va contrôler l'axe piloté et faire évoluer son état dans la machine
d'états PLCopen MC. Ils sont ensuite dérivés pour être utilisés avec les topologies d'axes inclus
dans *rtrmac* ou pour encapsuler les blocs fonctionnels de bibliothèques propriétaires dans le cas
de l'usage de contrôleurs de mouvement industriels (cf. figure 2.21). Ces blocs fonctionnels vont
être utilisés pour construire l'unité d'organisation de programme qui va permettre de gérer l'axe
robotique présenté dans le chapitre suivant.

<figure><img src="image_45.png" /><figcaption>FIGURE 2.21 – Classes exécutant les comportements des blocs fonctionnels PLCopen Motion Control partie 1.</figcaption></figure>

Ces blocs fonctionnels seront exécutés de façon masquée pour l'utilisateur par les gestionnaires d'axe robotique qui vont fournir une interface unique pour contrôler toutes les architectures matérielles ainsi que les axes de simulation.

### 2.2.2.2 Exemple de programme de régulation en position d'un actionneur électrique

Les figures 2.22 et 2.23 présentent les classes et structures utilisées dans l'implémentation de l'étage de régulation d'un axe électrique de topologie 1 : pont en H, module codeur et moteur courant continu avec codeur. Ces objets sont exécutés dans le programme Hardware qui est attribué à la classe de tâche prioritaire Cyclic#1. La première figure présente les actions menées pendant la phase d'initialisation de la tâche. L'exécution de la méthode Enabling() des classes de contrôle commande (dans la colonne de droite) charge les paramètres définis dans les structures après vérification de leur cohérence par les classes de vérification.

La figure 2.23 décrit le flux de données qui circule lors de l'exécution périodique des méthodes Executing(). La carte d'entrée de comptage fournit un nombre d'incréments qui est l'image de la position moteur. L'instance de la classe RbCodeur convertit cette valeur en position en unité de travail de l'utilisateur (en degrés, ici) et calcule les dérivées première et seconde. Ces trois informations servent d'entrées à l'objet RegMot qui instancie la classe de régulation des axes de
topologie 1. La sortie de ce bloc de régulation est convertie en entier de commande de la carte de puissance par l'instance de la classe RbAnalogOutput.
<figure><img src="image_46.png" /><figcaption>FIGURE 2.22 – Implémentation d'un programme de régulation moteur : chargement et vérification des paramètres à l'exécution des méthodes Enabling().</figcaption></figure>

<figure><img src="image_47.png" /><figcaption>FIGURE 2.23 – Implémentation d'un programme de régulation moteur : flux de données dans la chaîne de traitement des entrées-sorties.</figcaption></figure>
### 2.2.2.3 Réalisation d'un gestionnaire d'axe robotique

Pour simplifier l'usage des blocs fonctionnels PLCopen Motion Control, la bibliothèque rtrmac fournit une unité d'organisation logicielle permettant d'utiliser un composant appelé gestionnaire d'axe. Il donne accès aux blocs d'administration et de mouvement par une structure de commande, aux paramètres de l'axe, par une structure de paramètres et aux informations sur l'état de l'axe par une structure d'information. Cette fonctionnalité est fournie, par certains fournisseurs de matériel, sous la forme de blocs fonctionnels propriétaires puisque ce niveau d'intégration n'est pas imposé par le standard de commande d'axe.

L'unité d'organisation logicielle de gestion d'un axe robotique donne un accès indirect aux blocs fonctionnels de commande d'axe par l'intermédiaire d'une structure de commande et d'une structure d'information qui pourront être échangées entre programmes. La modification de la structure de commande permet d'activer et de passer les paramètres des différentes fonctions de mouvement nécessaires au pilotage de mécanismes et de robots. Ces fonctions seront accessibles pour le pilotage des moteurs et des articulations des robots ou des sorties des mécanismes. Il est possible de choisir un mode de contrôle (en position, en vitesse ou en couple, selon les possibilités offertes par le composant d'adaptation de puissance). Pour chacun, le gestionnaire d'axe peut générer une loi de commande vers un objectif à atteindre ou suivre une consigne qui sera fournie périodiquement par un générateur externe au gestionnaire d'axe.

Comme pour l'étage de régulation présenté dans le chapitre précédent, l'implémentation est réalisée sous la forme de classes abstraites à dériver pour contrôler les différentes topologies d'axes pris en charge et pour s'interfacer avec les bibliothèques de commande d'axe des fournisseurs de matériel.

L'unité d'organisation logicielle abstraite réunit les classes RbMcAxeRob et deux structures d'échange, l'une contient les ordres utilisateurs permettant de déclencher des actions de préparation ou de mouvement (démarrage, arrêt, déplacement vers une position ou une vitesse objectifs, par exemple), la seconde retourne des informations sur l'état de l'axe qui seront exploitées par le programme de niveau hiérarchique supérieur : le gestionnaire de groupe d'axes ou le gestionnaire machine.

Cette classe abstraite exécute des instances des classes représentant les blocs fonctionnels PLCopen partie 1 présentés au paragraphe précédent et coordonne leur usage par une machine d'états qui définit à chaque situation les actions disponibles. Elle est dérivée (cf. figure 2.24) pour s'adapter à différents usages :

- la classe Rb00 MC AxeRob permet de contrôler les différentes topologies d'entraînements électriques,

- la classe RbJoint va permettre de traiter de façon homogène aux axes moteurs les axes articulaires des systèmes robotique, ce sont des axes parfaits, du point de vue de la régulation,

- et la classe Rb10 MC AxeRob permet de prendre en charge les contrôleurs de mouvement de la marque B&R Automation.

La figure 2.25 présente la machine qui coordonne les actions de démarrage et arrêt des étages de puissance, de prise d'origine et d'arrêt d'urgence logiciel. Cette dernière fonctionnalité interrompt toutes les consignes de génération de mouvement et réalise un freinage contrôlé jusqu'à l'arrêt de l'axe.

Lorsque l'axe est dans l'état Standstill, l'utilisateur peut choisir l'un des modes de pilotage
<figure><img src="image_48.png" /><figcaption>FIGURE 2.24 – Classes implémentant les gestionnaires d’axes robotiques.</figcaption></figure>

présentés sur la figure 2.26. Le gestionnaire de mouvement donne accès à un mode manuel de type *Jogging* qui est un déplacement à vitesse constante tant que la commande de mouvement est active, un déplacement vers un point d’arrêt et à plusieurs modes de suivi de consigne périodique. Dans ce dernier cas, la variation de consigne est générée à l’extérieur du gestionnaire d’axe, à la période d’exécution de l’automate. Il peut s’agir d’une consigne :

- de position ou de vitesse,

- de couple, si le préactionneur a un accès à la boucle de régulation en courant.

Cette partie de la bibliothèque *rtrmac* a été testée intensivement et est une brique élémentaire présente dans les logiciels de pilotage de tous les dispositifs de l’équipe RoBioSS. Elle sera utilisée dans les exemples de mécanismes et de robots présentés dans les parties 3 et 4 de ce manuscrit.
<figure><img src="image_49.png" /><figcaption>FIGURE 2.25 – Axe robotique : étapes de préparation avant mouvement (démarrage - arrêt, prise d'origine, arrêt d'urgence logiciel).</figcaption></figure>
<figure><img src="image_50.png" /><figcaption>FIGURE 2.26 – Modes de pilotage d’un axe robotique.</figcaption></figure>