IEC 61508 : sécurité fonctionnelle générique et niveaux SIL

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

Guide · IEC 61508

IEC 61508 est la norme générique de sécurité fonctionnelle des systèmes électriques, électroniques et électroniques programmables relatifs a la sécurité (systèmes E/E/PE). Publiée en 1998, refondue en 2010 (édition 2), maintenue par le sous-comite SC 65A WG 14 de la Commission électrotechnique internationale, elle définit le concept de Safety Integrity Level (SIL 1 a 4), le cycle de vie de sécurité, les exigences architecturales sur les défaillances matérielles aléatoires et sur les défaillances systématiques, dont le logiciel. Elle joue surtout un rôle de norme parente : les normes sectorielles ISO 26262 pour l'automobile, EN 50128 et EN 50657 pour le logiciel ferroviaire, IEC 61511 pour les industries de process, IEC 62061 pour les machines, en sont des dérivations directes. Cette page expose la structure en sept parties, la classification SIL, l'allocation par HAZOP et LOPA, les contraintes Route 1H sur HFT et SFF, et l'arborescence des normes dérivées.

Structure en sept parties

L'IEC 61508:2010 est publiée en sept parties qui couvrent l'ensemble du cycle de vie de sécurité, du concept a la mise hors service. Le découpage est utile pour cadrer un projet et pour localiser une exigence ou un tableau lors d'une revue.

Partie	Sujet	Contenu indicatif
Partie 1	Exigences générales	Cycle de vie de sécurité global, Functional Safety Management, exigences sur les compétences, allocation des SIL, FSA et confirmation measures, tableaux de plages PFD_avg et PFH par SIL
Partie 2	Exigences pour les systèmes E/E/PE relatifs a la sécurité	Architecture matérielle, sous-systèmes de type A et B, tableaux HFT/SFF/SIL (Routes 1H et 2H), diagnostic, intégration, intégration des "compliant items"
Partie 3	Exigences logicielles	Cycle de vie logiciel, techniques et mesures par SIL, langages restreints, codage défensif, tests, verification et validation, exigences sur le logiciel préexistant
Partie 4	Definitions et abréviations	Vocabulaire normatif : SIL, SIF, PFD, PFH, HFT, SFF, défaillance aléatoire vs systématique, mode demande faible vs élevée
Partie 5	Exemples de méthodes de détermination des SIL	Methodes quantitatives et semi-quantitatives, ALARP (As Low As Reasonably Practicable), risk graph, calibration des critères
Partie 6	Lignes directrices d'application des parties 2 et 3	Exemples illustres, calculs PFD_avg / PFH par architecture, techniques de diagnostic, intégration des composants
Partie 7	Vue d'ensemble des techniques et mesures	Catalogue commente des techniques (formelles, semi-formelles, défensives) référencées dans les annexes normatives des parties 2 et 3

Les parties 1 a 4 sont normatives au sens strict. Les parties 5, 6 et 7 sont informatives : elles n'ajoutent pas d'exigence, mais leurs exemples sont fréquemment cites lors des revues d'assesseur pour justifier un choix d'architecture ou une technique de codage.

SIL, SIF et chaine fonctionnelle

Le SIL n'est pas un attribut d'un produit, c'est un attribut d'une Safety Instrumented Function (SIF), ou Safety Function. Une SIF est une fonction E/E/PE qui maintient ou amene le procede dans un état sur en présence d'un evenement redoute. Elle est implémentée par une chaine fonctionnelle complete : capteur, traitement logique (automate, microcontrôleur, fonction logicielle), actionneur, ainsi que les diagnostics, l'alimentation et les chemins de communication associes.

Une fonction de sécurité typique de procede :

• capteur : transmetteur de pression sur tank de stockage,
• logique : automate de sécurité (Safety PLC) qui compare la mesure a un seuil,
• actionneur : vanne de sectionnement avec ressort de rappel a la sécurité,
• diagnostic : auto-tests cycliques du transmetteur et de l'automate, lecture de retour de position de la vanne,
• alimentation et communication : alimentation redondée, bus de sécurité (PROFIsafe, openSAFETY, FSoE selon contexte).

Le SIL alloue a cette SIF resulte de l'analyse de risque, pas du catalogue produit. Une même installation peut porter des SIF de SIL différents, ce qui est la regle dans une raffinerie ou une usine chimique, et l'exception sur un équipement standard ou une seule SIF dominante structure le design.

