Extraction de données de l’usine

Un atelier réel est une mosaïque. Des contrôleurs de différents fournisseurs, de différentes générations et de différents protocoles cohabitent côte à côte — un Siemens S7 sur un châssis, un automate Allen-Bradley sur le suivant, des compteurs d’énergie et des variateurs de fréquence Modbus dans le poste électrique, des capteurs IO-Link sur la ligne de conditionnement, des machines-outils CNC dans l’atelier, et des contrôleurs BACnet pilotant la CVC du bâtiment. Presque rien de tout cela n’a été conçu pour partager des données avec quoi que ce soit d’autre.

La tâche de l’extraction de données de l’usine consiste à récupérer des mesures fiables, nommées et horodatées sur l’ensemble de ces équipements et à les rassembler en un seul endroit — sans recâbler l’usine, remplacer les contrôleurs ni réécrire les programmes des automates. En pratique, cela signifie parler le protocole natif de chaque appareil, transformer les registres et les tags bruts en valeurs d’ingénierie nommées avec leurs unités, attacher un signal de qualité pour savoir si une lecture est digne de confiance, et le faire de manière fiable à la périphérie même lorsque le réseau tombe.

IronFlock résout cela avec une famille d’applications collectrices légères, déployées à la périphérie — une par famille de protocole. Chacune s’exécute comme un conteneur Docker classique sur n’importe quelle passerelle Linux, découvre automatiquement ce qu’elle peut, normalise les adresses brutes en valeurs nommées, met en mémoire tampon pendant les coupures, et diffuse l’ensemble dans la base de données de séries temporelles de votre projet. Chaque collecteur se configure entièrement dans le navigateur et est livré avec un mode démo, afin que vous puissiez évaluer toute l’expérience avant même de connecter le moindre matériel.

La réalité du brownfield

Il n’existe aucun protocole unique couvrant une usine entière. La question pratique est toujours « quel collecteur lit mon équipement ? » Le tableau ci-dessous met en correspondance les équipements que vous êtes susceptible de trouver avec le collecteur qui les prend en charge.

Modbus et OPC UA fonctionnent dès aujourd’hui, tout comme IO-Link, MTConnect et BACnet. Les pilotes Siemens S7 (S7comm) et Allen-Bradley (EtherNet/IP) de l’Industrial Collector reposent sur le moteur Apache PLC4X et sont en cours de validation sur différents appareils — les contrôleurs S7-1200/1500 peuvent déjà être lus dès aujourd’hui via leur serveur OPC UA intégré.

Là où les collecteurs IronFlock partagent une même approche

Quel que soit le protocole collecté, les cinq applications fonctionnent de la même manière en interne. Elles écrivent dans les mêmes tables de base de données par projet (gateways, assets, datapoints, measurements, assetstatus), mettent en mémoire tampon les lectures localement et les transmettent dans l’ordre lorsque le lien montant vers la plateforme revient, isolent chaque appareil de sorte qu’une machine injoignable ne bloque jamais les autres, et se configurent en direct dans le navigateur sans fichiers de configuration ni redémarrages. Cela reste vrai quelle que soit la façon dont IronFlock est déployé — cloud managé, cloud privé, ou appliance sur site entièrement hors ligne. Chaque page ci-dessous reprend ces traits communs afin de se suffire à elle-même.

Limites connues

Certains équipements anciens n’ont pas encore d’accès direct. Les anciens Allen-Bradley MicroLogix / SLC (PCCC sur DF1), les cellules uniquement Profibus sans port Ethernet libre, les systèmes pilotés uniquement depuis un DCS d’usine, et les équipements sans aucun contrôleur numérique (câblage dur uniquement) nécessitent une passerelle, un pont de protocole ou un rééquipement de capteur. Si vous ne savez pas si votre équipement est pris en charge, contactez-nous — si un appareil parle Modbus ou OPC UA, il fonctionne presque certainement dès aujourd’hui, et de nouveaux pilotes et packs de profils sont ajoutés sur demande.

Les collecteurs

