SIL Calcul

Cette application permet de calculer le niveau d’Intégrité de Sécurité (SIL) atteint par le système instrumenté (SIS) utilisé pour réaliser une fonction de sécurité (SIF). L’animation  a un objectif pédagogique en montrant l’influence des choix de conception et d’exploitation sur le niveau d’intégrité de sécurité atteint. « SIL Calcul » permet d’évaluer la capabilité aléatoire du système instrumenté de sécurité selon les normes CEI 61511: 2017 et CEI 61508: 2010 en fonction de nombreux paramètres (architectures, taux de défaillance, périodicité des tests, taux de couverture de diagnostic, les temps de maintenance et de remise en service, les types de composants, …).
Fonction Instrumentée de Sécurité -
--> Votre navigateur est trop ancien - Utiliser chrome ou Firefox à jour
Taux de défaillances en FIT - CAPTEURS


%
heures
Tests Partiels:
%
Taux de défaillances en FIT - TRAITEMENT


%
heures
Tests Partiels:
%
Taux de défaillances en FIT - ACTIONNEURS


%
heures
Tests Partiels:
%

Guide d'utilisation

PFD Calcul
Chaque niveau d’intégrité d’une SIF (SIL 1, 2, 3 ou 4), est associé à un niveau de réduction de risque croissant. Une SIF peut être compromise par des pannes systématiques et/ou des pannes matérielles aléatoires. A noter que les attaques volontaires et notamment les cyber attaques sont également traitées dans le cadre de la sécurité fonctionnelle. Elles font l’objet d’une évaluation du niveau de cybersécurité (SL) conformément à la CEI 62443.
Les pannes aléatoires peuvent généralement être quantifiées alors que les défaillances systématiques sont évaluées selon des critères qualitatifs (système de gestion de la sécurité fonctionnelle, compétence du personnel, indépendance, outils et méthodes, qualité logicielle, cycle en V, V&V,  …).
La zone supérieure (1) et inférieures (3) sont des zones de saisie et de sélection. La zone centrale (2) est la zone de présentation des résultats en fonctions des architectures, des matériels utilisés et des conditions d’utilisations.
Permet de sélectionner le mode de fonctionnement de la SIF parmi les trois modes.
Le mode Faible sollicitation doit être choisi si la SIF n’est pas sollicitée dans le cadre du fonctionnement normal du système opérationnel et lorsque la fréquence de sollicitation est inférieure à 1 fois par an. Dans ce mode l’évaluation repose, entre autre, sur la PFDAvg (Probabilité moyenne de défaillance lors d’une sollicitation).
Le mode Forte sollicitation doit être choisi si la SIF n’est pas sollicitée dans la cadre du fonctionnement normal du système opérationnel et lorsque la fonction est sollicitée plus d’une fois par an. Dans ce mode l’évaluation repose sur la PFH (Fréquence moyenne de défaillances dangereuses par heure) et non sur la PFD.
Le mode Continu doit être choisi dés que la fonction est sollicité en fonctionnement normal. La perte de la SIF, génère a elle seule un danger.
Indiquer pour chaque sous-fonctions (parties Entrée, Traitement et Sortie) les taux de défaillances dangereuses non détectées (λdu), dangereuses détectées (λdd), sûres non détectées (λsu) et sûres détectées (λsd). Les défaillances sont exprimées en FIT (Failure in Time).  1 FIT = 10E-9. Tous les taux de défaillance sont données en période de vie utile (taux constant).

 

Sélectionner l’architecture de chaque partie (Entrée, Traitement et Sortie). Les architectures sont normalisées M-out-of-N” (MooN) selon CEI 61508.
Les architectures influent sur le calcul de la PFD/PFH et impactent le niveau SIL atteint selon le HFT associé (Hardware Fault Tolerance). Les architectures MooND intègrent des capacités de diagnostics permettant d’améliorer l’intégrité et/ou la disponibilité. Dans le cas d’architectures redondantes, le facteur Beta indique la proportion de défaillances de mode commun et/ou cause commune (CCF). Ce facteur Beta peut être amélioré (réduit) par de la diversité (redondance hétérogène). Sauf justification, il sera considéré un fort mode commun (valeur conservatrice de 10%). 

 

Les tests périodiques (Proof Test) ont pour objectif de détecter les défaillances dangereuses non détectées (λdu) par les autodiagnostics. A l’issue d’un test partiel, le système est remis en état comme à l’origine. Si durant la durée de vie utile, les tests périodiques ne permettent pas de couvrir plus de 90% des défaillances dangereuses non détectées, il conviendra de rentrer en Ti la durée de vie du sous-système et de considérer le TI comme un test partiel (Di). 
Indiquer le temps total de réparation en heures. Le terme MRT a été choisi à la place de MTTR afin d’éviter toute confusion suivant les normes. Ce MRT doit être vu ici comme le temps total de remise en état du sous-système suite à une défaillance. Outre le temps de réparation (repair time) pouvant être donné par le constructeur, ce temps inclut tout les temps annexes de maintenance (détection, logistique, appel personnel compétent, réglages, essais, …).
Il est considéré que le système opérationnel n’est pas mis en position de sécurité  durant la maintenance (généralement l’arrêt). Si ce n’est pas le cas, entrez 0, puisque le phénomène dangereux n’est plus présent durant la réparation.
Permet de sélectionner le type de composant. Sélectionner « Eprouvé & certifié » si le composant est éprouvé sur la base d’une utilisation antérieure dans un environnement similaire, et fait l’objet d’un certificat de « capabilité SIL » délivré par le constructeur. C’est le cas optimum. 
Sélectionné « Eprouvé » s’il peut-être démontré que le composant ou sous-système a été largement utilisé dans un environnement similaire et a donné satisfaction (taux de défaillance dangereuses non détectées faible). Si le système n’est ni éprouvé, ni certifié, sélectionner « composant basique ».  Le système ne pourra prétendre a un niveau SIL qu’avec des mesures compensatoires et après un temps de surveillance et d’évaluation.