Système embarquant une IA : Étude de Sécurité

La Sécurité est la lutte contre les dysfonctionnements anormaux et involontaires d’un Système, provoquant des dommages au Système lui-même, à son Environnement ou à la Personne.

Les dysfonctionnements peuvent provenir du moindre élément non maîtrisé du Produit que l’on conçoit. Si on a une brique logicielle d’Intelligence Artificielle (modèle entraîné sur dataset et qui oui/non s’entraîne en continu) alors il y a un certain degrés de non maîtrise !

Connaissez-vous la valeur de tous les poids et biais des neurones de votre réseaux de neurones ? Et quand bien même, savez-vous interpréter clairement leur rôle respectif dans l’output de votre modèle de Deep Learning ?

Dans cet article je vais prendre en tant qu’exemple d’IA les réseaux de neurones (machine learning / deep learning) pour la Vision, en exploitation dans des Systèmes Embarqués. Je les désignerai « IA » tout court ensuite.

Considérons l’exemple semi-humoristique suivant pour notre étude :
2030. Les rats sont devenus trop nombreux en ville et aux abords des villes. Des essaims de drones chasseurs RatHunter8000© sont déployés pour les détecter et les tuer via tir de fléchettes empoisonnées.

Pertinence de l’Ingénierie Système

Un logiciel qui fait de l’IA reste un logiciel, et il s’insère dans un système complexe (avec de l’électronique, de la mécanique etc.) éventuellement en embarqué pour répondre à un Besoin.

Ainsi, la vision Système et les process et méthodes d’ingénierie qui vont avec (Cycle en V hybride, notamment mais pas que) sont toujours pertinents.

Le fait qu’une brique de notre Système soit de l’IA ne change pas le fait qu’on a un système complet à créer et faire performer selon le Besoin attendu.

Dans notre exemple RatHunter8000© : on peut imaginer que la partie logicielle chargée de détecter un animal et le classifier ou non comme un rat soit opérée par une AI (réseau de neurones : couches de convolution et couches denses).

Il y a 2 grandes activités pour gérer la Sécurité, comme pour un Produit sans IA, correspondant peu ou prou aux 2 grandes phases du V : la descente et la remontée.

La Descente (activités majoritairement indirectes) : on étudie la Sécurité pour anticiper les garde-fou nécessaires, on s’assure de mettre en place ces barrières pour mitiger les risques et d’avoir une architecture Système qui tienne les performances demandées.

La Remontée (activités majoritairement directes): on intègre, vérifie, valide, qualifie pour s’assurer que tout fonctionne comme l’attendu et que les anticipations qu’on a réalisées lors de la descente du V ont effectivement permis de gommer les problèmes éventuels.

Dans cet article, nous traiterons de la descente. Nous verrons la remontée dans un prochain.

Méthodes classiques à conserver

Tout ce qu’on a vu dans les articles précédents n’est pas à jeter ! Au contraire !

AMDEC

Faire des AMDEC reste valable : cet outil permet de faire apparaître les évènements redoutés (les risques) que vous devez mettre sous contrôle.‍

Exemple de risque avec RatHunter8000©: Le drone confond un rat avec un humain et tire sur ledit malheureux.

J'ai choisi ce risque car il implique l'IA et c'est ce qui nous intéresse ici.

J’ai noté la probabilité à 3/4: elle est non négligeable. Admettons que vous ayez fait des simulations avec votre modèle d'IA et vous voyez que votre réseau de neurones peut se tromper 1 fois toutes les 1000h de vols en considérant un taux de rencontre moyen de X rats/heure. Si vous avez 10 drones qui tournent 24h/24 en forêt, cela donne 1,7 mort/semaine !

‍Non détectabilité : En l’état on n’a rien pour que ce soit détectable. La seule détection viendrait du fait qu'un promeneur trouve l’humain décédé avec une fléchette plantée… Ce qui est un peu tard !‍

Conséquence : il y a mort d’Homme ! Ce n’est pas acceptable.

