Le rôle du cloud dans les véhicules d'aujourd'hui (2e partie)

Présentation générale

JOHN : Aujourd’hui, dans « The Garage », nous vous proposons la deuxième partie de notre série spéciale en deux volets consacrée au cloud computing dans le secteur automobile, avec notre invité spécial Stefano Marzani, d’AWS. Dans la première partie de notre entretien, nous avons abordé les aspects liés aux données et au calcul dans le cloud computing. Dans l’épisode d’aujourd’hui, nous poursuivons la conversation et parlons du prototypage, de l’analyse de données, de l’ AI, ainsi que des applications du cloud dans les systèmes ADAS et la conduite autonome. Poursuivons notre entretien avec Stefano Marzani, d’AWS. C’est parti !

Thème n° 3 : Le prototypage dans le cloud et la « parité environnementale »

JOHN : C'est d'ailleurs une transition parfaite vers notre troisième sujet, à savoir le prototypage. Comme je l'ai mentionné, nous avons récemment discuté avec Robert Day, et Arm constate que son architecture est adoptée dans un large éventail de sous-systèmes automobiles. Et, vous savez, je suis fier d'avoir travaillé chez Arm pendant 14 ans. C'est donc un sujet qui me tient particulièrement à cœur. Mais Robert en a beaucoup parlé. Mais je pense que cela signifie également – et je crois que c’est l’un de vos arguments –, que le fait que Graviton soit présent dans le cloud, avec des instances basées sur Arm aussi bien dans le cloud que dans les véhicules, ouvre la voie à des possibilités vraiment intéressantes en matière de prototypage.

STEFANO : Tout à fait, oui. On appelle ça la « parité environnementale », n’est-ce pas ? C’est nous qui avons lancé ce terme lors de la Dev Summit Conference en 2021, lors d’un atelier que nous avons animé à l’Arm Dev Summit et qui a bénéficié d’une diffusion et d’une visibilité assez importantes. Comme c’était la première fois que nous présentions ce concept, nous nous sommes demandé : pourquoi ne pourrions-nous pas utiliser les architectures Arm dans le cloud pour exécuter les mêmes logiciels que ceux qui tournent sur la même architecture Arm, si l’on peut dire, dans les voitures ? Même architecture Arm, mais pas les mêmes processeurs : nous n'en avons aucune idée, et nous n'avons pas l'intention d'intégrer le Graviton dans une voiture, n'est-ce pas ? Ce sont en réalité les calculateurs embarqués (ECU) des voitures qui proviennent de divers fournisseurs tels que Qualcomm, Nvidia, NXP, et tous sont basés sur des cœurs Arm. Et encore une fois, le cœur Arm est exactement le même que celui que nous avons dans le Graviton. N'est-ce pas ? En ce qui concerne Arm 64, bien sûr, ce n’est pas vraiment le même processeur, car notre Graviton repose sur l’architecture Neoverse, alors que dans les véhicules, on trouve souvent du Cortex, mais l’essentiel du jeu d’instructions est identique.

Exécution sur Arm dans le cloud et dans le véhicule

STEFANO : C’est la raison pour laquelle nous pouvons les charger, et une fois que cette idée nous est venue, nous l’avons mise en œuvre. Nous disposons donc désormais d’une grande variété de systèmes d’exploitation embarqués qui, traditionnellement, ne fonctionnaient que dans des environnements émulés ou sur du matériel physique, et qui tournent désormais en mode natif dans le cloud AWS sur Graviton. Des systèmes comme QNX, VxWorks, Yocto Linux, AGL. Pour les développeurs embarqués, c’est une nouvelle façon de développer ; nous constatons un engouement incroyable, voire une certaine surprise, si l’on peut dire : « Non, attendez, on lance simplement ce processus dans le cloud, et j’ai une invite QNX devant moi, comme si j’utilisais une sorte d’ECU. » Oui, c’est exactement ce que nous entendons par « parité environnementale ». Vous pouvez commencer votre travail là-bas. Vous avez besoin d’un matériel, bien sûr, mais pas pour démarrer le développement.

Se lancer dans le développement logiciel dans le cloud

STEFANO : C'est un énorme frein pour le secteur en ce moment, et c'est un aspect important du point de vue du prototypage, n'est-ce pas ? On peut recourir à des solutions innovantes à moindre coût si l'on a constamment besoin que les développeurs, et notamment les meilleurs d'entre eux, disposent de matériel pour travailler, n'est-ce pas ? Car il n'existe pas de matériel capable de répondre à la demande.

JOHN : Bien sûr. Et du point de vue des tests, les tests de régression. Nous en avons parlé dans un épisode précédent : nous avons également commencé à réaliser nos propres tests dans le cloud. Ainsi, au lieu d’avoir des rangées et des rangées de serveurs qu’il faut redémarrer à distance, on peut utiliser des instances virtuelles et EC2. C’est donc ce que nous faisons également. Nous constatons les avantages de cette approche et nous l’utilisons beaucoup.

Difficultés liées à la validation dans le secteur automobile

