Niveau de performance ISO 13849 (PL ae) : un guide pratique de la sécurité des machines

Le niveau de performance est évalué pour une fonction de sécurité

Une fonction de sécurité implique souvent plusieurs parties du système de contrôle Un modèle conceptuel utile consiste à diviser la fonction en entrée, logique et sortie.

• Entrée Détecter la condition pertinente La partie entrée fournit des informations relatives à la sécurité sur une condition qui nécessite une action protectrice.
• Logique Évaluer les informations La partie logique traite l'entrée liée à la sécurité et détermine la réponse de contrôle requise.
• Sortie Atteindre ou maintenir l'état de sécurité La partie de sortie agit sur la machine de sorte que l'action de protection requise peut être réalisée.

PLr et PL atteint décrivent différentes choses

L'une des distinctions les plus utiles de la norme ISO 13849 est la différence entre le niveau requis et le niveau réellement atteint par la conception achevée.

Que signifie un PFH inférieur ?

Un PFH inférieur représente une fréquence moyenne plus faible de défaillance dangereuse attribuable à la fonction de contrôle liée à la sécurité Il s'agit donc d'une mesure quantitative de la fiabilité requise de cette fonction.

Le PFH ne doit cependant pas être interprété comme une prédiction du moment où un accident se produira Il s'agit d'une mesure probabiliste de sécurité fonctionnelle utilisée dans l'évaluation du système de contrôle lié à la sécurité.

Pourquoi le PFH à lui seul n'établit pas le niveau de performance

ISO 13849 combine la fiabilité quantitative avec les exigences architecturales et qualitatives Le niveau de performance résultant dépend donc de plus que la fréquence de défaillance dangereuse calculée.

L'évaluation prend également en compte des facteurs tels que la catégorie, MTTF_d, DC_avg, : mesures et exigences de cause commune et de défaillance destinées à prévenir les défaillances systématiques.

Ces facteurs sont examinés plus en détail plus loin dans le présent guide.

La catégorie décrit l'architecture et le comportement des défauts

L'ISO 13849 utilise les catégories B, 1, 2, 3 et 4 comme architectures désignées Ils décrivent les principes structurels et la façon dont le sous-système de contrôle lié à la sécurité est censé se comporter lorsque des défauts surviennent.

Le passage de la catégorie B à la catégorie 4 introduit généralement des exigences plus exigeantes relatives à la fiabilité des composants, aux essais, à la tolérance aux pannes et à la détection des pannes.

Mais le numéro de Catégorie est pas lui-même le PL obtenu.

• Chat B Principes de base de sécurité

  Les pièces liées à la sécurité sont conçues, construites, sélectionnées, assemblées et combinées conformément aux normes pertinentes afin de pouvoir résister aux influences attendues, en utilisant les principes de base de sécurité.

• Chat. 1 Principes éprouvés et fiabilité accrue des composants

  La catégorie 1 s'appuie sur la catégorie B et utilise des principes de sécurité éprouvés ainsi que des composants éprouvés si nécessaire. L'architecture reste fondamentalement monocanal, de sorte que la résistance aux pannes dangereuses repose fortement sur la fiabilité des composants.

• Chat. 2 Fonction de sécurité avec tests périodiques ou liés à la demande

  La catégorie 2 introduit une fonction de test qui vérifie la fonction de sécurité à intervalles définis ou dans des conditions définies Un défaut dangereux peut exister entre les tests, de sorte que l'efficacité et le moment des tests sont des éléments importants de l'architecture.

• Chat. 3 Tolérance à défaut unique avec détection partielle des défauts

  Un seul défaut ne doit pas entraîner de perte de la fonction de sécurité Des défauts uniques doivent être détectés à la demande suivante ou avant chaque fois que cela est raisonnablement possible Parce que tous les défauts dangereux ne doivent pas nécessairement être détectés, une accumulation de défauts non détectés peut quand même entraîner une perte de la fonction de sécurité.

• Chat. 4 Tolérance à défaut unique avec un comportement de défaut plus exigeant

  Un seul défaut ne doit pas entraîner de perte de la fonction de sécurité et doit être détecté au moment ou avant la demande suivante Lorsque la détection n'est pas possible, l'accumulation de défauts non détectés ne doit pas entraîner de perte de la fonction de sécurité.

