É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 professionnels et les articles de blog actuels. De nombreux produits promettent de vous aider à réaliser une intégration verticale des flux et des données de production et des logiciels d'entreprise tels que les ERP. Mais généralement, 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 d'une interopérabilité totale entre les fournisseurs, vous vous retrouvez bloqué par les fournisseurs, en particulier si vous envisagez des solutions logicielles vendues par les fournisseurs de machines de production en même temps que leurs équipements.

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 naturellement développé et donc intrinsèquement complexe. À sa base, il utilise un ancien système ERP qui est étendu par des applications web PHP personnalisées et des interfaces vers d'autres logiciels (par exemple, CAO, FAO comme le logiciel d'imbrication laser, ...) et des systèmes clients pour l'échange direct de données. Tout cela dans un environnement de serveur mixte Windows/Linux et un ensemble de clients presque exclusivement basés sur Windows dans un Active Directory. Les services de fichiers sont principalement basés sur les 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 (IOs numériques, Profinet, EtherCat, ethernet standard). Selon les spécifications du fournisseur, seule une interface Ethernet standard est exposée à l'infrastructure 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 remplis 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 s'est avérée ne pas être trop 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 courant 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 compliqués et donc en contradiction avec l'objectif de réduction de la complexité.

Ainsi, au lieu d'un codage personnalisé, le client opte pour une plateforme d'intégration dotée d'un connecteur OPC UA préconstruit, d'une interface facile à utiliser et de la possibilité de se connecter à des systèmes de back-office tels qu'ERP, CRM, divers systèmes de gestion de documents ou bases de données - locaux ou en nuage - et d'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. Ceci est basé sur l'expérience du client avec les données récoltées sur d'autres machines de production, par exemple des machines de découpe 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 que la granularité fine n'est 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, pour l'instant, seule la source laser peut être connectée. D'autres composants ne peuvent pas être intégrés : l'automate du robot ne dispose que de 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 toute la machine et ne semble pas accessible aux clients extérieurs.

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. L'expérience de mon client dans le passé était que toutes les machines ne conservent pas leurs fichiers journaux pendant les redémarrages. De plus, 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 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 que la direction technique de l'entreprise puisse y accéder facilement, ces rapports quotidiens sont générés sous forme de fichiers PDF et stockés dans une boîte de dépôt partagée, au cas où un appel d'assistance au vendeur de la machine devrait s'ouvrir.

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 E/S numériques si ce n'est pas possible autrement) pour obtenir un calendrier précis de démarrage/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/la maintenance ;

Accès au système de caméras : comme le soudage au laser est un procédé de soudage différent, les clients de mon client doivent certifier cette méthode de production avant de livrer des produits réels. Ces processus seront beaucoup plus faciles à réaliser si une documentation complète du processus de soudage peut être fournie en permanence et automatiquement.

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 d'automates programmables, les systèmes de bus de terrain industriels). 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.