STEFANO : Oui. Oui, tout à fait. C’est, c’est un énorme avantage, encore une fois, pour les développeurs, et pour la phase de validation, n’est-ce pas ? Réfléchissez-y. Aujourd’hui encore, la voiture est littéralement un système qui n’est pas, vous savez, testé en profondeur. C’est dû à des raisons historiques. Comme nous le disions au début de l’épisode, la voiture subit actuellement une transformation profonde : elle passe d’un système composé de plus de 150 calculateurs (ECU) dans un véhicule moderne à moteur thermique à un nombre bien moindre, disons 30 ou 40, avec des calculateurs consolidés. Vous aurez toujours vos unités périphériques à microcontrôleur pour la détection ou l’actionnement. Mais le gros du calcul sera effectué par des architectures consolidées intégrant de nombreux cœurs Arm – 8, 12, 16, 40 –, n’est-ce pas ? – dans des architectures ultra-consolidées. Et c’est extrêmement important, n’est-ce pas ? C’est une tendance extrêmement importante.

Donner plus de moyens aux développeurs grâce au cloud

STEFANO : Et on ne peut pas s’attendre à ce que les développeurs aient ces machines sur leur bureau pour travailler ; il faut leur proposer un environnement, un environnement « cloud-native », pour les raisons que nous avons déjà évoquées. Parce que c’est là que se trouvent les données. C’est là que se trouvent les ressources de calcul. C’est là que se trouve Graviton. C’est donc l’environnement naturel où les développeurs peuvent trouver leurs outils, travailler, déployer sur le matériel et continuer à tester sur le matériel, mais pas l’inverse.

Le volume des logiciels embarqués va tripler au cours des cinq prochaines années

STEFANO : Parce que si on commence par le matériel, on étouffe tout simplement l’innovation. Tu sais, dans le domaine du SDV, on s’attend à ce que la quantité de code triple au cours des cinq prochaines années, passant de 100 millions à 300 millions, selon certains analystes. Comment peut-on y parvenir si l’on continue d’exiger des développeurs qu’ils disposent de matériel pour travailler et produire du code automobile ?

JOHN : Waouh, c'est un chiffre incroyable ! Je n'avais jamais entendu parler de cette statistique : un triplement au cours des trois prochaines années ?

STEFANO : Cinq ans.

JOHN : C’est incroyable. Tu sais, je me disais justement qu’il y a aussi une sorte de cercle vertueux, parce que nous avions parlé dans un épisode précédent de la consolidation des charges de travail, et tu viens d’en parler il y a un instant. Et je pense que nous avions également évoqué l’importance de la virtualisation et de la possibilité d’exécuter ces applications en parallèle, sans qu’elles n’interfèrent les unes avec les autres. J'ai l'impression que cela crée une véritable synergie avec cette approche de prototypage dans le cloud ainsi qu'avec la virtualisation, car on peut reprendre ces mêmes charges de travail que l'on a testées là-bas, et elles peuvent désormais coexister côte à côte. Et cela ressemble beaucoup plus, comme vous l'avez dit, à l'approche de « parité environnementale » dont vous aimez parler.

STEFANO : Oui, tout à fait. Tout à fait. Et encore une fois, si on y réfléchit bien, quand on commence à avoir 12 ou 16 cœurs, on ne les utilise pas tous pour un seul système d’exploitation ; cela signifie qu’il faut partitionner ces cœurs et faire tourner plusieurs systèmes d’exploitation. Mais c’est exactement ce que nous faisons dans le cloud : nous disposons d’un hyperviseur qui gère, sur les 64 cœurs d’un processeur Graviton, plusieurs systèmes d’exploitation, n’est-ce pas ? C’est exactement la même chose. Bien sûr, cela diffère en termes de qualification électronique et de bien d’autres aspects. Mais du point de vue de l’ingénierie logicielle, nous pouvons procéder de telle sorte que les deux environnements soient très proches.

JOHN : En fait, ça permet presque de valider comment ça fonctionnera dans la version finale dès la phase de prototypage et de test, c’est très intéressant. C’est… c’est quelque chose que je trouve vraiment fascinant, d’un point de vue technique, et je pense que c’est aussi un outil très puissant pour le développement.

« Shift left » pour accélérer le cycle de conception

JOHN : Et, vous savez, nous constatons – et nous en avons déjà parlé il y a des années – cette notion de « shift left » : comment utiliser le prototypage virtuel, le cloud, etc., pour accélérer le cycle de conception. Et nous constatons – nous en avons également parlé dans l’un de nos récents épisodes – qu’une pression s’exerce sur le cycle de conception pour qu’il soit plus rapide, et je pense que le contexte concurrentiel pour les équipementiers et les fournisseurs de premier rang devient de plus en plus difficile. Et si ces outils permettent de raccourcir le cycle de conception, cela peut rendre les entreprises plus compétitives, réduire les coûts et, en réalité, je pense, gérer cette complexité considérable. Comme vous l’avez mentionné, le nombre de lignes de code augmente, et il faut absolument maîtriser cela. Je pense qu’il faut diviser pour mieux régner pour que cela fonctionne. Sinon, si l’on considère cela comme un système géant et monolithique, il est impossible de le vérifier.

40 à 50 milliards de dollars de pertes dues aux rappels automobiles

