Explication de la préparation des données de fabrication pour l'IA

La « préparation des données de production » désigne un état dans lequel les données opérationnelles ne sont pas seulement exactes, mais également contextualisées: chaque donnée (par exemple, la température) est automatiquement associée à son contexte (identifiant de l'opérateur, Ordre de travail, état de la machine) au moment de sa création, ce qui permet aux modèles d'IA de l'exploiter immédiatement sans qu'un nettoyage manuel soit nécessaire.

Pendant des années, on a fait croire aux fabricants que pour se préparer à l'intelligence artificielle, ils avaient besoin du « big data ». Ils ont donc dépensé des millions pour créer des lacs de données, en transférant des téraoctets de données de capteurs vers le cloud.

Aujourd'hui, la plupart de ces lacs sont en réalité de véritables « marécages de données ». Les données sont bien là, mais elles sont inutilisables. Pourquoi ? Parce qu'une mesure de vibration de 0,54 mm/s n'a aucun sens pour une IA si elle ne le sait pas quoi le produit fonctionnait, qui utilisait la machine, et si la machine était censée être à l'arrêt.

La préparation des données n'est pas une question de volume, mais de contexte. Sans cela, votre stratégie d'IA restera bloquée au stade de la phase pilote.

Dans le secteur grand public, les données sont naturellement contextualisées. Une transaction par carte de crédit comporte des informations relatives à l'utilisateur, au commerçant, à la date et à l'heure, ainsi qu'à la localisation, qui sont intégrées au fichier.

Dans le secteur manufacturier, les données sont dispersées à travers la pile ISA-95 :

• L'automate (au niveau de la machine) connaît la température.
• Le ERP (au niveau de l'entreprise) a connaissance de Ordre de travail.
• Le MES (niveau d'exécution) connaît l'opérateur.

Pour un modèle d'IA, il s'agit de trois langues sans rapport entre elles. C'est ce qu'on appelle le « fossé contextuel ».

Lorsque vous alimentez un système d'intelligence artificielle avec des données brutes et non structurées, vous vous exposez à un risque d'ambiguïté.

Si un opérateur demande à un assistant IA, « Pourquoi la ligne 1 s'est-elle arrêtée ? », et l'IA ne voit qu'un Intensité du moteur : 0 signal, il pourrait détecter à tort une défaillance mécanique.

Toutefois, si cette donnée était replacée dans son contexte avec un État : Changement_prévu Grâce à ce tag, l'IA identifie correctement l'événement comme une procédure standard. C'est le contexte qui fait la différence entre une information utile et un mensonge dangereux.

Pour passer d'un marécage à une stratégie, votre architecture de données doit répondre à trois niveaux spécifiques :

1. Structure (le schéma sémantique)

Les systèmes hérités utilisent des balises obscures telles que PLC_Tag_101 ou Registre_4002. Cela nécessite qu'une personne effectue manuellement le mappage de chaque point.

Les données compatibles avec l'IA s'appuient sur un modèle sémantique (par exemple, Site/Zone/Ligne/Four_1/Température). Cela garantit que lorsqu'une IA recherche « Température du four », elle trouve instantanément cette information sur tous les sites, que le four soit de marque Siemens ou Allen-Bradley.

2. Contexte (les métadonnées)

C'est là le chaînon manquant le plus crucial. Les données issues des machines doivent être enrichies par un contexte humain.

• Données brutes : « La machine s'est arrêtée à 10 h. »
• Données contextualisées : « La machine s'est arrêtée à 10 h 00 pendant le changement de production effectué par l'opérateur John pour le produit X. »
• Apps le meilleur moyen de collecter ces données centrées sur l'humain, car elles enregistrent naturellement les éléments « qui, quoi et pourquoi » en plus du « quand » fourni par la machine.

3. Access (Le protocole)

Les intégrations point à point traditionnelles (requêtes SQL, appels d'API) sont trop rigides pour l'IA. Elles créent des dépendances étroites.

L'IA nécessite une architecture de type « publish/subscribe » (comme MQTT/Sparkplug), dans laquelle les données sont publiées vers un courtier central. Cela permet à un agent IA de simplement « s'abonner » à un flux de données sans qu'il soit nécessaire de recourir à une intégration sur mesure développée par le service informatique.

La solution architecturale au problème du « Context Gap » est l'espace de noms unifié (UNS).

Considérez l'UNS comme le système nerveux central de votre usine. Au lieu de connecter chaque application à chaque machine, tous les systèmes transmettent leurs données à un hub central, selon une hiérarchie claire.

• La Machine publie : Ligne 1/Four/Température : 400
• L'application publie : Ligne 1/Four/État : Actif
• L'IA s'abonne à Ligne 1/Four/N° et les voit immédiatement tous les deux.

En mettant en œuvre un système UNS, vous garantissez que le contexte est appliqué en temps réel, rendant ainsi vos données « prêtes pour l'IA » dès leur génération. Cela permet la mise en place de modèles RAG (Retrieval Augmented Generation), dans lesquels l'IA peut interroger l'état actuel de l'usine pour répondre à des questions en direct.

La plupart des initiatives en matière de préparation des données se concentrent exclusivement sur les capteurs des machines. C'est là une erreur fatale. Les capteurs peuvent vous dire ce qui s'est passé, mais ils vous indiquent rarement pourquoi.

• Un capteur de vibrations vous indique que le moteur est en panne.
• Seul l'opérateur sait que cela a échoué parce que « la matière première était humide ».

Si vous excluez cette vision humaine de votre ensemble de données, votre IA n'apprendra jamais à établir des liens de causalité. L'utilisation d'applications sans code pour enregistrer les journaux, les observations et les actions des opérateurs est essentielle pour former des modèles d'IA capables de saisir toute la réalité de la production.

Une objection courante est la suivante : « Mes machines ont 30 ans ; elles ne disposent pas d'API. »

Il n'est pas nécessaire de remplacer vos équipements existants pour les rendre compatibles avec l'IA. Il suffit de les équiper d'une interface.

• IoT : du matériel peu coûteux peut être connecté à des automates programmables (PLC) existants pour extraire des données et les convertir en protocoles modernes tels que MQTT.
• Vision par caméra : pour les machines dépourvues de ports de données, Vision par ordinateur peut « lire » des jauges analogiques ou des tours lumineuses et numériser ce signal.
• L'« App Wrapper » : si une machine est complètement hors ligne, placez une Tulip à côté d'elle. L'opérateur qui saisit manuellement « Début du cycle » et « Fin du cycle » fait office de capteur numérique.

Comparaison : charges utiles brutes et charges utiles prêtes pour l'IA

Pour vous rendre compte de la différence, observez comment une IA analyse un paquet de données.

Si vous souhaitez préparer votre établissement à l'arrivée de Frontline Intelligence, commencez par ici :

1. Cessez d'accumuler des données brutes : si les données ne comportent pas d'horodatage ni de balises de contexte, ne les stockez pas. Elles constituent un risque, et non un atout.
2. Mettez en œuvre une stratégie en périphérie : traitez les données à haute fréquence en périphérie. Traitez les données localement (ajoutez-y du contexte) avant de les envoyer vers le cloud.
3. Adoptez une norme sémantique : choisissez une convention de nommage (comme MQTT Sparkplug B) et respectez-la.
4. Numérisez le « pourquoi » : remplacez les registres papier par des applications afin que le contexte humain soit numérisé et accessible à l'IA.