Étude de cas : Premiers pas vers l'IIoT dans l'environnement d'une PME

L'IIoT et l'industrie 4.0 sont des sujets omniprésents dans les salons industriels et les articles de blog d'aujourd'hui. De nombreux produits promettent de vous aider à réaliser l'intégration verticale des flux et des données de production et des logiciels d'entreprise tels que les ERP. Mais en général, il y a aussi un piège : soit vous obtenez des produits très complexes avec une étiquette de prix tout aussi choquante - soit, malgré la promesse de l'IIoT d'une interopérabilité totale entre les fournisseurs, vous vous retrouverez bloqué, en particulier si vous considérez les solutions logicielles qui sont vendues par les fournisseurs de machines de production en conjonction avec leur équipement.

Pour les petites entreprises aux ressources limitées et les départements informatiques de petite taille ou n'employant qu'une seule personne, c'est un dilemme. Alors que ces entreprises comptent sur la flexibilité pour concurrencer les grandes entreprises et doivent donc adopter des paradigmes comme Industry 4.0, cela s'accompagne généralement d'un investissement énorme et d'un mur d'une complexité technique apparemment insurmontable.

Dans cette étude de cas, tout d'abord, je montrerai comment une plateforme d'intégration logicielle avec des connecteurs préconstruits pour la communication des données machine peut aider à surmonter ces limitations. Et deuxièmement, quelles peuvent être les premières applications pratiques pour les données machine en temps réel dans une petite usine qui commence son voyage vers l'Internet industriel des objets.

Sur le client et ses exigences

Le client est un fournisseur de la petite industrie qui fournit principalement des produits en tôle d'acier inoxydable, avec des lots de petite taille et un portefeuille de produits complexe.

Pour pouvoir rivaliser avec d'autres fabricants dans ce domaine, l'usine a besoin de progrès technologiques et d'une évolution constante du processus de production. Par conséquent, le client a commencé à introduire le soudage laser robotisé de pointe dans le processus de production.

Outre le processus lui-même, l'intégration d'une telle solution de soudage robotisé dans la planification de la production, l'obtention des données nécessaires au calcul des coûts, le contrôle de la qualité, etc. constituent un autre défi.

L'environnement informatique du client

