{"id":1481,"date":"2026-02-17T10:17:08","date_gmt":"2026-02-17T10:17:08","guid":{"rendered":"https:\/\/imalogic.com\/blog\/?p=1481"},"modified":"2026-02-17T10:18:26","modified_gmt":"2026-02-17T10:18:26","slug":"engineering-safe-and-sustainable-railway-software-systems-beyond-30-years-developper-des-systemes-logiciels-ferroviaires-surs-et-durables-sur-plus-de-30-ans","status":"publish","type":"post","link":"https:\/\/imalogic.com\/blog\/2026\/02\/17\/engineering-safe-and-sustainable-railway-software-systems-beyond-30-years-developper-des-systemes-logiciels-ferroviaires-surs-et-durables-sur-plus-de-30-ans\/","title":{"rendered":"Engineering Safe and Sustainable Railway Software Systems Beyond 30 Years – D\u00e9velopper des syst\u00e8mes logiciels ferroviaires s\u00fbrs et durables sur plus de 30 ans."},"content":{"rendered":"\n

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.<\/em><\/p>\n\n\n\n

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.<\/em><\/p>\n\n\n\n

Cet article, r\u00e9dig\u00e9 sous forme d\u2019essai et d\u2019\u00e9tude de cas, explore un ensemble de recommandations pratiques (architecture, cycle de vie, facteurs humains, obsolescence, conformit\u00e9, exploitation & maintenance, migration) et met en \u00e9vidence les principes normatifs de r\u00e9f\u00e9rence permettant de r\u00e9pondre \u00e0 ce type de d\u00e9veloppement.<\/p>\n\n\n\n

Cette r\u00e9flexion est n\u00e9e \u00e0 la suite de demandes clients dans le domaine ferroviaire, confront\u00e9es \u00e0 des enjeux forts en mati\u00e8re de s\u00fbret\u00e9 (safety). N\u2019ayant pas initialement une expertise approfondie dans ce domaine sp\u00e9cifique, cette \u00e9tude constitue avant tout une d\u00e9marche personnelle d\u2019analyse : une tentative structur\u00e9e de comprendre comment j\u2019aborderais le probl\u00e8me si j\u2019\u00e9tais aux commandes du projet, en int\u00e9grant les contraintes normatives, techniques et humaines propres aux syst\u00e8mes critiques. <\/p>\n\n\n\n

<\/p>\n\n\n

Principes ma\u00eetres (r\u00e9sum\u00e9 rapide)<\/h1>\n
\n
S\u00e9curit\u00e9 et s\u00fbret\u00e9 d\u2019abord<\/strong> : la priorit\u00e9 est donn\u00e9e \u00e0 l\u2019identification et \u00e0 la ma\u00eetrise des risques tout au long du cycle de vie du syst\u00e8me, selon un processus structur\u00e9 : Hazard Analysis \u2192 d\u00e9finition des exigences \u2192 conception \u2192 v\u00e9rification et validation \u2192 exploitation<\/strong>. Intertek<\/a><\/li>\n
\n
\n
HARA (Hazard Analysis and Risk Assessment)<\/strong> correspond \u00e0 l\u2019analyse des dangers et \u00e0 l\u2019\u00e9valuation des risques. Cette \u00e9tape consiste \u00e0 identifier tous les dangers potentiels li\u00e9s au syst\u00e8me, \u00e0 estimer leur gravit\u00e9 et leur probabilit\u00e9, puis \u00e0 d\u00e9terminer les mesures de s\u00e9curit\u00e9 n\u00e9cessaires.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
Cette approche est essentielle car elle permet de :<\/p>\n
\n
d\u00e9tecter et traiter les risques d\u00e8s les premi\u00e8res phases de d\u00e9veloppement,<\/li>\n
d\u00e9finir des exigences de s\u00e9curit\u00e9 claires et v\u00e9rifiables,<\/li>\n
r\u00e9duire les accidents et incidents pendant l\u2019exploitation,<\/li>\n
assurer la conformit\u00e9 avec les normes de s\u00fbret\u00e9 et de s\u00e9curit\u00e9.<\/li>\n<\/ul>\n
Ainsi, HARA constitue la base pour garantir que la s\u00e9curit\u00e9 et la s\u00fbret\u00e9 sont int\u00e9gr\u00e9es de mani\u00e8re proactive dans le cycle de vie du syst\u00e8me, conform\u00e9ment aux recommandations d\u2019Intertek.<\/p>\n\n\n\n\n\n\n\n\n\n\n
\n
Danger (Hazard)<\/p>\n<\/td>\n
\n
Probabilit\u00e9 (1\u20115)<\/p>\n<\/td>\n
\n
Gravit\u00e9 (1\u20115)<\/p>\n<\/td>\n
\n
Score de risque (P \u00d7 G)<\/p>\n<\/td>\n
\n
Priorit\u00e9<\/p>\n<\/td>\n
\n
Mesures de mitigation<\/p>\n<\/td>\n<\/tr>\n
\n
Erreur humaine : saisie incorrecte d\u2019un horaire<\/p>\n<\/td>\n
\n
3<\/p>\n<\/td>\n
\n
4<\/p>\n<\/td>\n
\n
12<\/p>\n<\/td>\n
\n
Moyenne<\/p>\n<\/td>\n
\n
Validation automatique, double contr\u00f4le, formation des op\u00e9rateurs<\/p>\n<\/td>\n<\/tr>\n
\n
Conflit de trafic : deux trains sur la m\u00eame voie<\/p>\n<\/td>\n
\n
2<\/p>\n<\/td>\n
\n
5<\/p>\n<\/td>\n
\n
10<\/p>\n<\/td>\n
\n
Haute<\/p>\n<\/td>\n
\n
Alertes automatiques, verrouillage de la r\u00e9servation de voie, plan de contingence<\/p>\n<\/td>\n<\/tr>\n
\n
D\u00e9faillance logicielle : plantage ou bug critique<\/p>\n<\/td>\n
\n
2<\/p>\n<\/td>\n
\n
5<\/p>\n<\/td>\n
\n
10<\/p>\n<\/td>\n
\n
Haute<\/p>\n<\/td>\n
\n
Redondance serveurs, sauvegardes automatiques, tests r\u00e9guliers<\/p>\n<\/td>\n<\/tr>\n
\n
D\u00e9faillance communication : perte liaison postes-trains<\/p>\n<\/td>\n
\n
3<\/p>\n<\/td>\n
\n
4<\/p>\n<\/td>\n
\n
12<\/p>\n<\/td>\n
\n
Moyenne<\/p>\n<\/td>\n
\n
Syst\u00e8me de communication de secours, proc\u00e9dures manuelles, surveillance en temps r\u00e9el<\/p>\n<\/td>\n<\/tr>\n
\n
Intrusion \/ attaque cyber<\/p>\n<\/td>\n
\n
1<\/p>\n<\/td>\n
\n
5<\/p>\n<\/td>\n
\n
5<\/p>\n<\/td>\n
\n
Moyenne<\/p>\n<\/td>\n
\n
Authentification forte, surveillance r\u00e9seau, mises \u00e0 jour r\u00e9guli\u00e8res<\/p>\n<\/td>\n<\/tr>\n
\n
Conditions externes : obstruction voie, intemp\u00e9ries<\/p>\n<\/td>\n
\n
3<\/p>\n<\/td>\n
\n
4<\/p>\n<\/td>\n
\n
12<\/p>\n<\/td>\n
\n
Moyenne<\/p>\n<\/td>\n
\n
D\u00e9tection obstacles, plans alternatifs, alertes m\u00e9t\u00e9o int\u00e9gr\u00e9es<\/p>\n<\/td>\n<\/tr>\n
\n
Perte de donn\u00e9es critiques<\/p>\n<\/td>\n
\n
1<\/p>\n<\/td>\n
\n
5<\/p>\n<\/td>\n
\n
5<\/p>\n<\/td>\n
\n
Moyenne<\/p>\n<\/td>\n
\n
Sauvegardes fr\u00e9quentes, r\u00e9plication sur plusieurs sites, plan de r\u00e9cup\u00e9ration<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n
Cycle de s\u00fbret\u00e9\/SSIL<\/strong><\/li>\n<\/ul>\n
Hazard Analysis<\/strong><\/p>\n
\u2013 Identifier les dangers et risques<\/p>\n
\u2013 Classer selon criticit\u00e9<\/p>\n
\u2013 R\u00e9sultat : liste des hazards et exigences de s\u00e9curit\u00e9 initiales<\/p>\n
Safety & Security Requirements<\/strong><\/p>\n
\u2013 D\u00e9finir exigences fonctionnelles et non-fonctionnelles<\/p>\n
\u2013 Tra\u00e7abilit\u00e9 vers les hazards identifi\u00e9s<\/p>\n
\u2013 Base pour le design et les tests<\/p>\n
System \/ Software Analysis \u2018Design\u2019<\/strong><\/p>\n
\u2013 Analyse de conception globale et architecture<\/p>\n
\u2013 V\u00e9rification que l\u2019architecture peut satisfaire les exigences de s\u00fbret\u00e9<\/p>\n
\u2013 Pr\u00e9parer les bases pour le design d\u00e9taill\u00e9<\/p>\n
Software Detailed Design \u2018Design\u2019<\/strong><\/p>\n
\u2013 D\u00e9finition des modules, interfaces, m\u00e9canismes de s\u00e9curit\u00e9<\/p>\n
\u2013 Design d\u00e9taill\u00e9 de chaque composant logiciel<\/p>\n
\u2013 Sp\u00e9cification des tests unitaires et d\u2019int\u00e9gration correspondants<\/p>\n
Implementation (Coding) \u2018Design\u2019<\/strong><\/p>\n
\u2013 Codage effectif des modules selon le design<\/p>\n
\u2013 Mise en place des m\u00e9canismes de s\u00e9curit\u00e9<\/p>\n
\u2013 Conformit\u00e9 avec les exigences et normes applicables<\/p>\n
Unit Testing \u2018Design\u2019<\/strong><\/p>\n
\u2013 Tester chaque module individuellement<\/p>\n
\u2013 V\u00e9rification du comportement attendu<\/p>\n
\u2013 Documentation des r\u00e9sultats et anomalies<\/p>\n
Integration Testing \u2018Design\u2019<\/strong><\/p>\n
\u2013 Tester les interactions entre modules<\/p>\n
\u2013 V\u00e9rification des interfaces et communication<\/p>\n
\u2013 Validation partielle des exigences fonctionnelles<\/p>\n
System Verification<\/strong><\/p>\n
\u2013 V\u00e9rification compl\u00e8te du syst\u00e8me par rapport aux exigences<\/p>\n
\u2013 Test de conformit\u00e9 et de s\u00fbret\u00e9 fonctionnelle<\/p>\n
\u2013 R\u00e9sultats document\u00e9s pour audits<\/p>\n
System Validation<\/strong><\/p>\n
\u2013 Validation sur environnement r\u00e9el ou simul\u00e9<\/p>\n
\u2013 V\u00e9rification que le syst\u00e8me r\u00e9pond aux besoins op\u00e9rationnels et exigences de s\u00fbret\u00e9<\/p>\n
\u2013 Confirmation finale avant mise en production<\/p>\n
Operation \/ Maintenance<\/strong><\/p>\n
\u2013 D\u00e9ploiement et exploitation du logiciel<\/p>\n
\u2013 Suivi des incidents, corrections et mises \u00e0 jour<\/p>\n
\u2013 Boucle de retour d\u2019exp\u00e9rience pour am\u00e9liorer le cycle<\/p>\n
Modularit\u00e9 & interfaces ouvertes<\/strong> : d\u00e9couper en composants rempla\u00e7ables (interlocking, traffic management, RBC\/ETCS, HMI, comms).<\/p>\n
$\"\"$ <\/a><\/p>\n
\n
Interlocking : module critique pour la s\u00e9curit\u00e9, contr\u00f4le les itin\u00e9raires et assure qu\u2019il n\u2019y a pas de conflit de circulation.<\/li>\n
Traffic Management : planifie et supervise le trafic, re\u00e7oit et envoie des donn\u00e9es aux autres modules.<\/li>\n
RBC \/ ETCS : communique avec les trains et coordonne la vitesse et l\u2019espacement, en interaction avec Interlocking et Traffic Management.<\/li>\n
Comms : module d\u00e9di\u00e9 aux communications entre modules et avec les \u00e9quipements externes.<\/li>\n
HMI : interface pour l\u2019op\u00e9rateur, connect\u00e9e aux modules critiques via des interfaces ouvertes.<\/li>\n<\/ul>\n
Explication des flux <\/strong><\/p>\n
Traffic Management \u2192 RBC\/ETCS<\/strong><\/p>\n
\n
Envoie plan de circulation, priorit\u00e9s, contraintes de trafic.<\/li>\n
Re\u00e7oit l\u2019\u00e9tat global du trafic et alertes de s\u00e9curit\u00e9.<\/li>\n<\/ul>\n
RBC\/ETCS \u2194 Interlocking<\/strong><\/p>\n
\n
RBC\/ETCS re\u00e7oit l\u2019\u00e9tat des itin\u00e9raires du blocage.<\/li>\n
Interlocking re\u00e7oit les ordres de verrouillage\/d\u00e9verrouillage.<\/li>\n<\/ul>\n
HMI \u2194 Tous les modules<\/strong><\/p>\n
\n
L\u2019op\u00e9rateur visualise l\u2019\u00e9tat du syst\u00e8me et peut envoyer des commandes.<\/li>\n
HMI re\u00e7oit des notifications critiques, alertes, ou \u00e9tats de s\u00e9curit\u00e9.<\/li>\n<\/ul>\n
Comms \u2194 Tous les modules<\/strong><\/p>\n
\n
Transporte les donn\u00e9es entre modules et vers l\u2019ext\u00e9rieur (trains, centre de contr\u00f4le).<\/li>\n<\/ul>\n
Interfaces ouvertes<\/strong><\/p>\n
\n
Tous les flux utilisent des interfaces standardis\u00e9es pour assurer interop\u00e9rabilit\u00e9 et modularit\u00e9<\/strong>.<\/li>\n<\/ul>\n
\n
Ind\u00e9pendance technologique<\/strong> : abstraction mat\u00e9riel\/OS, virtualisation et \u00ab hardware independence \u00bb pour remplacer facilement des sous-syst\u00e8mes.<\/li>\n
Conception pour la maintenance et l\u2019\u00e9volution<\/strong> : API stables, versioning, migration clear paths, et tests automatis\u00e9s.<\/li>\n
Facteur humain int\u00e9gr\u00e9<\/strong> : conception HMI centr\u00e9e op\u00e9rateur, proc\u00e9dures, formation continue et ergonomie d\u2019alarmes.<\/li>\n<\/ol>\n
Normes et conformit\u00e9 (points de r\u00e9f\u00e9rence)<\/strong><\/p>\n
\n
S\u2019appuyer sur IEC 61508<\/strong> (cadre g\u00e9n\u00e9rique de s\u00e9curit\u00e9 fonctionnelle) pour la gouvernance du cycle de vie. Intertek<\/a><\/li>\n
Utiliser EN 50128<\/strong> pour le d\u00e9veloppement logiciel ferroviaire (SIL, techniques recommand\u00e9es). verifysoft.com+1<\/a><\/li>\n
Utiliser EN 50129<\/strong> pour la qualification des syst\u00e8mes \u00e9lectroniques de signalisation. BSI Knowledge+1<\/a><\/li>\n
Pour interop\u00e9rabilit\u00e9 et contr\u00f4le de trafic europ\u00e9en, se r\u00e9f\u00e9rer \u00e0 ERTMS\/ETCS<\/strong> (sp\u00e9cifications op\u00e9rationnelles, exigences Train Data). European Union Agency for Railways+1<\/a><\/li>\n<\/ul>\n
Architecture recommand\u00e9e (niveau syst\u00e8me)<\/h1>\n
\n
Architecture en couches + s\u00e9parations fortes<\/strong>\n
\n
Couche mat\u00e9rielle (I\/O, PLC certifi\u00e9s)<\/li>\n
Couche temps r\u00e9el \/ safety-critical (interlockings, RBC) avec redondance physique\/logique.<\/li>\n
Couche services non-safety (planification, optimisation, UI avanc\u00e9e) \ud83e\udc6a peut \u00e9voluer plus vite<\/li>\n
Couche d\u2019int\u00e9gration \/ bus avec interfaces formelles<\/strong> (messages versionn\u00e9s, protobuf\/ASN.1\/standard ferroviaire)<\/li>\n<\/ul>\n<\/li>\n
Principes de r\u00e9silience<\/strong>\n
\n
Redondance active\/active ou active\/standby selon la fonction et le SIL<\/li>\n
D\u00e9tection et basculement automatiques, et comportements \u2018fail-safe\u2019 clairement d\u00e9finis<\/li>\n<\/ul>\n<\/li>\n
Isolation des responsabilit\u00e9s<\/strong> (s\u00e9parer fonctions critiques et non-critiques pour limiter surface de d\u00e9faillance)<\/li>\n<\/ol>\nLangages, outils, techniques d\u2019ing\u00e9nierie<\/h1>\n
\n
Langages<\/strong> : pour fonctions safety-critical privil\u00e9gier des langages\/modes faciles \u00e0 analyser (ex. Ada\/SPARK, MISRA C\/C++ avec conformit\u00e9) et justifier par la norme.<\/li>\n
Outils certifi\u00e9s<\/strong> : utiliser outils qualifiables\/certifi\u00e9s pour compilation, traceabilit\u00e9, analyse statique (EN 50128 recommande l\u2019analyse statique pour SIL\u22651). CodeSecure<\/a><\/li>\n
M\u00e9thodes formelles<\/strong> : pour les parties critiques (interlock, calcul de s\u00e9curit\u00e9), appliquer sp\u00e9cification formelle + preuve (model checking, proofs) quand possible.<\/li>\n
CI\/CD contr\u00f4l\u00e9<\/strong> : pipeline d\u2019int\u00e9gration automatis\u00e9 mais r\u00e9glement\u00e9 (gates manuelles pour releases certifi\u00e9es).<\/li>\n<\/ul>\n
Gestion de l\u2019obsolescence (30+ ans)<\/h1>\n
\n
Abstraction mat\u00e9rielle et couches d\u2019adaptateurs<\/strong> \ud83e\udc6a pouvoir remplacer les CPU, cartes I\/O sans toucher \u00e0 la logique m\u00e9tier.<\/li>\n
Virtualisation et conteneurisation<\/strong> \ud83e\udc6a empaqueter les fonctions dans des VMs ou des conteneurs certifiables pour portage ult\u00e9rieur.<\/li>\n
Catalogue de versions & strat\u00e9gie de migration<\/strong> \ud83e\udc6a politique LTS (Long-Term Support), compatibilit\u00e9 ascendante des messages et scripts de migration.<\/li>\n
Stock de pi\u00e8ces & strat\u00e9gie fournisseurs<\/strong> \ud83e\udc6a obligations contractuelles sur disponibilit\u00e9 des pi\u00e8ces, droit \u00e0 la maintenance, code escrow.<\/li>\n
Open interfaces & standards<\/strong> \ud83e\udc6a \u00e9viter solutions propri\u00e9taires exclusives ; garantir rempla\u00e7abilit\u00e9 des fournisseurs.<\/li>\n
Digital twin \/ simulation<\/strong> \ud83e\udc6a maintenir un jumeau num\u00e9rique pour tester upgrades et migrations avant d\u00e9ploiement.<\/li>\n<\/ol>\n
Facteur humain & op\u00e9rations<\/h1>\n
\n
HMI \/ op\u00e9rateur<\/strong> : conception centr\u00e9e utilisateur, normalisation des alarmes (priorit\u00e9, clart\u00e9), training simulators int\u00e9gr\u00e9s.<\/li>\n
Automation vs. op\u00e9rateur<\/strong> : garder op\u00e9rateur \u00abdans la boucle\u00bb pour d\u00e9cisions critiques, mais r\u00e9duire charge cognitive par automation assist\u00e9e.<\/li>\n
Proc\u00e9dures & formation<\/strong> : maintenances, updates, sc\u00e9narios d\u2019incident, exercices r\u00e9guliers.<\/li>\n
Organisation<\/strong> : \u00e9quipes d\u2019exploitation et maintenance form\u00e9es au long terme ; documentation vivante et accessible.<\/li>\n<\/ul>\n
Tests, v\u00e9rification et validation<\/h1>\n
\n
V&V complet<\/strong> : tests unitaires, tests d\u2019int\u00e9gration, tests syst\u00e8me, tests d\u2019acceptation, tests en charge et tests de r\u00e9gression.<\/li>\n
Simulation & fuzzing<\/strong> : simuler trafic, panne capteur, anomalies comms.<\/li>\n
Tests s\u00e9curit\u00e9\/cyber<\/strong> : audits r\u00e9guliers, pentests, tests de r\u00e9silience aux attaques.<\/li>\n
Certification<\/strong> : dossier de s\u00fbret\u00e9 conforme EN 50128\/50129 + preuves\/artefacts contr\u00f4lables.<\/li>\n<\/ul>\n
Cybers\u00e9curit\u00e9<\/h1>\n
\n
S\u00e9paration r\u00e9seau (safety vs. management), chiffrement des liaisons critiques, authentification forte, gestion des cl\u00e9s, mise \u00e0 jour s\u00e9curis\u00e9e.<\/li>\n
Plan de r\u00e9ponse incident et s\u00e9curit\u00e9 \u00abby design\u00bb. (la s\u00e9curit\u00e9 et la gestion des incidents sont pens\u00e9es d\u00e8s l\u2019architecture du syst\u00e8me<\/strong>, pas trait\u00e9es comme un correctif ou une option plus tard.)<\/li>\n<\/ul>\n
Donn\u00e9es, monitoring et exploitation<\/h1>\n
\n
Observabilit\u00e9<\/strong> : t\u00e9l\u00e9m\u00e9trie fine (sant\u00e9 HW, latence, erreurs), logging structur\u00e9, alerting SLO\/SLA.<\/li>\n
Maintenance pr\u00e9dictive<\/strong> : analytics pour anticiper pannes et planifier remplacements.<\/li>\n
Archivage & tra\u00e7abilit\u00e9<\/strong> : logs immuables pour incidents & forensic (analyse technique post-incident visant \u00e0 comprendre exactement ce qui s\u2019est pass\u00e9<\/strong>, de mani\u00e8re factuelle, tra\u00e7able et exploitable juridiquement ou r\u00e9glementairement<\/strong>.)<\/strong>.<\/li>\n<\/ul>\n
Gouvernance produit & contrat fournisseur<\/h1>\n
\n
Requirements bas\u00e9s risque<\/strong> (safety cases), ownership clair des interfaces.<\/li>\n
Clauses long-term support<\/strong> (SLA, pi\u00e8ces, code escrow \u2013 e.g code d\u00e9pos\u00e9 chez un tiers ind\u00e9pendants), audits r\u00e9guliers fournisseur.<\/li>\n
Politique de format de donn\u00e9es et API stables<\/strong>.<\/li>\n<\/ul>\n
Roadmap pratique (phases)<\/h1>\n
\n
Concept & hazard analysis<\/strong> (FMECA\/Hazard Log) \u2192 d\u00e9finir SILs. Intertek+1<\/a><\/li>\n
Architecture & sp\u00e9cifications formelles<\/strong> (interfaces, modes d\u00e9grad\u00e9s)<\/li>\n
Prototype modulaire + tests formels des blocs critiques<\/strong><\/li>\n
Qualification outils & process<\/strong> (outils analysers, config management) \ud83e\udc6a conforme EN 50128\/29. verifysoft.com+1<\/a><\/li>\n
Industrialisation, d\u00e9ploiement en shadow-mode (tests sur r\u00e9seau simul\u00e9, ex\u00e9cution du nouveau syst\u00e8me ou de la nouvelle version en parall\u00e8le du syst\u00e8me officiel, sans qu\u2019il n\u2019influence la production r\u00e9elle.)<\/strong><\/li>\n
Op\u00e9ration, monitoring, \u00e9volution & plan de migration continu<\/strong><\/li>\n<\/ol>\nExemples de pratiques concr\u00e8tes (checklist rapide)<\/h1>\n
\n
Tracer chaque requirement jusqu\u2019au code + tests (DOORS \/ JIRA + lien).<\/li>\n
Utiliser analyse statique + couverture MC\/DC pour modules critiques. CodeSecure<\/a><\/li>\n
Redondance g\u00e9ographique pour centres de contr\u00f4le principaux\/secours.<\/li>\n
Contr\u00f4le de versions strict, tags releases certifi\u00e9es, audits externes p\u00e9riodiques.<\/li>\n
Jumeau num\u00e9rique pour valider MAJ avant d\u00e9ploiement live.<\/li>\n
Contrats fournisseur incluant right-to-fix<\/strong> et code-escrow.<\/li>\n<\/ul>\n
Risques principaux & mitigations<\/h1>\n
\n
Obsolescence HW<\/strong> \u2192 mitig\u00e9 par abstraction et contrat fournisseurs.<\/li>\n
D\u00e9gradation des comp\u00e9tences<\/strong> \u2192 mitigation : formation continue, documentation, pair-programming, apprenticeship.<\/li>\n
Dette technique<\/strong> \u2192 mitigation : temps d\u00e9di\u00e9 au refactoring, tests, CI.<\/li>\n
Attaques cyber<\/strong> \u2192 mitigation : d\u00e9fense en profondeur, patching contr\u00f4l\u00e9.<\/li>\n
\u00c9volutions r\u00e9glementaires<\/strong> \u2192 mitigation : veille, conformit\u00e9 et modularit\u00e9 pour petites mises \u00e0 jour.<\/li>\n<\/ul>\nR\u00e9f\u00e9rences cl\u00e9s (pour approfondir)<\/h1>\n
\n
IEC 61508 \u2014 cadre de s\u00e9curit\u00e9 fonctionnelle. Intertek<\/a><\/li>\n
EN 50128 \u2014 logiciel pour syst\u00e8mes de contr\u00f4le et protection ferroviaire (SIL, techniques). verifysoft.com+1<\/a><\/li>\n
EN 50129 \u2014 syst\u00e8mes \u00e9lectroniques de signalisation s\u00e9curit\u00e9. BSI Knowledge+1<\/a><\/li>\n
Sp\u00e9cifications ERTMS \/ ETCS (Train Data & op\u00e9rations). European Union Agency for Railways+1<\/a><\/li>\n
R\u00f4le de l\u2019analyse statique & outils qualifiables pour EN 50128. CodeSecure<\/a><\/li>\n<\/ul>\n
Int\u00e9grer de nouveaux langages ou autres nouvelles techno ? (Intelligence artificielle, Rust, go, \u2026 ) Quid de l\u2019obsolescence ? Quid du long terme ?<\/h1>\n
Le choix initial d\u2019insister sur Ada\/SPARK, C\/MISRA, etc., vient du contexte ferroviaire safety-critical<\/strong> : on parle de syst\u00e8mes certifi\u00e9s SIL 4 (les plus exigeants), o\u00f9 robustesse, auditabilit\u00e9 et tra\u00e7abilit\u00e9<\/strong> passent avant la nouveaut\u00e9 technologique. Mais \u00e7a ne veut pas dire qu\u2019on doit ignorer les nouveaux langages\/techniques.<\/p>\n
Pourquoi les nouveaux langages ne sont pas encore massivement utilis\u00e9s en ferroviaire<\/h2>\n
\n
Certification et maturit\u00e9<\/strong>\n
\n
Les normes (EN 50128\/50129) imposent de qualifier outils, compilateurs, libs \u2192 processus long (souvent plusieurs ann\u00e9es).<\/li>\n
Ada\/SPARK, C\/MISRA ont 30+ ans d\u2019historique dans l\u2019a\u00e9ronautique et le ferroviaire, donc d\u00e9j\u00e0 \u00ab prouv\u00e9s \u00bb et document\u00e9s.<\/li>\n
Rust, Go, Python, etc. n\u2019ont pas encore ce pedigree safety (pas de compilateur qualifi\u00e9, pas de guidelines certifi\u00e9es SIL).<\/li>\n<\/ul>\n<\/li>\n
\u00c9cosyst\u00e8me<\/strong>\n
\n
Rust, Go \u00e9voluent vite \u2192 risque de rupture de compatibilit\u00e9, difficile \u00e0 figer pour un syst\u00e8me cens\u00e9 durer 30 ans.<\/li>\n
Ada\/SPARK est stable et sp\u00e9cifiquement con\u00e7u pour v\u00e9rification formelle, contrats, absence de comportements ind\u00e9finis.<\/li>\n<\/ul>\n<\/li>\n
Outils et formation<\/strong>\n
\n
Les \u00e9quipes ferroviaires sont form\u00e9es sur des langages \u00ab classiques \u00bb ; il faut aussi tenir compte du facteur humain (comp\u00e9tences disponibles pour maintenance dans 20 ans).<\/li>\n
Les nouvelles technos manquent parfois de main-d\u2019\u0153uvre certifi\u00e9e ou de formations standardis\u00e9es.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n
O\u00f9 int\u00e9grer Rust, Go, IA, etc. de mani\u00e8re r\u00e9aliste<\/h2>\n
\n
Rust<\/strong>\n
\n
Excellent candidat \u00e0 moyen terme<\/strong> pour du safety-critical (ownership model, \u00e9limination des UB, gestion m\u00e9moire s\u00fbre).<\/li>\n
Peut \u00eatre introduit dans les couches non-safety (diagnostic, outils, cybers\u00e9curit\u00e9)<\/strong> au d\u00e9but.<\/li>\n
S\u2019il se stabilise et gagne en certification (comme MISRA pour C\/C++), il deviendra un choix pertinent pour du code safety.<\/li>\n<\/ul>\n<\/li>\n
Go<\/strong>\n
\n
Pas con\u00e7u pour temps r\u00e9el strict, mais tr\u00e8s bien pour couches non-critiques<\/strong> : supervision, orchestration, monitoring distribu\u00e9.<\/li>\n
Son runtime garbage collector est r\u00e9dhibitoire pour SIL, mais pas pour outils IT ferroviaires.<\/li>\n<\/ul>\n<\/li>\n
IA \/ ML<\/strong>\n
\n
Pas pour le contr\u00f4le safety<\/strong> (black box, pas de preuve formelle possible aujourd\u2019hui).<\/li>\n
Mais tr\u00e8s utile en maintenance pr\u00e9dictive, optimisation de trafic, analyse de logs\/anomalies<\/strong>.<\/li>\n
Plac\u00e9e dans les couches non-safety avec interfaces claires \u2192 on garde le c\u0153ur certifi\u00e9 immuable, mais on \u00e9volue c\u00f4t\u00e9 performance & maintenance.<\/li>\n<\/ul>\n<\/li>\n
Python, Julia, R<\/strong>\n
\n
Id\u00e9aux pour R&D, simulation, prototypage, analyse de donn\u00e9es \u2192 mais jamais dans le chemin critique safety.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
Vue long terme (>30 ans)<\/h2>\n
\n
Principe cl\u00e9<\/strong> :\n
\n
S\u00e9parer fonctions safety<\/strong> (langages stables, preuves formelles, cycles de vie fig\u00e9s)<\/li>\n
et fonctions non-safety<\/strong> (langages modernes, agiles, \u00e9volutifs).<\/li>\n<\/ul>\n<\/li>\n
\u00c9volutivit\u00e9<\/strong> :\n
\n
Le socle safety est volontairement conservateur (Ada\/SPARK, C\/MISRA, peut-\u00eatre Rust un jour).<\/li>\n
Les couches non-safety profitent de l\u2019innovation (Go, Rust, IA).<\/li>\n
Interfaces stables (API\/message bus) \u2192 permettent de remplacer\/moderniser les couches non-safety sans recertifier le noyau.<\/li>\n<\/ul>\n<\/li>\n
Obsolescence<\/strong> :\n
\n
Langages modernes = risque d\u2019\u00e9volution rapide \u2192 il faut pr\u00e9voir un processus de gel de versions (long-term support)<\/strong> pour ne pas \u00eatre d\u00e9pendant d\u2019une lib ou runtime abandonn\u00e9.<\/li>\n
En parall\u00e8le, pr\u00e9voir un plan de migration<\/strong> document\u00e9 (tests automatis\u00e9s, conteneurisation, virtualisation).<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n
La raison pour laquelle Rust\/Go\/IA n\u2019ont pas \u00e9t\u00e9 abord\u00e9 dans un premier temps :<\/p>\n
\n
En safety-critical certifi\u00e9<\/strong>, ils ne sont pas encore utilisables comme base de confiance.<\/li>\n
mais ils ont clairement une place<\/strong> dans l\u2019architecture globale, surtout dans les couches non-safety (diagnostic, optimisation, maintenance, IA pr\u00e9dictive).<\/li>\n
Rust, en particulier, a un potentiel r\u00e9el de devenir un futur standard safety (comme Ada dans les ann\u00e9es 90).<\/li>\n<\/ul>\n
Sch\u00e9ma d\u2019architecture sur 30 ans<\/strong> montrant :<\/p>\n
\n
quelles couches restent fig\u00e9es en Ada\/SPARK ou C\/MISRA,<\/li>\n
et o\u00f9 Rust\/Go\/IA peuvent entrer progressivement sans compromettre la certification\u00a0<\/li>\n<\/ul>\n
Explication synth\u00e9tique (ce que montre le sch\u00e9ma)<\/strong><\/p>\n
$\"\"$ <\/a><\/p>\n
\n
S\u00e9paration claire Safety vs Non-Safety<\/strong> \u2014 le c\u0153ur safety (interlocking, RBC) reste fig\u00e9, certifiable (Ada\/SPARK, MISRA C aujourd\u2019hui), avec maintenance strictement contr\u00f4l\u00e9e.<\/li>\n
Interfaces stables et versionn\u00e9es<\/strong> \u2014 bus de messages sign\u00e9s (ASN.1 \/ Protobuf + signature), points d\u2019adaptateurs qui isolent le c\u0153ur des innovations.<\/li>\n
Adoption progressive<\/strong> :\n
\n
Ann\u00e9es 0\u20135<\/strong> : containers, virtualisation, Go pour orchestration, IA\/ML pour analytics (non-safety), commencer R&D Rust dans non-safety.<\/li>\n
Ann\u00e9es 5\u201315<\/strong> : Rust consolid\u00e9 en non-safety\/temps-r\u00e9el dur, migration de services non-critiques vers Rust quand stable. Continuer virtualisation et hardening des runtimes.<\/li>\n
Ann\u00e9es 15\u201330<\/strong> : \u00e9valuer qualification de Rust pour modules safety (apr\u00e8s qualification d\u2019outils & preuves formelles). Maintien du core gel\u00e9 + remplacements mat\u00e9riel via abstraction.<\/li>\n<\/ul>\n<\/li>\n
Mesures transverses<\/strong> : jumeau num\u00e9rique (digital twin) pour tests, CI\/CD contr\u00f4l\u00e9, catalogues de versions LTS, code escrow, contrats fournisseurs, monitoring avanc\u00e9 et maintenance pr\u00e9dictive.<\/li>\n<\/ol>\n
Carte rapide d\u2019affectation des technos (exemples)<\/strong><\/p>\n
\n
Safety-critical (SIL3\/4)<\/strong> : Ada\/SPARK, C (MISRA), outils formels, compilateurs qualifi\u00e9s.<\/li>\n
Hard real-time non-safety<\/strong> : C++, Rust (apr\u00e8s qualification exp\u00e9rimentale).<\/li>\n
Services distribu\u00e9s \/ orchestration<\/strong> : Go, Rust, Kubernetes (pour non-safety).<\/li>\n
Analytics \/ IA \/ Prototypage<\/strong> : Python, frameworks ML (isol\u00e9s hors du chemin safety).<\/li>\n
Interfaces & messages<\/strong> : ASN.1 \/ Protobuf, versioning s\u00e9mantique, signatures.<\/li>\n<\/ul>\n
Plan de migration concret (5 \u00e9tapes imm\u00e9diates)<\/strong><\/p>\n
\n
Geler et documenter le core<\/strong> : safety case, API publiques, hazard log.<\/li>\n
Standardiser les interfaces<\/strong> : choisir format (ASN.1\/protobuf), signer messages, versioning.<\/li>\n
Conteneuriser les services non-safety<\/strong> : orchestre avec Kubernetes priv\u00e9, d\u00e9ployer IA en sandbox.<\/li>\n
R&D Rust<\/strong> : cr\u00e9er modules prototypes en Rust pour monitoring\/gateway; valider performance, outils d\u2019analyse statique et preuves.<\/li>\n
Qualification progressive<\/strong> : lancer qualification d\u2019outils Rust, d\u00e9finir r\u00e8gles de codage et tests (MC\/DC, formal proofs) si avanc\u00e9e.<\/span><\/li>\n<\/ol>\n
Conclusion \/ Conclusion<\/h1>\n
Cet article illustre comment aborder le d\u00e9veloppement logiciel pour des syst\u00e8mes ferroviaires safety-critical en combinant analyse personnelle, \u00e9tude de cas et r\u00e9f\u00e9rences normatives, en soulignant l\u2019importance d\u2019une s\u00e9paration claire entre fonctions safety et non-safety<\/strong> : un c\u0153ur certifiable fig\u00e9 (Ada\/SPARK, C\/MISRA) et des couches non-critiques ouvertes \u00e0 l\u2019innovation (Rust, Go, IA\/ML). Le cycle de vie int\u00e9grant HARA, exigences safety, design modulaire, tests et validation, ainsi que des mesures transverses comme le jumeau num\u00e9rique, CI\/CD contr\u00f4l\u00e9 et gestion de l\u2019obsolescence, assure robustesse et p\u00e9rennit\u00e9 sur 30 ans. Cette r\u00e9flexion montre que l\u2019introduction progressive de nouvelles technologies est possible sans compromettre la certification<\/strong>, \u00e0 condition de respecter les interfaces stables, la tra\u00e7abilit\u00e9 et la gouvernance formelle.<\/p>\n
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<\/strong>: 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<\/strong>, provided stable interfaces, traceability, and formal governance are maintained.<\/em><\/p><\/body>","protected":false},"excerpt":{"rendered":"
This article, written in the form of an essay and case study, explores a set of practical recommendations (architecture, lifecycle,<\/p>\n","protected":false},"author":1,"featured_media":1488,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[7,115,76,116],"tags":[],"class_list":["post-1481","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-coding","category-delivery-process","category-security","category-software-engineering"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/imalogic.com\/blog\/wp-content\/uploads\/2026\/02\/ChatGPT-Image-17-fevr.-2026-11_14_51-e1771323374664.png?fit=800%2C533&ssl=1","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p8J21V-nT","jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/posts\/1481","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/comments?post=1481"}],"version-history":[{"count":4,"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/posts\/1481\/revisions"}],"predecessor-version":[{"id":1489,"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/posts\/1481\/revisions\/1489"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/media\/1488"}],"wp:attachment":[{"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/media?parent=1481"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/categories?post=1481"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/imalogic.com\/blog\/wp-json\/wp\/v2\/tags?post=1481"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}