Les leaders de l'automatisation aux États-Unis font face aux défis d'intégration : combler la communication entre systèmes d'usine

Projets visant à combler la communication entre robots, autres composants d'usine

Comme les délégués internationaux des Nations Unies qui utilisent des interprètes pour se comprendre, les robots, machines et autres composants industriels de divers fournisseurs parlent différents langages informatiques et ont besoin de traducteurs pour les aider à communiquer.

Largement à cause de l'économie, les entreprises fabriquant machines-outils, robots, convoyeurs et similaires utilisent des logiciels propriétaires pour leur opération et communication entre eux et avec des composants comme capteurs, drivers et PLC. Les constructeurs de machines veulent que les services d'achat d'usine restent avec leur marque de solution totale pour créer plus de revenus.

« La pensée dominante à un moment était que si j'investis mes fonds et fournis des solutions, je veux protéger mes ventes », dit Matthew Robinson, responsable de programme, consortium ROS-Industrial (ROS-I) Amériques, Southwest Research Institute. « Si je fournis des machines-outils, j'aimerais que les clients utilisent tous mes produits… mon logiciel, mon matériel et technologies interconnectées associées. »

Quand un propriétaire d'usine décide de passer à une marque différente, des problèmes de communication surviennent et entravent l'intégration, la simulation et l'analyse qui peuvent augmenter la production et la qualité.

Jusqu'à maintenant, la tâche de permettre la communication entre toute la technologie dans une usine est tombée largement sur les intégrateurs système qui créent les traducteurs de code informatique, ou ponts, disons, d'une caméra 3D à un robot ou entre deux robots faits par différents fournisseurs. C'est un processus qui prend beaucoup de temps et coûte beaucoup d'argent — tellement que le prix de l'ingénierie de connectivité peut excéder celui d'une machine elle-même.

« L'ingénierie prend si longtemps et coûte si cher que beaucoup d'entreprises ne prendront pas la route de l'automatisation », dit Juan Aparicio, chef du groupe de recherche pour l'Automatisation de Fabrication Avancée chez Siemens Technology. « Ça n'a pas de sens pour eux parce qu'ils n'ont pas un gros budget qui peut justifier l'automatisation. »

Mouvement vers un standard commun

Ce scénario a mené à un problème à grande échelle : le temps et la dépense associés à l'intégration entravent l'adoption de l'automatisation dans beaucoup d'ateliers — et freinent le progrès dans l'industrie américaine.

Ce que les fabricants, et leurs résolveurs de problèmes d'intégration espérés comme Robinson, Aparicio et autres, expérimentent maintenant a un précédent dans un autre domaine de fabrication.

Il y a environ 30 ans dans l'industrie des semi-conducteurs, les équipements de traitement de wafer comme les machines de lithographie à gravure de différents fournisseurs ne pouvaient pas non plus se parler. Pour combattre l'atrophie imminente dans ce cas, les fabricants de semi-conducteurs ont formé un consortium et ont dit aux fournisseurs qu'ils devaient créer un standard commun. C'est exactement ce qui s'est passé.

« La question est : 'La demande des clients est-elle assez puissante pour driver la création d'un standard commun [maintenant] ?' » C'est selon John Wen, chef de l'ingénierie électrique, informatique, et systèmes à l'Institut Polytechnique Rensselaer. « Il reste à voir mais il semble y avoir un mouvement dans cette direction. »

Wen est aussi parmi ceux qui travaillent sur les efforts actuels vers la communalité et la création de ponts qui traduisent les langages machine pour que les dispositifs d'une usine puissent se parler.

Leur travail est financé par l'Institut Advanced Robotics for Manufacturing (ARM), qui fait partie de Manufacturing USA. Les projets financés par l'Institut ARM incluent le développement de middleware spécifique — un de l'académie et un autre de l'entrepreneur aux poches profondes Scott Hassan — à un niveau de maturité technique plus élevé pour que les options de middleware soient prêtes pour l'usage industriel général et puissent aider les usines à bourdonner avec une communication actionnable.

