Auteur : Peter Bechberger, directeur du marketing produit, SoC, Renesas
Comment l'informatique centralisée, les chiplets et les chaînes d'outils ouvertes permettent des architectures durables pour les véhicules à pilotage logiciel
Les véhicules à gestion logicielle (SDV) transforment radicalement la conception, le développement et l'évolution des systèmes électroniques automobiles tout au long du cycle de vie du véhicule. Les systèmes avancés d'aide à la conduite, la perception et la prise de décision pilotées par l'IA, la complexité croissante des fonctions du poste de conduite et l'exigence de mises à jour continues à distance (OTA) font exploser les besoins de traitement, dépassant largement les capacités des architectures d'ECU traditionnelles et hautement distribuées. Parallèlement, l'industrie des semi-conducteurs constate une diminution des gains liés à la miniaturisation classique des nœuds de gravure. Chaque nouveau nœud offre des améliorations modestes en termes de performances et d'efficacité, tandis que les coûts, la complexité de conception et les efforts de qualification augmentent considérablement. Pour les constructeurs automobiles (OEM) et les équipementiers de premier rang, cela crée un décalage structurel : la complexité logicielle et les exigences de performance croissent rapidement, tandis que l'approche traditionnelle, qui consiste à s'appuyer sur des SoC monolithiques toujours plus volumineux gravés sur les nœuds de gravure les plus récents, devient économiquement et techniquement contraignante. De ce fait, les architectures électroniques des véhicules évoluent vers des plateformes informatiques centralisées associées à des modèles de développement privilégiant le logiciel. Dans ce contexte, le R-Car Gen5 de Renesas sert de plateforme informatique centrale pour les véhicules à définition logicielle (SDV), combinant les avantages d'intégration d'un SoC monolithique avec l'évolutivité basée sur les chiplets et un SDK et une chaîne d'outils ouverts pour répondre aux exigences des systèmes automobiles.

Figure 1. Croissance de la demande en informatique embarquée et en plateformes informatiques évolutives
L'informatique centralisée comme colonne vertébrale architecturale des véhicules autonomes
L'informatique centralisée est un facteur clé pour les véhicules autonomes, car elle permet de consolider plusieurs domaines du véhicule sur une base matérielle et logicielle partagée. Au lieu de maintenir de nombreuses unités de contrôle électronique (ECU) dédiées avec des logiciels isolés, une plateforme informatique centralisée peut héberger les fonctions des systèmes avancés d'aide à la conduite (ADAS), du poste de conduite, de la passerelle et de la carrosserie au sein d'un seul système, à condition que les exigences de criticité mixte soient correctement gérées. Cette consolidation réduit la complexité du système, les efforts de câblage et les coûts d'intégration, tout en permettant une architecture logicielle plus cohérente pour l'ensemble du véhicule.

Figure 2. Transition vers des architectures E/E centralisées
La R-Car Gen5 est conçue pour fonctionner comme une plateforme informatique centrale. Elle combine des processeurs d'application haute performance avec des cœurs dédiés à la sécurité et au temps réel, permettant ainsi à des charges de travail aux exigences très différentes en matière de synchronisation, de sécurité et de disponibilité de coexister sur une seule et même plateforme. L'architecture privilégie non seulement des performances de calcul maximales, mais aussi un comportement prévisible, une disponibilité à long terme et la capacité d'accompagner l'évolution logicielle pendant de nombreuses années. Pour les véhicules de développement logiciel (SDV), c'est un point crucial : le logiciel n'est plus statique au moment de la vente, mais continue d'évoluer tout au long du cycle de vie du véhicule.
Du point de vue des systèmes, l'informatique centralisée permet également aux constructeurs automobiles de définir une infrastructure matérielle et logicielle commune pour plusieurs gammes de véhicules. Cela réduit la fragmentation et favorise une réutilisation plus efficace des composants logiciels, des outils et des processus. Il en résulte non seulement des coûts de développement réduits, mais aussi une qualité supérieure et une mise en œuvre plus rapide des nouvelles fonctionnalités.
Évolutivité basée sur les chiplets sous les contraintes de l'industrie automobile
Si l'informatique centralisée simplifie l'architecture, elle ne dispense pas de l'amélioration des performances. Les charges de travail des systèmes avancés d'aide à la conduite (ADAS) et de l'intelligence artificielle (IA), en particulier, continuent de croître rapidement, sous l'effet de la multiplication des capteurs, de la hausse de la résolution, de l'essor de l'IA embarquée et de la sophistication croissante des modèles. Or, l'augmentation des performances par l'accroissement continu de la taille et de la complexité des systèmes sur puce (SoC) monolithiques présente des limites pratiques. Les contraintes liées à la taille des réseaux, la dégradation des performances sur les grandes puces et les défis posés par la densité énergétique rendent cette approche de moins en moins attractive, notamment pour les applications automobiles soumises à des exigences strictes en matière de fiabilité et de qualification.
Les architectures Chiplet offrent une alternative
En décomposant un système en plusieurs puces de silicium au sein d'un même boîtier, les performances peuvent être adaptées de manière plus flexible et économique. Pour les applications automobiles, le principal avantage ne réside pas tant dans la modularité maximale en soi, mais plutôt dans la possibilité d'ajouter de la puissance de calcul là où c'est nécessaire, sans avoir à repenser l'intégralité du SoC. Le R-Car Gen5 incarne cette philosophie en combinant un SoC de base performant avec la possibilité d'étendre ses performances grâce à des chiplets supplémentaires, notamment pour l'accélération de l'IA.
Cette approche permet aux constructeurs automobiles et aux équipementiers de premier rang de déployer une plateforme matérielle commune à différentes catégories de véhicules et niveaux de finition, tout en modulant les performances grâce à des extensions optionnelles. Les véhicules d'entrée de gamme peuvent utiliser la configuration de base, tandis que les versions haut de gamme ou les mises à niveau ultérieures peuvent intégrer des ressources de calcul supplémentaires. Cette évolutivité est conçue pour répondre aux contraintes de l'industrie automobile, telles que la sécurité fonctionnelle, la fiabilité à long terme et un comportement prévisible. Plutôt que de coupler étroitement toutes les puces via une mémoire partagée, l'architecture privilégie une communication contrôlée et des limites claires pour la gestion des pannes.

