Comment Rivian réinvente-t-elle l'architecture automobile ?

Présentation générale

JOHN : Nous sommes ravis d’accueillir l’un des pionniers qui fait progresser les véhicules définis par logiciel et les technologies de pointe dans le secteur automobile. Aujourd’hui, dans « The Garage », nous recevons le vice-président senior chargé du matériel électrique chez Rivian. C’est parti !

JOHN : Bienvenue sur The Garage. Je m'appelle John Heinlein, je suis directeur marketing chez Sonatus.

Découvrez Vidya Rajagopalan

JOHN : Dans « The Garage », nous réunissons des responsables des secteurs du matériel et des logiciels automobiles, et nous accueillons aujourd’hui une invitée spéciale. Nous sommes ravis d’accueillir sur « The Garage » Vidya Rajagopalan, vice-présidente chargée du matériel électrique chez Rivian. Vidya, bienvenue sur « The Garage ».

VIDYA : Merci. Merci de m'avoir invitée, John.

JOHN : C'est avec plaisir. Nous parlions justement du fait que nous nous sommes rencontrés il y a de nombreuses années. Nous avons estimé que c'était il y a environ 15 ans, en 2009, lorsque nous avons travaillé ensemble. Je travaillais chez Arm à l’époque, et vous étiez chez Xilinx où vous travailliez sur leur Zynq. Vous avez d’ailleurs contribué à la création de leur gamme de produits Zynq, qui est vraiment unique. Pourriez-vous commencer par nous parler un peu de votre parcours et peut-être de cette gamme de produits qui a été l’occasion de notre première rencontre ?

VIDYA : Oh, c’est génial. C’est drôle, parce que quand on s’est rencontrés, aucun de nous deux ne travaillait dans le secteur automobile. J’étais chez Xilinx. En fait, j’avais rejoint cette entreprise pour les aider dans leur transition. Xilinx était alors connue comme une entreprise spécialisée dans les FPGA. Et ils ont réalisé que, pour assurer leur croissance, ils devaient vraiment élargir leur champ d’action. J’ai donc été recrutée pour les aider à développer leur première gamme de produits SoC. J’ai contribué au lancement du produit Zynq, ce qui est intéressant – et je ne m’en rendais probablement pas compte à l’époque, mais c’est sans doute ce qui a marqué le début de mon parcours dans l’automobile – car l’une des toutes premières applications du Zynq concernait le domaine des systèmes d’aide à la conduite (ADAS) pour les caméras avant. Mais j’ai participé à la mise en place de la gamme de SoC Zynq, ce qui a vraiment constitué une grande transition pour Xilinx. C’était un système basé sur Arm, et nous avons travaillé avec vous sur les composants Arm, la propriété intellectuelle (IP). Et cela a complètement changé la donne pour Xilinx, car il s’agissait véritablement de dispositifs programmables par logiciel, prêts à démarrer. Nous fournissions des logiciels, notamment sous Linux, et aidions réellement nos clients en leur proposant un système sur puce prêt à l’emploi. Ils pouvaient alors y ajouter leur « recette secrète » pour se différencier, sur le FPGA.

JOHN : Exactement. C'est en quelque sorte l'un des premiers précurseurs des véhicules définis par logiciel, si l'on peut dire, qui intègrent le logiciel au matériel de manière innovante, je pense.

VIDYA : C'est vrai, c'est vrai.

JOHN : Après ça, tu as travaillé chez Tesla pendant un certain temps.

VIDYA : C'est vrai. En fait, j'ai passé toute ma carrière… J'ai commencé ma carrière en concevant des microprocesseurs dans une entreprise que la plupart des gens ne connaissent probablement pas aujourd'hui. Elle s'appelle DEC, ou plutôt s'appelait DEC.

JOHN : Moi aussi, j'ai travaillé chez DEC il y a des années.

VIDYA : Ah oui, c’est vrai. D’accord. Digital Equipment Corporation. J’y ai travaillé sur le microprocesseur Alpha, qui était en fait un microprocesseur pionnier à l’époque. J’ai consacré les tout débuts de ma carrière à la conception de systèmes sur puce (SoC) pour microprocesseurs. Puis, après Xilinx, où j’ai vécu une expérience vraiment passionnante en développant l’ensemble de la gamme de produits Zynq. Je cherchais à faire quelque chose de différent, et je voulais m’engager dans un projet qui, potentiellement, réunirait certaines de mes passions. L’une d’elles était le climat, et l’autre, l’ AI. Et j’ai vu en Tesla, au sein d’une industrie automobile en pleine mutation, un lieu où ces deux passions pouvaient se rejoindre. C’est donc cela qui m’a amenée dans le secteur automobile : ma passion pour le changement climatique et la volonté de lutter concrètement contre ce phénomène.

JOHN : C'est génial. Je veux dire, Tesla a réalisé beaucoup de choses incroyables, je dirais même qui ont bousculé les codes, en essayant des approches inédites qui n'avaient jamais été tentées auparavant. Mais aujourd'hui, tu travailles chez Rivian, où tu es depuis plusieurs années. Parle-nous de ton rôle au sein de l'entreprise et de ton champ de responsabilités.

VIDYA : C'est exact. Je travaille donc chez Rivian. Mon rôle consiste à diriger l'équipe chargée du matériel électrique chez Rivian. Le « matériel électrique », c'est en fait tout ce qui touche à l'électricité. C'est un terme assez large. Cela va jusqu’aux dispositifs à basse tension. Et depuis peu, je m’occupe également de la partie haute tension, c’est-à-dire de l’électronique liée au groupe motopropulseur. La partie basse tension, comme vous le savez, comprend tous nos contrôleurs, nos calculateurs (ECU), nos faisceaux de câbles, bref, tous les dispositifs électroniques que nous utilisons. Donc les écrans, le système audio, enfin, tout le…