MTTF_d: résistance à une défaillance aléatoire dangereuse

MTTF_d moyens Temps moyen jusqu’à un échec dangereux. Il s'agit d'un paramètre de fiabilité statistique utilisé dans la norme ISO 13849 pour caractériser la résistance d'un canal ou d'un agencement de composants pertinent à une défaillance dangereuse.

Il ne doit pas être interprété comme une durée de vie physique garantie d'un MTTF_d la valeur est une entrée dans le calcul de la sécurité fonctionnelle plutôt qu'une promesse qu'un composant fonctionnera pendant ce nombre d'années avant d'échouer.

Deux sous-systèmes ayant des architectures similaires peuvent donc produire des niveaux de performance différents si la fiabilité de leurs composants ou canaux diffère considérablement.

DC_avg: efficacité de la détection des défauts dangereux

La couverture diagnostique décrit dans quelle mesure les diagnostics détectent les défaillances dangereuses L'ISO 13849 utilise DC_avg représenter la couverture diagnostique moyenne des parties concernées du sous-système.

Les diagnostics peuvent inclure une surveillance croisée, des contrôles de plausibilité, une surveillance des sorties, des impulsions de test ou d'autres mesures en fonction de la technologie et de l'architecture.

Une couverture diagnostique plus élevée peut améliorer les performances de sécurité d’une architecture appropriée, mais DC_avg ne peut pas établir un PL indépendamment de la catégorie, de la fiabilité et des autres exigences applicables.

CCF : éviter l’échec de la redondance pour la même raison

Les canaux redondants n'apportent que peu d'avantages si une cause partagée peut les vaincre en même temps L'ISO 13849 exige donc de prendre en considération Insuffisance de cause commune (CCF) le cas échéant.

Les mesures contre le CCF peuvent aborder des questions telles que :

• séparation physique ou fonctionnelle ;
• protection contre les influences environnementales ;
• indépendance électrique, mécanique et électromagnétique ;
• diversité appropriée des composants ou de la technologie, le cas échéant ;
• analyse systématique des causes potentielles de défaillance partagée ; et
• compétences et pratiques d'ingénierie appropriées à la conception.

L'ISO 13849-1 :2023 met plus clairement l'accent sur la prise en compte du CCF au niveau du sous-système plutôt que de supposer qu'une évaluation générique du CCF couvre automatiquement chaque partie d'une fonction de sécurité complexe.

Une panne matérielle aléatoire n’est qu’une partie de l’image

Une fonction de sécurité peut échouer même lorsque le calcul matériel probabiliste semble satisfaisant.

Des erreurs de spécification, une application de composant inadaptée, des erreurs logicielles, un paramétrage incorrect, des erreurs de câblage, des erreurs d'intégration ou des modifications incontrôlées peuvent être introduites défaillances systématiques.

L'ISO 13849 comprend donc des exigences et des orientations destinées à prévenir ou contrôler ces défaillances tout au long de la spécification, de la conception, de la mise en œuvre, de la vérification et de la validation.

Étape 1 : Définissez la fonction de sécurité

Avant d'effectuer des calculs de fiabilité, le comportement prévu doit être clairement défini.

Une description simplifiée de la fonction de sécurité pour cet exemple pourrait être la suivante

Lorsque le dispositif de protection d'accès est ouvert, le mouvement dangereux de la machine doit être amené ou maintenu dans l'état de sécurité défini conformément aux exigences de réponse spécifiées.

Une spécification réelle des exigences de sécurité contiendrait des informations supplémentaires telles que les modes de fonctionnement, les conditions de déclenchement, l'état de sécurité, le temps de réponse requis, le comportement de réinitialisation et de redémarrage, la réaction aux pannes et les interfaces pertinentes.

Étape 2 : Identifiez les pièces qui mettent en œuvre la fonction de sécurité

À des fins d'explication, de nombreuses fonctions de sécurité peuvent être comprises à l'aide de la séquence d'entrée-sortie familière :

• Entrée Détecter que le protecteur d'accès n'est plus dans l'état requis pour le fonctionnement dangereux de la machine.
• Logique Évaluer les données relatives à la sécurité et émettre la réponse de contrôle requise liée à la sécurité.
• Sortie Agir sur la machine de manière à ce que les mouvements dangereux soient arrêtés ou empêchés conformément à la fonction de sécurité définie.