Figure 3. Plateforme SoC évolutive avec extensions de calcul à chiplets
Maintenir un modèle logiciel unifié
La modularité matérielle n'est pertinente que si elle ne fragmente pas l'environnement logiciel. Dans les environnements de développement logiciel (EDL), la réutilisation et la portabilité des logiciels sont essentielles, car les efforts de validation et de certification augmentent rapidement avec la complexité du système. Par conséquent, il est fondamental que l'évolutivité matérielle – qu'elle passe par l'ajout de cœurs ou de chiplets – n'entraîne pas de modifications majeures de l'architecture logicielle.
R-Car Gen5 et ses extensions de chiplets sont conçus pour présenter un système logique unifié au logiciel. Des interfaces standardisées, la virtualisation et des couches d'abstraction garantissent un accès cohérent aux accélérateurs, qu'ils soient intégrés au SoC de base ou fournis par un chiplet. Du point de vue du système d'exploitation et des applications, les ressources de calcul supplémentaires apparaissent comme faisant partie intégrante du système, et non comme des périphériques spécifiques.
Ce modèle logiciel unifié réduit les efforts d'intégration et limite le besoin de branches logicielles spécifiques à chaque variante. Il simplifie également la maintenance à long terme, car les mises à jour logicielles et les nouvelles fonctionnalités peuvent être développées et validées grâce à une abstraction de plateforme cohérente, même en cas d'évolution du matériel sous-jacent.
SDK ouvert et ensemble d'outils ouverts comme levier pour accélérer la mise sur le marché
À mesure que le contenu logiciel augmente, l'efficacité du développement devient un facteur essentiel de compétitivité. La seule capacité matérielle ne suffit pas si le déploiement de la plateforme et l'intégration logicielle prennent trop de temps. Renesas répond à ce problème grâce à un SDK et un ensemble d'outils ouverts, connus sous le nom de plateforme R-Car Open Access (RoX), utilisant le SDK Whitebox comme configuration de base.
L'accent est mis sur la fourniture d'un environnement de développement cohérent et orienté production, plutôt que sur un ensemble d'outils disparates. Linux et Android constituent le socle du logiciel de haut niveau, complété par la prise en charge de la virtualisation et des options de système d'exploitation temps réel selon les besoins. Des API standard et des interfaces ouvertes sont utilisées afin de minimiser la dépendance vis-à-vis des fournisseurs et de faciliter la portabilité entre les projets et les générations de matériel.
Un aspect particulièrement important est la possibilité d'initier le développement logiciel au plus tôt. Les plateformes virtuelles et les environnements de développement dans le cloud permettent aux équipes de commencer l'intégration, les tests et les flux de travail CI/CD avant même que le matériel final ne soit disponible. Cette approche proactive réduit le risque d'intégration tardive et raccourcit les délais de développement globaux — un avantage de plus en plus crucial à mesure que les programmes de véhicules se multiplient et que la complexité des logiciels s'accroît.

Figure 4. Plateforme RoX Open SDV
Implications systémiques pour les fabricants d'équipement d'origine (OEM) et les fournisseurs de niveau 1
L'association d'une informatique centralisée, d'une évolutivité basée sur les chiplets et d'une chaîne d'outils ouverte a des implications majeures au niveau système. Les constructeurs automobiles peuvent ainsi définir des plateformes informatiques et logicielles stables, compatibles avec plusieurs générations de véhicules, préservant leurs investissements logiciels et limitant les modifications architecturales. Les équipementiers de premier rang bénéficient d'objectifs d'intégration plus clairs et d'un environnement de développement partagé, réduisant la duplication des efforts et accélérant la collaboration.
Du point de vue du cycle de vie, cette approche permet une évolutivité progressive des performances et l'ajout de nouvelles fonctionnalités sans modifications matérielles majeures en fin de programme. Elle s'accorde également avec les déploiements de fonctionnalités à distance (OTA), permettant l'introduction de nouvelles fonctionnalités des années après le début de la production en série, à condition de disposer d'une puissance de calcul suffisante ou de solutions de mise à niveau modulaires.
Conclusion
La transition vers les véhicules pilotés par logiciel met en évidence les limites des approches informatiques automobiles traditionnelles. Les plateformes informatiques centralisées deviennent essentielles, mais elles doivent être évolutives, compatibles avec les logiciels et adaptées aux cycles de vie prolongés de l'industrie automobile. R-Car Gen5 combine une architecture informatique centralisée avec une évolutivité basée sur les chiplets et un kit de développement logiciel (SDK) et un ensemble d'outils ouverts pour répondre à ces exigences système.
Au lieu de s'appuyer sur des SoC monolithiques de plus en plus volumineux, l'accent est mis sur la modularité, la réutilisabilité et l'efficacité du développement, en tenant compte des contraintes réelles de l'industrie automobile. Pour les constructeurs automobiles et les équipementiers de premier rang, le calcul évolutif et les plateformes logicielles unifiées ne sont plus des optimisations optionnelles, mais des éléments fondamentaux pour des architectures SDV compétitives.






