La Sécurité de Fonctionnement (SdF): définition, explication et exemple. Correspondant à la notion « Safety » en Anglais, il s’agit de l’ensemble des dispositions assurant que votre Système ne se dégrade pas ni ne blesse ses utilisateurs, à la suite de dysfonctionnements involontaires. Voici quelques méthodes avancées pour sécuriser un Produit.
Sécurité, Sûreté, Fiabilité, Résilience… Ces 4 mots ne désignent en fait pas les mêmes notions. Et la différence est importante lors de la conception de votre Produit car les objectifs et méthodes sont différents. Je traite dans cet article de la notion de Sécurité Système (le S de FMDS), et j'aborde la sécurisation d'un Système avec les méthodes avancées de l'état de l'art.
Pour en savoir plus sur la définition et l'objectif de la Sécurité Fonctionnelle, référez-vous à l'article dédiées aux méthodes simples.
Il y a plusieurs moyens d'arriver à sécuriser son Système. Voici ci-dessous les méthodologies à exploiter. Il s'agit du « mode expert » de la conception Produit.
Pour connaître les méthodes simples, lisez cet article avant de poursuivre.
Les exigences initiales de FMDS (RAMS en Anglais), dont la Sécurité, sont des exigences de Besoin. Elles sont donc exprimées par le Client, seul ou accompagné par l'industriel (vous). On peut aussi parler d'Objectifs FMDS.
Ce travail de collaboration est très important car d'une part le Client sait mieux que vous ce dont il a besoin, et d'autre part il ne sait peut-être pas l'exprimer sous forme d'exigences claires et éventuellement chiffrées.
Lors de cette collaboration/négociation, il faut aussi garder en tête que les RAMS doivent être exprimés en fonction des coûts induits dans le Projet. En effet, un effort RAMS est non négligeable dans la mise au monde d'un Produit. Cela vient avec des coûts dédiés et potentiellement élevés. Il faut que tout le monde (client, fournisseur) en ait conscience et adapte le degrés d’effort en fonction du budget autorisé.
Nous avons vu dans l'article sur les méthodes simples comment réaliser une Analyse de Risques via une AMDEC. Dans ce précédent article, je conseille de faire une AMDEC au niveau Système complet ("Spécification Générale") en passant en revue chaque exigence fonctionnelle Système.
Selon votre Produit (engin spatial ? dispositif médical ?), et ce que vous demandent les standards ou vos clients, vous serez peut-être amenés à faire une AMDEC à chaque étage de spécification.
Exemple :
Dois-je faire des AMDEC sur toutes les exigences de toutes mes spécifications de tout mon produit ?
Si vous ne savez pas où vous arrêter : le responsable Qualité de votre client ainsi que les textes applicables à votre Produit devraient pouvoir vous aiguiller.
NOTA : Avant de nous amuser à aller plus loin, peut-être voudriez-vous retourner aux origines des AMDEC ? Dans ce cas je vous conseille la lecture de la MIL-STD-1629.
Avec un Fault Tree Analysis (FTA), on peut affiner notre estimation de la probabilité d’apparition d’un mode de défaillance.
Il s'agit de prendre en compte non pas seulement les défaillances des fonctions, mais aussi les Facteurs Humains, pour chaque exigence Opérationnelle ou en tout cas chaque exigence du Produit où un Humain intervient à un moment ou à un autre.
Comment faire ?
En dehors des AMDEC, d'autres outils existent : HEART (Human Error Assessment and Reduction Technique) par exemple.
Les humains jouent toujours un rôle important dans le (dys)fonctionnement d’un produit : son installation, son utilisation, sa maintenance, la prévention des accidents. Négliger les humains reviendra à surestimer les performances de son Produit (Disponibilité, Fiabilité, Sécurité, Sûreté, Maintenabilité).
Les AMDEC peuvent également se faire sur les processus de Fabrication, et les moyens (de fabrication, de Support etc.) ! Toujours dans une optique de protection de l'Humain, de l'Environnement et/ou du Système lui-même.
La Sécurité d’un Système concerne la maîtrise de ses défaillances involontaires. Mais l’analyse de Sécurité et la sécurisation qui en découle doivent aussi s’intéresser à la production série du Produit (fabrication, assemblage, intégration, tests), et à sa maintenance !
Si une opération de montage en production série est jugée délicate (=risquée, avec un évènement redouté associé), alors il faut la sécuriser de la même façon que s’il s’agissait d’une fonction de notre Système directement.
Exemple :
On peut également faire des AMDEC sur un état antérieur au Système ou à ses moyens... : sur les composants qui vont le constituer (processeurs, petites pièces...) !
On y regardera les modes de défaillance classiques à ce niveau :
Des méthodes quantitatives et/ou qualitatives viennent s’ajouter aux autres pour parfaire la sécurisation de votre Système. On peut les trouver dans certains textes :
D’autres normes sont également intéressantes (plutôt orientées aéronautique, tout de même très utiles dans d'autres domaines) :
NOTA : le mot Anglais est bien « safety » pour parler de Sécurité; et non « security ». Attention aux faux-amis !
Les Best Practices des méthodes spécifiques qu'on retrouve dans les textes sont généralement les suivantes :
Beaucoup d’évènements redoutés et de barrières à mettre en place pour limiter leur non-détectabilité, probabilité d’occurrence et gravité s’identifient grâce à la rigueur et l’expérience de l’ingénieur menant l’étude.
En effet, si ce dernier a pu travailler sur des systèmes autres et profiter de retours d'expériences, s'il a accumulé plusieurs règles métiers au cours de sa carrière, et s'il a lu un certain nombre d’ouvrages pour se perfectionner… Ainsi, il sera d’autant plus efficace et exhaustif dans sa sécurisation du Système.
Faire appel à un Expert sur ces sujets est toujours utile.
Pour confirmer que tout se passe bien dans la durée (pas de dysfonctionnements graves et non rattrapés par des barrières de Sécurité), il peut être essentiel de mettre en place un monitoring de son Produit en utilisation chez les usagers.
Dans certaines industries c'est même obligatoire pour démontrer, même au bout de 10 ans d'utilisation de votre Système, que ce dernier est bien resté sous sa limite de nombre de défaillances/an qui lui était allouée par les normes en vigueur.
Ce Monitoring peut-être plus ou moins lourd, et c’est à la discrétion du/des clients, des standards applicables, et de vous :
Exemples :
Pour assurer la Sécurité de son Produit, les fonctions sécuritaires peuvent être soumises à des (auto)tests sur le Système :
La nécessité, le périmètre et la couverture de ces (auto)tests est à penser et à mettre en place dès la Conception de son Produit. Cela peut se définir pendant qu’on fait les AMDEC de Sécurité du produit (comme moyen de mitigation d'un ou plusieurs risques).
Les revues du Projet sont un bon moyen de suivre l’évolution d’un projet de manière générale. On peut donc les mettre à contribution pour également suivre la Sécurisation du Produit.
Exemple : Faire un focus particulier en séance sur le nombre d’exigences de sécurité et leur degré d’atteinte (combien seront a priori OK sur le produit ? combien sont incertaines ?)
A mesure que le projet avance, on doit voir que le Système est de plus en plus sécurisé car les exigences de Sécurité sont de plus en plus maîtrisées et atteintes.
La Sécurité est à penser dès le début du projet, et cette réflexion est à intégrer complètement dans la démarche d’Architecture Systèmes de votre projet.
La Sécurité doit être partie intégrante de la démarche d’Ingénierie Systèmes.
La vérification de certaines exigences de son Système étant complexe (comment garantir à la livraison du Système qu’il n’y aura que X défaillances sur les 10 prochaines années ?), l’appel à la modélisation, aux analogies et autres moyens de ce type sera obligatoire… Mais cela ne garantit pas que votre modèle ou votre analogie étaient bons. La Sécurisation de son Système reste donc une science inexacte… mais sera inexistante si rien n’est fait.
Rappel : l’Ingénierie Système doit prendre en compte toutes les phases de vie du Système. A savoir (liste non exhaustive) son développement, son IVVQ, sa production, son utilisation, son support et enfin son retrait de service. Oublier des phases de vie c’est oublier des exigences de Sécurité qui peuvent être cruciales pour son Système.
Il est clair qu’adopter une démarche de Sécurité pour son produit augmente le coût en conception de ce dernier : consultation d’un expert, charge de travail supplémentaire sur les exigences etc. Le chef de projet doit donc être à bord du sujet Sécurité. Il doit en être conscient et confirmer/infirmer que cela en vaut la peine.
Je termine sur cette citation :
"Doing is one thing; doing it right is a whole different story" — Aubrey Graham
Aurélien NARDINI
Un Système Sans Problème est une ressource de connaissances et de savoir-faire pratiques, avec exemples concrets.
Que vous soyez Chef de Programme, Chef de Projet, Architecte Système, Ingénieur, Manager dans l'Industrie, Etudiant ou Curieux de l'Ingénierie, vous êtes au bon endroit.
Au travers d'articles publiés régulièrement, découvrez ou révisez les Processus, Méthodes, Outils et Astuces utiles pour concevoir et piloter dans les domaines du Software, Firmware, de l’Électronique, et de la Mécanique.
Parce-qu'un produit fiable et industrialisable ne s'improvise pas !