SIL 1 a 4 : plages PFD_avg et PFH

La partie 1 de l'IEC 61508:2010 fixe les plages numériques par SIL dans les tableaux 2 (mode demande faible) et 3 (mode demande élevée ou continu). Les valeurs ci-dessous sont celles publiées dans la norme, reproduites ici a titre de reference ; toute application réglementaire renvoie a la version pinnee du document IEC.

SIL	Mode demande faible : PFD_avg	Mode demande élevée / continu : PFH (par heure)
SIL 4	>= 10^-5 a < 10^-4	>= 10^-9 a < 10^-8
SIL 3	>= 10^-4 a < 10^-3	>= 10^-8 a < 10^-7
SIL 2	>= 10^-3 a < 10^-2	>= 10^-7 a < 10^-6
SIL 1	>= 10^-2 a < 10^-1	>= 10^-6 a < 10^-5

Le choix du mode d'opération se decide par la fréquence d'appel attendue de la fonction. Le seuil de bascule généralement retenu est de une sollicitation par an : au-dessus, on bascule en mode demande élevée et l'unité de cible passe a la PFH ; au-dessous, on reste en mode demande faible avec PFD_avg. Pour une fonction de protection sur evenement rare (anti-debordement de tank), le mode demande faible est usuel. Pour une fonction continue (régulation de vitesse, anti-collision), le mode demande élevée est la regle.

