SOVD et EU Right to Repair : création d'une architecture d'accès au diagnostic évolutive et conforme pour les SDV

La plupart des OEM présents sur les marchés de l'UE connaissent déjà la conformité au droit à la réparation. Le règlement d'exemption par catégorie pour les véhicules à moteur (MVBER) impose un accès non discriminatoire aux services de diagnostic pour les réparateurs indépendants depuis 1995. Il ne s'agit pas d'une nouvelle réglementation qui affecte le secteur, mais d'une référence établie qui façonne le fonctionnement des marchés automobiles européens depuis trente ans.

Ce qui a changé, c'est le véhicule. Les véhicules définis par logiciel, dotés de HPC centralisés, d'applications conteneurisées, de mises à jour OTA à distance et de flux de travail de services connectés au cloud, fragilisent de plus en plus les architectures de diagnostic traditionnelles. Les approches qui répondaient techniquement aux exigences du MVBER à l'ère des calculateurs autonomes et de l'accès physique aux ateliers ont du mal à s'adapter à l'ère des SDV.

La vraie question qui se pose aujourd'hui aux OEM n'est pas de savoir s'ils doivent fournir un accès aux diagnostics, ils sont déjà obligés de le faire. Il s'agit de savoir si leur architecture de diagnostic peut réellement fournir cet accès d'une manière gérable, sécurisée et utile sur le plan opérationnel à mesure que la complexité des logiciels du véhicule s'accroît. Le SOVD est la solution architecturale, et ses avantages vont bien au-delà de la conformité réglementaire et concernent la manière dont les OEM permettent à leurs concessionnaires et à leurs réseaux de service indépendants de travailler sur des véhicules de plus en plus pilotés par logiciel.

La base de conformité : ce que le MBER exige réellement

Le MVBER accorde aux OEM une dérogation à certaines exigences du droit de la concurrence de l'UE, y compris le droit d'exploiter des réseaux de concessionnaires franchisés, en échange d'une obligation claire : les réparateurs indépendants doivent bénéficier d'un accès non discriminatoire aux données techniques, aux outils de diagnostic et aux informations de réparation à des conditions commerciales équitables.

Cela signifie que les OEM ne peuvent pas utiliser des architectures de diagnostic propriétaires pour créer de facto des barrières d'accès qui favorisent les réseaux de concessionnaires agréés par rapport aux réparateurs indépendants. L'accès doit être techniquement faisable, et pas seulement théoriquement autorisé. Et à mesure que les véhicules sont de plus en plus définis par logiciel, la « faisabilité technique » est un critère de plus en plus exigeant.

Une illustration concrète : un grand OEM a exploré le SOVD en particulier parce que sa solution de diagnostic propriétaire ne peut pas être déployée dans l'UE sous sa forme actuelle. Le problème n'est pas l'intention légale, mais la réalité architecturale. Les systèmes propriétaires conçus pour les réseaux de concessionnaires créent des modèles d'accès qui ne correspondent pas parfaitement à l'accès non discriminatoire requis par le MVBER, en particulier lorsque les diagnostics sont transférés vers les logiciels et les domaines distants.

MVBER en un coup d'œil

Actif depuis 1995, prolongé jusqu'en 2028. Exige des constructeurs qu'ils fournissent aux réparateurs indépendants un accès aux informations techniques et de réparation des véhicules dans des conditions non discriminatoires comparables à celles que reçoivent les réseaux de concessionnaires agréés. S'applique à tous les OEM qui vendent des véhicules sur les marchés de l'UE, quel que soit le siège social de l'OEM.

Pourquoi les SDV compliquent le problème de l'architecture

Les diagnostics traditionnels ont été conçus autour d'une architecture ECU stable et distribuée. Chaque ECU avait des identifiants fixes, des fichiers de description statiques et une implémentation UDS connue. La conformité impliquait la publication de ces interfaces, complexes et imparfaites, mais réalisables.

Les véhicules définis par logiciel décomposent ce modèle de plusieurs manières :

• Configurations logicielles dynamiques : Les SDV modernes exécutent des applications conteneurisées sur des HPC. Le logiciel change à chaque mise à jour OTA. Le véhicule expédié n'est pas le véhicule sur le terrain six mois plus tard. Les fichiers de description statiques et les cartes ECU fixes ne peuvent pas suivre le rythme.
  
• Workflows de service à distance et basés sur le cloud : Les diagnostics sont de plus en plus effectués avant que le véhicule n'atteigne un atelier : pré-triage à distance, surveillance de l'état de la flotte, alertes de service déclenchées par l'OTA. Les modèles de diagnostic d'accès physique traditionnels n'ont pas été conçus pour cela, et les tunnels distants propriétaires intégrés aux systèmes existants créent une fragmentation.
  