STEFANO : Tout à fait. Et il y a d’autres avantages également. Il faut donc opter pour le « shift left », c’est certain. Cela permet d’améliorer la qualité du code, car on peut étendre davantage les tests. C’est donc vraiment très, très important. Pensez-y dans le secteur automobile. Aujourd’hui encore, on perd entre 40 et 50 milliards de dollars chaque année à cause des rappels. 70 % de ces cas sont dus à des défauts logiciels. 70 % des cas recensés. Réfléchissez-y. C’est un manque de qualité. Peut-on le dire ainsi ?

JOHN : Ouais.

STEFANO : Des tests insuffisants.

JOHN : Tout à fait.

STEFANO : Pas vers la gauche.

JOHN : Ouais.

STEFANO : N’est-ce pas ? Donc, en avançant vers la gauche, on réduit les coûts et on améliore la qualité. Mais j’aimerais également penser aux utilisateurs finaux. Car ce que l’on constate, c’est que si l’on n’a pas besoin d’envoyer ces calculateurs pour le développement, on peut favoriser la collaboration dans le cloud. Et c’est extrêmement important. En fait, c’est l’un des aspects surprenants du SDV. Nous avons parlé des services ADAS/AV, basés sur la télématique, les services télématiques.

Développement d'une interface homme-machine (IHM) automobile via le cloud

STEFANO : On constate une forte augmentation du développement des IHM dans le cloud : interaction homme-machine, interface utilisateur, expérience utilisateur. Et pour moi, c'est fantastique. Et on comprend tout de suite pourquoi. On le comprend parce que, pour la première fois, on dispose d’un calculateur électronique virtuel (ECU) dans le cloud, qui présente une interface utilisateur dans le navigateur. Je peux immédiatement la montrer à l’ensemble de mon réseau de collaboration à travers le monde, car le cloud est présent partout. Je peux donc demander à un collègue au Japon, ou à un collègue en Afrique du Sud : « Que penses-tu de ma nouvelle interface utilisateur, compte tenu de tes préférences locales ? » Ou encore : « Peux-tu l’adapter ? » Ou « Peux-tu travailler dessus ? »

JOHN : Et la localisation, la langue.

STEFANO : C’est littéralement une révolution dans la manière dont on conçoit les systèmes IHM, si l’on imagine ne plus avoir à déployer tout ce matériel partout. Il s’agit d’adopter une approche « cloud-native » et « cloud-first », comme on dit, pour le développement des IHM. Et nous avons déjà un client qui tente de l’adopter. Et récemment encore, nous avons publié, en collaboration avec BMW, une présentation très intéressante sur leurs pratiques de développement d’IHM dans le cloud lors du dernier sommet AWS à Berlin, et nous pouvons bien sûr vous fournir la référence. C’est une belle démonstration. Mais il ne s’agit pas de ne parler que de BMW : je peux par exemple évoquer la démo que nous avons réalisée au CES avec Marelli. Marelli est un équipementier de premier rang. Et ils y ont présenté le premier système d’IHM natif du cloud sur notre stand. C’est vraiment intéressant, car on voit ainsi que nous développions une application d’IHM dans le cloud, puis que nous la déployions à Milan, en Italie. C’est un ingénieur qui s’en est chargé dans le cloud, puis qui l’a déployée à Las Vegas sur le stand, n’est-ce pas ? Encore une fois, on commence par le développement dans le cloud, puis on déploie et on personnalise sur une solution matérielle spécifique, n’est-ce pas ? Et c’est vraiment, vraiment puissant, quand on y pense. Ce n’est pas seulement puissant. C’est du SDV, n’est-ce pas ? C’est défini par le logiciel. Sinon, c’est défini par le matériel : si l’on part du matériel, c’est défini par le matériel. Si c’est vraiment défini par le logiciel, il faut commencer par le logiciel, puis déployer par la suite.

La SDV peut réduire le coût des rappels

JOHN : Exactement, exactement. Tu viens d’aborder tellement de sujets là-dessus. Et je ne voudrais pas passer à côté du point que tu as soulevé concernant les rappels. On entend souvent les équipementiers, qui ont un lourd fardeau en matière de développement logiciel – ce qui est vrai –, exprimer leurs inquiétudes en disant : « Oh, c’est trop difficile d’intégrer cette fonctionnalité logicielle au véhicule. » Mais quand on pense à des chiffres, comme vous l’avez dit, de 40 ou 50 milliards de dollars, dont une grande partie est liée aux logiciels, ce serait de la folie de ne pas intégrer les capacités nécessaires pour y remédier, car cela ne demande pas un investissement énorme pour économiser potentiellement des milliards de dollars.

STEFANO : Oui, on a eu un très bon épisode de « All Things Automotive » avec Martin Stamm, de Conti.

JOHN : Oui, j'ai vu cet épisode.

STEFANO : Oui, tu as vu ça ? Là où il explique pourquoi c'est comme ça, c'est ça ?

Regroupement des calculateurs électroniques

