Étude de cas : Premiers pas vers l'industrie 4.0 dans une petite installation de production

Auteur invité Nouvelles de l'entreprise, Connecteurs, Généralités Laissez un commentaire

L'IIoT et Industry 4.0 sont des sujets omniprésents dans les salons professionnels et les articles de blog de l'industrie d'aujourd'hui. De nombreux produits promettent de vous aider à réaliser l'intégration verticale des flux de production et des données, ainsi que des logiciels d'entreprise comme les ERP. Mais généralement, il y a aussi un hic : soit vous obtenez des produits très complexes dont le prix est tout aussi choquant - ou malgré IIoT's la promesse d'une interopérabilité totale entre les fournisseurs que vous verrouillé par le vendeursurtout si l'on considère les solutions logicielles vendues par les vendeurs 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, j'aimerais montrer comment le Connecting Software Plate-forme d'intégration Connect Bridge aide à combler cette lacune et fournit une boîte à outils facile à utiliser pour commencer rapidement à développer des Les solutions de l'IIoT.  

Sur le client et ses exigences

Le client est un petit fournisseur industriel qui fournit principalement des produits en tôle d'acier inoxydable avec des lots de petite taille (jusqu'à un seul) et un portefeuille de produits complexe.  

Pour pouvoir concurrencer les 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 robotisé au laser dans le processus de productions. Si le soudage au laser à semi-conducteurs présente de nombreux avantages, tels qu'une distorsion plus faible, une post-production de joints de soudure faible ou nulle, etc., il s'agit également d'un processus difficile à mettre en œuvre en raison de son besoin inhérent de précision et d'autres exigences complexes.  

Un autre défi consiste à intégrer une telle solution de soudage robotisée dans la planification de la production, à obtenir les données nécessaires pour le (post) calcul des coûts, le contrôle de la qualité, etc.  

Malgré l'essor de la robotique collaborative et donc l'imprégnation de ces applications dans la production, elles sont aujourd'hui principalement utilisées pour des tâches très répétitives avec très peu de changement dans les produits/processus traités. Par conséquent, le choix d'un logiciel de planification de la production qui réponde aux besoins de mon client est pratiquement inexistant, d'où la nécessité d'une solution personnalisée qui s'accroît avec l'adaptation continue du processus de soudage au laser dans sa chaîne de fabrication.  

Les exigences en bref : 

  • Acquisition de données du système de soudage robotisé (et de ses composants respectivement) à des fins de calcul (post) des coûts, de contrôle de la qualité, de planification de la production
  • Intégration de ces données dans l'environnement ERP personnalisé du client
  • Fournir un outil de planification de la production pour le soudage robotisé qui est ouvert à des améliorations futures (par exemple, programmation hors ligne)
  • Une solution adaptable qui évolue avec l'entreprise
  • Éviter le verrouillage des fournisseurs et maintenir la complexité et les besoins de maintenance de l'ensemble de l'écosystème logiciel aussi bas que possible

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.  

Avec une migration en cours vers Microsoft Windows 10 et Office 365, des sujets comme la mise en œuvre de SharePoint ou OneDrive dans les processus informatiques de l'entreprise peuvent être intéressants.   

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 longue. Par conséquent, toutes les machines ne sont pas équipées pour les applications de l'industrie 4.0 ou n'offrent qu'une fonctionnalité très limitée dans ce domaine. Le présent document se concentre donc 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 allemand bien connu. Il se compose d'une source laser à semi-conducteurs, d'un robot avec table rotative inclinable, d'une tête d'usinage avec système de caméra, d'une cellule de protection nécessaire pour les applications laser de haute puissance, de systèmes de contrôle et de systèmes auxiliaires (aspiration, dépoussiérage, refroidissement).  

Les composants de ce système communiquent via une variété d'interconnexions industrielles standard (E/S numériques, Profinet, EtherCat, standard ethernet). Selon les spécifications du vendeur, une seule interface ethernet standard est exposée vers l'infrastructure de réseau du client. Cette interface est connectée au système PLC global des vendeurs de machines et n'offre qu'un accès très limité aux données et au système de contrôle des machines. Il offre une interface OPC UA avec seulement quelques points de données (moins de 10) disponibles. Et ils ne sont alimentés que si l'usine utilise le logiciel de planification de la production du vendeur de la machine, qui tourne sur l'automate de la machine. Par conséquent, cette interface s'est avérée peu utile pour mon client maintenant. Cette situation pourrait changer. Cependant, comme cette interface OPC UA exposée est un travail en cours, elle obtiendra probablement des fonctionnalités plus utiles avec les futures mises à jour. 

Mais comme de nombreux sous-composants des machines utilisent l'ethernet standard comme méthode de communication, un accès plus large est possible. Les réseaux internes des machines permettent d'atteindre les automates du robot, la source laser et le système de caméra des têtes de soudage. Mais sans autre modification, tous n'offrent pas les outils nécessaires pour permettre un accès facile à l'OPC UA.  

Les premiers pas

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

Le contrôle direct de ces systèmes via le Connect Bridge (CB) n'est pas une cible, car il pourrait potentiellement violer le principe du point de contrôle unique nécessaire à la sécurité des machines.  CB fournit une interface facile à utiliser avec la norme OPC UA qui est de plus en plus courante dans les automates et les machines d'aujourd'hui. Si cette norme peut ê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 les 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 donc en contradiction avec l'objectif de réduction de la complexité.  

Par conséquent, le choix est tombé sur la Connect Bridge avec ses avantages de installation facile, SQL sans problème interface basée sur l'OPC UA, mais aussi à d'autres services locaux et en nuage, et des prix extrêmement compétitifs