Etant donné l’importance de la chose, vous décidez qu’il faut jouer sur les 3 leviers à la fois pour mitiger le risque.

Je reviens sur l’AMDEC dans l’étude de sécurité plus bas.

Fault Tree Analysis (FTA)

Pour maîtriser ce que vous faites dans la mitigation de la Probabilité d’occurrence (et dans la recherche de Cause également), les Fault Tree Analysis seront d’une grande aide !

Un FTA vous permettra de vous donner des objectifs de Sécurité pour l’évènement redouté global ainsi que pour les items le décomposant, et de vous conforter dans le fait que vous limiterez la probabilité d’occurrence du risque considéré.

C’est un outil qui a toute sa place quand on traite avec de l’IA dans un système/produit !

Je reviens sur le FTA dans l'exemple un peu plus bas.

La Spécification et l’Architecture

IA ou non, une spécification est toujours utile pour ne rien oublier au cours du développement (interfaces, performances), anticiper les problèmes et prévoir les tests d’IVVQ.

Une fois identifiées les barrières pour la mitigation des risques, il est nécessaire de les inclure dans les exigences de votre Produit, qui devient alors Safe-by-Design.

Et puisque c’est de Sécurité dont il s’agit, les exigences liées à ces leviers de mitigation doivent être taggués et déclinées comme « exigences de Sécurité ». Cela permet de faire un focus particulier sur ces dernières car on sait l’enjeu qu’il y a derrière.

D’autres exigences peuvent également être considérées pour ce qui est du spécifique aux convolutional neural networks utilisés en computer vision :

• Des contraintes sur les datasets que vous allez utiliser pour entraîner l’algorithme de vision pour repérer les rats en toutes conditions et les classifier correctement
• Des contraintes sur le modèle lui-même (régularisation L1/L2…)
• Des contraintes sur le choix des hyperparamètres

A ne pas négliger, la traçabilité des exigences (le fait de rattacher chaque exigence à une exigence mère qui en est la source) est un moyen très pratique d’avoir une justification de pourquoi telle exigence est là. Cela s’avèrera très utile quand vous serez face à une exigence que vous aimeriez ne pas suivre parce-qu’elle vous challenge… !

Enfin, l'assurance de la couverture des exigences entre elles (toutes les exigences donnent lieu à des exigences filles, sauf celles qu’on a explicitement désigné comme à ne plus décliner), et des exigences par les tests (chaque exigence est associée à un test en regard) permet d’être sûr de n’avoir rien oublié dans sa conception.

Etude de Sécurité du Système embarqué avec IA

Reprenons notre AMDEC ci-dessus. Nous avons décidé de jouer sur les 3 leviers à notre disposition pour mitiger le risque lié au tir sur une cible qui ne soit pas un rat.

Comme mitigation, on se rappelle qu’on doit :

• Soit supprimer le risque (l’IA est-elle réellement utile pour cette fonction ? Ne devrais-je pas la faire porter par quelque chose que je maîtrise mieux ?)
• Soit le réduire (sa probabilité d’occurrence ou la gravité de ses conséquences)
• Soit faire en sorte que les gens concernés soient au courant qu’il y a un problème (alarmes...)

Probabilité avec FTA (« Contracts »)

Considérons qu’après mûre réflexion avec les autorités compétentes, le taux de défaillance (la probabilité du risque que RatHunter8000© tire sur une personne) acceptable socialement et économiquement soit de 10^-7/heure de vol.

Soit 1 tir de fléchette sur un Humain tous les 10 millions d’heures d’opération de drone.

On peut dire au passage que c’est du DAL B (Design Assurance Level catégorie B, si on veut faire le lien avec la DO-178) :

Cela devient un objectif à tenir. Une spécification système, entendue soit avec le Client soit avec les Autorités compétentes (soit les 2).

Etant donné notre architecture Système, le FTA lié au Risque étudié est le suivant :

En effet, ce qui peut raisonnablement causer le risque est :