Étape 3 Déterminez comment chaque sous-système est évalué

Tous les sous-systèmes ne doivent pas être évalués exactement de la même manière Les données disponibles relatives à la sécurité dépendent du fait que le sous-système est conçu par le constructeur de la machine ou qu'il a déjà été évalué et validé par son fabricant.

Cette distinction est importante Les ingénieurs ne doivent pas ouvrir automatiquement chaque sous-système validé et inventer une nouvelle Catégorie interne, MTTF_d ou DC_avg valeurs lorsque le sous-système est destiné à être utilisé via ses données déclarées liées à la sécurité.

Étape 4 : Évaluez la fonction de sécurité complète

La fonction de sécurité est ensuite évaluée comme la combinaison des sous-systèmes contributeurs.

Leurs contributions aux défaillances dangereuses, leurs capacités liées à la sécurité, leur architecture et leurs exigences qualitatives applicables doivent être prises en compte à l'aide de la méthodologie ISO 13849.

Il ne suffit pas d'identifier le sous-système avec le PL individuel le plus élevé et d'appliquer cette notation à l'ensemble de la fonction De même, un sous-système d'entrée solide ne peut pas compenser automatiquement les performances inadéquates ailleurs dans la chaîne liée à la sécurité.

Étape 5 Comparez le PL obtenu avec PLr

Une fois les exigences quantitatives et qualitatives pertinentes évaluées, le niveau de performance atteint est comparé au niveau de performance requis défini dans la spécification des exigences de sécurité.

Pour cet exemple:

Obligatoire PLr = d

La fonction de contrôle liée à la sécurité achevée doit donc démontrer un niveau de performance atteint suffisant pour répondre à cette exigence.

Un calcul qui produit un PL obtenu inférieur signifie que la conception ne satisfait pas au PLr supposé et doit être reconsidérée.

Étape 6 Utiliser des outils de calcul le cas échéant

Les outils d'ingénierie peuvent faciliter l'évaluation, notamment lorsqu'une fonction de sécurité contient plusieurs sous-systèmes ou des données détaillées sur la fiabilité.

SISTEMA, fourni par l'Institut allemand pour la sécurité et la santé au travail (IFA), prend en charge l'évaluation ISO 13849 en modélisant les structures liées à la sécurité et en calculant les valeurs, y compris le niveau de performance atteint.

Étape 7 Vérification et validation suivent toujours

Atteindre le PL calculé requis n’est pas la fin du processus.

La conception doit être vérifiée par rapport à ses exigences spécifiées, et la fonction de sécurité mise en œuvre doit être validée pour confirmer qu'elle fonctionne comme prévu dans les conditions de fonctionnement et de panne pertinentes.

Cela inclut bien plus que les mathématiques de fiabilité. La mise en œuvre réelle peut impliquer le câblage, la configuration, les logiciels, les interfaces, la réaction aux pannes, le comportement d'arrêt et le comportement de redémarrage qui doivent être vérifiés dans le cadre de l'argument complet de la sécurité.

PL et SIL appartiennent à des méthodologies différentes

Comparaison des plages quantitatives de PFH

Le tableau ci-dessous est mieux lu comme un Guide de correspondance PFH, [TRADUCTION], non pas comme une table de conversion universelle entre deux normes complètes.

“PL d égale SIL 2” est utile raccourci mais incomplet

PL d et SIL 2 occupent le même intervalle PFH quantitatif, la comparaison sténographique est donc utile lorsque l'on parle de panne matérielle aléatoire dangereuse.

Cela ne signifie pas qu'un système conçu et évalué selon la norme ISO 13849-1 peut simplement être réétiqueté comme système CEI 62061 SIL 2, ou vice versa.

Chaque norme comporte des exigences régissant des questions telles que l'architecture du sous-système, la tolérance aux pannes matérielles, les diagnostics, les pannes systématiques, les logiciels, la vérification et la validation. Ces exigences font toujours partie de la méthodologie applicable.

La catégorie n'est pas une troisième échelle équivalente

ISO 13849 Les catégories B, 1, 2, 3 et 4 décrivent les architectures désignées et le comportement des défauts Elles ne forment pas une autre échelle d'intégrité qui peut être placée à côté de PL et SIL dans un simple diagramme de conversion à trois colonnes.

