This article, written in the form of an essay and case study, explores a set of practical recommendations (architecture, lifecycle, human factors, obsolescence, compliance, operations & maintenance, migration) and highlights the relevant normative principles that can address this type of development.

This reflection originated from client requests in the railway sector, where safety-related challenges are particularly critical. As I did not initially have in-depth expertise in this specific domain, this study is primarily a personal analytical exercise: a structured attempt to understand how I would approach the problem if I were leading the project, integrating the normative, technical, and human constraints inherent to safety-critical systems.

Cet article, rédigé sous forme d’essai et d’étude de cas, explore un ensemble de recommandations pratiques (architecture, cycle de vie, facteurs humains, obsolescence, conformité, exploitation & maintenance, migration) et met en évidence les principes normatifs de référence permettant de répondre à ce type de développement.

Cette réflexion est née à la suite de demandes clients dans le domaine ferroviaire, confrontées à des enjeux forts en matière de sûreté (safety). N’ayant pas initialement une expertise approfondie dans ce domaine spécifique, cette étude constitue avant tout une démarche personnelle d’analyse : une tentative structurée de comprendre comment j’aborderais le problème si j’étais aux commandes du projet, en intégrant les contraintes normatives, techniques et humaines propres aux systèmes critiques.

Principes maîtres (résumé rapide)

• Sécurité et sûreté d’abord : la priorité est donnée à l’identification et à la maîtrise des risques tout au long du cycle de vie du système, selon un processus structuré : Hazard Analysis → définition des exigences → conception → vérification et validation → exploitation. Intertek
• • HARA (Hazard Analysis and Risk Assessment) correspond à l’analyse des dangers et à l’évaluation des risques. Cette étape consiste à identifier tous les dangers potentiels liés au système, à estimer leur gravité et leur probabilité, puis à déterminer les mesures de sécurité nécessaires.

Cette approche est essentielle car elle permet de :

• détecter et traiter les risques dès les premières phases de développement,
• définir des exigences de sécurité claires et vérifiables,
• réduire les accidents et incidents pendant l’exploitation,
• assurer la conformité avec les normes de sûreté et de sécurité.

Ainsi, HARA constitue la base pour garantir que la sécurité et la sûreté sont intégrées de manière proactive dans le cycle de vie du système, conformément aux recommandations d’Intertek.

Danger (Hazard)	Probabilité (1‑5)	Gravité (1‑5)	Score de risque (P × G)	Priorité	Mesures de mitigation
Erreur humaine : saisie incorrecte d’un horaire	3	4	12	Moyenne	Validation automatique, double contrôle, formation des opérateurs
Conflit de trafic : deux trains sur la même voie	2	5	10	Haute	Alertes automatiques, verrouillage de la réservation de voie, plan de contingence
Défaillance logicielle : plantage ou bug critique	2	5	10	Haute	Redondance serveurs, sauvegardes automatiques, tests réguliers
Défaillance communication : perte liaison postes-trains	3	4	12	Moyenne	Système de communication de secours, procédures manuelles, surveillance en temps réel
Intrusion / attaque cyber	1	5	5	Moyenne	Authentification forte, surveillance réseau, mises à jour régulières
Conditions externes : obstruction voie, intempéries	3	4	12	Moyenne	Détection obstacles, plans alternatifs, alertes météo intégrées
Perte de données critiques	1	5	5	Moyenne	Sauvegardes fréquentes, réplication sur plusieurs sites, plan de récupération

• Cycle de sûreté/SSIL

Hazard Analysis

– Identifier les dangers et risques

– Classer selon criticité

– Résultat : liste des hazards et exigences de sécurité initiales

Safety & Security Requirements

– Définir exigences fonctionnelles et non-fonctionnelles

– Traçabilité vers les hazards identifiés

– Base pour le design et les tests

System / Software Analysis ‘Design’

– Analyse de conception globale et architecture

– Vérification que l’architecture peut satisfaire les exigences de sûreté

– Préparer les bases pour le design détaillé

Software Detailed Design ‘Design’

– Définition des modules, interfaces, mécanismes de sécurité

– Design détaillé de chaque composant logiciel

– Spécification des tests unitaires et d’intégration correspondants

Implementation (Coding) ‘Design’

– Codage effectif des modules selon le design

– Mise en place des mécanismes de sécurité

– Conformité avec les exigences et normes applicables

Unit Testing ‘Design’

– Tester chaque module individuellement