STEFANO : Traditionnellement, les constructeurs, les équipementiers, avaient besoin d’intégrer une nouvelle fonctionnalité. Cela signifiait : « Bon, il faut intégrer un calculateur de plus, puis encore un, et encore un, jusqu’à en avoir 150. » Mais si l’on réfléchit à l’effet combinatoire de cette situation, on ne pourra jamais tester tous les cas possibles où toutes ces fonctionnalités sont combinées. C’est pourquoi – et c’est une bonne chose pour le secteur –, poussés par l’électrification et d’autres tendances. Le fameux CASE, n’est-ce pas : Connecté, Autonome, Partagé et Électrifié, sans oublier l’expérience utilisateur. Cette consolidation est en train de se produire.

Consolider efficacement les logiciels sans les alourdir

STEFANO : Et c’est une véritable aubaine pour le secteur, pour être honnête, même si le défi consiste à transformer les logiciels présents dans tout ce système distribué pour les regrouper dans ces unités consolidées. Mais – et il y a un « mais » ici –, car il est très important de ne pas se contenter de dire : « Bon, maintenant qu’on a le logiciel dans cet ECU, je vais juste le prendre et le transposer dans mon unité consolidée. » C'est du « bloatware ». Vous savez, c'est prêt à exploser. Il faut repenser l'architecture du système, car l'unité consolidée est radicalement différente d'un ECU isolé optimisé en termes de coûts. Et en réalité, en termes de ressources, le logiciel a été spécialement conçu pour ce matériel quasi-sur-mesure. C’est pourquoi on voit tant de choses de ce genre – et vous en êtes bien conscient –, comme le travail que nous avons mené, par exemple, avec l’Autoware Foundation sur l’Open AD Kit : il s’agissait de prendre le logiciel – dans ce cas précis, celui de la conduite autonome, qui est classiquement monolithique, ce qu’on appelle un « monolithe » – et de le décomposer en microservices afin de le repenser pour qu’il soit pris en charge par une plateforme matérielle et logicielle qui exige véritablement plus de modularité et plus de flexibilité. Mises à jour différentielles, n’est-ce pas ? Standardisation des interfaces. Et tous ces concepts sont extrêmement importants pour repenser l’architecture de l’ensemble du secteur automobile.

SOAFEE et les normes du secteur automobile

JOHN : Tu sais, ce que tu viens d’évoquer rejoint tout à fait la discussion que nous avons eue récemment avec Robert Day au sujet de SOAFEE. Et en ce qui concerne SOAFEE, je sais qu’Amazon en était un membre fondateur ; tu en es donc un fervent défenseur. Une grande partie de ce que cette initiative cherche à faire consiste justement à fournir certaines de ces normes et de ces interfaces cohérentes dont tu as parlé. Mais c’est peut-être un sujet à aborder une autre fois.

STEFANO : Oui, tout à fait, c'est d'ailleurs une discussion très enrichissante. Je trouve que SOAFEE est une initiative fantastique. Et si vous vous renseignez, vous verrez que SOAFEE a pour objectif de fournir une implémentation de référence basée sur des normes ouvertes et l'open source. Oh là là, on a tellement besoin de normes ouvertes et d’open source dans le secteur automobile, n’est-ce pas ? C’est pourquoi des initiatives comme Yocto, COVESA, Eclipse SDV ou encore AUTOSAR sont vraiment très importantes. Et l’un des signes très positifs que l’on observe avec SOAFEE, c’est qu’on commence à collaborer ensemble, n’est-ce pas ? Et il faut insister là-dessus, n’est-ce pas ? Vraiment, parce que les normes ouvertes sont essentielles : on ne se fait pas concurrence sur les normes. Ça, ça ne se fait pas, n’est-ce pas ? On se fait concurrence — une fois les normes définies — pour innover, pour répondre aux besoins et aux envies réels des clients, ce qui ne relève pas de la norme. Personne ne se dit : « Ah oui, j’achète cette voiture parce que cette norme y est parfaitement mise en œuvre. » Ça n’a aucun sens. N’est-ce pas ?

JOHN : Exactement. Il s'agit de permettre une différenciation à valeur ajoutée par rapport aux normes, tout en s'appuyant sur ces dernières comme base.

STEFANO : En tant que base. Bien sûr, encore une fois, c’est un autre moyen de réduire les coûts, d’optimiser. Pourquoi consacrer du temps et de l’argent à se démarquer sur une fonctionnalité courante, n’est-ce pas ?

JOHN : Si cet épisode vous plaît, je vous invite à cliquer sur « J'aime » et à vous abonner pour ne rien manquer de nos prochaines publications sur The Garage. Nous tournons un épisode toutes les deux semaines environ, et nous serions ravis de vous retrouver ici pour un prochain épisode.

Thème n° 4 : Apprentissage automatique et analyse de données

JOHN : Alors Stefano, nous avons abordé tellement de domaines différents que j’aimerais maintenant parler de l’intelligence artificielle, de l’apprentissage automatique et, plus généralement, de l’analyse de données, car nous avons évoqué cet incroyable lac de données que nous collectons, nous avons parlé de ces capacités de calcul dans les services spécialisés que vous proposez, avec des types de calcul spécifiques, etc. Sans oublier l’importance du prototypage, etc. Mais tout ce domaine de l’apprentissage automatique et de l’analyse de données est peut-être l’un des plus passionnants : la combinaison de ces éléments permet de réaliser des choses qui n’étaient jamais possibles auparavant.