JOHN : Rien d'important [sarcasme !]

VIDYA : Rien d'important. Ça fait avancer la voiture, je suppose.

JOHN : C'est incroyable. Et tu as… Je pense qu'on va aborder presque tous ces aspects au cours de notre conversation d'aujourd'hui.

Une anecdote surprenante et amusante sur Vidya

JOHN : On aime aussi faire connaissance avec nos invités dès le début. Tu dois nous révéler une anecdote amusante à ton sujet.

VIDYA : Bon, d’accord. Je dois avouer quelque chose. Je ne faisais pas partie de ces gens qui, vous savez, ont grandi en rêvant de voitures, en jouant avec des petites voitures ou en ayant des posters de voitures dans leur chambre. Si vous m’aviez parlé du secteur automobile il y a environ 15 ans, j’aurais éclaté de rire. Ce qui m’a amenée ici, c’est vraiment ma passion pour la technologie et, comme je l’ai dit, la lutte contre le changement climatique. Les gens partent toujours du principe que, quand on travaille dans une entreprise automobile, on est forcément un mordu de voitures. Je dois avouer que ce n’est pas ce qui m’a amenée ici.

JOHN : Je pense que ma situation est identique. J’aime toujours mettre mes invités en valeur. Et je dirais que mon parcours est exactement le même. J’ai travaillé sur les microprocesseurs, dans le matériel informatique, l’architecture informatique, et bien d’autres domaines. Je ne m’étais jamais imaginé mettre mes compétences au service de l’automobile. Mais comme vous l’avez mentionné, l’un des aspects – ou plutôt deux aspects majeurs qui se rejoignent dans le secteur automobile – est l’incroyable intégration technologique qui s’opère actuellement dans ce domaine. Et puis, le deuxième, c’est l’écologie… la durabilité. Je trouve que ces deux aspects sont formidables. C’est l’une des raisons pour lesquelles je suis moi aussi ravi d’évoluer dans ce secteur. C’est vraiment passionnant. Je suis également particulièrement ravi de vous avoir ici, car je suis un grand fan de Rivian. Je conduis des véhicules électriques depuis, je crois, environ 12 ans. Mon contrat de location actuel arrive bientôt à terme, et j’ai vraiment hâte d’opter pour une Rivian comme prochaine voiture. Je suis donc très enthousiaste à cette idée.

Mais aussi l’incroyable travail d’ingénierie que vous avez accompli. La R1 est une plateforme révolutionnaire en soi, mais vous venez d’annoncer – et nous en parlerons sans doute longuement aujourd’hui – la R1 de deuxième génération, qui présente des innovations incroyables de bout en bout, dont vous avez participé à bon nombre. Vous avez également annoncé… Rivian a également annoncé la R2 et d’autres modèles qui suivront, vous savez, dans deux ans.

Le changement de mentalité nécessaire à la création d'un SDV

JOHN : Rivian est donc à l'origine d'innovations incroyables. Et je pense que vous incarnez parfaitement l'esprit d'innovation de ce secteur. Nous sommes donc ravis de vous accueillir parmi nous.

Ainsi, lorsque nous réfléchissons à la transition vers les véhicules à conduite autonome (SDV) – et nous abordons ici, sur The Garage, de nombreux aspects de cette transition –, je pense toutefois que ce n'est pas un changement isolé qui permet d'aboutir à un SDV. Ce n'est pas comme si l'on basculait un simple interrupteur et que, d'un seul coup, on se retrouvait face à un SDV. Il s'agit d'un véritable changement de mentalité concernant la manière dont on conçoit le véhicule, le matériel, les logiciels et les réseaux. Et l’une des choses les plus impressionnantes dans le travail que vous accomplissez chez Rivian, c’est que vous montrez vraiment comment tout cela peut être réalisé, notamment avec cette récente évolution du R1 vers le R1 Gen2.

Regroupement des ECU

Votre R1 de première génération était déjà très impressionnante, mais la nouvelle génération passe à la vitesse supérieure. Commençons donc peut-être par le premier de ces aspects. C’est d’ailleurs un peu mon préféré : la consolidation et l’intégration des calculateurs (ECU). Car on ne peut pas avoir de SDV sans partager fondamentalement le matériel. L’une des caractéristiques qui distinguent un véhicule défini par le matériel (HDV) d’un véhicule défini par logiciel (SDV), c’est qu’un boîtier ne remplit qu’une seule fonction, pour toujours. Or, ce n’est pas le principe d’un véhicule défini par logiciel. Dans un véhicule défini par logiciel, un boîtier doit remplir plusieurs fonctions, partager la puissance de calcul et isoler les charges de travail entre tous les composants. Vous avez accompli un travail incroyable chez Rivian. Le modèle R1 de première génération comptait déjà 17 ECU, ce qui est bien moins qu’un véhicule classique. Vous répondiez donc déjà aux critères du SDV. Mais pour la deuxième génération, que vous venez d’annoncer il y a quelques mois, vous avez réduit ce nombre à seulement sept ECU principaux, plus quelques autres ECU de moindre importance. Sept ECU. C’est incroyable ! Parlez-nous de ce parcours et de votre philosophie qui vous a permis d’en arriver là.

VIDYA : D'accord. Pour commencer, je tiens à vous dire que nous serions ravis de vous proposer l'un de nos véhicules à trois ou quatre moteurs. Alors, dès que vous serez prêt, n'hésitez pas à nous contacter.

Réflexion systémique

