Les solutions informatiques de nouvelle génération pour les véhicules (2e partie)

Présentation générale

JOHN : Aujourd’hui, dans « the garage », nous vous proposons la deuxième partie de notre série en deux volets consacrée à NXP Semiconductors. À la fin de notre précédente discussion avec nos invités, Brian Carlson expliquait comment le véhicule à conducteur autonome (SDV) pouvait évoluer grâce à un large éventail de solutions en matière de semi-conducteurs et d’écosystèmes. Dans l’entretien d’aujourd’hui, nous allons poursuivre sur cette lancée et nous pencher sur l’avenir des véhicules, notamment les architectures zonales et la collaboration dans de nombreux autres domaines. C’est parti.

NXP collabore avec l'Sonatus e dans le domaine des logiciels automobiles

JOHN : Nous avons également constaté, comme vous l’avez mentionné, que vous comptez de nombreux ingénieurs logiciels, et pas seulement des ingénieurs matériel. Je veux dire par là que nous nous y attelons : nous rencontrons régulièrement certains de vos collaborateurs exceptionnels pour résoudre ces problèmes. Et nous sommes ravis d’y participer. Nous sommes ravis de développer des solutions sur l’ensemble de vos plateformes et de continuer à travailler avec vous à l’avenir. C’est donc une excellente collaboration.

BRIAN : Oui, tout à fait. Je veux dire, vous apportez une grande expertise dans le domaine des réseaux définis par logiciel. Et venant du secteur des infrastructures d’entreprise, ce que j’adore dans l’automobile, c’est que nous travaillons avec différents types d’entreprises qui ne sont pas des acteurs traditionnels de l’automobile ; nous avons d’ailleurs publié cette semaine une nouvelle version axée sur la sécurité, qui intègre véritablement les meilleures pratiques en matière de sécurité issues du monde de l’entreprise. Et maintenant, en collaborant avec vous qui venez du monde des réseaux, nous disposons également d’une grande expertise en matière de réseaux du point de vue matériel : si l’on remonte jusqu’à Motorola et son héritage – Motorola, Freescale, et aujourd’hui NXP –, nous sommes présents dans le domaine des réseaux numériques depuis de très nombreuses années. Et en ajoutant votre expertise logicielle à nos puces, cela crée une véritable force de frappe, n’est-ce pas ? C’est ce qu’on appelle le meilleur de sa catégorie, ce qui est vraiment apprécié par les équipementiers. Parce qu’ils en ont besoin. Je veux dire, ils développent leur propre expertise, mais en même temps, ce que nous constatons, c’est une collaboration avec les équipementiers et les fournisseurs de premier rang, mais surtout avec les équipementiers désormais. Ils souhaitent collaborer pour aller plus en profondeur. Nous accueillons ainsi des équipementiers pendant deux semaines, durant lesquelles nous approfondissons le sujet et travaillons également avec Sonatus pour leur montrer concrètement comment nous pouvons proposer une solution de bout en bout optimisée. Il ne s’agit pas simplement de leur dire : « Voici une puce de NXP, voici un logiciel que vous pouvez installer via Sonatus ». Nous travaillons réellement ensemble pour rationaliser ces processus et garantir leur efficacité. Et je pense que la clé réside justement dans ce type de partenariats. Pour simplifier les choses, car ce SDV, comme nous l’avons évoqué, est une véritable révolution.

La plateforme de véhicules « Sonatus »

BRIAN : C'est un véritable défi. Et il faut un tel niveau de collaboration pour que tout se mette en place.

JOHN : C'est exact. Vous avez évoqué le réseau. C'est justement un domaine dans lequel nous apportons un ensemble de compétences, grâce à de nombreux collaborateurs issus des secteurs des réseaux définis par logiciel et des réseaux de centres de données. L'une de nos activités consiste donc à fournir à nos clients une plateforme de configuration, que nous appelons notre plateforme « Foundation », qui leur permet de configurer, d'ajuster et de gérer les réseaux de leurs véhicules. Et je pense que c’est un atout considérable. Vous avez également évoqué certains de nos produits de données : notre produit « Collector » fonctionne aujourd’hui sur du matériel NXP, où nous effectuons une collecte de données très fine. C’est donc très stimulant de travailler à vos côtés et de contribuer à fournir ce type de solution combinée à nos clients équipementiers et à nos fournisseurs de premier rang.

Réseaux définis par logiciel dans le secteur automobile

BRIAN : Oui, c’est vraiment important. Et il y a une chose que j’aime souligner à propos des véhicules définis par logiciel : tout le monde parle des mises à jour à distance, de l’installation de nouvelles applications… Ce que j’apprécie, c’est que ce n’est pas simplement comme sur un smartphone ; pensez plutôt au moment où vous installez une nouvelle application ou un nouveau service n’importe où dans le véhicule. Il ne s’agit pas simplement de l’installer sur un serveur, mais de l’intégrer aux niveaux les plus bas, ce qui génère de nouveaux types de données, de nouvelles bandes passantes et de nouvelles caractéristiques. Et il faut réfléchir à la manière de gérer tout cela. On ne peut pas se contenter d’installer quelque chose, il faut configurer le réseau. Et avec ce tout nouveau réseau Ethernet, ce réseau sensible au temps, qui est essentiel pour l’infrastructure de ces véhicules, n’est-ce pas, il faut disposer d’un moyen de gérer la qualité de service et le déterminisme. Si l’on se contente de télécharger quelque chose sans tenir compte de l’ingénierie du trafic, ce qui est pourtant crucial… C’est tout ce concept de réseau défini par logiciel. Je trouve qu’on n’en parle pas assez. Nous essayons donc de sensibiliser les gens au fait qu’il s’agit d’un domaine crucial : il ne s’agit pas seulement de logiciels et de la possibilité de déployer sur des machines virtuelles, etc. Mais maintenant, qu’en est-il de l’accès aux données quand vous en avez besoin ? Qu’en est-il de l’obtention d’informations critiques et de leur transmission à travers le véhicule ? Si vous ne mettez pas en place une ingénierie du trafic adéquate, ou si vous ne disposez pas d’un moyen dynamique de reconfigurer le réseau pour le gérer, vous allez au-devant de problèmes. Et c’est ce que j’apprécie dans ce que vous faites, n’est-ce pas ? Vous offrez cette capacité, et vous permettez aux constructeurs automobiles de le faire. Oui. Et cela aide énormément, car de nombreux enseignements ont été tirés, n’est-ce pas ?

JOHN : Ouais, pas besoin de réinventer la roue.

BRIAN : Exactement.

Architectures zonales

JOHN : Je pense que c’est en fait une transition parfaite pour parler de « zonal ». Vous avez évoqué le « zonal » tout à l’heure. L’un des domaines dans lesquels nous collaborons étroitement avec vous consiste à préparer le terrain, si l’on peut dire, pour les réseaux « zonal » de nouvelle génération. Nous avons réalisé une démonstration fantastique lors du dernier Consumer Electronics Show [2023], et nous en parlons souvent. Nous avons organisé un webinaire avec NXP il y a quelques mois sur le sujet du « zonal » ; nous pouvons mettre un lien vers celui-ci dans la description de l’émission. Mais l’une des choses dont vous avez parlé concernant les réseaux embarqués en temps réel, c’est que je considère le « zonal » comme presque… en quelque sorte… vous avez évoqué le temps réel en termes de traitement ; le réseau « zonal » et l’utilisation de ces réseaux « zonal » de nouvelle génération, c’est comment garantir cette qualité de service ? Comment transposer ce temps réel dans les réseaux modernes, alors que les voitures ont toujours reposé exclusivement, ou en grande partie, sur des réseaux CAN ou d’autres technologies ? À mesure que nous passons à l’Ethernet automobile et à d’autres technologies plus récentes et plus configurables, il faut prendre conscience que tous les types de trafic ne se valent pas. Vous savez, je dois m’assurer que mon trafic sensible au temps arrive à destination quand il le faut, et j’ai peut-être du trafic non sensible au temps, comme de la vidéo ou d’autres éléments, qui pourrait partager les mêmes liaisons. Comment gérer cela ? Il s’agit bien de qualité de service, mais ce n’est pas statique : cela doit être ajusté à mesure que de nouvelles sources de trafic apparaissent, afin de garantir une transmission dans les délais.

NXP S32Z et NXP S32E pour les architectures zonales

BRIAN : Oui, exactement. Et c’est justement pour cela que cette collaboration dont nous parlons a été vraiment essentielle. Mais ce que nous faisons au niveau de nos puces, en particulier dans les zones, c’est d’y intégrer du matériel pour permettre cela. Exactement, et en les intégrant par exemple dans les modèles S32Z et E, qui disposent d’un commutateur Ethernet intégré offrant de nombreuses options de configuration, ainsi que de ports internes, je peux associer un port Ethernet à n’importe quelle tâche logicielle. On peut donc configurer et contrôler cela de manière dynamique en tirant parti, entre autres, des réseaux Ethernet sensibles au temps et de la capacité à effectuer des opérations directement dans la puce. Vous savez, l’un des enjeux majeurs est de savoir comment les équipementiers et les fournisseurs de premier rang vont passer du modèle actuel de boîtiers à ce concept d’ECU virtuels, n’est-ce pas ?

JOHN : Il leur faut une trajectoire d'approche.

BRIAN : Ils ont besoin d’une voie d’accès, c’est vrai, exactement, oui, ils ont besoin d’un moyen d’y parvenir. C’est un aspect vraiment important sur lequel nous nous sommes également concentrés, tant au niveau de nos appareils que de nos logiciels. Par exemple, GreenVIP est un logiciel qui vient se superposer à tout ça, mais on pose d’abord les bases avec la puce, en étant capables de tout virtualiser, d’isoler littéralement tout au niveau matériel, du cœur à la mémoire, en passant par les périphériques et les broches d’E/S. C’est ce qui est vraiment unique : on s’occupe de tout, ce n’est pas seulement une partie, on gère l’ensemble de bout en bout. Pensez donc à ce que nous pouvons faire : grâce à cette isolation matérielle, que vous pouvez activer, configurer de manière dynamique ou verrouiller en toute sécurité au démarrage. N’est-ce pas ? Et vous pouvez le faire. Vous êtes donc en mesure de faire en sorte que ce processeur ou cette tâche fonctionne comme autrefois. Ou comme aujourd’hui, où il s’agit d’un boîtier. Cela garantit ainsi une qualité de service et une bande passante dédiée pour l’accès aux mémoires, n’est-ce pas ? On a la garantie de pouvoir dire : « Je ne contrôle que ces E/S et ces temporisateurs », et tout ça. On est donc à l’abri de toute interférence. Tout commence donc par ce silicium qui permet de faire cela. Et puis cette couche logicielle, comme GreenVIP qui vient se superposer, permet aux utilisateurs de prendre réellement le contrôle de tous ces boutons et commutateurs et de configurer l’ensemble de la puce selon leurs besoins. Et une chose dont j’aime parler, c’est que je pourrais placer cette puce dans le cloud, dans un boîtier. Et vous pourriez avoir plusieurs fournisseurs de premier rang développant des logiciels sur la même puce, voire le même cœur, le même cœur Arm. Et ils ne savent même pas que les autres fournisseurs de premier rang existent. Et ce qui est vraiment important – on n’en parle pas beaucoup – c’est qu’il y a des problèmes liés à la propriété intellectuelle. Oui. Nous sommes donc désormais dans un monde d’intégration avec plusieurs fournisseurs de logiciels. On ne veut pas que, par exemple, le fournisseur de premier rang A et le fournisseur de premier rang B aient accès au code de la concurrence. Cela renforce également la confidentialité et la sécurité, car ils sont totalement isolés. On bénéficie ainsi du meilleur des deux mondes : on obtient la consolidation. Mais on conserve tout de même l’environnement de développement. Comme les boîtiers individuels, ainsi que la confidentialité et l’isolation, ce qui est vraiment essentiel pour les équipementiers. Si on ne dispose pas de ce type de technologie, ça ne fonctionnera pas dans le cadre du SDV. Donc, le matériel le met en œuvre, GreenVIP le configure, puis nous travaillons avec des partenaires, comme Sonatus, pour superposer leurs logiciels et leur contrôle par-dessus tout cela, depuis le cloud jusqu’aux zones.

Assurer une transition en douceur depuis les architectures CAN existantes

JOHN : Oui, et tu as mentionné que nous avions parlé de cette trajectoire de transition et de certains de ces composants matériels ; tu sais, le CAN n’est pas près de disparaître. Il va clairement rester d’actualité pendant un certain temps encore. Mais en même temps, on souhaite également utiliser l’infrastructure principale du véhicule pour passer à l’Ethernet automobile ou aux futures normes. Et les normes évoluent beaucoup en ce moment. Nous travaillons donc beaucoup avec vous sur des sujets tels que la conversion du CAN vers l’Ethernet, et sur l’utilisation de certaines de ces nouvelles normes de réseau TSN modernes de l’IEEE qui vous permettent de prendre un signal CAN, de le convertir en signal Ethernet, de l’envoyer de l’autre côté, puis de le reconvertir en signal CAN, ce qui vous évite de tout repenser d’un seul coup. Vous disposez ainsi d’une voie de transition et, parallèlement, certaines de ces normes intègrent des fonctionnalités très performantes, telles que la redondance, entre autres.

BRIAN : Oui, tout à fait. Je suis content que tu en parles. C’est vraiment important, car le SDV est un parcours. C’est un marathon, pas un sprint. Et pense à tout l’héritage dont disposent les équipementiers. En fait, ils disposent aujourd’hui de systèmes dont ils ne comprennent pas toujours parfaitement le fonctionnement, car ils ont été conçus il y a 10 ou 15 ans par des personnes qui ne sont plus là, et la documentation n’est pas toujours aussi complète qu’elle pourrait l’être. Ils doivent donc migrer ces systèmes. Nous travaillons d’ailleurs à aider les équipementiers à transférer ces éléments vers des plateformes comme celle-ci, mais dans certains cas, ils devront encore s’appuyer sur ces anciens systèmes. Le SDV et l’architecture zonale ne viennent donc pas comme par magie remplacer tout d’un coup. Certes, il y a des acteurs qui partent de zéro : la Silicon Valley, la Chine, par exemple, où le scénario est un peu différent. Mais les grands équipementiers ont un lourd héritage dont ils souhaitent encore tirer parti à certains endroits, et c’est davantage un marathon. Il faut donc être capable de prendre en charge certains de ces éléments qui ne relèvent pas de la zone. Il s’agit notamment des nœuds finaux ou des calculateurs électroniques (ECU) hérités. Ceux-ci utilisent encore le protocole CAN, ou commenceront à exploiter le CAN-XL – que nous prenons désormais en charge – afin d’offrir une vitesse et une bande passante accrues, entre autres. C’est donc indispensable pour prendre en charge ces héritages, car les interfaces héritées ne disparaîtront pas. Le CAN va donc perdurer pendant longtemps. Mais l’épine dorsale qui reliera réellement tout cela sera davantage l’Ethernet TSN. Et la redondance entre en jeu, cela en fait partie. Il est question de qualité de service, de déterminisme, de bande passante garantie, mais aussi de cette redondance, car que se passe-t-il si une ligne est coupée ? Il faut tout de même assurer le bon fonctionnement du véhicule.

JOHN : Et tu as évoqué tout à l’heure, dans le cadre de la « zone », que l’un des aspects essentiels est le poids. En ce qui concerne le poids du véhicule, la complexité du câblage et celle de l’assemblage des véhicules traditionnels constituent un obstacle majeur à la production. Je pense donc que c’est un point qui va être amélioré grâce à cette approche.

La transition progressive vers des architectures zonales via le « body zonal »

BRIAN : J’ai un exemple rapide à ce sujet, parce que les gens n’y pensent pas toujours. Mais parfois, vous savez, on a parlé de l’approche par zones, on a tout dit sur la transition. Et je pense que ça va parfois se faire par étapes. Si on regarde tous les équipementiers, chacun adopte une approche un peu différente. Certains suivent une démarche évolutive : ils passent d’une approche à une autre, puis adoptent peut-être une nouvelle approche quelques années plus tard. Ça ne va donc pas nécessairement se faire d’un seul coup en 24 ou 25 ; il y aura différentes étapes. Mais ce qui est intéressant, c’est que l’une de ces étapes progressives est ce qu’on appelle la « carrosserie par zones ». Et vous m’avez fait réfléchir à cela, car la fabrication est un énorme enjeu aujourd’hui, n’est-ce pas ? On voit ces gros câbles. Et on a entendu des anecdotes selon lesquelles il faut même chauffer les câbles pour pouvoir les faire passer dans la portière. Réfléchissez-y : nous voulons éliminer une grande partie de la complexité du câblage, car la fiabilité et la fabrication constituent un énorme enjeu. Si je peux réduire le temps de fabrication, cela se traduit par une marge plus importante pour mon véhicule, et je peux réduire mes coûts.

JOHN : Pour l'équipementier.

BRIAN : Pour les équipementiers. Oui, c’est énorme. Mais maintenant, on voit apparaître ce qu’on appelle le « body zonal », n’est-ce pas ? Il y a peut-être cette étape intermédiaire : bon, passons progressivement au « zonal », mais commençons par le « body », parce que ça nous offre un excellent rapport qualité-prix. Et c’est assez simple par rapport à la mise en place de tout le temps réel et de tout le reste qui doit être mis en place…

JOHN : Parce que c'est localisé…

BRIAN : C’est localisé. Imaginez donc que j’ai ces quatre zones. Et j’ai un seul boîtier, je fais passer un seul câble, pas 100, pas 100 fils dans un boîtier. N’est-ce pas ? Ça facilite la fabrication, ça me prépare pour l’avenir ; on commence à intégrer ces appareils, on commence à intégrer et à comprendre l’isolation, ainsi que la manière de développer dans un nouvel univers SDV. Et en même temps, on élimine du poids – tout ce poids lié à tous ces câbles –, ainsi que la complexité du cuivre, ce qui améliore la fiabilité et tout le reste. Je tenais donc à souligner ce point, car vous avez évoqué le fait que c’est un aspect essentiel à l’heure actuelle. Et dans certains cas, l’une des étapes pour les équipementiers consiste à se concentrer dans un premier temps sur la carrosserie, car cela apporte toute cette valeur ajoutée.

Soutenir une refonte complète ou une évolution progressive des véhicules

JOHN : Exactement, et je pense que si l’on prend un peu de recul, comme vous l’avez mentionné… il y a des entreprises qui sont plus audacieuses et qui adoptent une approche « table rase », d’autres qui s’en tiennent à leurs systèmes existants, et toutes sortes de cas intermédiaires. Et l’une des choses que nous faisons, et il semble que vous le fassiez aussi, c’est de montrer à nos équipementiers et à nos clients de premier rang qu’il n’est pas nécessaire de tout jeter. Si vous souhaitez repartir de zéro, c’est parfait, nous pouvons vous y aider. Mais si vous disposez d’une infrastructure existante, de capacités de base existantes, etc., nous pouvons vous aider à atteindre cet objectif futur au rythme qui vous convient. C’est tout à fait ça. J’ai eu des échanges avec des équipementiers. Et avec des fournisseurs de premier rang, d’ailleurs : cette semaine, plusieurs d’entre eux sont venus à notre salon, et nous avons eu ce genre de discussions, car ils essaient tous de déterminer quelle est la bonne voie à suivre. Comment gérer au mieux les risques, en somme ? Comment concrétiser ces propositions de valeur dont nous avons commencé à parler ? Comment y parvenir ? Même de manière progressive, comment obtenir le meilleur rapport qualité-prix ? Et comment y parvenir au fil du temps, car ils ont tous des contraintes. Tout le monde traverse cette phase : ils doivent recruter de nouveaux types de talents, ils doivent commencer… à travailler davantage de manière transversale, et les collaborateurs doivent penser à l’échelle du système, et non plus au niveau d’un composant ou d’un sous-système. C’est donc énorme. Mais ils doivent commencer à se demander : « Que puis-je faire en attendant, pendant que je transforme mon organisation ? Que puis-je faire pour y parvenir ? » Donc, ces discussions, que ce soit par votre intermédiaire, via le logiciel, la configuration, l’automatisation, ou par notre intermédiaire pour les puces, n’est-ce pas ? Et l’élément clé pour les puces, c’est l’évolutivité. La scalabilité, c’est donc de disposer de dispositifs compatibles qui, bien qu’identiques, offrent une évolutivité, des performances et un encombrement compatibles, ainsi qu’une compatibilité logicielle, tout en vous ouvrant la voie vers l’avenir, que ce soit au sein de la même famille de produits ou via une évolution future, comme ce que nous faisons avec les dispositifs en 5 nanomètres. Vous savez, nous nous tournons déjà vers l’avenir… nous avons des dispositifs en 5 nanomètres qui vont tout simplement faire passer cela au niveau supérieur.

Évolution de la gamme S32 et du NXP S32N

JOHN : Tu as dit qu’un nouvel épisode allait sortir, tu veux bien nous en dire un peu plus ?

BRIAN : Oui. Oui, les gens n’arrêtent pas de nous poser la question, c’est vrai. Nous avons présenté notre puce au Computex, notre première puce de test… une puce de test en 5 nanomètres. Nous disposons donc aujourd’hui d’une puce de test fonctionnelle. Nous avons un dispositif en 5 nanomètres, le tout premier d’ailleurs, le premier dispositif en 5 nanomètres, je crois, chez NXP. Elle s’appelle la S32N, et la S32N va jouer un rôle clé dans ces véhicules connectés (SDV). On ne nous en dit donc pas beaucoup plus que ça, si ce n’est qu’elle va arriver et qu’il existe une feuille de route, que je qualifierais de prometteuse, entre nos puces actuelles et la prochaine génération. Attendez-vous donc à des annonces passionnantes à ce sujet dans un avenir proche.

Développer aujourd'hui sur S32N virtuel dans le cloud

BRIAN : Et ce qui est intéressant là-dedans, et dont on n’a pas vraiment parlé, c’est : comment le processus de développement logiciel évolue-t-il ? Quel rôle joue le cloud ? Parce que c’est vraiment, je dirais, le point de basculement où tout est désormais développé dans le cloud. C’est à peu près ça, non ? Parce qu’avant la mise à disposition des puces, les puces destinées à la production vont bientôt arriver. Et comment est-ce que je développe en amont, n’est-ce pas ? On a donc évoqué le fait que le secteur parle de « shift left », c’est-à-dire d’avancer le développement logiciel d’un an, voire plus. Et c’est ce que nous vivons actuellement, n’est-ce pas ? Nous le vivons avec S32N, car des milliers d’ingénieurs développent effectivement des logiciels aujourd’hui. Et cela fait déjà un certain temps qu’ils développent dans le cloud, sur l’environnement virtuel S32N ?

JOHN : C'est tout à fait ça. Nous avons longuement discuté avec Stefano Marzani, d'AWS, de l'importance du prototypage dans le cloud ; c'était dans l'un de nos récents épisodes, où il a évoqué la possibilité, comme tu l'as dit, de développer des logiciels avant même que le matériel ne soit disponible, et de permettre aux ingénieurs de disposer d'une capacité de développement bien plus évolutive que s'ils étaient limités par du matériel physique. C'est donc un avantage vraiment important. Et c’est formidable d’apprendre que vous procédez de la même manière en interne, tant pour votre propre développement que pour le prototypage.

BRIAN : C’est clairement important, car il ne s’agit pas seulement du « shift left », mais aussi, vous savez, de projeter cela dans l’avenir, c’est tout le processus de développement continu. Comme vous l’avez dit, la voiture s’améliore au fil du temps. Donc, en réalité, nous soutenons non seulement le « shift left », mais nous l’étendons également vers la droite. Cela couvre ainsi l’ensemble du cycle de vie. L’infrastructure que vous mettez en place commence par le SoC, c’est-à-dire le boîtier, la zone ou le contrôleur, et consiste à les relier entre eux. Vous verrez donc des véhicules entiers se virtualiser et le jumeau numérique prendre une importance considérable. Il s’agit d’utiliser le cloud pour gérer l’ensemble du cycle de développement, pas seulement pour le développement, mais pour tout le cycle de vie de la voiture.

JOHN : Rien que sur ce sujet du prototypage, on pourrait passer une heure à en discuter.

BRIAN : C'est un sujet très vaste.

JOHN : Bon, on ne va pas s'y attaquer aujourd'hui. Mais on fera peut-être un autre épisode. On invitera peut-être Stefano à se joindre à nous pour une discussion à trois sur ce sujet. Parce que je sais que tu as beaucoup travaillé là-dessus. Tu as évoqué AWS, mais surtout en ce qui concerne le prototypage, tu as vraiment ouvert la voie.

La collaboration et la sensibilisation à la sécurité sont essentielles

JOHN : Bon, écoutez, on a eu une longue conversation. On a abordé tellement de sujets… Peut-être pourriez-vous nous faire part de vos dernières réflexions ?

BRIAN : Oui, je pense qu’on a abordé tous les points essentiels. Donc, pour résumer, il s’agit vraiment d’une disruption, mais d’une disruption positive qui vise à jeter les bases de l’avenir, ce qui va réellement permettre l’émergence de nombreux nouveaux cas d’utilisation, opportunités et sources de revenus, pas seulement pour les équipementiers, mais aussi pour l’écosystème dans son ensemble. Mais le fait est que cela nécessite une collaboration, ainsi que du matériel et des puces véritablement optimisés pour cela. En effet, si l’on ne dispose pas de cette base matérielle, les gens parlent d’abstraction du logiciel et du matériel, presque comme si le matériel n’avait aucune importance, comme si l’on pouvait simplement brancher une carte ici ou là. Ce n’est pas aussi simple qu’on le laisse entendre.

JOHN : C'est un partenariat.

BRIAN : C’est indispensable, et c’est là le point essentiel : le matériel doit être vraiment, vraiment performant. Je vois donc l’innovation comme un « sandwich » composé de différentes couches. Nous sommes, en quelque sorte, à la base, comme la tranche de pain du dessous, qui apporte l’innovation : comment faire cela de manière efficace, sûre et sécurisée. Et il faut y réfléchir : ce n’est pas un centre de données, ni un smartphone, ni les appareils sur lesquels les gens travaillaient auparavant. Ça ressemble davantage à un avion, n’est-ce pas ? Votre vie en dépend. On ne peut donc pas oublier que la sécurité est primordiale. Et ça doit être, vous savez, une préoccupation majeure. Beaucoup de gens parlent, oui, de véhicules définis par logiciel, mais la sécurité est indispensable : on ne peut pas faire les deux. Il existe certes des solutions, mais cela nécessite beaucoup de matériel et de logiciels pour prendre en charge ce système, le structurer en couches et le rendre réellement sûr. Ce n’est pas une mince affaire. C’est donc une question de collaboration. Un matériel basé sur des puces, conçu pour les SDV, qui assure la sécurité et la sûreté dans l’ensemble du véhicule, pas seulement au niveau de certains modules, mais à l’échelle de l’ensemble du véhicule. C’est la mise en œuvre logicielle et les partenariats, l’écosystème – comme notre collaboration avec Sonatus – qui permettent d’apporter ici les capacités et l’expertise issues d’autres marchés et d’autres domaines, puis de tout rassembler et de travailler en étroite collaboration avec les équipementiers et les fournisseurs de premier rang pour proposer une solution de bout en bout. Je dirais donc que la conclusion à retenir est que cela nécessite la collaboration de l’ensemble du secteur ; un seul acteur ne peut pas tout faire à lui seul.