Par exemple, la déclaration :

Catégorie 3 = PL d = SIL 2

est une simplification excessive.

La catégorie 3 peut faire partie d'une conception qui atteint PL d, mais le PL obtenu dépend également des données de fiabilité, de la couverture diagnostique, des mesures de cause commune d'échec et du respect des autres exigences ISO 13849 applicables.

L'utilisation de sous-systèmes standard est possible mais contrôlée

La conception moderne de la sécurité des machines peut combiner des sous-systèmes préalablement validés développés selon différentes normes de sécurité fonctionnelle. L'ISO 13849-1 :2023 reconnaît explicitement les sous-systèmes précédemment validés conformément à la CEI 62061, à la série CEI 61508 et aux normes de produits pertinentes liées à la sécurité.

Lorsque des sous-systèmes basés sur SIL sont incorporés dans une fonction de sécurité ISO 13849, leur capacité PFH et intégrité peut être utilisée dans les conditions définies par la norme Cela ne signifie pas qu'une catégorie ISO 13849 doit toujours être attribuée au sous-système importé.

ISO 13849 ou CEI 62061 ?

Le cadre approprié dépend de l'application des machines, des normes applicables, des technologies impliquées, de l'approche technique et du cycle de vie de sécurité adopté pour le projet.

Il n'est plus précis de réduire le choix à la norme ISO 13849 pour les systèmes mécaniques et à la norme CEI 62061 pour les systèmes électriques.“ Les deux normes prennent désormais en charge les technologies de systèmes de contrôle de machines à grande échelle et peuvent être utilisées dans des conceptions sophistiquées de sécurité fonctionnelle.

Quelle que soit la méthodologie sélectionnée, elle doit être appliquée de manière cohérente et clairement documentée.

Trois points à retenir

• PL et SIL peuvent être comparés via PFH, mais les deux méthodologies complètes ne sont pas interchangeables.
• PL d et SIL 2 ont une correspondance quantitative PFH particulièrement directe, X et Y 2, Y 2, Y 2, Y 2, Y 2, Y 2, Y 2, Y 2, Y 2, Y 1, Y 1, Y 1, Y 1, Y 1, Y 1, Y 1, Y 1, Y 1, Y 1, Y 1, Y 1, Y 1, Y 1, alors que PL e doit être lu en utilisant la définition actuelle ISO 13849-1 :2023 de PFH <10⁻⁷.
• Catégorie est un concept architectural ISO 13849, pas une échelle de conversion SIL/PL supplémentaire.

Classe de type et capacité d'application

La relation est mieux exprimée à l'aide de “jusqu'à” plutôt que de traiter Type, PL et SIL comme des étiquettes interchangeables.

Pourquoi le Type 3 est-il important ?

Les éditions antérieures du cadre CEI 61496 étaient généralement associées aux ESPE de type 2 et de type 4. La quatrième édition de la CEI 61496-1, publiée en 2020, a introduit le type 3 comme classe supplémentaire.

Le type 3 offre une capacité pour les applications jusqu'à PL d / SIL 2. Cela comble l'écart entre la capacité d'application maximale du type 2 et du type 4.

Cela démontre également pourquoi la sélection de type doit suivre les performances requises de la fonction de sécurité plutôt que l'hypothèse selon laquelle le type le plus élevé doit toujours être sélectionné.

Le type n'est pas la même chose que la résolution ou la capacité de détection

Un deuxième malentendu courant consiste à traiter la classe de type CEI 61496 comme si elle décrivait la résolution de détection physique d'un ESPE.

Ce sont des caractéristiques différentes.

• Type aborde la conception liée à la sécurité, le comportement des pannes et la capacité d’intégrité.
• Capacité ou résolution de détection décrit la taille ou la caractéristique d'un objet que le système de détection est destiné à détecter.
• Dimensions du champ de protection décrire la zone de détection physique fournie par l'équipement.

Une résolution particulière n'établit donc pas si une ESPE est de type 2, de type 3 ou de type 4.

La capacité de l'appareil et la capacité du système sont des questions distinctes

Lors de la sélection d'un dispositif de protection électro-sensible, deux questions doivent rester séparées.

• Le type ESPE convient-il au PLr ou au SIL requis de l'application ?
• La fonction de contrôle complète liée à la sécurité atteint-elle réellement les performances requises une fois que tous les sous-systèmes contributeurs ont été évalués ?