• Une mauvaise classification de la cible par le modèle d'IA (classifié Rat alors que c’était un Humain ?)
• Une défaillance de la caméra qui enverrait des données pixels fausses (défaillance électronique) ? Pour l'exemple, je considère que quand la caméra commence à mourir son flux vidéo erratique présente un risque quasi sûr d'amener à un tir non contrôlé sur un humain.

D’où la forme de mon arbre pour ce risque-ci.

J’ai quantifié les différentes feuilles de mon arbre comme suit :

• La caméra que j'ai choisie a dans sa Datasheet constructeur 6,67*10-5 /h comme taux de défaillance si j'inverse le MTBF donné. Vous noterez que je considère MTBF comme le MUT ici (je néglige le temps de réparation, disons que le drone est conçu pour que ce soit facilement réparable).
• Pour le SW IA : je reprend le Retex pris en hypothèse en début d’article (10-3) /h.

Bon, on voit qu’on ne peut pas tenir l’objectif de 10^-7 avec ce Système…

Quelles solutions s’offrent à nous ? Comment modifier notre Système pour rentrer dans les clous de la Sécurité ?

Etant donné les taux de défaillance côté électronique et logiciel, ainsi que le OU qui les relie (OU=Somme) on est obligés de jouer sur les 2 métiers (électronique et logiciel).

Contraindre davantage la partie IA ? C’est celle qui nous pénalise le plus ! Supposons qu'on ne peut pas la contraindre, qu’on est déjà au meilleur effort dessus. Alors imbriquons-la dans un module software qu’on peut, lui, contraindre et qui aura une vraie influence sur le comportement global du logiciel !

Idées :

• ‍‍Lorsqu’un rat est en la ligne de mire, faire 5 classifications d’image a 1s d’intervalle de cette même cible en réalisant un hippodrome dans les airs, et si les 5 classifications donnent plus de 99% « Rat » alors on autorise le tir. C’est le principe du vote a l’unanimité avec un fort taux de certitude. Le logiciel opérant le vote sera développé au niveau DAL B.
• Mettre en œuvre en parallèle une méthodo classique de vision par ordinateur (comparaison d’histogrammes du type LBPH) et n’autoriser le tir que si les 2 classifications concluent à un Rat à 99% minimum ?
• Embarquer un micro directionnel sur le drone, qui en parallèle de la vision viendra écouter les bruits du mammifère en ligne de visée pour voir si les couinements usuels d’un rats sont bien là ? Ce qui permet de profiter au passage de 2 voies d’acquisitions de cibles différentes

‍

La caméra est problématique également… Mettons en 2 en redondance chaude, les 2 flux vidéo seront comparés pour vérifier que les flux sont OK ?

Attention : Cela impacte peut-être le processeur à embarquer… Et la consommation électrique du tout… Et la taille/techno du stockage d’énergie...

‍

Partons sur les solutions suivantes :

• Redondance chaude des caméras
• Encapsuler la partie IA dans un code qui vient exploiter un système de vote (5 voix) de ce même algo selon différents angles de vue avant tir. Et ce code sera développé en niveau DAL B, pour satisfaire à l’objectif 10^(-7) défaillance/heure de vol. Avec une relation en « ET » vis-à-vis de l’IA, le tour devrait être joué.

Voilà ce que donne notre nouvel arbre :

NOTA : on aurait pu considérer que faire 5 votes revienne à mettre la probabilité de dysfonctionnement du modèle IA à la puissance 5, donnant une proba de en 10^(-15). Je préfère ne pas risquer l’excès de confiance et ne pas trop jouer avec les chiffres. Restons en 10^(-10).

Il semble qu’avec ces modifications d’architecture on puisse tenir la Probabilité souhaitée ! Grâce à ce FTA, nous avons vu comment modifier l’architecture du Système pour réduire la probabilité d’occurrence du risque à un niveau acceptable (garde fous). Cela donne également des objectifs clairs et atteignables à vérifier et valider lors des phases d’IVVQ. A noter qu’on a aussi changé l’Opérationnel du Système (faire un hippodrome et 5 prises de vue au-dessus de la cible avant le tir).

