Dans tous les secteurs industriels — ferroviaire, énergie, fabrication, médical, aéronautique, automobile — les systèmes critiques font face à un changement rapide : complexité fonctionnelle croissante, besoin d’agilité, impératifs de cybersécurité, pression réglementaire et cycles d’innovation toujours plus courts. En réponse, une approche gagne régulièrement du terrain : le software-defined safety (SDS). Cette architecture permet de concilier sûreté de fonctionnement, flexibilité logicielle, cybersécurité et coûts de maintenance réduits.
Cet article explore le paradigme en trois parties, suivies d’un regard sur les piles de communication de sûreté et non-sûreté d’ISIT-Neperis.
Software-defined safety : dépasser le tout-matériel
Historiquement, la sûreté de fonctionnement reposait sur un matériel dédié, certifié et figé. Cette approche apporte robustesse et prévisibilité — mais elle a un défaut majeur : le matériel ne s’adapte pas. Dans un monde où les exigences évoluent plus vite que les cycles industriels, cette rigidité devient un goulot d’étranglement.
Le problème : des systèmes trop rigides
- Tout changement fonctionnel exige souvent une modification matérielle, rendant les améliorations coûteuses, lentes et difficiles à déployer.
- Les équipements de sûreté certifiés sont rarement évolutifs, car tout changement significatif impose une re-certification lourde, freinant l’innovation et les mises à jour.
- La montée des cybermenaces appelle des mises à jour plus fréquentes, mais les architectures traditionnelles, rigides et peu modulaires, s’accommodent mal de ce besoin de mise à jour régulière.
La réponse : rendre la sûreté 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 de sûreté. Cela permet de construire un système flexible, adaptable et certifiable dans la durée.
Il ne s’agit pas de minimiser le matériel — au contraire, il demeure le socle robuste et déterministe sur lequel tout repose. Le logiciel, lui, devient le moteur de la conformité dynamique, de la reconfigurabilité et de la mise à jour continue des mécanismes de sûreté et de sécurité.
Une architecture hybride : un hyperviseur + un OS de sûreté + un OS non-sûreté
Au cœur du software-defined safety se trouve un modèle d’architecture moderne bâti sur trois piliers : un matériel partagé, un hyperviseur certifiable, et deux environnements d’exécution distincts capables malgré tout de coopérer.
Un seul matériel, partagé entre niveaux de criticité
Un unique SoC/CPU exécute simultanément :
- les fonctions de sûreté (temps réel dur, sûreté de fonctionnement) ;
- les fonctions non-sûreté (interface graphique, connectivité, analytique, maintenance, IA embarquée, etc.).
Cette mutualisation réduit le coût, la consommation et la complexité matérielle, tout en simplifiant la maintenance et l’évolution de la plateforme.
Un hyperviseur certifiable : la pierre angulaire
L’hyperviseur joue un rôle central dans l’architecture SDS. Il assure :
- une isolation stricte entre les partitions de sûreté et non-sûreté ;
- l’exécution parallèle de plusieurs systèmes d’exploitation ;
- une allocation déterministe des ressources (CPU, mémoire, timers, etc.) ;
- un périmètre de certification réduit ;
- une meilleure résilience face aux attaques et aux défaillances.
Grâce à un micronoyau minimal, stable et certifiable, il garantit que les environnements critiques et non critiques coexistent sans interférence.
Deux systèmes d’exploitation distincts — conçus pour coopérer
| Environnement | Rôle | Bénéfices |
|---|---|---|
| OS de sûreté | Exécute les fonctions critiques (IEC 61508, ISO 26262, EN 50128, DO-178, etc.) | Déterminisme, certification, stabilité |
| OS non-sûreté | Héberge les fonctions applicatives évolutives (UI, connectivité, IA embarquée, etc.) | Agilité, mises à jour fréquentes, innovation |
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 de sûreté.
Flexibilité et cybersécurité : le duo gagnant des architectures SDS
Les industriels évoluent désormais dans un environnement où ils doivent :
- appliquer des mises à jour de sécurité régulières (patching) ;
- se conformer aux exigences réglementaires modernes (NIS2, R155/R156 automobile, 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
Séparer la sûreté de la non-sûreté ouvre la voie à une maintenance logicielle plus fluide :
- l’OS non-sûreté peut être mis à jour fréquemment sans affecter le périmètre certifié ;
- l’OS de sûreté reste stable, avec des cycles de validation maîtrisés et moins fréquents ;
- 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 meilleur time-to-market et une capacité d’évolution bien supérieure aux architectures traditionnelles.
Une cybersécurité renforcée par l’architecture
Le software-defined safety améliore directement le niveau de cybersécurité :
- isolation claire des domaines applicatifs ;
- surface d’attaque réduite ;
- déploiement plus rapide 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églementés, tout en maintenant un haut niveau de sûreté de fonctionnement.
La communication de sûreté intégrée à une approche SDS
Dans une architecture software-defined safety, la communication critique doit elle aussi être livrée sous forme de briques logicielles certifiables. Les piles de sûreté d’ISIT-Neperis — CANopen Safety, CANopen Safety certifiable SIL3, FSoE (Safety over EtherCAT) et J1939 Safety certifiable — s’inscrivent directement dans ce modèle, offrant des solutions modulaires et portables conçues sans code tiers, adaptées à n’importe quel processeur, OS ou même environnement bare-metal.
Certaines de ces piles sont disponibles en versions pré-certifiées ou certifiables jusqu’au SIL3, telles que la pile CANopen Safety certifiable — unique sur le marché — ou la pile FSoE, conforme à l’IEC 61784-3-12 et utilisable en mode maître ou esclave (MainInstance/SubInstance).
Dans le modèle SDS, ces piles se placent naturellement dans la partition OS de sûreté, où elles gèrent les échanges critiques, tandis que l’hyperviseur garantit leur isolation et leur intégrité. Elles contribuent à une architecture cohérente et robuste :
- une communication de sûreté certifiable ;
- un périmètre de sûreté mieux maîtrisé ;
- une intégration simplifiée avec les fonctions de sûreté existantes.
Les piles d’ISIT-Neperis complètent ainsi efficacement l’approche software-defined safety, en fournissant des composants de communication de sûreté fiables et certifiables, parfaitement alignés sur les exigences des systèmes industriels modernes. Découvrez les piles de communication ISIT-Neperis →
Conclusion
Le software-defined safety marque une avancée majeure dans la conception des systèmes industriels critiques. En combinant un hyperviseur, un OS de sûreté et un OS non-sûreté sur une seule plateforme matérielle, cette approche réunit :
- une sûreté de fonctionnement maîtrisée ;
- une flexibilité logicielle qui permet d’adapter le système sans repenser le matériel ;
- une innovation continue grâce à un OS non-sûreté évolutif ;
- des mises à jour simplifiées, y compris les correctifs de sécurité ;
- un renforcement natif de la cybersécurité par l’isolation et la segmentation.
Avec ses piles de communication de sûreté et non-sûreté modulaires et certifiables conçues pour les architectures modernes, ISIT-Neperis aide les industriels à tirer pleinement parti du SDS en fournissant des briques logicielles fiables et intégrables, prêtes à accompagner leur transition vers des systèmes plus sûrs, plus ouverts et plus durables.
Parlez-en à notre équipe pour intégrer une communication de sûreté certifiable dans votre plateforme SDS.
Adapté de l’article ISIT « Software-Defined Safety : la révolution logicielle de la sûreté dans l’industrie » (isit.fr).