La première question concerne la capacité de l'équipement de protection La seconde concerne la fonction complète de sécurité de la machine.

La réussite du premier test ne répond pas automatiquement au second.

La CEI 61496 ne détermine pas l'aménagement complet de la sauvegarde

La CEI 61496 spécifie les exigences relatives à l'équipement de protection lui-même ainsi que ses performances et son comportement d'interface liés à la sécurité. Il ne détermine pas, à lui seul, tous les aspects de la manière dont la sauvegarde doit être appliquée à une machine particulière.

Des questions telles que la fonction de sécurité requise, l'évaluation des risques de la machine, le positionnement de l'équipement de protection, la distance de sécurité et d'autres mesures spécifiques à l'application doivent être abordées au moyen des normes de sécurité des machines et du processus d'ingénierie pertinents.

La vérification et la validation répondent à différentes questions

En termes d’ingénierie pratique, la distinction peut être comprise comme suit.

Vérification : vérification du résultat de l'ingénierie

La vérification fournit la preuve que la conception liée à la sécurité a été élaborée et évaluée conformément aux exigences définies et à la méthodologie ISO 13849 applicable.

Selon la fonction de sécurité, la vérification peut inclure la confirmation :

• que la fonction de sécurité et ses exigences ont été clairement définies ;
• que le PLr sélectionné est l'exigence traitée ;
• que les structures et interfaces des sous-systèmes sont représentées correctement ;
• que les données du fabricant et les valeurs de fiabilité sont utilisées dans leurs conditions déclarées ;
• cette catégorie, MTTF_d, DC_avg, [TRADUCTION], le CCF et d'autres paramètres pertinents ont été évalués le cas échéant ;
• que les exigences logicielles et systématiques ont été satisfaites ; et
• que le niveau de performance atteint est suffisant pour le PLr requis.

La vérification est donc plus large que la simple lecture de la valeur finale PL à partir d'un outil de calcul.

Validation : confirmation de la fonction de sécurité mise en œuvre

La validation examine si la fonction de contrôle liée à la sécurité mise en œuvre répond réellement aux exigences de sécurité spécifiées.

utilisations de validation ISO 13849 analyse et test. Les deux approches se complètent ; l’analyse n’élimine pas la nécessité de tests fonctionnels appropriés.

En fonction de la fonction de sécurité et de sa spécification, la validation peut comprendre l'examen de :

• lancement de l'action de sécurité requise ;
• réalisation et maintien de l'état de sécurité défini ;
• réponse aux défauts pertinents ;
• comportement de réinitialisation et de redémarrage ;
• modes de fonctionnement et transitions de modes ;
• temps de réponse ou d'arrêt spécifiés ;
• comportement du câblage et de l'interface ;
• paramètres logiciels et paramètres ; et
• conditions environnementales ou d'exploitation qui font partie de la spécification des exigences de sécurité.

Qu'est-ce qui a changé avec la validation dans la norme ISO 13849-1 :2023 ?

Les éditions antérieures étaient souvent utilisées avec la norme ISO 13849-2 pour le processus de validation détaillé.

Dans la norme ISO 13849-1 :2023, les exigences normatives de validation ont été révisées et intégrées Article 10 de la partie 1. Cela rend la validation une partie plus visible du même cycle de vie de conception de fonction de sécurité couvert par la norme ISO 13849-1.

Le changement renforce également la relation entre la spécification des exigences de sécurité et le processus de validation ultérieur : la validation nécessite un ensemble défini d'exigences par rapport auxquelles la fonction de sécurité mise en œuvre peut être examinée.

Où SISTEMA s'adapte-t-il ?

SISTEMA : l'outil logiciel d'intégrité de la sécurité pour l'évaluation des applications de machines est fourni par IFA pour prendre en charge les travaux d'ingénierie avec la norme ISO 13849.

Il permet à un ingénieur de représenter les fonctions et sous-systèmes de sécurité, de saisir les données pertinentes liées à la sécurité et de calculer les quantités utilisées pour évaluer le niveau de performance atteint.

La documentation relie le processus complet

Une bonne documentation de sécurité fonctionnelle devrait permettre de retracer les décisions techniques depuis la fonction de danger et de sécurité d'origine jusqu'aux preuves de validation finales.