VIDYA : Oui, vous avez tout à fait raison. Il ne s’agit pas seulement, vous savez, de savoir comment on obtient un véhicule défini par logiciel. Il ne suffit pas de dire : « Je veux en construire un », mais tout commence en réalité par le matériel. Et cela commence même avant de construire le matériel. Ça commence par la conception du système. On part donc de zéro. Et c’est, je pense, ce qui nous différencie. Dès le tout début, nous considérons le véhicule dans son ensemble comme un seul et même système électrique. Et tout le monde s’accorde à dire qu’aujourd’hui, une voiture est, en quelque sorte, un ordinateur sur roues. Ce n’est pas un seul ordinateur, mais un ensemble d’ordinateurs en réseau. Des ordinateurs très variés, en fait. Si l’on examine la diversité des types d’ordinateurs, on trouve des systèmes de calcul haute performance, mais aussi des systèmes de calcul en temps réel, dont les performances ne sont pas aussi élevées. On observe une diversité de capacités de calcul que l’on ne retrouve nulle part ailleurs. Sans oublier les actionneurs, les capteurs, et tout cela réuni.

JOHN : Et les systèmes critiques pour la sécurité aussi.

VIDYA : Et où la sûreté et la sécurité sont essentielles.

JOHN : C'est vrai.

VIDYA : Parce qu’on ne veut pas que quelqu’un d’autre prenne le contrôle. C’est donc un système très complexe, composé de nombreux capteurs, actionneurs et types de calcul complexes. Et il faut le considérer comme un seul et même grand système. Nous adoptons une approche « à partir d’une feuille blanche ». Et c’est justement ce qui, selon moi, pose traditionnellement problème aux équipementiers : quand on achète un boîtier à un tiers, on se demande comment assembler tous ces boîtiers. Or, le résultat n’est jamais optimal, car on ne peut pas simplement empiler un tas de composants ; c’est un tri qui se fait en quelque sorte de bas en haut, ce qui ne fonctionne pas. C’est pourquoi nous partons d’une feuille blanche. Nous examinons toutes les tâches que nous cherchons fondamentalement à accomplir. Nous déterminons de quel type de puissance de calcul nous avons besoin pour celles-ci. Ensuite, nous examinons également – comme nous l’avons dit, nous avons parlé des capteurs et des actionneurs – le fait qu’ils ont tous un emplacement naturel dans le véhicule. Et nous constatons, bien évidemment, qu’il est souhaitable que la puissance de calcul — ou même pas tant la puissance de calcul que les E/S — soit très proche du capteur ou de l’actionneur lui-même. Car l’un des gros problèmes dans les véhicules, ou plutôt l’un des principaux facteurs de poids, provient du câblage. Nous considérons donc cela comme un système vraiment complexe qu’il faut optimiser selon de très nombreux vecteurs différents. N’est-ce pas ?

Ainsi, lorsque nous avons lancé Rivian, notre objectif était de proposer à nos clients un produit vraiment convaincant, doté de la meilleure technologie disponible. Le bon compromis pour nous à ce moment-là était une architecture par domaine, qui représente déjà un niveau de consolidation supérieur à celui utilisé par de nombreux autres équipementiers. Dans une architecture par domaine, on dispose d’un calculateur (ECU) par groupe ou par catégorie de fonctions. Ainsi, par exemple, nous avions 17 calculateurs – développés en interne – qui contrôlaient différentes catégories de fonctions. Par exemple, le calculateur de carrosserie, qui contrôle l’éclairage, les portes, les essuie-glaces, c’est-à-dire tout ce qui est lié à la carrosserie, comme son nom l’indique. Un autre contrôleur était dédié à la dynamique du véhicule. Tout cela nous a réellement permis de disposer d’équipes logicielles spécialisées travaillant sur un seul contrôleur à la fois, ce qui constituait un moyen très efficace de commercialiser un produit. Et un produit convaincant, pas n’importe quel produit.

Et comme je l’ai dit, encore une fois, vous savez, les anciens équipementiers auraient eu besoin de nombreux contrôleurs pour faire le travail d’un seul de nos contrôleurs de domaine. C’est donc ainsi que nous avons commencé. Nous nous sommes lancés, je crois… Et je pense aussi que dès le tout début, et je devrais probablement en parler. Notre objectif a toujours été d’être intégrés verticalement. Notre intention n’a jamais été de dépendre de composants matériels provenant de différents fournisseurs. C’était donc très clair pour nous dès le départ.

Conception de systèmes à partir de puces disponibles dans le commerce

JOHN : Exactement. Je pense que, même si, d'une manière générale, on utilise des processeurs provenant d'autres domaines que l'ingénierie des systèmes pour les intégrer dans ce qu'on appelle communément des « ordinateurs », une grande partie de ce travail est réalisée en interne.

VIDYA : C’est pour ça qu’on a fait ça. Oui. Ça a toujours été notre intention. On achète des puces disponibles dans le commerce, mais on les intègre dans nos systèmes. C’est logique pour nous.

JOHN : Oui, je pense aussi que c'est un bon compromis, car ça évite de réinventer la roue. Il existe déjà beaucoup de ressources informatiques performantes, mais l'intégration du système doit être adaptée à l'usage prévu.

VIDYA : C'est vrai. Tout à fait. Et même si elle est adaptée à l'usage prévu, ce que je tiens à souligner, c'est que nous la concevons pour être évolutive. Nous utilisons donc les mêmes calculateurs que ceux équipant nos véhicules Amazon, que nous appelons les EDV, et ce sont les mêmes que ceux de la plateforme R1S / R1T. Ainsi, même s’ils sont conçus pour un usage spécifique, ils sont conçus pour être évolutifs. Et si l’on compare l’EDV, qui est un véhicule vraiment imposant, et le R1, on constate qu’ils sont très différents.

JOHN : Exactement.

VIDYA : Et on peut vraiment répondre aux besoins des deux avec un seul équipement.

