Schneider Foxboro SDA fait évoluer le DCS vers le logiciel

Schneider Electric a annoncé EcoStruxure Foxboro Software Defined Automation le 2 septembre 2026, lors de l’ARC Industry Leadership Forum à Orlando. L’entreprise l’a présenté comme un système de contrôle distribué ouvert et défini par logiciel pour les industries de procédés et hybrides. L’annonce est récente, mais son importance sur le plan de l’ingénierie dépend moins de l’appellation que de la manière dont sont mis en œuvre les fonctions de contrôle, le matériel, la disponibilité, la cybersécurité et les responsabilités liées au cycle de vie.

Ce que Schneider Electric a annoncé

Foxboro Software Defined Automation, ou Foxboro SDA, est présenté comme une évolution de la gamme Foxboro DCS. Schneider indique que l’architecture sépare les logiciels d’automatisation du matériel dédié afin de permettre le déploiement et la maintenance des fonctions de contrôle avec davantage de flexibilité. La plateforme est optimisée par EcoStruxure Automation Expert et vise à préserver la continuité opérationnelle attendue d’un DCS tout en réduisant la dépendance à une génération fixe de contrôleurs.

L’annonce de l’entreprise mettait l’accent sur l’ouverture, la cybersécurité intégrée, l’intelligence en temps réel et la modernisation par étapes. Schneider a également établi un lien entre ce lancement et une étude menée avec Omdia, selon laquelle les architectures de contrôle fermées peuvent entraîner des coûts importants liés aux arrêts, à l’inefficacité et aux mises en conformité. Ces estimations commerciales doivent être validées sur chaque site, mais le problème d’ingénierie sous-jacent est bien connu : l’obsolescence matérielle, les mises à niveau étroitement couplées et les interfaces propriétaires peuvent rendre les changements coûteux.

Défini par logiciel ne signifie pas indépendant du matériel

Une application de contrôle s’exécute toujours sur des ressources physiques de calcul, de réseau, d’alimentation, d’E/S et de synchronisation. Une architecture définie par logiciel change la façon dont les fonctions sont regroupées, affectées et gérées ; elle ne supprime pas ces contraintes. Les ingénieurs doivent toujours garantir une exécution déterministe, un comportement d’analyse connu, la synchronisation temporelle, la redondance, la qualification environnementale et le confinement des défaillances.

La question de conception devient alors de déterminer quelles responsabilités sont transférées au logiciel et lesquelles restent liées à un appareil. Un service de supervision virtualisé peut généralement tolérer des temps de reprise différents de ceux d’une tâche de contrôle en boucle fermée. Une fonction de sécurité a des exigences de certification, d’indépendance et de gestion des changements différentes de celles d’un connecteur d’historisation. Les sites doivent classer les charges de travail avant de décider où elles peuvent s’exécuter.

Pour la base installée, cette distinction est importante. La collection Foxboro du site comprend les familles de matériel que les installations existantes peuvent devoir prendre en charge pendant une transition par étapes. Un plan de modernisation doit recenser chaque module d’E/S, interface de bus de terrain, dépendance de contrôleur, progiciel applicatif et processus de maintenance, plutôt que de supposer que la portabilité des logiciels résout automatiquement les contraintes héritées.

Valeur potentielle pour la modernisation des installations existantes

Les mises à niveau traditionnelles de DCS cumulent souvent plusieurs risques : remplacement des contrôleurs, changement de système d’exploitation, conversion des applications, migration du réseau, modification des graphiques et nouvelle formation des opérateurs. Le découplage des fonctions peut permettre des étapes de migration plus petites, mais uniquement lorsque les interfaces et les règles de coexistence sont clairement définies.

Un plan solide pour une installation existante doit préciser quels équipements peuvent être conservés, lesquels nécessitent des passerelles et lesquels doivent être remplacés. Il doit définir les points de retour arrière, les architectures temporaires, la propriété des données et le comportement testé en cas de perte d’un nouveau service logiciel. L’avantage ne consiste pas seulement à retarder les achats de matériel. Il s’agit de réduire le nombre de variables modifiées lors de chaque arrêt.

L’ouverture nécessite des interfaces mesurables

Une architecture ouverte a une véritable portée lorsque les ingénieurs peuvent identifier les protocoles pris en charge, les modèles de données, les API, les limites de portabilité et les exigences de conformité. Une interface publiée ne garantit pas que deux fournisseurs interprètent de la même manière les alarmes, les états de qualité, les horodatages, la redondance ou la propriété de la configuration.

Les équipes chargées des achats doivent demander quelles interfaces sont natives, lesquelles nécessitent des composants optionnels et lesquelles sont destinées uniquement à la supervision. Elles doivent également déterminer si des applications tierces peuvent participer au contrôle, accéder à des données contextualisées ou seulement consommer certaines valeurs. Les limites de performance, les politiques de mise à jour, les licences et les responsabilités de support doivent figurer dans la spécification technique.

