Dans un futur plus ou moins déjà là, une partie non négligeable du logiciel des Systèmes sera faite d’IA. Comment les Valider ? Les produire en Série ? Comment contrôler leur évolution au cours de leur vie ?
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.
Cet article suit directement un article précédent décrivant une étude de Sécurité pouvant être menée sur un système embarqué porteur d’une IA.
On considère toujours 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 chasseursRatHunter8000© sont déployés pour les détecter et les tuer via tir de fléchettes empoisonnées.
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.
Ily 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.
Dans cet article, nous traiterons de la Remontée. La Descente a déjà été traitée dans l’article précédent.
Tout ce qu’on a vu dans les articles précédents de FMDS n’est pas à jeter ! Au contraire !
Une fois la Spécification de votre produit construite, vous devez évidemment en vérifier les exigences (de Sécurité et toutes les autres) lors des phases d’IVVQ pour garantir que votre Système est bien conçu et Sécuritaire.
Ces vérifications (que ce soit, concernant l’IA, sur les hyperparamètres du modèle, son data set d’entraînement, ses sorties ou autre…) sont une étape obligée, et cela passe au préalable comme vous le savez par la rédaction de Plans de Tests.
En plus de maîtriser le processus de conception et le processus de vérification, validation, intégration, il est important de maîtriser la version du Système d’intérêt tout au long de sa vie.
La version = sa configuration logicielle + sa configuration matérielle (électronique, mécanique).
Savoir quel produit est composé exactement de quelle électronique et quel logiciel est une étape très importante pour savoir de quoi il est capable (ou non capable) et les éventuels risques associés.
Divers outils existent pour ce faire, que ce soit pour des plans mécaniques, des schémas électroniques ou des codes logiciels. Git est certainement le plus connu.
Et bien sûr, en plus de l'outillage, le process qui va autour est également important : le change control.
Des textes existent pour vous aider dans la sécurisation de vos produits :
Ces textes invitent à assurer un développement cadré, une validation complète selon le niveau de criticité d’un logiciel, afin d’avoir un Système Sécuritaire à la fin.
Bien que ces textes restent tout à fait valables dans le cadre de l’utilisation de l’intelligence artificielle, de nouveaux textes sont en rédaction spécifiquement pour les Systèmes embarquant du Deep Learning.
Si on décide d’exploiter de l’IA dans un Système, c’est certainement parce-que développer (avec un cerveau humain) une méthode déterministe est jugé trop complexe voire impossible.
Il sera donc compliqué d’être 100% couvrant lors des phases de tests du Système puisqu’il faut arriver à trouver et reproduire tous les cas de sollicitation notable d’une suite buissonnante de petites opérations mathématiques (les neurones du réseau).
Ainsi, si les tests seront de toute façon « trop légers » pour notre Système, en faire un nombre négligemment réduit revient vraiment à lésiner sur la Sécurité. Il faut en faire beaucoup, et tout azimut !
Ne pas hésiter à exploiter toute la palette des types de vérifications :
Exemples :
*Pour éviter les erreurs grossières, adopter des architecture de réseaux de neurones plus ou moins éprouvées pour le type de tache à faire (détection de chat --> des hyperparamètres ont été fixés par Google par exemple).
Comme dans toute remontée du V digne de ce nom, des tests doivent être faits depuis les plus petits composants du Système (fonctions logicielles unitaires, cartes électroniques, …) jusqu’au Produit complet inséré dans son environnement opérationnel avec ses utilisateurs.
Pour ce qui est de l’IA, des tests/comparaisons/moyens de se rassurer à bas niveau, plus ou moins automatisables, existent :
Ensuite, si tout est OK au niveau du dessous, il s’agit de tester le logiciel complet (avec l’IA intégrée).
Par exemple, avec des tests d’endurance où on épuise l’aléatoire (Monte Carlo). On exploration une multitude d’entrées possibles et on voit si les sorties sont bien dans le cadre qu’on s’est mis (garde fous opérationnels).
Enfin, le Système complet (Logiciel, Matériel, Infrastructures etc.) doit être dûment testé.
Si on ne tient pas les spécifications niveau IA, logiciel, sous-système ou Système : on doit alors mettre au point le produit… et reboucler sur les tests aux niveaux pertinents.
Le client doit être impliqué à 100%. Il faut qu’il ait conscience qu’une partie du Système (IA) est mise sous contrôle mais reste un élément fondamentalement non maîtrisé (une petite zone d’ombre dans une boîte blanche).
La validation doit se faire aussi sur les data qui ont entrainé notre réseau de neurones.
Les critères suivants sont à évaluer pour ce set :
Comme toujours, il faut documenter le fonctionnement du Produit, et ses résultats en tests de Validation.
Documenter les éléments suivants revêt alors une importance particulière :
Cela permettra :
Ça y est, notre Système RatHunter8000 embarquant de l’IA pour la détection et la classification de rats est développé, validé, et peut donc aller rôder dans les sous-bois pour empoisonner ces dérangeants rongeurs.
2 cas de figure :
Dans le cas n°2, il faut éviter une dégradation des performances de l’IA (et plus globalement votre Système). Le pire cas est celui du CACE (change anything = change everything) : une donnée d’entraînement supplémentaire a complètement altéré le comportement de votre réseaux.
De manière générale, le change control est très important pour un Produit. Il devient vital lorsque votre Système va évoluer au gré de ses aventures dans la cambrousse.
Un monitoring à distance du fonctionnement de l’IA et de ses nouvelles données d’entraînement acquises en vie réelle s’impose :
On est toujours dans le cas n°2 abordé précédemment : le Système RatHunter8000 évolue en poursuivant son entrainement au gré des détections et des tirs sur les rats.
La production série traditionnelle se déroule comme suit :
A priori, le Système numéro N et N+1 seront en tout point identiques (aux tolérances diverses près).
Quid de notre RatHunter8000 évolutif ?
La notion de série bat de l’aile :
On peut se satisfaire de ce mode là, où chaque Système devient indépendant… Ou alors, on peut préférer que tous les systèmes embarquent le même code strictement.
Dans ce cas-là, on peut peut-être imaginer une boucle de mise à jour collective des spécimens :
Pas sûr que ce soit la meilleure solution, mais cela limite les écarts entre les produits d’une série en les synchronisant tous de temps en temps.
Comment donc intégrer, vérifier, valider, qualifier, faire évoluer, contrôler 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.
La particularité de l’IA nécessite tout de même des méthodes et outils spécialisés pour la vérifier à bas niveau (hyperparamètres, contrôle de data set…).
Les notions de production série et de contrôle du changement au cours de la vie du Système sont challengées et nécessite d’être (re)pensées au moins un minimum. Ces questions s’anticipent dès la conception de son Produit !
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 !