– Vérification du comportement attendu

– Documentation des résultats et anomalies

Integration Testing ‘Design’

– Tester les interactions entre modules

– Vérification des interfaces et communication

– Validation partielle des exigences fonctionnelles

System Verification

– Vérification complète du système par rapport aux exigences

– Test de conformité et de sûreté fonctionnelle

– Résultats documentés pour audits

System Validation

– Validation sur environnement réel ou simulé

– Vérification que le système répond aux besoins opérationnels et exigences de sûreté

– Confirmation finale avant mise en production

Operation / Maintenance

– Déploiement et exploitation du logiciel

– Suivi des incidents, corrections et mises à jour

– Boucle de retour d’expérience pour améliorer le cycle

Modularité & interfaces ouvertes : découper en composants remplaçables (interlocking, traffic management, RBC/ETCS, HMI, comms).

• Interlocking : module critique pour la sécurité, contrôle les itinéraires et assure qu’il n’y a pas de conflit de circulation.
• Traffic Management : planifie et supervise le trafic, reçoit et envoie des données aux autres modules.
• RBC / ETCS : communique avec les trains et coordonne la vitesse et l’espacement, en interaction avec Interlocking et Traffic Management.
• Comms : module dédié aux communications entre modules et avec les équipements externes.
• HMI : interface pour l’opérateur, connectée aux modules critiques via des interfaces ouvertes.

Explication des flux

Traffic Management → RBC/ETCS

• Envoie plan de circulation, priorités, contraintes de trafic.
• Reçoit l’état global du trafic et alertes de sécurité.

RBC/ETCS ↔ Interlocking

• RBC/ETCS reçoit l’état des itinéraires du blocage.
• Interlocking reçoit les ordres de verrouillage/déverrouillage.

HMI ↔ Tous les modules

• L’opérateur visualise l’état du système et peut envoyer des commandes.
• HMI reçoit des notifications critiques, alertes, ou états de sécurité.

Comms ↔ Tous les modules

• Transporte les données entre modules et vers l’extérieur (trains, centre de contrôle).

Interfaces ouvertes

• Tous les flux utilisent des interfaces standardisées pour assurer interopérabilité et modularité.

1. Indépendance technologique : abstraction matériel/OS, virtualisation et « hardware independence » pour remplacer facilement des sous-systèmes.
2. Conception pour la maintenance et l’évolution : API stables, versioning, migration clear paths, et tests automatisés.
3. Facteur humain intégré : conception HMI centrée opérateur, procédures, formation continue et ergonomie d’alarmes.

Normes et conformité (points de référence)

• S’appuyer sur IEC 61508 (cadre générique de sécurité fonctionnelle) pour la gouvernance du cycle de vie. Intertek
• Utiliser EN 50128 pour le développement logiciel ferroviaire (SIL, techniques recommandées). verifysoft.com+1
• Utiliser EN 50129 pour la qualification des systèmes électroniques de signalisation. BSI Knowledge+1
• Pour interopérabilité et contrôle de trafic européen, se référer à ERTMS/ETCS (spécifications opérationnelles, exigences Train Data). European Union Agency for Railways+1

Architecture recommandée (niveau système)

1. Architecture en couches + séparations fortes
   • Couche matérielle (I/O, PLC certifiés)
   • Couche temps réel / safety-critical (interlockings, RBC) avec redondance physique/logique.
   • Couche services non-safety (planification, optimisation, UI avancée) 🡪 peut évoluer plus vite
   • Couche d’intégration / bus avec interfaces formelles (messages versionnés, protobuf/ASN.1/standard ferroviaire)
2. Principes de résilience
   • Redondance active/active ou active/standby selon la fonction et le SIL
   • Détection et basculement automatiques, et comportements ‘fail-safe’ clairement définis
3. Isolation des responsabilités (séparer fonctions critiques et non-critiques pour limiter surface de défaillance)

Langages, outils, techniques d’ingénierie

• Langages : pour fonctions safety-critical privilégier des langages/modes faciles à analyser (ex. Ada/SPARK, MISRA C/C++ avec conformité) et justifier par la norme.
• Outils certifiés : utiliser outils qualifiables/certifiés pour compilation, traceabilité, analyse statique (EN 50128 recommande l’analyse statique pour SIL≥1). CodeSecure
• Méthodes formelles : pour les parties critiques (interlock, calcul de sécurité), appliquer spécification formelle + preuve (model checking, proofs) quand possible.
• CI/CD contrôlé : pipeline d’intégration automatisé mais réglementé (gates manuelles pour releases certifiées).