• Industrial Collector — une application pour tout l’atelier : Siemens S7, Allen-Bradley, Modbus et OPC UA côte à côte, avec un catalogue de profils d’équipements pré-mappés.
• IO-Link Collector — maîtres IO-Link et capteurs intelligents avec découverte automatique et décodage IODD automatique sur HTTP, OPC UA ou MQTT.
• Modbus Collector — la façon la plus légère de lire l’immense parc installé de compteurs, variateurs et contrôleurs Modbus.
• MTConnect Collector — machines-outils CNC et équipements d’atelier via le standard ouvert MTConnect, avec découverte sans configuration.
• BACnet Collector — automatisation du bâtiment, CVC et systèmes d’énergie via BACnet/IP, avec découverte automatique du réseau et des points.

Où vont les données

Chaque collecteur stocke ses lectures dans la base de données de séries temporelles privée de votre projet, où elles sont immédiatement disponibles pour le reste de la plateforme : interrogez-les et modélisez-les via le Data Backend, visualisez-les en direct dans les tableaux de bord IoT et les boards SCADA, et surveillez-les avec l’application Alarmes pour des notifications par SMS/e-mail. Pour mettre les appareils en ligne et installer ces applications, voir Gestion des appareils et Gestion des applications.

De la collecte à la connaissance : un schéma d’implémentation typique

L’extraction est la fondation, pas l’objectif. Personne ne veut des registres et des tags — les usines veulent des chiffres d’OEE, des alertes précoces avant qu’une broche ne lâche, l’énergie par pièce, un rapport d’équipe qui s’écrit tout seul. Le déploiement IronFlock typique s’organise donc en deux couches qui restent proprement séparées :

Couche 1 — collecter. Installez les applications collectrices correspondant à vos équipements sur les passerelles qui les côtoient, et mappez vos machines dans le navigateur. À partir de là, des mesures nommées, horodatées et dotées d’un indicateur de qualité s’accumulent en continu dans la base de données standardisée de votre projet — chaque projet reçoit la même, si bien qu’un collecteur se comporte à l’identique où qu’il soit installé, et le propriétaire du projet dispose d’un point central pour inspecter tout ce qui est collecté. À l’intérieur, les données de chaque application vivent dans leur propre schéma isolé : un actif unique et croissant qui vous appartient, privé par application par défaut.

Couche 2 — consommer. Installez (ou construisez) les applications qui transforment ces mesures en décisions, et laissez-les lire les données des collecteurs via l’accès aux données inter-applications :

• Une application de tableau de bord OEE prête à l’emploi consomme les états machine et les compteurs de production et fournit disponibilité, performance et qualité par ligne — en direct sur le mur, sans une seule réunion d’intégration.
• Une application de maintenance prédictive s’entraîne sur des mois d’historique de vibrations, de courant et de température déjà recueilli par les collecteurs, puis évalue le flux en direct pour signaler le roulement qui a commencé à dériver.
• L’analyse énergétique croise la consommation des compteurs Modbus avec les compteurs de production des machines pour rapporter l’énergie par pièce, le gaspillage en marche à vide et le risque de pointe de charge.
• Les applications de reporting et de qualité lisent les mêmes tables pour remplir automatiquement les cahiers d’équipe, les dossiers de lot et les pistes d’audit.
• Un runtime Node-RED (ou n’importe quel atelier généraliste) déclare qu’il consomme toutes les données du projet avec un seul joker, puis découvre les tables disponibles à l’exécution — de sorte qu’un ingénieur peut câbler des flux sur chaque collecteur et chaque application d’analyse de l’atelier sans écrire une intégration pour chacun.

Chaque application consommatrice déclare de quelles données de collecteur elle a besoin — une liste précise, ou - app: "*" pour tout — et vous approuvez ou révoquez cet accès par projet avec un interrupteur — en lecture seule, toujours. Comme chaque collecteur IronFlock écrit le même schéma de tables (gateways, assets, datapoints, measurements, assetstatus), une application consommatrice écrite pour un collecteur fonctionne avec tous : le tableau de bord OEE se moque de savoir si les états machine sont arrivés via S7, Modbus, MTConnect ou IO-Link.

Le résultat est une architecture qui grandit avec vous au lieu de vous enfermer : commencez avec un collecteur sur une ligne, ajoutez des applications d’analyse quand vous êtes prêt, remplacez ou étendez chaque couche indépendamment — et si les applications sur étagère ne conviennent pas, construisez votre propre application consommatrice sur les données que vous collectez déjà.