Le véhicule est-il désormais défini par le logiciel ? Architecture de domaine et transformation SDV

Technologies des véhicules électriques
Auteur: Deniz Erkan
Création: 14 Octobre 2026

Une architecture réduisant plus d'une centaine d'unités de contrôle à quelques contrôleurs zonaux fait que l'identité de la voiture est désormais produite non pas à partir de l'acier, mais à partir du code.

Partagez cette page

Oui : le comportement, les caractéristiques et le caractère performantiel de l'automobile moderne sont désormais définis en priorité par le logiciel. Cette transformation, appelée véhicule défini par le logiciel (SDV), déplace l'architecture électronique du véhicule des piles d'ECU vers des contrôleurs de domaine et zonaux, séparant le matériel du logiciel et remodelant tout, du poids du câblage aux mises à jour OTA.

Points clés

Les véhicules actuels 100 et plus peuvent contenir des unités de contrôle ; les nouvelles architectures visent à jusqu'à 20% réduire ce nombre.
L'architecture de domaine s'organise par fonction, l'architecture zonale par emplacement physique.
Dans la topologie zonale, CAN XL (jusqu'à 20 Mbps) et des colonnes vertébrales à haut débit comme l'Ethernet gigabit sont utilisés.
La mise à jour OTA est une capacité fondamentale du SDV rendue possible grâce à la dissociation matériel-logiciel.
La transition est progressive : le premier domaine concerné est celui de la carrosserie (body) ; l'ADAS, le groupe motopropulseur et le châssis peuvent rester plus longtemps dans la structure existante.

Qu'est-ce qu'un véhicule défini par le logiciel, exactement ?

La définition est claire : un véhicule défini par le logiciel est un véhicule dont la fonctionnalité et le comportement sont déterminés en priorité par le logiciel plutôt que par le matériel. Dans une voiture traditionnelle, une fonctionnalité était définie par une pièce matérielle conçue spécifiquement pour cette fonction ; dans un SDV, le même matériel peut prendre des fonctions différentes grâce au logiciel qui s'exécute dessus. Même après la vente du véhicule, de nouvelles fonctionnalités peuvent être ajoutées, le comportement peut être calibré et les erreurs peuvent être corrigées à distance.

Les architectures E/E actuelles se composent de 100 unités de contrôle ou plus ; les structures de nouvelle génération permettent d'économiser jusqu'à 20% sur le nombre d'unités de contrôle et jusqu'à 10% sur les matériaux et le matériel.
Bosch Mobility, évaluation de l'architecture E/E

Les chiffres contenus dans cette phrase résument l'ampleur de la transformation. Le problème ne concerne pas seulement le nombre d'unités de contrôle : chaque ECU apporte son propre câblage, sa propre pile logicielle et sa propre charge de validation. La vision du SDV est de transformer cette structure dispersée en un système où le logiciel peut tout gérer comme une seule couche cohérente. Pour cela, l'architecture électronique doit être repensée dès le départ.

Des ECU à l'architecture de domaine : regroupement par fonction

L'époque où chaque petite fonction d'une automobile disposait de sa propre unité de contrôle électronique (ECU) a rendu les faisceaux de câblage ingérables. L'architecture de domaine a été la première réponse systématique à ce problème : elle organise l'électronique du véhicule en grands domaines fonctionnels tels que l'ADAS, l'infodivertissement, le groupe motopropulseur (powertrain), l'électronique de carrosserie, le châssis et la sécurité. Chaque domaine possède généralement son propre processeur, sa propre pile logicielle, sa propre interface de communication, ses capteurs et ses actionneurs, et est géré par un contrôleur de domaine.

Cette structure a permis une consolidation importante par rapport au chaos des ECU. Cependant, à mesure que l'objectif du SDV grandissait, les limites de l'architecture de domaine sont apparues. En particulier, les données de capteurs générées par les fonctions autonomes ont poussé la bande passante des réseaux CAN classiques à ses limites. De plus, le fait que chaque domaine transporte sa propre ressource de calcul a laissé le faisceau de câblage complexe et a rendu difficile la mise à l'échelle du logiciel à l'échelle du véhicule.

Architecture zonale : l'organisation passe de la fonction à l'emplacement

L'architecture zonale inverse la logique : elle regroupe l'électronique non pas par fonction, mais par emplacement physique dans le véhicule. Le véhicule est divisé en zones comme avant gauche, avant droit, arrière gauche, arrière droit et habitacle ; dans chaque zone, un contrôleur zonal regroupe les capteurs, les actionneurs et la distribution de puissance de cette zone et communique avec les plateformes de calcul centralisées haute performance.

Caractéristique	Architecture par domaine	Architecture zonale
Principe d'organisation	Par fonction (groupe motopropulseur, ADAS, carrosserie...)	Par emplacement physique (avant gauche, arrière droit...)
Ressources de calcul	Calcul spécifique à chaque domaine	Calcul centralisé/distribué unifié
Câblage	Faisceau de câbles complexe et long	Câblage et poids réduits
Nombre d'ECU	Grand nombre d'ECU	Petit nombre de contrôleurs zonaux + ordinateur central
Flexibilité logicielle	Difficile à mettre à l'échelle pour les SDV	Haute flexibilité logicielle

Les gains sont concrets et mesurables : le poids du faisceau de câbles diminue, les connexions point à point se réduisent, l'architecture du véhicule et l'effort de validation des systèmes se simplifient. Plus important encore, les conceptions des capteurs et des actionneurs deviennent indépendantes du nœud de calcul central ; les cycles de mise à jour matérielle et logicielle sont ainsi découplés et une conception de capteur peut être utilisée sur plusieurs générations de véhicules.

Quel est le rôle du contrôleur zonal ? Répartition des tâches et lien avec le matériel

Zonal mimaride kablolar kısaldıkça araç hafifler, sigortalar yerini yarı iletken anahtarlara bırakır ve güç artık bölge bölge yönetilir.

La clé de l'architecture zonale est le contrôleur zonal, chargé de connecter de nombreux actionneurs et capteurs à l'ECU de calcul central. Ce contrôleur n'est pas une simple boîte de collecte de données ; il peut exécuter des boucles de contrôle en temps réel, gérer les périphériques de sa zone et envoyer vers l'épine dorsale un trafic filtré et priorisé. Selon l'évaluation d'ingénierie de Ti, le MCU du module zonal doit offrir des performances temps réel élevées, une mémoire importante, une prise en charge de la virtualisation pour différents niveaux ASIL, une communication à haut débit vers l'épine dorsale et de nombreuses interfaces périphériques à faible coût comme CAN FD et LIN.

Comment la distribution de puissance se décentralise-t-elle ?

Dans l'architecture par domaine, la puissance est distribuée depuis des boîtiers centraux de distribution de puissance contenant des fusibles et des relais. Dans une structure zonale, la distribution se décentralise : un seul faisceau de puissance est tiré de la batterie vers la zone, et le module zonal répartit la puissance entre les modules de cette zone. Des câbles de puissance courts signifient directement un gain de poids et de coût. De plus, les fusibles sont remplacés par des fusibles intelligents à semi-conducteurs ; les commutateurs haute tension à caractéristique I²t offrent une moindre variabilité des fusibles et des sections de câbles plus optimisées. Le boîtier intelligent de distribution de puissance, composé du MCU, des commutateurs haute tension et des transceivers, devient une unité configurée par logiciel : le même boîtier peut être utilisé dans chaque zone, adapté à la charge.

Dissociation des entrées/sorties physiques et logiques

Le module zonal regroupe les fonctions logiques d'entrée/sortie de plusieurs ECU en un seul point afin de réduire la complexité du câblage, tandis que les emplacements physiques des capteurs et actionneurs sont préservés. Un pas plus loin, les périphériques deviennent "intelligents" : le circuit local conserve les informations d'état et exécute le diagnostic des pannes. Des protocoles simplifiés comme CAN FD Light peuvent même supprimer le besoin d'un MCU séparé dans certains nœuds périphériques. Cette dissociation, où le matériel reste fixe et la fonction est définie par le logiciel, constitue l'épine dorsale d'ingénierie du SDV.

Le bus de données dans le véhicule zonal : bande passante, temporisation et cybersécurité

La fusion de capteurs et les charges de travail d'IA rendent obligatoire la construction de la topologie zonale sur des dorsales à haute bande passante : PCIe, jusqu'à 20 Mbps le CAN XL, qui atteint ce débit de données tout en préservant la compatibilité CAN existante, et l'Ethernet gigabit. Le véritable défi va au-delà de la bande passante : c'est la temporisation ; les courts messages de contrôle, les données des capteurs ADAS et le trafic infotainment ont des exigences de latence, de gigue et de synchronisation très différentes. Les ordres de grandeur approximatifs sont les suivants : des objectifs de latence de l'ordre de la milliseconde pour l'audio et de la microseconde pour la transmission de puissance et le contrôle du châssis.

Pour transporter ces différentes classes de trafic sur un seul réseau, la solution qui s'impose est le Time-Sensitive Networking (TSN) basé sur Ethernet. Des normes telles que la synchronisation temporelle (IEEE 802.1AS), le façonnage du trafic sensible au temps (802.1Qbv), le trafic express (802.3br), la préemption de trames (802.1Qbu) et la redondance (802.1CB) garantissent une latence déterministe pour les données critiques. Côté sécurité, le support d'ISO 26262, les chemins de communication redondants, le cloisonnement de sécurité et la détection des pannes sont déterminants ; côté cybersécurité, ce sont la norme ISO/SAE 21434, les réglementations UNECE et les mécanismes de chiffrement-authentification de bas niveau comme MACsec. Comme l'architecture zonale centralise les réseaux, les méthodes d'attaque basées sur Ethernet deviennent également applicables ; l'effondrement du concept de dissociation E/traitement en cas de faille de sécurité est un risque qui doit être évalué individuellement.

Comment la dissociation matériel-logiciel rend-elle possible la mise à jour OTA ?

La mise à jour OTA est la première caractéristique qui vient à l'esprit dans la plupart des discussions sur le SDV, mais ce n'est pas une capacité en soi ; c'est le résultat d'une architecture. Une mise à jour ininterrompue ne peut être assurée sans que le logiciel soit découplé de puces spécifiques via une couche d'abstraction matérielle (HAL) et sans que les fonctions du véhicule soient divisées en services indépendants, réutilisables et faiblement couplés (architecture orientée services, SOA). La dissociation englobe également l'isolation mutuelle des logiciels de différents niveaux de sécurité.

Son sens concret : l'architecture en zones, avec les mises à jour OTA/FOTA et la connectivité cloud permanente, donne au constructeur le contrôle de la maintenance logicielle de haut niveau tout en déplaçant les boucles de contrôle en temps réel vers les modules de zone. Des ajustements fins, comme le renforcement des modules non utilisés dans les véhicules électriques, sont également facilités par cette structure. En définitive, le logiciel d'un véhicule électrique est, au-delà d'un simple canal de mise à jour, la couche de définition qui détermine les caractéristiques du véhicule, ses systèmes de sécurité et son caractère de performance. Le véhicule commence à ressembler à un centre de données distribué sur roues ; la chaîne de valeur repose sur le logiciel, la puissance de calcul et l'architecture système.

Quelle sera la vitesse de la transition et l'architecture zonale suffira-t-elle à elle seule ?

La transition sera progressive. Le domaine de la carrosserie (body), qui contient de nombreux actionneurs distribués et calculateurs ECU de capteurs, sera le premier à passer à l'architecture en zones ; la transition de l'ADAS, du groupe motopropulseur et du contrôle du châssis pourrait prendre plus de temps en raison de leur nature critique pour la sécurité. L'évolution observée depuis 2017 dans les couches MCAL, BSW et applicatives montre qu'il ne s'agit pas d'un simple projet technique, mais d'un changement de mentalité à l'échelle du secteur.

Il faut aussi lire de manière équilibrée. L'architecture zonale réorganise physiquement le véhicule ; les aspects logiques et logiciels (SOA, HAL, cybersécurité) doivent être résolus séparément - réorganiser uniquement les câbles ne rend pas un véhicule défini par logiciel. Les estimations de la taille du marché varient également considérablement selon les définitions de périmètre ; les chiffres différents relatifs au marché de l'architecture E/E proviennent de ce que l'on inclut (uniquement les plateformes de calcul, ou toute l'électronique distribuée). Il ne faut pas non plus oublier que les semi-conducteurs et les fournisseurs de solutions, parties prenantes de la transition, sont naturellement favorablement disposés envers cette transformation.

Le résultat, c'est un équilibre d'ingénierie clair : la définition d'un véhicule par le logiciel n'est possible que par l'existence simultanée d'une nouvelle organisation matérielle fondée sur des contrôleurs de domaine et de zone, de couches logicielles découplées et d'une colonne vertébrale de données déterministe et sûre. La mise à jour OTA est le fruit le plus visible de cette structure intégrée ; la véritable révolution réside dans le transfert au logiciel du cahier des charges du matériel du véhicule.