La double boucle
Grâce à elle, nous avons plein pouvoir sur notre groupe motopropulseur
Temps de lecture : 11 minutes.
Ce rapport hebdomadaire est destiné aux 202 pionniers.
Salut à tous,
Un jour, peut-être, nous fabriquerons notre propre contrôleur.
Le contrôleur est, pour rappel, cette boîte noire qui alimente le moteur électrique de notre groupe motopropulseur — et qui s’assure que cet insaisissable moteur fasse exactement ce qu’on lui demande.
C'est pour cette raison qu’on l’appelle ainsi : il contrôle le moteur.
Ce que je trouve finalement plus juste que l’autre terme qui est souvent utilisé (inverter en anglais, ou “onduleur”), qui est beaucoup moins évocateur.
Un jour, donc, nous saurons peut-être concevoir et fabriquer ces boîtes noires. Mais pour l’heure, nous n’avons pas le loisir de nous plonger dans un tel développement. Nous préférons laisser ce fardeau à ceux qui savent y faire. Chacun son métier, il faut savoir raison garder.
En revanche, cette division des tâches n’est pas sans défaut.
Car si elle nous permet de ne pas nous soucier de la conception de notre contrôleur, elle nous oblige à accepter les conditions imposées par notre fournisseur.
Dans notre cas, notre fournisseur est Mahle.
Et chez Mahle, malgré leur bonne volonté, ils ne sont pas plus que ça tournés vers une quelconque transparence de ce qui se trouve dans leur contrôleur. Ils se contentent de nous donner accès à quelques paramétrages macroscopiques, et puis c’est tout.
Mais vendredi, dans la newsletter que j’ai consacré au pilotage intelligent d’un groupe motopropulseur, j’ai essayé de vous démontrer que nous avons un besoin vital de piloter correctement toutes les briques technologiques qui composent notre groupe motopropulseur.
Et ce rôle devrait incomber à notre contrôleur.
Manque de chance, les paramétrages que je décris comme macroscopiques sont des paramétrages à la grosse louche. Une louche si grosse que n’importe quelle ambition de finesse se voit tuée dans l’œuf.
Mais plutôt que de me laisser abattre par un tel mauvais sort, j’ai essayé d’allumer la machine à idées afin de trouver un moyen d’outrepasser l’opacité du contrôleur Mahle.
Et en toute légalité, je crois que j’ai trouvé.
Les macro-paramètres à notre disposition
D’abord, précisons le cadre de notre discussion.
Nous sommes, depuis plus d’un an, en accord de confidentialité avec Mahle. Nous n’avons donc aucun droit de communiquer sur les informations confidentielles qu’ils nous partagent.
Car il faut bien admettre que si leur contrôleur n’est pas exactement aussi ouvert que ce que l’on espèrerait, ils nous ont donné accès à son protocole de communication. Ce qui nous permet de le paramétrer à notre guise, dans les limites de ce qui est permis.
Tout ce que je vais dire ici doit donc passer à la moulinette de la confidentialité.
Et puisque je ne veux aucun problème, ma stratégie est simple : les informations que je vais partager avec vous sont toutes disponibles sur internet. De cette manière, je ne prends aucun risque de froisser ce géant qui a eu l’audace de nous accompagner.
Voilà donc l’information la plus complète que je peux vous donner, sur les paramètres auxquels nous avons accès dans notre contrôleur :
Cette image est une courbe de l’intensité que notre contrôleur peut approvisionner vers notre moteur, en fonction du régime de notre moteur. Et en conséquence, cette courbe d’intensité se transforme en une courbe de couple.
Ce que vous voyez ici, c’est précisément ce que Mahle nous permet de paramétrer :
Nous pouvons, si nous le souhaitons, changer les points de la courbe bleue (de manière très grossière), afin de modifier le comportement de notre moteur.
Et nous pouvons aussi moduler cette courbe en activant un mode économie, qui correspond à cette même courbe décalée vers le bas. Une courbe moins énergivore, donc.
Enfin, il y a un autre paramètre que nous pouvons modifier, mais celui-là est confidentiel.
Je ne l’ai trouvé nulle part sur internet.
Mais si vous avez quelques notions de contrôle moteur, vous pouvez peut-être deviner ce paramètre manquant, que nous pouvons paramétrer, et que je ne n’ai pas le droit de communiquer. Disons que c’est un paramètre pré-requis, que l’on retrouve même sur les moteurs de drones.
C’est dire.
Ainsi, et malgré toute la bonne volonté de Mahle, ces paramètres sont les seuls que nous pouvons toucher.
Et je ne sais pas ce que vous en dites, mais ça paraît quand même relativement léger. Car aucun de ces paramètres n’autorise une modification en temps réel du comportement de notre moteur. Ces paramètres donnent un cadre maximal, un couple à ne pas dépasser, et rien de plus.
Forcément, ça ne peut pas me suffire.
Car si notre moteur voit sa température augmenter, à cause de la chaleur extérieure ou d’une utilisation continue pendant plusieurs dizaines de minutes, je ne peux absolument rien faire d’autre que d’activer rapidement le mode économie.
Ce qui est brutal, et très désagréable pour l’utilisateur.
À la place d’une telle brutalité, je préfèrerais suggérer au moteur d’éviter certaines zones de rendement défavorable, ou moduler la commande de couple pour la réduire légèrement afin d’éviter la surchauffe.
Mais jusqu’à maintenant, je ne peux pas le faire.
Et si c’était acceptable jusqu’à ce que nous ayons la preuve que notre groupe motopropulseur fonctionnait correctement, ce n’est plus acceptable aujourd’hui. Car fonctionner correctement n’est plus notre objectif. Nous, on veut fonctionner excellemment.
Que dis-je excellemment, sublimement !
Un asservissement à 2 couches
Si je décortique notre groupe motopropulseur tel qu’il est aujourd’hui, la chaîne de traction ressemble à ça :
Il y a d’abord la poignée d’accélération, qui est connectée au contrôleur et qui lui envoie une commande.
Le contrôleur traduit cette commande pour envoyer du courant dans le moteur, qui entraîne alors la roue à une certaine vitesse.
Et le contrôleur, pour ne pas travailler à l’aveugle, intègre une boucle d’asservissement. C’est-à-dire que régulièrement, il s’enquiert de la vitesse du moteur, pour s’assurer qu’elle est bien égale à celle qu’il s’attend à voir. Si elle l’est, tout va bien, il rassure son tempérament inquiet.
Mais si elle n’est pas égale à ce qui est attendu, alors le contrôleur doit réagir. Et pour ça, il intègre une modélisation du moteur en son sein (d’où le bloc “modèle du moteur” dans mon schéma) afin de savoir précisément que faire de cette bévue.
En somme, ce schéma est celui d’un système asservi, comme on en voit mille.
Le problème, c’est que dans ce schéma, vous pouvez voir que j’ai intégré un rectangle pointillé. Ce rectangle, c’est le rectangle de l’opacité. Celui auquel je n’ai pas accès. Ou plus précisément, celui auquel je n’ai pas suffisamment accès.
Mais nous venons de le voir, cette opacité ne me convient pas.
Alors plutôt que de me laisser abattre, j’ai sorti une carte finalement toute simple : plutôt que de traiter le contrôleur comme un composant tout-puissant, je vais le traiter comme un esclave.
Attention, je ne fais ici pas l’apologie de la servitude abjecte de composants harassés.
Non, je suggère simplement d’utiliser une architecture que l’on qualifie généralement “maître/esclave”. C’est-à-dire une architecture où un composant est positionné au-dessus des autres composants, et les pilote à sa guise.
Et ce composant, nous l’avons déjà dans notre groupe motopropulseur : c’est le calculateur central, qui se charge déjà de faire l’interopérabilité entre tous les organes de notre groupe motopropulseur.
Le calculateur central, donc, va prendre du galon.
Car prenant acte de la décision du contrôleur de ne pas ouvrir ses entrailles, il va le piloter de l’extérieur et devenir le centre de commande de notre groupe motopropulseur. Il était colonel, il devient général.
Nous donnant alors un schéma de contrôle à 2 boucles d’asservissement : une boucle à l’intérieur du contrôleur, et une boucle à l’extérieur.
Dans ce schéma, l’idée est donc de rendre robuste notre conception, en centralisant l’intelligence dans le seul composant propriétaire de notre groupe motopropulseur : le calculateur central.
Et mieux encore, on se rend indépendants du contrôleur.
Du jour au lendemain, on n’est plus tributaires du bon vouloir de notre contrôleur, et de la bonne entente avec Mahle. S’ils décident de couper les ponts pour une raison ou pour une autre, notre architecture ne sera pas bouleversée puisque toute l’intelligence de pilotage sera dans notre calculateur central.
Il nous suffira de trouver un autre contrôleur et paf, nous serons repartis de plus belle.
En somme, cette architecture de contrôle de notre groupe motopropulseur est à la fois :
Un filet de sécurité industriel (elle nous rend moins dépendants à Malhe) ;
Et une filière de performance (elle nous permet de tirer le meilleur parti de nos composants).
Car oui, je n’oublie pas mon but initial !
Je le rappelle, mon but initial est de m’inspirer de ce que j’ai pu lire dans l’étude dont je vous ai parlée vendredi, pour maximiser les performances de notre groupe motopropulseur.
Donc je me félicite de commencer dès aujourd’hui à travailler à cette architecture de contrôle, qui va demander un petit peu de développement.
Et pour cause : le plus compliqué ne sera pas de la mettre en place, mais de développer le deuxième bloc “modèle moteur”, que j’ai ajouté dans le schéma, et qui sera quant à lui logé dans le calculateur central.
La suite des choses
Dans les prochains jours — maintenant que tout fonctionne comme un charme — je vais donc me lancer ce défi de rajouter une couche d’intelligence à notre calculateur central.
Et je vais faire les choses dans l’ordre.
Car dès qu’on se lance dans une telle œuvre de pilotage intelligent, on se fait assaillir par une nuée de projets tous plus excitants les uns que les autres. Forcément, on s’imagine mille possibilités, en tant qu’ingénieur fétichiste des nombres.
On se dit qu’on va pouvoir identifier les moments de glissement dans la roue pour améliorer la tenue de route ;
On se dit qu’on va pouvoir piloter très finement la température du moteur afin de le garder toujours à une température optimale ;
Et on se dit dit qu’on va pouvoir maximiser la durée de vie de nos batteries en tirant juste ce qu’il faut pour les préserver.
En somme, on peut vite prendre feu, face à un tel enthousiasme naïf.
Mais en réalité, tous ces éléments que je viens de citer sont tributaires de notre capacité à bien lire le comportement à chaque instant de notre moteur. C’est-à-dire à connaître l’intensité dans ses bobines, son couple, son régime et sa température.
Sans ces informations, on travaille à l’aveugle.
Car sans ces informations, on est incapable de relier la dynamique de notre véhicule avec les paramètres de notre groupe motopropulseur.
Or nous n’avons déjà pas accès à toutes ces informations.
Les informations auxquelles j’ai accès sont elles aussi confidentielles, mais sachez simplement que le moteur ne nous renseigne pas toutes ces informations dont j’ai pourtant besoin.
Ainsi, avant de m’enfiévrer à lister les options que pourraient déployer notre calculateur central, je vais devoir trouver des stratégies pour estimer en temps réel toutes les caractéristiques qui me manquent.
Je vais donc m’y consacrer, et je vous raconterai les faits saillants de ce que j’aurai trouvé pour résoudre ce problème.
Et d’ici là, nous allons nous amuser avec à lister toutes les options que nous pourrions intégrer à notre groupe motopropulseur grâce à cette architecture.
Sur ce sujet, je suis sûr que vous avez quelques idées d’options.
Alors je vous laisse me les décrire en commentaires.
N’ayez aucun scrupule, ni aucun complexe. Les options impossibles à mettre en place n’existent pas. Alors soyez aussi créatifs que vous le souhaiterez. Qui sait, une idée révolutionnaire pourrait émerger de nos échanges !
Je vous souhaite un très bon dimanche,
Julien
Moi, en tant qu'ingénieur en informatique, quand je lis ton post, une chose me vient directement en tête : Intelligence artificielle. Un réseau de neurones correctement entraîné me semble parfaitement indiqué pour piloter "intelligemment" un moteur.
Une simple recherche donne un premier article (j'ai juste lu l'intro) : https://hal.science/hal-02907937/document écrit par des français. Peut être y a t il un sujet intéressant pour un thésard de ces labos. Compte tenu de la vitesse de développement de ce domaine, je pense que le temps nécessaire pour mettre au point un tel système n'est pas si grand (a vérifier).
Je suis convaincu que ce sujet est au cœur même de votre "core business". Si l'idée est de commercialiser un groupe motopropulseur meilleur que les autres, l'IA, au delà de son effet marketing hype, donnera un atout concurrentiel et un vrai savoir faire. De plus, et c'est la une chose que Tesla a bien compris, le modèle est capable de continuer à apprendre une fois en production sur les motos des clients. Et la boucle vertueuse entre en marche. Plus il y a de moto dans la rue, plus le modèle apprend, plus il est pertinent sur les cas non anticipé, et plus le modèle s'affine et devient encore meilleur. Attention quand même, on ira pas au delà des 100% d'efficacité 🤣
Une piste de réflexion qui me semble intéressante à creuser.
V.
Pour revenir sur le sujet qui me préoccupe : mon souhait préféré serait une possible détermination des pannes potentielles comme j'ai pu le vivre lorsque je conduisais des locomotives électriques. Les dernières générations de machines vous permettent de rentrer dans un guide de dépannage numérique ou l'on peut se dépanner dans certaines situations.
Exemple: isoler un moteur endommagé. Bien sûr, impossible dans notre cas, mais peut-être un mode dégradé si possible. Et aussi (surtout) la possibilité de déterminer l'organe HS afin de limiter les dépenses en réparations.
Bon c'est du rêve, personne ne voudra s'engager sur un terrain pareil: Trop de manque à gagner sûrement.
Tschuss