JOHN : L'un des avantages des véhicules définis par logiciel, c'est que l'infrastructure de base peut rester la même, mais qu'il est possible de personnaliser les accessoires, les périphériques ou d'autres éléments de ce genre.

VIDYA : Exactement. Oui.

Passage du domaine à la zone

JOHN : C'est formidable. Donc… Vous avez évoqué une architecture par domaine. Maintenant que vous êtes passés à la plateforme R1 de deuxième génération qui vient de sortir, l'une des choses que vous avez faites est de passer à une architecture par zone, ou plutôt de vous orienter davantage vers ce type d'architecture. Pouvez-vous nous parler de cette évolution et de ce qu'elle vous a permis de réaliser ? Car la simplification du câblage que vous avez réussi à mettre en place est vraiment impressionnante.

VIDYA : C'est exact. Comme je l’ai dit tout à l’heure, l’un de nos objectifs pour la Gen 1 était de commercialiser rapidement un produit attractif. Ensuite, pour la Gen 2, notre objectif était de savoir comment l’optimiser davantage. Et cette optimisation passe en grande partie par l’amélioration de la fabrication et la réduction du poids. Il n’y en a pas beaucoup… certaines de ces optimisations sont évidemment visibles pour les clients, mais la plupart ne le sont même pas. Si vous regardez la R1 Gen 2, la plupart des gens ne seraient pas capables de faire la différence avec une R1 Gen 1 ; à moins d’être un véritable expert, vous pouvez remarquer la différence au niveau des caméras. Mais tout cela était très délibéré, car nous sommes passés d’une architecture basée sur les domaines à une architecture par zones, ce qui nous a permis de passer de 17 calculateurs à 7. Cela, vous savez… et en quoi est-ce important ? C’est vraiment important, car cela nous aide à réduire la masse de 44 livres. Nous avons réduit la longueur de câblage de 1,6 mile, ce qui est énorme ; pour un véhicule électrique, la masse a une très grande influence sur l’autonomie. Et puis, moins il y a de câbles, moins il y a de connexions à réaliser en usine. On a besoin de moins de personnel, ou on peut terminer l’assemblage d’une voiture plus rapidement. En réalité, ces optimisations, dont beaucoup se trouvent sous le capot, contribuent grandement à rendre Rivian plus efficace dans son processus de fabrication. Elles permettent d’utiliser le pack de batteries plus efficacement pour obtenir une plus grande autonomie. Certaines d’entre elles ne sont donc pas vraiment visibles pour le grand public, mais elles rendent le véhicule bien plus efficace à tous les niveaux.

Et nous avons effectivement mis en place d’autres optimisations de performances. Par exemple, l’ADAS. Nous avons considérablement amélioré notre puissance de calcul. Mais la question clé est la suivante : pourquoi n’avons-nous pas adopté une architecture par zone dès le départ ? Ce n’est pas comme si nous ne savions pas qu’il était possible d’en créer une. Mais la mise en œuvre concrète d’une telle architecture implique une grande complexité logicielle. Et lorsque nous disposions auparavant d’une architecture par domaine, c’était pour nous le moyen le plus rapide de démarrer. Et c’était important pour une entreprise de notre taille de pouvoir le faire. Car, comme je l’ai mentionné plus tôt, vous aviez une équipe qui travaillait sur le module de gestion thermique. Vous aviez une autre équipe. Avec une architecture par zone, vous avez toutes ces différentes fonctions. Chaque calculateur, désormais dans sa propre architecture, fonctionne sur l’espace physique, du moins en ce qui concerne la partie E/S, il fonctionne sur l’espace physique qui l’entoure.

Ce qui signifie, vous voyez, qu’autrefois – j’adore prendre l’exemple de l’éclairage –, un contrôleur d’éclairage gérait tout l’éclairage du véhicule. On avait donc des câbles qui serpentaient partout dans le véhicule à partir d’un seul point. Avec le contrôleur de zone, c’est le contrôleur le plus proche de la source lumineuse physique qui gère ses E/S. Mais cela signifie que pour obtenir cette simplicité matérielle, la complexité logicielle a augmenté. Désormais, chaque contrôleur de zone est capable de gérer l’éclairage. Et vous avez désormais plusieurs équipes qui travaillent sur des domaines différents. Elles opèrent désormais sur le même processeur physique, ce qui signifie qu’elles doivent apprendre à répartir la charge de calcul entre les microprocesseurs. Il y avait donc une raison pour laquelle nous n’avons pas adopté cette approche dès le départ, mais cela nous permet aujourd’hui de construire une base matérielle bien plus solide, ce qui apporte des avantages en termes de coût, de masse, ainsi que de nombreux autres bénéfices, notamment en matière de durabilité, etc.

Architecture par zones de la Rivian R1 Gen 2

JOHN : Donc, cette transition vers les architectures zonales – dont nous parlons beaucoup dans le podcast – est vraiment intéressante pour les raisons que vous avez évoquées. On a trois zones : avant gauche, avant droite et arrière. Mais on a aussi quatre calculateurs principaux : un pour l’infodivertissement et l’autonomie (notamment la navigation et les systèmes ADAS), un pour la gestion de la batterie, un pour le contrôle d’accès, et enfin un calculateur dédié à la technologie NFC au niveau des portes. Vous disposez donc toujours de blocs de calcul très performants, en particulier, par exemple, celui dédié à l’infodivertissement et à l’autonomie, qui offre des performances incroyables. Il repose sur deux processeurs Nvidia Orin, qui délivrent 250 TOPS, soit 250 000 milliards d’opérations « AI » par seconde, ce qui est incroyable. Expliquez-nous comment vous avez trouvé le juste équilibre entre ces calculateurs haute performance et cette conception développée en interne.