Une solution plug-and-play

Wen dirige un projet intitulé « Robot Raconteur (RR) : Un middleware interopérable pour la robotique. » RR collecte des données et invoque des fonctions, comme opérer une caméra, aussi.

« Robot Raconteur … est une technologie middleware avancée, augmentée, orientée objet, spécifiquement conçue pour fournir de vraies capacités d'interopérabilité plug-and-play pour les systèmes d'automatisation/robotique », selon la proposition de recherche de Wen.

RR est déjà polyvalent : il est compatible avec les systèmes d'exploitation Linux, Windows, OSX, iOS, Android, OpenBSD, QNX, Arduino et xPC Target. Il a des bibliothèques pour C++, Python, C#, Java, MATLAB, LabView, JavaScript navigateur et xPC Target.

Le middleware Raconteur a été développé dans le laboratoire de Rensselaer de Wen par John Wason. Après que Wason a obtenu son doctorat, il a essaimé sa propre entreprise, Wason Technology, focalisée sur le middleware. Wason participe à la recherche financée par l'Institut ARM avec Rensselaer, tout comme le Southwest Research Institute et United Technology Corp.

En attendant, les utilisateurs de robots industriels comptent encore sur un processus d'enseignement-répétition pour les mettre au travail.

La clé pour s'éloigner du paradigme enseignement-répétition est d'utiliser des capteurs, que ce soit pour la vision, 3D, balayage laser, proximité, tactilité ou force, dit Wen.

Cependant, intégrer et programmer des capteurs dans un robot ajoute de la complexité : ils sont un coût additionnel. Et les capteurs peuvent casser. Plus il y a de choses qui peuvent casser, plus la probabilité qu'une ligne tombe en panne est haute, coûtant de l'argent à une usine.

La solution de Wen est de développer RR en un système open-source, plug-and-play qui rendrait la programmation et l'intégration de robots, capteurs, périphériques et logiciels de simulation de multiples fournisseurs et plateformes facile, rapide, et sécurisée.

Cela ouvrirait aussi la porte à l'utilisation d'une gamme plus large de capteurs, incluant des produits grand public à coût inférieur, comme les caméras 3D Azure Kinect et Intel RealSense, dit Wen.

« Programmez dans votre langage de choix »

Inhérent au travail de Robinson au Southwest Research Institute est de travailler avec et promouvoir ROS-I, un autre middleware open-source similaire à RR dans le sens que vous pouvez connecter des ensembles divers de dispositifs mais qui facilite aussi la visualisation et la simulation.

Il connaît le paradigme en silo d'un fournisseur promouvant une et une seule solution est ce qui a mis la fabrication dans le pétrin dans l'arène de la connectivité en premier lieu.

Alors, Robinson a pesé le pour et le contre et est franc sur le côté négatif de sa fondation, ROS (Robot Operating System), dans le domaine spécifique de l'IoT.

« Un des gros inconvénients de ROS est que c'est beaucoup de C++, qui est un langage informatique en évolution rapide et mis à jour », dit-il. « Cela peut être, pour les nouveaux venus, intimidant et semé de toutes sortes de problèmes. Donc, il y a beaucoup d'entités et d'outils pour isoler les gens de l'industrie qui veulent juste faire marcher leurs systèmes de devoir faire toutes sortes d'écriture de logiciel informatique hardcore profond en C++.

« RR cherche à abaisser cette barrière à l'entrée. »

Aparicio est un autre partisan de la diversité des langages informatiques.

« Je pense qu'il est irréaliste de dire qu'il n'y aura qu'un seul langage dans la fabrication, mais s'il y en a plusieurs — tous avec pour et contre — alors nous avons besoin d'une passerelle » sous forme de logiciel qui agit comme un interprète, dit-il.

