Conférence de Gireg Lanoë – machine learning et diagnostic moteur

Retranscription de la conférence

Yves Français, PSA

[00:00] Bonjour à toutes et à tous. Yves Français, chef de projet innovation au sein du groupe PSA.

Aujourd’hui, nous allons vous parler d’aide au diagnostic et plus particulièrement des équipes d’assistance qui jouent un rôle extrêmement important. Les équipes d’assistance, ce sont elles qui viennent en soutien des concessionnaires ou des garages lorsque des clients, parfois vous, ont quelques difficultés pour identifier l’origine d’une panne. L’objectif est de rendre plus efficace et plus autonome ces équipes d’assistance. Ils ont un deuxième rôle extrêmement important, c’est qu’ils peuvent être en relation directe avec les fournisseurs de pièces ou de composants, mais aussi en relation avec les centres techniques de R&D, donc les spécialistes et les techniciens. Ce que l’on a cherché à faire est de les rendre plus autonomes. C’est-à-dire, un peu comme le disaient nos collègues de la SNCF, c’est de capitaliser sur l’expertise des équipes techniques en créant une boîte à outils et en livrant des outils qui leur permettent d’être plus autonomes, donc moins solliciter les spécialistes et les experts du centre technique et être aussi plus efficace lorsqu’ils interviennent auprès des concessionnaires et des garages. Ce travail a débuté il y a trois ans, de manière un peu embryonnaire. Et de manière un peu plus concrète, il y a deux ans, avec nos collègues d’Acsystème. Et aujourd’hui, quelques outils sont opérationnels auprès des équipes d’assistance. Je vais laisser la parole à Gireg Lanoë d’Acsystème pour présenter le sujet.

Gireg Lanoë, Acsystème

[01:22] Bonjour à tous, Gireg Lanoë. Je suis ingénieur d’études chez Acsystème. Je vais vous présenter le sujet avec en première partie une présentation du problème, du contexte, l’étude qui a été réalisée avec Matlab, Simulink, les outils qu’on a déployés pour aider PSA et enfin la conclusion.

La première partie : le contexte, c’est le diagnostic ! Qu’est-ce que c’est le diagnostic ? Sur un moteur, on a des consignes qui sont envoyées par le conducteur, c’est-à-dire qu’il accélère, il freine, il passe les rapports. Le diagnostic : le moteur, lui, reçoit des messages des capteurs. Et le diagnostic consiste à analyser les potentielles incohérences qu’on peut avoir entre ce qui a été envoyé, ce qui est demandé au moteur et ce que le moteur réalise réellement. Et si on a un écart en fonction de la gravité du défaut, on aura différents types de voyants qui pourront s’allumer sur le tableau de bord et qui seront également visibles en concession. L’enjeu pour le diagnostic moteur, c’est de réduire le nombre de déposes en service après-vente, notamment dans les phases de garantie. L’intérêt est clair pour le constructeur puisque dès qu’on est capable d’identifier la panne, on va être capable de réparer le bon composant et donc faire une intervention rapide. Et également la satisfaction client : si le client a besoin de faire plusieurs allers-retours avec le garage, on peut penser que la satisfaction va baisser. Donc tout l’enjeu, c’est d’améliorer la qualité des diagnostics moteurs, avec notamment une identification plus précise de la source, de façon à réduire le temps d’intervention et un bon compromis de détection. C’est-à-dire qu’une méthode de détection, ce sera toujours un compromis entre de la non-détection et de la fausse anomalie. La non-détection, le risque, c’est qu’on ne détecte pas le jour où le composant casse : « On est arrêté sur le bord de la route ». Et la fausse anomalie, elle, à l’inverse, elle va faire ce qu’on appelle « l’effet sapin de Noël ». C’est-à-dire que sur le tableau de bord du véhicule, le voyant va s’allumer de manière intempestive alors qu’en réalité, il n’y a pas de défaut.

“Tout l’objectif d’une bonne méthode de détection, c’est de converger vers le « Graal ». C’est le zéro fausse anomalie et le zéro non-détection, tout en sachant qu’y arriver ce serait très optimiste.”

Gireg Lanoë, Matlab Expo 2018

