Vous avez un projet à cadrer, un budget à défendre, et quelqu’un en face de vous qui vous demande si un CompactLogix ne ferait pas l’affaire à la place d’un ControlLogix. La question semble simple. Elle ne l’est pas. Ces deux familles partagent le même logiciel, le même jeu d’instructions, le même écosystème Rockwell. Mais là où l’une impose une architecture qui décide de votre flexibilité pour les dix prochaines années, l’autre optimise l’espace et le budget d’aujourd’hui. Choisir le mauvais automate ne se voit pas tout de suite. Ça se paye au moment de l’évolution, de la migration, ou du premier arrêt non planifié. Ce guide n’est pas une liste de spécifications : c’est un outil de décision.
Ce que Rockwell ne vous dit pas d’emblée : deux familles, une seule plateforme logicielle
Le ControlLogix porte le catalogue 1756. Le CompactLogix, selon la génération, porte le 1769 ou le 5069. Ce détail de référence est en réalité le premier filtre à poser : dès qu’on lit un numéro de catalogue, on sait immédiatement à quelle famille on a affaire. Les deux appartiennent à la gamme Logix 5000 d’Allen-Bradley, la ligne de contrôleurs la plus déployée en Amérique du Nord, et toutes deux se programment avec Studio 5000 Logix Designer. C’est cette unité logicielle qui entretient la confusion.
Partager le même environnement de développement ne signifie pas partager la même architecture matérielle. Un programme écrit pour un CompactLogix peut ressembler à celui d’un ControlLogix, mais les contraintes physiques, les capacités réseau et les options de redondance divergent profondément. Considérer ces deux familles comme interchangeables, c’est l’erreur la plus fréquente en phase de conception, et souvent la plus coûteuse à corriger en cours de projet.
Architecture châssis vs sans châssis : un choix structurant dès le départ
Le ControlLogix repose sur un châssis qui accueille plusieurs modules, automate, E/S, communication, redondance, reliés entre eux via un backplane interne. Ce châssis existe en différentes tailles et peut héberger plusieurs contrôleurs simultanément. C’est cette modularité qui lui permet de s’adapter à des applications dont les besoins évoluent : on ajoute un module, on étend le rack, on reconfigure sans toucher au reste. Le CompactLogix, à l’inverse, fonctionne sans châssis dédié. Les modules E/S et communication s’y connectent directement au contrôleur, dans une conception intégrée et compacte qui convient parfaitement aux machines autonomes ou aux installations à empreinte réduite.
Ce qui est rarement mentionné : les modules E/S Compact 5000 (5069) d’un CompactLogix 5380 peuvent être configurés en E/S distribuées pour un ControlLogix 5580. Cela permet de construire des architectures hybrides où un ControlLogix central supervise des nœuds CompactLogix répartis sur le réseau EtherNet/IP. Une option intéressante pour les installations multi-zones qui veulent centraliser la puissance de traitement sans multiplier les contrôleurs haut de gamme.
Performances, mémoire et nombre d’axes : les chiffres qui tranchent
Voici ce que les fiches techniques de Rockwell indiquent pour les générations actuelles. Le tableau ci-dessous compare les points clés entre le CompactLogix 5380 et les ControlLogix 5580 et 5590 :
| Critère | CompactLogix 5380 | ControlLogix 5580 | ControlLogix 5590 |
|---|---|---|---|
| Mémoire utilisateur max. | 10 Mo | 40 Mo | 80 Mo |
| Axes de mouvement max. | 32 | 128 | 512 |
| Nœuds EtherNet/IP max. | 180 | 300+ | 600+ |
| Ports Ethernet embarqués | 1 port 1 Gb (double IP) | 2 ports 1 Gb | 2 ports 1 Gb + USB-C |
| OPC UA natif | Non | Non | Oui (100 000 nœuds) |
| Redondance intégrée | Non (module séparé requis) | Oui (module 1756-RM) | Oui (module 1756-RM3) |
| Sécurité fonctionnelle native | Jusqu’à SIL 3/PLe (1oo2) | Via GuardLogix 5580 | SIL 2/PLd sur toutes variantes |
Un cas mérite une mention à part : le CompactLogix 5480. Cet automate exécute en parallèle un moteur de commande Logix et une instance Windows 10 IoT Enterprise. Il partage le même moteur de commande réarchitecturé que les 5380 et 5580, mais y ajoute un environnement Windows embarqué pour l’analytique locale, la collecte de données et les calculs prédictifs. C’est l’option edge computing de la gamme Compact, et elle est quasi absente des comparatifs habituels.
Redondance et sécurité fonctionnelle : là où le ControlLogix prend une longueur d’avance
La redondance reste l’apanage du ControlLogix. Elle s’obtient via le module 1756-RM3, qui assure un basculement sans à-coup entre contrôleur primaire et secondaire pour les applications où l’arrêt est simplement inacceptable : production pharmaceutique, pétrochimie, traitement de l’eau. Le CompactLogix ne propose pas ce mécanisme nativement. Une disponibilité maximale sur cette famille implique obligatoirement une architecture applicative redondante construite par le programmeur, ce qui n’est pas la même chose.
Sur la sécurité fonctionnelle, la situation a changé avec le lancement du ControlLogix 5590 en octobre 2025. Toutes ses variantes, Standard, XT anticorrosion et P Process, embarquent nativement la sécurité fonctionnelle SIL 2/PLd sans module de sécurité séparé. Pour atteindre SIL 3/PLe, un partenaire de sécurité suffit. Cela permet d’unifier le système de contrôle de base (BPCS) et le système instrumenté de sécurité (SIS) dans un seul contrôleur, ce qui simplifie considérablement la validation dans les secteurs réglementés : oil et gas, life sciences, agroalimentaire, chimie. Le CompactLogix 5380 via son variant Compact GuardLogix peut atteindre SIL 3/PLe, mais en architecture 1oo2, ce qui implique deux contrôleurs physiques et une logique de sécurité doublée.
Protocoles réseau : quand l’EtherNet/IP ne suffit plus
Les deux familles s’appuient sur EtherNet/IP comme protocole principal, avec prise en charge de CIP Security sur le CompactLogix 5380 depuis Studio 5000 version 34. Mais au-delà de ce socle commun, les capacités réseau divergent nettement. Le ControlLogix, via ses modules de communication dédiés, supporte ControlNet, DeviceNet, Remote I/O et SyncLink, des protocoles indispensables dans les environnements industriels anciens ou multi-fournisseurs. Le CompactLogix se limite à EtherNet/IP et DeviceNet.
Le point qui échappe à la plupart des comparatifs : le ControlLogix 5590 intègre OPC UA nativement, avec la capacité de gérer jusqu’à 100 000 nœuds OPC UA, ainsi que les protocoles MQTT et REST via des bibliothèques machine builder. Cela positionne le 5590 comme un véritable pont IT/OT, capable d’alimenter directement les systèmes MES, les plateformes cloud et les outils d’analyse sans passerelle intermédiaire. Le CompactLogix 5380, lui, ne dispose pas de cet accès OPC UA natif. Pour les projets d’industrie connectée, c’est une différence d’architecture majeure, pas une simple option de communication.
Les pièges de la compatibilité Studio 5000 que personne ne signale avant le projet
La compatibilité logicielle est une source d’erreurs fréquentes, souvent découvertes trop tard. La version de Studio 5000 conditionne directement les contrôleurs supportés, et les règles ne sont pas intuitives. Plusieurs situations reviennent régulièrement sur le terrain lors de migrations ou de conversions entre familles :
- Studio 5000 v28 ne supporte pas les contrôleurs 5380 et 5580 : toute tentative d’ouverture de projet sur ces contrôleurs avec cette version échoue.
- Les modules E/S Compact 5000 (5069) nécessitent Studio 5000 version 33 minimum, une version distincte de celle requise pour les 1769.
- Les contrôleurs 5380 et 5580 demandent Studio 5000 v30 au minimum, et v32 pour accéder à l’ensemble des fonctionnalités.
- Le ControlLogix 5590 est supporté à partir de Studio 5000 version 38, ainsi que par FactoryTalk Design Studio v2.03.
- Les cartes motion SERCOS du ControlLogix ne migrent pas vers le CompactLogix : toute conversion entre familles sur un projet avec contrôle d’axes implique une refonte matérielle complète, pas un simple portage logiciel.
Ces contraintes ne figurent jamais en tête des fiches commerciales. Elles apparaissent, en revanche, systématiquement lors des phases de mise en service. Les vérifier en amont fait gagner des semaines.
Quel automate pour quel usage : la grille de décision pragmatique
Il n’existe pas de réponse universelle, mais il existe des cas d’usage où l’erreur de sélection est évitable. Une ligne de conditionnement haute cadence avec plusieurs dizaines d’axes synchronisés appelle naturellement un ControlLogix 5580 ou 5590 : la puissance de traitement, la capacité mémoire et la gestion des nœuds réseau y sont dimensionnantes. Une machine OEM standalone, un îlot de process intermédiaire ou une installation à empreinte réduite avec moins de 32 axes trouvera dans le CompactLogix 5380 un équilibre performances-coût difficile à battre. Pour les applications nécessitant de l’analytique locale, de la collecte de données en temps réel et du calcul prédictif embarqué, le CompactLogix 5480 s’impose seul dans sa catégorie. Et pour tout système où l’arrêt n’est pas une option, la combinaison ControlLogix avec module 1756-RM3 reste la seule architecture qui garantit un basculement bumpless.
La question du TCO (coût total de possession) mérite d’être posée explicitement. Un CompactLogix coûte moins à l’achat. Mais si le projet évolue, si l’on doit ajouter des axes, étendre les E/S ou migrer vers une architecture redondante, le coût de la conversion peut rapidement dépasser celui d’un ControlLogix dimensionné correctement dès le départ. Sous-estimer la durée de vie d’un système de commande industriel, c’est souvent là que se joue le vrai budget.
Choisir, c’est renoncer — mais renoncer en connaissance de cause
Le ControlLogix et le CompactLogix ne sont pas en concurrence. Ils répondent à des besoins distincts, à des durées de vie distinctes, à des niveaux d’exigence distincts. La question pertinente n’est pas « lequel est le meilleur » mais « lequel correspond à ce que ce système devra faire dans dix ans ». Un automate bien choisi se fait oublier. Un automate sous-dimensionné, lui, se rappelle à vous au pire moment.