La collection DCS et systèmes de contrôle plus large fournit un contexte sur les plateformes installées que les usines de procédés comparent. Quelle que soit l’architecture choisie, les opérateurs ont besoin d’un comportement stable lors du basculement des contrôleurs, des défaillances réseau, de la maintenance des serveurs et de la perte partielle de l’infrastructure.

La cybersécurité s’intègre au cycle de vie

Schneider décrit la cybersécurité comme intégrée à l’architecture Foxboro SDA. Son guide de cybersécurité de juillet 2026 et son guide technique de la solution constituent un point de départ plus utile que les formulations générales du lancement, car ils abordent la planification et la configuration. Les documents officiels décrivent l’architecture du système ; la mise en œuvre sur le site détermine néanmoins le niveau de sécurité final.

Les systèmes définis par logiciel renforcent l’importance de la gestion des identités, des certificats, des logiciels signés, de la séparation des rôles, de la qualification des correctifs, de la journalisation, des sauvegardes et de la reprise. Ils peuvent également entraîner des changements logiciels plus fréquents qu’avec le cycle de vie traditionnel d’un contrôleur. Les sites ont besoin d’un processus contrôlé pour tester les mises à jour avec les applications de contrôle, les pilotes, les graphiques, les services horaires et la redondance avant leur déploiement en production.

Le cloisonnement du réseau reste nécessaire. Le trafic de gestion, l’accès d’ingénierie, les communications de contrôle et les échanges de données avec l’entreprise doivent suivre des chemins et disposer d’autorisations définis. L’administration à distance ne doit pas devenir une dérogation non documentée au processus d’accès OT du site. La supervision de la sécurité doit distinguer les activités d’orchestration attendues des modifications de configuration non autorisées.

La disponibilité doit être démontrée au niveau des fonctions

Une déclaration de disponibilité d’un DCS doit être décomposée en scénarios de défaillance. Que se passe-t-il lorsqu’un nœud de calcul tombe en panne, qu’un chemin réseau est interrompu, qu’un service d’orchestration devient indisponible ou qu’un déploiement logiciel est incomplet ? Quelles boucles de contrôle continuent de fonctionner, quelles vues opérateur se dégradent et combien de temps dure la reprise ?

Les ingénieurs doivent exiger des preuves concernant le temps de basculement, la synchronisation des états, le transfert sans à-coup, la continuité des alarmes, la mise en mémoire tampon de l’historien et la reprise après des défaillances simultanées. Une sauvegarde n’équivaut pas à une haute disponibilité, et la redondance est inutile si les défaillances de cause commune n’ont pas été prises en compte. Les essais de réception en usine doivent inclure les modes dégradés, et pas seulement le fonctionnement normal.

Comment les sites peuvent évaluer Foxboro SDA

Définir un projet pilote délimité

Sélectionnez une unité non critique ou un système d’essai représentatif avec de vraies E/S, des alarmes, des séquences, des communications et des graphiques opérateur. Documentez les performances actuelles afin de pouvoir comparer la nouvelle architecture à une référence.

Recenser chaque dépendance

Répertoriez les contrôleurs, les E/S, les serveurs, les commutateurs, les sources horaires, les services de domaine, les licences, les outils d’ingénierie et les progiciels tiers. Identifiez le responsable de chaque dépendance et la manière dont elle est restaurée.

Tester les changements et la reprise

Appliquez une mise à jour logicielle, annulez-la, remplacez un nœud défaillant, interrompez les chemins réseau et restaurez une sauvegarde. Vérifiez que les procédures fonctionnent avec les compétences et les outils disponibles sur le site.

Distinguer les affirmations des critères d’acceptation

Traduisez l’ouverture, la flexibilité et la cybersécurité en exigences mesurables. Il peut s’agir des versions de protocoles prises en charge, du temps maximal de reprise, des systèmes d’exploitation validés, de la durée de conservation des journaux, des autorisations associées aux rôles et des limites d’exécution des contrôleurs.

Point de vue de l’ingénierie

Foxboro SDA représente une tentative sérieuse de modifier la manière dont les capacités d’un DCS sont déployées et renouvelées. L’annonce officielle du lancement du 2 septembre de Schneider Electric établit l’orientation du produit, tandis que son guide technique de la solution Foxboro SDA fournit un contexte de mise en œuvre.

L’opportunité réside dans une plus grande flexibilité lors de la modernisation. Le risque est de considérer l’abstraction comme la preuve que les problèmes de synchronisation, de sécurité, de disponibilité et de support ont disparu. Les sites qui s’appuient sur la classification des charges de travail, la migration par étapes, des interfaces explicites et des essais d’acceptation fondés sur les défaillances seront mieux placés pour évaluer les domaines dans lesquels l’architecture apporte une réelle valeur.