Projets IIoT pour manufacturiers

Mise à jour :

Formuler un besoin mesurable avant l’architecture

L’Internet industriel des objets regroupe des moyens de collecte et d’échange appliqués à des actifs et à des opérations industriels. Le projet n’est pas défini par le nombre de capteurs. Une PME peut chercher à détecter une dérive de température, à comprendre une perte de production ou à suivre un équipement mobile. Précisez ce que l’équipe fera lorsqu’une condition apparaît et quelle information lui manque aujourd’hui.

Dans un exemple de procédé, un four peut nécessiter le suivi de températures pour expliquer des variations observées. Il faut définir les emplacements, les unités, la fréquence et les limites d’interprétation. Une valeur hors plage peut provenir du procédé, du capteur ou de la transmission. Les responsables métier doivent distinguer ces situations avant de demander des alertes. Sans action et sans personne disponible, la collecte crée un historique qui risque de rester inutilisé.

Choisir les capteurs et le traitement local

La mesure doit correspondre à la grandeur recherchée et aux conditions physiques. Vérifiez la plage, la précision nécessaire, l’installation, l’étalonnage et le maintien du capteur. Une mesure indirecte peut être utile, mais elle doit être validée contre une référence adaptée. Le choix doit tenir compte des vibrations, de la chaleur, du nettoyage et des déplacements, selon le poste concerné.

Une passerelle ou un traitement local peut filtrer, agréger et conserver temporairement les données. Décidez ce qui doit rester disponible sans connexion externe et ce qui peut être transmis plus tard. Le traitement près de l’équipement ne rend pas automatiquement le projet plus sûr ni plus fiable : ses mises à jour et ses règles doivent être gérées. Conservez les informations nécessaires pour expliquer un événement sans envoyer systématiquement toutes les données brutes à une plateforme distante.

Structurer les événements et les échanges

Les données doivent porter des identifiants stables, des horodatages et des unités. Un nom de capteur sans contexte peut devenir incompréhensible après un remplacement ou un déplacement. Définissez les références d’équipement, les états et les règles de correction. Le rapprochement avec les ordres ou les lots demande aussi une source fiable pour le contexte de production. Une mesure seule ne permet pas toujours d’attribuer une variation à un produit.

Les interfaces peuvent utiliser OPC UA, MQTT ou d’autres moyens adaptés. Faites préciser le format et les conditions d’échange entre les composants. Testez les messages perdus, répétés et tardifs. Les garanties du protocole ne prouvent pas que l’application a correctement interprété l’événement. La plateforme doit indiquer les données incomplètes et permettre leur traitement selon une règle documentée. Le fonctionnement nominal n’est qu’une partie du projet ; les interruptions révèlent sa capacité à rester exploitable.

Intégrer la sécurité et la maintenance dès le pilote

Une nouvelle connexion doit être évaluée dans le contexte du réseau industriel et des contraintes de procédé. Définissez les flux nécessaires, les accès et les responsabilités. Limitez les communications inutiles et protégez les identifiants de service. Les méthodes de sécurité utilisées dans un environnement bureautique ne peuvent pas être appliquées aveuglément à des équipements dont la disponibilité et la sûreté sont prioritaires.

Maintenez un inventaire des composants et un plan de soutien. Vérifiez comment les certificats, les mises à jour et les sauvegardes sont gérés. Un capteur dont la batterie est vide ou une passerelle devenue inaccessible peut rendre l’information trompeuse sans arrêter la production. Les personnes responsables doivent pouvoir repérer ces états. Prévoyez une manière de désactiver la collecte ou de remplacer un composant sans perturber la commande de l’équipement ni perdre les données essentielles.

Valider la valeur et élargir avec méthode

Le pilote doit comparer les mesures avec une observation de référence et vérifier la pertinence des décisions. Définissez ce qui constitue une alerte utile, une fausse alerte et une donnée non exploitable. Si le projet vise une maintenance conditionnelle, une tendance n’est pas une prédiction garantie de panne. L’interprétation doit être validée avec les personnes qui connaissent l’équipement et les limites du signal.

Évaluez ensuite le coût des capteurs, des services, du stockage, des interfaces et de l’administration. L’extension à plusieurs ressources peut nécessiter des installations et des règles différentes. Documentez le modèle retenu et les variantes autorisées. Les progrès doivent être mesurés sur des périodes comparables et rester attribués avec prudence. Un projet IIoT réussi fournit une information fiable et une pratique opérationnelle durable ; la connectivité seule n’est pas une preuve d’amélioration de la performance de l’usine.

Sujets associés

  • Calculer le TRG (OEE)

    Pour calculer l’OEE, multipliez la disponibilité, la performance et la qualité avec des données prises sur le même périmètre. Définissez les temps de référence avant de parler de TRG, car les conventions françaises de TRG et de TRS ne sont pas toujours équivalentes à l’OEE. Utilisez les pertes détaillées pour choisir une action au plancher plutôt que comparer un pourcentage isolé à une cible universelle.

  • Connecter ses machines pour mesurer le TRG

    Une machine ancienne peut être suivie avec des signaux disponibles, des capteurs externes et une passerelle sans modifier son contrôle. Commencez par distinguer les états, les cycles et les quantités, puis validez leur sens avec les opérateurs. Utilisez OPC UA ou MQTT selon l’architecture retenue, avec des accès limités et un traitement explicite des interruptions.

  • Tableaux de bord de production numériques

    Un tableau de bord de production utile indique un écart, son contexte et la personne qui peut agir. Choisissez quelques mesures compréhensibles par quart et affichez leur fraîcheur ainsi que les limites de collecte. Organisez le suivi au plancher avant d’ajouter des graphiques ou des alertes qui ne déclenchent aucune décision.

Questions fréquentes

IIoT signifie-t-il envoyer toutes les données dans le nuage ?

Non. Une partie du traitement peut rester locale. L’architecture dépend de la décision, des contraintes de disponibilité, des échanges et des exigences de protection.

Des capteurs permettent-ils de prédire toutes les pannes ?

Non. Les signaux et les modèles ont des limites. Une démarche de maintenance conditionnelle doit être validée sur l’équipement et ne remplace pas les contrôles requis.

Quelle différence entre IIoT et MES ?

L’IIoT décrit des moyens de collecte et d’échange ; un MES relie davantage l’exécution aux ordres et aux preuves de production. Ils peuvent se compléter sans être équivalents.

Quand élargir le projet à d’autres machines ?

Lorsque le pilote démontre une donnée fiable, un usage utile et un soutien maîtrisé. Vérifiez les différences de procédé et de connexion avant de reproduire l’installation.

Termes du glossaire

Références

Benoît Cormier

Expert certifié NUMERI, GLM Conseil — 18 ans en productivité et intégration technologique manufacturière