Logiciels de contrôle intelligent et IHM : Autonomiser les ingénieurs pour construire les réseaux IIoT de nouvelle génération

Marissa Tucker de Parker Hannifin s'entretient avec le rédacteur en chef principal Patrick Waurzyniak

Marissa, quel est le rôle du contrôleur de mouvement dans l'Internet Industriel des Objets [IIoT], et quels logiciels sont impliqués ?

J'irais un pas au-delà du contrôleur de mouvement et dirais que le contrôleur d'automatisation programmable [PAC] joue le plus grand rôle dans l'IIoT. C'est parce qu'en plus d'avoir la logique machine, les PAC incluent le contrôle de mouvement dans leurs routines et ont souvent une interface homme-machine [IHM] intégrée, aussi. La beauté de cette approche est que le programme n'a pas besoin de partager des étiquettes entre dispositifs parce que les composants sont sur le même dispositif utilisant la même logique. Non seulement cela réduit le temps de programmation, mais cela facilite aussi les capacités IIoT.

Voici un exemple : L'erreur de position — qui était très spécifique au contrôleur de mouvement — est automatiquement accessible par l'IHM intégrée. Si cette IHM intégrée a des capacités de serveur web, ce que beaucoup ont, l'IHM peut immédiatement envoyer une alerte à l'opérateur local et aussi à un gestionnaire d'usine par e-mail ou SMS [service de messages courts]. C'est bien mieux que l'approche traditionnelle consistant à faire envoyer l'erreur par le contrôleur de mouvement au PLC [contrôleur logique programmable], le PLC devant ensuite traiter les données pour les envoyer à l'IHM — qui peut ou non avoir un serveur web. Ce transfert de données complexe entre dispositifs est éliminé, car la logique est écrite sur un logiciel de programmation téléchargé sur un dispositif matériel. C'est si étroitement intégré que vous pouvez facilement obtenir l'information n'importe où.

S'assurer que le développeur créant l'IHM intégrée peut créer différents groupes d'utilisateurs et identifiants est critique. Cela permet au programmeur de créer une instance personnalisée de l'IHM, selon l'utilisateur.

La facilité de flux d'information à l'intérieur de la machine est importante, mais aussi la facilité de flux d'information entre machines. La norme de programmation CEI 61131-3 assure qu'une machine développée par un fabricant parle le même langage utilisé par un autre. Cela profite grandement aux intégrateurs car ils peuvent plus facilement faire parler deux systèmes de machines différents entre eux, une étape nécessaire vers l'IIoT. Des organisations comme OMAC [Organization for Machine Automation and Control], qui promeut la norme PackML, portent la CEI 61131-3 au niveau supérieur en recommandant non seulement comment un système devrait être programmé mais aussi en développant un ensemble standard d'étiquettes que les machines devraient rendre disponibles aux autres machines dans le réseau.

Qu'en est-il des dispositifs de bas niveau, comme les valves pneumatiques et les capteurs de position ? N'est-ce pas tout censé faire partie de l'IoT ?

Le défi réside dans la prise de données des dispositifs de bas niveau et leur transformation en information utile. Une approche est de faire le traitement au niveau de ces dispositifs et d'envoyer les résultats soit sur un bus de contrôle haute performance, soit directement vers le cloud. C'est une approche très coûteuse et cela n'aide pas à rassembler ou centraliser les données. Alternativement, nous voyons une énorme croissance de la popularité d'IO-Link, un protocole série qui peut collecter des données de base de capteurs de température, électrovannes, manifolds de valves pneumatiques, etc., sans surcoût coûteux.

En gardant le bus simple, ces données peuvent être collectées et rendues utiles par le traitement sur le PAC ou PLC qui doit exister dans chaque système de machine. En optant pour un PAC, qui a aussi une IHM intégrée pour la publication web, les utilisateurs peuvent alors prendre cette information et la mettre sur le réseau, où elle doit aller. Imaginez un système pneumatique avec un capteur surveillant continuellement le son en décibels. La seule donnée qui doit être envoyée à un PAC IO-Link est le dB actuel. Le PAC peut avoir des blocs de fonctions CEI 61131-3 personnalisés développés par le fabricant qui peuvent fonctionner sur plusieurs contrôleurs. Ces blocs de fonctions peuvent vérifier s'il y a un motif bizarre dans le bruit, pour dire : « Ah, il pourrait y avoir une fuite. » Le programmeur peut prendre cette alerte et envoyer un message à un utilisateur de niveau maintenance de l'IHM avant que la pneumatique ne tombe en panne.

Comment l'information passe-t-elle de la machine au cloud, et qu'en est-il du logiciel impliqué ?

Il y a encore une grande division entre le plancher d'usine et l'IT. Surtout pour les entreprises manufacturières avec plusieurs installations dans divers États, ou pays, stocker les données dans un serveur externe ou le cloud est idéal. Du côté logiciel, les fabricants de composants doivent aider à rendre la vie des constructeurs de machines aussi facile que possible quand ils travaillent avec l'IT.