Si on ne tient pas la performance attendue : on modifie le produit… et on reboucle... Jusqu’à ce que ça passe (ou alors le client accepte de relâcher ses objectifs de Sécurité?)

‍

Quelles autres barrières auraient pu être employées pour diminuer la probabilité du Risque ?

• Diminuer drastiquement le taux de défaillance du modèle de reconnaissance visuelle des rats (mieux maîtriser les performances de l’IA --> on a considéré ci-dessus que ce n'était pas une voie à emprunter)
• Choisir de meilleures caméras (meilleur Mean Up Time)
• Utiliser RatHunter8000© uniquement la nuit (en supposant que moins d’êtres humains se baladent en pleine nuit). Ce qui pousserait à changer les caméras pour des modèles IR ? 
• Utiliser RatHunter8000©  uniquement dans des zones où les Humains sont peu nombreux
• (Ne pas utiliser de drones pour cette mission de dératisation mais de la bonne vieille  mort-au-rat… Le risque est carrément supprimé)
• Etc.

‍

Le fait de se contraindre à des performances précises pour chaque sous-système (ici les sous-parties logicielles, et la partie Caméra) est une méthode qui a fait sa preuve avant l’IA, et qui est toujours utilisée aujourd’hui par plusieurs sociétés telles que Boeing, Sierra Nevada, la NASA etc. y compris sur des Systèmes dans lesquels l’IA porte des fonctions critiques (gestion de l’atterrissage, évitement d’obstacles en vol, …).

Ces sociétés parlent de« Contracts » pour les performances que chaque brique doit tenir.

Je n’ai rien trouvé de probant comme information à ce sujet du côté de chez Tesla. Je pense qu’ils doivent traiter le problème de manière similaire ?

Ce papier évoque le sujet des Contracts et de leur vérification :

Non Détectabilité

Comme nous sommes de fins limiers, nous allons considérer que l’effort de mitigation via la probabilité n’est pas suffisant et allons également jouer sur la détectabilité du risque.

Que pouvons-nous imaginer pour augmenter la détectabilité de ce problème ?

Idées :

• ‍‍Un opérateur Humain contrôle à intervalle régulier quelques images prises des sujets pris pour cible et ayant mené à un tir (vérification a postériori permettant d’éventuellement corriger le SW)
• Assurer la testabilité des éléments de sécurité : PBIT/CBIT pour tester que les parties IA et caméras sont fonctionnelles (critère d’évaluation à définir : entrée type et check des sorties) avant de démarrer le Système ou pendant son fonctionnement.
• Alarme sur une fréquence audible seulement par l’Homme et non par les rats avant un tir ? De manière à l’avertir que la foudre va tomber… Cela dit si tous les drones se mettent à siffler lorsqu’ils tirent, ça va être le bazar…

Gravité

Enfin, pour vraiment blinder notre Produit contre le dysfonctionnement considéré (et notre dossier de certification par la même occasion), on décide également de jouer sur la gravité du dysfonctionnement, sur ses conséquences.

Idées :

• ‍‍Ne mettre sur les fléchettes qu’une dose de poison léthale pour petits rongeurs et non pour l’Homme ?
• Avoir plusieurs fléchettes embarquées, dont un type moins dosé pour les cas de classification litigieux ?

‍

Propriétés allouables spécifiquement aux modèles IA

En supplément du taux de dysfonctionnement, de la détectabilité et de la limitation de la gravité, on peut allouer d’autres exigences de performances aux parties IA de notre Système (d’autres « Contracts ») afin de se rassurer sur la confiance qu’on peut accorder au modèle, ses hyperparamètres (nombre de couches de neurones, fonction d’activation etc.), ses poids, ses biais :

• Accountability : le fait que l’IA soit tenue comme responsable de ses actes.

Exemple : identifier clairement que la décision de tir du RatHunter3000 a pris corps dans le modèle de Machine Learning utilisé.

• Controllability : le fait qu’un Humain puisse intervenir dans le fonctionnement pour le modifier, sécuriser, …

Exemple : mettre en place le système de 5 votes exploité ci-dessus dans cet article.

• Explainability : le fait qu’un code IA puisse afficher la raison derrière son output

Exemple : Pourquoi j’ai noté comme 99,9% Rat un être Humain et lui ai donc envoyé une fléchette. Quels ont été les principaux facteurs qui m’ont convaincu que c’était un Rat ?

• Interpretability : le faut qu’un humain puisse comprendre la raison derrière l’output de l’IA

Exemple : si le modèle m’explique qu’il a envoyé une fléchette sur Mamie à cause du poids n°37 et du biais n°22, cela ne va pas m’aider à comprendre réellement (ni que faire pour corriger ça).

• Transparency : le fait de pouvoir recréer et comprendre le cheminement qui, à partir d’un input donné, crée l’output sorti par l’intelligence artificielle.

Exemple : je peux décrire le cheminement des données de chaque pixel du flux d’image, voir quelles sont les features appliquées par les couches de convolution, et comment les sorties de ce réseaux sont exploitées dans le réseau dense… Jusqu’à donner une classification de la bêbête en ligne de mire.

• CACE (à éviter) : Change Anything, Change Everything. Comportement à éviter dans une IA, qui pour une mini variation d’un paramètre sort des résultats complètements différents.

Exemple : si le Rat observé n’est pas de la taille habituelle (à 5cm en longueur de queue près), on passe de 99% de probabilité que cette cible soit un Rat à 10%. Des concepts existent pour jouer là-dessus : La régularisation L1/L2 par exemple (pour éviter l’overfit et adversary outputs).

Voir cet article dont je tire ces possibles exigences de performance.

C’est un peu vague comme exigences à allouer à un code d'IA ?

Oui, il est nécessaire de décliner chaque propriété en ce qu’elle signifie pour nous et notre Système, puis mettre en place les exigences/règles à suivre en interne (logs, sondes logicielles, …) pour les réaliser.

Que disent les organismes de standardisation sur l'intégration de l’IA ?

De nouveaux textes sont en préparation… Mais n’existent pas encore tout à fait !

Les organismes de standardisation IEEE, ISO et SAE planchent actuellement sur le sujet de comment bien gérer la Sécurité et la Validation de Systèmes dont l’IA réalise une fonction importante voire critique.

• ISO : un working group est en place --> ISO/IEC JTC 1/SC 42
• IEEE : IEEE P7009, “Fail-Safe Design of Autonomous and Semi-Autonomous Systems” fait partie des 1^ers standards (en écriture)
• SAE : un comité en est place et a commencé à sortir des textes intéressants → SAE G-34

Quelques mots pour conclure

Comment donc concevoir un Système dont l’une des parties critiques est portée par une IA ? De manière très similaire à ce qu’on connaît déjà.

Si une brique de notre Produit est une IA, cela reste une brique : on identifie les risques, on les mitige, et on s’assure de tenir les performances via des méthodes particulières de développement, et via vérifications et validations complètes à la fin du Développement.

Si on n’est pas satisfait du fonctionnement du Système, on reboucle sur sa spécification, sa conception, son développement, IVVQ… jusqu’à ce que soit satisfaisant (que le contrat soit rempli).

Dans l’étude de Sécurité présentée, je considère qu’on peut toujours entraîner davantage la brique IA de détection et classification pour augmenter sa Sécurité ; cela dit ce n’est pas le levier de mitigation que je préfère activer pour limiter la probabilité d’un problème. On risque en effet le surentraînement et les ressources (temps, €, infrastructures) demandées peuvent être rédhibitoires. Je préfère simplement aller au plus court : accepter le fait que l’IA considérée est défaillante, et faire en sorte que ces défaillances soient assez contrôlées par ailleurs pour devenir assez rares ou acceptables.

Aurélien NARDINI