Design de systèmes sûrs

Bonjour,

Je travaille actuellement sur l’ordinateur de bord d’un véhicule automatique dans le cadre d’un projet scolaire que j’ai terminé. Je souhaite aller plus loin en améliorant mon système. Il est assez basique, j’ai une chaîne de capteurs utilisant plusieurs protocoles qui communiquent avec un micro-contrôleur de type STM32. À partir de ces données, l’ordinateur exécute sa boucle de contrôle et envoie des pwm à des actionneurs.

Mon premier axe d’amélioration concerne la sécurité. Je souhaite que mon système soit "sûr" (fail safe en anglais, je trouve l’expression plus claire qu’en français). Pour cela je me renseigne sur l’implémentation de la redondance mais à ma grande déception je ne trouve aucun livre d’ingénierie pour me l’expliquer. D’où les questions suivantes :

• Première chose à faire ce serait d’avoir plusieurs capteurs du même type au cas-où qu’un des capteurs parte en vrille. Imaginons que j’ai deux capteurs du même type. Comment ça se déroule au niveau de l’ordinateur de bord ? Je lis les deux et je prend une des deux données au pif si elles sont bonnes ? Comment définir la validité d’une donnée ?
• Deuxième chose, une redondance des ordinateurs de bord. Pareil ici, je n’ai strictement aucune idée de comment ça se passe.
• Enfin, une redondance des actionneurs, dans mon cas ce sont des moteurs donc la redondance de ce côte je ne peux pas faire grand chose, je décide que si un moteur meurt, le système est foutu.

Si vous avez des ressources (anglais ou français, peut importe) à propos de l’implémentation de systèmes fail-safe je suis preneur.

Merci pour votre aide et bon week-end.

Salut,

Le terme que tu cherches est probablement sûreté de fonctionnement ou en anglais functional safety. Dans l’automobile, la norme qui est suivie est la norme ISO 26262 (qui ne couvre que la partie logicielle et électronique, pas la mécanique). Ça peut t’aider à trouver de la documentation sur le sujet. Le mot fail safe est très vague et n’est pas forcément un mot-clé que tu veux chercher. Il y a obligatoirement des livres qui parlent de sûreté de fonctionnement. Mais pas de redondance en particulier, parce que ce n’est qu’un moyen d’atteindre la sûreté.

La première étape serait de définir ce qui ne doit pas arriver dans ton système. On appelle ça un événement redouté, et c’est ce qui gouverne tout le reste de la conception. Si tu n’as pas ça, tu ne sait pas si doubler les capteurs, les moteurs, le contrôleur est une mesure efficace.

Ce que je veux dire, c’est que tu ne dois pas prendre le problème à l’envers. Les redondances sont une solution parmi d’autres pour atteindre un niveau de sûreté et de fiabilité donné, mais ce n’est pas la seule et ce n’est pas forcément suffisant. Ça permet notamment de limiter l’impact de ce qu’on appelle des singles failures dans le jargon. Dans les voitures, on a souvent une très grosse diversité et des redondances assez importantes, mais variées et qui permettent de garder le contrôle et s’arrêter en toute sécurité. Dans les avions, on a des redondances x3 pour qu’on puisse détecter et continuer à voler avec des contrôles défaillants. Dans le nucléaire, on a de la diversité technologique, des redondances x4 sur certains systèmes, et des systèmes qui se suppléent les uns les autres.

Le chapitre 8 de Principles of Computer System Design: An Introduction couvre de manière assez générale les choix de design que tu peux faire, mais c’est peut être pas assez appliqué pour toi. Si ça t’intéresse je peux t’envoyer le pdf.

Je ne suis pas sûr qu’un livre concernant la conception de systèmes informatiques soit entièrement adapté à la conception de systèmes mécatroniques.

Bonjour Wizix;

Pour moi, Système Sûr (ou encore "système critique") et "Fail Safe", ce n’est pas exactement la même chose. Pour moi, le "Fail Safe" est une caractéristique des systèmes critiques: "Quand le système est en panne, il reste (ou se place) en condition sécurité (Safety en GB)". Mais, un systeme critique doit faire mieux que ça: son fonctionnement en cas de panne doit être maîtrisé et le taux de panne, quantifier.

Bien sûr, la redondance est une méthode qui est couramment implémentée dans les systèmes critiques, mais c’est pas la seule.

C’est d’analyser la fiabilité de tous les éléments de ta chaîne (ça s’appelle une AMDEC, en FR, FMEA en GB), à la fois le taux d’erreur et de panne. Si c’est le capteur le plus faible, en effet, il faut commencé par lui!

Aabu, lui, remonte encore d’un niveau, avec l’identification des "événement redoutés" ("Failures conditions" en GB). Quand tu parles de redondance, tu es déjà dans les solutions, quand tu es dans l’identification des failures conditions, c’est encore la faisabilités de ton système que tu analyse. Mais, c’est vrais qu’il faut sûrement commencer par là: "Si une fonction de mon système n’est pas remplis, quel est l’effet ?" par exemple: "Fonction: Le moteur entraîne la roue. Événement redouté: Panne du moteur qui se bloque. Effet: la voiture va dans le décore, quoi que fasse le conducteur!", événement critique!, il faut lui donnée une probabilité acceptable (on voudrait dire Zéro, mais on n’y arrivera pas, alors en accord avec les réglementations on va dire 1 fois sur 1 000 000 000 heure de conduite [je ne suis pas dans le domaine, je ne sais pas si c’est crédible]). Et ensuite on va définir l’architecture pour pouvoir tenir ce chiffre (Par exemple, sur la roue, pour pas qu’elle se bloque on va mettre une pièce avec une fragilité pour qu’elle se casse si le moteur se bloque). [PS: je ne connais pas le milieux des voitures, mes exemples sont sûrement farfelu!]

