Brevet FR3125607A1 — publié le 20230127

La présente invention concerne un procédé et un dispositif de calibration d’un calculateur de véhicule. A cet effet, le calculateur met en œuvre une architecture logicielle multicouches (1) comprenant une couche applicative haut niveau (10) et une couche de service bas niveau (11), la couche applicative mettant en œuvre une pluralité de modules logiciels applicatifs (101 à 103) et la couche de service mettant en œuvre un module de gestion (111) de données de calibration stockées en mémoire du calculateur. Un accès en lecture, par un des modules logiciels applicatifs, à un jeu de données de calibration est permis via le module de gestion (111) de données de calibration par l’intermédiaire d’une première interface (1100) entre la couche applicative (10) et la couche de service (11), cette première interface (1100) étant commune à tous les modules logiciels applicatifs (101 à 103). Figure pour l’abrégé : Figure 1 Procédé et dispositif de calibration d’un calculateur de véhicule La présente invention concerne les procédés et dispositifs de calibration d’un calculateur d’un véhicule, par exemple un véhicule automobile. La présente invention concerne également un procédé et un dispositif de communication de données entre plusieurs couches d’une architecture logicielle multicouches d’un calculateur de véhicule. Arrière-plan technologique Les véhicules contemporains embarquent un grand nombre de calculateurs assurant chacun par exemple une ou plusieurs fonctions de systèmes d’aide à la conduite, telles que par exemple la gestion de l’aide à la conduite, de l’antipatinage, de la répartition électronique du freinage ou encore la commande d’actionneurs pour assurer le fonctionnement optimal d’un moteur à combustion. Ces systèmes d’aide à la conduite sont connus sous le nom de systèmes dits ADAS (de l’anglais « Advanced Driver-Assistance System » ou en français « Système d’aide à la conduite avancé »). Les systèmes d’aide à la conduite les plus aboutis assurent le contrôle du véhicule qui devient un véhicule dit autonome, c’est-à-dire un véhicule apte à rouler dans l’environnement routier sans intervention du conducteur. Ces calculateurs sont aussi appelés UCE (« Unité de Commande Electronique » ou en anglais ECU « Electronic Control Unit »). Ces calculateurs embarquent des logiciels qui sont exécutés pour assurer les fonctions dont ils ont la charge. Ces calculateurs mettent en œuvre une architecture logicielle multicouche avec une hiérarchie entre les couches, la ou les couches de niveau plus élevé mettant en œuvre des logiciels applicatifs exécutant les fonctions ADAS par exemple alors que la ou les couches de plus bas niveau mettent en œuvre des services tels que des accès au bus de données, à la mémoire, etc. Une telle hiérarchie entre les couches est par exemple décrite dans le modèle OSI (de l’anglais « Open Systems Interconnection » ou en français « Interconnexion de systèmes ouverts ») ou, concernant plus spécifiquement les calculateurs de véhicule, dans le standard AUTOSAR (de l’anglais « AUTomotive Open System Architecture » ou en français « Architecture de système ouvert automobile »). Pour fonctionner, les logiciels applicatifs de la ou les couches haut niveau font appel ou utilisent des données de calibration accessibles via un module de gestion de données de calibration mis en œuvre dans une couche de service bas niveau. La modification des données de calibration implique de modifier systématiquement la couche de service bas niveau mettant en œuvre ce module, ce qui complexifie notamment le processus de développement des logiciels applicatifs requérant de nouvelles données de calibration ou des données de calibration mises à jour. Ainsi, une modification des données de calibration requises pour une évolution d’un logiciel applicatif requiert une mise à jour de logiciels mis en œuvre dans les couches bas niveau gérant ces données de calibration, la dépendance entre les logiciels applicatifs de la ou les couches haut niveau et les services fournies par les couches bas niveau étant très forte. Les coûts et temps de développement de la partie applicative haut niveau sont ainsi très élevés. Résumé de la présente invention Un objet de la présente invention est de résoudre au moins un des inconvénients de l’arrière-plan technologique. Un autre objet de la présente invention est de réduire la dépendance entre une partie applicative haut niveau et une partie service bas niveau d’une architecture logicielle multicouches d’un calculateur de véhicule. Selon un premier aspect, la présente invention concerne un procédé de calibration d’un calculateur de véhicule, le calculateur mettant en œuvre une architecture logicielle multicouches comprenant une couche applicative haut niveau et au moins une couche de service bas niveau, la couche applicative haut niveau mettant en œuvre une pluralité de modules logiciels applicatifs et la au moins une couche de service bas niveau mettant en œuvre un module de gestion de données de calibration stockées en mémoire du calculateur, le procédé comprenant une étape d’accès en lecture, par un premier module logiciel applicatif de la pluralité de modules logiciels applicatifs, à au moins un premier jeu de données de calibration via le module de gestion de données de calibration par l’intermédiaire d’une première interface entre la couche applicative haut niveau et la au moins une couche de service bas niveau, la première interface étant commune à chaque module logiciel applicatif de la pluralité de modules logiciels applicatifs. Selon une variante, la première interface est configurée pour permettre un accès en lecture à le au moins un premier jeu de données de calibration à chaque module logiciel applicatif de la pluralité de modules logiciels applicatifs via le module de gestion de données de calibration. Selon une autre variante, les données de calibration du au moins un premier jeu sont stockées dans la mémoire sous une forme de tableau et/ou sous une forme de scalaires. Selon une variante supplémentaire, le procédé comprend en outre une étape d’accès en lecture, par un deuxième module logiciel applicatif de la pluralité, à au moins un deuxième jeu de données de calibration via le module de gestion de données de calibration par l’intermédiaire d’au moins une deuxième interface entre la couche applicative haut niveau et la au moins une couche de service bas niveau, la au moins une deuxième interface étant dédiée au deuxième module logiciel. Selon encore une variante, chaque module logiciel applicatif de la pluralité de modules logiciels applicatifs est configuré pour mettre en œuvre au moins une fonction d’un système d’aide à la conduite du véhicule, dit système ADAS. Selon une variante additionnelle, le au moins un premier jeu de données est identifié par un nom générique ne dépendant pas de la au moins une fonction du système ADAS. Selon une autre variante, un volume du au moins un premier jeu de données de calibration est fonction d’un espace disponible dédiée aux données de calibration dans la mémoire. Selon un deuxième aspect, la présente invention concerne un dispositif de calibration d’un calculateur de véhicule, le dispositif comprenant une mémoire associée à un processeur configuré pour la mise en œuvre des étapes du procédé selon le premier aspect de la présente invention. Selon un troisième aspect, la présente invention concerne un véhicule, par exemple de type automobile, comprenant un dispositif tel que décrit ci-dessus selon le deuxième aspect de la présente invention. Selon un quatrième aspect, la présente invention concerne un programme d’ordinateur qui comporte des instructions adaptées pour l’exécution des étapes du procédé selon le premier aspect de la présente invention, ceci notamment lorsque le programme d’ordinateur est exécuté par au moins un processeur. Un tel programme d’ordinateur peut utiliser n’importe quel langage de programmation, et être sous la forme d’un code source, d’un code objet, ou d’un code intermédiaire entre un code source et un code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. Selon un cinquième aspect, la présente invention concerne un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé selon le premier aspect de la présente invention. D’une part, le support d’enregistrement peut être n'importe quel entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire ROM, un CD-ROM ou une mémoire ROM de type circuit microélectronique, ou encore un moyen d'enregistrement magnétique ou un disque dur. D'autre part, ce support d’enregistrement peut également être un support transmissible tel qu'un signal électrique ou optique, un tel signal pouvant être acheminé via un câble électrique ou optique, par radio classique ou hertzienne ou par faisceau laser autodirigé ou par d'autres moyens. Le programme d’ordinateur selon la présente invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme d’ordinateur est incorporé, le circuit intégré étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève description des figures D’autres caractéristiques et avantages de la présente invention ressortiront de la description des exemples de réalisation particuliers et non limitatifs de la présente invention ci-après, en référence aux figures 1 à 3 annexées, sur lesquelles : illustre schématiquement une architecture logicielle multicouches d’un calculateur de véhicule, selon un exemple de réalisation particulier et non limitatif de la présente invention ; illustre schématiquement un dispositif configurer pour calibrer le calculateur de la , selon un exemple de réalisation particulier et non limitatif de la présente invention ; illustre un organigramme des différentes étapes d’un procédé de calibration du calculateur de la , selon un exemple de réalisation particulier et non limitatif de la présente invention. Description des exemples de réalisation Un procédé et un dispositif de calibration d’un calculateur de véhicule vont maintenant être décrits dans ce qui va suivre en référence conjointement aux figures 1 à 3. Des mêmes éléments sont identifiés avec des mêmes signes de référence tout au long de la description qui va suivre. Selon un exemple particulier et non limitatif de réalisation de la présente invention, un calculateur d’un véhicule met en œuvre une architecture logicielle multicouches, par exemple telle que décrite dans le standard AUTOSAR. Une telle architecture comprend une pluralité de couches hiérarchisées, parmi lesquelles une couche applicative haut niveau met en œuvre une pluralité de modules logiciels applicatifs et une ou plusieurs couches de service bas niveau (c’est-à-dire avec un niveau hiérarchique inférieure à la couche applicative) mettent en œuvre un module de gestion de données de calibration, ces données de calibration étant utilisées par les modules logiciels applicatifs, les données de calibration étant stockées en mémoire du calculateur. Un accès en lecture à un ou plusieurs premiers jeux de données de calibration est donné à un premier module logiciel applicatif via le module de gestion des données de calibration, cet accès étant permis par une première interface commune à l’ensemble des modules logiciels applicatifs entre la couche applicative haut niveau et les couches de service bas niveau. Cette première interface vient en sus de deuxièmes interfaces existantes, chaque deuxième interface étant dédiée et spécifique à un deuxième module logiciel applicatif pour accéder à un deuxième jeu de données de calibration particulier. Le standard AUTOSAR est par exemple décrit dans le document version 11.2020: R20-11. Les données de calibration correspondent par exemple à des variables globales constantes dans un logiciel, appelé module logiciel applicatif. Ces données de calibration ne peuvent pas être modifiées lors de l’exécution du code du logiciel en vie série du véhicule. Ces données de configuration peuvent être modifiées ou mises à jour via un outil d’instrumentation ou via un outil de téléchargement. Une calibration d’un logiciel permet, à chaque phase du développement d’un logiciel d’un calculateur, de mettre au point une ou plusieurs lois de commande jusqu’à arriver à une solution optimale pour la vie série du calculateur mettant en œuvre ces lois de commande via les logiciels applicatifs mis en œuvre par la couche applicative haut niveau. Cela permet d’assurer un fonctionnement du calculateur conforme à un cahier des charges, permettant d’assurer la sécurité du véhicule et de ses passagers. La première interface commune à l’ensemble des modules logiciels applicatifs fait office d’interface générique entre les modules logiciels applicatifs et le module de gestion de données de calibration ce qui facilite les accès aux premiers jeux de données de calibration accessible par l’ensemble des modules logiciels applicatifs, même lorsque ces derniers évoluent ou sont modifiés. L’accès générique aux premiers jeux de données de calibration permet de calibrer et tester chaque module logiciel lors d’une évolution de ce module logiciel, ce qui facilite le développement de tels modules logiciels et réduit les coûts de développement associés. La première interface est configurée pour permettre l’évolution des utilisations de calibration d’au moins une couche applicative haut niveau sans modification d’une seule couche de service bas niveau. illustre schématiquement une architecture logicielle multicouches 1 d’un calculateur de véhicule, selon un exemple de réalisation particulier et non limitatif de la présente invention. Le calculateur, dont l’architecture est présentée de manière schématique sur la , met par exemple en œuvre une ou plusieurs fonctions d’un système ADAS via plusieurs modules logiciels applicatifs 101, 102, 103 (aussi appelés applications), par exemple pour la gestion des radars millimétriques équipant le véhicule et permettant la détection d’objets dans l’environnement du véhicule, ainsi que la distance entre le véhicule et ses objets. Des exemples de tels système ADAS sont fournis à titre d’illustration de manière non exhaustive ci-dessous : - système d’aide au stationnement ; - système d’aide au maintien dans la file de circulation du véhicule, dit système LKA (de l’anglais « Lane-Keeping Assist » ou en français « Assistant de maintien dans la file ») ; - système de régulation adaptative de vitesse, dit ACC (de l’anglais « Adaptive Cruise Control ») ; - régulateur de vitesse prédictif, dit système PCC (de l’anglais « Predictive Cruise Control ») ; - système de contrôle électronique de stabilité, dit système ESC (de l’anglais « Electronic Stability Control » ou en français « Contrôle électronique de la stabilité »), DSC (de l’anglais « Dynamic Stability Control » ou en français « Contrôle dynamique de la stabilité ») ou encore ESP (de l’anglais « Electronic Stability Program » ou en français « Programme électronique de la stabilité ») ; - système de climatisation automatique ; - allumage automatique des feux de croisement ; - essuie-vitre automatique. L’architecture logicielle 1 du calculateur comprend une ou plusieurs couches applicatives 10 de haut niveau et une ou plusieurs couches de bas niveau 11 (c’est-à-dire de niveau inférieur à la ou les couches applicatives haut niveau), dites de service. Dans ce qui suit, il sera fait référence à une couche applicative haut niveau 10 et une couche de service bas niveau 11 pour des raisons de clarté, le nombre de couche(s) applicative(s) haut niveau ne se limitant pas à une seule couche et le nombre de couche(s) de service bas niveau ne se limitant pas à une seule couche. La couche applicative haut niveau 10 met avantageusement en œuvre plusieurs modules logiciels applicatifs 101, 102, 103 mettant par exemple chacun en œuvre une fonction déterminée d’un système ADAS, par exemple la gestion des radars du véhicule pour la détection d’objet(s), la mesure de la distance vis-à-vis de ces objets, la reconnaissance de ces objets, etc. Le nombre de modules logiciels applicatifs mis en œuvre dans la couche 10 n’est pas limité à 3 mais s’étend à tout nombre supérieur ou égal à 1. La validation et la calibration de chacun de ces modules logiciels applicatifs 101, 102, 103 se fait sur la base de données de calibration stockées en mémoire du calculateur, les accès en lecture à ces données de calibration étant gérés par un module de gestion des données de calibration 111 mis en œuvre par la couche de service bas niveau 11. Le module de gestion 111 des données de calibration gère et garantit les accès aux différents jeux de données de calibration stockés en mémoire du calculateur suivant les adresses physiques allouées à ces différents jeux de données de calibration. Les modules logiciels applicatifs 101 à 103 ont accès en lecture à ces différents jeux de données de calibration sans cependant avoir besoin de connaitre les adresses physiques de ces jeux de données dans la mémoire. La couche applicative haut niveau ne gère ainsi pas les adresses mémoires des jeux de données de calibration. La ou les couches de service bas niveau 11 mettent avantageusement en œuvre des modules logiciels dit de base ou basiques (de l’anglais « Basic Software » ou en français « Logiciels basiques »), dont le module de gestion des données de calibration 111. Selon une variante de réalisation, l’architecture logicielle comprend une couche de niveau intermédiaire entre la couche applicative haut niveau 10 et la couche de service bas niveau, cette couche étant appelée couche RTE (de l’anglais « Runtime Environment » ou en français « Environnement d’exécution »). Les couches bas niveau comprennent par exemple une couche de service, une couche d’abstraction d’UCE (« Unité de Commande Electronique » ou en anglais ECU « Electronic Control Unit », aussi appelée calculateur), une couche d’abstraction de microcontrôleur et une couche de pilotes complexes. Ces différentes couches et leurs fonctions sont connues de l’homme du métier et ne sont pas décrites en détail. Ces couches bas niveau, dite de service, fournissent plusieurs prestations ou services, par exemple regroupés fonctionnellement, par exemple elles délivrent des services d’accès à la mémoire du calculateur, des services d’accès au système ou encore des services de communication (via par exemple un ou plusieurs bus de données). Chacun de ces services est fourni ou mis en œuvre par un ou plusieurs modules logiciels dits de base ou basiques. Ainsi, l’accès à la mémoire et notamment aux données de calibration par les modules logiciels applicatifs 101 à 103 de la couche applicative haut niveau 10 est contrôlé par le module de gestion des données de calibration 111 de la couche de service bas niveau 11. Les accès aux données de calibrations par les modules logiciels applicatifs 101, 102, 103 sont obtenus via le module de gestion 111 des données de calibration par l’intermédiaire : - d’une première interface 1100 commune à l’ensemble des modules logiciels applicatifs 101 à 103 de la couche applicative haut niveau 10 pour accéder à un ou plusieurs premiers jeux de données de calibration stockés en mémoire, chacun de ces premiers jeux étant accessible par chaque module logiciel applicatif de la couche applicative 10 ; et - d’une pluralité de deuxièmes interfaces 1101, 1102, 1103 et 1104 chacune spécifique à un unique module logiciel applicatif de la couche applicative 10, chaque deuxième interface permettant à un deuxième jeu de données spécifique au module logiciel applicatif auquel est dédiée la deuxième interface permettant d’accéder à ce deuxième jeu de données de calibration. Ainsi par exemple, le module logiciel applicatif 101 a accès à un deuxième jeu de données de calibration déterminé via la deuxième interface 1101 qui est dédiée uniquement à ce module logiciel 101 ; le module logiciel applicatif 102 a accès à un deuxième jeu de données de calibration déterminé via la deuxième interface 1102 qui est dédiée uniquement à ce module logiciel 102 ainsi qu’à un autre deuxième jeu de données de calibration déterminé via la deuxième interface 1103 qui est dédiée uniquement à ce module logiciel 102 ; et le module logiciel applicatif 103 a accès à un deuxième jeu de données de calibration déterminé via la deuxième interface 1104 qui est dédiée uniquement à ce module logiciel 103. Les accès au(x) premier(s) jeu(x) de données de calibration par les modules logiciels 101 à 103 via la première interface 1100 sont illustrés avec des traits en pointillés alors que les accès aux deuxièmes jeux de données de calibration par les modules logiciels 101 à 103 via les deuxièmes interfaces 1101 à 1104 sont illustrés avec des traits pleins sur la . L’accès en lecture au(x) premier(s) jeu(x) de données de calibration par un ou plusieurs premiers modules logiciels applicatifs parmi les modules 101 à 103 comprend par exemple, pour un premier module logiciel applicatif, la transmission d’une requête de lecture d’un premier jeu de données de calibration. La requête comprend par exemple un nom identifiant ce premier jeu de données, le nom étant défini selon des règles de nommage déterminées. Par exemple, le nom d’un premier jeu de données de calibration est choisi de manière à être générique, c’est-à-dire ne dépendant pas des fonctions du système ADAS mises en œuvre par les modules logiciels applicatifs 101 à 103. Les données sont elles-mêmes chacune identifiées par un nom générique. Les noms des différents premiers jeux sont avantageusement connus de chacun des modules 101 à 103, permettant à chacun de ces modules d’appeler un ou plusieurs premiers jeux en fonction des besoins de calibration lors des différentes phases de développement de ces modules logiciels applicatifs 101 à 103, à l’exception de la première phase de développement qui s’appuie sur les deuxièmes jeux de données calibrations spécifiques à chaque module logiciel applicatif 101 à 103. Cette requête est transmise via la première interface 1100. A réception de la requête en lecture, le module de gestion 111 détermine l’adresse physique du premier jeu de données de calibration requis à partir du nom contenu dans la requête et identifiant ce premier jeu de données de calibration. Cette adresse physique est par exemple déterminée à partir d’une table de correspondance, dite LUT (de l’anglais « Look-Up Table ») mettant en correspondance ou associant les noms de chacun des premiers jeux de données stockées en mémoire avec leur adresse physique respective dans la mémoire. L’accès en lecture à un ou plusieurs deuxièmes jeux de données de calibration par un module logiciel applicatif auquel ces deuxièmes jeux sont dédiés (appelé deuxième module logiciel applicatif) est obtenu de manière similaire par l’émission d’une requête en lecture par ce deuxième module à destination du module de gestion 111. Cependant, chaque deuxième jeu de données est nommé selon un nom particulier dépendant de la fonction du système ADAS mise en œuvre par ce deuxième module logiciel applicatif. Un deuxième jeu de données ne peut ainsi être appelé en lecture que par le deuxième module auquel il est dédié via la deuxième interface également dédiée à ce deuxième module et à ce deuxième jeu de données de calibration. Le module de gestion 111 fournit alors un accès en lecture au premier jeu de données requis via la première interface 1100 au module logiciel applicatif ayant émis la requête. Le processus de calibration du module logiciel applicatif est alors mis en œuvre sur la base du premier jeu de données de calibration. Chaque premier jeu de données de calibration est par exemple stocké en mémoire sous la forme d’une table ou tableau ou sous la forme de scalaires. Selon une variante, un premier jeu de données de calibration est stocké selon un mixte tableau(x)/scalaires. La taille ou le volume total des premiers jeux de données de calibration est fonction de l’espace mémoire disponible pour les données de calibration, et ne peut excéder ce volume d’espace mémoire disponible ou dédié aux données de calibration. illustre schématiquement un dispositif 2 configuré pour la calibration d’un ou plusieurs logiciels d’une couche applicative d’un calculateur, selon un exemple de réalisation particulier et non limitatif de la présente invention. Le dispositif 2 correspond par exemple à un dispositif embarqué dans le véhicule, par exemple un calculateur. Le dispositif 2 est par exemple configuré pour la mise en œuvre des opérations décrites en regard de la et/ou des étapes du procédé décrit en regard de la . Des exemples d’un tel dispositif 2 comprennent, sans y être limités, un équipement électronique embarqué tel qu’un ordinateur de bord d’un véhicule ou un calculateur électronique tel qu’une UCE (« Unité de Commande Electronique »). Les éléments du dispositif 2, individuellement ou en combinaison, peuvent être intégrés dans un unique circuit intégré, dans plusieurs circuits intégrés, et/ou dans des composants discrets. Le dispositif 2 peut être réalisé sous la forme de circuits électroniques ou de modules logiciels (ou informatiques) ou encore d’une combinaison de circuits électroniques et de modules logiciels. Le dispositif 2 comprend un (ou plusieurs) processeur(s) 20 configurés pour exécuter des instructions pour la réalisation des étapes du procédé et/ou pour l’exécution des instructions du ou des logiciels embarqués dans le dispositif 2. Le processeur 20 peut inclure de la mémoire intégrée, une interface d’entrée/sortie, et différents circuits connus de l’homme du métier. Le dispositif 2 comprend en outre au moins une mémoire 21 correspondant par exemple à une mémoire volatile et/ou non volatile et/ou comprend un dispositif de stockage mémoire qui peut comprendre de la mémoire volatile et/ou non volatile, telle que EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, disque magnétique ou optique. Le code informatique du ou des logiciels embarqués comprenant les instructions à charger et exécuter par le processeur est par exemple stocké sur la mémoire 21. Selon différents exemples de réalisation particuliers et non limitatifs, le dispositif 2 est couplé en communication avec d’autres dispositifs ou systèmes similaires et/ou avec des dispositifs de communication, par exemple une TCU (de l’anglais « Telematic Control Unit » ou en français « Unité de Contrôle Télématique »), par exemple par l’intermédiaire d’un bus de communication ou au travers de ports d’entrée / sortie dédiés. Selon un exemple de réalisation particulier et non limitatif, le dispositif 2 comprend une interface de communication 22 qui permet d’établir une communication avec d’autres dispositifs (tels que d’autres calculateurs du système embarqué) via un canal de communication 220. L’interface de communication 22 correspond par exemple à un transmetteur configuré pour transmettre et recevoir des informations et/ou des données via le canal de communication 220. L’interface de communication 22 correspond par exemple à un réseau filaire de type CAN (de l’anglais « Controller Area Network » ou en français « Réseau de contrôleurs »), CAN FD (de l’anglais « Controller Area Network Flexible Data-Rate » ou en français « Réseau de contrôleurs à débit de données flexible »), FlexRay (standardisé par la norme ISO 17458) ou Ethernet (standardisé par la norme ISO/IEC 802-3). Selon un exemple de réalisation particulier et non limitatif, le dispositif 2 peut fournir des signaux de sortie à un ou plusieurs dispositifs externes. illustre un organigramme des différentes étapes d’un procédé de calibration d’un calculateur d’un véhicule et/ou de calibration d’un ou plusieurs modules logiciels applicatifs d’une couche applicative haut niveau du calculateur, selon un exemple de réalisation particulier et non limitatif de la présente invention. Le procédé est par exemple mis en œuvre par un dispositif embarqué dans le véhicule, par exemple par le dispositif 2 de la . Dans une étape 31, un accès en lecture à au moins un premier jeu de données de calibration est autorisé pour un premier module logiciel applicatif d’une pluralité de modules logiciels applicatifs mis en œuvre dans une couche applicative haut niveau du calculateur. Cet accès est autorisé via un module de gestion de données de calibration mis en œuvre dans une couche de service bas niveau du calculateur, par l’intermédiaire d’une première interface entre la couche applicative haut niveau et la couche de service bas niveau. Cette première interface est avantageusement commune à chaque module logiciel applicatif de la pluralité de modules logiciels applicatifs mis en œuvre dans la couche applicative haut niveau du calculateur. Selon une variante, les variantes et exemples des opérations décrits en relation avec la s’appliquent aux étapes du procédé de la . Bien entendu, la présente invention ne se limite pas aux exemples de réalisation décrits ci-avant mais s’étend à un procédé de calibration d’un logiciel applicatif qui inclurait des étapes secondaires sans pour cela sortir de la portée de la présente invention. Il en serait de même d’un dispositif configuré pour la mise en œuvre d’un tel procédé. La présente invention concerne également un véhicule, par exemple automobile ou plus généralement un véhicule autonome à moteur, comprenant le dispositif 2 de la . Procédé de calibration d’un calculateur de véhicule, ledit calculateur mettant en œuvre une architecture logicielle multicouches (1) comprenant une couche applicative haut niveau (10) et au moins une couche de service bas niveau (11), ladite couche applicative haut niveau (10) mettant en œuvre une pluralité de modules logiciels applicatifs (101, 102, 103) et ladite au moins une couche de service bas niveau (11) mettant en œuvre un module de gestion (111) de données de calibration stockées en mémoire dudit calculateur, ledit procédé comprenant une étape (31) d’accès en lecture, par un premier module logiciel applicatif de ladite pluralité de modules logiciels applicatifs (101, 102, 103), à au moins un premier jeu de données de calibration via ledit module de gestion (111) de données de calibration par l’intermédiaire d’une première interface (1100) entre ladite couche applicative haut niveau (10) et ladite au moins une couche de service bas niveau (11), ladite première interface (1100) étant commune à chaque module logiciel applicatif de ladite pluralité de modules logiciels applicatifs (101, 102, 103). Procédé selon la revendication 1, pour lequel ladite première interface (1100) est configurée pour permettre un accès en lecture audit au moins un premier jeu de données de calibration à chaque module logiciel applicatif de ladite pluralité de modules logiciels applicatifs (101, 102, 103) via ledit module de gestion (111) de données de calibration. Procédé selon la revendication 1 ou 2, pour lequel les données de calibration du au moins un premier jeu sont stockées dans ladite mémoire sous une forme de tableau et/ou sous une forme de scalaires. Procédé selon l’une quelconque des revendications 1 à 3, comprenant en outre une étape d’accès en lecture, par un deuxième module logiciel applicatif de ladite pluralité de modules logiciels applicatifs (101, 102, 103), à au moins un deuxième jeu de données de calibration via ledit module de gestion de données de calibration par l’intermédiaire d’au moins une deuxième interface (1101, 1102, 1103, 1104) entre ladite couche applicative haut niveau (10) et ladite au moins une couche de service bas niveau (11), ladite au moins une deuxième interface (1101, 1102, 1103, 1104) étant dédiée audit deuxième module logiciel. Procédé selon l’une des revendications 1 à 4, pour lequel chaque module logiciel applicatif de ladite pluralité de modules logiciels applicatifs (101, 102, 103) est configuré pour mettre en œuvre au moins une fonction d’un système d’aide à la conduite du véhicule, dit système ADAS. Procédé selon la revendication 5, pour lequel ledit au moins un premier jeu de données est identifié par un nom générique ne dépendant pas de ladite au moins une fonction du système ADAS. Procédé selon l’une des revendications 1 à 6, pour lequel un volume dudit au moins un premier jeu de données de calibration est fonction d’un espace disponible dédiée aux données de calibration dans ladite mémoire. Programme d’ordinateur comportant des instructions pour la mise en œuvre du procédé selon l’une quelconque des revendications précédentes, lorsque ces instructions sont exécutées par un processeur. Dispositif (2) de calibration d’un calculateur de véhicule, ledit dispositif (2) comprenant une mémoire (21) associée à au moins un processeur (20) configuré pour la mise en œuvre des étapes du procédé selon l’une quelconque des revendications 1 à 7. Véhicule comprenant le dispositif (2) selon la revendication 9.