Si votre projet implique la collecte de données, la conversion multiprotocole, l'inférence IA légère ou l'extension de fonctionnalités futures, une architecture PLC + ARM (souvent appelée solution PLC + passerelle de périphérie industrielle) offre plus d'avantages qu'un système PLC pur. Si le projet ne nécessite qu'un simple contrôle logique sans aucun besoin de données en nuage, une solution PLC pure est suffisante.
Les ingénieurs qui ont beaucoup travaillé sur des sites industriels partagent souvent la même expérience : les automates traditionnels sont suffisamment stables, mais ils sont de plus en plus “à bout de souffle” lorsqu'il s'agit de répondre aux exigences actuelles en matière de données. Par exemple, sur une ligne de production de pièces automobiles, le responsable peut vouloir surveiller l'état de la ligne, calculer le rendement horaire, prévoir les pannes d'équipement et même télécharger les données vers le nuage pour une analyse globale. Tout cela rend le programme de plus en plus complexe et le cycle de débogage nettement plus long. Si un automate traditionnel peut assurer des mouvements de cylindre précis, sa capacité à gérer des algorithmes complexes et à se connecter directement au cloud est souvent limitée.
C'est là que l'architecture PLC + ARM entre en jeu : le PLC se concentre sur le contrôle tandis que l'ARM s'occupe des données et de l'intelligence. L'ARM fournit la puissance de calcul, de riches interfaces de communication et un écosystème Linux, capable de gérer des tâches pour lesquelles les automates traditionnels sont moins adaptés. Cependant, tous les projets ne se prêtent pas à cette “approche combinée”. Les cinq conditions suivantes peuvent vous aider à déterminer si votre projet devrait l'adopter.
Pourquoi de plus en plus de projets envisagent une architecture PLC + ARM
Les automates traditionnels fonctionnent en mode de balayage cyclique et excellent dans le contrôle logique et la réponse en temps réel. Cependant, lorsqu'il s'agit de calculs complexes, de conversion multiprotocole ou d'intégration de données dans le nuage, bien que ces tâches puissent être prises en charge par des modules d'extension ou des passerelles tierces, elles s'accompagnent souvent de coûts de développement élevés, d'une configuration complexe et d'une flexibilité limitée.
En revanche, les ordinateurs industriels basés sur l'architecture ARM (souvent appelés “passerelles intelligentes” ou “contrôleurs ARM”) sont généralement plus performants que les CPU PLC de milieu ou de bas de gamme pour les calculs en virgule flottante et le traitement des données. Ils offrent également un écosystème logiciel plus ouvert et des options de connectivité plus riches. La combinaison des deux permet de créer une structure de traitement des données et d'interconnexion en couches, parallèlement à la couche de contrôle, en tirant parti des points forts de chacune d'elles.
Par expérience, ce type de solution est plus un compromis qu'une solution universelle - elle peut ajouter des capacités de traitement des données à une ligne de production sans modifier la logique de contrôle PLC d'origine, mais l'équipe doit avoir des connaissances de base de Linux et de la configuration du réseau.
Condition 1 : le système nécessite-t-il un traitement de données ou une prise de décision algorithmique ?
Si un projet ne nécessite qu'un contrôle logique simple (par exemple, “appuyez sur un bouton, le moteur démarre”), un automate seul est suffisant. Toutefois, lorsque le projet répond aux besoins suivants, une architecture PLC + ARM mérite d'être envisagée :
-
L'inférence légère de l'IA : Par exemple, l'utilisation d'une caméra pour identifier les couleurs d'un produit, vérifier la présence d'étiquettes ou compter les pièces. Certains processeurs ARM intègrent des NPU (par exemple, 1 TOPS) capables d'exécuter des modèles légers, adaptés aux images à faible résolution, à la classification simple ou à la détection d'un seul objet dans des scénarios de base. Bien qu'ils ne puissent pas remplacer les systèmes complexes de vision multi-objets, ils peuvent prendre en charge certaines décisions auxiliaires à la périphérie.
-
Stratégies complexes fondées sur des règles : Par exemple, déterminer s'il faut déclencher un avertissement en fonction de plusieurs facteurs tels que la fréquence des vibrations de l'équipement, les tendances de la température et les données historiques. La mise en œuvre d'une telle logique sur ARM à l'aide de Python ou de Node-RED est généralement plus efficace que l'écriture d'une logique en échelle ou d'un texte structuré sur un automate programmable.
-
Analyse statistique : Le calcul en temps réel de l'OEE des appareils, les tendances de la consommation d'énergie au cours de l'heure écoulée et la génération de rapports sont des tâches qui conviennent mieux à l'ARM.
Dans de nombreux projets de modernisation de lignes de production, la suppression des tâches statistiques de l'API a permis de raccourcir les programmes API de plus de 30%, améliorant ainsi considérablement l'efficacité du débogage. Le côté ARM convient pour les tâches de données à forte intensité de calcul et non en temps réel, mais il ne convient pas pour les boucles de contrôle nécessitant une réponse en temps réel. Si les résultats du traitement des données doivent être utilisés pour le contrôle en boucle fermée, la latence de communication doit être évaluée et l'automate doit conserver l'autorité de décision finale.
Condition 2 : Le système nécessite-t-il une conversion multiprotocole ou une intégration directe dans le nuage ?
C'est l'un des domaines où l'architecture ARM excelle véritablement. Bien que de nombreux automates traditionnels soient dotés de capacités de communication, la connexion directe à des nuages publics ou la gestion de divers protocoles peuvent être relativement complexes. Dans les scénarios suivants, un contrôleur ARM joue le rôle de “traducteur” et de “relais” :
-
Des équipements de différentes marques : Un atelier peut disposer d'automates Siemens, d'onduleurs Mitsubishi et de compteurs Modbus. Un contrôleur ARM peut s'interfacer avec tous ces appareils simultanément, en convertissant leurs données dans un protocole unifié tel que OPC UA ou MQTT pour une intégration transparente des données.
-
Les données doivent être transmises aux appareils mobiles : Par exemple, l'envoi d'alarmes critiques ou de données de production à des applications telles que DingTalk ou WeCom.
-
Les données doivent être téléchargées dans le nuage pour être stockées et analysées à long terme : Assurer une transmission stable des données vers les bases de données en nuage via les réseaux 4G, 5G ou câblés.
Certains ordinateurs industriels ARM sur le marché prennent en charge plusieurs protocoles industriels courants, soit par le biais d'un logiciel de passerelle industrielle préinstallé, soit par le développement de pilotes personnalisés, y compris Modbus, OPC UA, EtherNet/IP et certains protocoles propriétaires d'automates. La couverture des protocoles, la capacité des points simultanés et la maturité des logiciels varient considérablement d'un fournisseur à l'autre, de sorte que ces facteurs doivent être soigneusement pris en compte lors de la sélection.
Par exemple, le Ordinateurs industriels ARM de la série EC300 sont préinstallés avec Node-RED et NeuronEX-Lite, ce qui permet une collecte multiprotocole et une conversion unifiée par logiciel. Leur environnement ouvert basé sur Linux permet également le développement secondaire et l'extension des fonctionnalités. Cette conception découple la conversion des protocoles du matériel, ce qui rend le système plus flexible pour les ajustements et les mises à niveau futurs.
Dans les applications pratiques, le nombre de points simultanés et les performances de traitement doivent encore être évalués en fonction des exigences du projet (telles que l'échelle des points et le cycle de rafraîchissement) et de la configuration des ressources matérielles.
Condition 3 : le contrôle implique-t-il des exigences en matière de sécurité et de temps réel ?
Il s'agit d'une “ligne rouge” à ne pas franchir lors du choix d'une architecture PLC + ARM : toutes les actions qui impliquent une sécurité personnelle ou un risque d'endommagement des équipements doivent être contrôlées directement par le PLC.
Du côté ARM, on utilise généralement un système Linux, qui n'offre pas le même niveau de performance en temps réel qu'un automate programmable, et qui peut être sujet à des pannes de système ou à des interruptions de réseau. Par conséquent, une division raisonnable du travail est la suivante : L'ARM en tant que “cerveau” et PLC comme le “muscle”.” travaillent en étroite collaboration. L'ARM, en tant que cerveau, s'occupe principalement du traitement des données, de la prise de décision logique et de l'interaction homme-machine, puis envoie des instructions à l'automate via l'Ethernet industriel ou le port série (par exemple, “température trop élevée, préparez-vous à vous arrêter”). L'automate, en tant que muscle, est responsable de l'arrêt d'urgence, des rideaux lumineux de sécurité et d'autres actions en temps réel. Les programmes de l'automate doivent fonctionner de manière indépendante et ne pas être affectés par l'état de l'ARM.
En outre, la conception du système doit tenir compte de la défaillance de l'ARM, ce qui est essentiel. Si l'ARM tombe en panne ou si le réseau tombe en panne, l'automate doit automatiquement passer à un état sûr ou à un mode de fonctionnement dégradé en fonction d'un mécanisme de chien de garde prédéfini ou d'une logique de temporisation de la communication, afin que la chaîne de production ne devienne pas incontrôlable. Le contrôleur ARM lui-même doit également disposer d'un chien de garde matériel pour redémarrer automatiquement en cas d'anomalie. En outre, la communication entre l'automate et l'ARM doit prendre en charge la reconnexion et la mise en mémoire tampon des données afin d'éviter toute perte de données.
Dans la pratique, il s'agit souvent du risque le plus sous-estimé lors de la modernisation d'anciennes lignes de production. Cela peut sembler idéal, mais en réalité, il faut tenir compte de la latence du réseau et des coûts de maintenance. L'échange de données entre l'automate et l'ARM (généralement via Ethernet ou un port série) peut avoir des retards de l'ordre de la milliseconde ou plus, en fonction de la charge du réseau et du type de protocole. Pour un contrôle coordonné à réponse rapide, il est essentiel d'évaluer si la latence se situe dans des limites acceptables et de mettre en œuvre des mécanismes de synchronisation des données appropriés.
Certains contrôleurs ARM fournissent des interfaces DI/DO isolées. Celles-ci sont généralement utilisées pour les interactions de signaux non critiques pour la sécurité (par exemple, les voyants d'état, les signaux de retour auxiliaires) et sont déconseillé pour le pilotage d'actionneurs pouvant présenter des risques pour la sécurité. Tous les contrôles critiques doivent toujours être gérés par l'automate.
Condition 4 : Le projet nécessite-t-il une extension future ?
De nombreux projets d'automatisation présentent un schéma commun : la première phase ne répond qu'aux exigences de base, mais au cours de la deuxième ou de la troisième phase, de nouvelles fonctionnalités sont continuellement ajoutées. Alors que les automates traditionnels peuvent facilement étendre les modules d'E/S, l'ajout d'une fonction d'analyse de l'IA, le changement de plateforme cloud ou la connexion de nouveaux appareils intelligents sont souvent limités par les performances de l'unité centrale ou les interfaces de communication.
L'architecture PLC + ARM en couches offre des avantages évidents en termes d'évolutivité :
-
Extension horizontale des interfaces : Grâce aux interfaces riches du côté ARM (USB, HDMI, CAN, etc.), il est possible d'ajouter ultérieurement des caméras, de grands écrans, des lecteurs de codes-barres et d'autres dispositifs intelligents.
-
Extension verticale des applications : Le système Linux de l'ARM permet l'installation de nouveaux conteneurs logiciels ou de nouvelles applications à l'avenir - par exemple, l'ajout d'une interface de visualisation Web SCADA ou l'ajustement du flux de traitement des données - sans modifier le programme PLC sous-jacent.
Cependant, l'expansion n'est pas illimitée. Il faut tenir compte de la marge de manœuvre de l'unité centrale, de l'espace de stockage et de la bande passante du réseau sur le contrôleur ARM. Par exemple, si la première phase pousse déjà l'utilisation de l'unité centrale au-delà de 70%, l'ajout de tâches de traitement d'images peut entraîner une dégradation des performances. Lors de la sélection d'un système, prévoyez un horizon de 3 à 5 ans et réservez des ressources suffisantes pour une croissance future.
Condition 5 : Qu'en est-il de la complexité de l'exploitation, de la maintenance et du débogage ?
C'est souvent la principale préoccupation des chefs d'équipe et des ingénieurs sur place : une nouvelle architecture va-t-elle accroître les difficultés de débogage et de maintenance ?
S'ils sont bien conçus, les outils logiciels de la partie ARM peuvent en fait réduire la complexité globale.
Tout d'abord, il simplifie le programme de l'automate. Les algorithmes complexes, la conversion des protocoles et les tâches d'enregistrement des données sont transférés à l'ARM. L'automate ne gère que le contrôle logique, ce qui rend les programmes plus courts, plus stables et plus faciles à dépanner.
Deuxièmement, les contrôleurs ARM prennent généralement en charge la configuration à distance par SSH ou par le web. Les ingénieurs n'ont plus besoin de se rendre sur le site pour modifier un paramètre.
Enfin, la partie ARM peut exécuter des outils de programmation visuelle tels que Node-RED. Les flux de données peuvent être construits rapidement par glisser-déposer, ce qui réduit la barrière de développement de Linux.
En bref, l'ARM agit comme un “traducteur”, convertissant le langage des différents appareils en quelque chose que la plateforme en nuage peut comprendre. Toutefois, cela signifie également que les équipes qui utilisent l'ARM doivent avoir des connaissances de base de Linux et des compétences en matière de configuration de réseau.
Quels sont les projets qui n'ont pas besoin d'une PLC + architecture ARM?
Pour éviter de suivre aveuglément les tendances, les types de projets suivants ne nécessitent généralement pas de couche ARM :
-
Contrôle purement logique sans besoin de collecte de données : Par exemple, une simple commande de relais ou des machines automatisées autonomes - les automates programmables suffisent.
-
Projets dotés d'un système de niveau supérieur existant et bien établi : Si le site dispose déjà d'un PC industriel et d'un système SCADA capables de répondre aux besoins pour les 3 à 5 prochaines années, il n'est pas nécessaire d'ajouter une couche ARM.
-
Projets avec des exigences de sécurité extrêmement élevées qui ne peuvent tolérer une complexité accrue du système : Par exemple, certains systèmes instrumentés de sécurité (SIS). Plus le système est simple, plus il est fiable ; l'introduction d'une couche informatique supplémentaire pourrait créer de nouveaux points de risque.
-
Projets avec des budgets très serrés : L'ajout d'un contrôleur ARM augmente les coûts de matériel et de développement. Si le projet est très sensible aux coûts, les avantages peuvent ne pas justifier les dépenses.
Exemple de déploiement typique
Dans une architecture PLC + ARM typique, le PLC gère le contrôle des E/S en temps réel et la logique de sécurité, tandis que le contrôleur de périphérie ARM collecte les données de la ligne de production, exécute des analyses légères (telles que les calculs OEE de l'équipement) et télécharge les données vers le nuage via MQTT ou OPC UA. Ces contrôleurs fonctionnent généralement sous Linux et permettent de créer des flux de traitement de données par le biais de scripts ou de la programmation visuelle. Les différents produits varient selon qu'ils sont ou non préinstallés avec des outils visuels et selon le type d'outils fournis.
Dans les projets réels, les différents modèles de contrôleurs industriels ARM diffèrent considérablement en termes de nombre d'interfaces, de puissance de calcul et de logiciels préinstallés. Il est recommandé d'évaluer et de comparer les options au cours de la phase de sélection en fonction du scénario d'application spécifique - comme la collecte de données, l'assistance visuelle légère ou l'IHM locale - afin de trouver la solution la mieux adaptée à l'architecture de votre système.
Détails techniques à prendre en compte lors de la sélection
Si vous décidez d'adopter une architecture PLC + ARM, outre les exigences fonctionnelles, les détails techniques suivants doivent être pris en compte :
-
Temps de latence des communications et synchronisation : L'échange de données entre l'automate et l'ARM peut avoir des retards de l'ordre de la milliseconde ou plus en fonction de la charge du réseau et du type de protocole. Pour un contrôle coordonné à réponse rapide, il est essentiel d'évaluer si le temps de latence se situe dans des limites acceptables et de mettre en œuvre des mécanismes de synchronisation des données appropriés.
-
Isolation et protection de l'interface : Les environnements industriels présentent souvent des interférences électriques. Les interfaces des contrôleurs ARM - y compris les ports série, Ethernet et les E/S - doivent être dotées d'une isolation électrique et d'une protection contre les surtensions afin d'éviter qu'une défaillance d'une seule interface n'affecte l'ensemble du système.
-
Capacité d'adaptation à l'environnement : S'il est installé dans une armoire de commande, le contrôleur ARM doit fonctionner de manière fiable dans une large gamme de températures (par exemple, de -40°C à +70°C). Les conceptions sans ventilateur et à refroidissement passif réduisent les points de défaillance et conviennent mieux aux environnements difficiles.
-
Écosystème logiciel et assistance : Le vendeur fournit-il un kit de développement complet, des exemples de code et une assistance technique ? Les outils préinstallés (par exemple, Node-RED, passerelles de protocole) sont-ils libres ou faciles à étendre ? Ces facteurs ont une incidence directe sur l'efficacité de la mise en œuvre du projet.
Résumé
L'architecture PLC + ARM ne vise pas à remplacer les automates traditionnels, mais plutôt à ajouter une couche de traitement des données flexible au contrôle industriel. Lorsque vous rencontrez des projets qui nécessitent le traitement de données, l'exécution d'algorithmes légers, l'intégration multiprotocole, la connectivité au cloud ou l'expansion future, cette combinaison peut apporter une valeur évidente. Toutefois, il est essentiel de séparer strictement la couche de contrôle de la couche informatique, en veillant à ce que les tâches en temps réel critiques pour la sécurité restent entièrement gérées par l'automate, l'ARM ne servant que de couche auxiliaire et d'amélioration.
D'un point de vue technique, cette approche revient à doter votre système PLC existant d'un “cerveau de données” plutôt que de partir de zéro. Si le concept semble séduisant sur le papier, son succès dépend fortement des conditions du réseau sur site et de la familiarité de l'équipe avec Linux. Si vous évaluez ce type d'architecture, il est recommandé de commencer par un petit projet pilote pour valider la latence des communications, la compatibilité des logiciels et la capacité de l'équipe avant de l'étendre progressivement à d'autres lignes de production.