Gestion de l’obsolescence (30+ ans)

1. Abstraction matérielle et couches d’adaptateurs 🡪 pouvoir remplacer les CPU, cartes I/O sans toucher à la logique métier.
2. Virtualisation et conteneurisation 🡪 empaqueter les fonctions dans des VMs ou des conteneurs certifiables pour portage ultérieur.
3. Catalogue de versions & stratégie de migration 🡪 politique LTS (Long-Term Support), compatibilité ascendante des messages et scripts de migration.
4. Stock de pièces & stratégie fournisseurs 🡪 obligations contractuelles sur disponibilité des pièces, droit à la maintenance, code escrow.
5. Open interfaces & standards 🡪 éviter solutions propriétaires exclusives ; garantir remplaçabilité des fournisseurs.
6. Digital twin / simulation 🡪 maintenir un jumeau numérique pour tester upgrades et migrations avant déploiement.

Facteur humain & opérations

• HMI / opérateur : conception centrée utilisateur, normalisation des alarmes (priorité, clarté), training simulators intégrés.
• Automation vs. opérateur : garder opérateur «dans la boucle» pour décisions critiques, mais réduire charge cognitive par automation assistée.
• Procédures & formation : maintenances, updates, scénarios d’incident, exercices réguliers.
• Organisation : équipes d’exploitation et maintenance formées au long terme ; documentation vivante et accessible.

Tests, vérification et validation

• V&V complet : tests unitaires, tests d’intégration, tests système, tests d’acceptation, tests en charge et tests de régression.
• Simulation & fuzzing : simuler trafic, panne capteur, anomalies comms.
• Tests sécurité/cyber : audits réguliers, pentests, tests de résilience aux attaques.
• Certification : dossier de sûreté conforme EN 50128/50129 + preuves/artefacts contrôlables.

Cybersécurité

• Séparation réseau (safety vs. management), chiffrement des liaisons critiques, authentification forte, gestion des clés, mise à jour sécurisée.
• Plan de réponse incident et sécurité «by design». (la sécurité et la gestion des incidents sont pensées dès l’architecture du système, pas traitées comme un correctif ou une option plus tard.)

Données, monitoring et exploitation

• Observabilité : télémétrie fine (santé HW, latence, erreurs), logging structuré, alerting SLO/SLA.
• Maintenance prédictive : analytics pour anticiper pannes et planifier remplacements.
• Archivage & traçabilité : logs immuables pour incidents & forensic (analyse technique post-incident visant à comprendre exactement ce qui s’est passé, de manière factuelle, traçable et exploitable juridiquement ou réglementairement.).

Gouvernance produit & contrat fournisseur

• Requirements basés risque (safety cases), ownership clair des interfaces.
• Clauses long-term support (SLA, pièces, code escrow – e.g code déposé chez un tiers indépendants), audits réguliers fournisseur.
• Politique de format de données et API stables.

Roadmap pratique (phases)

1. Concept & hazard analysis (FMECA/Hazard Log) → définir SILs. Intertek+1
2. Architecture & spécifications formelles (interfaces, modes dégradés)
3. Prototype modulaire + tests formels des blocs critiques
4. Qualification outils & process (outils analysers, config management) 🡪 conforme EN 50128/29. verifysoft.com+1
5. Industrialisation, déploiement en shadow-mode (tests sur réseau simulé, exécution du nouveau système ou de la nouvelle version en parallèle du système officiel, sans qu’il n’influence la production réelle.)
6. Opération, monitoring, évolution & plan de migration continu

Exemples de pratiques concrètes (checklist rapide)

• Tracer chaque requirement jusqu’au code + tests (DOORS / JIRA + lien).
• Utiliser analyse statique + couverture MC/DC pour modules critiques. CodeSecure
• Redondance géographique pour centres de contrôle principaux/secours.
• Contrôle de versions strict, tags releases certifiées, audits externes périodiques.
• Jumeau numérique pour valider MAJ avant déploiement live.
• Contrats fournisseur incluant right-to-fix et code-escrow.

Risques principaux & mitigations

