Logiciel embarqué, AUTOSAR et architecture électronique du véhicule : audit, conseil, formation et assistance technique pour l'automobile

Le cadre normatif du logiciel embarqué automobile

AUTOSAR, plateformes Classic et Adaptive

AUTOSAR est un partenariat de normalisation qui publie une architecture logicielle embarquée standardisée pour les véhicules. Sa vision affichée est celle d'un standard de logiciel et de méthode pour des architectures électroniques et électriques ouvertes, avec pour buts la modularité, des interfaces normalisées et la réutilisation du logiciel. Le site d'AUTOSAR présente la plateforme Classic, la plateforme Adaptive, les interfaces applicatives et un socle commun nommé Foundation.

La plateforme Classic s'adresse aux calculateurs soumis à des contraintes temps réel strictes et à des ressources limitées : la pile de base est configurée avant la génération du code, et les échanges se décrivent dans des fichiers au format ARXML. La plateforme Adaptive vise des calculateurs plus puissants, qui exécutent des applications en C++ pouvant être mises à jour et communiquant par services. Les deux coexistent dans un même véhicule et dialoguent entre elles. Les niveaux de partenariat d'AUTOSAR sont payants : nous ne sommes pas partenaire d'AUTOSAR, et nos mentions du standard sont purement descriptives.

Règles de codage, langages et système temps réel

Le langage C domine les piles de base et le code de bas niveau, tandis que le C++ s'est installé dans les applications de la plateforme Adaptive. Pour limiter les défauts propres à ces langages, la plupart des constructeurs et des équipementiers automobiles imposent un jeu de règles de codage. La référence la plus répandue est MISRA C. Selon la page de l'éditeur, l'édition courante est MISRA C:2025, mise à jour en mars 2025, qui remplace les éditions de 1998, 2004, 2012, 2019 et 2023. Une règle s'applique à un projet avec des écarts justifiés par écrit, et un outil d'analyse statique en vérifie une partie seulement : le reste relève de la revue.

Le système d'exploitation temps réel et l'ordonnancement des tâches posent des questions voisines : priorités, temps d'exécution maximal, gestion des interruptions, protection de la mémoire. Ils conditionnent le respect des échéances de chaque fonction, sur un microcontrôleur seul comme sur un système sur puce à plusieurs cœurs. Un défaut d'ordonnancement se voit rarement en essais courts et se révèle à la charge maximale, d'où l'intérêt d'une revue d'architecture avant l'intégration plutôt qu'après les premiers essais véhicule.

Mises à jour logicielles et réception : règlements ONU R155 et R156

Deux règlements ONU (Organisation des Nations unies) ont fait entrer le logiciel dans la réception des véhicules. Le règlement n° 155 porte sur la cybersécurité et le système de management de la cybersécurité : adopté à Genève le 24 juin 2020, entré en vigueur le 22 janvier 2021 et amendé trois fois depuis, selon le registre des traités des Nations unies. Le règlement n° 156 porte sur les mises à jour logicielles et sur le système de gestion de ces mises à jour ; il est entré en vigueur à la même date, et le registre mentionne une notification d'amendements du 12 juin 2026.

Dans l'Union, le règlement (UE) 2019/2144 rend ces textes applicables à la réception : nouveaux types de véhicules à partir de juillet 2022, puis ensemble des véhicules neufs à partir de juillet 2024. Le certificat appartient au constructeur. Un équipementier de rang 1 ne détient pas lui-même de système de gestion au sens du règlement, mais ses clients lui répercutent des exigences de traçabilité des versions, de contrôle d'intégrité des mises à jour et de gestion des vulnérabilités. La norme ISO 24089, consacrée à l'ingénierie des mises à jour logicielles des véhicules, sert de cadre technique à ces exigences. La sûreté fonctionnelle et la cybersécurité (ISO 26262, ISO/SAE 21434) font l'objet d'un autre domaine de ce site : nous n'en retenons ici que l'effet sur l'architecture logicielle.

Les enjeux d'un équipementier et d'un constructeur

Intégrer des logiciels de plusieurs fournisseurs

Un calculateur livré par un équipementier de rang 1 réunit rarement un seul auteur : le fabricant du microcontrôleur ou du système sur puce fournit des pilotes, un éditeur ou une équipe interne la pile de base, le constructeur ses exigences de communication et de diagnostic, et l'équipementier l'application. Chaque version doit être intégrée, testée et tracée, avec des variantes qui se multiplient selon les motorisations, les pays et les équipements. Les sous-traitants de rang 2 qui livrent du logiciel de base ou des modules électroniques subissent la même chaîne d'exigences, répercutée de rang en rang.

Dans ce contexte, les clients demandent des preuves : conformité aux règles de codage, couverture des tests, traçabilité des exigences, journal des écarts acceptés. Les processus de développement sont examinés selon Automotive SPICE (Software Process Improvement and Capability dEtermination, évaluation de la capacité des processus logiciels), dont le domaine voisin d'ingénierie système et de validation traite le cadre. Notre rôle ici est plus technique : rendre l'architecture et le code assez lisibles pour que ces preuves puissent être produites sans reprise massive.

Automotive Ethernet et architecture électronique

Les bus CAN et LIN restent présents, mais Automotive Ethernet s'impose pour les flux volumineux et pour relier les calculateurs puissants : liaisons monopaires de type 100BASE-T1 ou 1000BASE-T1, communication orientée services avec SOME/IP, diagnostic sur IP (Internet Protocol, protocole internet) selon ISO 13400. Cette évolution accompagne le regroupement des fonctions, soit par domaine fonctionnel, soit par zone du véhicule, avec moins de calculateurs et davantage de puissance centralisée.

