Notes de veilleNote de veille
Calcul en périphérie : traiter les données au plus près des machines
Le calcul en périphérie revient dans tous les projets industriels. Derrière le terme, une question simple : où traiter chaque donnée pour qu'elle serve à temps, à un coût raisonnable et sans fragiliser l'usine ?
Une ligne d’embouteillage produit chaque seconde des milliers de mesures : vitesse des convoyeurs, pression, températures, images de contrôle. Envoyer tout cela vers un centre de données lointain pour décider, une demi-seconde plus tard, qu’une bouteille est mal remplie n’a pas de sens. C’est le point de départ de l’edge computing industriel, ou calcul en périphérie : traiter une partie des données sur place, au pied des machines, et ne faire remonter que ce qui est utile.
Le terme est à la mode ; l’idée ne l’est pas. Les automates programmables font du calcul en périphérie depuis des décennies. Ce qui change, c’est la puissance disponible dans des boîtiers industriels compacts, capables d’exécuter des modèles d’analyse d’images ou de détection d’anomalies, et la volonté de relier enfin ces traitements au reste du système d’information.
Trois raisons de traiter sur place
Le temps de réponse. Certaines décisions doivent être prises en quelques millisecondes : rejeter une pièce, arrêter un mouvement, ajuster un réglage. Elles ne peuvent pas dépendre d’un aller-retour sur un réseau étendu, dont la latence varie.
Le volume. Les flux vidéo et les mesures à haute fréquence représentent des quantités considérables. Les résumer sur place (une alerte, une moyenne, un extrait d’images autour d’un défaut) réduit la bande passante et le stockage nécessaires.
L’autonomie. Une usine, une station de pompage ou un poste électrique doivent continuer à fonctionner quand la liaison vers l’extérieur tombe. Tout traitement dont dépend la production doit pouvoir s’exécuter localement.
À ces trois raisons s’ajoute parfois une quatrième, la confidentialité : certaines données de procédé, qui révèlent un savoir-faire, n’ont pas à quitter le site.
La bonne question n’est pas « edge ou cloud ? » mais « où chaque traitement doit-il s’exécuter ? ». Le contrôle en temps réel reste sur place ; l’historique long, la comparaison entre sites et l’entraînement des modèles se font plus naturellement au centre.
Ce qui se complique
Multiplier les petits ordinateurs dans les ateliers multiplie aussi les choses à gérer. Chaque passerelle a un système d’exploitation à mettre à jour, des certificats à renouveler, des modèles à déployer et à surveiller. Sans outil de gestion à distance et sans inventaire tenu, une flotte de cinquante boîtiers devient en deux ans cinquante configurations différentes, dont plusieurs oubliées.
La sécurité change également de nature. Une passerelle placée entre les automates et le réseau de l’entreprise devient un point de passage privilégié pour un attaquant. Les principes de la série IEC 62443 (zones, conduits, niveaux de sécurité) et les recommandations de l’ANSSI pour les systèmes industriels s’appliquent pleinement : la passerelle doit être cloisonnée, durcie et surveillée comme un équipement critique, pas comme un accessoire.
Enfin, les modèles d’analyse déployés sur place vieillissent. Un changement de matière première, d’éclairage ou de cadence suffit à dégrader un modèle de contrôle visuel. Il faut prévoir comment détecter cette dérive et comment redéployer une version corrigée sans arrêter la ligne.
Trois questions avant d’acheter des passerelles
Quel traitement précis doit s’exécuter sur place, et pourquoi ? Si la réponse n’invoque ni le temps de réponse, ni le volume, ni l’autonomie, le traitement peut probablement attendre au centre.
Qui gérera la flotte dans trois ans ? Mises à jour, supervision, remplacement du matériel : cette charge doit avoir un responsable et un outil avant le premier déploiement.
Comment les données remontent-elles ? Un protocole ouvert et décrit (OPC UA, MQTT avec un modèle de données documenté) évite d’enfermer l’usine dans le format d’un fournisseur.
Le calcul en périphérie est une bonne réponse à des contraintes physiques réelles. Il devient un problème quand il sert à contourner l’absence d’architecture d’ensemble. Pour relier proprement les automates au système d’information, voir notre expertise industrie et automates ; l’article sur le retrofit des machines anciennes traite du cas, fréquent, des équipements qui n’ont jamais été prévus pour communiquer.