La conception de logiciels de contrôle intelligent et d'IHM aide les ingénieurs à créer de nouveaux réseaux pour l'IIoT

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

Marissa, quel est le rôle du contrôleur de mouvement dans l'Internet industriel des objets [IIoT], et quel logiciel est impliqué ?

J'irais au-delà du contrôleur de mouvement et dirais que le contrôleur d'automatisation programmable [PAC] joue le rôle le plus important dans l'IIoT. En effet, en plus d'avoir la logique de la machine, les PAC incluent le contrôle de mouvement dans le cadre de leurs routines et ont souvent une interface homme-machine [HMI] intégrée. La beauté de cette approche est que le programme n'a pas besoin de partager des balises entre les appareils car les composants sont sur le même appareil en utilisant la même logique. Non seulement cela réduit considérablement le temps de programmation, mais cela facilite également les capacités IIoT.

Voici un exemple :L'erreur de position, qui était auparavant 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 d'entre elles font, l'IHM peut immédiatement envoyer une alerte à l'opérateur local et également à un directeur d'usine par e-mail ou SMS [service de messages courts]. C'est bien mieux que l'approche traditionnelle consistant à faire en sorte que le contrôleur de mouvement envoie l'erreur à l'automate [automate programmable industriel], l'automate devant alors traiter les données uniquement pour les envoyer à l'IHM, qui peut ou non avoir un serveur Web. Ce transfert de données complexe entre les appareils est éliminé, car la logique est écrite sur un logiciel de programmation téléchargé sur un appareil matériel. Il est si étroitement intégré que vous pouvez facilement obtenir des informations n'importe où.

Il est essentiel de s'assurer que le développeur qui crée l'IHM intégrée peut créer différents groupes d'utilisateurs et informations d'identification. Cela permet au programmeur de créer une instance personnalisée de l'IHM, en fonction de l'utilisateur.