La plupart des constructeurs de machines sont à l'aise pour programmer un PLC ou PAC en CEI ou langages similaires, donc les entreprises devraient chercher des fabricants qui adoptent une approche intégrée du contrôle machine pour rendre le flux d'information facile mais qui rendent aussi facile le partage de cette information vers les serveurs IT. Une autre norme pilotée depuis l'Europe est OPC-UA [OPC Unified Architecture]. Ce protocole client-serveur s'est considérablement étendu, permettant un moyen universel de transférer des données soit machine-à-machine, machine-à-SCADA, ou machine-à-serveur. En raison de sa flexibilité, OPC-UA devient rapidement la norme IoT. Cherchez des fournisseurs qui ont des outils logiciels intégrés pour créer facilement une connexion OPC-UA en quelques clics et permettre aux développeurs de partager des données simplement en partageant quelques étiquettes dans un programme CEI 61131-3. Une fois accessible sur un serveur, laissez l'IT s'occuper du reste.

L'information est-elle utile dans le cloud ? Comment les données critiques arrivent-elles dans les mains de l'opérateur, sur le plancher d'usine ?

Cela dépend du cas d'utilisation. Quiconque pense à l'IIoT, qu'il soit opérateur machine, constructeur de machines OEM, ou propriétaire d'usine, devrait d'abord développer un cas d'utilisation. Un gestionnaire de plancher d'usine, par exemple, peut vouloir des informations d'efficacité globale des équipements [OEE]. Ce type d'information n'est généralement pas quelque chose à partager avec une sphère publique plus large, donc il est préférable d'utiliser un serveur interne. Cependant, les gestionnaires de plancher d'usine peuvent souvent être loin de la machine, ou pas à leur bureau, mais avoir encore besoin de regarder l'OEE. Le cas d'utilisation guide la solution : Si la machine a une IHM intégrée avec un serveur web, un utilisateur peut s'y connecter depuis une plateforme iOS ou Android, entrer ses identifiants, et voir l'OEE des machines, sans cloud externe nécessaire. Ce réseau dans l'usine est souvent appelé « fog » computing.

Un autre exemple est un agent d'achats qui doit surveiller les données de rendement pour plusieurs lignes d'usine dans plusieurs emplacements. Un serveur externe est la seule réponse. Pour minimiser le risque d'exposer des informations sensibles de l'entreprise, le programme peut publier seulement la sortie totale, plutôt que les rendements. Bien que cette solution exige l'utilisation d'un serveur cloud, elle illustre le besoin de retenue lors de l'envoi de données vers un serveur externe pour deux raisons : généralement, c'est moins sûr que de le garder sur un réseau interne ou « fog », et la plupart des plans facturent aux entreprises l'envoi et le stockage de données vers un cloud externe.

Les marketeurs ont fait un excellent travail en promouvant l'Industrie 4.0, mais chaque utilisateur doit prendre du recul et se demander : « Comment puis-je utiliser l'information ? » Le cloud n'est peut-être pas aussi nécessaire que vous pourriez le penser.

Toute cette connectivité ne fait-elle pas monter les coûts ?

Cela peut, mais ce n'est pas obligé. Là où ça devient cher, c'est dans trois ou quatre ans, quand votre entreprise est prête pour l'IoT, mais que vous avez spécifié des dispositifs qui rendent difficile ou impossible la communication via serveur web ou OPC-UA, ou que vous avez choisi un design traditionnel fragmenté plutôt que des PAC mono-machine qui rendent le flux de données significativement plus facile. Pour atténuer cette erreur, vous pouvez acheter des capteurs incroyablement chers qui vont du contrôle de température directement vers un cloud externe, en contournant tous les autres dispositifs sur la machine. De là, vous devrez programmer toute une couche personnalisée ou site web en utilisant le logiciel de quelqu'un d'autre pour rendre les données utiles. Vous ne voulez pas être ce gars-là.

Au lieu de cela, déployez l'IIoT intelligemment : faites-en partie du design de la machine dès le premier jour. Si vous construisez une nouvelle application, vous êtes dans la position parfaite pour faire la transition, même si ce n'est pas quelque chose que votre organisation envisage pour l'instant. Les choix que vous faites aujourd'hui peuvent économiser des centaines de milliers de dollars plus tard.

Sélectionnez aussi des dispositifs de bas niveau qui supportent des bus comme IO-Link pour pouvoir en sortir des données à moindre coût. Utilisez des protocoles standards qui sont rentables et vous permettent d'utiliser des données de nombreuses sources. Utilisez un seul logiciel de programmation sur un seul contrôleur pour simplifier la programmation. Assurez-vous que le contrôleur machine a la capacité d'une relation client-serveur sans nécessairement exiger une passerelle supplémentaire. Ainsi, si vous avez besoin de commencer à router l'information vers différents endroits, vous pouvez le faire directement dans votre programme basé sur CEI. N'oubliez pas le fog computing. Si votre PLC a une IHM intégrée qui est capable de serveur web, vous pourriez être capable de satisfaire tous vos cas d'utilisation IIoT sans utiliser de cloud du tout. Et si vous en avez besoin, assurez-vous que le contrôleur que vous choisissez a un logiciel qui rend facile le partage vers un serveur OPC-UA, pour que l'IT puisse faire ce que l'IT fait de mieux.

Des choix intelligents rendent la conversion à l'IIoT très abordable, mais les choix doivent être faits maintenant.