• Obsolescence HW → mitigé par abstraction et contrat fournisseurs.
• Dégradation des compétences → mitigation : formation continue, documentation, pair-programming, apprenticeship.
• Dette technique → mitigation : temps dédié au refactoring, tests, CI.
• Attaques cyber → mitigation : défense en profondeur, patching contrôlé.
• Évolutions réglementaires → mitigation : veille, conformité et modularité pour petites mises à jour.

Références clés (pour approfondir)

• IEC 61508 — cadre de sécurité fonctionnelle. Intertek
• EN 50128 — logiciel pour systèmes de contrôle et protection ferroviaire (SIL, techniques). verifysoft.com+1
• EN 50129 — systèmes électroniques de signalisation sécurité. BSI Knowledge+1
• Spécifications ERTMS / ETCS (Train Data & opérations). European Union Agency for Railways+1
• Rôle de l’analyse statique & outils qualifiables pour EN 50128. CodeSecure

Intégrer de nouveaux langages ou autres nouvelles techno ? (Intelligence artificielle, Rust, go, … ) Quid de l’obsolescence ? Quid du long terme ?

Le choix initial d’insister sur Ada/SPARK, C/MISRA, etc., vient du contexte ferroviaire safety-critical : on parle de systèmes certifiés SIL 4 (les plus exigeants), où robustesse, auditabilité et traçabilité passent avant la nouveauté technologique. Mais ça ne veut pas dire qu’on doit ignorer les nouveaux langages/techniques.

Pourquoi les nouveaux langages ne sont pas encore massivement utilisés en ferroviaire

1. Certification et maturité
   • Les normes (EN 50128/50129) imposent de qualifier outils, compilateurs, libs → processus long (souvent plusieurs années).
   • Ada/SPARK, C/MISRA ont 30+ ans d’historique dans l’aéronautique et le ferroviaire, donc déjà « prouvés » et documentés.
   • Rust, Go, Python, etc. n’ont pas encore ce pedigree safety (pas de compilateur qualifié, pas de guidelines certifiées SIL).
2. Écosystème
   • Rust, Go évoluent vite → risque de rupture de compatibilité, difficile à figer pour un système censé durer 30 ans.
   • Ada/SPARK est stable et spécifiquement conçu pour vérification formelle, contrats, absence de comportements indéfinis.
3. Outils et formation
   • Les équipes ferroviaires sont formées sur des langages « classiques » ; il faut aussi tenir compte du facteur humain (compétences disponibles pour maintenance dans 20 ans).
   • Les nouvelles technos manquent parfois de main-d’œuvre certifiée ou de formations standardisées.

Où intégrer Rust, Go, IA, etc. de manière réaliste

• Rust
  • Excellent candidat à moyen terme pour du safety-critical (ownership model, élimination des UB, gestion mémoire sûre).
  • Peut être introduit dans les couches non-safety (diagnostic, outils, cybersécurité) au début.
  • S’il se stabilise et gagne en certification (comme MISRA pour C/C++), il deviendra un choix pertinent pour du code safety.
• Go
  • Pas conçu pour temps réel strict, mais très bien pour couches non-critiques : supervision, orchestration, monitoring distribué.
  • Son runtime garbage collector est rédhibitoire pour SIL, mais pas pour outils IT ferroviaires.
• IA / ML
  • Pas pour le contrôle safety (black box, pas de preuve formelle possible aujourd’hui).
  • Mais très utile en maintenance prédictive, optimisation de trafic, analyse de logs/anomalies.
  • Placée dans les couches non-safety avec interfaces claires → on garde le cœur certifié immuable, mais on évolue côté performance & maintenance.
• Python, Julia, R
  • Idéaux pour R&D, simulation, prototypage, analyse de données → mais jamais dans le chemin critique safety.

Vue long terme (>30 ans)

1. Principe clé :
   • Séparer fonctions safety (langages stables, preuves formelles, cycles de vie figés)
   • et fonctions non-safety (langages modernes, agiles, évolutifs).
2. Évolutivité :
   • Le socle safety est volontairement conservateur (Ada/SPARK, C/MISRA, peut-être Rust un jour).
   • Les couches non-safety profitent de l’innovation (Go, Rust, IA).
   • Interfaces stables (API/message bus) → permettent de remplacer/moderniser les couches non-safety sans recertifier le noyau.
3. Obsolescence :
   • Langages modernes = risque d’évolution rapide → il faut prévoir un processus de gel de versions (long-term support) pour ne pas être dépendant d’une lib ou runtime abandonné.
   • En parallèle, prévoir un plan de migration documenté (tests automatisés, conteneurisation, virtualisation).