• Conditions d'accès multipartites : MBBER nécessite un accès pour les réparateurs indépendants. Les opérateurs de flottes ont également besoin de leur propre accès. Le support central OEM a besoin d'une visibilité à distance. Les techniciens des concessionnaires ont besoin d'outils en atelier. Les équipes d'ingénierie ont besoin d'un accès approfondi au débogage. La gestion de tous ces éléments par le biais d'intégrations point à point propriétaires n'est pas évolutive.
  
• Preuves d'audit et de conformité : Les réglementations telles que la norme UN R156 exigent des preuves structurées de la manière dont les mises à jour logicielles sont gérées. L'assemblage de packages de conformité à partir de journaux éparpillés dans des systèmes propriétaires est de plus en plus intenable à mesure que la taille de la flotte augmente.

Il en résulte que les OEM qui ont construit des architectures de diagnostic adaptées à la génération de véhicules précédente sont confrontés à une dette technique croissante au moment même où leurs obligations en matière de service et de conformité augmentent.

SOVD : la base architecturale d'un accès évolutif

La norme SOVD (Service-Oriented Vehicle Diagnostics) est une norme ASAM (qui passe par la norme ISO 17978) qui définit une API basée sur HTTP/REST pour le diagnostic des véhicules. Alors que les diagnostics traditionnels nécessitaient tous les outils nécessaires pour implémenter une logique de communication personnalisée pour chaque programme du véhicule, SOVD fournit un contrat d'API commun. Le contenu des diagnostics (codes d'erreur, mesures, paramètres de configuration, état des mises à jour logicielles) est exposé via des points de terminaison REST standardisés à l'aide de JSON, avec des fonctionnalités auto-décrites via les spécifications OpenAPI.

Pour les OEM qui doivent gérer simultanément les obligations de conformité de l'UE et la complexité des services SDV, le SOVD répond aux deux grâce au même investissement architectural.

Une interface unique pour tous les scénarios d'accès

SOVD définit une API unifiée qui fonctionne dans des scénarios à distance (cloud), de proximité (en magasin) et à bord du véhicule. Un réparateur indépendant se connectant à l'atelier, un opérateur de flotte surveillant à distance et un ingénieur de support OEM effectuant le pré-triage avant une visite de service interagissent tous via la même interface logique, l'accès étant régi par des autorisations basées sur les rôles, et non par la pile d'outils propriétaires dont ils disposent.

Pour la conformité au MVBER, cela est important car l'architecture permet intrinsèquement un accès non discriminatoire. L'OEM définit les niveaux d'autorisation (qui voit quoi), mais l'interface elle-même est standardisée et accessible à tous les outils autorisés, sans être liée à un VCI ou à une chaîne d'outils spécifique à l'OEM.

Accès contrôlé et auditable : les OEM gardent le contrôle

Un point critique qui mérite d'être souligné : le SOVD n'ouvre les diagnostics des véhicules à personne. Les OEM conservent le contrôle total des autorisations via OAuth 2.0 et OpenID Connect, les mêmes normes de sécurité que celles utilisées dans les logiciels d'entreprise. Le contrôle d'accès basé sur les rôles détermine exactement ce que chaque type de client peut faire. Un réparateur indépendant a accès aux codes d'erreur et aux routines de diagnostic définies. Un ingénieur OEM bénéficie d'un accès plus approfondi aux fonctions d'étalonnage et de débogage. L'exploitant d'une flotte consulte les données relatives à la santé et à l'état.

Ce qui change, ce n'est pas qui contrôle l'accès, ce sont toujours les OEM qui le font, mais la manière dont cet accès est géré. Une API standardisée, journalisée et auditable remplace un ensemble fragmenté d'intégrations propriétaires difficiles à gérer à grande échelle.

Faire le lien entre les calculateurs existants et les architectures basées sur HPC

Le SOVD ne nécessite pas le remplacement de l'infrastructure ECU existante. Un adaptateur de diagnostic classique gère la traduction entre les requêtes SOVD et les commandes UDS pour les calculateurs traditionnels : les anciens systèmes continuent de fonctionner. Les nouvelles applications basées sur HPC peuvent exposer les diagnostics de manière native via SOVD. L'outil du réparateur indépendant communique avec une seule interface ; le véhicule gère le routage en interne. Cela rend l'adoption progressive réaliste sans programme de remplacement.

Preuve de conformité en tant que sous-produit