Aparicio est investigateur principal pour un projet financé par l'Institut ARM pour créer un logiciel open-source plug-and-play pour l'interopérabilité et la communication entre systèmes d'automatisation, simulateurs, plateformes cloud et un robot (qui est contrôlé par ROS-I).

La passerelle fonctionnera avec trois standards et protocoles largement utilisés dans la fabrication : OPC-UA, MTConnect et DDS.

Rejoignant Siemens et le Southwest Research Institute sur le projet sont la firme logicielle Real Time Innovations et les fournisseurs de robots Keba et Yaskawa.

« À la fin, la sauce secrète sera à quel point vous permettez facilement à toutes ces machines de se parler… d'interopérer… d'abstraire toutes ces communications de bas niveau pour que vous puissiez programmer dans votre langage de choix », dit Aparicio.

Les machines héritées peuvent-elles parler, aussi ?

Les nouvelles machines-outils et dispositifs d'usine sont équipés pour la connectivité et l'interopérabilité sortie de boîte, et leurs propriétaires devraient être capables de prendre un avantage robuste du travail qu'Aparicio, Wen et Robinson font.

Mais qu'en est-il des machines héritées ?

« En général, si ça a une carte réseau, si ça peut supporter le déplacement d'information sur l'internet traditionnel, on est bons pour y aller », dit Robinson.

Même certains robots hérités qui ont une dizaine d'années ou plus peuvent être mis au travail au lieu de prendre la poussière dans un magasin d'usine.

« Si vous avez un robot de 10 ans environ, c'est essentiellement un actif gratuit à ce stade, donc vous ajoutez juste quelques capteurs, tirez parti de quelques morceaux de logiciel », dit Robinson. « Vous devrez peut-être travailler avec un partenaire contractuel à moins que vous ayez une bonne équipe interne, mais vous pouvez être en marche [à un] coût bien [plus bas] qu'acheter un tout nouveau système from scratch.

« Ce retour sur investissement devient très convaincant. »

Le travail d'un codeur n'est jamais fini

Même avec toute l'expertise et le travail dur mis dans les projets financés par l'Institut ARM, avec leurs résultats réussis, il y a encore beaucoup de travail à faire pour aider la fabrication américaine à atteindre son plein potentiel d'interopérabilité et de connectivité.

Il y a aussi de la place pour plus de participants.

« C'est le genre de projet où plus il y a de gens qui en savent, mieux c'est. Nous voulons avoir de plus en plus d'entreprises à bord », dit Aparicio. « Ce n'est pas que nous résolvons totalement le problème. Nous résolvons un petit obstacle. Il y aura d'autres projets » nécessaires pour résoudre le problème plus large.

Comme l'a dit Wen des résultats des projets : « Tout le monde veut ça. »

Qu'est-ce que ROS ?

Certains des projets de développement technologique financés par l'Institut Advanced Robotics for Manufacturing (ARM) tirent parti d'une grande partie du contenu dans le logiciel ROS-Industrial pour étendre ses capacités et idéalement durcir les modules développés pour l'usage industriel général.

L'historique de ROS, le code logiciel fondamental de ROS-Industrial, est enraciné dans la Silicon Valley.

Le code ROS a été développé par une équipe travaillant à Willow Garage dirigée par le fondateur de l'entreprise Scott Hassan, un milliardaire de la Silicon Valley qui était l'architecte logiciel clé pour Google, selon une bio postée sur le site web de son entreprise subséquente, Suitable Technologies. ROS, et maintenant ROS2, est actuellement développé et maintenu par l'organisation à but non lucratif Open Robotics.

Le nom communément utilisé, ROS, est un acronyme pour « robot operating system », mais cela vend ses capacités à la courte.

« ROS n'est pas un système d'exploitation au sens traditionnel de gestion de processus et d'ordonnancement ; plutôt, il fournit une couche de communication structurée au-dessus des systèmes d'exploitation hôtes … », selon une vue d'ensemble de ROS sur le site web de Willow Garage.