Le paysage informatique des clients est un paysage qui s'est développé naturellement et qui est donc intrinsèquement complexe. À la base, il utilise un ancien système ERP qui est étendu par des applications web PHP personnalisées et des interfaces avec d'autres produits logiciels (par exemple, CAO, FAO comme le logiciel d'imbrication laser, ...) et les systèmes des clients pour l'échange direct de données. Tout cela dans un environnement de serveur mixte Windows/Linux et un pool de clients presque exclusivement basés sur Windows dans un Active Directory. Les services de fichiers sont principalement basés sur des partages Windows et (dans une moindre mesure) sur Dropbox.

En général, la stratégie du client consiste à réduire la complexité de son infrastructure informatique en essayant de réduire la quantité de technologies différentes utilisées (piles LAMP, AD, Windows, O365, systèmes hérités, etc.), ce qui augmente la gérabilité et réduit les coûts de maintenance de l'ensemble de l'écosystème.

L'environnement de production

Les machines de production ont généralement une durée d'utilisation intrinsèquement longue. Par conséquent, toutes les machines ne sont pas équipées pour les applications de l'industrie 4.0 ou offrent des fonctionnalités très limitées dans ce domaine. Par conséquent, cet article se concentre uniquement sur l'application de soudage robotisé et ses besoins d'intégration.

Le système de soudage est une solution clé en main d'un fabricant réputé, comprenant une source laser à semi-conducteurs, un robot avec table rotative et inclinable, une tête d'usinage avec un système de caméra, une cellule de protection nécessaire aux applications laser à haute puissance, des systèmes de contrôle et des systèmes auxiliaires (aspiration, dépoussiérage, refroidissement).

Les composants de ce système communiquent via une variété d'interconnexions industrielles standard (IO numériques, Profinet, EtherCat, Ethernet standard). Selon les spécifications du fournisseur, seule une interface Ethernet standard est exposée à l'infrastructure du réseau du client. Cette interface est connectée au système PLC global du fournisseur de la machine et n'offre qu'un accès très limité aux données et au système de contrôle de la machine. Elle offre une interface OPC UA avec moins de 10 points de données qui ne sont renseignés que si l'usine utilise le logiciel de planification de la production du fournisseur de la machine fonctionnant sur l'automate de la machine. Par conséquent, cette interface ne s'est pas révélée très utile pour mon client actuellement, mais la situation pourrait changer.

Les premiers pas

Dans un premier temps, l'objectif était d'acquérir des données directement à partir des composants de la machine.

Le client a choisi le protocole de communication OPC UA, qui est de plus en plus répandu dans les automates et les machines d'aujourd'hui. Bien que cette norme puisse être utilisée pour établir une communication en temps réel et donc remplacer les fonctions actuellement mises en œuvre par les systèmes de bus de terrain industriels, dans notre scénario, les capacités en temps réel ne sont pas nécessaires. Bien que des SDK soient disponibles pour l'intégration directe de la pile OPC UA dans l'application de mon client, ils sont généralement complexes et vont donc à l'encontre de l'objectif de réduction de la complexité.

Ainsi, au lieu d'un codage personnalisé, le client opte pour une plateforme d'intégration qui dispose d'un connecteur OPC UA préconstruit avec une interface facile à utiliser et la possibilité de se connecter à des systèmes de back-office tels que ERP, CRM, divers systèmes de gestion de documents ou bases de données - locales et basées sur le cloud, et un prix raisonnable.

Le contrôle direct de ces systèmes via la plate-forme d'intégration n'est pas un objectif, car il pourrait potentiellement violer le principe du point de contrôle unique nécessaire à la sécurité des machines.

Fréquence des sondages de données

Dans cette usine, la nouvelle technologie est en cours d'adaptation, de sorte que le système de soudage robotisé ne fonctionne qu'en une seule équipe et que la machine ne fonctionne pas en permanence, même pendant les heures de travail. Par conséquent, les données acquises à ce stade peuvent être utiles, mais peuvent également s'avérer peu fiables pour une utilisation future ou à des fins prédictives. Ce constat est basé sur l'expérience du client en matière de données recueillies sur d'autres machines de production, par exemple des machines de découpe au laser. Certains facteurs - la présence ou non de l'opérateur de la machine à la fin d'un cycle de production, le moment où l'acquisition des données a été déclenchée - ont prouvé que même des données apparemment très précises pouvaient donner une image erronée et qu'une granularité fine n'était pas toujours nécessaire pour juger de l'efficacité du processus de production.

Ainsi, une fréquence d'interrogation plutôt faible de 30 secondes est actuellement utilisée pour l'acquisition des données.

Dans cette première étape, le client souhaite interroger les données de ces 3 principaux composants :

la source laser,

l'automate du robot,

le système de caméras.

Cependant, à l'heure actuelle, seule la source laser peut être connectée. D'autres composants ne peuvent pas être intégrés : l'automate du robot n'a que l'interface OPC Classic, et la transition vers l'architecture unifiée est difficile pour le moment ; le système de caméra est lié à l'automate de la machine entière et ne semble pas être accessible par des clients externes.

OPC UA pour la source laser

Il reste donc la source laser. Heureusement, ce système est équipé d'un contrôleur de pointe qui intègre une interface OPC UA sophistiquée avec plusieurs niveaux d'accès : accès anonyme avec capacités de lecture limitées, lecture seule, lecture et écriture. Comme mentionné précédemment, l'accès en lecture et écriture était hors de question pour des raisons de sécurité de la machine. Par conséquent, l'accès en lecture seule a été choisi.

Cette interface offre une pléthore de données :

État général du système laser

Périodes de fonctionnement, puissance utilisée, ...

Messages d'erreur et de maintenance

Grâce à la plate-forme d'intégration, le client a développé un service Windows dans C# pour interroger périodiquement les données et les compiler dans plusieurs tables de base de données SQL pour une utilisation ultérieure. Les tables peuvent fournir des informations telles que des données générales, l'utilisation de l'équipement, des tables pour les messages de maintenance/erreur produits par la source laser.

Une grande question : comment utiliser les données de cette machine ?

La première information précieuse est la compilation des messages du journal de la machine. D'après l'expérience de mon client, toutes les machines ne conservent pas leurs fichiers journaux pendant les redémarrages. En outre, les opérateurs de machines ne signalent pas toujours avec précision les dysfonctionnements et les erreurs à leurs superviseurs. Cela peut entraîner des temps d'arrêt de la machine plus longs que nécessaire lorsqu'un dysfonctionnement grave se produit. La question de savoir si la machine a fonctionné ce jour-là est importante.

Pour faciliter l'accès à la gestion technique de l'entreprise, ces rapports quotidiens sont générés sous forme de fichiers PDF et stockés dans une Dropbox partagée, au cas où un appel d'assistance au fournisseur de la machine devrait être lancé.

Bien entendu, il ne s'agit là que d'une application très limitée de l'immense capacité du connecteur OPC UA. Les prochaines étapes que le client est en train de développer sont :

Connexion à l'automate du robot (via des entrées/sorties numériques si cela n'est pas possible autrement) pour obtenir une synchronisation précise du démarrage et de l'arrêt des cycles de production.

En conjonction avec le système de feuilles de temps de l'entreprise, cela permettra de mieux comprendre combien de temps la machine est réellement en production et combien de temps est utilisé pour l'enseignement (programmation du robot) et/ou le chargement/déchargement/maintenance ;

Accès au système de caméras : étant donné que le soudage au laser est un processus de soudage différent, les clients de mon client doivent certifier cette méthode de production avant que des produits réels ne soient livrés. Ces processus seront beaucoup plus faciles à réaliser si une documentation complète du processus de soudage peut être fournie de manière constante et automatique.

De plus, avec la réduction prévue de la complexité et des services utilisés, le passage de Dropbox-Shared à OneDrive est imminent, une fois que tous les clients concernés auront été mis à contribution. Le client est également intéressé par une éventuelle analyse des données pour la maintenance prédictive.

Conclusion

Comme indiqué ci-dessus, ce projet est dans sa phase de démarrage et est encore loin d'être une solution IIoT pleinement fonctionnelle. L'utilisation d'une plateforme d'intégration avec des connecteurs prédéfinis au lieu de programmer l'ensemble de l'intégration m'a permis d'éviter d'avoir à entrer dans les détails d'une autre pile de connexion (comme OPC UA ou l'API Dropbox). Et pour mon client, cela a fourni une pile de communication centralisée pour les applications futures.

À propos de Richard Majer

Richard Majer, fondateur de flupo Systemtechnik e.U., spécialisé dans l'informatique industrielle et les technologies d'automatisation pour les PME. Avant de créer sa propre entreprise, Richard a travaillé dans un institut de R&D pour des applications laser de haute puissance (il a acquis de l'expérience dans la technologie laser, les simulations FEM, la robotique industrielle, la programmation PLC, les systèmes industriels de bus de terrain), et il a plus de 10 ans d'expérience dans l'informatique générale, avec un accent sur le développement de logiciels dans des environnements de PME (principalement des interfaces entre différents produits logiciels et des applications de planification de la production). Il est titulaire d'une maîtrise en mathématiques de l'université de Vienne.