STEFANO : Tout à fait. Et cela s'inscrit toujours dans la perspective de ce que nous appelons la « grande boucle », n'est-ce pas ? C'est extrêmement important, car, comme vous l'avez bien compris, les scientifiques affirment souvent que l'ensemble de données est l'élément le plus important pour élaborer correctement une modélisation, n'est-ce pas ? Nous gardons donc toujours cela à l'esprit. Il s'agit donc de sélectionner les bonnes données à stocker dans le cloud.

Collecte et annotation des données avec SageMaker

STEFANO : Donc, il faut intégrer un peu d’intelligence artificielle dans les voitures pour distinguer ce qui est pertinent en fonction de la situation, n’est-ce pas ? Peut-être y a-t-il eu un freinage brusque. Pourquoi ? Ou bien c’est une combinaison de facteurs. Il y a aussi les tests embarqués, nous allons parler de cette fonctionnalité extrêmement importante dès maintenant. Mais bon, une fois les données sélectionnées, il faut un peu d’apprentissage automatique qui doit être mis à jour, n’est-ce pas ? On envoie les données, on les collecte, on les nettoie, on organise le lac de données, parfait. Ensuite, on utilise une partie de ces données pour en annoter une partie, c’est ça. Nos clients les annotent donc à leurs propres fins ; nous disposons d’outils pour cela, appelés SageMaker Ground Truth. Une fois l’annotation terminée, nous utilisons ces données pour entraîner et valider les modèles. Nous disposons ici de diverses options. SageMaker est notre plateforme dédiée à cette tâche.

Autres frameworks d'apprentissage automatique sur AWS

STEFANO : Si vous êtes vraiment un spécialiste chevronné de l’apprentissage automatique, vous pouvez utiliser des frameworks de base comme PyTorch, par exemple, et aller vraiment au plus profond de ceux-ci ; ou bien, à l’inverse, vous pouvez utiliser ce qu’on appelle des services « AI s ». Par exemple, des services de reconnaissance où il suffit d’envoyer une image pour obtenir la liste des objets qu’elle contient. Exactement, des services de transcription AI . Nous avons donc ces trois niveaux.

Validation en conditions réelles de conduite des nouveaux modèles

STEFANO : Lorsque vous entraînez votre modèle via SageMaker, en général, vous le déployez en périphérie, mais là encore, c’est un long processus. Il est donc déployé, mais il n’est pas encore en production. Il est là pour des tests embarqués. Il existe une autre version de ce logiciel qui est actuellement en production. La première étape consiste donc à analyser si ce modèle offre des performances supérieures ou inférieures à celles du modèle en production, en le soumettant à des conditions réelles, éventuellement sur un grand nombre de véhicules en circulation, car nous sommes limités par la puissance de calcul. Nous disposons donc d'un peu plus de ressources, ce qui permet d'effectuer des calculs supplémentaires.

Identifier les cas limites

STEFANO : Exactement, comme vous l’avez dit tout à l’heure, le but est justement de repérer ces cas particuliers, ces « cas limites », comme on les appelle : il est impossible de simplement les imaginer en amont de manière abstraite ; il faut vraiment disposer de voitures, et de nombreuses voitures, sur le terrain pour valider les performances d’un modèle d’apprentissage automatique. Et quand on évalue cela, et si l’on constate que le modèle est meilleur, qu’il n’y a pas de régression, on le remplace, on le met en production, et la boucle continue, n’est-ce pas ? Sur un nombre de véhicules de plus en plus important, n’est-ce pas ? Vous voyez donc que l’apprentissage automatique n’est pas simplement une méthode magique pour entraîner un modèle. C’est en réalité cette boucle intelligente. Et il est très important de définir les workflows. Nous disposons de nombreux outils pour gérer ces workflows. Certains d’entre eux se trouvent dans SageMaker même.

Outils de gestion des flux de travail d'apprentissage automatique

STEFANO : Parmi d’autres exemples, notamment en matière de gestion des données, nous proposons une implémentation et une gestion d’Airflow, appelée « Managed Workflow with Apache Airflow ». Nous utilisons cet outil pour composer tous ces workflows, n’est-ce pas ? J’utilisais déjà Airflow dans mon ancien poste ; c’est un outil très puissant pour composer ce genre de pipelines. N’est-ce pas ? Et c’est un aspect très, très important. Tout cela, nos clients l’utilisent souvent dans ce qu’on appelle des « workbenches » ; en effet, de plus en plus, nos clients nous demandent de leur proposer un espace accessible via un navigateur où ils peuvent retrouver leurs outils. Ces outils peuvent être des pipelines de données, des workflows, des données liées au machine learning, l’accès au data lake, l’accès à des outils sectoriels… Tout récemment, par exemple, lors de l’événement dSPACE, nous avons présenté une collaboration avec MathWorks dans ce cadre. Vous pouvez donc trouver ces outils dans cet espace. Vous avez ainsi la possibilité de vous concentrer pleinement, de bénéficier d’un environnement uniforme, d’une distribution mondiale de cet environnement, d’un accès mondial à ces environnements, d’une intégration et de la possibilité de créer des automatisations. Récemment, notre PDG a publié un message sur LinkedIn indiquant que, grâce à cette approche, Toyota avait économisé 10 millions de dollars par an. Ce n’est pas mal, n’est-ce pas ? Il suffit simplement d’organiser les outils et de les présenter via une interface commune offrant la possibilité de créer des automatisations à partir de ceux-ci.