La norme UN R156 impose aux OEM de gérer leurs systèmes de gestion des mises à jour logicielles avec des preuves structurées de la manière dont les mises à jour sont planifiées, exécutées et validées. Les interactions d'API normalisées et enregistrées de SOVD génèrent naturellement ces preuves. L'inventaire des logiciels, les contrôles de disponibilité, la validation après la mise à jour et les journaux d'audit sont les résultats des opérations SOVD normales et ne constituent pas un exercice d'investigation distinct organisé au moment de l'examen de conformité.

L'avantage du réseau de concessionnaires et de services

Au-delà de la conformité, la valeur fondamentale de SOVD réside dans ce qu'elle permet aux concessionnaires et aux réseaux de service indépendants qui entretiennent des véhicules utilitaires compacts. C'est là que le retour sur investissement opérationnel devient concret.

Pré-triage à distance avant la visite de l'atelier

Le support central OEM peut accéder aux véhicules via SOVD avant leur arrivée pour entretien, en récupérant les journaux, en identifiant les modèles de panne, en configurant la capture de données haute résolution et, dans de nombreux cas, en résolvant les problèmes sans intervention physique. Lorsqu'une visite d'atelier est nécessaire, le technicien arrive avec le contexte, et non une feuille blanche. Les taux fixes pour la première fois s'améliorent. Les remplacements de pièces inutiles diminuent. Les coûts de garantie diminuent.

Des outils pour concessionnaires qui suivent le rythme des mises à jour logicielles

Dans le véhicule défini par logiciel, le profil de diagnostic de la voiture peut changer à chaque mise à jour OTA. L'architecture autodescriptive de SOVD signifie que les outils des concessionnaires découvrent les fonctionnalités actuelles des véhicules au moment de l'exécution plutôt que de s'appuyer sur des bases de données de description statiques qui sont peut-être déjà obsolètes. Les concessionnaires travaillent sur le véhicule qui existe aujourd'hui, et non sur un instantané du logiciel d'il y a six mois.

Habilitation des réparateurs indépendants sans exposition à la propriété intellectuelle

L'une des principales tensions en matière de droit à la réparation a toujours été la suivante : comment fournir un accès significatif aux diagnostics sans exposer un logiciel d'étalonnage propriétaire, un code ECU et des algorithmes de grande valeur ? Le SOVD résout ce problème grâce à l'encapsulation des services. L'API expose ce dont un réparateur a besoin pour diagnostiquer et entretenir le véhicule (codes d'erreur, valeurs de mesure, routines de test définies) sans exposer l'implémentation logicielle sous-jacente. Les OEM définissent les limites du service de diagnostic ; le SOVD l'applique.

Accès évolutif pour les opérateurs de flottes

Les opérateurs de flottes représentent certains des scénarios de service les plus exigeants : nombre élevé de véhicules, opérations critiques en termes de disponibilité, flottes géographiquement réparties. SOVD permet de surveiller l'état de santé au niveau de la flotte via la même API que celle utilisée pour le diagnostic individuel des véhicules, en agrégeant les modèles de panne, en suivant les versions des logiciels sur l'ensemble du parc et en identifiant les besoins de service proactifs avant qu'ils ne se transforment en panne.

Sibros SOVD : de l'évaluation à la production
‍Sibros a construit un Offre SOVD - couvrant à la fois les fonctionnalités des serveurs embarqués et les outils cloud et de back-office - conçu pour les OEM passant de l'évaluation architecturale au déploiement en production. Notre offre comprend :

• Client SOVD et plateforme d'administration : contrôle d'accès basé sur les rôles, flux de travail de diagnostic à distance et de proximité et journalisation structurée des audits tout au long du cycle de vie du véhicule.
• Intégration de la fabrication et de l'après-vente : la même infrastructure SOVD prend en charge la configuration de fin de ligne, les outils de service des concessionnaires et la surveillance à distance de la flotte sans implémentations distinctes.
• OTA et écosystème d'exploitation forestière : Diagnostic du SOVD et gestion des mises à jour logicielles travaillez à partir d'une infrastructure unifiée aux côtés de Sibros Deep Logger et capacités OTA.
• Services de conseil de la SOVD : pour les OEM qui évaluent les décisions relatives à l'architecture, définissent les exigences des fournisseurs ou planifient l'adoption progressive du SOVD dans l'ensemble des programmes de véhicules. ‍

‍La conformité de l'UE au droit à la réparation constitue la base de référence depuis trente ans. Ce qui change, c'est le véhicule et, avec lui, les exigences architecturales liées à la mise en conformité à grande échelle de flottes définies par logiciel. Les OEM qui mettent en place une infrastructure de diagnostic autour du SOVD ne se contentent pas de résoudre un problème de conformité. Ils jettent les bases des opérations de service pour l'ère des SDV.