SIL 4 est un niveau extrême reserve a quelques applications de procede catastrophique (centrales nucléaires, certaines installations chimiques majeures). La grande majorité des SIF industrielles, automobiles et machines se situent entre SIL 1 et SIL 3. ISO 26262 culmine a ASIL D, qui correspond approximativement a SIL 3 selon les contraintes architecturales (la correspondance n'est pas une égalité stricte, les deux normes ayant divergent sur la métrique de target).

Defaillances aléatoires vs systématiques

L'une des contributions structurantes de l'IEC 61508 est la distinction entre défaillances aléatoires et défaillances systématiques. La distinction conditionne la nature des exigences applicables.

• Defaillances aléatoires matérielles : défaillances qui surviennent de maniere aléatoire dans le temps, principalement liées a la physique du matériel (usure, fatigue, derive thermique, défaut de fabrication latent). Elles sont caractérisées par un taux de défaillance lambda, decoupe en lambda_sd (safe detected), lambda_su (safe undetected), lambda_dd (dangerous detected), lambda_du (dangerous undetected). Les cibles SIL sur PFD_avg et PFH portent essentiellement sur ces défaillances.
• Defaillances systématiques : défaillances qui résultent d'une erreur dans la spécification, la conception, l'implémentation, l'intégration ou l'usage. Une défaillance logicielle est, par construction, systématique : un bug est présent ou absent, il n'apparaît pas spontanement. L'IEC 61508 ne propose pas de borne quantitative sur la probabilité de défaillance systématique (la communauté considere qu'il n'existe pas de méthode universelle pour la chiffrer), elle impose un ensemble de techniques et mesures dont la rigueur croit avec le SIL.

Cette dualité explique pourquoi le SIL ne se "calcule" pas seulement par PFH ou PFD_avg : un dossier qui demontre une PFD_avg conforme a SIL 3 mais qui n'applique pas les techniques de la partie 3 pour le logiciel ne soutient pas la revendication SIL 3.

Allocation des SIL : HAZOP, LOPA, risk graph

L'allocation d'un objectif SIL a chaque SIF s'effectue par une méthode reconnue. Trois approches dominent.

HAZOP (HAZard and OPerability study) : étude structurée par mots-cles (no, more, less, as well as, part of, reverse, other than) appliquée aux parametres d'un procede, conduite par une equipe pluridisciplinaire. Elle identifie les écarts possibles et leurs conséquences, et alimente une matrice de risque. Le HAZOP est très répandu dans la chimie et le pétrole, et reste l'amont de l'identification des SIF.

LOPA (Layer Of Protection Analysis) : analyse semi-quantitative qui denombre les couches de protection indépendantes (IPL, Independent Protection Layer) entre un evenement initiateur et un evenement redoute, et compare le risque résiduel a un critère de tolerabilite. La SIF est dimensionnée pour combler l'écart entre le risque tolere et le risque restant apres les couches non-SIS. LOPA est l'outil de reference dans la process industry, codifie par IEC 61511 partie 3.

Risk graph : méthode graphique calibrée (parametres conséquence, exposition, evitabilite, fréquence) qui aboutit a un SIL cible. La partie 5 de l'IEC 61508 donne un exemple de calibration, en avertissant que toute calibration doit être justifiée par le contexte d'application. Le risk graph est largement utilise en automobile (HARA, Hazard Analysis and Risk Assessment, est l'équivalent calibre pour ASIL en ISO 26262) et en machinerie.

D'autres méthodes sont admises : Fault Tree Analysis (FTA), Markov, analyse de criticité type FMEDA (Failure Modes, Effects and Diagnostic Analysis) au niveau composant. L'essentiel n'est pas la méthode, c'est la justification documentée de l'allocation, traçable jusqu'a l'objectif quantitatif PFD_avg / PFH et jusqu'aux exigences sur le logiciel et l'intégration.

Route 1H : HFT et SFF

La partie 2 de l'IEC 61508:2010 impose une contrainte architecturale qui limite le SIL atteignable selon la Hardware Fault Tolerance (HFT) et la Safe Failure Fraction (SFF) du sous-système. C'est la Route 1H, dite "architectural constraints route". Une Route 2H alternative repose sur des données de fiabilité éprouvées et ne reproduit pas les tableaux ci-dessous.

Les sous-systèmes sont classes en deux types selon la qualité de caractérisation des modes de défaillance :

• Type A : modes de défaillance bien caracterises, comportement en condition de défaut connu, données de retour d'expérience disponibles. Composants discrets simples, contacts, relais, transmetteurs analogiques.
• Type B : modes de défaillance non intégralement caracterises ou comportement en défaut non intégralement specifie. Microcontrôleurs, ASIC complexes, FPGA, composants programmables avec firmware.

Tableau 2 (sous-systèmes de type A), Route 1H :

SFF	HFT = 0	HFT = 1	HFT = 2
< 60 %	SIL 1	SIL 2	SIL 3
60 % a < 90 %	SIL 2	SIL 3	SIL 4
90 % a < 99 %	SIL 3	SIL 4	SIL 4
>= 99 %	SIL 3	SIL 4	SIL 4

Tableau 3 (sous-systèmes de type B), Route 1H, plus restrictif :

SFF	HFT = 0	HFT = 1	HFT = 2
< 60 %	non autorise	SIL 1	SIL 2
60 % a < 90 %	SIL 1	SIL 2	SIL 3
90 % a < 99 %	SIL 2	SIL 3	SIL 4
>= 99 %	SIL 3	SIL 4	SIL 4

Conclusion pratique : un sous-système de type B (typiquement un microcontrôleur généraliste) en HFT 0 (pas de redondance) ne peut pas porter une fonction au-dela de SIL 2, et seulement si la SFF est suffisante. Pour atteindre SIL 3 sur du logiciel, deux voies courantes : architecture 1oo2D (un canal sur deux avec diagnostic) en HFT 1 avec SFF entre 60 % et 90 %, ou bien composant Type B specialise (lockstep, redondance interne, diagnostic embarque) qui atteint une SFF >= 90 % en HFT 0.

L'auto-diagnostic est central : plus le diagnostic detecte de défaillances dangereuses, plus la SFF monte, plus le SIL atteignable monte. Une grande partie de l'effort de conception SIL 3 / SIL 4 porte sur les mécanismes de diagnostic interne (test de RAM, test de ROM, watchdog indépendant, comparaison de canaux, ECC sur mémoires, etc.).

Architectures et notation MooN

L'IEC 61508 emploie la notation MooN (M-out-of-N) pour décrire les votes architecturaux d'une chaine de sécurité, avec et sans diagnostic. Les variantes courantes :

• 1oo1 (1-out-of-1) : un canal unique sans redondance. Plafond Route 1H sévère sur Type B, généralement limite a SIL 1 ou SIL 2 selon SFF.
• 1oo1D : un canal unique avec diagnostic ; le diagnostic amene le système en état sur sur défaut detecte. La SFF est typiquement plus élevée, mais HFT reste 0.
• 1oo2 (1-out-of-2) : deux canaux en parallèle, l'un suffit a exécuter la fonction de sécurité ; bonne disponibilité, sensibilité aux défaillances en mode commun (CCF, Common Cause Failure).
• 2oo2 : deux canaux en serie, les deux doivent voter pour exécuter ; minimise les déclenchements intempestifs mais affaiblit la sécurité (un seul canal peut masquer la défaillance dangereuse).
• 1oo2D : deux canaux avec diagnostic, l'architecture la plus répandue pour SIL 3 sur Type B. Le diagnostic detecte le canal défaillant et bascule sur le canal sain.
• 2oo3 : trois canaux avec vote majoritaire, compromis disponibilité/sécurité eleve, utilise sur procedes critiques (centrales, raffineries).

Le calcul de PFD_avg pour une architecture MooN integre les taux de défaillance des canaux, le diagnostic, la période de proof test (T1) et la part de défaillance de cause commune (bêta, beta_D selon la formulation IEC 61508-6). La formule de la partie 6, annexe B, donne les expressions analytiques par architecture. Une bêta typique de 1 a 10 % suffit a dominer le PFD_avg d'une architecture redondante : la conception cherche a réduire bêta par diversification (canaux matériels distincts, logiciels diversifies, alimentations séparées, capteurs de technologie différente).

Cycle de vie de sécurité et logiciel par SIL

La partie 3 organise les exigences logicielles autour d'un cycle de vie en V : spécification de l'architecture logicielle, spécification des modules, codage, tests unitaires, intégration, validation. A chaque étape, des techniques et mesures sont listées dans les annexes normatives avec un degré de recommandation par SIL : "HR" (Highly Recommended), "R" (Recommended), "NR" (Not Recommended), "---" (no recommendation).

Quelques exigences saillantes par SIL :

• SIL 1 : tests dynamiques de modules, codage défensif, revue de code formelle, identification des données d'entrée/sortie.
• SIL 2 : techniques de spécification semi-formelles (HR), revue d'inspection formelle (HR), tests de couverture instructions et branches.
• SIL 3 : techniques semi-formelles ou formelles (HR), couverture MC/DC souvent demandée, analyse statique étendue (HR), tests d'intégration avec verification de la performance temporelle (HR), restriction du langage (sous-ensemble securise type MISRA C pour le C, pas de gestion dynamique de mémoire en exploitation).
• SIL 4 : techniques formelles HR pour les portions critiques, langages a sémantique restreinte, environnement de développement qualifie (qualification du compilateur), preuves formelles ou analyse statique avancee.

Le logiciel préexistant (PSW, Pre-existing Software ; SOUP, Software Of Unknown Pedigree) est traite par un dispositif spécifique. Un OS commercial, un middleware, une librairie peuvent être integres dans une SIF SIL N a condition que leur évaluation soit documentée : revue de la documentation, analyse des défauts connus, tests dedies, restriction de l'utilisation, "wrapping" défensif. La voie la plus simple est de sélectionner un composant déjà evalue par un assesseur tiers comme "compliant item".

Functional Safety Management et compétences

La partie 1 impose un Functional Safety Management (FSM) : organisation, processus, ressources, planning, gestion documentaire et de configuration, gestion des modifications, gestion des non-conformites, gestion du retour d'expérience. Le FSM est verifie lors de la FSA et lors des audits de surveillance.

Les exigences sur les compétences (clause 6 de la partie 1) imposent que chaque acteur ayant un rôle dans le cycle de vie de sécurité soit compétent pour le rôle tenu, et que cette compétence soit documentée. Les critères incluent formation, expérience, autorité, compréhension du contexte d'application. Pour des projets SIL 3 et SIL 4, l'industrie a converge sur des qualifications individuelles reconnues (Certified Functional Safety Engineer / Expert delivre par TUV Rheinland, exida, TUV SUD, CFSE / CFSP), sans que la norme l'exige explicitement.

L'indépendance de l'assesseur croit avec le SIL :

SIL	Independance requise pour le FSA
SIL 1	Independance de personne (l'assesseur n'est pas l'auteur direct)
SIL 2	Independance de département
SIL 3	Independance d'organisation (typiquement assesseur tiers)
SIL 4	Independance d'organisation, généralement organisme accredite

Les confirmation measures complètent la FSA : audits de phase, revues de jalons, vérifications indépendantes, traçabilité des actions correctives. Elles ne se confondent pas avec les revues internes de projet, elles ont un caractère d'attestation independante.

Derivation vers les normes sectorielles

L'architecture d'IEC 61508 a engendre un ensemble de normes sectorielles qui en héritent le squelette (cycle de vie, niveaux d'intégrité, techniques par niveau) en l'adaptant aux contraintes et au vocabulaire de chaque secteur.

Secteur	Norme dérivée	Niveau d'intégrité	Specificites
Process industry	IEC 61511	SIL 1 a 4 (identique a 61508)	Vocabulaire SIS / SIF / IPL, LOPA codifie partie 3, séparation fournisseur (sous 61508) / intégrateur (sous 61511)
Automobile	ISO 26262	ASIL A a D	HARA en place de HAZOP, controllability ajoutée a la sévérité et exposition, work products spécifiques, qualification de composants ("SEooC", Safety Element out of Context)
Ferroviaire (logiciel)	EN 50128 + EN 50657	SIL 0 a 4 (SSIL)	SSIL 0 pour le non-safety, distinction signalisation (50128) et a bord (50657)
Ferroviaire (système)	EN 50126 + EN 50129	SIL 1 a 4	Approche RAMS (Reliability, Availability, Maintainability, Safety), Safety Case detaille pour acceptation par autorité nationale
Machines (control)	IEC 62061	SIL CL 1 a 3 (SIL claim limit)	Plafond SIL 3, approche compatible avec ISO 13849 (qui utilise les Performance Levels PL a a e en approche parallèle)
Medical	IEC 60601-1 + ISO 14971	Pas de SIL formel, approche risque par MOOP/MOPP et performance essentielle	Pour le logiciel, IEC 62304 classifie en A, B, C, en approche parallèle a 61508
Nucleaire	IEC 61513	Categories A, B, C	Approche spécifique, references croisées avec 61508 sur les architectures

Une note importante : les normes sectorielles ne reproduisent pas mécaniquement IEC 61508, elles l'adaptent. Une revendication SIL 3 sous IEC 61508 n'est pas automatiquement équivalente a une revendication ASIL C ou D sous ISO 26262. Un composant developpe sous 61508 et integre dans un projet 26262 fait l'objet d'une analyse d'écart (gap analysis) documentée, qui justifie la réutilisation au regard des exigences spécifiques de la norme sectorielle.

"Compliant item" et proven-in-use

Un composant commercial peut être integre dans une SIF de SIL donne par deux voies, hors développement spécifique sous le SIL vise.

Compliant item : le fournisseur a fait évaluer le composant par un assesseur tiers sous IEC 61508 partie 2 (matériel) et partie 3 (logiciel), et publie un certificat de conformité avec un safety manual. Le safety manual liste les chiffres a intégrer dans le calcul de PFD_avg / PFH (lambda_dd, lambda_du, lambda_sd, lambda_su, SFF), les diagnostics integres, les hypothèses d'usage et les contraintes d'application. L'intégrateur reprend ces chiffres dans son dossier et applique strictement les contraintes du safety manual. Les microcontrôleurs et SoC "SIL 2 / SIL 3 capable" (TI Hercules, Infineon AURIX, Renesas RH850, ST SPC58, etc.), les automates de sécurité (Siemens S7-1500F, ABB AC800M HI, Rockwell GuardLogix), les transmetteurs de procede (Emerson, Yokogawa, ABB) entrent dans cette categorie.

Proven-in-use : le composant n'a pas ete evalue formellement sous 61508, mais son retour d'expérience demontre une fiabilité suffisante. Les conditions sont strictes (partie 7) : usage documente sur une durée significative, sur une population statistiquement significative, dans un environnement comparable, avec un retour de défaillances trace. La justification proven-in-use est plus exigeante a documenter qu'on l'imagine ; elle reste rare en pratique pour atteindre SIL 3 sur un composant complexe, plus frequente pour SIL 1 / SIL 2 sur des composants simples.

Un microcontrôleur "industriel standard" sans certification 61508 et sans dossier proven-in-use ne peut pas porter directement une SIF SIL 2 ou plus. Il est utilisable dans un sous-système qui implemente une architecture redondante avec un canal de diagnostic indépendant, mais l'effort d'architecture (1oo2D, comparaison de canaux, monitoring externe) augmente fortement.

Un cas concret de le cadrage 61508 d'un sous-systeme electronique en amont d'une evaluation par assesseur tiers ? AESTECHNO peut auditer votre conception et votre plan de certification. Nous contacter →

Pieges classiques observes sur le terrain

Plusieurs écueils reviennent dans les retours d'intégrateurs et d'assesseurs.

• Confusion entre SIL composant et SIL fonction : un composant "SIL 3 capable" ne fait pas une SIF SIL 3. La SIF complete (capteur + logique + actionneur + diagnostic + alimentation) doit atteindre la cible PFD_avg / PFH au niveau système, et chaque élément doit respecter les contraintes Route 1H ou Route 2H.
• Architecture HFT 0 sur composant Type B vise SIL 3 : non autorise par Route 1H, sauf si la SFF est >= 99 %. Très peu de composants Type B atteignent ce niveau de SFF en HFT 0 sans redondance interne ; le design force généralement une architecture 1oo2D ou un composant lockstep.
• Application des techniques logicielles non alignées sur le SIL : un code conforme MISRA C n'est pas suffisant pour SIL 3 s'il manque l'analyse statique étendue, la couverture MC/DC, la qualification de l'environnement de développement, la spécification semi-formelle ou formelle.
• Safety manual non applique : le safety manual d'un "compliant item" porte des hypothèses d'usage (température de jonction, tension d'alimentation, fréquence d'horloge, configuration des periphriques) et des contraintes d'application (diagnostic régulier requis, période de proof test, restriction de fonctions internes). Toute déviation invalide la revendication SIL du composant.
• Confusion entre proof test et auto-diagnostic : l'auto-diagnostic interne est continu et detecte une fraction des défaillances dangereuses (mesurée par la SFF). Le proof test est un test periodique manuel, généralement annuel, qui detecte les défaillances dangereuses non détectées par le diagnostic. Les deux entrent dans le calcul PFD_avg, mais ce sont des objets distincts.
• Sous-traitance d'intégration sans transfert du dossier FSM : un fournisseur qui transmet du matériel SIL-capable sans transférer le safety manual et les hypothèses ne permet pas a l'intégrateur de boucler son dossier ; l'assesseur final renvoie le dossier en l'état.
• Allocation SIL non justifiée : un SIL alloue sans rattachement explicite a une analyse de risque (HAZOP, LOPA, risk graph documente) est généralement requalifie en cours d'évaluation, parfois a la baisse, parfois a la hausse.
• Confusion entre normes parentes et dérivées : un fournisseur certifie sous IEC 61508 SIL 3 ne dispense pas le constructeur automobile d'une analyse d'écart vers ASIL ; un fournisseur d'automate certifie sous 61508 ne dispense pas l'intégrateur de site sous IEC 61511 de sa propre analyse SIF.

Proof test, MTTR et hypothèses de calcul

Le PFD_avg d'une fonction de sécurité en mode demande faible se calcule sur la durée d'un cycle de proof test, période T1 au-dela de laquelle la fonction de sécurité est vérifiée dans sa totalité, souvent manuellement, parfois partiellement. Plus T1 est court, plus PFD_avg est bas, mais le coût opérationnel du proof test croit ; un compromis usuel sur installation de procede est T1 = 1 an, parfois étendu a 3 ou 5 ans avec un proof test partiel (PTC, Proof Test Coverage, généralement compris entre 60 et 95 %).

Le MTTR (Mean Time To Restoration) intervient sur les défaillances détectées par le diagnostic : c'est le temps moyen entre la détection d'une défaillance et le retour en état opérationnel apres reparation. Pour une fonction en mode demande élevée ou continu, le MTTR pondéré directement la PFH, parce que la fonction est inopérante pendant la reparation.

Le couple T1 et MTTR pilote, autant que les taux lambda, le PFD_avg / PFH d'une architecture. Une chaine 1oo2D bien spécifiée avec lambda_du faible mais T1 = 10 ans peut dépasser sa cible SIL ; la même chaine avec T1 = 1 an restera confortablement dans la plage. Le proof test n'est pas accessoire, il fait partie intégrante du dossier de sécurité.

Les hypothèses de calcul (T1, MTTR, bêta, lambda detailles, couverture diagnostique) doivent être explicitement listées dans le safety manual du composant et reprises dans le dossier d'intégration. Une revue d'assesseur verifie systématiquement la cohérence entre les hypothèses affichées et les conditions réelles d'exploitation.

Periodes de validité et maintenance des certificats

Un certificat IEC 61508 émis par un assesseur tiers a une durée de validité typique de 3 a 5 ans, avec un audit de surveillance annuel ou bisannuel. Toute modification significative du produit (révision matrice, mise a jour majeure du firmware, changement de fournisseur sur un composant critique) declenche une revue de delta sur le dossier de sécurité. La gestion des modifications est codifiée par la partie 1 du standard : chaque modification fait l'objet d'une analyse d'impact, d'une revue traçable, d'une mise a jour du dossier de validation et, selon la sévérité, d'une nouvelle FSA partielle ou complete.

Pour le glossaire complet des termes utilises (SIL, SIF, PFD_avg, PFH, HFT, SFF, FSA, FSM, ALARP, HAZOP, LOPA, Route 1H, compliant item, proven-in-use), voir le glossaire.

Articulation avec le marquage CE

L'IEC 61508 n'est pas directement une norme harmonisée au sens du Reglement (UE) 2023/988 (sécurité générale des produits) ou de la directive Machines (UE) 2023/1230, mais ses dérivées le sont. Pour une machine, c'est IEC 62061 ou ISO 13849 qui donnent présomption de conformité sur le volet sécurité des systèmes de commande. Pour un équipement de procede, c'est IEC 61511 (transposée EN 61511). Pour un vehicule, ISO 26262, articulée avec le règlement UE type-approval.

Sur le marquage CE des produits qui contiennent une fonction de sécurité, l'enjeu est de démontrer que le SIL alloue est atteint par l'intégration des composants, et que la documentation de sécurité (safety case, safety manual destine a l'utilisateur final, manuel d'utilisation, formation requise) est disponible. Le passage d'un dossier IEC 61508 a un dossier CE n'est pas un changement de norme, c'est un assemblage : la norme harmonisée sectorielle fournit la présomption, le dossier 61508 sous-jacent fournit la traçabilité technique.

Pour le cadre global du marquage CE, voir la page CE et les normes harmonisees. Pour les approfondissements sectoriels, voir ISO 26262 (automobile) et EN 50128 / EN 50657 (logiciel ferroviaire).

Pour aller plus loin

Cette page expose le cadre générique IEC 61508. Plusieurs pages dédiées viendront approfondir des sujets spécifiques :

• ISO 26262 et les ASIL : dérivation automobile, HARA, ASIL décomposition, SEooC, qualification de composants électroniques pour l'automotive,
• EN 50128 et EN 50657 : logiciel ferroviaire de signalisation et embarque, niveaux SSIL, validation et Safety Case ferroviaire,
• IEC 61511 : safety instrumented systems en process industry, LOPA codifie, séparation fournisseur / intégrateur, proof test,
• IEC 62061 et ISO 13849 : sécurité des machines, plafonds SIL CL et Performance Levels,
• IEC 62304 et le logiciel medical : approche parallèle a 61508 partie 3, classes A, B, C.

Besoin d’un appui ?

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

AESTECHNO est le bureau d'études qui édite spilma. Nous aidons les équipes produit à cadrer leur démarche de certification et à éviter les pièges classiques.

Réserver un audit gratuit

Sources & références

1. IEC 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems , IEC www.iec.ch/functional-safety
2. IEC TC 65 SC 65A WG 14, mainteneur de la norme IEC 61508 , IEC www.iec.ch/dyn/www/f?p=103:7:::::FSP_ORG_ID:1297
3. ISO 26262, Road vehicles, Functional safety , ISO www.iso.org/standard/68383.html
4. IEC 61511, Functional safety, Safety instrumented systems for the process industry sector , IEC webstore.iec.ch/publication/24241
5. IEC 62061, Safety of machinery, Functional safety of safety-related control systems , IEC webstore.iec.ch/publication/59927
6. EN 50128, Railway applications, Software for railway control and protection systems , CENELEC www.cenelec.eu/dyn/www/f?p=104:110:::::FSP_PROJECT,FSP_LANG_ID:23715,25