Dans les projets de numérisation industrielle, la même question revient régulièrement : edge ou cloud ?

Comme s’il fallait choisir entre deux visions du monde qui s’excluent mutuellement. D’un côté le traitement sur site, de l’autre le cloud. L’un est rapide et autonome, l’autre évolutif et administrable de manière centralisée.

En réalité, un système industriel performant utilise presque toujours les deux. Non pas au gré des modes technologiques, mais selon l’endroit où une donnée ou une décision peut être traitée de la manière la plus sûre, la plus rapide et la plus économique.

Que recouvre réellement l’edge ?

L’edge n’est pas forcément un serveur particulier installé à côté de la ligne de production. Il peut englober toute capacité de calcul et de décision qui fonctionne à proximité du lieu où les données sont produites.

Il peut s’agir :

  • d’un capteur intelligent ;
  • d’un automate programmable (PLC) ;
  • d’une passerelle IoT industrielle ;
  • d’un ordinateur local ;
  • d’un serveur sur site ;
  • d’un service de traitement de données exécuté dans un conteneur.

Le rôle de l’edge ne se résume pas à « envoyer moins de données vers le cloud ». Il peut prendre en charge localement les fonctions pour lesquelles comptent une faible latence, l’indépendance vis-à-vis du réseau, la protection des données ou la sûreté de fonctionnement.

Ce qu’il ne faut pas confier à une connexion distante

Si une décision doit être prise en quelques millisecondes ou secondes, l’aller-retour sur le réseau peut représenter un risque. Il en va de même lorsque le procédé doit continuer à fonctionner sans connexion Internet.

Restent généralement en local :

  • la commande directe des machines et des procédés ;
  • les fonctions de sécurité fonctionnelle (safety) ;
  • l’intervention de protection immédiate ;
  • le prétraitement des données à fréquence d’échantillonnage élevée ;
  • la mise en mémoire tampon des données ;
  • les fonctions opérateur locales essentielles ;
  • l’adaptation des protocoles de communication.

Par exemple, si un capteur de vibrations produit plusieurs milliers d’échantillons par seconde, il n’est pas forcément judicieux d’envoyer en continu chaque valeur brute vers un système central. Le traitement local peut calculer des indicateurs caractéristiques, détecter un dépassement de seuil et ne transmettre que la synthèse pertinente ou la séquence d’échantillons entourant un événement.

Là où le traitement central ou cloud est plus performant

L’environnement central est avantageux lorsqu’il faut rapprocher les données de plusieurs sites, de longues périodes ou de plusieurs systèmes métier.

C’est là qu’il convient de traiter, par exemple :

  • la comparaison entre sites ;
  • l’analyse historique ;
  • la supervision des équipements à l’échelle du parc ;
  • le reporting d’entreprise ;
  • la gestion centralisée des droits d’accès ;
  • l’entraînement des modèles ;
  • les processus de maintenance et les processus métier ;
  • la gestion des versions et des configurations.

L’avantage du cloud ne tient pas seulement au fait que « le serveur est ailleurs ». Il peut offrir une capacité flexible, une accessibilité centralisée, une exploitation homogène et le traitement conjoint de données issues de plusieurs sources.

Cinq vrais critères de décision

La répartition des tâches entre edge et cloud doit être définie selon au moins cinq critères.

1. Latence

En combien de temps faut-il réagir ? Une intervention de protection machine et un rapport énergétique mensuel ne relèvent évidemment pas de la même catégorie.

2. Fiabilité de la connexion

Que se passe-t-il si la liaison WAN ou mobile est interrompue ? Le processus local doit continuer à fonctionner en toute sécurité, et les données doivent, si nécessaire, être mises en mémoire tampon puis synchronisées ultérieurement.

3. Volume de données

Transmettons-nous des séries de données brutes ou des indicateurs déjà traités ? La bande passante, le coût de stockage et l’objectif de l’analyse déterminent ensemble la bonne réponse.

4. Sécurité et gestion des données

Quelles données peuvent quitter le site ? Dans quel sens les connexions sont-elles autorisées ? Où ont lieu l’authentification, le chiffrement et la journalisation ?

5. Cycle de vie et exploitation

Qui met à jour le composant local ? Comment gérer la configuration d’une centaine de sites ? Comment revenir en arrière après une version défectueuse ? Un équipement edge ne doit pas devenir une boîte noire oubliée.

Le fonctionnement hors ligne n’est pas une exception, mais un état de conception

Dans une solution industrielle, une coupure réseau doit être conçue non comme un accident exceptionnel, mais comme un état du système traité à l’avance.

Il faut définir :

  • la quantité de données pouvant être stockée localement ;
  • l’ordre dans lequel les données sont rechargées ;
  • la manière de gérer les doublons ;
  • ce qui se passe en cas de commandes contradictoires ;
  • les fonctions qui restent disponibles ;
  • quand et à qui le système envoie des alertes.

L’approche passerelle et plateforme d’OrigSmart prend en charge cette continuité. La connectivité terrain, la logique locale, la transmission des messages, le traitement central des données et les processus métier ne sont pas des projets distincts, mais les éléments d’un même système conçu de bout en bout.

Dans un système bidirectionnel, la frontière compte encore davantage

La simple télémétrie ne fait que remonter des données. Une véritable plateforme opérationnelle peut toutefois aussi agir en retour sur le fonctionnement physique : elle modifie une consigne (setpoint), régule un onduleur, planifie une consommation, acquitte une alarme ou lance un processus local.

Il faut alors distinguer clairement :

  • la recommandation de la commande exécutable ;
  • l’optimisation centrale de la limite de sécurité locale ;
  • les droits de l’utilisateur de l’autorisation côté équipement ;
  • le fonctionnement normal du mode de repli sûr (fallback).

Le système central peut indiquer qu’une réduction de charge serait économiquement avantageuse. La commande locale doit cependant empêcher toute intervention qui franchirait une limite technologique ou de sécurité.

La réponse d’OrigSmart : la continuité entre edge et cloud

OrigSmart ne vend pas un lieu de déploiement particulier : elle construit une architecture opérationnelle. Selon la tâche et les exigences du client, les composants de la plateforme peuvent être déployés en local, dans un environnement central ou dans le cloud. La passerelle de terrain peut raccorder les équipements physiques et traiter les données localement, tandis que la plateforme commune réunit les données, les droits d’accès et les processus métier de plusieurs sites.

Cela permet :

  • de prendre les décisions rapides sur place ;
  • de rendre la sûreté de fonctionnement indépendante d’Internet ;
  • d’étendre l’analyse à plusieurs sites ;
  • de transformer les données en tâches et en décisions suivies de manière centralisée ;
  • de faire évoluer la solution progressivement à partir d’un projet pilote.

À la question « edge ou cloud ? », il n’existe donc pas de réponse gagnante universelle.

Un bon système traite les données là où cela a le plus de sens pour la décision concernée — et établit entre les deux mondes une liaison contrôlée et fiable.

Parlons de votre projet

Sources