Le débat sur l'informatique de pointe dans les environnements d'entreprise a tendance à tourner autour du coût : traitement local pour réduire les factures de cloud, filtrage des données en périphérie pour ne pas transmettre ce qui n'a pas besoin de l'être. Dans le contexte industriel, ce cadrage est erroné. L’Edge Computing dans une usine n’est pas une décision optimisée en termes de coûts avec une alternative viable dans le cloud. Pour un ensemble important d'applications industrielles, l'architecture cloud centralisée ne répond tout simplement pas aux exigences opérationnelles : latence trop élevée pour le contrôle des processus, volume de données trop élevé pour une transmission continue, dépendance inacceptable au réseau pour les opérations critiques. La question n’est pas de savoir si la périphérie ou le cloud sont moins chers. La question est de savoir quelles applications nécessitent un traitement local en tant qu’exigence fonctionnelle non négociable, et comment faire évoluer l’infrastructure périphérique pour les prendre en charge.
Que signifie la latence en millisecondes sur la ligne de production
Les systèmes de contrôle de processus industriels (API, DCS, systèmes de vision) fonctionnent selon des cycles de temps allant de quelques microsecondes pour le contrôle de mouvement à des dizaines de millisecondes pour le contrôle de processus chimiques. La latence aller-retour vers un centre de données situé dans la même ville, dans des conditions de réseau favorables, est généralement comprise entre 5 et 20 millisecondes. Dans des conditions de réseau avec jitter, ou avec un data center géographiquement éloigné, elle peut facilement dépasser 50 millisecondes.
Pour un système de vision par ordinateur de ligne d'inspection qui doit rejeter les pièces défectueuses avant que la pièce ne passe au poste suivant, la latence de décision doit être compatible avec la vitesse de la ligne. Un cycle de ligne de 200 millisecondes par pièce donne une fenêtre de temps pour que la caméra capture, le modèle à traiter et le signal de rejet à envoyer à l'actionneur. Soustrayez le temps de capture d'image, le temps d'actionnement de l'actionneur et la marge de sécurité, et la fenêtre de traitement peut être inférieure à 50 millisecondes. Aucune architecture de cloud public ne fournit cette latence de manière fiable et cohérente.
Le même raisonnement s'applique aux systèmes de contrôle de robots collaboratifs, aux systèmes d'arrêt d'urgence basés sur l'analyse de capteurs et à toute application où l'action physique dépend d'une décision d'algorithme en temps réel. Dans ces cas-là, l’informatique de pointe n’est pas préférable : elle est obligatoire. Le coût d’une décision avec une latence excessive n’est pas un tableau de bord obsolète. Il s’agit d’une pièce défectueuse qui a passé avec succès l’inspection, d’un équipement qui ne s’est pas arrêté au bon moment ou encore d’une opération que le réseau a interrompue.
Le problème du volume de données que les mathématiques résolvent
Une caméra d'inspection industrielle haute résolution à 30 images par seconde génère environ 1 à 3 Go de données par heure et par caméra, en fonction de la compression et de la résolution. Une usine équipée d'une cinquantaine de caméras d'inspection génère entre 50 et 150 gigaoctets par heure. En un mois de fonctionnement en deux équipes, cela représente entre 24 et 72 téraoctets de vidéo. La transmission continue de ce volume vers le cloud n'est pas une question de bande passante : certaines opérations disposent de la bande passante disponible pour cela. Il s'agit de coûts de stockage et de traitement dans le cloud qui deviennent rapidement injustifiables lorsque la grande majorité des images capturées sont constituées de pièces impeccables et ne nécessitent pas d'analyse.
Le modèle qui fonctionne est l'inférence à la limite : le modèle de vision par ordinateur fonctionne sur du matériel local, traite chaque image et produit uniquement le résultat - approuvé ou rejeté, avec un certain degré de confiance - au lieu de transmettre l'image complète. Les images des pièces rejetées ou peu fiables peuvent être envoyées vers le cloud pour examen humain et recyclage. Le résultat est que la transmission vers le cloud passe de gigaoctets par heure à mégaoctets par heure, et les données qui atteignent le cloud sont celles qui ont de la valeur pour l'analyse et l'amélioration du modèle.
Les capteurs de vibrations haute fréquence destinés à l’analyse de l’état des équipements ont un profil similaire. L'échantillonnage à 10 kHz, nécessaire pour détecter certaines catégories de défauts mécaniques, génère des volumes de données qui ne justifient pas une transmission continue. Ce qui a du sens est de calculer localement les mesures pertinentes (spectre de fréquence, amplitude dans des bandes spécifiques, indices de condition) et de transmettre uniquement ces indicateurs calculés, avec la série chronologique complète disponible sur le stockage local pour une analyse plus approfondie si nécessaire.
Architecture industrielle de pointe : qu'est-ce qui compose la pile
L’environnement industriel de pointe n’est pas un serveur rack Linux. Il s'agit d'une hiérarchie de capacité de calcul répartie entre l'équipement et le cloud, avec différents niveaux de traitement à chaque couche.
Au niveau d'équipement le plus proche se trouvent les passerelles de protocole, c'est-à-dire des dispositifs qui traduisent les protocoles industriels tels que Modbus, Profibus, EtherNet/IP et OPC-UA en formats que le reste de la pile peut consommer. Ces passerelles sont souvent du matériel spécialisé — Moxa, Advantech, Siemens SIMATIC — avec un firmware conçu pour l'environnement industriel : température de fonctionnement étendue, sans ventilateur, cycle de vie des composants de dix ans. Le coût unitaire est supérieur à celui du matériel informatique équivalent en termes de spécifications de traitement, mais l'exigence de fiabilité dans un environnement industriel justifie la différence.
Une couche au-dessus se trouve les serveurs de périphérie – du matériel capable de tout exécuter, des PC industriels robustes aux racks GPU compacts pour déduire des modèles de vision par ordinateur. Ici, le choix du matériel dépend de la charge de calcul. Pour traiter les séries temporelles et calculer les indicateurs de maintenance, un processeur basse consommation suffit. Pour l'inférence de modèles de vision par ordinateur à haute fréquence, les GPU industriels comme le Nvidia Jetson AGX ou la propre gamme A2000 de Nvidia apparaissent dans les spécifications de conception.
Au niveau logiciel, la question de l'orchestration (comment déployer, mettre à jour et surveiller les applications exécutées sur des dizaines ou des centaines de nœuds périphériques) est celle où la plupart des architectures industrielles de pointe présentent le plus grand écart. Kubernetes fonctionne, mais sa complexité opérationnelle dans les environnements OT peut être excessive pour les équipes sans expérience approfondie en orchestration de conteneurs. Des plates-formes telles qu'Azure IoT Edge, AWS Greengrass et Balena offrent des abstractions plus simples et une intégration native avec les services cloud correspondants, mais créent un verrouillage vis-à-vis du fournisseur qui doit être évalué dans le contexte du projet.
Sécurité physique et logique dans un environnement d'usine
L’informatique industrielle de pointe ajoute une surface d’attaque aux environnements conçus pour fonctionner de manière isolée. Un serveur périphérique dans une usine est un matériel physique accessible, connecté au réseau OT et souvent géré par du personnel informatique qui n'a pas d'accès physique habituel à l'espace. Cela crée des risques que le modèle de sécurité centralisé du centre de données ne prend pas en compte.
La sécurité physique commence par l'enceinte : les racks industriels avec serrures et surveillance d'ouverture ne sont pas de la paranoïa, ils sont une pratique courante pour tout équipement informatique dans une zone d'accès non contrôlée d'une usine. La gestion de l'accès physique au matériel inclut le contrôle de qui peut connecter un port USB, retirer un disque ou réinitialiser le matériel.
La sécurité logique dans un environnement Edge nécessite que chaque nœud Edge soit authentifié pour la communication avec le cloud – authentification basée sur un certificat et non des informations d'identification statiques partagées. Les mises à jour du micrologiciel et des logiciels doivent être signées numériquement pour empêcher l'installation de logiciels malveillants. Le modèle de segmentation du réseau doit limiter ce à quoi le serveur périphérique peut accéder au-delà des systèmes dont il a besoin pour fonctionner : il n'y a aucune raison pour qu'un serveur d'inférence de vision par ordinateur ait accès au système RH de l'entreprise.
Comment dimensionner et budgétiser l'infrastructure périphérique
L'erreur la plus courante dans la budgétisation industrielle de pointe consiste à calculer uniquement le coût du matériel du serveur et à ignorer tout ce qui l'entoure : l'infrastructure réseau OT qui doit être adaptée pour prendre en charge le nouveau trafic, le câblage structuré qui doit être installé dans des environnements qui n'ont pas été conçus pour cela, le système d'alimentation sans interruption pour garantir que le nœud périphérique ne perd pas de données en cas de panne de courant, et les coûts d'ingénierie pour la mise en service et l'intégration avec les systèmes existants.
Une règle empirique utilisée dans les projets industriels de pointe consiste à prévoir le coût total de possession du matériel de pointe comme étant deux à trois fois supérieur au coût du matériel lui-même au cours des deux premières années. La différence couvre l'installation, l'intégration, la formation de l'équipe opérationnelle et le cycle d'ajustement initial requis par toute nouvelle implémentation. À partir de la troisième année, le coût d'exploitation se stabilise autour de 15 à 25 % du coût annuel du matériel, principalement en maintenance logicielle et en remplacement préventif des composants à cycle de vie limité comme les batteries et les disques de l'onduleur.
A lire aussi
- Edge computing : pourquoi l'informatique quitte le cloud et se rapproche des données
- Edge computing : pourquoi le traitement distribué va redéfinir votre architecture
- Architecture Edge Computing : Stratégies pour le traitement distribué -L'inférence à la périphérie : lorsque l'exécution de l'IA sur l'appareil a plus de sens que dans le cloud -La ville comme laboratoire : quand l'espace urbain devient plateforme d'essai
- Informatique autonome : lorsque le système se corrige avant que vous ne remarquiez l'erreur