La facilité de circulation des informations au sein de la machine est importante, mais la facilité de circulation des informations entre les machines l'est tout autant. La norme de programmation CEI 61131-3 garantit 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 dialoguer deux systèmes de machines différents, une étape nécessaire vers l'IIoT. Des organisations comme OMAC [Organisation pour l'automatisation et le contrôle des machines], qui fait la promotion de la norme PackML, font passer la norme CEI 61131-3 au niveau supérieur en recommandant non seulement la manière dont un système doit être programmé, mais également en développant un ensemble standard de balises qui machines devrait mettre à la disposition des autres machines du réseau.

Qu'en est-il des dispositifs de bas niveau, tels que les vannes pneumatiques et les capteurs de position ? Tout n'est-il pas censé faire partie de l'IdO ?

Le défi consiste à extraire des données d'appareils de bas niveau et à les transformer en informations utiles. Une approche consiste à effectuer le traitement au niveau de ces appareils, puis à envoyer les résultats soit via un bus de contrôle hautes performances, soit directement dans le cloud. Cette approche est très coûteuse et ne permet pas de collecter ou de centraliser les données. Alternativement, nous constatons une énorme croissance de la popularité d'IO-Link, un protocole série qui peut collecter des données de base à partir de capteurs de température, de solénoïdes, de collecteurs de vannes pneumatiques, etc., sans frais généraux coûteux.

En laissant le bus simple, ces données peuvent être collectées et rendues utiles par un traitement sur le PAC ou l'automate qui doit exister dans chaque système de machine. En optant pour un PAC, qui dispose également d'une IHM intégrée pour la publication Web, les utilisateurs peuvent ensuite prendre ces informations et les mettre sur le réseau, où qu'elles soient. Imaginez un système pneumatique avec un capteur surveillant en continu le son en décibels. La seule donnée à envoyer à une PAC IO-Link est le dB actuel. Le PAC peut avoir des blocs fonctionnels CEI 61131-3 personnalisés développés par le fabricant qui peuvent fonctionner sur plusieurs contrôleurs. Ces blocs fonctionnels peuvent vérifier s'il y a un motif étrange 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 de maintenance de l'IHM avant que le système pneumatique ne tombe en panne. .

Comment les informations sont-elles transmises de la machine au cloud, et qu'en est-il des logiciels impliqués ?

Il existe toujours une grande division entre l'usine et l'informatique. Surtout pour les entreprises de fabrication avec plusieurs installations dans différents états ou pays, le stockage des données sur un serveur externe ou dans le cloud est idéal. Du côté des logiciels, les fabricants de composants doivent contribuer à rendre la vie des constructeurs de machines aussi simple que possible lorsqu'ils travaillent avec l'informatique.

La plupart des constructeurs de machines sont à l'aise avec la programmation d'un API ou d'un PAC dans des langages CEI ou similaires. Les entreprises doivent donc rechercher des fabricants qui adoptent une approche intégrée du contrôle des machines pour faciliter le flux d'informations. mais qui facilitent également le partage de ces informations avec les serveurs informatiques. Un autre standard chassé d'Europe est OPC-UA [OPC Unified Architecture]. Ce protocole client-serveur s'est considérablement développé, offrant un moyen universel de transférer des données de machine à machine, de machine à SCADA ou de machine à serveur. En raison de sa flexibilité, OPC-UA devient rapidement la norme IoT. Recherchez des fournisseurs qui disposent d'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 balises au sein d'un programme CEI 61131-3. Une fois qu'il est accessible sur un serveur, laissez le service informatique s'occuper du reste.

Les informations sont-elles utiles dans le cloud ? Comment les données critiques arrivent-elles entre les mains de l'opérateur, dans l'usine ?

Cela dépend du cas d'utilisation. Quiconque pense à l'IIoT, qu'il soit opérateur de machine, constructeur de machine OEM ou propriétaire d'usine, doit d'abord développer un cas d'utilisation. Un directeur d'usine, par exemple, peut vouloir des informations sur l'efficacité globale de l'équipement [OEE]. Ce type d'informations n'est généralement pas quelque chose qui doit être partagé avec une sphère publique plus large, il est donc préférable d'utiliser un serveur interne. Cependant, les responsables d'usine peuvent souvent être loin de la machine, ou ne pas être à leur bureau, mais doivent quand même regarder l'OEE. Le cas d'utilisation pilote la solution :si la machine dispose d'une IHM intégrée avec un serveur Web, un utilisateur peut s'y connecter à partir d'une plate-forme iOS ou Android, entrer ses informations d'identification et afficher l'OEE des machines, aucun cloud externe n'est nécessaire . Ce réseau en usine est souvent appelé "fog computing".

Un autre exemple est un agent d'achat 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 sur l'entreprise, le programme peut publier uniquement la production totale, plutôt que les rendements. Bien que cette solution nécessite l'utilisation d'un serveur cloud, elle illustre la nécessité de faire preuve de modération lors de l'envoi de données vers un serveur externe pour deux raisons :généralement, c'est moins sécurisé que de les conserver sur un réseau interne ou "fog", et la plupart des plans facturer aux entreprises l'envoi et le stockage de données vers un cloud externe.

Les spécialistes du marketing ont fait un excellent travail de promotion de l'Industrie 4.0, mais chaque utilisateur doit prendre du recul et se demander :"Comment puis-je utiliser les informations ?" Le cloud n'est peut-être pas aussi nécessaire comme vous pourriez le penser.

Toute cette connectivité n'augmente-t-elle pas les coûts ?

C'est possible, mais ce n'est pas obligatoire. Là où cela devient cher, c'est dans trois ou quatre ans, lorsque votre entreprise est prête pour l'IoT, mais que vous avez spécifié des appareils qui rendent difficile ou impossible la communication via un serveur Web ou OPC-UA, ou que vous avez choisi une conception fragmentée traditionnelle plutôt que des PAC à une seule machine qui facilitent considérablement le flux de données. Pour atténuer cette erreur, vous pouvez acheter des capteurs incroyablement coûteux qui passent du contrôle de la température directement à un cloud externe, en contournant tous les autres appareils de la machine. À partir de là, vous devrez programmer toute une couche personnalisée ou un site Web en utilisant le logiciel de quelqu'un d'autre pour rendre les données utiles. Tu ne veux pas être ce gars.

Déployez plutôt l'IIoT intelligemment :intégrez-le à la conception de la machine dès le premier jour. Si vous créez une nouvelle application, vous êtes dans la position idéale pour effectuer la transition, même si ce n'est pas quelque chose que votre organisation envisage actuellement. Les choix que vous faites aujourd'hui peuvent vous faire économiser des centaines de milliers de dollars plus tard.

Sélectionnez également des périphériques de bas niveau prenant en charge des bus tels que IO-Link afin de pouvoir en extraire des données à moindre coût. Utilisez des protocoles standard qui sont rentables et vous permettent d'utiliser des données provenant de nombreuses sources. Utilisez un seul logiciel de programmation sur un seul contrôleur pour simplifier la programmation. Assurez-vous que le contrôleur de la machine a la capacité d'établir une relation client-serveur sans nécessairement nécessiter une autre passerelle supplémentaire. De cette façon, si vous avez besoin de commencer à acheminer des informations vers différents emplacements, vous pouvez le faire directement dans votre programme basé sur IEC. N'oubliez pas le calcul du brouillard. Si votre API dispose d'une IHM intégrée compatible avec un serveur Web, vous pourrez peut-être satisfaire tous vos cas d'utilisation IIoT sans utiliser de cloud. Et si vous en avez besoin, assurez-vous que le contrôleur que vous choisissez dispose d'un logiciel qui facilite le partage avec un serveur OPC-UA, afin que le service informatique puisse faire ce qu'il fait le mieux.

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