Un relevé de projet peut donc comprendre

• l'évaluation des risques liés aux machines ;
• la spécification des exigences de sécurité ;
• le PLr déterminé ;
• architecture du sous-système et données relatives à la sécurité ;
• calculs et hypothèses d'ingénierie ;
• informations sur les logiciels et la configuration, le cas échéant ;
• dossiers de vérification ; et
• plans de validation, résultats des tests et conclusions.

Cette traçabilité devient particulièrement importante lorsqu'une machine est modifiée ultérieurement, car les ingénieurs doivent comprendre quelles hypothèses originales et quelles exigences de sécurité ont pu être affectées.

1. Accent accru sur la fonction de sécurité et ses sous-systèmes

L’un des changements structurels les plus évidents est l’accent mis davantage sur la mise en œuvre d’une fonction de sécurité en combinant plusieurs sous-systèmes.

Cela rend la vue au niveau du système plus explicite. Au lieu de traiter un dispositif de sécurité individuel comme s'il s'agissait de la fonction de sécurité complète, l'ingénieur prend en compte tous les sous-systèmes qui contribuent au comportement de sécurité requis.

Ces sous-systèmes peuvent inclure des structures auto-développées ainsi que des sous-systèmes préalablement évalués avec des données déclarées liées à la sécurité.

2. Les spécifications de la fonction de sécurité et le SRS ont été renforcés

L'article 5 accorde une plus grande attention à la spécification des fonctions de sécurité et à la Spécification des exigences de sécurité (SRS).

L'intention est d'établir clairement ce que la fonction de sécurité doit faire avant que l'ingénieur ne tente de prouver que la conception atteint le niveau de performance requis.

Selon la fonction de sécurité, les exigences pertinentes peuvent inclure

• le comportement de sécurité requis ;
• PLr;
• modes de fonctionnement pertinents ;
• conditions de déclenchement;
• exigences de sécurité ;
• délais de réponse;
• comportement de réaction aux pannes ;
• exigences de réinitialisation et de redémarrage ; et
• interfaces avec d'autres fonctions de sécurité.

L'annexe M fournit des informations supplémentaires destinées à soutenir l'élaboration de la spécification des exigences de sécurité.

3. Plusieurs règles de conception des sous-systèmes ont été clarifiées

L'article 6 contient des exigences révisées et clarifiées pour la conception des sous-systèmes liés à la sécurité.

Parmi les changements figure une définition optimisée de Catégorie 2, : ainsi que des éclaircissements relatifs à la prise en compte des défauts, à l'exclusion des défauts et à l'utilisation de composants éprouvés.

La révision renforce un principe qui s'applique dans toute la norme ISO 13849 : la catégorie identifie les caractéristiques architecturales et de comportement en cas de panne, mais elle ne détermine pas indépendamment le niveau de performance final.

4. La défaillance de cause commune est considérée plus explicitement par sous-système

L'annexe F élargit et clarifie les mesures contre Insuffisance de cause commune (CCF).

Un changement pratique important est l’attente plus claire que les mesures anti-CCF soient prises en compte niveau sous-système. Différents sous-systèmes peuvent avoir différentes technologies, mises en page, expositions environnementales et mécanismes de défaillance partagés.

L'ingénieur ne doit donc pas supposer qu'une évaluation générique du CCF représente automatiquement chaque sous-système dans une fonction de sécurité complexe.

5. Les exigences logicielles liées à la sécurité ont été révisées et élargies

L'article 7 contient des améliorations et des précisions relatives aux logiciels liés à la sécurité.

L'édition 2023 aborde les logiciels dans le cadre du processus complet d'ingénierie lié à la sécurité plutôt que de considérer la fiabilité du matériel comme suffisante à elle seule.

L'annexe N complète ces exigences par des informations permettant d'éviter les pannes systématiques grâce à la conception de logiciels et comprend un exemple simple relatif à la validation de logiciels.

Ceci est particulièrement pertinent car un système peut satisfaire ses objectifs de fiabilité matérielle aléatoire tout en ne parvenant pas à remplir sa fonction de sécurité prévue en raison d'erreurs de spécification, de programmation, de paramétrage ou de modification.

6. Les exigences de validation sont désormais intégrées à la partie 1