JOHN : Ce que je trouve intéressant dans ce que tu as dit, c’est qu’il y a plusieurs aspects : il y a d’abord les données, les données brutes ; ensuite, la capacité à modéliser, à affiner et à améliorer les modèles. Et puis, une fois que l’on dispose de tout cela, dans le cloud, il y a tous ces différents outils et modules qui peuvent s’interconnecter pour effectuer le post-traitement et l’analyse postérieure. Et il en existe de nombreux types différents. Je pense donc que l’ensemble de ce cycle est vraiment important.

STEFANO : Tout à fait, oui. Et c’est pourquoi, par exemple, nous l’avons mis en place et rendu public via notre cadre de données sur la conduite autonome, qui est une initiative open source visant à mettre à la disposition de nos clients des références open source pour créer ce type de structures et de flux de travail. Et, oui, nos clients adoptent honnêtement la majeure partie de cet outil exactement de cette manière dans le cadre d’un flux de travail. Des clients comme Toyota, par exemple, utilisent nos instances P simplement pour se connecter à notre environnement de calcul et de discussion, n’est-ce pas, afin d’entraîner le modèle sur AWS. Mais encore une fois, il ne s’agit pas d’une activité isolée. Ce n’est qu’une partie d’un flux de travail. Et c’est très important d’en tenir compte.

Thème n° 5 : Systèmes d'aide à la conduite avancés (ADAS) et conduite autonome

JOHN : Et c'est peut-être le moment idéal pour passer au dernier de nos sujets, à savoir les systèmes ADAS et la conduite autonome, un domaine sur lequel nous avons travaillé ensemble pendant plusieurs années et dans lequel nous avons acquis une grande expérience. Parlons de l’importance du cloud – je dirais même qu’il est indispensable – dans l’évolution des systèmes ADAS, ainsi que du potentiel de ce parcours dans lequel nous sommes tous engagés, vers la conduite autonome. C’est un parcours assez long, mais nous faisons des progrès significatifs.

STEFANO : Tout à fait. Et comme je l’ai déjà dit, c’est un sujet qui me tient vraiment à cœur – nous en avons d’ailleurs déjà discuté –, je suis très attaché à l’idée d’adopter une approche progressive en matière de conduite autonome, de fonctionnalités autonomes et d’autonomie dans les véhicules en général, n’est-ce pas ?

Avantages à court terme des systèmes ADAS

STEFANO : Parce que les systèmes ADAS, disons de niveau 2 ou 3, apportent aujourd’hui une valeur ajoutée considérable. Et c’est très important, car avant tout, ils sauvent des vies. C’est aussi simple que ça. N’est-ce pas ? Nous avons récemment testé une voiture équipée d’un système ADAS de dernière génération, et c’est fantastique. C’est une voiture qui dispose réellement de systèmes de freinage d’urgence automatique. Par exemple, si vous êtes distrait et qu’il y a un obstacle, la voiture freine. C’est simple, mais si ça marche, ça sauve des vies. C’est donc un aspect extrêmement important à mes yeux. Et je suis de plus en plus convaincu que l’autonomie sera un ensemble de ces fonctions qui seront progressivement automatisées, n’est-ce pas ? Il est donc important de réfléchir également aux fonctionnalités supplémentaires qui seront progressivement automatisées dans les véhicules. C’est mon point de vue sur la question. Et la manière dont nous abordons le cloud, en réutilisant tout ce dont nous avons discuté – essentiellement la diversité des options de calcul, la possibilité de ces lacs de données, leur architecture, ainsi que les outils d’apprentissage automatique –, voilà les éléments fondamentaux nécessaires au développement des systèmes ADAS et des véhicules autonomes. Il y a un autre aspect des options de calcul, pour deux raisons spécifiques aux systèmes ADAS, qui est très, très important : en effet, on collecte fréquemment des données sur le terrain et on les stocke dans S3, au sein du lac de données. Puis on les utilise à des fins de validation, n’est-ce pas ? Ainsi, on replie généralement ces données collectées auprès des véhicules dans les algorithmes en cours de développement afin d’évaluer s’ils sont meilleurs ou moins performants que ceux de la génération précédente. Ou bien vous utilisez la puissance de calcul pour effectuer des simulations synthétiques. Nous avons d’ailleurs un excellent cas d’utilisation avec Valeo que nous avions prévu de présenter au CES, qui a malheureusement été annulé en raison du COVID et auquel personne ne s’est rendu. Nous avions toutefois préparé cette formidable démonstration – il y a une vidéo sur YouTube, dont nous pouvons bien sûr partager le lien – où l’on voit Valeo utiliser deux technologies : IPG CarMaker d’une part, et Foretellix d’autre part, pour, vous le savez, multiplier les scénarios grâce à la simulation synthétique, et les décliner en des milliers de variantes différentes sur AWS, car on bénéficie de l’évolutivité, de l’élasticité et de la disponibilité de la puissance de calcul, puis on essaie vraiment de couvrir tous ces cas limites, justement pour vérifier s’il manque quelque chose dans notre analyse, en substance, n’est-ce pas ?