VIDYA : Tout à fait. Je pense donc que l'ordinateur de zone concernait principalement des aspects tels que les fonctions corporelles, la dynamique et la gestion thermique.

JOHN : Les capteurs, surtout.

VIDYA : Oui, des capteurs. Mais je dirais plutôt des capteurs non liés à l’ADAS, car, vous savez, il existe tellement de types de capteurs différents. Nous avons donc intégré toutes ces fonctionnalités, qui sont souvent sensibles au temps réel, dans les contrôleurs de zone. Ce n’est pas le cas de toutes, mais beaucoup le sont, car il faut réagir en temps réel. Et puis, nous avons délibérément choisi de séparer l’infodivertissement et l’ADAS. Eh bien, tu sais, parce qu’ils sont très différents de ce qui se passe dans les contrôleurs de zone. L’infodivertissement offre toutes les expériences avec lesquelles le conducteur ou le passager peut interagir. La télématique, tu sais, connecte le véhicule au Web ou à Internet. Et puis l’ADAS est en quelque sorte un autre système très puissant, qui recueille vraiment toutes les informations provenant des différents capteurs. Tu sais, nous sommes une entreprise multimodale.

Vous savez, on utilise des radars, des caméras, des IMU, des GNSS, tout ça. Et puis, bien sûr, le système ADAS traite toutes ces informations et commande les actionneurs. Le système d'infodivertissement et le système ADAS sont donc tous deux très complexes, et ils ont vraiment des besoins informatiques élevés. Le système d'infodivertissement, parce qu'il doit afficher tous ces graphismes riches. Ce sont des types de besoins très différents.

Il était donc très clair pour nous que les systèmes de zone formaient un ensemble. L’infodivertissement et la télématique formaient un ensemble. L’ADAS formait un ensemble. Même si, physiquement, nous avons regroupé l’ADAS et l’infodivertissement dans un seul boîtier. Et puis, l’accès au véhicule est tout simplement un cas à part. Ce n’est pas un calculateur aussi complexe que certains de ceux de l’infodivertissement ou de l’ADAS, mais il doit vraiment être placé de manière à pouvoir détecter l’approche de personnes. C’est donc pour cette raison qu’il s’agit d’une unité à part entière. Il en va de même pour le calculateur de la poignée de porte. Et puis nous avons un système de gestion de batterie qui est étroitement lié au bloc-batterie. Comme vous le savez, nous proposons deux types de batteries. Il est donc livré pré-assemblé avec la batterie. Il s’agit donc d’une unité distincte à part entière.

JOHN : Donc, c'est vraiment… Je pense que c'est un compromis technique très judicieux et intelligent. N'est-ce pas ? D'un côté, on a les zones qui effectuent des tâches physiquement proches des éléments concernés, où le temps réel est crucial et où la longueur du câblage est un facteur déterminant. Mais de l'autre, ces modules de calcul haute performance – d'une manière générale – se chargent de ces autres tâches spécifiques.

Réseaux embarqués et Ethernet automobile

JOHN : Parlons des réseaux embarqués. Vous avez mentionné tout à l’heure que vous aviez réussi à réduire de 1,6 mile la longueur du câblage à l’intérieur du véhicule, ce qui est une quantité impressionnante, ainsi que de 44 livres de câbles, si je me souviens bien. Cela simplifie l’assemblage. Et cela allège bien sûr le poids du véhicule. Vous avez également changé de technologies de mise en réseau, car je crois que la dorsale de votre véhicule repose sur l’Ethernet automobile. Mais au sein des zones, la communication avec les capteurs peut toujours s’effectuer à l’aide de protocoles existants, tels que le CAN ou le LAN. Pouvez-vous nous en dire plus sur la mise en réseau de vos véhicules ?

VIDYA : Bien sûr. Je tiens tout d'abord à préciser que ces 44 livres ne provenaient pas uniquement des câbles, mais aussi de la consolidation de l'ECU.

JOHN : Bien sûr. D'accord.

VIDYA : Parce que, vous savez, la réduction du nombre de boîtiers en soi apporte déjà beaucoup. Donc oui, tout à fait. En fait, même sur les véhicules de la génération 1, nous avions déjà l’Ethernet automobile. Mais je dirais qu’il y a davantage d’Ethernet automobile dans cette génération. Ça a toujours été… C’était déjà une colonne vertébrale auparavant, mais c’est peut-être une colonne vertébrale encore plus solide cette fois-ci. Et je pense, vous savez, que l’Ethernet est remarquable pour toutes les raisons que tout le monde connaît et apprécie : les piles logicielles et la facilité de communication. La bande passante, évidemment, mais ce n’est pas… Il n’en est pas encore au point aujourd’hui de pouvoir servir de support de communication partout. Le CAN et le LAN sont vraiment, vous savez, bon marché et simples. Et leur principal atout, c’est la capacité multipoint du CAN. Alors qu’avec Ethernet, il faut vraiment installer des commutateurs partout. Je sais qu’il existe une nouvelle technologie Ethernet : le 10-Base T1S. Mais vous savez, elle n’en est pas encore là où nous en avons besoin. Donc oui, nous utilisons une approche hybride. Nous utilisons Ethernet comme une sorte de dorsale solide pour la bande passante. Nous utilisons également les capacités de synchronisation temporelle d’Ethernet. Mais quand il s’agit de communiquer avec, disons, les actionneurs, cela dépend des types d’actionneurs et de capteurs. Certains, comme le radar par exemple, fonctionnent encore très bien avec Ethernet, mais pour certains capteurs et actionneurs, nous utilisons encore largement le CAN et le LAN au niveau local. Exactement. Cela nous aide donc à limiter l’utilisation du CAN et du LAN aux zones concernées. Et pas partout… Nous avons bien du CAN sur tous les véhicules. Il est toujours présent. Mais pas de manière aussi étendue que dans les générations précédentes.

