EN 50128 et EN 50657 : logiciel ferroviaire

Auteur Hugues Orgitello Mis à jour le 3 juillet 2026 ~16 min de lecture

Guide · EN 50128 / EN 50657

EN 50128 et EN 50657 sont les deux normes CENELEC qui régissent l'assurance du logiciel dans le ferroviaire européen : la première pour le logiciel de signalisation et de protection, la seconde pour le logiciel embarque sur matériel roulant. Toutes deux sont des déclinaisons sectorielles du cadre générique IEC 61508 sur la sécurité fonctionnelle, et toutes deux sont référencées comme moyen reconnu de conformité par les Specifications Techniques d'Interoperabilite (STI) adoptées au titre du 4e Paquet Ferroviaire de l'Union européenne. Cette page expose la place des deux normes dans la famille CENELEC (EN 50126, EN 50128, EN 50129, EN 50657), le concept de Software Safety Integrity Level (SSIL 0 a 4), la séparation des rôles exigée, la classification des outils en T1/T2/T3, le traitement du logiciel préexistant, et l'articulation avec ERA et les sous-systèmes ERTMS et ETCS.

La famille CENELEC ferroviaire

Le cadre normatif CENELEC ferroviaire repose sur quatre normes principales qui se complètent : une norme de processus au niveau programme, une norme de système pour la signalisation, et deux normes de logiciel selon le domaine. L'ensemble est designe sous l'appellation "famille CENELEC" ou "groupe normes ferroviaires".

Reference	Perimetre	Sujet principal
EN 50126	Programme et système ferroviaire	Processus RAMS (Reliability, Availability, Maintainability, Safety) sur l'ensemble du cycle de vie ; cadre de gouvernance applicable a tout projet ferroviaire (infrastructure, matériel roulant, signalisation). Publie en plusieurs parties (50126-1 générique, 50126-2 spécifique sécurité).
EN 50129	Systeme de signalisation	Exigences pour les systèmes électroniques de sécurité relatifs a la signalisation. Définit l'attribution des SIL au niveau système, la structure du Safety Case, les exigences d'architecture (composition de barrières, diversité, redondance).
EN 50128	Logiciel signalisation	Exigences pour le logiciel des systèmes de commande et de protection ferroviaires. Cycle de vie logiciel, séparation des rôles, techniques recommandées par SSIL, classification des outils, gestion du logiciel préexistant.
EN 50657	Logiciel matériel roulant	Exigences pour le logiciel embarque sur matériel roulant qui n'est pas couvert par EN 50128 (controle-commande train, freinage, portes, énergie, climatisation, information voyageurs). Même socle méthodologique que EN 50128, périmètre distinct.

Les normes d'environnement (CEM ferroviaire EN 50121, équipements électroniques embarques EN 50155) complètent ce cadre sur les aspects matériel et qualification, mais ne traitent pas du logiciel. La frontière fonctionnelle entre EN 50128 et EN 50657 est posée par EN 50129 : un logiciel implique dans une fonction classée "signalisation" releve de EN 50128 ; un logiciel embarque sur matériel roulant qui n'est pas classe signalisation releve de EN 50657. La frontière n'est pas toujours nette en pratique (l'ETCS embarque pose la question), et son interprétation releve de l'autorité nationale de sécurité et de l'évaluateur indépendant.

Relation au cadre générique IEC 61508

EN 50128 et EN 50657 sont des déclinaisons sectorielles du cadre IEC 61508. IEC 61508 est la norme parapluie sur la sécurité fonctionnelle des systèmes électriques, électroniques et programmables relatifs a la sécurité, publiée par la CEI en sept parties (61508-1 a 61508-7). Elle définit le concept de SIL (Safety Integrity Level) sur quatre niveaux et fournit un cadre méthodologique générique.

La clause d'introduction de IEC 61508 prévoit explicitement que lorsqu'une norme sectorielle existe, c'est cette norme sectorielle qui prévaut sur le secteur concerne. Pour le ferroviaire, cette norme sectorielle est la famille CENELEC. Un projet ferroviaire applique donc directement EN 50126, EN 50128, EN 50129 et EN 50657, sans repasser par IEC 61508. Toutefois, plusieurs principes et terminologies de IEC 61508 transparaissent dans les normes CENELEC : échelle SIL, techniques recommandées par niveau, approche fondée sur le risque, séparation des rôles. La connaissance de IEC 61508 facilite la lecture des normes CENELEC, sans qu'elle soit exigée.