Ces choix d'architecture ont des conséquences en chaîne : charge processeur et réseau, latences, partitionnement des fonctions de niveaux d'exigence différents, mise à jour à distance, coût de la nappe de câblage. Un conseil d'architecture, mené avant que les interfaces soient figées avec le constructeur, coûte moins qu'une réorganisation en cours de programme, notamment lorsque la plateforme choisie doit supporter plusieurs générations de véhicules.

Le diagnostic et la reprogrammation des calculateurs ajoutent une couche d'exigences souvent sous-estimée : services de diagnostic normalisés (le protocole UDS, décrit par l'ISO 14229), descriptions de diagnostic échangées avec le constructeur, chargeur de démarrage capable de recevoir une nouvelle version sans bloquer le calculateur si le transfert est interrompu. Ces fonctions s'écrivent tôt et se testent tard ; elles pèsent pourtant sur la mise à jour à distance, sur la maintenance et sur la réception, et méritent leur propre revue.

Rôles, responsabilités et données du véhicule

Le constructeur porte la réception du véhicule et la cohérence de l'architecture d'ensemble. L'équipementier répond de son calculateur, de son logiciel et des preuves associées, dans les limites du contrat. Les véhicules connectés produisent en outre des données dont l'accès est encadré par le règlement (UE) 2023/2854, dit Data Act, applicable depuis le 12 septembre 2025 : la page de la Commission cite les voitures et renvoie à un guide sur les données des véhicules.

Pour un logiciel embarqué, cela signifie documenter ce qui est collecté, où cela transite et qui peut y accéder, ce qui rejoint les exigences de traçabilité déjà évoquées. Nous n'apportons pas d'avis juridique sur ces textes : nous aidons les équipes d'ingénierie à traduire les exigences en choix d'architecture, que leurs juristes et leurs experts de la réception valident ensuite.

Ce que nous faisons, et ce que nous ne faisons pas

Ce que nous faisons

Nous intervenons sur quatre registres, sous la responsabilité d'Optédif :

• la revue d'architecture et de code, avec des constats classés par criticité et un plan de remédiation ;
• le conseil sur l'architecture électronique et sur la stratégie AUTOSAR, avec des options comparées ;
• la conception de composants, de couches d'abstraction et de configurations, remis avec leurs sources et leurs tests ;
• l'assistance technique, pour réaliser un lot défini d'intégration ou de développement.

Nous travaillons avec les outils que vous utilisez, parmi lesquels ceux d'ETAS : le site de l'éditeur présente notamment une solution de logiciel de base AUTOSAR Classic (RTA-CAR) et les outils de mesure et de calibration INCA. Ces mentions sont descriptives. La formation en intra-entreprise complète ces prestations pour que vos équipes reprennent les pratiques mises en place.

Ce que nous ne faisons pas

Nous ne délivrons aucune certification, homologation, réception, évaluation officielle ni label, et nous n'employons pas de personnel certifié par un tiers. Une revue de notre part ne valide pas un produit : la validation, la sûreté fonctionnelle et la cybersécurité de votre logiciel restent de votre responsabilité, éventuellement confirmées par un organisme indépendant. Nous n'engageons ni l'obtention d'une réception, ni la conformité d'un produit aux règlements ONU, aux normes ISO ou aux exigences de votre client.

Nous ne sommes ni partenaire d'AUTOSAR, ni revendeur ou centre de formation officiel des outils cités. Nous ne signons pas à votre place les documents que vous adressez à votre client, et nous ne nous substituons pas à votre responsable de la qualité logicielle. Nos audits et revues sont des prestations de conseil, sans valeur de certification, qui ne préjugent pas de la décision de votre client.

Assistance technique et confidentialité

Nos missions d'assistance technique sont réalisées par nos intervenants, sous la responsabilité et l'encadrement d'Optédif, avec des livrables définis, dans le cadre d'un contrat de prestation de services portant sur un objectif et un périmètre convenus avec vous. Elles sont proposées au forfait ou en récurrent. Nos intervenants restent salariés d'Optédif, dirigés et encadrés par Optédif, et ne sont pas intégrés à votre hiérarchie.

Le code, les configurations, les données de prototypes et de pré-série ne sont traités que dans le cadre contractuel de confidentialité, de propriété intellectuelle et de sécurité de l'information défini avec vous avant le démarrage. Si certains composants relèvent d'un contrôle à l'exportation, signalez-le dès le cadrage : nous adaptons alors le périmètre et les accès.

Références officielles

Standards et référentiels

Le standard AUTOSAR et ses plateformes, les règles de codage de MISRA et le présent descriptif des outils d'ETAS sont à consulter chez leurs éditeurs, qui seuls font foi. Les normes ISO et les spécifications des bus de communication sont payantes et s'obtiennent auprès de l'organisation de normalisation concernée ; nous ne reproduisons aucun de leurs textes.

L'Automotive SPICE est publié par le VDA (Verband der Automobilindustrie, association allemande de l'industrie automobile) QMC (Quality Management Center, centre de management de la qualité de la VDA), et la certification des personnes qui conduisent les évaluations est gérée par intacs. Ces points sont détaillés dans notre domaine consacré à l'ingénierie système et à ASPICE.

Autorités et textes de réception

Les règlements ONU n° 155 et 156 sont suivis par le registre des traités des Nations unies. Leur application dans l'Union passe par le règlement (UE) 2019/2144, consultable sur EUR-Lex.

En France, la réception des véhicules relève du ministre chargé des transports, par délégation de la sous-direction SD6 (sous-direction chargée de la réception des véhicules du ministère des transports), avec le Centre national de réception des véhicules et l'UTAC (organisme d'essais, d'homologation et de certification de l'automobile) comme service technique, comme le décrit la page du ministère. Les règlements sont à lire dans leur dernière version à la source avant toute décision.