[04:15] Le diagnostic, tel qu’il existe aujourd’hui, il est généralement basé sur l’observation d’un seul critère. C’est-à-dire que généralement, cela va être l’observation d’une tension, d’un écart de boucle de régulation… Et il peut être complexe à calibrer. Généralement, on ajuste un seuil sur une monovariable, plus un anti-rebond, qui fera qu’on attendra que le défaut soit présent un certain nombre de secondes pour valider le défaut et le remonter au client. Donc, on a à la fois, si ce seuil est mal calibré, un risque de non-détection ou de fausse anomalie, et, avec cette analyse mono critère, on a des difficultés à qualifier certains types de défaillances et orienter précisément vers la cause de l’alerte du client. Le constat au moment où on a récupéré le sujet avec PSA, c’était qu’il était possible d’avoir une autre approche du diagnostic, notamment en utilisant plus de signaux, et par la création de modèles qu’on a appelé entre nous des modèles experts pour détecter. Et ensuite, intervient la mise au point de ces modèles experts par une analyse en portrait de phase que je vais vous présenter.

[05:38] Le portrait de phase, c’est quoi ? C’est de se dire qu’au lieu d’observer juste une variable en fonction du temps, on va observer deux variables, l’une en fonction de l’autre et voir si on arrive à identifier visuellement une forme. C’est l’objet du graphique qui est à gauche : là où on a un nuage de points en bleu et un nuage de points en rouge (voir slide ci-dessous). Le nuage de points en bleu étant la répartition nominale et en rouge un essai en défaut. Quand on a récupéré le sujet de PSA, l’objectif, c’était dans un premier temps de créer un outil qui était capable, à partir de signaux (3 maximum), d’identifier trois signaux qui pouvaient permettre de détacher une forme nominale et de bien identifier un nuage de points en défaut dans cette même représentation sur trois axes. Tout l’objet de l’analyse expert dont je parlais juste avant, ce serait de créer un Simulink qui viendrait créer des frontières pour encadrer le nuage bleu, et ainsi, si l’on est au-delà de ces limites, on remonte un défaut. Ça, c’était la première approche.

[07:14] La seconde approche a été de passer à une approche de machine learning. C’est-à-dire qu’au lieu de travailler à la main, apprendre automatiquement le nuage nominal et les points en défaut. On a donc mis en place une démarche de machine learning avec une première étape qui a consisté à la création d’une base de données. À partir des essais, identifier quelles étaient les zones des essais où on avait le défaut. Il y a quand même un travail d’expert à faire au préalable. La seconde partie, qui était l’apprentissage avec le choix des entrées observées via l’interface en portrait de phase qu’on a pu voir avant, l’apprentissage avec différentes méthodes que je vais présenter après, puis la calibration du seuil qui va permettre de gérer le compromis entre fausses anomalies et non détection. Et ensuite, une troisième étape de la démarche, c’est la génération de rapport et l’analyse des taux de bonne détection / fausse alarme pour juger de la pertinence ou non d’une méthode de détection.

[08:23] Les méthodes de détection qui ont été étudiées, elles ont été faites par complexité croissante et on a d’abord fait les arbres de décision qui sont une succession de seuils pour arriver à une décision, les polygones convexes englobant, les réseaux de neurones, les mélanges de gaussiennes, le support vecteur machine, et tout cela avec Matlab, avec l’utilisation des toolbox Statistic and Neural Networks. Et la petite surcouche qui a été apportée par Acsystème, c’était d’adapter pour avoir des visualisations qui permettent un peu plus de compréhension dans la limite de deux entrées. Donc là, c’est une illustration des différentes méthodes qu’on a pu tester (voir illustration ci-dessous). La première, en haut à gauche, ce sont les arbres de décision couplés à une analyse en composantes principales afin d’avoir des axes qui ne sont pas parallèles aux axes des deux entrées sélectionnées et une analyse par les polygones englobants. Si on est dans le polygone rouge, on dit qu’on n’est pas dans le polygone bleu, donc on est en défaut. Si on est dans le polygone bleu, on est en nominal.

