---

Description détaillée

 

Nous allons donc vers une logique de développement qui part de la fonction voulue et de ses éventuelles évolutions, vers l'application d'abord matérielle (calculateur) puis viennent le design et la définition du véhicule (châssis, motorisation).

A contrario: L'embryon de la Citroën 2CV, défini par Pierre-Jules Boulanger - le PDG de Citroën de l'époque - par « Quatre roues sous un parapluie ». Plus précisément : « On doit pouvoir la conduire avec un chapeau haut de forme et transporter un panier d'œufs à travers un champ labouré sans casser un seul œuf ». Nous montre une logique révolue avec une définition du véhicule presque anecdotique si nous devions la comparer avec la conception d'une Tesla par exemple.

Les véhicules modernes embarquent plusieurs dizaines de calculateurs (ECU), des réseaux complexes (CAN, LIN, FlexRay, Ethernet), et plus de 100 millions de lignes de code soit environ 15 fois celle d'un avion. Cette complexité n’est plus soutenable avec une architecture distribuée classique (E/E ou électrique/électronique).

D’où l’émergence du Software Defined Vehicle (SDV), qui s’appuie sur une architecture E/E centralisée et sur des plateformes logicielles standardisées pour offrir un véhicule agile, évolutif et connecté. Il aura en plus des communications internes au véhicule, des communications externes de type V2X_¹ régies par l'IEC 15118 qui permettront des échanges de données avec un cloud, des véhicules, des entreprises et bien d'autres.

 

Process de développement véhicule

Du côté développement on peut observer un véritable bouleversement dans le process :

En effet nous voyons que d'une première étape consistant à une construction physique du véhicule (carrosserie/mécanique) nous évoluons vers une conception priorisant l'architecture électronique avec un cahier des charges plus orienté vers "l'application" ou les fonctionnalités du véhicule.

Le développement des logiciels est passé en seconde place, alors qu'il était auparavant à la quatrième. De nos jours de plus en plus de constructeurs ont ouvert des services dédiés à cette étape évitant ainsi les coûts supplémentaires que peuvent représenter les sous-traitants historiquement employés pour cette étape. En effet il est important de souligner que l'on parle d'un marché qui se compte en milliards de dollars au niveau mondial uniquement pour cette partie.

Nous avons ensuite le middleware, avec hardware déjà développé, et une intégration des logiciels suivant la mise en marche du système d'exploitation. Ici nous pouvons déjà nous rendre compte d'une architecture en couche qui va permettre une véritable flexibilité des supercalculateurs et, par extension, du véhicule du point de vue de ses fonctionnalités.

Enfin nous voyons sur les dernières étapes les conséquences de cette réorganisation avec une validation qui ne limite pas l'évolution du véhicule après commercialisation.

 

 

---

Qu'est-ce que le SDV?

 

Un Software Defined Vehicle est un véhicule dont les fonctionnalités sont découplées du hardware et pilotées par une plateforme logicielle centralisée.

Ses principales caractéristiques :

•  Premier étage le hardware, soit les calculateurs : Cette couche représente le matériel électronique et informatique essentiel, y compris les calculateurs, qui alimentent les équipements de la voiture et permettent son fonctionnement.
• Deuxième étage, le Middleware ou intergiciel, le système d’exploitation : il fait fonctionner tous les équipements de la voiture, y compris le moteur, le châssis, les commandes numériques et le GPS. L’intergiciel joue un rôle central dans le développement et le fonctionnement des véhicules.
• Troisième étage, les applications : elles gèrent tous les équipements de la voiture, créant ainsi une expérience utilisateur spécifique à la marque, avec une interface utilisateur intuitive et agréable à utiliser. Bien que la personnalisation soit déjà possible dans les architectures E/E, ici il est question de rajouter des fonctionnalités en utilisant les capteurs et actionneurs déjà présents.
• Quatrième étage, le Cloud : il est le cœur dans le management des données en V2X, tous les véhicules étant désormais connectés (depuis 2018). BMW par exemple s'appuie sur le AWS (Amazon Web Service) pour la récolte des données de ses véhicules connectés et prévoit une autonomisation de la conduite par ce service.

 

En pratique, un SDV se rapproche d’un ordinateur roulant, où l’OS embarqué, la virtualisation et le cloud jouent un rôle aussi central que le moteur thermique ou électrique.

 

Quel impact sur le véhicule en lui-même ?

Du point de vue après-vente c'est l'architecture véhicule qui est complétement retravaillée :

 

Ici la différence est flagrante avec une architecture dépouillée basée sur : 

Architecture E/E à gauche de l'image :

• De nombreux calculateurs (généralement 1 par fonction).
• Un réseau multiplexé étendu comprenant une quantité de fils bien supérieure.
• Des protocoles multiplexés plus lents inhérents à l'architecture (longueur du réseau) mais aussi aux possibilités des calculateurs.
• Cette organisation a longtemps été efficace, mais elle atteint aujourd’hui ses limites : complexité croissante, difficultés de maintenance et d’évolution logicielle, et multiplication du câblage.

