Software-Defined Safety : la révolution logicielle de la sûreté dans l’industrie

Temps de lecture : 6-8 minutes - Juin 2026

Dans tous les secteurs industriels : ferroviaire, énergie, manufacturing, médical, aéronautique, automobile, les systèmes critiques sont confrontés à une évolution rapide : complexification des fonctionnalités, besoin d’agilité, impératifs de cybersécurité, pressions réglementaires et cycles d’innovation toujours plus courts.
Face à ces défis, une approche s’impose progressivement : le software-defined safety (SDS).
Cette architecture permet de concilier sûreté de fonctionnement, flexibilité logicielle, sécurité informatique et réduction des coûts de maintenance.

Cet article explore ce paradigme en trois parties, suivies d’une présentation de l’offre ISIT en stacks safety & non-safety.

Historiquement, la sûreté de fonctionnement (Safety) reposait sur du matériel dédié, certifié, figé. Cette approche offre robustesse et prévisibilité… mais souffre d’un défaut majeur : le hardware ne s’adapte pas.
Dans un monde où les exigences changent plus vite que les cycles industriels, cette rigidité devient un frein.

Le constat : des systèmes trop figés

• Toute évolution fonctionnelle nécessite souvent une modification matérielle, ce qui rend les améliorations coûteuses, longues et difficiles à déployer.
• Les dispositifs certifiés safety restent rarement évolutifs, car chaque changement important impose une recertification lourde, freinant l’innovation et les mises à jour.
• La montée des menaces cyber impose des mises à jour plus fréquentes, mais les architectures traditionnelles, rigides et peu modulaires, absorbent mal ces besoins de mise à jour régulière.

La réponse : rendre la Safety programmable

Le software-defined safety consiste à transférer au logiciel – plutôt qu’au matériel – la responsabilité d’exécuter, d’isoler et d’orchestrer les fonctions safety.
Cette approche permet de construire un système flexible, adaptable et certifiable sur la durée.

Il ne s'agit pas de diminuer l’importance du hardware, au contraire, celui-ci reste la fondation robuste et déterministe sur laquelle repose l’ensemble.

Le logiciel, quant à lui, devient le moteur de la conformité dynamique, de la reconfigurabilité et de la mise à jour continue des mécanismes de sécurité et de sûreté.

Le cœur du software-defined safety repose sur un modèle d’architecture moderne, basé sur trois piliers : un matériel mutualisé, un hyperviseur certifiable et deux environnements d’exécution séparés mais capables de coopérer.

Un hardware unique, partagé entre plusieurs niveau de criticité

Un même SoC/CPU exécute simultanément :

• Des fonctions safety (temps réel strict, sûreté de fonctionnement)
• Des fonctions non-safety (GUI, connectivité, analytique, maintenance, IA embarqué…).

Cette mutualisation permet de réduire les coûts, la consommation énergétique et la complexité matérielle, tout en simplifiant la maintenance et l’évolution des plateformes.

Un hyperviseur certifiable : la pierre angulaire (ou le socle de confiance)

L’hyperviseur joue un rôle central dans l’architecture SDS, il assure :

• Une isolation stricte entre partitions safety et non-safety
• L’exécution parallèle de plusieurs OS
• Une allocation déterministe des ressources (CPU, mémoire, timers…)
• Une réduction du périmètre de certification
• Une meilleure résilience face aux attaques et aux fautes

Grâce à son un micro-noyau minimal, stable, certifiable, il garantit que les environnements critiques et non-critiques coexistent sans interférences.

Deux OS séparés… mais conçus pour coopérer

Cette séparation fonctionnelle permet d’innover rapidement sur les services non-critiques tout en préservant l’intégrité, la conformité et la stabilité des fonctions safety.

Les industriels évoluent désormais dans un environnement où ils doivent :

• appliquer des mises à jour de sécurité régulières (patching),
• se conformer à des exigences réglementaires modernes (NIS2, R155/R156 automotive, directives IACS, etc.),
• protéger des infrastructures critiques de plus en plus exposées aux attaques.

Un système conçu pour les mises à jour continues

La séparation Safety / Non Safety ouvre la voie à une maintenance logicielle plus fluide :

• l'OS non Safety peut être mis à jour fréquemment sans impacter le périmètre certifié ;
• l'OS Safety reste stable, avec des cycles de validation maitrisés et plus espacés ;
• l’hyperviseur garantit l’intégrité de l’ensemble, en isolant les mises à jour du reste du système.

Résultat : des cycles de maintenance plus courts, un time-to-market amélioré et une capacité d’évolution bien supérieure aux architectures traditionnelles.

Une cybersécurité renforcée par l’architecture

Le software-defined safety contribue directement à améliorer le niveau de cybersécurité :

• isolation claire des domaines applicatifs
• surface d’attaque réduite
• déploiement accéléré des correctifs
• segmentation logicielle renforcée
• compatibilité avec les approches Zero Trust embarquées

L’architecture SDS répond donc à un impératif majeur: sécuriser des systèmes industriels désormais connectés et fortement régulés, tout en maintenant un haut niveau de sureté de fonctionnement.

Dans une architecture software‑defined safety, les communications critiques doivent elles aussi être fournies sous forme de briques logicielles certifiables. Les piles Safety d’ISIT — CANopen Safety, CANopen Safety Certifiable SIL3, FSoE (Safety over EtherCAT) et J1939 Safety Certifiable — s’intègrent directement dans cette logique en offrant des solutions modulaires, portables et conçues sans code tiers, adaptées à tout type de processeur, d’OS ou même d’environnement bare‑metal. [presentationeze.com]

Certaines de ces piles sont disponibles en versions pré‑certifiées ou certifiables jusqu’au niveau SIL3, comme la pile CANopen Safety Certifiable, unique sur le marché, ou la pile FSoE, conforme à la norme IEC 61784‑3‑12 et utilisable en mode Master ou Slave. [ibm.com], [abbreviati...finder.org]

Dans le modèle SDS, ces piles prennent naturellement place dans la partition OS Safety, où elles assurent les échanges critiques, tandis que l’hyperviseur garantit leur isolation et leur intégrité. Elles contribuent ainsi à une architecture cohérente et robuste :

• communications Safety certifiables,
• périmètre de sûreté mieux maîtrisé,
• intégration simplifiée avec les fonctions Safety existantes.

Les stacks ISIT complètent donc efficacement l’approche software‑defined safety en apportant des composants de communication Safety fiables, certifiables et parfaitement alignés avec les exigences des systèmes industriels modernes.

Conclusion

Le software-defined safety constitue une évolution majeure dans la conception des systèmes industriels critiques. En combinantsur une même plateforme matérielle un hyperviseur, un OS Safety et un OS non Safety, cette approche réunit :

• une sûreté de fonctionnement maîtrisé,
• une flexibilité logicielle permettant d’adapter le système sans revoir le matériel,
• une innovation continue grâce à un OS non-Safety évolutif,
• des mises à jour simplifiées y compris de sécurité,
• un renforcement natif de la cybersécurité grâce à l’isolation et à la segmentation.

Avec ses piles de communication Safety et non Safety, modulaires, certifiables et adaptées aux architectures modernes, ISIT permet aux industriels de tirer pleinement parti du SDS en leur offrant des briques logicielles fiables, intégrables et prêtes à accompagner leur transition vers des systèmes plus sûrs, plus ouverts et plus durables.