La raison pour laquelle Rust/Go/IA n’ont pas été abordé dans un premier temps :

• En safety-critical certifié, ils ne sont pas encore utilisables comme base de confiance.
• mais ils ont clairement une place dans l’architecture globale, surtout dans les couches non-safety (diagnostic, optimisation, maintenance, IA prédictive).
• Rust, en particulier, a un potentiel réel de devenir un futur standard safety (comme Ada dans les années 90).

Schéma d’architecture sur 30 ans montrant :

• quelles couches restent figées en Ada/SPARK ou C/MISRA,
• et où Rust/Go/IA peuvent entrer progressivement sans compromettre la certification 

Explication synthétique (ce que montre le schéma)

1. Séparation claire Safety vs Non-Safety — le cœur safety (interlocking, RBC) reste figé, certifiable (Ada/SPARK, MISRA C aujourd’hui), avec maintenance strictement contrôlée.
2. Interfaces stables et versionnées — bus de messages signés (ASN.1 / Protobuf + signature), points d’adaptateurs qui isolent le cœur des innovations.
3. Adoption progressive :
   • Années 0–5 : containers, virtualisation, Go pour orchestration, IA/ML pour analytics (non-safety), commencer R&D Rust dans non-safety.
   • Années 5–15 : Rust consolidé en non-safety/temps-réel dur, migration de services non-critiques vers Rust quand stable. Continuer virtualisation et hardening des runtimes.
   • Années 15–30 : évaluer qualification de Rust pour modules safety (après qualification d’outils & preuves formelles). Maintien du core gelé + remplacements matériel via abstraction.
4. Mesures transverses : jumeau numérique (digital twin) pour tests, CI/CD contrôlé, catalogues de versions LTS, code escrow, contrats fournisseurs, monitoring avancé et maintenance prédictive.

Carte rapide d’affectation des technos (exemples)

• Safety-critical (SIL3/4) : Ada/SPARK, C (MISRA), outils formels, compilateurs qualifiés.
• Hard real-time non-safety : C++, Rust (après qualification expérimentale).
• Services distribués / orchestration : Go, Rust, Kubernetes (pour non-safety).
• Analytics / IA / Prototypage : Python, frameworks ML (isolés hors du chemin safety).
• Interfaces & messages : ASN.1 / Protobuf, versioning sémantique, signatures.

Plan de migration concret (5 étapes immédiates)

1. Geler et documenter le core : safety case, API publiques, hazard log.
2. Standardiser les interfaces : choisir format (ASN.1/protobuf), signer messages, versioning.
3. Conteneuriser les services non-safety : orchestre avec Kubernetes privé, déployer IA en sandbox.
4. R&D Rust : créer modules prototypes en Rust pour monitoring/gateway; valider performance, outils d’analyse statique et preuves.
5. Qualification progressive : lancer qualification d’outils Rust, définir règles de codage et tests (MC/DC, formal proofs) si avancée.

Conclusion / Conclusion

Cet article illustre comment aborder le développement logiciel pour des systèmes ferroviaires safety-critical en combinant analyse personnelle, étude de cas et références normatives, en soulignant l’importance d’une séparation claire entre fonctions safety et non-safety : un cœur certifiable figé (Ada/SPARK, C/MISRA) et des couches non-critiques ouvertes à l’innovation (Rust, Go, IA/ML). Le cycle de vie intégrant HARA, exigences safety, design modulaire, tests et validation, ainsi que des mesures transverses comme le jumeau numérique, CI/CD contrôlé et gestion de l’obsolescence, assure robustesse et pérennité sur 30 ans. Cette réflexion montre que l’introduction progressive de nouvelles technologies est possible sans compromettre la certification, à condition de respecter les interfaces stables, la traçabilité et la gouvernance formelle.

This article illustrates an approach to software development for safety-critical railway systems, combining personal reflection, case study, and normative references, emphasizing a clear separation between safety-critical and non-critical functions: a frozen certifiable core (Ada/SPARK, C/MISRA) and non-critical layers open to innovation (Rust, Go, AI/ML). The lifecycle, including HARA, safety requirements, modular design, testing and validation, along with cross-cutting measures such as digital twins, controlled CI/CD, and obsolescence management, ensures robustness and sustainability over 30 years. This reflection shows that gradual integration of new technologies is feasible without compromising certification, provided stable interfaces, traceability, and formal governance are maintained.