Ou alors d’avoir des capteurs de modèles différents, comme ça, si l’un des deux a une faiblesse ou un bug, le second lui ne l’aura pas.

Euh … comme ça dans le vide, c’est pas facile à trouver une solution, mais: 1) tu peux avoir des capteurs qui te donne leur "état de santé" ou un "facteur de qualité" en plus de la valeur mesurée. Dans ce cas tu choisies la meilleur. 2) tu peux aussi comparer les valeurs des 2 capteur, et si elles sont trop différente, tu indiques au chauffeur que tu te déconnectes et lui laisse faire le boulot. 3) Tu peux mettre 3 capteurs, et rejeter la mesure la plus éloignée des 2 autres, 4) …

Là aussi, pas facile dans le vide, … Mais là aussi, il y a des méthodes. Une parmi d’autre: une architecture Com/Mon (Com pour "commande", Mon pour "monitor" : 2 processeurs qui font le même job, le premier fournie les commandes à ton moteur, et le second, lui ne fait que comparer ce qu’il a calculé et ce qu’a calculé l’autre processeur Com, et si c’est différent, il décide de déclarer le Com en panne, et de débrailler le moteur associé.

C’est là pour moi, que tu dois trouver des moteurs "Fail Safe". Si tu mets de la redondance sur les moteurs (car ton AMDEC te le demande!), il faut qu’ils se débraillent en cas de pannes, ou … Enfin, pas facile de parler dans le vide. "Le système est foutu!", facile à dire, mais que va-t-il se passer, si tu est à 130km/h sur autoroute dans un virage, alors que tu doit freiner d’urgence ? Ca bloque une roue, .. et tu vas dans le décor! …

Hélas, je ne connais pas de livre qui parle des méthodes, … Je travail dans l’Avionique, et dans mon milieux, c’est l’expérience qui est la base. Il y a des normes sur les obligations réglementaire (c’est à dire "légales") (La D0178C du RTCA pour les SW, la DO254 du RTCA pour le HW et l’ARP 4754A du SAE pour les systèmes) mais c’est payant, c’est de l’assurance qualité, et pas de la technique. Par contre c’est peut-être des mots clef sur internet. Mais, en effet, comme le dit Aabou, recherche dans le domaine de la SdF, connue aussi sous les termes: science des pannes.

Il y a encore deux ou trois subtilités, mais déjà, j’espère que tu te rends compte d’où l’on en est:

2 chaînes redondantes, avec chacune :

• un calculateurs architecture Com/Mon (Ca fait 4 processeurs/RAM/FLASH/Acquisition/Sorite),
• 2 capteurs par chaîne (4 en tout)
• un moteur avec système d’auto-débraillement (2 en tout)
• Éventuellement 2 capteurs pour vérifier que le moteur n’est pas en panne et tourne (?)
• Un système "Fail Safe" qui surveille l’alimentation électrique (Si l’on est sur l’autoroute à 130 KM/H, que la batterie se met en court-circuit, et que nos 2 chaînes sont OFF, que se passe-t-il ? Y a t il un événement redouté ?)
• …

(Je suis d’accord, c’est sûrement beaucoup trop, pour ton système, Je parle dans le vide, …) Tu te rends compte que ton projet prends une nouvelle ampleur ! Quand on développe des systèmes critiques, (pour le nucléaire, le ferroviaire, l’aérien, l’automotive, voir le médical) on change de dimension.

En tout cas, tu me surprends: C’est pas courant qu’un scolaire se pose ce type de questions. Bravo! les système critiques, ça peut être un boulot super …

Bon aller, je te taquine maintenant … tu as oublié quand même une chose : Es-tu sûr que le hardware que tu utilise et que le logiciel que tu as développé ne sont pas buggé ? Il fonctionne comme espérer dans absolument tous les cas ? …

Bien cordialement.

PS: Il y a même une formation sur OC, je ne sais pas ce quelle vaut, …

J’ai l’impression qu’on a beaucoup parlé de théorie. Se poser des questions sur la sûreté est très bien ; les systèmes qui nous entourent doivent répondre à des exigences de sûreté de fonctionnement de plus en plus fortes, parce qu’on ne tolère plus certains risques.

Dans le cadre d’un projet scolaire, faire une analyse simple de ton système me paraît déjà quelque chose d’assez valorisant. Quand je parle d’analyse simple, c’est d’analyser par exemple les conséquences des défaillances des différents éléments de ton système, afin de juger de son adéquation avec les objectifs de sûreté que tu pourrais te fixer. Dans l’automobile (et ailleurs), on considère comme très grave quelque chose qui tue des gens ; en général, les événements les plus graves sont, en gros, la perte de direction, la perte de freinage, et les accélérations inattendues.

Si tu veux t’inspirer d’une méthode existante, je te conseille de te renseigner sur l’AMDEC (analyse des modes de défaillances, de leurs effets et de leurs criticité). L’idée grossière de cette analyse est, pour chaque élément du système, de déterminer comment ils défaillent (les modes de défaillance), comment cela affecte la fonction qu’ils remplissent (les effets), et la gravité de l’effet (la criticité)

Je suis d’accord avec toi Aabu.

Mais, je pensais, étant donné que l’année scolaire est finie, que notre ami Wizix souhaité en savoir plus justement sur les systemes critiques, et pas forcément pour son projet uniquement. C’est pour ça que j’ai essayé de lui montrer la complexité … mais aussi, l’intérêt!

Cordialement.