JOHN : Je suppose donc que cela signifie que vous continuez à transmettre par Ethernet certains signaux essentiels à la sécurité, n'est-ce pas ? Car vous utilisez un réseau à temps réel pour certains signaux de sécurité transmis par Ethernet.

VIDYA : Exactement. Et je pense que cela dépend de la façon dont on définit la sécurité : par exemple, les airbags, la communication… Tout cela s’effectue via des canaux de communication dédiés, entre les capteurs et les unités de contrôle des airbags, et passe par des câbles spécialisés. Mais oui, nous utilisons bien sûr, par exemple – je reprends ce cas –, les données provenant d’un radar ou d’un autre système qui transitent par un réseau Ethernet. Oui. Mais nous disposons d’une architecture de sécurité très robuste. Comme je l’ai mentionné tout à l’heure, nous mettons l’accent sur les avantages qu’il y a à concevoir l’architecture complète du véhicule comme un système. Nous analysons la décomposition de la sécurité fonctionnelle de l’ensemble du système au niveau du véhicule et nous nous assurons qu’elle est très robuste.

Architecture logicielle

JOHN : Eh bien, c'est une transition parfaite. Parlons de l'architecture logicielle de manière plus générale. En effet, avec cette philosophie qui consiste à adopter une approche intégrée verticalement, vous avez dû réfléchir de manière globale. Parlez-nous donc des compromis que vous avez dû faire et des choix que vous avez opérés dans ce domaine.

VIDYA : Tout à fait. J’ai beaucoup parlé du matériel, car c’est sur ce point que travaillent mes équipes. Mais notre équipe logicielle a vraiment fait un travail remarquable à cet égard. En effet, nous n’utilisons aucune des solutions proposées par le secteur, comme AUTOSAR. Nous avons vraiment tout développé nous-mêmes ; nous abordons cela sous deux angles. Si vous y réfléchissez bien, nous développons… Nos contrôleurs de zone reposent sur un système interne très robuste, développé par nos équipes, ce qui nous a apporté une agilité remarquable en termes de rapidité de développement des fonctionnalités, de conception du matériel, de tests et de mise en service.

Et cela repose effectivement sur Free RTOS, mais nous y avons ajouté de nombreuses couches supplémentaires. Cela s'est avéré être un outil très puissant pour nous. De la même manière, en matière d'autonomie, même si nous utilisons les processeurs de Nvidia, nous croyons fermement à l'importance de développer nous-mêmes les couches applicatives et les couches de middleware, etc.

Nous utilisons bien sûr les éléments de base fournis par Nvidia, mais nous avons également développé notre propre pile logicielle dans ce domaine.

JOHN : C’est fantastique. Et je note que nous avons évoqué tout à l’heure que vous disposez de cette incroyable capacité de 250 TOPS, et nous avons discuté avec plusieurs autres équipementiers dans ce podcast du fait qu’il leur est parfois difficile de justifier une marge de manœuvre dans leurs capacités. J’ai également écouté plusieurs podcasts de votre PDG, qui a très clairement expliqué votre philosophie : vous voulez vous assurer de pouvoir planifier l’avenir et étendre vos capacités. Parlez-nous de cette décision que vous avez prise d’intégrer une marge de manœuvre.

VIDYA : Tout à fait. Et je pense que dans ce domaine précis, entre la Gen1 et la Gen2, comme je l’ai dit, bon nombre des changements visaient davantage à réduire nos coûts, à faciliter la fabrication, etc. Mais dans le domaine des systèmes ADAS, il est très clair que nous avons prévu une marge de manœuvre importante. Vous savez, notre capacité de calcul est 10 fois supérieure à celle de la génération précédente. Nous disposons de plus de capteurs ; nos caméras sont de huit mégapixels. Donc, de la détection au calcul, nous avons vraiment fait passer notre système ADAS à un niveau supérieur. Et nous avons clairement prévu une marge de manœuvre, car je pense que notre parcours dans le domaine des logiciels ADAS ne fait que commencer.
Et il y avait vraiment un long chemin à parcourir… Nous constatons déjà que nos équipes sont tout à fait capables d'exploiter tous ces TOPS. Et, vous savez, compte tenu de notre expérience antérieure dans la conception de microprocesseurs, ce logiciel va utiliser toute la puissance de calcul et toute la mémoire que vous lui fournirez. Mais nous constatons déjà que si vous commencez à utiliser tous les modèles de nouvelle génération basés sur les transformateurs, tous ces modèles sophistiqués, vous aurez besoin de ces TOPS, et même davantage, franchement.

Systèmes d'aide à la conduite (ADAS) et conduite autonome

JOHN : Et en matière d’autonomie – enfin, les systèmes ADAS et l’autonomie, selon le point de vue que l’on adopte –, les mentalités sont encore en pleine évolution, tout comme la réglementation. Je pense donc que l’on commence – d’après ce que j’ai entendu –, par un niveau modeste de… enfin, de capacités incroyables. Mais on laisse également la porte ouverte à l’avenir : à mesure que les attentes du public grandissent et que la réglementation se renforce, on pourra aller de plus en plus loin.