SDV à droite de l'image :

• Des super calculateurs (en rose).
• Des hub de connexion (en jaune).
• Des calculateurs zonaux (en gris).
• Des protocoles de communications rapides (Ethernet automotive).
• l’architecture SDV propose une approche plus centralisée. Les nombreuses unités électroniques sont remplacées par quelques calculateurs de domaine ou centraux, beaucoup plus puissants, capables d’exécuter plusieurs fonctions via des logiciels modulaires.

 

L'effet en lui même est évident, outre la possibilité d'évolution du véhicule, on comprend vite l'économie de matière que représente cette structure. Toutefois ce système pourra paraître plus complexe à approcher en diagnostic pour les populations d'atelier. Les protocoles de communication évoluent (protocole Ethernet), les super calculateurs assurent plusieurs fonctions, certains calculateurs zonaux pourront tout de même avoir une certaine autonomie dans la gestion de fonction de sécurité par exemple, intégration d'IA afin d'optimiser et gérer les fonctions du véhicule. C'est donc là que nous allons devoir évoluer dans nos pratiques et appréhender de nouvelles technologies avec une évolution du poste de technicien vers l'informatique (en partie seulement).

 

---

Et demain?

 

La trajectoire des SDV se dessine autour de plusieurs tendances :

• Architecture zonale standardisée : remplacement progressif de centaines d’ECU par quelques HPC_³ reliés via Ethernet (1 Gbit/s et plus).
• OS automobile propriétaire (ex. MB.OS, VW.OS_²) ou basé sur des standards (Android Automotive, QNX, Linux).
• IA générative_⁴ et edge computing_⁵ pour ADAS et maintenance prédictive.
• Véhicule évolutif : achat du hardware, mais personnalisation continue du software (nouveau business model).
• Interopérabilité accrue entre constructeurs, équipementiers et acteurs cloud (standardisation obligatoire pour réduire coûts et temps de développement).
• Véhicules autonomes : Etape indispensable pour une autonomisation du véhicule. Le SDV permettra de rendre ce type de véhicule fiable et sécuritaire.

 

---

Méthodes et pratiques

Outils et spécificités au diagnostic du SDV

 

Les contrôles filaires des réseaux ainsi que des résistances de terminaison seront donc obsolètes. En effet le RJ45 , qui est le bus pour le protocole Ethernet, ne supporte pas les contrôles avec un multimètre du fait de la finesse des brins (0.13mm²).

 

 

 

Pour le contrôle du bus il sera alors nécessaire d'avoir des outils spécifiques.

Il n'y aura donc plus de mesures physiques mais la nécessité de connaître et manipuler de nouveaux outils.

De plus, la compréhension des schémas de principes, de câblages et fonctionnels sera indispensable dans l'optique de réaliser des diagnostics sur ce type de réseaux.

 

 

Les outils de diagnostic traditionnels (basés uniquement sur OBD-II et CAN), bien qu'il reste l'obligation d'OBD2 pour le contrôle technique et le contrôle des forces de l'ordre, deviennent insuffisants. Le SDV impose :

 

• Communication Ethernet/DoIP (Diagnostics over IP) : diagnostic haute vitesse via réseaux 100/1000BASE-T1.
  Attention certains outils nécessitent un passage manuel en DOIP.
• Middleware diagnostic : AUTOSAR Adaptive, basé sur POSIX, permettant des services distribués. Ce sera un équivalent à l'assistant d'erreur sous Windows par exemple.
• Cloud diagnostics : interaction directe entre l’outil atelier et la plateforme constructeur (accès logs, télémétrie, campagnes OTA).
• Rollback et versioning : capacité à restaurer un firmware ou un logiciel après mise à jour défaillante.
• Sécurité intégrée : signature numérique des binaires, vérification de l’intégrité (Secure Boot, HSM).
• Virtualisation : diagnostic de machines virtuelles embarquées (containers Docker/OCI dans l’automobile).

 

 

---

Impact sur les compétences en atelier

Le SDV transforme radicalement l’écosystème après-vente :

• Diminution des interventions mécaniques, par la maintenance prédictive, augmentation des problématiques logiciels.
• Diagnostic distant (remote diagnostics) : le constructeur ou l’atelier peut analyser et corriger un bug sans passage physique du véhicule.
• Maintenance prédictive : collecte massive de données télématiques et analyse IA pour anticiper les pannes.
• Réduction des temps d’immobilisation : OTA permet d’appliquer des correctifs en arrière-plan.
• Formation technique : le mécanicien devient aussi un “technicien IT embarqué”, avec compétences en cybersécurité, protocoles IP, gestion des versions logicielles.
• Nouvelle chaîne de valeur : une partie du revenu après-vente se déplacera vers la gestion des licences logicielles et des abonnements.