Fréquence des sondages de données

Dans cette usine, la nouvelle technologie passe par un processus d'adaptation, si bien 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 de prévision. Cette approche est basée sur l'expérience du client avec des données recueillies 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 fausse, et qu'une granularité fine n'est pas toujours nécessaire pour juger de l'efficacité du processus de production. 

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

Dans cette première étape, le client veut sonder les données de ces 3 composantes principales :  

  • 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, l'automate du robot et le système de caméra étant indisponibles pour des raisons qui leur sont propres.  

Pourquoi le robot PLC ne peut pas se connecter

L'automate du robot est accessible via ethernet, mais il utilise une interface OPC héritée. En raison de contraintes logicielles imposées par son fabricant, il ne peut pas exécuter l'interface utilisateur OPC. Une interface OPC - OPC UA pourrait permettre de remédier à cette situation, mais sans le feu vert du fabricant de la machine en termes de compatibilité, l'installation d'un tel logiciel ne semble pas réalisable. Pour l'instantle client met au point une solution de contournement : les entrées/sorties numériques de l'API du robot seront connectées via un PC industriel pour obtenir des informations précises (par exemple, quand un processus de production a été lancé ou terminé) et pour déclencher une fenêtre d'acquisition de données plus étroite.  

Pourquoi la caméra ne peut pas se connecter

Le système de caméra est lié à l'automate de la machine entière et ne semble pas être accessible aux clients extérieurs. Comme la vision serait utile à des fins de contrôle de la qualité et de documentation des processus, l'utilisation d'un système de caméra externe supplémentaire est actuellement en cours d'évaluation pour résoudre ce problème.

OPC UA pour la source laser

Il reste la source laser. Heureusement, ce système est équipé de un contrôleur de pointe qui intègre une interface OPC UA sophistiquée avec plusieurs niveaux d'accès : accès anonyme avec des 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é des machines. C'est pourquoi 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

Avec le CB, le client a développé un service Windows dans le C# pour interroger périodiquement les données et les compiler dans plusieurs tables de base de données SQL pour une utilisation future. 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.  

Mais comment appliquer ces données ? 

Une grande question : comment utiliser les données des machines

La première information utile est le compilation du message du journal de la machines. L'expérience de mon client dans le passé était que toutes les machines ne conservent pas leurs fichiers journaux lors des redémarrages. En outre, les opérateurs de machines ne signalent pas toujours avec précision les dysfonctionnements et les erreurs à leurs supérieurs. Cela peut entraîner des temps d'arrêt plus longs que nécessaire des machines lorsqu'un dysfonctionnement grave se produit. Si la machine fonctionnait ce jour-là - est une question 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 sûr, il ne s'agit actuellement que d'une application très limitée de l'immense capacité du CB. Les prochaines étapes que le client est en train de développer sont les suivantes :  

  • 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 feuille de temps de l'entreprise, cela permettra de mieux comprendre le temps que la machine passe actuellement en la production et le temps consacré à l'enseignement (programmation des robots) et/ou au chargement/déchargement/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. Mais avec peu d'efforts initiaux, un démonstrateur utile pour le client pourrait être développé en s'appuyant sur le les puissantes capacités du Connect Bridge. En tant que développeur, cela m'a aidé en m'évitant de devoir entrer dans les détails d'une autre pile de connexion (comme l'OPC UA ou l'API Dropbox). Et pour mon client, il a fourni une pile de communication centralisée pour les applications futures, qui est également très compétitif par rapport aux solutions d'autres fournisseurs qui présentent parfois des configurations de licence compliquées avec des licences basées sur le nombre d'appareils auxquels son outil accède et même le nombre de points de données acquis. 

Abréviations utilisées

CB - le Connect Bridge plate-forme d'intégration

PLC - Contrôleur logique programmable 
Généralement un système informatique capable de fonctionner en temps réel avec une puissance de traitement relativement faible (par rapport aux appareils PC standard) avec des interfaces de bus de terrain industriel et des E/S numériques utilisées pour contrôler les machines. 

IIoT - l'Internet industriel des objets 

OPC UA - Architecture unifiée de l'OPC 

CAO - Conception assistée par ordinateur 

FAO - Fabrication assistée par ordinateur 

Contexte

Cette étude de cas analyse l'application du protocole OPC UA pour la collecte de données actualisées sur les machines dans une petite usine de production en Autriche. Un Connecteur OPC UA construit sur la Plate-forme d'intégration Connect Bridge par Connecting Software a été utilisé pour extraire les données des machines dans des tableaux de rapport afin d'assurer la maintenance des équipements en temps voulu dans l'installation de production. La plate-forme d'intégration accepte des requêtes SQL simples de type Create, Read, Update and Delete (CRUD) par l'intermédiaire de pilotes ODBC, JDBC et Web Services standard. Ces requêtes sont then translated vers l'API standard calls native vers le système cible. Un certain nombre de connecteurs préconstruits permettent de livrer ces données aux systèmes ERP, MES, CRM, DMS, etc. pour une exploitation ultérieure. 

À propos de l'auteur

Richard Majer, Fondateur de flupo Systemtechnik e.U. spécialisée 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 les 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 de bus de terrain industriels). Il a plus de 10 ans d'expérience en informatique générale avec un accent sur le développement de logiciels dans les environnements des PME (interfaces entre différents logiciels, applications de planification de la production). Il est titulaire de Maîtrise diplôme en mathématiques de l'université de Vienne 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *