Arm : faire des SDV une réalité

Présentation générale

SANJAY : Nous vous proposons un nouvel épisode spécial du podcast « Driving Innovation », en direct du salon CES 2024 à Las Vegas. Dans l’épisode d’aujourd’hui, nous recevons Robert Day, directeur de la stratégie de commercialisation automobile chez Arm. Robert va nous parler de l’implication d’Arm dans le secteur automobile, ainsi que de son initiative visant à faciliter le développement de logiciels «cloud native» grâce à son programme SOAFEE. J’espère que vous apprécierez cette émission.

Ordre du jour

ROBERT : Merci. Je tiens donc à remercier Sonatus de nous avoir permis de venir sur leur fabuleux stand au CES 2024 et de vous parler un peu de la manière dont nous, chez Arm, envisageons de faire du véhicule défini par logiciel une réalité. Les véhicules définis par logiciel font l’objet de nombreux débats. Beaucoup de gens cherchent différentes façons de concrétiser réellement ce concept. Et c’est justement ce dont nous allons parler aujourd’hui. Si l’on examine l’ordre du jour, nous allons tout d’abord vous présenter brièvement qui est Arm et quel est son rôle dans le secteur automobile. Nous aborderons ensuite la notion de « véhicule défini par logiciel » : qu’est-ce qu’un véhicule défini par logiciel ? Pourquoi parle-t-on d’un véhicule défini par logiciel ? Puis nous évoquerons certaines de nos initiatives qui, selon nous, permettront de faire du véhicule défini par logiciel une réalité. Commençons par une brève présentation d’Arm. Eh bien, nous sommes une entreprise technologique qui développe essentiellement des IP destinées à être intégrées dans des produits à base de silicium. Nous avons connu un beau succès au cours de nos 30 années d’existence. Et comme vous pouvez le constater, un grand nombre de puces basées sur Arm ont déjà été commercialisées. Nous estimons que 70 % de la population mondiale utilise des produits intégrant la technologie Arm. Ce qui est assez intéressant, c’est que j’ai commencé à compter le nombre de produits Arm que j’ai chez moi, mais j’ai fini par m’arrêter parce que cela devenait un peu compliqué. Et ce que nous constatons, c’est que cette tendance s’accélère à mesure qu’Arm passe des appareils grand public présentés au Consumer Electronics Show au secteur automobile. Et c’est précisément ce dont nous allons parler aujourd’hui.

Arm dans le secteur automobile

ROBERT : En fait, Arm est présent dans le secteur automobile depuis 25 ans. D’accord. Nous avons passé pratiquement toute notre existence à travailler sur les systèmes embarqués. Mais nous sommes généralement restés un peu « sous le capot », si vous voyez ce que je veux dire. Et donc, si vous regardez certaines de ces statistiques ici, plus de 85 % des systèmes IVI fonctionnent sur Arm, ce qui est assez naturel puisque les systèmes IVI s’apparentent à des appareils grand public. Ils se trouvent simplement dans votre véhicule. Mais aujourd’hui, avec l’arrivée des nouvelles fonctionnalités ADAS et de l’autonomie, bon nombre de processus applicatifs s’appuient également sur la technologie Arm. Chez Arm, nous avons créé des produits spécialement destinés au secteur automobile. Nous proposons donc des processeurs (CPU), des processeurs graphiques (GPU) et des processeurs d’image (ISP), que je vais vous présenter dans un instant, dont la sécurité fonctionnelle est une caractéristique essentielle. Nous disposons également d’un formidable écosystème automobile, dont Sonatus fait partie en tant que partenaire.

Pourquoi un véhicule défini par logiciel ?

ROBERT : Alors, pourquoi un véhicule défini par logiciel est-il important ? Tout d’abord, du point de vue des constructeurs automobiles, cela leur permet d’envisager de nouveaux modèles économiques, de nouvelles sources de revenus et de nouvelles relations avec leurs clients. Le principe des véhicules définis par logiciel, comme leur nom l’indique, réside dans le fait que le développement précoce des logiciels est essentiel. Il y aura tellement de logiciels dans une voiture qu’il est impossible de tout faire d’un seul coup. D’accord ? Mais nous constatons que le véhicule défini par logiciel est une question de survie pour l’industrie automobile. Il est d’ailleurs intéressant de noter que cette transition est déjà en cours. Voici une citation de Gartner datant de l’année dernière : en substance, d’ici 2023, 50 % des 10 principaux constructeurs automobiles proposeront de nouvelles fonctionnalités via des mises à jour logicielles. Et c’est là tout l’intérêt du véhicule défini par logiciel : vous pouvez intégrer ces fonctionnalités sous forme de logiciels, les mettre à jour, les améliorer et en ajouter de nouvelles. C’est l’un des aspects essentiels de cette évolution.

Sommes-nous prêts pour le SDV ?

ROBERT : La question suivante est la suivante : sommes-nous prêts, en tant que consommateurs, à adopter un véhicule « software-defined » ? Et sommes-nous prêts à payer pour cela ? Aurora Labs et Strategy Analytics ont mené une étude, je crois en 2022, dans laquelle ils ont demandé aux consommateurs s’ils seraient prêts à payer pour des fonctionnalités et des services « software-defined ». Et comme vous pouvez le voir, près de 50 % des personnes interrogées ont déclaré qu’elles seraient prêtes à payer 20 dollars par mois pour bénéficier de services supplémentaires dans leur véhicule. Cela représente une somme considérable sur une année. Et sur toute la durée de vie du véhicule. Certains seraient même prêts à payer jusqu’à 50 dollars, ce qui est vraiment incroyable. Je ne vais même pas faire le calcul pour savoir à combien cela s’élève sur une année.

Nouvelles exigences relatives à la SDV

ROBERT : Le principe d’un véhicule défini par logiciel, c’est qu’il impose de nouvelles exigences par rapport à l’automobile traditionnelle. Nous devons donc être capables de proposer ces fonctions définies par logiciel sous forme de fonctionnalités avancées. Nous devons favoriser l’innovation, mais nous devons aussi faire preuve d’agilité. Cela s’apparente donc davantage à l’univers traditionnel du logiciel qu’à celui de l’automobile. Ces éléments doivent pouvoir être mis à jour et mis à niveau. Ils doivent être sécurisés. Et ils doivent garantir la sécurité. Enfin, elles doivent être évolutives. L’un des aspects essentiels d’un véhicule défini par logiciel réside dans la possibilité d’adapter ces caractéristiques et ces fonctions à différents modèles de votre gamme. Il sera donc très intéressant de voir comment cette dynamique va se développer à mesure que nous entrons dans l’ère du véhicule défini par logiciel.

Les produits automobiles d'Arm

ROBERT : Chez Arm, comme je l’ai mentionné, nous proposons des produits destinés au secteur automobile ; nous disposons ainsi d’une gamme de produits que nous appelons « AE » (Automotive Enhanced). Nous proposons notamment un processeur haute performance appelé Cortex-A78AE. Celui-ci intègre une fonctionnalité intéressante appelée « split-lock », qui permet de verrouiller des paires de cœurs entre elles pour garantir des niveaux de sécurité plus élevés. Mais si vous recherchez des performances élevées, vous pouvez les déverrouiller. On dispose alors, en gros, d’un processeur bicœur. Cette fonctionnalité est présente dans nos processeurs AE. Nous proposons également un processeur graphique (GPU) à sécurité fonctionnelle, le Mali-G78AE, doté d’un mécanisme de partitionnement intéressant permettant un rendu graphique sécurisé. Nous disposons également d’un processeur d’images (ISP) appelé Mali-C78AE. Tous ces composants sont donc essentiels pour l’exécution des fonctions définies par logiciel, ainsi que pour l’exécution des applications graphiques dans le véhicule, qui feront partie intégrante de ces fonctions. Quant à l’ISP, il permet d’obtenir des images de caméra d’une très grande fidélité à l’intérieur du véhicule pour l’ensemble des fonctionnalités ADAS et d’autres applications similaires. Passons maintenant au SDV.

Les quatre piliers du SDV

ROBERT : En discutant avec les acteurs du secteur, nous avons en quelque sorte pris conscience qu’il existe quatre piliers essentiels à la mise en œuvre et à la concrétisation du véhicule défini par logiciel (SDV). D’un côté, il y a évidemment la sécurité et la sûreté, et de l’autre, la nécessité d’une capacité en temps réel. Ce sont des éléments dont le secteur automobile a besoin de toute façon, et dont le véhicule défini par logiciel a également besoin. Nous avons besoin de normes qui s’ajoutent aux normes automobiles traditionnelles. Pour les fonctions définies par logiciel, il faut des API et des normes sur lesquelles nous puissions nous appuyer pour les développer. Nous devons également adopter de nouvelles méthodologies logicielles. Je vais m’étendre davantage sur ce sujet aujourd’hui, car c’est un moyen intéressant d’introduire ces méthodologies logicielles issues d’autres secteurs dans l’industrie automobile. Ce qui est essentiel, et j’y reviendrai dans un instant, c’est de pouvoir exécuter le logiciel alors que le véhicule et son système informatique ne sont pas encore disponibles. Il faut pouvoir commencer tôt et recourir à des techniques telles que la simulation. Et le point essentiel, que j’aborderai à la fin, c’est la collaboration au sein du secteur. Nous ne pouvons plus nous permettre ce genre de cloisonnement. Les acteurs doivent travailler ensemble. Le problème est trop vaste pour qu’une seule entreprise puisse le résoudre seule. Examinons donc brièvement certains de ces aspects. L’un des éléments clés dont nous venons de parler concernait les nouvelles méthodologies logicielles.

Les processus de développement modernes

ROBERT : Ce qu’il nous faut donc faire aujourd’hui dans le secteur automobile, c’est adopter des processus de développement modernes afin, en substance, d’accélérer les délais de développement et de déploiement des logiciels. Nous devons également parvenir à ce que l’on appelle la « parité environnementale » : si vous développez dans le cloud et que vous déployez en périphérie, il est très utile que ces deux environnements partagent le même jeu d’instructions, ce qui vous permet d’exécuter le logiciel dans le cloud puis de l’exécuter dans la voiture. Nous y reviendrons un peu plus en détail. Il est également très important de pouvoir déployer facilement les logiciels chez différents fournisseurs de puces. Cela garantit la portabilité de vos logiciels lorsque vous passez d’une génération de voiture à une autre, ou d’un modèle de voiture à un autre. Et cela permet aussi de mettre en œuvre une stratégie de « shift-left ». Je vous l’expliquerai sur la diapositive suivante.

La stratégie « shift-left » dans le secteur automobile

ROBERT : Le développement automobile traditionnel, ici, est assez séquentiel. En gros, on conçoit d’abord le logiciel et le SoC, puis on développe l’ECU, et enfin, on s’occupe des applications. C’est donc un processus en série. On ne peut pas vraiment se lancer dans le développement des applications tant que ces éléments ne sont pas en place. Dans le cadre de notre approche « cloud native », on intègre le cloud dès le départ. Et si l’on peut commencer le développement des applications tôt dans le cloud, c’est-à-dire à ce stade-ci, on peut alors réellement commencer à développer ici pendant que ces autres étapes se déroulent en parallèle. Et une fois l’intégration du système effectuée, c’est à ce moment-là que vous pouvez le transférer et le tester dans le véhicule. Ce que nous faisons en réalité, c’est le tester et le développer ici en amont. Lorsque le véhicule est prêt, ou que son système informatique est prêt, vous le transférez. L’autre avantage que cela permet – et c’est là que réside votre « shift-left » en termes de timing – c’est qu’il permet également des mises à jour et des mises à niveau continues, ce qui est un facteur important pour le véhicule défini par logiciel. Vous êtes ainsi en mesure de proposer en permanence de nouveaux services ou des services mis à jour aux utilisateurs de votre véhicule. Cela ouvre la voie à une évolution vraiment intéressante de la dynamique relationnelle entre les constructeurs automobiles et les conducteurs de leurs voitures, car à l’heure actuelle, lorsque vous achetez une voiture, vous la conduisez en quelque sorte hors du parc d’exposition. Vous n’avez pas vraiment de relation avec l’entreprise qui a construit la voiture. Alors qu’à présent, si celle-ci fournit des mises à jour et des services, c’est tout autre chose. La relation commence donc à évoluer entre les conducteurs et les constructeurs. Comment y parvenir ?

Initiative SOAFEE

ROBERT : Il y a quelques années, nous avons lancé une initiative appelée SOAFEE. Il s’agit d’une initiative sectorielle qui vise véritablement à apporter des expériences de développement logiciel « cloud-native » aux véhicules automobiles « software-defined ». D’accord ? Pour ce faire, nous avons créé le groupe d’intérêt spécial SOAFEE. Notre premier objectif était d’essayer de définir une architecture logicielle qui rendrait cela possible. SOAFEE consiste donc avant tout à définir une architecture, et non du code. Cependant, pour que les gens puissent vraiment se lancer avec SOAFEE, nous savions qu’il nous fallait disposer d’une implémentation logicielle de référence afin qu’ils puissent commencer à développer et à tester ces nouvelles méthodologies pour les charges de travail automobiles. Et comme vous pouvez le constater, les membres fondateurs et les membres du comité de pilotage de SOAFEE proviennent véritablement de l’ensemble de l’écosystème automobile. Nous avons donc des équipementiers (OEM), des fournisseurs de premier rang (Tier 1), des acteurs du cloud, notre équipe, ainsi que des spécialistes du logiciel. Nous comptons notamment Red Hat et SUSE, qui possèdent une expertise approfondie en matière de développement logiciel et de l’articulation de l’ensemble. Nous estimons donc que, rien qu’au sein des instances dirigeantes, nous avons une bonne vision de ce que nous souhaitons accomplir. Je vous en dirai un peu plus dans un instant sur les membres de SOAFEE.

Architecture native du cloud

ROBERT : Mais je vous ai dit que nous essayions vraiment de définir une architecture. Et comme vous pouvez le voir ici, nous avons cette architecture qui comprend des éléments dans le cloud et d’autres embarqués dans le véhicule. L’idée, cependant, réside dans les applications elles-mêmes, et une grande partie de ce que vous voyez ici restera constante, ou cohérente, entre le cloud et la périphérie. Cela signifie donc que lorsque vous développez des éléments tels que vos applications ou vos services dans le cloud, une fois que vous êtes prêt à les déployer en périphérie, ils devraient tout simplement fonctionner. Et c’est là que nous utilisons des technologies telles que les conteneurs, ainsi que des techniques comme l’orchestration. Ces concepts sont en quelque sorte empruntés à ce qui se fait dans l’univers du cloud. Ils sont donc déjà bien établis. Les gens les connaissent déjà bien. Ce que nous devons faire, c’est les adapter au secteur automobile. Concrètement, cela signifie que nous devons prendre en compte des aspects tels que la sécurité fonctionnelle, le temps réel et le calcul hétérogène, qui n’existent pas nécessairement dans le cloud. C’est donc l’un des défis que SOAFEE va relever.

Adhésion à la SOAFEE

ROBERT : Donc, ces deux dernières années, nous avons en fait eu un groupe de membres plutôt solide. Vous pouvez revoir la liste des membres du conseil d’administration. Je pense que nous en sommes désormais à environ 115 membres. Et vous pouvez voir ici – vous ne le distinguez probablement pas –, mais c’est le logo d’ Sonatus . Sonatus est membre de SOAFEE. Ce qui est tout à fait logique, car une grande partie des travaux d’ Sonatus porte justement sur le véhicule défini par logiciel. C’est la technologie « cloud-to-vehicle ». C’est donc un véritable expert dans ce domaine avec lequel nous pouvons collaborer.

Groupes de travail SOAFEE

ROBERT : Parlons un peu de la structure de SOAFEE. Encore une fois, je ne sais pas si je vais réussir à être très clair. Nous avons donc un organe directeur présidé par Bill, d’AWS. Nous avons un comité de pilotage technique et un comité de pilotage marketing. Le comité de pilotage technique supervise tous les groupes de travail qui mènent les activités, et les domaines qu’ils abordent concernent notamment l’architecture système. Nous nous intéressons au « cloud natif ». Nous nous penchons sur la criticité mixte, ainsi que sur des technologies telles que les hyperviseurs, que nous estimons essentielles. Tout cela alimente ensuite cette implémentation de référence que nous publions en open source afin de permettre une adoption précoce de SOAFEE. Voici d’autres initiatives que nous menons. En fait, si nous revenons en arrière, vous pouvez voir ici que nous avons une autre équipe « Tiger » : il s’agit de la « Blueprints Tiger Team ».

Plans SOAFEE

ROBERT : Donc, le simple fait de publier une implémentation de référence open source, c’est bien, mais ça repose en quelque sorte sur les gens pour qu’ils se disent : « Bon, maintenant, il faut qu’on fasse quelque chose. » D’accord ? Nous avons donc décidé de proposer ces « blueprints » SOAFEE, qui sont des applications de référence destinées à un cas d’utilisation automobile et conçues pour fonctionner dans un environnement SOAFEE. Elles peuvent être open source ou propriétaires. Notre objectif était d’introduire des exemples d’applications dans l’écosystème SOAFEE pour que les utilisateurs puissent s’en servir, mais aussi pour permettre aux équipementiers de se lancer rapidement grâce à ces exemples disponibles. Je vais vous expliquer un peu plus en détail ce que font réellement ces blueprints. Un blueprint SOAFEE consiste essentiellement à exploiter une partie du temps d’exécution de l’implémentation de référence sur, vous le savez, le micrologiciel et le matériel. Et puis nous avons ces conteneurs. Comme je l’ai dit, une partie de l’architecture SOAFEE repose sur la conteneurisation des charges de travail. Il s’agit donc d’une approche de type microservices. Nous avons ainsi différentes charges de travail s’exécutant dans différents conteneurs. Et vous pouvez voir ici les différents éléments logiciels : d’un côté, les charges de travail spécifiques aux applications ; de l’autre, la pile de base, qui comprend les conteneurs, l’orchestration, éventuellement des hyperviseurs, des outils et tout le reste ; et enfin, la plateforme de calcul en bas. Voilà à quoi ressemble un « blueprint » générique. Je vais maintenant vous donner un exemple.

Kit Open AD

ROBERT : Le premier exemple concernait donc ce qu’on appelle l’OpenAD Kit. Il s’agit d’une collaboration avec une entreprise de logiciels open source dédiée à la conduite autonome, Autoware. Concrètement, nous avons pris la pile logicielle d’Autoware et nous l’avons décomposée en différents conteneurs. Ces conteneurs communiquent ensuite entre eux via un réseau virtuel. Vous pouvez donc voir les différentes fonctions présentes dans chacun des conteneurs : cartographie, perception, planification et interface véhicule. Au début, on a un peu triché pour s’assurer que tout cela fonctionnait. En réalité, on exécute quatre copies complètes d’Autoware dans un conteneur, mais on n’y fait fonctionner que la fonction de cartographie. Voici ce que nous avons dû faire pour évoluer vers une architecture davantage axée sur les microservices : nous avons essentiellement placé chacune de ces fonctions dans son propre conteneur, de sorte que ce n’est plus la pile autonome complète qui s’exécute ici, mais bien chacune des fonctions individuellement. Et c’est exactement ce que nous faisons actuellement avec ce blueprint OpenAD Kit. Ce qui est intéressant avec les blueprints, et c’est d’ailleurs la raison pour laquelle nous les avons créés, c’est que nous voulions que le secteur s’en empare et commence à les utiliser, soit comme exemples de ce qu’il est possible de faire si vous êtes un équipementier, soit si vous êtes une autre entreprise technologique souhaitant y intégrer sa propre technologie pour la rendre encore plus intéressante. Ainsi, l’année dernière, une entreprise appelée Kern Concept nous a dit : « D’accord, je vais me pencher à nouveau sur ces solutions conteneurisées. » Et je sais qu’une des fonctions ici, l’interface véhicule, est une fonction de sécurité. Si elle ne fonctionne pas, le véhicule ne fonctionne pas. D’accord ? Elle doit donc fonctionner au sein d’un système de sécurité. Ce qu’ils ont donc fait – si je me rends ici –, c’est qu’ils ont mis en place deux systèmes. Ils en avaient un de ce côté-ci, qui exécute la majeure partie des composants Autoware, et un autre de ce côté-là, dédié à la fonction de sécurité, qui gère essentiellement l’interface véhicule, le tout relié par un réseau Ethernet physique, et non un réseau Ethernet virtuel. C’est donc le même concept que celui des microservices conteneurisés, mais cette fois-ci dans un réseau hétérogène – un système hétérogène. Vous pouvez donc voir que la partie sécurité se trouve ici, qu’on peut alors héberger sur un microprocesseur de sécurité, en l’occurrence un NXP. Et puis, de ce côté-ci, il y a les processus applicatifs qui ne doivent pas nécessairement présenter le même niveau de sécurité.

Plateformes cibles de SOAFEE

ROBERT : En parlant de plateformes, l’autre chose dont nous avions besoin, c’était de disposer d’une plateforme matérielle. Cela n’apparaissait pas sur la carte, mais bon nombre de nos partenaires fabricants de puces font partie de SOAFEE. Et ce que nous essayons vraiment de faire maintenant, c’est de les inciter à apporter leurs plateformes. Intégrer SOAFEE, l’implémentation de référence de SOAFEE, sur ces plateformes. Vous pouvez donc constater que nous avons des entreprises comme Renesas, NXP et Marvell. Nous disposons également d’une instance cloud native d’AWS. Cela signifie que vous pouvez exécuter SOAFEE en mode « bare metal » dans le cloud sur un Graviton, qui est un processeur basé sur l’architecture Arm. Nous souhaitions également disposer de plateformes de développement non automobiles intéressantes. Nous avons donc le Turing Pi et le Raspberry Pi. D’ailleurs, lors de l’événement COVESA hier soir, le Raspberry Pi faisait partie des systèmes sur lesquels SOAFEE était en exécution. Voilà, c’est donc ça, SOAFEE.

Comment s'impliquer

ROBERT : Si cela vous intéresse et que vous souhaitez vous impliquer, SOAFEE.io vous fournira de nombreuses informations. Il existe un canal Slack, et SOAFEE est présent sur LinkedIn. Et si vous souhaitez nous rejoindre, le mieux est sans doute de me contacter directement à l’adresse Robert.Day@arm.com. Je vous aiderai alors à devenir membre. Voilà donc ce qu’est SOAFEE. Nous pensons que c’est un aspect vraiment intéressant pour faire du véhicule défini par logiciel une réalité. Si certains d’entre vous ont suivi attentivement, vous aurez remarqué qu’il existe d’autres consortiums qui contribuent également à faire du véhicule défini par logiciel une réalité. Mais chacun d’entre nous évolue en quelque sorte dans son propre univers, où nous travaillons sur notre partie du projet. Et donc, ce n’est pas toujours évident. Comment tout cela s’articule-t-il ? Eh bien, en mars dernier, nous avons décidé d’essayer d’y contribuer également.

Alliance SDV

ROBERT : Nous avons donc formé une nouvelle alliance. Cette alliance a été lancée hier. Il s’agit d’une collaboration – une collaboration naissante, dirais-je – entre quatre organisations qui s’efforcent toutes de faire de la SDV une réalité. Nous avons donc Autosar, sans doute le plus ancien des… non, le plus abouti des consortiums. Nous avons COVESA, anciennement GENIVI ou GEN IVI. Nous avons Eclipse SDV, et nous avons SOAFEE. Ce que nous faisons, c’est favoriser une collaboration entre ces différents consortiums. C’est en quelque sorte le consortium des consortiums, ou la collaboration des collaborations, si vous préférez. Rien qu’au sein de ces quatre organisations, on compte plus de 500 entreprises de l’écosystème automobile impliquées dans ces différents consortiums. Ce que cela apporte également, et ce que nous allons faire en tant qu’alliance, c’est de montrer très clairement comment tous ces éléments s’articulent entre eux. D’ailleurs, lors de l’événement de lancement hier soir, nous avons présenté une démonstration de certaines parties de chacun de ces systèmes fonctionnant ensemble, simplement pour montrer que cela est possible. Mais ce que cela apporte, c’est une intégration du cloud à la périphérie, la voiture connectée, l’open source, les normes ouvertes, le temps réel et la sécurité, le tout réuni en un ensemble cohérent. L’objectif est que, si nous parvenons à mettre cela en place correctement, cela devrait considérablement faciliter la tâche des équipementiers pour développer et déployer le véhicule défini par logiciel. Mais cela encouragera également la collaboration, et davantage de collaboration. Pas une collaboration entre consortiums cloisonnés, mais un véritable travail en commun. Ces neuf derniers mois ont constitué un parcours vraiment passionnant, consacrés à la mise en place de cette alliance et à la collaboration. Maintenant que nous avons lancé l’initiative, le travail commence. Je vous invite donc à rester attentifs aux résultats qui émergeront de cette alliance. Et encore une fois, si vous souhaitez vous impliquer dans cette alliance, vous pouvez contacter n’importe laquelle de ces autres organisations. La dernière chose que je tiens à dire, c’est qu’il s’agit d’une alliance ouverte. Nous nous attendons à ce que d’autres consortiums s’y joignent. Nous ne sommes pas les seuls quatre. Nous avons donc voulu donner le coup d’envoi, mais nous encourageons d’autres consortiums à s’impliquer dans cette alliance et dans cet effort conjoint de l’industrie. Et nous en sommes vraiment convaincus – j’ai d’ailleurs entendu cela hier soir en discutant avec deux équipementiers – que c’est quelque chose qu’ils apprécient. Nous espérons donc que ce sera un très bon début, le véritable point de départ du parcours vers le véhicule défini par logiciel. J’ai dit que c’était déjà en cours, mais ce qu’il nous faut, c’est de le concrétiser à grande échelle. Et nous espérons que tous les membres de ce consortium se rassembleront et travailleront ensemble pour que cela devienne réellement une réalité. Passons cette diapositive.

Conclusion

ROBERT : Sur ce, je tiens à vous remercier. Merci encore à Sonatus de nous avoir donné l’occasion de venir vous parler de ces innovations passionnantes liées aux véhicules définis par logiciel. J’espère que vous apprécierez cette vidéo en ligne. Merci beaucoup.