Deux points essentiels

JOHN : Oui. Et ce que j’ai retenu de la conversation d’aujourd’hui, ce sont deux points clés. Le premier, c’est qu’il y a ce… continuum. Ce n’est pas… il n’y a pas un seul changement : on ne se contente pas de remplacer le système par un ordinateur central, d’installer un serveur dans le coffre et c’est tout. Ça ne va pas résoudre le problème. Il faut une solution hétérogène qui réponde à différents besoins. Et ça doit fonctionner en temps réel. Le deuxième point que tu as mentionné et que je trouve vraiment convaincant, c’est que cette transition vers le SDV est un véritable parcours. C’est un marathon, pas un sprint, comme on dit. Mais je pense que c’est une analogie assez pertinente : il y aura des transitions, et chaque constructeur automobile évoluera à des rythmes différents selon les parties du véhicule concernées, en résolvant des problèmes spécifiques. Et vous savez, je pense que cela nécessite un partenariat : le matériel et les logiciels doivent travailler ensemble pour aider chaque constructeur automobile et chaque équipementier de premier rang à atteindre cet objectif à son propre rythme, selon la manière dont il se sent prêt à le faire.

Conclusion

JOHN : Nous sommes donc ravis de nous associer à vous.

BRIAN : Tout à fait.

JOHN : Et j'ai hâte de prendre la route au volant de ces véhicules de série…

BRIAN : Et on dit « Salut NXP » et « Sonatus » à l'intérieur, c'est ça ?

JOHN : Moi aussi ! Ça me fait sourire à chaque fois que j'en vois un ! Alors, merci beaucoup, Brian, d'avoir participé à « The Garage ». On est vraiment ravis de t'avoir eu parmi nous.

BRIAN : Je suis ravi d’avoir eu cette opportunité. J'ai regardé ces épisodes, et je dois dire que j'adorerais pouvoir discuter avec vous. J'adore discuter avec vous, et le SDV est un sujet tellement passionnant parce que, comme je l'ai dit, il y a tellement d'angles différents à aborder. Comme je l'ai dit, c'est une mine d'or, et vous avez encore toute une série d'épisodes passionnants à venir ; je suis sûr que vous saurez mettre tout cela en lumière pour votre public. Merci pour cette opportunité.

JOHN : Merci beaucoup. Nous apprécions que vous ayez apporté un point de vue différent à l'épisode d'aujourd'hui.

BRIAN : Merci, John.

JOHN : Un grand merci, Brian. Aujourd’hui, nous avons abordé le sujet des véhicules définis par logiciel sous un angle nouveau, celui du matériel, en examinant comment les puces électroniques, associées à nos partenaires de l’écosystème, peuvent véritablement faire la différence pour ces véhicules. Nous espérons que cette conversation vous a plu. Si vous appréciez le contenu proposé par The Garage , n’hésitez pas à « aimer » cet épisode et, mieux encore, à vous abonner pour ne pas manquer nos prochains épisodes. Merci de nous avoir suivis et nous avons hâte de vous retrouver très bientôt sur The Garage .