Recherche de cas limites

STEFANO : Et essayer de prendre les devants, si vous voulez, exactement comme nous en avons discuté, pour résoudre ce problème avant que le logiciel ne soit déployé sur les véhicules eux-mêmes, n’est-ce pas ? Il s’agit donc, encore une fois, de repenser ces flux de travail, et chez AWS, nous disposons de tous les outils nécessaires pour permettre à nos clients de le faire. Et si ce n’est pas le cas, nous serons ravis de collaborer avec nos clients pour les créer.

Analyse détaillée de la conduite autonome

JOHN : Tout à fait. Et je pense que beaucoup de gens pourraient croire que la conduite autonome est une tâche monolithique. Mais en réalité, elle se compose d’une multitude de sous-tâches. J’aime bien plaisanter en disant qu’il y a la reconnaissance des vélos et le maintien de la voie. Mais trêve de plaisanterie, il y en a beaucoup d’autres. Il faut décomposer tout ça… Vous savez, quand on conduit, on conduit, tout simplement. Mais en réalité, l’approche de l’apprentissage automatique et de l’intelligence artificielle consiste à la décomposer en différentes parties. Et ce que vous avez mentionné il y a un instant, je trouve ça très intéressant. Parce que quand on pense à l’entraînement, vous savez, si on considère la conduite comme une activité humaine, la plupart du temps, c’est assez ennuyeux : on roule tout droit, et c’est monotone. Ce qui est donc plus difficile que les choses que l’on doit s’entraîner à faire, c’est que même s’il peut y avoir un virage serré ou un obstacle, ce que vous avez mentionné est très intéressant : on peut accélérer les cas limites, en me fournissant une multitude de cas limites pour aider le modèle à apprendre beaucoup plus rapidement que ce ne serait possible dans un scénario de conduite réel.

STEFANO : Tout à fait, tout à fait. C’est tout à fait vrai. Et c’est pourquoi, par exemple, comme nous en avons parlé, les microservices sont importants dans cette optique, car on peut vouloir simplement remplacer le modèle de perception, tout en laissant le reste tel quel, n’est-ce pas ? Il s’agit donc d’avoir différentes équipes, dotées de compétences différentes, qui travaillent chacune sur leur petite partie, n’est-ce pas ? C’est donc un aspect extrêmement important : reconnaître les différents profils impliqués dans le développement des systèmes ADAS ou des véhicules autonomes. C’est un aspect extrêmement important, n’est-ce pas ? C’est tout à fait vrai, c’est un scénario complexe. Mais là encore, nous disposons de très bonnes références dans ce domaine. Encore une fois, le cas que je décrivais avec Continental concernait le développement d’un système ADAS, et vous verrez vraiment les gains qu’ils ont réalisés en termes de gain de temps, de réduction des coûts et d’agilité. En adoptant une approche « cloud native », n’est-ce pas ? C’était l’objectif de cet exercice CAEDGE que nous avons développé avec eux. Cela s’inscrivait d’ailleurs également dans le cadre d’une expérience de véhicule défini par logiciel. C’est donc une excellente référence. C’est vraiment grâce à notre collaboration avec Conti que nous avons commencé à réfléchir à la plupart de ces concepts. Une collaboration vraiment formidable.

Collaboration entre AWS et Sonatus

JOHN : Pour conclure notre entretien, j’ai pensé que nous pourrions prendre quelques instants pour évoquer certains des domaines dans lesquels Sonatus et AWS collaborent.

STEFANO : Oui, avec plaisir, car encore une fois, j’ai vu sur the garage des démos incroyables — merci beaucoup, d’ailleurs, de me les avoir montrées. Et c’est tout simplement incroyable, n’est-ce pas ? Certaines des fonctionnalités que j’ai découvertes, par exemple le contrôle de la logique du véhicule et le déploiement d’une nouvelle logique en fonction d’une nouvelle situation, correspondent exactement à ce dont nous avons discuté en termes de SDV et de mise à jour en « big loop ». On voit donc vraiment cela se concrétiser. C’est vraiment fantastique à voir. Et, oui, c’est une excellente collaboration. C’est un exemple parfait. Tu vois, il ne s’agit pas simplement d’envoyer ou de collecter des données ; on commence à mettre en œuvre cette vision d’un plan de données : oui, il faut collecter des données, mais aussi pour le plan de contrôle. Donc, pour pouvoir gérer cette micro-logique, du cloud à la périphérie et inversement, il faut disposer de certaines de ces micro-logiques, peut-être un peu d’apprentissage automatique à la périphérie, et il faut mettre en œuvre certaines de ces micro-logiques ou de cet apprentissage automatique dans le cloud. Et si l’on pense à la consolidation, si l’on pense aux cœurs Arm, vous savez, c’est un système que nous qualifions de continuum entre le cloud et la périphérie. Et je pense que vous faites vraiment un excellent travail dans la mise en œuvre de cette vision avec votre gamme de produits.

