Du contrôle centré sur les automates programmables industriels à l'automatisation définie par logiciel
L'automatisation industrielle dépasse le modèle traditionnel fondé sur des automates programmables industriels dédiés, des microcontrôleurs et des machines à fonction fixe. Les systèmes modernes associent de plus en plus le contrôle basé sur des automates programmables industriels à des microprocesseurs et systèmes sur puce hautes performances afin de gérer les IHM, la vision industrielle, l'analytique en périphérie, la connectivité, les jumeaux numériques et les charges de travail d'IA.
Cette évolution ne rend pas obsolètes les architectures de contrôle traditionnelles. Elle crée plutôt une architecture en couches dans laquelle les automates programmables industriels peuvent continuer à gérer le contrôle déterministe au niveau du terrain, tandis que des plateformes informatiques plus performantes exécutent les fonctions de supervision, d'analyse, de visualisation et d'IA.
Du point de vue de l'ingénierie, l'enjeu important n'est pas simplement d'ajouter de la capacité de calcul. Le véritable défi consiste à garantir que ces charges de travail supplémentaires ne puissent pas compromettre le temps de réponse, la disponibilité ou l'intégrité des fonctions de contrôle établies.
L'IA physique introduit un nouveau défi pour l'automatisation
L'introduction de l'IA physique rend l'architecture système plus exigeante, car les informations générées par l'IA peuvent influencer les équipements physiques et les décisions opérationnelles.
Un modèle d'IA peut identifier un état anormal de la machine, détecter une anomalie visuelle, faciliter une inspection prédictive ou identifier une situation liée à un opérateur. Toutefois, un résultat d'inférence d'IA ne constitue qu'une partie de la chaîne complète d'automatisation.
Le système doit toujours acquérir les informations des capteurs, exécuter le modèle d'IA, valider le contexte de fonctionnement, appliquer des politiques de contrôle prédéfinies et communiquer l'état obtenu à l'application ou à l'opérateur approprié.
À mon avis, l'IA industrielle devrait donc être considérée comme une charge de travail d'aide à la décision ou à réponse contrôlée plutôt que comme une couche d'intelligence isolée. La plateforme d'automatisation environnante détermine si les informations issues de l'IA peuvent être traitées et exploitées dans les limites de temps et de sécurité requises.
Les charges de travail à criticité mixte nécessitent une véritable isolation
Les processeurs multicœurs modernes permettent de consolider des fonctions qui nécessitaient auparavant des plateformes matérielles distinctes. Un même système informatique peut désormais héberger le contrôle en temps réel strict, les services IHM, les fonctions réseau, les diagnostics, la journalisation des événements, la vision industrielle, l'analytique et l'inférence d'IA.
Ces charges de travail n'ont pas les mêmes exigences.
Une tâche de contrôle en temps réel strict peut être soumise à une échéance d'exécution impérative. Une IHM peut tolérer d'autres caractéristiques temporelles, tandis qu'un processus d'inférence d'IA peut nécessiter des ressources CPU importantes. Les services réseau introduisent également des voies de communication externes qui ne devraient pas avoir un accès sans restriction aux ressources critiques.
Par conséquent, le simple fait de placer plusieurs applications sur un processeur multicœur ne crée pas automatiquement une architecture résiliente.
L'environnement d'exécution doit fournir des mécanismes de séparation temporelle, de protection de la mémoire, de contrôle des ressources et de confinement des défaillances.
La consolidation matérielle n'est pas synonyme de résilience
La consolidation matérielle peut réduire le nombre de plateformes informatiques, simplifier le câblage et accroître l'intégration. Toutefois, elle crée également un point de défaillance commun potentiel.
Si des charges de travail indépendantes partagent le même processeur et le même environnement d'exécution, un pilote défectueux, une application hors de contrôle, une défaillance de mémoire ou un service compromis pourrait affecter d'autres fonctions, à moins que l'architecture logicielle n'établisse des frontières appropriées.
Il s'agit de l'une des considérations les plus importantes lors de la modernisation d'une automatisation existante.
L'objectif ne doit pas simplement être de placer davantage de fonctions sur un nombre réduit de processeurs. Il doit être de regrouper les charges de travail sans créer de dépendances inacceptables entre elles.
Le système d'exploitation devient une couche de contrôle
Dans une architecture d'automatisation définie par logiciel, le système d'exploitation n'est plus simplement une plateforme sur laquelle les applications s'exécutent.
Il détermine la manière dont les processus sont planifiés, dont la mémoire est protégée, dont les ressources matérielles sont accessibles et dont les services individuels interagissent les uns avec les autres. Ces mécanismes influencent directement la capacité du système à rester opérationnel lorsqu'un composant individuel tombe en panne.
Une architecture résiliente doit donc pouvoir isoler un service défaillant et, lorsque la conception du système le permet, rétablir ce service sans redémarrer les applications non concernées.
Cette approche est particulièrement pertinente pour les systèmes industriels, où un redémarrage complet du système peut interrompre les opérations de contrôle, de visualisation, de communication ou de production.
Pourquoi l'architecture à micro-noyau est importante
Un système d'exploitation monolithique conventionnel place généralement de nombreux services, pilotes, systèmes de fichiers et composants réseau dans un environnement de noyau hautement privilégié.
Un micro-noyau adopte une approche architecturale différente. Il conserve un ensemble réduit de fonctions fondamentales dans le noyau, tout en permettant à de nombreux pilotes, piles de protocoles, systèmes de fichiers et services système de s'exécuter en tant que processus distincts dans des espaces d'adressage protégés.
Pour l'automatisation industrielle, cette architecture peut offrir plusieurs propriétés utiles :
- Confinement des défaillances : un pilote ou un service défectueux peut être isolé des processus non concernés.
- Récupération contrôlée : Les services individuels peuvent être redémarrés sans nécessairement redémarrer l’ensemble du système.
- Réduction du code privilégié : Moins de composants doivent fonctionner avec les privilèges système les plus élevés.
- Isolation mémoire : Les espaces d’adressage protégés contribuent à empêcher une application d’interférer directement avec une autre.
- Prise en charge de la criticité mixte : Les tâches de contrôle en temps réel peuvent coexister avec l’IHM, les réseaux, l’analyse et les charges de travail d’IA.
- Maintenance du cycle de vie : Les services modulaires peuvent simplifier la maintenance et les mises à jour au niveau des composants.
Un micronoyau n’élimine ni les défauts logiciels ni les vulnérabilités de cybersécurité. Sa valeur réside dans l’établissement de limites architecturales pouvant restreindre les conséquences de défaillances ou de compromissions individuelles.
Le déterminisme temps réel reste une exigence fondamentale
La modernisation industrielle ne doit pas permettre aux exigences liées à l’IA et au calcul haute performance d’éclipser celles du contrôle déterministe.
Pour les applications de contrôle, la question n’est pas simplement de savoir quelle puissance de traitement est disponible. Le système doit également fournir un comportement d’ordonnancement prévisible et des caractéristiques de réponse bornées pour les fonctions soumises à des exigences temporelles définies.
Cela est particulièrement important lorsque les charges de travail d’IA ou d’analyse consomment des ressources informatiques importantes.
Selon mon évaluation, l’architecture pratique n’est donc pas « l’IA qui remplace le contrôle », mais plutôt un contrôle déterministe fonctionnant aux côtés d’une intelligence de plus haut niveau, dans des limites de ressources contrôlées.
La cybersécurité doit s’étendre à l’ensemble du cycle de vie du produit
L’isolation technique n’est qu’un aspect de la cyberrésilience.
Les fabricants industriels ont également besoin de processus pour identifier les composants logiciels, surveiller les vulnérabilités, valider les mises à jour, contrôler la diffusion des logiciels et assurer la maintenance des produits tout au long de leur vie opérationnelle.
La série ISA/IEC 62443 fournit un cadre axé sur le cycle de vie, particulièrement pertinent pour les systèmes d’automatisation et de contrôle industriels. D’autres normes, notamment l’ISO/SAE 21434, montrent comment une gestion structurée des risques de cybersécurité peut s’étendre du développement à l’exploitation, à la maintenance et au déclassement.
Le Cyber Resilience Act européen renforce également l’importance de la gestion de la cybersécurité tout au long du cycle de vie des produits entrant dans son champ d’application.
Pour les fabricants d’équipements industriels, cela signifie que la cybersécurité ne peut raisonnablement pas être considérée comme une activité de certification de dernière étape. La composition logicielle, la réponse aux vulnérabilités, les mécanismes de mise à jour, la gestion des fournisseurs et la maintenance des produits doivent être pris en compte lors du développement du système.
L’architecture de sécurité doit favoriser la récupération, et pas seulement la prévention
Les discussions traditionnelles sur la cybersécurité se concentrent souvent sur la prévention des accès non autorisés. La résilience industrielle exige une perspective plus large.
Un composant compromis ou défectueux peut malgré tout survenir malgré les contrôles préventifs. L’architecture doit donc limiter la capacité de ce composant à affecter les fonctions critiques et fournir une voie de récupération définie.
Cela crée trois objectifs d’ingénierie complémentaires :
- Prévenir les comportements non autorisés ou involontaires.
- Contenir les défaillances et les composants compromis.
- Récupérer les services affectés tout en maintenant les opérations non affectées.
Pour l’automatisation industrielle, cette combinaison est plus pratique que de compter uniquement sur la prévention.
QNX comme plateforme fondamentale en temps réel
QNX fournit une architecture de système d’exploitation à micro-noyau temps réel strict, conçue pour les systèmes dans lesquels l’exécution prévisible, l’isolation des processus et l’accès contrôlé aux ressources sont importants.
Dans une architecture d’automatisation industrielle, QNX peut fournir l’environnement d’exécution fondamental pour les applications, les pilotes, les piles de protocoles et les systèmes de fichiers fonctionnant dans des espaces d’adressage protégés. L’ordonnancement fondé sur les priorités peut prendre en charge des charges de travail ayant des exigences temporelles différentes.
Cette architecture peut compléter le contrôle basé sur des automates plutôt que le remplacer.
Un système pratique peut conserver des automates pour le contrôle établi au niveau terrain, tout en utilisant des plateformes informatiques basées sur des MPU ou des SoC et exécutant un système d’exploitation temps réel pour l’IHM, la vision industrielle, la connectivité, l’analytique, les fonctions de supervision et les charges de travail liées à l’IA.
Une architecture pratique pour la modernisation industrielle
Un système industriel moderne peut donc être considéré comme composé de plusieurs couches coopérantes :
- Couche terrain : capteurs, actionneurs, variateurs et autres équipements physiques.
- Couche de contrôle : automates programmables et contrôleurs exécutant une automatisation déterministe.
- Couche informatique : plateformes MPU/SoC fournissant une capacité de traitement supplémentaire.
- Couche d’intelligence : vision industrielle, analytique, inférence par IA et autres charges de calcul.
- Couche de supervision : IHM, diagnostics, gestion des événements et applications opérationnelles.
- Couche de connectivité : réseaux industriels et services de communication externes.
- Couche logicielle fondamentale : système d’exploitation temps réel, isolation, ordonnancement, gestion des ressources et mécanismes de récupération.
La principale exigence d’ingénierie consiste à définir les limites entre ces couches plutôt qu’à considérer l’ensemble de l’environnement informatique comme un espace applicatif indifférencié.
La modernisation doit préserver les investissements existants dans le contrôle
Les équipements industriels restent souvent opérationnels pendant de nombreuses années. Remplacer un contrôle établi basé sur des API simplement parce que de nouvelles capacités de calcul sont disponibles n'est pas toujours justifié sur le plan technique ou économique.
Une stratégie de modernisation plus pragmatique consiste à préserver les fonctions de contrôle éprouvées tout en ajoutant des ressources de calcul autour d'elles.
Les plateformes basées sur des MPU et des SoC peuvent fournir la capacité de traitement requise pour les IHM modernes, l'IA, l'analyse, la visualisation et la connectivité, tandis que les API existants continuent d'assurer un contrôle déterministe.
Cette approche permet aux fabricants d'introduire de nouvelles fonctionnalités sans perturber inutilement les architectures de contrôle établies.
Mon point de vue d'ingénieur : la résilience commence par l'architecture
La leçon la plus importante de cette transition est que la résilience ne peut pas être ajoutée après la consolidation du système.
Lorsque le contrôle, la mise en réseau, l'IHM, l'analyse et l'IA partagent des ressources de calcul, les mécanismes d'isolation et de récupération doivent faire partie de l'architecture initiale.
Un processeur puissant ne suffit pas, à lui seul, à créer un système d'automatisation résilient. De même, un modèle d'IA ne rend pas un système d'automatisation intelligent si la plateforme environnante ne peut pas acquérir les données, exécuter le modèle, valider ses résultats, appliquer des politiques prédéfinies et réagir dans les limites opérationnelles requises.
La prochaine génération d'automatisation industrielle dépendra donc non seulement de performances de calcul supérieures, mais aussi de la manière dont l'architecture logicielle contrôle efficacement les interactions entre les charges de travail.
Conclusion
L'automatisation industrielle entre dans une architecture où les API, les processeurs hautes performances, l'IA, la connectivité et les fonctions définies par logiciel fonctionnent de plus en plus ensemble.
Cela crée d'importantes possibilités de modernisation, mais introduit également de nouvelles dépendances et de nouveaux modes de défaillance.
Une architecture résiliente doit combiner une exécution déterministe, l'isolation des processus, la protection de la mémoire, un accès contrôlé aux ressources, le confinement des défaillances, la gestion du cycle de vie de la cybersécurité et des mécanismes de récupération définis.
Les systèmes d'exploitation temps réel basés sur un micronoyau, tels que QNX, représentent une approche architecturale pour répondre à ces exigences. Utilisées parallèlement aux technologies existantes d'API et de contrôleurs, ces plateformes peuvent fournir les fondations logicielles nécessaires à l'intégration de charges de travail informatiques modernes, tout en maintenant des limites claires autour des fonctions d'automatisation critiques.