L'ISO 13849-1 :2023 introduit une clause de validation dédiée 10. Les exigences de validation normative de l'ISO 13849-2 ont été révisées et intégrées dans la partie 1.

Cela amène la validation plus visiblement dans le même cycle de vie que la spécification, la conception et l'évaluation du niveau de performance.

Cela renforce également l'importance du SRS : la validation nécessite des exigences définies par rapport auxquelles la fonction de sécurité mise en œuvre peut être examinée par le biais d'analyses et de tests.

7. Guide pour déterminer PLr, en particulier le paramètre P modifié

L'annexe A conserve le principe familier du graphique des risques SF mais révise le traitement des paramètre P, : la possibilité d’éviter le danger ou de limiter le préjudice.

L'édition 2023 fournit des orientations plus structurées afin que la décision P1 ou P2 reflète des conditions d'exploitation réalistes plutôt qu'une question simpliste de savoir si un opérateur pourrait théoriquement s'éloigner.

Les facteurs peuvent inclure les caractéristiques de l'opérateur, la vitesse de déplacement dangereuse, la possibilité physique d'évitement, la reconnaissance du danger et la complexité opérationnelle.

8. La gestion de la sécurité fonctionnelle a reçu des orientations plus explicites

L'annexe G.5 élargit les orientations sur Gestion de la sécurité fonctionnelle.

L'objectif est de fournir une approche systématique de la conception et de la mise en œuvre des systèmes de contrôle liés à la sécurité et de réduire les erreurs introduites par la spécification, la mise en œuvre et la modification ultérieure.

Un plan de sécurité fonctionnelle peut documenter les activités, responsabilités, ressources et procédures pertinentes tout au long du cycle de vie du projet La forme et la profondeur appropriées dépendent de facteurs tels que la complexité, l'ampleur et la nouveauté du projet.

9. L’immunité CEM fait l’objet d’une attention pratique supplémentaire

L'annexe L fournit de plus amples informations sur la réalisation d'une immunité électromagnétique suffisamment élevée pour les systèmes de contrôle liés à la sécurité.

Cela est important car les perturbations électromagnétiques peuvent devenir une influence courante ou systématique sur l’électronique, les interfaces et les voies de communication liées à la sécurité.

La sécurité fonctionnelle ne peut donc pas être évaluée uniquement au moyen de numéros de fiabilité tout en ignorant l'environnement électromagnétique réel dans lequel la fonction de sécurité doit fonctionner.

10. Plusieurs annexes informatives fournissent des orientations techniques supplémentaires

Les annexes révisées rendent les informations techniques à l’appui plus explicites dans plusieurs domaines.

1. Annexe F Cause d'échec

   Clarifie les mesures contre le CCF et leur évaluation au niveau du sous-système.

2. Annexe G.5 Gestion fonctionnelle de la sécurité

   Fournit des conseils pour organiser le processus de sécurité fonctionnelle et documenter les responsabilités et les activités.

3. Annexe L : CEM

   Fournit des informations supplémentaires destinées à soutenir une immunité électromagnétique adéquate des systèmes de contrôle liés à la sécurité.

4. Annexe M Spécifications des exigences de sécurité

   Fournit des informations supplémentaires pour définir et documenter les exigences en matière de fonction de sécurité.

5. Annexe N Logiciels liés à la sécurité

   Fournit des informations relatives à l'évitement des pannes logicielles systématiques et comprend un exemple simple de validation logicielle.

6. Annexe O Composante liée à la sécurité

   Fournit des conseils supplémentaires pour communiquer et utiliser les données des composants liées à la sécurité, alignés sur l'approche utilisée dans la VDMA 66413.

Qu'est-ce qui n'a pas fondamentalement changé ?

L'idée centrale reste familière : définir une fonction de sécurité, établir le PLr requis, concevoir le système de contrôle lié à la sécurité, évaluer le niveau de performance atteint, et vérifier et valider cette mise en œuvre.

Paramètres tels que Catégorie, MTTF_d, DC_avg et le CCF continue d’être important lors de l’évaluation des sous-systèmes auto-développés.

Ce qui a le plus visiblement changé, c'est la structure autour de ces calculs : des spécifications de fonction de sécurité plus claires, une plus grande utilisation du concept de sous-système, un logiciel et un traitement de validation plus solides, ainsi que des conseils plus explicites en matière de cycle de vie et de gestion.