D'autres secteurs ont produit leurs propres déclinaisons de IEC 61508 : ISO 26262 pour l'automobile, IEC 61511 pour les industries de procedes, IEC 62061 pour la sécurité des machines, EN 50402 pour la détection de gaz, EN 50402 et EN 50271 pour les détecteurs en atmosphère explosible. Le ferroviaire et l'automobile sont parmi les deux secteurs qui ont le plus formalise leur cadre, avec des rôles indépendants explicites et une classification fine des outils. Pour le cadre générique, voir le guide IEC 61508.

Software Safety Integrity Level (SSIL)

EN 50128 et EN 50657 retiennent une échelle SSIL de 0 a 4 pour caractériser le niveau de criticité du logiciel. Le SSIL conditionne le niveau de rigueur exige sur le cycle de vie logiciel : techniques recommandées, profondeur de la verification, séparation des rôles, niveau d'indépendance de l'évaluation, exigences sur les outils.

SSIL	Criticite indicative	Profil applicable
SSIL 0	Aucune fonction de sécurité	Logiciel non lie a une fonction de sécurité. Aucune exigence particulière de la norme, mais conformité au processus qualité général (ISO 9001 typiquement).
SSIL 1	Securite faible	Logiciel dont la défaillance peut contribuer a une situation dangereuse avec un risque limite. Verification interne suffisante, séparation des rôles legere.
SSIL 2	Securite modérée	Verification renforcée, séparation Auteur / Verificateur stricte au sein de l'equipe, évaluation indépendante recommandee.
SSIL 3	Securite élevée	Separation organisationnelle plus marquée (Vérificateur et Validateur dans des entités distinctes de l'Auteur), techniques formelles recommandées sur les composants critiques, évaluation indépendante exigée.
SSIL 4	Securite critique	Niveau le plus exigeant. Indépendance maximale (Évaluateur d'une entité distincte de la conception), techniques formelles fortement recommandées, qualification poussée des outils T3, gestion du logiciel préexistant très restrictive.

Le SSIL n'est pas attribue au logiciel en isolation. Il decoule d'une analyse d'attribution au niveau système conduite selon EN 50129, qui prend en compte les barrières matérielles, l'architecture de redondance et de diversité, et l'environnement d'exploitation. Un logiciel dont la fonction est protégée par une barrière matérielle indépendante peut héréditairement être classe a un SSIL inférieur au SIL de la fonction système. C'est l'un des leviers d'architecture qui permet d'éviter d'avoir a tout développer en SSIL 4 alors que la fonction système est classée SIL 4.

La correspondance entre SSIL et SIL IEC 61508 est conceptuelle : un même numéro traduit un même niveau de criticité indicatif. Mais l'attribution rigoureuse passe par EN 50129 dans le ferroviaire, et non par les tables de PFD (Probability of Failure on Demand) ou de PFH (Probability of Failure per Hour) de IEC 61508-1.

Cycle de vie en V et phases couvertes

EN 50128 et EN 50657 imposent un cycle de vie logiciel en V, decoupe en phases qui doivent être tracées, vérifiées et evaluees. Les phases sont applicables a tout SSIL, l'intensité des techniques et la profondeur de la verification varient.

• Planification : Software Quality Assurance Plan, Software Verification Plan, Software Validation Plan, Software Configuration Management Plan, Software Maintenance Plan. Ces plans sont evalues avant le démarrage de la phase suivante.
• Specification des exigences logiciel (SRS) : dérivation des exigences depuis les exigences système (sortie de EN 50129), traitement des exigences fonctionnelles, non fonctionnelles, et de sécurité.
• Architecture logiciel : décomposition en modules, identification des fonctions critiques et non critiques, définition des interfaces, choix des techniques de tolérance aux fautes.
• Conception détaillée : conception des modules, choix des algorithmes, définition des structures de données, traitement de la cohérence et de la robustesse.
• Codage : écriture du code source selon des regles de codage définies (sous-ensembles de langage, interdits, restrictions d'usage des pointeurs, des allocations dynamiques, des récursions).
• Verification module et intégration : tests unitaires, tests d'intégration, couverture de code (instruction, branche, MC/DC selon SSIL), analyse statique.
• Validation logiciel : validation des exigences logiciel face au code execute, en environnement représentatif (simulateur, banc de test, plate-forme cible).
• Verification et validation système (V&V) : conformité du logiciel integre au système, déroulement des scenarios de test système.
• Deploiement et mise en service : transfert du logiciel sur le site, intégration, essais de marche, retour d'exploitation initial.
• Exploitation, maintenance, modification : gestion des anomalies, des demandes de changement, des correctifs, suivi du retour d'exploitation.
• Decommissioning : retrait progressif, transfert éventuel des bases de données historiques, archivage des dossiers.

Chaque phase produit des artefacts (plans, spécifications, code, rapports de test, rapports de verification) qui sont conserves dans le dossier de configuration. Le dossier complet est l'entrée de l'Evaluation indépendante (Independent Safety Assessor), dont le rapport est lui-même un livrable au dossier de Safety Case du système global selon EN 50129.

Separation des rôles : Auteur, Verificateur, Validateur, Evaluateur

EN 50128 et EN 50657 imposent une séparation organisationnelle des rôles pour éviter qu'une même personne ou une même equipe ne soit juge et partie sur ses propres livrables. Quatre rôles principaux sont définis.

Role	Fonction	Independance requise
Auteur (Designer / Implementer)	Production des artefacts logiciel : spécifications, architecture, conception, code, tests unitaires.	Aucune contrainte d'indépendance par rapport aux autres auteurs ; mais séparation stricte vis-a-vis du Verificateur et du Validateur.
Verificateur	Verification de la cohérence interne des artefacts d'une phase (revue, analyse statique, verification des exigences vs design, du design vs code).	SSIL 1-2 : personne distincte de l'Auteur, même equipe possible. SSIL 3-4 : equipe ou département distinct.
Validateur	Verification que le produit fini satisfait aux exigences spécifiées au début du projet. Validation par tests en environnement représentatif.	SSIL 1-2 : personne distincte de l'Auteur. SSIL 3-4 : indépendance organisationnelle plus marquée, fréquemment département distinct.
Evaluateur (Independent Safety Assessor, ISA)	Evaluation indépendante du processus et de la conformité a la norme. Rapport d'évaluation (Assessment Report) integre au Safety Case.	Independance maximale. Pour SSIL 3-4, l'Evaluateur est généralement une entité externe (société distincte), accredite et reconnu par l'autorité nationale de sécurité.

L'indépendance n'est pas symbolique. Elle est vérifiée par l'organigramme du projet, le rattachement hiérarchique des personnes, et l'absence de lien financier direct entre l'Auteur et l'Evaluateur sur le périmètre evalue. Un Evaluateur qui rapporte au même directeur de projet que l'Auteur n'est pas indépendant au sens de la norme. Pour les SSIL 3-4 sur des projets a forts enjeux (ETCS, enclenchements), l'autorité nationale de sécurité peut exiger explicitement un ISA externe, voire en designer un parmi une liste accreditee.

Classification des outils : T1, T2, T3

EN 50128 introduit une classification des outils de développement logiciel selon leur capacité a introduire un défaut dans le produit final ou a masquer un défaut existant. La classification conditionne le niveau de qualification ou de validation exige.

Classe	Definition	Exemples typiques	Demonstration requise
T1	Outil qui ne peut pas affecter directement ou indirectement le code exécutable ou les données du produit fini.	Editeur de texte, outil de gestion documentaire, outil de rédaction des plans, traceur de revue, gestionnaire de bibliographie.	Aucune justification spécifique. Verification de l'usage et de la maitrise par l'equipe.
T2	Outil qui supporte la verification du logiciel mais n'en produit pas le code exécutable. Une défaillance T2 peut masquer un défaut sans en introduire.	Analyseur statique, outil de couverture de test, générateur de jeu de tests, outil de revue, simulateur de plate-forme.	Demonstration de capacité (capability) : version pinnee, configuration documentée, retours d'exploitation, comparaison avec un outil alternatif, tests sur cas de reference.
T3	Outil dont la sortie est incorporée directement ou indirectement dans le code exécutable ou les données du produit fini.	Compilateur, linker, assembleur, générateur de code (MBSE, modeles UML), outil de chargement, outil de configuration de FPGA si la FPGA contient du code logiciel.	Demonstration de confiance forte : qualification de l'outil (cas SSIL 3-4), restriction de la zone d'utilisation (sous-ensemble de langage, options de compilation pinnees), historique d'exploitation documente, ou validation par double exécution avec un outil diversifie.

La classification se pose par outil et par projet, en fonction de l'usage effectif. Un même outil peut être T2 dans un projet (analyseur statique utilise comme aide a la revue) et basculer T3 dans un autre (s'il genere des annotations intégrées au binaire). La classification est documentée dans le Tool Qualification Report, livrable spécifique au dossier logiciel pour SSIL 3-4.

Pour les compilateurs C utilises en SSIL 3-4, la pratique courante consiste a pinner une version spécifique, a restreindre les options de compilation a un jeu valide, a appliquer un sous-ensemble de langage (typiquement MISRA C avec des exceptions documentées), et a fournir un retour d'exploitation cumule (nombre de projets, lignes de code, anomalies trouvées attribuées au compilateur). La qualification formelle d'un compilateur reste rare ; le retour d'exploitation est le mécanisme le plus utilise.

Logiciel préexistant (Pre-existing Software, PES)

Le logiciel préexistant designe tout composant logiciel qui n'a pas ete developpe spécifiquement pour le projet en cours et selon la norme. Cela inclut les composants sur étagère (COTS), les bibliothèques tierces (FAT/FAT32, TCP/IP, cryptographie), le code réutilisé d'un projet antérieur, les systèmes d'exploitation temps réel, et les pilotes de chipset. EN 50128 ne l'interdit pas, mais elle impose un traitement spécifique selon deux voies.

Voie 1, qualification du PES. Le composant préexistant est analyse comme s'il était spécifique : analyse statique, examen du code source si disponible, jeu de tests dedie, démonstration de couverture, évaluation des regles de codage appliquées lors de son développement initial. Pour les composants sans code source disponible (bibliothèques fermées, OS propriétaires), la qualification s'appuie sur un dossier de qualification fourni par l'éditeur (Proven In Use Argument) qui documente le retour d'exploitation cumule : nombre d'installations, heures de fonctionnement, anomalies remontées et traitées, évolutions du composant. La demarche Proven In Use est acceptable selon le SSIL, l'historique disponible et l'analyse du domaine d'usage.

Voie 2, confinement. Le composant préexistant est confine dans une zone non critique de l'architecture, en s'appuyant sur des barrières indépendantes (wrapper de sûreté, surveillance externe, redondance diversifiée). L'argument est que la défaillance du composant préexistant ne peut pas atteindre la fonction critique, ou que sa défaillance est détectée et neutralisée par un autre composant developpe selon la norme. Cette voie est frequente pour les systèmes d'exploitation temps réel : le RTOS est utilise pour la gestion des taches, mais la fonction critique est encapsulée dans un superviseur dont l'intégrité ne dépend pas du bon fonctionnement du RTOS.

Le choix entre qualification et confinement dépend du SSIL attribue, de l'architecture système validée par EN 50129, et de la disponibilité des éléments de qualification. Pour SSIL 4, la voie de qualification pure est rarement praticable sur des composants tiers, et le confinement architectural domine.

Gestion des modifications et du changement

Le logiciel ferroviaire a typiquement une durée de vie opérationnelle de plusieurs decennies. La gestion des modifications (correctifs, évolutions fonctionnelles, adaptations a un nouveau matériel, mises en conformité réglementaire) est encadrée explicitement par les deux normes.

Toute modification declenche une analyse d'impact qui evalue : les exigences impactées, les composants logiciel modifies, les composants impactes indirectement par leur interface, le risque d'introduction de régression sur la fonction de sécurité, et l'effort de re-verification necessaire. Selon l'ampleur de la modification, le cycle peut être soit une re-verification ciblée (modification mineure, périmètre limite), soit une re-validation complete (modification majeure, impact sur l'architecture), soit une nouvelle Evaluation indépendante (modification structurelle ou changement de SSIL).

La pratique courante consiste a tracer chaque modification dans un dossier de modification (Change Request) qui contient l'analyse d'impact, le périmètre de re-verification, les artefacts modifies, les rapports de test, et l'avis de l'Evaluateur. Le Safety Case système est mis a jour en conséquence, et l'autorité nationale de sécurité peut être notifiée selon l'ampleur (modification dite "substantielle" au sens du Common Safety Method on Risk Assessment, régulation UE 402/2013).

TSI, ERTMS et ETCS : le contexte réglementaire européen

Le 4e Paquet Ferroviaire, adopte en 2016, harmonise l'autorisation de mise en service du matériel roulant et la certification de sécurité ferroviaire au niveau européen. Avant le 4e Paquet, chaque état membre délivrait ses propres autorisations ; depuis, l'Agence de l'Union européenne pour les chemins de fer (ERA, European Union Agency for Railways) delivre une autorisation unique valable dans la zone d'usage declaree.

Les Specifications Techniques d'Interoperabilite (STI, ou TSI en anglais, Technical Specifications for Interoperability) imposent des exigences techniques harmonisées pour les sous-systèmes structurels du réseau ferroviaire :

• TSI CCS (Control-Command and Signalling) : signalisation au sol et embarquée, dont les sous-systèmes ETCS et GSM-R/FRMCS. Reference explicitement EN 50126, EN 50128, EN 50129.
• TSI LOC&PAS (Locomotives and Passenger Rolling Stock) : matériel roulant voyageurs et locomotives. Reference EN 50126, EN 50657 pour le logiciel embarque non signalisation.
• TSI WAG (Wagons) : wagons de fret.
• TSI INF (Infrastructure) : voie, ouvrages d'art, gabarits.
• TSI ENE (Energy) : sous-systèmes d'alimentation electrique.
• TSI PRM (Personnes a mobilité réduite) et TSI SRT (Safety in Rail Tunnels) : exigences transversales.

L'ERTMS (European Rail Traffic Management System) est le système cible d'unification du controle-commande ferroviaire en Europe. Il se compose de deux briques principales : l'ETCS (European Train Control System), système de signalisation en cabine et de protection automatique du train ; et le GSM-R (en cours de remplacement par le FRMCS, Future Railway Mobile Communication System), système de radiocommunication sol-train.

Les sous-systèmes ETCS embarques et au sol sont classes en signalisation et relèvent donc explicitement de EN 50128 selon la TSI CCS. Pour les autres logiciels embarques sur matériel roulant (controle-commande train, freinage, portes, énergie), la TSI LOC&PAS s'applique et EN 50657 est la norme de reference.

Articulation avec le marquage CE

Le matériel roulant et les sous-systèmes ferroviaires ne sont pas couverts par les directives CE classiques (machines, basse tension, CEM générique) au sens d'un produit grand public : la conformité des sous-systèmes structurels est démontrée par la Verification CE des sous-systèmes selon les TSI, conduite par un organisme notifie (NoBo, Notified Body) designe au titre de la directive interopérabilité (2008/57/CE, refondue par la directive 2016/797). Les sous-systèmes ferroviaires reçoivent ainsi une Declaration CE de Verification distincte des Declarations CE de Conformite des directives classiques.

Toutefois, certains équipements embarques peuvent relever d'autres directives en parallèle (CEM via la directive CEM générique pour les équipements connectes, RED pour les émetteurs radio embarques), avec leurs propres exigences. La page marquage CE detaille le cadre général du marquage et de la présomption de conformité.

Pour le vocabulaire normatif (SIL, SSIL, RAMS, Safety Case, ISA, PES, T1/T2/T3), voir le glossaire.

Voir aussi

• DO-178C et DO-254 : logiciel + matériel avionique
• DO-326A et ED-202A: cybersécurité avionique
• MIL-STD-461 et MIL-STD-464, normes CEM défense
• AEC-Q100, Q101, Q200 : composants automobiles

Un cas concret de le cadrage normatif d'un sous-ensemble electronique destine au monde ferroviaire ? AESTECHNO peut auditer votre conception et votre plan de certification. Nous contacter →

Pieges classiques observes sur le terrain

Plusieurs écueils reviennent sur les projets logiciels ferroviaires, qu'il est utile d'anticiper avant le démarrage.

• Confusion entre EN 50128 et EN 50657 sur le périmètre. Un logiciel embarque sur matériel roulant qui pilote indirectement une fonction de signalisation (par exemple, un controle-commande train qui dialogue avec l'embarquement ETCS) peut basculer sous EN 50128 selon l'interprétation système. La frontière est posée par EN 50129 au niveau système et doit être fixée très tot, idéalement avant la spécification logiciel.
• Attribution du SSIL avant l'attribution système. Le SSIL ne se choisit pas en isolation : il decoule de l'analyse d'attribution conduite selon EN 50129, en tenant compte de l'architecture de barrières. Un projet qui demarre le logiciel en SSIL 4 par défaut, sans analyse système, paye un coût de développement et d'évaluation très supérieur a ce qui est strictement requis.
• Sous-estimation de la qualification d'outils T3. La qualification d'un compilateur C en SSIL 4 demande un dossier d'historique d'exploitation que peu d'éditeurs fournissent en standard. Le choix d'un compilateur sans dossier prequalifie peut bloquer le projet en phase finale d'évaluation. Vérifier la disponibilité du dossier (souvent commercialise sous le nom Compiler Qualification Kit) avant de figer la chaine de compilation.
• PES sans dossier Proven In Use. Réutiliser un RTOS commercial ou une bibliothèque ouverte sans dossier de qualification préexistant impose un travail de qualification interne lourd, voire impossible si le code source n'est pas disponible. L'arbitrage entre Proven In Use (dépendant de l'éditeur) et confinement architectural (indépendant) doit être fait avant le choix du composant.
• Separation des rôles symbolique. L'indépendance Auteur / Verificateur / Validateur / Evaluateur exige un organigramme réel et un rattachement hiérarchique distinct. Un Evaluateur designe sur le papier mais rattache au même directeur de projet que l'equipe de développement n'est pas indépendant au sens de la norme. L'audit du dossier par l'autorité nationale releve cette non-conformité.
• Confusion entre EN 50128 et IEC 61508 pour le ferroviaire. Conformément a la clause d'introduction de IEC 61508, le secteur ferroviaire applique directement la famille CENELEC, et non IEC 61508. Un dossier qui invoque IEC 61508 sans EN 50128 ou EN 50657 sera renvoyé par l'évaluateur. La connaissance de IEC 61508 reste utile pour la lecture, mais elle ne se substitue pas.
• Modification mineure traitée comme un correctif sans analyse d'impact. Toute modification, même mineure, declenche une analyse d'impact formelle. Un correctif rapide sans mise a jour du dossier de configuration et sans avis de l'Evaluateur peut invalider le Safety Case et entraîner une suspension de l'autorisation de mise en service.

Pour aller plus loin

Cette page expose le cadre général de EN 50128 et EN 50657. Plusieurs sujets méritent un approfondissement separe :

• la structure détaillée du Safety Case selon EN 50129 et son articulation avec le dossier logiciel,
• la qualification des outils T3 et les pratiques industrielles autour des Compiler Qualification Kits,
• la demarche Proven In Use et son acceptabilité selon les SSIL,
• l'articulation entre EN 50128 et les exigences cybersécurité (TS 50701, IEC 62443) pour le ferroviaire connecte,
• la procédure d'autorisation de mise en service par l'ERA depuis le 4e Paquet et la répartition des rôles entre ERA et autorité nationale de sécurité.

Besoin d’un appui ?

Un audit de 30 minutes avec les ingénieurs AESTECHNO.

AESTECHNO est le bureau d'etudes electronique qui edite spilma. Nous accompagnons les equipes produit sur la conception et la certification de leurs equipements electroniques, y compris en interface avec des environnements normatifs sectoriels exigeants.

Réserver un audit gratuit

Sources & références

1. EN 50128:2011+A2:2020, Railway applications, Communication, signalling and processing systems, Software for railway control and protection systems , CENELEC www.cenelec.eu/dyn/www/f?p=104:110:::::FSP_PROJECT,FSP_LANG_ID:21621,25
2. EN 50657:2017, Railways Applications, Rolling stock applications, Software on Board Rolling Stock , CENELEC www.cenelec.eu/dyn/www/f?p=104:110:::::FSP_PROJECT,FSP_LANG_ID:60963,25
3. EN 50126 / EN 50129, Railway applications RAMS and electronic systems for signalling , CENELEC www.cenelec.eu/
4. European Union Agency for Railways (ERA), Technical Specifications for Interoperability (TSI) , ERA www.era.europa.eu/activities/technical-specifications-interoperability_en
5. 4th Railway Package, European Commission, Mobility and Transport , Commission européenne transport.ec.europa.eu/transport-modes/rail/railway-packages/fourth-railway-package_en
6. IEC 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems , IEC www.iec.ch/functional-safety