VIDYA : C'est vrai. Et je pense, tu sais, que ce que je dirais, c'est que tu as tout à fait raison. Tout d'abord, quand les gens parlent d'autonomie… Notre équipe s'appelle « Autonomie », mais en réalité… c'est un continuum. Ce n'est pas un niveau quatre. Tu sais, on n'entre pas vraiment dans ce débat. Je pense qu’en réalité, tout le parcours de l’autonomie… C’est tout ce parcours qui a rendu possibles toutes les fonctionnalités de sécurité présentes dans les véhicules aujourd’hui, comme, par exemple, le freinage d’urgence automatique. Donc, en fait, cela englobe vraiment l’ensemble des fonctionnalités de sécurité ainsi que les capacités de conduite autonome. Et ce que nous avons fait consciemment, c’est de vraiment garder une marge de manœuvre, car toute notre philosophie repose sur les améliorations via OTA, qui permettent d’ajouter davantage de fonctionnalités par mise à jour à distance. Et, vous savez, les systèmes ADAS sont bien plus sophistiqués – qu’il s’agisse d’autonomie ou d’ADAS –, car pour ajouter réellement de plus en plus de fonctionnalités au fil du temps, il existe une boucle complexe d’ AI , qui implique la collecte de données et l’apprentissage, et cela prend du temps. Nous savons donc que nous sommes engagés dans cette voie, mais nous savons aussi que cela prend du temps. C’est précisément pour cette raison qu’il est important de disposer d’une marge de manœuvre.

Retour d'expérience en vue d'une amélioration continue

JOHN : Et l’un des autres points dont vous avez parlé récemment, c’est le fait que vous disposiez d’une boucle de rétroaction très étroite – vous venez justement d’évoquer la rétroaction. Le fait de pouvoir récupérer les données d’utilisation de vos véhicules – anonymisées, bien sûr –, de les transférer dans le cloud pour en tirer des enseignements, afin que vos véhicules deviennent plus intelligents et que vous puissiez analyser une situation… Ah, le véhicule a réagi de cette façon, mais nous aurions dû réagir autrement. Et jour après jour, le véhicule s’améliore.

VIDYA : C'est vrai.

JOHN : Et ce cycle d’apprentissage est important. Nous en avons parlé sur Sonatus, où nous avons montré, à travers une démonstration, comment utiliser notre technologie pour faire quelque chose de similaire. Pour pouvoir envoyer un retour d’information au système ADAS en lui indiquant : « Tiens, il y a eu cette situation très étrange. Pourquoi cela s’est-il produit ? » Ou bien : « Pouvons-nous recenser ce genre de situations pour résoudre le problème à l’avenir ? » Je pense que c’est une boucle de rétroaction importante, comme vous l’avez mentionné.

VIDYA : Tout à fait. Je pense que c’est vraiment essentiel. Et en fait, c’est ce que nous faisons partout, pas seulement dans le domaine des systèmes d’aide à la conduite (ADAS), n’est-ce pas ? Nous disposons d’une marge de manœuvre dans tous nos systèmes, et nous apprenons sans cesse.

Mises à jour sans fil (OTA)

VIDYA : Et c’est justement là qu’réside un autre atout des véhicules définis par logiciel : la mise à jour OTA, n’est-ce pas ? Nous ajoutons sans cesse de nouvelles fonctionnalités et prévoyons de continuer à le faire tout au long de la durée de vie du véhicule. J’ai hâte d’y être, moi aussi. C’est exactement comme quand on reçoit une nouvelle mise à jour sur iOS, n’est-ce pas ?

JOHN : Tu en parles, d’accord, c’est parfait parce que j’espérais justement qu’on en discute un peu. Vos véhicules, dès aujourd’hui… Vous avez effectué plus de 30 mises à jour OTA depuis le lancement de vos véhicules. Vous avez proposé plus de 500 nouvelles fonctionnalités à vos clients. Sans oublier, bien sûr, les améliorations apportées au fonctionnement des fonctionnalités existantes. Parle-nous de votre philosophie en matière de mises à jour OTA. Nous en avons parlé l’autre jour.

VIDYA : Exactement. Et donc, pour nous, les mises à jour OTA sont essentielles, n’est-ce pas ? Elles sont essentielles parce que, pour diverses raisons, on sait que malgré tous nos efforts, des bugs peuvent survenir. Et on ne veut vraiment pas avoir à… Et si on découvre plus tard qu’on avait un logiciel buggé, ou parfois même du matériel buggé qu’on peut contourner par voie logicielle, mais si on avait un logiciel buggé… on ne veut vraiment pas que le client doive amener son véhicule au service après-vente. C’est gênant pour lui. C’est en fait une charge importante pour nous, en tant que constructeurs. Donc pour nous, les mises à jour OTA sont presque une exigence pour chaque composant matériel présent dans le véhicule et exécutant un logiciel. C’est notre philosophie. Très, très, très peu… Je veux dire, je dirais que les exceptions sont très mineures. Il faut que ce soit quelque chose de vraiment insignifiant et sans importance, dont on ne se soucie pas vraiment.

JOHN : Ouais. Tu as dit que tu avais une philosophie. Soit c'est stupide, soit c'est évolutif. C'est ça, ta philosophie ?

VIDYA : Exactement.

JOHN : Donc, un capteur simple, ça ira. On sait ce que le capteur va faire. Tout le reste devrait pouvoir être mis à niveau au fil du temps.

VIDYA : C'est vrai, et ça doit être vraiment simple. Peut-être une petite lampe qui présente des caractéristiques qui nous conviennent, et avec laquelle on ne risque pas de se tromper.

JOHN : Cela signifie donc, en substance, que vous vous engagez pleinement à mettre en place des mises à jour OTA sur l'ensemble du véhicule.

VIDYA : Exactement.

JOHN : Parce que je pense que beaucoup d'entreprises, quand elles parlent d'OTA, vont proposer une nouvelle fonctionnalité pour le système d'infodivertissement ou autre chose, tu vois, peut-être des systèmes d'aide à la conduite (ADAS), bien sûr. Mais la plupart des entreprises, je crois, ne s'engagent pas à déployer ces mises à jour sur l'ensemble de leur parc automobile de la même manière. Vous, en revanche, vous vous y engagez pleinement.