[09:33] Ensuite, on a testé une approche par réseau de neurones, mélange de gaussienne et super vecteur machine. L’idée, ici, c’est que pour chaque point du plan, on est capable de donner un score. Là, l’hypothèse qu’on avait, c’était que s’il est négatif, c’est qu’on a plutôt tendance à être sur un point nominal et s’il est positif sur un point, c’est qu’il est en défaut. Les tests et validations, ce que cela a donné, c’est qu’on a plutôt retenu une solution avec les réseaux de neurones et les mélanges de gaussiennes parce qu’ils permettent un bon compromis avec la performance et l’embarquabilité. En sachant que le critère premier, c’est que le nombre de paramètres doit être fixe, pour un réseau de neurones, une GMM, de sorte que si l’on génère un Simulink, on n’a pas besoin d’y retoucher. On fera uniquement de la modification de paramètres. On a mis en place une interface qui permet de faire la calibration des seuils de façon à choisir, en fonction du choix de PSA en l’occurrence, ce qu’ils voulaient en termes de fausse anomalie et de non-détection et choisir la méthode qui l’intéressait. C’est ce qu’on peut voir sur le graphique de droite où on a en orange le résultat d’une méthode mélange de gaussienne et en bleu les réseaux de neurones (voir illustration ci-dessus). Avec les résultats de ces tests, on a constaté que le résultat était plus performant que l’homme. C’est-à-dire que dans certains cas, on avait indiqué que les défauts n’étaient présents qu’à certaines zones, et finalement, on s’est rendu compte en repassant ce même essai que la méthode nous disait : « Non, ici, il y a un défaut, et ici aussi, il y a un défaut ». Et effectivement, quand on le regardait avec l’œil de l’expert, on était capable de se dire « ah oui, effectivement, il y a bien un défaut qu’on n’avait pas identifié précédemment ».

[11:35] En termes de déploiement des outils, on a développé deux outils pour PSA. Un premier qu’on a appelé « outil concepteur expert » qui permet de faire l’analyse des défauts, créer des nouveaux modèles de détection et également faire la notation des essais. Objectif : faire tout le processus du machine learning : annoter, apprendre et régler le seuil. Et une fois que la méthode est satisfaisante aux yeux de l’expert, la stocker dans une base de données de défauts pour faire de la capitalisation. L’objectif de cet outil, c’est bien d’être utilisé par un expert qui a l’œil métier, qui est capable d’analyser les essais en amont. Le deuxième outil est un outil plutôt « utilisateur novice » qui permet, à partir de la base de données qui a été créée par le premier outil, et d’essais qui ont été réalisés sur GMP, d’avoir une checklist des défauts et des suspicions de défauts qu’il pourrait y avoir sur le moteur qu’il vient de tester. Donc ça, c’est plutôt pour une utilisation en service après-vente.

[12:43] Pour ce projet, on a choisi la solution Matlab parce qu’on a été capable, face à l’absence de licences Matlab sur tous les PC, de générer des outils en « .exe » de façon à les utiliser sur n’importe quel poste. On a, côté Acsystème, automatisé la procédure de compilation, c’est-à-dire qu’on a créé un script qui vient choisir les bons fichiers et générer automatiquement le « .exe ». L’intérêt, c’est qu’on a pu être très réactif avec PSA dans la phase de débogage. Dès qu’ils constataient un problème dans le code, ils nous faisaient le retour et on pouvait livrer très rapidement un nouveau « .exe ». Un autre intérêt, c’est la génération de modèles Simulink, parce que les spécifications, telles qu’elles sont réalisées chez PSA et chez les constructeurs d’une manière générale, sont sous Simulink. Ce qui est pratique avec les réseaux de neurones notamment, c’est la possibilité directement avec la Neural Network Toolbox de générer le Simulink qui correspond au réseau de neurones qui a été appris. Pour les GMM, nous n’avons pas eu le temps de le faire, mais on sait que c’est codable. Ce qui est également intéressant, c’est la prise en compte de contraintes. C’est-à-dire que si PSA a des exigences, par exemple sur du nommage ou sur du formalisme représentatif des Simulink, on est capable de faire du code pour que les Simulink générés respectent ces règles. La seule petite limitation qu’on avait, c’est que sur les outils compilés en « .exe », on n’avait pas la possibilité, avec les toolbox disponibles, d’utiliser directement du modèle Simulink. Il faudrait donc une toolbox supplémentaire.

[14:38] Les conclusions sur le sujet. D’après les études qu’on a faites, la méthode est plutôt générique dans le sens où elle peut s’appliquer à une boucle de régulation ou un capteur. Elle fournit à l’après-vente des détails sur l’origine des défauts et notamment si ce sont des défauts électriques ou des défauts mécaniques. Elle est intégrable sur calculateur. Comme je l’expliquais juste avant, on a la possibilité d’exporter ce qu’on a appris en Simulink. Et nous n’avons pas poussé le sujet, mais on sent qu’il y a des perspectives de mise en œuvre pour faire de la maintenance prédictive. Merci.