JOHN : Vous savez, merci beaucoup. Nous avons parlé tout à l’heure des données et, comme vous le savez, notre produit Collector est extrêmement optimisé : il collecte, traite et sélectionne avec soin des données à forte valeur ajoutée, puis les envoie vers le cloud, et nous travaillons avec vous sur ce point. Ensuite, le produit Automator que vous venez de mentionner, et que nous avons récemment lancé, nous permet de nous appuyer sur ce concept de données intelligentes pour passer à l’action, qu’il s’agisse d’actions à l’intérieur ou à l’extérieur du véhicule. Nous n’avons pas vraiment abordé la question des essais sur véhicules, mais ce problème devient lui aussi de plus en plus complexe. Nous sommes donc ravis de pouvoir exploiter cela de nouvelles façons pour, par exemple, améliorer le flux de production, ainsi que pour fournir de meilleurs services en aval. Vous avez évoqué tout à l’heure les véhicules connectés, ainsi que les capacités en aval pour l’utilisateur, et même pour les prestataires de services à valeur ajoutée sur le terrain.

Importance de l'utilisation d'ECU d'origine

STEFANO : Oui, et c’est vraiment intéressant. Et c’est un autre point très pertinent que j’ai remarqué, car vous le faites sur de véritables calculateurs. Et croyez-moi, ça fait une énorme différence, parce que je le répète sans cesse : quand on développe de nouveaux composants logiciels ou matériels pour l’automobile, il faut considérer que 50 % du travail, c’est le développement, et 50 % c’est la V et la V [vérification et validation]. Dans le cas des systèmes ADAS et des véhicules autonomes (AV), partons de quelques hypothèses. Pour les ADAS, je pense que le rapport est probablement de 20/80. Pour les véhicules autonomes, c’est plutôt 1 à 99. N’est-ce pas ? Parce qu’en réalité, la vérification et la validation, et vous le constatez, c’est différent quand vous commencez à voir le code s’exécuter sur de vrais processeurs, n’est-ce pas ? Ce n’est plus seulement un prototype sur votre bureau basé sur un kit d’évaluation. C’est quelque chose qui va être installé dans un million, deux millions, voire dix millions de véhicules. Cela fait donc toute la différence.

JOHN : Tu as raison. Et on est vraiment ravis d’être présents, tu sais, d’ici cette année, on sera présents dans des dizaines de modèles, et d’ici la fin de l’année prochaine, dans des millions de véhicules. C’est donc passionnant à voir : ce n’est pas un prototype, ce n’est pas un projet de recherche, mais une véritable production. Et on apprend beaucoup de la production réelle, là où les choses se concrétisent, pour ainsi dire. Ça rend les choses beaucoup plus difficiles.

STEFANO : Oui. Et tous ceux qui travaillent dans l’automobile savent bien que la mise en conformité avec les réglementations demande beaucoup d’efforts. C’est un aspect essentiel de ce secteur, n’est-ce pas ? On ne peut donc pas se contenter de déployer du code comme on le fait sur les téléphones. N’est-ce pas ? Ce n’est pas un appareil grand public, dans le sens où il s’agit d’un produit réglementé : il y a la sécurité fonctionnelle, il y a la cybersécurité. Et ce sont des aspects primordiaux. Et vraiment importants pour nous. C’est une priorité absolue, la priorité numéro zéro.

Résumé

JOHN : Oui, nous avons abordé tellement de sujets aujourd’hui que nous pourrions avoir de nombreuses conversations d’une heure chacune rien que sur les différents sous-thèmes dont nous avons parlé, mais nous allons devoir conclure pour aujourd’hui. Je tiens donc tout d’abord à te remercier infiniment d’être venu, Stefano. Ce fut un plaisir de t’accueillir. J'ai beaucoup appris au cours de cette conversation, et j'apprécie toujours autant de discuter avec toi. J'espère que tu reviendras nous rendre visite.

STEFANO : Moi aussi, merci de m’avoir invité. C’est toujours un plaisir. J’ai moi-même beaucoup appris. C’était vraiment génial.

JOHN : Merci, Stefano. Dans l’épisode d’aujourd’hui, nous avons abordé tous les aspects du cloud, et plus particulièrement ceux d’AWS. Nous avons évoqué les avantages que le cloud peut apporter et les améliorations qu’il peut apporter au secteur automobile et aux processus liés aux véhicules, en commençant par les données et leur importance, ainsi que les nombreuses façons de les exploiter. Nous avons également parlé des ressources de calcul et de la nécessité de disposer de différents types de services de calcul pour résoudre divers types de problèmes. Nous avons abordé le prototypage, et en particulier la possibilité de prototyper des fonctions de véhicule dans le cloud puis de les déployer dans un véhicule réel, ce qui est très intéressant. Nous avons parlé de l’apprentissage automatique et de l’analyse de données, ainsi que de la manière dont l’analyse de données peut être utilisée pour apporter de la valeur ajoutée de nombreuses façons différentes. Et enfin, nous avons très brièvement évoqué la conduite autonome et les systèmes ADAS, ainsi que l’importance d’améliorer et d’optimiser ce processus. Cette conversation a couvert un large éventail de sujets. J’espère que vous l’avez appréciée, et nous avons hâte de vous retrouver très bientôt pour un nouvel épisode d’« The Garage ». Merci beaucoup.