VIDYA : Tout à fait. Nous nous y engageons pleinement. Et nous prenons cela très au sérieux. Lorsque nous sélectionnons les composants au début du projet, c’est un critère essentiel. Évidemment, les calculateurs que nous développons en interne sont vraiment conçus pour les mises à jour OTA. C’est nous qui les concevons. Mais même lorsque nous nous approvisionnons auprès de fournisseurs – et nous utilisons effectivement certains composants de fournisseurs –, nous veillons à établir un accord clair avec eux et à définir un plan pour les mises à jour OTA. Vous savez, cela va des spécifications aux bootloaders, en passant par la sécurité, la sûreté et tout ce qui s’y rapporte. Et comme nous l’avons dit, il y a une multitude de raisons. L’une d’elles est simplement de pouvoir proposer de nouvelles fonctionnalités à l’avenir. Une autre consiste à corriger des bogues logiciels, et une autre encore, bien que très rare, consiste à contourner ce qui pourrait être un problème matériel.

Rivian R2

JOHN : Nous avons abordé tant de sujets intéressants jusqu’à présent. Je me demandais si vous pourriez conclure en nous parlant un peu du nouveau modèle R2, qui a été annoncé récemment. Tout le monde est très impatient de le découvrir. C’est encore un peu loin, la première mise en service étant prévue pour 2026. Parlez-nous un peu du R2.

VIDYA : C’est exact. Le R2 fait donc partie de ce que nous appelons notre « plateforme de taille moyenne », qui comprend en réalité le R2 et le R3. Nous les avons tous deux dévoilés plus tôt cette année. Le R2 sera lancé en premier, en 2026. En ce qui concerne l’architecture électrique, tout le travail que nous avons réalisé sur le R1 Gen2 s’apparentait en quelque sorte à un précurseur. C’était tout à fait délibéré. Cela n’a pas été fait uniquement pour le R1 Gen2, mais dans l’optique de créer une plateforme que nous reprendrions pour le R2. Ainsi, tout le travail que nous avons accompli pour mettre en place une architecture par zones sera repris. Ce ne seront pas exactement les mêmes calculateurs, mais des calculateurs modifiés. Ce concept d’architecture par zones sera repris sur la R2. Nous allons évidemment procéder à une refonte en profondeur de la plateforme d’infodivertissement, car on s’attend à ce que, d’ici là, les exigences en matière d’infodivertissement aient augmenté. Nous avons encore quelques autres atouts dans notre manche.

ADAS et autonomie… On s’est vraiment beaucoup concentrés sur les capteurs : on a considérablement amélioré leur performance, en passant par exemple de caméras d’un mégapixel à huit mégapixels. Nous pensons que c’est en réalité une configuration assez robuste et qu’elle restera inchangée. Et grâce à cela, nous pouvons exploiter toutes les données et l’entraînement que nous aurions effectués sur la plateforme R1 Gen2 et les transposer dans la R2. C’était donc, encore une fois, une décision très mûrement réfléchie que nous avons prise très tôt. Cela nous permettra ainsi de disposer d’une plateforme stable et pérenne en matière de capteurs.

Et puis une grande partie de l’innovation, en termes de… non, pas d’innovation, nous allons innover partout… mais l’effort d’intégration que nous avons mené, vous savez, en passant de 17 à 7 calculateurs. Du côté de la basse tension, nous allons en fait faire la même chose du côté de la haute tension. Nous allons donc chercher à faire preuve de plus d’ingéniosité dans la manière dont nous intégrons nos composants électroniques à faible consommation. Nous travaillons donc en permanence à l’amélioration de nos systèmes.

JOHN : Donc, d’un point de vue technique, il y a eu des compromis vraiment judicieux entre, tu sais, la R1 Gen1, la R1 Gen2, leur évolution, et les enseignements tirés de tout ça. Et on peut transposer une grande partie de ça à la R2. Mais il y a aussi, comme tu le dis, quelques astuces sympas dans ta manche et de superbes innovations.

VIDYA : Et puis, en réalité, ce qui nous intéresse vraiment avec la Gen2, c’est… Non, pas la Gen2, mais la R2 : il s’agit d’un prix plus bas. Donc, évidemment, nous nous penchons sur l’architecture par zones, nous intégrons tout cela et nous nous demandons : « Comment puis-je parvenir à un prix plus bas grâce à cela ? » Il y a donc beaucoup de travail d’optimisation à faire dans ce domaine. Mais nous pouvons désormais travailler sur une plateforme par zones plus stable.

Conclusion

JOHN : Eh bien, une période très passionnante s'annonce, tant du point de vue de l'ingénierie que de celui des pilotes et des passionnés d'automobile. C'est passionnant de voir tout le travail que vous accomplissez, et je suis très fier de vous compter parmi mes amis et de constater toutes les contributions incroyables que vous avez apportées à cette formidable entreprise et à cette formidable plateforme. Je vous remercie donc de vous être joint à nous.

VIDYA : Eh bien, merci de m'avoir invitée. Ça a été un plaisir. Et c'est incroyable. Tu sais, quand on quitte une entreprise, on se dit qu'on ne sait jamais quand nos chemins se croiseront à nouveau. Et je ne m'attendais vraiment pas à te retrouver alors que nous faisons tous les deux des choses similaires.

JOHN : Comme on est tous les deux en voiture, c'est ça. Merci beaucoup.

VIDYA : Merci. C'est avec plaisir.

JOHN : Si vous appréciez ce que vous voyez sur The Garage, nous espérons que vous mettrez un « J'aime » et que vous vous abonnerez pour découvrir d'autres épisodes comme celui-ci. Merci de nous avoir suivis et à très bientôt.