EN 50128 et EN 50657 : logiciel ferroviaire

Auteur Hugues Orgitello Mis à jour le 27 mai 2026 ~16 min de lecture

Guide · EN 50128 / EN 50657

EN 50128 et EN 50657 sont les deux normes CENELEC qui regissent l'assurance du logiciel dans le ferroviaire europeen : la premiere pour le logiciel de signalisation et de protection, la seconde pour le logiciel embarque sur materiel roulant. Toutes deux sont des declinaisons sectorielles du cadre generique IEC 61508 sur la securite fonctionnelle, et toutes deux sont referencees comme moyen reconnu de conformite par les Specifications Techniques d'Interoperabilite (STI) adoptees au titre du 4e Paquet Ferroviaire de l'Union europeenne. 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 separation des roles exigee, la classification des outils en T1/T2/T3, le traitement du logiciel preexistant, et l'articulation avec ERA et les sous-systemes ERTMS et ETCS.

La famille CENELEC ferroviaire

Le cadre normatif CENELEC ferroviaire repose sur quatre normes principales qui se completent : une norme de processus au niveau programme, une norme de systeme 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 systeme ferroviaire	Processus RAMS (Reliability, Availability, Maintainability, Safety) sur l'ensemble du cycle de vie ; cadre de gouvernance applicable a tout projet ferroviaire (infrastructure, materiel roulant, signalisation). Publie en plusieurs parties (50126-1 generique, 50126-2 specifique securite).
EN 50129	Systeme de signalisation	Exigences pour les systemes electroniques de securite relatifs a la signalisation. Definit l'attribution des SIL au niveau systeme, la structure du Safety Case, les exigences d'architecture (composition de barrieres, diversite, redondance).
EN 50128	Logiciel signalisation	Exigences pour le logiciel des systemes de commande et de protection ferroviaires. Cycle de vie logiciel, separation des roles, techniques recommandees par SSIL, classification des outils, gestion du logiciel preexistant.
EN 50657	Logiciel materiel roulant	Exigences pour le logiciel embarque sur materiel roulant qui n'est pas couvert par EN 50128 (controle-commande train, freinage, portes, energie, climatisation, information voyageurs). Meme socle methodologique que EN 50128, perimetre distinct.

Les normes d'environnement (CEM ferroviaire EN 50121, equipements electroniques embarques EN 50155) completent ce cadre sur les aspects materiel et qualification, mais ne traitent pas du logiciel. La frontiere fonctionnelle entre EN 50128 et EN 50657 est posee par EN 50129 : un logiciel implique dans une fonction classee "signalisation" releve de EN 50128 ; un logiciel embarque sur materiel roulant qui n'est pas classe signalisation releve de EN 50657. La frontiere n'est pas toujours nette en pratique (l'ETCS embarque pose la question), et son interpretation releve de l'autorite nationale de securite et de l'evaluateur independant.

Relation au cadre generique IEC 61508

EN 50128 et EN 50657 sont des declinaisons sectorielles du cadre IEC 61508. IEC 61508 est la norme parapluie sur la securite fonctionnelle des systemes electriques, electroniques et programmables relatifs a la securite, publiee par la CEI en sept parties (61508-1 a 61508-7). Elle definit le concept de SIL (Safety Integrity Level) sur quatre niveaux et fournit un cadre methodologique generique.

La clause d'introduction de IEC 61508 prevoit explicitement que lorsqu'une norme sectorielle existe, c'est cette norme sectorielle qui prevaut 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 : echelle SIL, techniques recommandees par niveau, approche fondee sur le risque, separation des roles. La connaissance de IEC 61508 facilite la lecture des normes CENELEC, sans qu'elle soit exigee.

D'autres secteurs ont produit leurs propres declinaisons de IEC 61508 : ISO 26262 pour l'automobile, IEC 61511 pour les industries de procedes, IEC 62061 pour la securite des machines, EN 50402 pour la detection de gaz, EN 50402 et EN 50271 pour les detecteurs en atmosphere explosible. Le ferroviaire et l'automobile sont parmi les deux secteurs qui ont le plus formalise leur cadre, avec des roles independants explicites et une classification fine des outils. Pour le cadre generique, voir le guide IEC 61508.

Software Safety Integrity Level (SSIL)

EN 50128 et EN 50657 retiennent une echelle SSIL de 0 a 4 pour caracteriser le niveau de criticite du logiciel. Le SSIL conditionne le niveau de rigueur exige sur le cycle de vie logiciel : techniques recommandees, profondeur de la verification, separation des roles, niveau d'independance de l'evaluation, exigences sur les outils.

SSIL	Criticite indicative	Profil applicable
SSIL 0	Aucune fonction de securite	Logiciel non lie a une fonction de securite. Aucune exigence particuliere de la norme, mais conformite au processus qualite general (ISO 9001 typiquement).
SSIL 1	Securite faible	Logiciel dont la defaillance peut contribuer a une situation dangereuse avec un risque limite. Verification interne suffisante, separation des roles legere.
SSIL 2	Securite moderee	Verification renforcee, separation Auteur / Verificateur stricte au sein de l'equipe, evaluation independante recommandee.
SSIL 3	Securite elevee	Separation organisationnelle plus marquee (Verificateur et Validateur dans des entites distinctes de l'Auteur), techniques formelles recommandees sur les composants critiques, evaluation independante exigee.
SSIL 4	Securite critique	Niveau le plus exigeant. Independance maximale (Evaluateur d'une entite distincte de la conception), techniques formelles fortement recommandees, qualification poussee des outils T3, gestion du logiciel preexistant tres restrictive.

Le SSIL n'est pas attribue au logiciel en isolation. Il decoule d'une analyse d'attribution au niveau systeme conduite selon EN 50129, qui prend en compte les barrieres materielles, l'architecture de redondance et de diversite, et l'environnement d'exploitation. Un logiciel dont la fonction est protegee par une barriere materielle independante peut hereditairement etre classe a un SSIL inferieur au SIL de la fonction systeme. C'est l'un des leviers d'architecture qui permet d'eviter d'avoir a tout developper en SSIL 4 alors que la fonction systeme est classee SIL 4.

La correspondance entre SSIL et SIL IEC 61508 est conceptuelle : un meme numero traduit un meme niveau de criticite 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 etre tracees, verifiees et evaluees. Les phases sont applicables a tout SSIL, l'intensite 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 demarrage de la phase suivante.
• Specification des exigences logiciel (SRS) : derivation des exigences depuis les exigences systeme (sortie de EN 50129), traitement des exigences fonctionnelles, non fonctionnelles, et de securite.
• Architecture logiciel : decomposition en modules, identification des fonctions critiques et non critiques, definition des interfaces, choix des techniques de tolerance aux fautes.
• Conception detaillee : conception des modules, choix des algorithmes, definition des structures de donnees, traitement de la coherence et de la robustesse.
• Codage : ecriture du code source selon des regles de codage definies (sous-ensembles de langage, interdits, restrictions d'usage des pointeurs, des allocations dynamiques, des recursions).
• Verification module et integration : tests unitaires, tests d'integration, couverture de code (instruction, branche, MC/DC selon SSIL), analyse statique.
• Validation logiciel : validation des exigences logiciel face au code execute, en environnement representatif (simulateur, banc de test, plate-forme cible).
• Verification et validation systeme (V&V) : conformite du logiciel integre au systeme, deroulement des scenarios de test systeme.
• Deploiement et mise en service : transfert du logiciel sur le site, integration, 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 eventuel des bases de donnees historiques, archivage des dossiers.

Chaque phase produit des artefacts (plans, specifications, code, rapports de test, rapports de verification) qui sont conserves dans le dossier de configuration. Le dossier complet est l'entree de l'Evaluation independante (Independent Safety Assessor), dont le rapport est lui-meme un livrable au dossier de Safety Case du systeme global selon EN 50129.

Separation des roles : Auteur, Verificateur, Validateur, Evaluateur

EN 50128 et EN 50657 imposent une separation organisationnelle des roles pour eviter qu'une meme personne ou une meme equipe ne soit juge et partie sur ses propres livrables. Quatre roles principaux sont definis.

Role	Fonction	Independance requise
Auteur (Designer / Implementer)	Production des artefacts logiciel : specifications, architecture, conception, code, tests unitaires.	Aucune contrainte d'independance par rapport aux autres auteurs ; mais separation stricte vis-a-vis du Verificateur et du Validateur.
Verificateur	Verification de la coherence 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, meme equipe possible. SSIL 3-4 : equipe ou departement distinct.
Validateur	Verification que le produit fini satisfait aux exigences specifiees au debut du projet. Validation par tests en environnement representatif.	SSIL 1-2 : personne distincte de l'Auteur. SSIL 3-4 : independance organisationnelle plus marquee, frequemment departement distinct.
Evaluateur (Independent Safety Assessor, ISA)	Evaluation independante du processus et de la conformite a la norme. Rapport d'evaluation (Assessment Report) integre au Safety Case.	Independance maximale. Pour SSIL 3-4, l'Evaluateur est generalement une entite externe (societe distincte), accredite et reconnu par l'autorite nationale de securite.

L'independance n'est pas symbolique. Elle est verifiee par l'organigramme du projet, le rattachement hierarchique des personnes, et l'absence de lien financier direct entre l'Auteur et l'Evaluateur sur le perimetre evalue. Un Evaluateur qui rapporte au meme directeur de projet que l'Auteur n'est pas independant au sens de la norme. Pour les SSIL 3-4 sur des projets a forts enjeux (ETCS, enclenchements), l'autorite nationale de securite 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 developpement logiciel selon leur capacite a introduire un defaut dans le produit final ou a masquer un defaut 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 executable ou les donnees du produit fini.	Editeur de texte, outil de gestion documentaire, outil de redaction des plans, traceur de revue, gestionnaire de bibliographie.	Aucune justification specifique. 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 executable. Une defaillance T2 peut masquer un defaut sans en introduire.	Analyseur statique, outil de couverture de test, generateur de jeu de tests, outil de revue, simulateur de plate-forme.	Demonstration de capacite (capability) : version pinnee, configuration documentee, retours d'exploitation, comparaison avec un outil alternatif, tests sur cas de reference.
T3	Outil dont la sortie est incorporee directement ou indirectement dans le code executable ou les donnees du produit fini.	Compilateur, linker, assembleur, generateur 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 execution avec un outil diversifie.

La classification se pose par outil et par projet, en fonction de l'usage effectif. Un meme outil peut etre T2 dans un projet (analyseur statique utilise comme aide a la revue) et basculer T3 dans un autre (s'il genere des annotations integrees au binaire). La classification est documentee dans le Tool Qualification Report, livrable specifique au dossier logiciel pour SSIL 3-4.

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

Logiciel preexistant (Pre-existing Software, PES)

Le logiciel preexistant designe tout composant logiciel qui n'a pas ete developpe specifiquement pour le projet en cours et selon la norme. Cela inclut les composants sur etagere (COTS), les bibliotheques tierces (FAT/FAT32, TCP/IP, cryptographie), le code reutilise d'un projet anterieur, les systemes d'exploitation temps reel, et les pilotes de chipset. EN 50128 ne l'interdit pas, mais elle impose un traitement specifique selon deux voies.

Voie 1, qualification du PES. Le composant preexistant est analyse comme s'il etait specifique : analyse statique, examen du code source si disponible, jeu de tests dedie, demonstration de couverture, evaluation des regles de codage appliquees lors de son developpement initial. Pour les composants sans code source disponible (bibliotheques fermees, OS proprietaires), la qualification s'appuie sur un dossier de qualification fourni par l'editeur (Proven In Use Argument) qui documente le retour d'exploitation cumule : nombre d'installations, heures de fonctionnement, anomalies remontees et traitees, evolutions 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 preexistant est confine dans une zone non critique de l'architecture, en s'appuyant sur des barrieres independantes (wrapper de surete, surveillance externe, redondance diversifiee). L'argument est que la defaillance du composant preexistant ne peut pas atteindre la fonction critique, ou que sa defaillance est detectee et neutralisee par un autre composant developpe selon la norme. Cette voie est frequente pour les systemes d'exploitation temps reel : le RTOS est utilise pour la gestion des taches, mais la fonction critique est encapsulee dans un superviseur dont l'integrite ne depend pas du bon fonctionnement du RTOS.

Le choix entre qualification et confinement depend du SSIL attribue, de l'architecture systeme validee par EN 50129, et de la disponibilite des elements 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 duree de vie operationnelle de plusieurs decennies. La gestion des modifications (correctifs, evolutions fonctionnelles, adaptations a un nouveau materiel, mises en conformite reglementaire) est encadree explicitement par les deux normes.

Toute modification declenche une analyse d'impact qui evalue : les exigences impactees, les composants logiciel modifies, les composants impactes indirectement par leur interface, le risque d'introduction de regression sur la fonction de securite, et l'effort de re-verification necessaire. Selon l'ampleur de la modification, le cycle peut etre soit une re-verification ciblee (modification mineure, perimetre limite), soit une re-validation complete (modification majeure, impact sur l'architecture), soit une nouvelle Evaluation independante (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 perimetre de re-verification, les artefacts modifies, les rapports de test, et l'avis de l'Evaluateur. Le Safety Case systeme est mis a jour en consequence, et l'autorite nationale de securite peut etre notifiee selon l'ampleur (modification dite "substantielle" au sens du Common Safety Method on Risk Assessment, regulation UE 402/2013).

TSI, ERTMS et ETCS : le contexte reglementaire europeen

Le 4e Paquet Ferroviaire, adopte en 2016, harmonise l'autorisation de mise en service du materiel roulant et la certification de securite ferroviaire au niveau europeen. Avant le 4e Paquet, chaque etat membre delivrait ses propres autorisations ; depuis, l'Agence de l'Union europeenne 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 harmonisees pour les sous-systemes structurels du reseau ferroviaire :

• TSI CCS (Control-Command and Signalling) : signalisation au sol et embarquee, dont les sous-systemes ETCS et GSM-R/FRMCS. Reference explicitement EN 50126, EN 50128, EN 50129.
• TSI LOC&PAS (Locomotives and Passenger Rolling Stock) : materiel 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-systemes d'alimentation electrique.
• TSI PRM (Personnes a mobilite reduite) et TSI SRT (Safety in Rail Tunnels) : exigences transversales.

L'ERTMS (European Rail Traffic Management System) est le systeme cible d'unification du controle-commande ferroviaire en Europe. Il se compose de deux briques principales : l'ETCS (European Train Control System), systeme 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), systeme de radiocommunication sol-train.

Les sous-systemes ETCS embarques et au sol sont classes en signalisation et relevent donc explicitement de EN 50128 selon la TSI CCS. Pour les autres logiciels embarques sur materiel roulant (controle-commande train, freinage, portes, energie), la TSI LOC&PAS s'applique et EN 50657 est la norme de reference.

Articulation avec le marquage CE

Le materiel roulant et les sous-systemes ferroviaires ne sont pas couverts par les directives CE classiques (machines, basse tension, CEM generique) au sens d'un produit grand public : la conformite des sous-systemes structurels est demontree par la Verification CE des sous-systemes selon les TSI, conduite par un organisme notifie (NoBo, Notified Body) designe au titre de la directive interoperabilite (2008/57/CE, refondue par la directive 2016/797). Les sous-systemes ferroviaires recoivent ainsi une Declaration CE de Verification distincte des Declarations CE de Conformite des directives classiques.

Toutefois, certains equipements embarques peuvent relever d'autres directives en parallele (CEM via la directive CEM generique pour les equipements connectes, RED pour les emetteurs radio embarques), avec leurs propres exigences. La page marquage CE detaille le cadre general du marquage et de la presomption de conformite.

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 + materiel avionique
• DO-326A et ED-202A: cybersecurite avionique
• MIL-STD-461 et MIL-STD-464, normes CEM defense
• 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 ecueils reviennent sur les projets logiciels ferroviaires, qu'il est utile d'anticiper avant le demarrage.

• Confusion entre EN 50128 et EN 50657 sur le perimetre. Un logiciel embarque sur materiel 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'interpretation systeme. La frontiere est posee par EN 50129 au niveau systeme et doit etre fixee tres tot, idealement avant la specification logiciel.
• Attribution du SSIL avant l'attribution systeme. 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 barrieres. Un projet qui demarre le logiciel en SSIL 4 par defaut, sans analyse systeme, paye un cout de developpement et d'evaluation tres superieur 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'editeurs fournissent en standard. Le choix d'un compilateur sans dossier prequalifie peut bloquer le projet en phase finale d'evaluation. Verifier la disponibilite du dossier (souvent commercialise sous le nom Compiler Qualification Kit) avant de figer la chaine de compilation.
• PES sans dossier Proven In Use. Reutiliser un RTOS commercial ou une bibliotheque ouverte sans dossier de qualification preexistant impose un travail de qualification interne lourd, voire impossible si le code source n'est pas disponible. L'arbitrage entre Proven In Use (dependant de l'editeur) et confinement architectural (independant) doit etre fait avant le choix du composant.
• Separation des roles symbolique. L'independance Auteur / Verificateur / Validateur / Evaluateur exige un organigramme reel et un rattachement hierarchique distinct. Un Evaluateur designe sur le papier mais rattache au meme directeur de projet que l'equipe de developpement n'est pas independant au sens de la norme. L'audit du dossier par l'autorite nationale releve cette non-conformite.
• Confusion entre EN 50128 et IEC 61508 pour le ferroviaire. Conformement 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 renvoye par l'evaluateur. La connaissance de IEC 61508 reste utile pour la lecture, mais elle ne se substitue pas.
• Modification mineure traitee comme un correctif sans analyse d'impact. Toute modification, meme 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 entrainer une suspension de l'autorisation de mise en service.

Pour aller plus loin

Cette page expose le cadre general de EN 50128 et EN 50657. Plusieurs sujets meritent un approfondissement separe :

• la structure detaillee 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 acceptabilite selon les SSIL,
• l'articulation entre EN 50128 et les exigences cybersecurite (TS 50701, IEC 62443) pour le ferroviaire connecte,
• la procedure d'autorisation de mise en service par l'ERA depuis le 4e Paquet et la repartition des roles entre ERA et autorite nationale de securite.

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 europeenne 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