Brevet FR3159025A1 — publié le 20250808

La présente invention concerne un calculateur (CL1), dit calculateur principal, et un procédé de contrôle mis en œuvre par un tel calculateur dans un véhicule (2). Le procédé comprend : réception, au moyen d’une première interface de communication (16), depuis un serveur (SV1) distant du véhicule (2), d’une commande de gestion (CMD1) relative à une fonction (F1a), dite fonction cible, dudit véhicule ; identification d’un calculateur secondaire (CL2a), dit calculateur cible, associé à la fonction cible (F1a) ; et transmission, au moyen d’une deuxième interface de communication (18), de la commande de gestion (CMD1) au calculateur cible (CL2a). Figure pour l’abrégé : Figure 1 Procédé et dispositif de contrôle d’une fonction d’un véhicule La présente invention concerne les procédés et dispositifs de contrôle d’une fonction d’un véhicule, et notamment mais pas exclusivement d’un véhicule de type automobile. L’invention vise en particulier le contrôle d’une fonction, gérée par un calculateur embarqué dans un véhicule, en coopération avec un serveur distant du véhicule. Arrière-plan technologique Dans le domaine automobile, l'intégration croissante de la technologie numérique représente une évolution majeure, grâce à l'inclusion de logiciels avancés permettant d’améliorer l'expérience de conduite et la gestion des véhicules. A cette fin, les véhicules contemporains embarquent nombre de calculateurs assurant chacun une ou plusieurs fonctions, telles que par exemple des fonctions relatives à la gestion de l’aide à la conduite, de l’antipatinage, de la répartition électronique du freinage, de la connectivité avec d'autres appareils… A titre d’exemple, un calculateur moteur, aussi appelé « boîtier de servitude moteur » ou « unité de commande moteur », est configuré pour collecter des données d’entrée (de capteurs ou autres), traiter ces données et envoyer des signaux de commande à divers composants (actionneurs) du moteur. Ces calculateurs, aussi appelés UCE (pour « Unité de Commande Electronique », ou ECU pour « Electronic Control Unit » en anglais), jouent un rôle essentiel en rendant les voitures plus sûres, plus efficaces et plus confortables. Pour ce faire, ils embarquent des logiciels configurables pour exécuter les fonctions dont ils ont la charge. La personnalisation de ces fonctions dans un véhicule est possible grâce à la mise à jour et à la configuration des logiciels embarqués dans les calculateurs, permettant ainsi de répondre aux besoins spécifiques de chaque utilisateur. Cependant, cette évolution technologique se confronte à des défis techniques majeurs qu’il convient d’adresser. Ainsi, avec l'augmentation du nombre de calculateurs embarqués dans les véhicules et la complexité grandissante de leurs architectures, la gestion de ces systèmes devient de plus en plus difficile, notamment pour les mises à jour logicielles. Cette complexité se traduit notamment par un coût important en ressources, en particulier en termes de bande passante et de consommation d'énergie. La multiplication des calculateurs à configurer entraînent une augmentation des connexions calculateur-serveur nécessaires pour configurer les différents calculateurs des véhicules selon les besoins et attentes des utilisateurs. En outre, la gestion actuelle des calculateurs et des fonctions qu'ils contrôlent présente des limites en termes de flexibilité et d'efficacité. Les cycles de vie ou de fonctionnement des calculateurs ne sont pas toujours en phase avec les besoins évolutifs des clients. Ainsi, un calculateur peut se trouver à un instant donné dans un état ne permettant pas d’activer une fonction associée, alors même qu’une telle activation est souhaitée, par un utilisateur par exemple. De même, le diagnostic des configurations des calculateurs et des fonctions associées dans les véhicules reste complexe. Dans ce contexte où les véhicules deviennent de plus en plus gérés par logiciel, il est crucial d'améliorer le contrôle et la gestion des calculateurs embarqués. Résumé de la présente invention L’un des objets de la présente invention est de résoudre au moins l’un des problèmes ou déficiences de l’arrière-plan technologique décrit précédemment. L’un des objets de la présente invention est d’améliorer le contrôle d’au moins un calculateur embarqué dans un véhicule. En particulier, un objet vise à contrôler un calculateur embarqué dans un véhicule, en coopération avec un serveur distant du véhicule, afin de gérer une fonction dudit calculateur de façon efficace, notamment en termes de coût en ressources, telles que la bande passante utilisée ou l’énergie consommée. L’un des objets de la présente invention est de permettre de configurer un calculateur embarqué dans un véhicule, ou une fonction associée, de façon flexible et efficace afin notamment de répondre à l’évolution des besoins des utilisateurs. Selon un premier aspect, la présente invention concerne un procédé de contrôle mis en œuvre par un calculateur principal dans un véhicule embarquant ledit calculateur principal et au moins un autre calculateur secondaire, ledit calculateur principal comprenant une première interface de communication et une deuxième interface de communication, le ledit procédé comprenant : - réception, au moyen de la première interface de communication, depuis un serveur distant du véhicule, d’une commande de gestion relative à une fonction, dite fonction cible, dudit véhicule ; - identification d’un calculateur secondaire, dit calculateur cible, associé à ladite fonction cible ; et - transmission, au moyen de la deuxième interface de communication, de la commande de gestion au calculateur cible. Le procédé selon le premier aspect de l’invention peut comporter d’autres caractéristiques qui peuvent être prises séparément ou en combinaison, notamment parmi les modes de réalisation qui suivent. Selon un mode de réalisation particulier, le procédé comprend, préalablement à la réception de la commande de gestion, enregistrement de données d’attribution associant des fonctions du véhicule à des calculateurs secondaires respectifs dudit véhicule ; dans lequel l’identification du calculateur cible est réalisée en déterminant le calculateur secondaire associé à la fonction cible selon les données d’attribution. Selon un mode de réalisation particulier, le procédé comprend une phase d’attente d’une commande provenant de l’extérieur du véhicule, le calculateur principal étant, pendant ladite phase d’attente, dans un état actif permettant de recevoir une commande provenant de l’extérieur du véhicule via la première interface de communication, indépendamment d’un état courant dans lequel se trouve chaque calculateur secondaire pendant ladite phase d’attente ; la commande de gestion étant reçue au cours de ladite phase d’attente. Selon un mode de réalisation particulier, le procédé comprend, après l’identification du calculateur cible : - vérification de si le calculateur cible est dans un état actif permettant une configuration de la fonction cible ; - mise en attente de la commande de gestion tant que le calculateur cible est dans un état inactif ; et - sur détection que le calculateur cible est à l’état actif, déclenchement de la transmission, au moyen de la deuxième interface de communication, de la commande de gestion au calculateur cible. Selon un mode de réalisation particulier, la commande de gestion transmise au calculateur cible cause au moins l’une parmi les opérations de configuration suivantes : - paramétrage de la fonction cible ; - activation de ladite fonction cible ; et - désactivation de ladite fonction cible. Selon un mode de réalisation particulier, le procédé comprend, préalablement à la réception de la commande de gestion : - réception, au moyen de la deuxième interface de communication depuis le calculateur cible, d’une valeur courante d’un paramètre de la fonction cible ; - enregistrement de la valeur courante en association avec la fonction cible dans des données de configuration ; et - en réponse à une commande de lecture, relative à la fonction cible, provenant du serveur distant, envoi au serveur distant de la valeur courante associée à ladite fonction cible selon les données de configuration ; la commande de gestion étant reçue en réponse audit envoi de la valeur courante. Selon un deuxième aspect, la présente invention concerne un calculateur, dit calculateur principal (ou encore dispositif de contrôle), configuré pour mettre en œuvre le procédé selon le premier aspect de l’invention. A cet effet, le calculateur principal peut comprendre une première interface de communication configurée pour communiquer avec un serveur distant d’un véhicule dans lequel est embarqué le calculateur principal, et une deuxième interface de communication configurée pour communiquer avec au moins un calculateur secondaire embarqué dans le véhicule. Selon un exemple, le calculateur principal comprend 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. A noter que les différents modes de réalisation mentionnés ci-avant en relation avec le procédé selon le premier aspect de l’invention ainsi que les avantages associés s’appliquent de façon analogue au calculateur principal selon le deuxième aspect de l’invention. Selon un troisième aspect, la présente invention concerne un véhicule, par exemple de type automobile ou de type véhicule à moteur terrestre, comprenant un calculateur principal selon le deuxième aspect de la présente invention. Selon un mode de réalisation particulier, le calculateur principal et ledit au moins un calculateur secondaire font partie d’un réseau de communication embarqué du véhicule, dans lequel le calculateur principal est l’unique calculateur, dans le réseau de communication, comprenant une dite première interface de communication permettant de communiquer avec le serveur distant. Ledit calculateur principal peut alors être configuré pour agir en tant qu’agent centralisé à l’interface entre le réseau de communication embarqué et le serveur distant. 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é de contrôle selon le premier aspect de la présente invention, ceci notamment lorsque le programme d’ordinateur est exécuté par au moins un processeur. Autrement dit, les différentes étapes du procédé de contrôle sont déterminées par des instructions de programmes d’ordinateurs. Ce programme d’ordinateur est configuré pour être mis en œuvre dans un dispositif de contrôle du deuxième aspect de l’invention, ou plus généralement dans un ordinateur. 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 (ou support d’informations), lisible par le dispositif de contrôle selon le deuxième aspect ou plus généralement par un ordinateur (ou un processeur), sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé de contrôle 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. La présente invention permet avantageusement de contrôler un calculateur embarqué dans un véhicule, en coopération avec un serveur distant du véhicule, afin de gérer au moins une fonction dudit calculateur de façon efficace, notamment en termes de coût en ressources, telles que la bande passante utilisée ou l’énergie consommée. De cette manière, on peut avantageusement configurer des calculateurs embarqués dans un véhicule, ou des fonctions associées, de façon flexible et efficace afin notamment de répondre à l’évolution des besoins des utilisateurs. On peut ainsi rationnaliser le fonctionnement des calculateurs embarqués dans un véhicule, faciliter la configuration des fonctions associées, et donc améliorer le confort et l’expérience utilisateur, tout en limitant les coûts associés en ressources. En particulier, on peut personnaliser efficacement la configuration de fonctions embarquées dans un véhicule selon l’évolution des besoins d’un utilisateur au cours du temps. Grâce à l’invention, on peut utiliser un tel calculateur principal en tant qu’agent centralisé faisant l’interface entre d’une part l’extérieur du véhicule, par exemple un serveur, et d’autre part des calculateurs (secondaires) embarqués dans le véhicule, ce qui permet notamment de réduire le nombre et la complexité des connexions calculateur-serveur et limiter la bande passage requise. En outre, les cycles de vie ou de fonctionnement des calculateurs embarqués dans un véhicule ne sont pas toujours en phase avec les besoins évolutifs des clients. L’invention offre également un gain en termes d’efficacité et de flexibilité dans la mesure où l’on peut configurer une fonction d’un véhicule à des stades variés du cycle de vie, ou de fonctionnement, d’un calculateur secondaire associé. Il est en effet possible de traiter une demande de configuration d’une fonction quel que soit l’état du calculateur secondaire associé à un instant courant, y compris dans le cas où ce calculateur secondaire est inactif, c’est-à-dire pas en mesure de traiter cette demande de configuration. On peut ainsi augmenter la disponibilité des calculateurs d’un véhicule pour mettre en œuvre une configuration d’une fonction associée et on peut accélérer le processus de configuration d’une telle fonction. L’invention peut également permettre de faciliter la réalisation de diagnostics visant notamment à vérifier, et si besoin adapter, la configuration d’un calculateur d’un véhicule, ou d’une fonction associée. 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 à 4 annexées, sur lesquelles : FIG. 1 illustre schématiquement un environnement comprenant un véhicule embarquant un calculateur principal et au moins un calculateur secondaire, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; FIG. 2 illustre schématiquement un exemple de mise en œuvre de l’environnement de la FIG. 1 , selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; FIG. 3 illustre schématiquement un calculateur principal configuré pour contrôler au moins un calculateur secondaire dans le véhicule illustré en FIG. 1 , selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; et FIG. 4 illustre un diagramme de différentes étapes d’un procédé de contrôle mis en œuvre par le calculateur principal illustré en FIG. 1 , selon au moins 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 contrôle selon des modes particuliers de réalisation vont maintenant être décrits dans ce qui va suivre en référence conjointement aux figures 1-4. Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité. Les termes « premier(s) » (ou première(s)), « deuxième(s) », etc.) sont utilisés dans ce document par convention arbitraire pour permettre d’identifier et de distinguer différents éléments (tels que des opérations, des moyens, etc.) mis en œuvre dans les modes de réalisation décrits ci-après. Comme précédemment indiqué, la gestion de la configuration de calculateurs embarqués dans un véhicule présente certaines contraintes et défis techniques qu’il convient d’adresser. L’invention vise notamment à résoudre ces problèmes et limitations. A cet effet, l’invention prévoit notamment un procédé de contrôle d’au moins un calculateur dans un véhicule, tel qu’un véhicule de type automobile ou autre, ou plus généralement un véhicule de type véhicule terrestre motorisé. L’invention se propose d’utiliser un calculateur embarqué du véhicule, dit calculateur principal, qui assure l’interface entre l’extérieur du véhicule, à savoir un serveur, et au moins un autre calculateur, dit calculateur secondaire, également embarqué dans le véhicule. A partir d’une commande de gestion, relative à une fonction du véhicule, qui est reçue depuis un serveur distant, le calculateur principal identifie un calculateur secondaire chargé d’exécuter cette fonction dans le véhicule et transmet la commande audit calculateur secondaire, causant ainsi par exemple une configuration du calculateur secondaire en réponse à la commande de gestion provenant du serveur distant. A cette fin, le calculateur principal selon l’invention peut comprendre une première interface de communication permettant de communiquer avec l’extérieur du véhicule, en particulier avec le serveur distant, et une deuxième interface de communication permettant de communiquer au sein du véhicule, en particulier avec un ou des calculateurs secondaires embarqués. Selon un exemple particulier et non limitatif de réalisation de la présente invention, le procédé de contrôle comprend : - réception, au moyen de la première interface de communication, depuis un serveur distant du véhicule, d’une commande de gestion relative à une fonction, dite fonction cible, dudit véhicule ; - identification d’un calculateur secondaire, dit calculateur cible, associé à ladite fonction cible ; et - transmission, au moyen de la deuxième interface de communication, de la commande de gestion au calculateur cible. On peut ainsi avantageusement améliorer ou rationnaliser le fonctionnement de calculateurs embarqués dans un véhicule, afin notamment de faciliter leur configuration et ainsi permettre une personnalisation efficaces de fonctions associées dans le véhicule, et ce en minimisant les ressources nécessaires en termes notamment de connectivité, bande passage et consommation en énergie. D’autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant. La FIG. 1 illustre schématiquement un environnement comprenant un véhicule 2 et un serveur SV1 situé à distance du véhicule 2, selon des exemples particuliers de réalisation de l’invention. Le véhicule 2 embarquent des calculateurs CL comprenant un calculateur CL1, configuré en tant que calculateur principal, et au moins un autre calculateur CL2 configuré en tant que calculateur secondaire, comme décrit plus en détail ci-après. Le type et les caractéristiques du véhicule 2 peuvent varier selon le cas. Le véhicule 2 peut par exemple être de type automobile ou équivalent. Plus généralement, le véhicule 2 peut être une automobile, un car, un bus, un camion, un véhicule utilitaire ou une motocyclette, ou un véhicule de type véhicule terrestre motorisé. On suppose par la suite à titre d’exemple que le véhicule 2 embarque un calculateur principal CL1 et une pluralité de calculateurs secondaires CL2. Le calculateur principal CL1 est apte à communiquer avec les calculateurs secondaires CL2 au sein d’un réseau de communication embarqué. L’architecture du système embarqué SY1, notamment en ce qui concerne les caractéristiques du réseau de communication embarqué et le nombre et l’agencement des calculateurs secondaires CL2, peuvent varier selon le cas. La FIG. 1 illustre à titre d’exemple un cas où le système embarqué SY1 comprend trois calculateurs secondaires CL2, notés CL2a, CL2b et CL2c, chacun d’eux étant aptes à opérer sous le contrôle du (ou en coopération avec le) calculateur principal CL1. La FIG. 2 représente à titre purement illustratif un exemple particulier de mise en œuvre du système embarqué SY1 comprenant le calculateur principal CL1 et une pluralité de calculateurs secondaires CL2. Dans cet exemple, les calculateurs CL sont agencés selon une arborescence dans le réseau de communication du système embarqué SY1. Ainsi, les calculateurs CL forment des nœuds connectés entre eux selon des relations parent/enfant dans l’arborescence. Chaque calculateur secondaire CL2 est agencé en tant que nœud fils, direct ou indirect, du calculateur principal CL1 qui constitue la racine du réseau. Chaque calculateur CL peut ainsi envoyer ou propager des données à un nœud qui lui est adjacent dans l’arborescence. A noter toutefois que l’architecture du système embarqué SY1 peut varier selon le cas. A titre d’exemple, le réseau de communication embarqué peut être l’un quelconque des types suivants : CAN (pour « Controller Area Network »), LIN (pour « Local Interconnect Network », Flexray (réseau de communication véhiculaire à haut débit) et Ethernet. D’autres types de réseau sont toutefois possibles. Les calculateurs CL, appelés aussi unités de commande électronique ou ECU (pour « Electronic Control Unit »), sont des dispositifs électroniques embarqués, qui gèrent ou contrôlent divers systèmes et fonctionnalités du véhicule 2. En particulier, chaque calculateur secondaire CL2 est configuré pour exécuter au moins une fonction F1 du véhicule 2, la nature et le nombre de ces fonctions F1 pouvant varier pour chaque calculateur considéré. Une fonction F1 au sens de la présente divulgation, telle que la fonction F1a décrite ci-après, peut être un service, une application ou un module logiciel exécutable par un calculateur secondaire CL2 associé. A titre d’exemple, la fonction F1 d’un calculateur secondaire CL2 peut porter sur la gestion de l’aide à la conduite, l’antipatinage, la répartition électronique du freinage, la commande d’actionneurs pour assurer le fonctionnement optimal d’un moteur à combustion (calculateur moteur), ou encore sur une fonction d’une plateforme d’infodivertissement embarquée. Ces unités permettent d’assurer un contrôle efficace et fiable des diverses fonctions F1 du véhicule 2. Le calculateur principal CL1 est apte à coopérer avec chaque calculateur secondaire CL2 pour contrôler les fonctions associées F1 dans le véhicule 2. Le calculateur principal CL1 est par exemple une TCU (pour « Unité de Contrôle de Transmission » ou « Transmission Control Unit »). Il s'agit d'un calculateur conçu pour gérer les communications d'un véhicule avec l’extérieur. Chaque calculateur secondaire CL2 opère selon une configuration donnée qu’il peut être nécessaire de modifier ou mettre à jour pour diverses raisons, par exemple pour personnaliser, paramétrer ou améliorer certaines fonctions F1 du véhicule 2. Le calculateur principal CL1 est configuré pour faire l’interface entre chaque calculateur secondaire CL2 d’une part, et le serveur distant SV1 d’autre part, en vue notamment de permettre une configuration si nécessaire des fonctions F1 associées aux calculateurs secondaires CL2. Pour ce faire, le calculateur principal CL1 peut notamment recevoir et traiter des commandes ou messages provenant du serveur SV1, et transmettre si besoin ces commandes ou messages à un ou des calculateurs secondaires CL2, par exemple en vue de causer une configuration d’au moins une fonction F1 du véhicule 2. Ces commandes ou messages peuvent par exemple spécifier la valeur de paramètres PR1 de fonction F1, comme décrit par la suite dans des exemples particuliers. Par souci de simplification de l’exposé de l’invention, la description qui suit se concentre sur la configuration et le fonctionnement du calculateur principal CL1 et d’un calculateur secondaire noté CL2a (figures 1-2), en vue de configurer une fonction F1a associée audit calculateur secondaire CL2a. Le principe de l’invention est toutefois applicable de façon analogue au contrôle d’une pluralité de calculateurs secondaires CL2. De même, le principe de l’invention peut être appliquer au contrôler d’une pluralité de fonctions F1 exécutées par un ou des calculateurs secondaires CL2. Comme illustré en FIG. 1 selon un exemple particulier, le calculateur principal CL1 peut comprendre au moins un processeur 12, au moins une mémoire non volatile 14, une première interface de communication 16 et une deuxième interface de communication 18. Un exemple de mise en œuvre du calculateur principal CL1 est décrit ultérieurement en référence à la FIG. 3 . La première interface de communication 16 permet au calculateur principal CL1 de communiquer (ou coopérer) avec l’extérieur du véhicule 2, et en particulier avec le serveur distant SV1 dans cet exemple. Il s’agit dans cet exemple d’une interface de type V2C pour « Vehicule-to-Cloud » permettant un échange de données avec un système situé hors du véhicule 2. La technologie V2C permet par exemple des mises à jour de type OTA (pour « Over-The-Air »). Cette première interface 16 peut par exemple comprendre un client de gestion exécuté par le calculateur principal CL1 pour pouvoir communiquer avec l’extérieur du système embarqué SY1. Selon un exemple, le calculateur principal CL1 est configuré pour agir en tant qu’agent centralisé, à l’interface entre au moins un calculateur secondaire CL2 (ou une pluralité d’entre eux) et le serveur distant SV1. A titre d’exemple, le calculateur principal CL1 peut être l’unique calculateur CL, dans le réseau de communication du système embarqué SY1, comprenant une dite première interface de communication 16 permettant de communiquer avec le serveur distant SV1. Le calculateur principal CL1 est ainsi configuré pour agir en tant qu’agent centralisé à l’interface entre le réseau de communication embarqué et le serveur distant SV1, ce qui permet de rationnaliser le fonctionnement des calculateurs et limiter les connexions calculateur-serveur entre les calculateurs embarqués CL et l’extérieur du véhicule 2. La deuxième interface de communication 18 permet au calculateur principal CL1 de communiquer (ou coopérer), au sein du réseau de communication du système embarqué SY1, avec les calculateurs secondaires CL2, dont le calculateur secondaire CL2a. La deuxième interface 18 est par exemple compatible avec une architecture de type AUTOSAR (pour « AUTomotive Open System Architecture »). Cette deuxième interface 18 peut par exemple être de type CAN, LIN, Flexray ou Ethernet. Le calculateur principal CL1 est configuré pour mettre en œuvre un processus (ou procédé) de contrôle comme décrit ci-après. A cet effet, le calculateur principal CL1 peut comprendre un programme d’ordinateur PG1 stocké dans la mémoire non volatile 14, ce programme d’ordinateur PG1 comprenant des instructions pour la mise en œuvre du procédé (ou processus) de contrôle comme décrit ci-après. Le processeur 12 est ainsi configuré pour exécuter notamment les instructions définies par le programme d’ordinateur PG1. La mémoire 14 du calculateur principal CL1 est apte à stocker diverses données, telles que par exemple des données d’attribution DT1 et/ou des données de configuration DT2. Les données d’attribution DT1 peuvent définir des fonctions F1 du véhicule 2 en association avec des calculateurs secondaires CL2 respectifs du véhicule. Les données de configuration DT2 peuvent définir au moins un paramètre (ou paramètre de configuration) PR1 en association avec une fonction F1 d’un calculateur secondaire CL2. La nature et l’usage de ces données DT1 et DT2 seront décrites plus en détail ultérieurement en référence au processus de contrôle de l’invention selon des exemples particuliers. Comme illustré en FIG. 1 , le calculateur secondaire CL2a comprend au moins un processeur 30, une interface de communication 32 et un programme d’ordinateur PG2 exécutable par le processeur 30 pour permettre au calculateur secondaire CL2a d’opérer en coopération avec le calculateur principal CL1. L’interface de communication 32 permet au calculateur secondaire CL2a de communiquer (ou coopérer) avec le calculateur principal CL1 via l’interface de communication 18 de ce dernier. Comme indiqué ci-avant, le calculateur principal CL1 est configuré pour mettre en œuvre un processus de contrôle. Ce processus est à présent décrit conjointement aux figures 1 et 2 selon des modes de réalisation particuliers. Plus précisément, le calculateur principal CL1 tel que précédemment décrit opère en coopération avec le serveur distant SV1 et le calculateur secondaire CL2a, en vue par exemple de configurer une fonction F1a associée au calculateur secondaire CL2a. Pour ce faire, le processeur 12 du calculateur principal CL1 exécute les instructions du programme d’ordinateur PG1. On suppose à titre d’exemple qu’un paramétrage (ou mise à jour) de la fonction F1a associée au calculateur secondaire CL2a doit être réalisé. Aussi, le serveur SV1 envoie au calculateur principal CL1 une commande de gestion CMD1 relative à la fonction F1a du véhicule 2. Dans une première opération, le calculateur principal CL1 reçoit ainsi, au moyen de sa première interface de communication 16, depuis le serveur distant SV1, la commande de gestion CMD1 relative à la fonction F1a, dite fonction cible, du véhicule 2 ( FIG. 1 ). Dans une deuxième opération, le calculateur principal CL1 identifie un calculateur secondaire CL2, à savoir dans cet exemple le calculateur CL2a, en tant que calculateur cible associé à la fonction cible F1a. Autrement dit, le calculateur cible CL2a est détecté comme étant celui correspondant à la fonction cible F1a telle que définie dans la commande de gestion CMD1. L’identification du calculateur cible CL2a peut être réalisée de diverses manières selon le cas. Selon un exemple particulier, préalablement à la première opération de réception de la commande de gestion CMD1, le calculateur principal CL1 enregistre des données d’attribution DT1 associant des fonctions F1 du véhicule 2 à des calculateurs secondaires CL2 respectifs dudit véhicule 2 (ou associe au moins la fonction F1a au calculateur secondaire CL2a). Ces données DT1 sont par exemple stockées dans la mémoire 14 ou dans une base de données accessibles par le calculateur principal CL1. L’identification du calculateur cible CL2a est ensuite réalisée au cours de la deuxième opération en déterminant le calculateur secondaire CL2 associé à la fonction cible F1a selon les données d’attribution DT1. Pour ce faire, le calculateur principal CL1 peut accéder aux données d’attribution DT1 et en déduire, à partir de la fonction cible F1a spécifiée dans la commande de gestion CMD1, le calculateur secondaire CL2 correspondant. L’enregistrement préalable des données d’attribution DT1 permet au calculateur principal CL1 d’attribuer, à chaque fonction embarquée F1, un calculateur secondaire CL2 respectif, et ainsi identifier un calculateur secondaire CL2 pour chaque commande de gestion CMD1 reçue depuis l’extérieur du véhicule 2. Selon un exemple particulier, la commande de gestion CMD1 reçue comprend un identifiant du calculateur cible CL2a gérant la fonction cible F1a. Ainsi, au cours de la deuxième opération, le calculateur cible CL2a peut être identifié à partir de l’identifiant de calculateur contenu dans la commande de gestion CMD1 conformément aux données d’attribution DT1. Dans une troisième opération, le calculateur principal CL1 transmet (ou distribue), au moyen de sa deuxième interface de communication 18, la commande de gestion CMD1 au calculateur cible CL2a identifié au cours de la deuxième opération. Le calculateur principal CL1 peut ainsi aguiller chaque commande de gestion CMD1 reçue vers le calculateur secondaire CL2 approprié. Le processus de contrôle permet avantageusement de contrôler le calculateur secondaire CL2a dans le véhicule 2, en coopération avec le serveur SV1, afin de gérer la fonction F1a dudit calculateur secondaire CL2a de façon efficace, notamment en termes de coût en ressources, telles que la bande passante utilisée ou l’énergie consommée. De cette manière, on peut avantageusement configurer les calculateurs CL2 embarqués dans le véhicule 2, ou des fonctions F1 associées, de façon flexible et efficace afin notamment de répondre à l’évolution des besoins d’un utilisateur. On peut ainsi rationnaliser le fonctionnement des calculateurs CL embarqués dans le véhicule 2, faciliter la configuration des fonctions F1 associées, et donc améliorer le confort et l’expérience utilisateur, tout en limitant les coûts associés en ressources. En particulier, on peut personnaliser efficacement la configuration de fonctions F1 embarquées dans le véhicule 2 selon l’évolution des besoins d’un utilisateur au cours du temps. Grâce au processus de contrôle, on peut utiliser le calculateur principal CL1 en tant qu’agent centralisé faisant l’interface entre d’une part l’extérieur du véhicule 2, à savoir avec le serveur SV1, et d’autre part les calculateurs secondaires CL2 embarqués dans le véhicule 2, ce qui permet notamment de réduire le nombre et la complexité des connexions calculateur-serveur et limiter la bande passage requise. Les caractéristiques et l’objet de la commande de gestion CMD1 peuvent varier selon le cas. La commande de gestion CMD1 ainsi transmise au calculateur cible CL2a cause par exemple au moins l’une parmi les opérations de configuration suivantes : - paramétrage (ou mise à jour) de la fonction cible F1a ; - activation de la fonction cible F1a ; et - désactivation de la fonction cible F1. En réponse à la commande de gestion CMD1 reçue, le calculateur cible CL2a peut ainsi réaliser une opération de configuration de la fonction cible F1a, par exemple l’une des opération précitées. Ainsi, le processus permet de configurer efficacement une fonction F1a gérée par un calculateur embarqué CL1a du véhicule 2, de façon par exemple à mettre à jour au moins un paramètre PR1a de la fonction cible F1a, ou à activer la fonction F1, ou encore à désactiver la fonction. Comme illustré en FIG. 1 à titre d’exemple, la commande de gestion CMD1 cause par exemple l’attribution d’une nouvelle valeur V2 à un paramètre PR1a de la fonction cible F1a. Ainsi, en réponse à cette commande de gestion CMD1, le calculateur cible CL2a configure le paramètre PR1a selon cette nouvelle valeur V2 spécifiée par la commande CMD1. Cela permet par exemple de modifier la valeur d’un paramètre PR1a déjà existant de la fonction cible F1a, en encore d’ajouter un nouveau paramètre PR1a à cette fonction cible. Selon un exemple, l’exécution de la command de gestion CMD1 entraîne le remplacement d’une valeur courante V1 d’un paramètre PR1a de la fonction cible F1a par la nouvelle valeur V2. Selon un exemple particulier, le calculateur principal CL1 peut effectuer une phase d’attente d’une commande provenant de l’extérieur du véhicule 2. Pendant cette phase d’attente, le calculateur principal CL1 se trouve dans (ou est configuré selon) un état actif permettant de recevoir une commande provenant de l’extérieur du véhicule 2 via la première interface de communication 16, et ce indépendamment d’un état courant (actif ou inactif) dans lequel se trouve chaque calculateur secondaire CL2 pendant ladite phase d’attente. Le calculateur principal CL1 peut ainsi recevoir la commande de gestion CMD1 au cours de cette phase d’attente. Cette commande de gestion CMD1 peut ensuite être transmise au calculateur cible CL2 via le réseau de communication embarqué, mais uniquement lorsque le calculateur cible CL2 est à l’état actif. Autrement dit, le calculateur principal CL1 reste à l’état actif pendant cette phase d’attente pour communiquer avec le serveur SV1, indépendamment de l’état actif ou inactif du calculateur cible CL2a pendant cette phase d’attente. De cette manière, le calculateur principal CL1 est capable de recevoir la commande de gestion CMD1 envoyé par le serveur SV1, et ce même si le calculateur cible CL2a est inactif, c’est-à-dire pas en mesure de recevoir ou traiter cette commande de gestion CMD1. Ainsi, il est possible de maintenir la calculateur principal CL1 à l’état actif pendant la phase d’attente pour recevoir la commande de gestion CMD1 tandis que le calculateur cible CL2a est inactif. Les cycles de vie ou de fonctionnement des calculateurs CL embarqués dans le véhicule 2 ne sont pas nécessairement en phase avec les besoins évolutifs d’un utilisateur au cours du temps. A titre d’exemple, le calculateur principal CL1 peut se trouver à un instant donné à l’état actif ce qui lui permet de recevoir et traiter une commande de gestion CMD1 reçue, alors que le calculateur cible CL2a se trouve à l’état inactif, ce qui empêche ce dernier de recevoir et traiter la commande de gestion CMD1 en question. Selon un exemple particulier, une fois que le calculateur cible CL2a a été identifié au cours de la deuxième opération, le calculateur principal CL1 vérifie si le calculateur cible CL2a est dans un état actif permettant une configuration de la fonction cible F1a. Le calculateur principal CL1 met en attente la commande de gestion CMD1 tant que le calculateur cible CL2a est dans un état inactif. Autrement dit, la transmission de la commande de gestion CMD1 est différée ou bloquée si (ou tant que) le calculateur cible CL2a est à l’état inactif. Sur détection que le calculateur cible CL2a est à l’état actif, le calculateur principal CL1 déclenche la transmission, au moyen de la deuxième interface de communication 18, de la commande de gestion CMD1 au calculateur cible CL2a. Le processus offre ainsi un gain en termes d’efficacité et de flexibilité dans la mesure où l’on peut initier la configuration d’une fonction F1a du véhicule 2 à des stades variés du cycle de vie, ou de fonctionnement, du calculateur secondaire CL2a associé. Il est en effet possible de traiter une commande de gestion CMD1 d’une fonction F1a quel que soit l’état du calculateur secondaire CL2a associé à un instant courant, y compris dans le cas où ce calculateur secondaire est inactif, c’est-à-dire pas en mesure de traiter cette commande de gestion. On peut ainsi augmenter la disponibilité des calculateurs CL d’un véhicule pour mettre en œuvre une configuration d’une fonction F1 associée et on peut permettre ou accélérer le processus de configuration d’une telle fonction. En particulier, on peut synchroniser efficacement un état de configuration des calculateurs secondaires CL2 avec les besoins d’un utilisateur tels que spécifiées par des commandes envoyées par un serveur SV1. Il n’est pas nécessaire que la totalité du système embarqué SY1 du véhicule 2 soit activé à réception de la commande de gestion CMD1 pour permettre la configuration (activation, etc.) de la fonction cible F1a gérée par le calculateur cible CL2a. Seul le calculateur principal CL1 doit être à l’état actif lorsque la commande de gestion CMD1 est reçue depuis le serveur SV1, afin que cette commande soit traitée et transmise en temps utile au calculateur cible CL2a. L’invention peut également permettre de faciliter la réalisation de diagnostics visant notamment à vérifier, et si besoin adapter, la configuration d’un calculateur d’un véhicule, ou d’une fonction associée. Selon un exemple particulier, préalablement à la première opération de réception de la commande de gestion CMD1, le calculateur principal CL1 reçoit, au moyen de sa deuxième interface de communication 16, depuis le calculateur cible CL2a, une valeur courante V1 ( FIG. 1 ) de la fonction cible F1a. Il peut s’agir par exemple d’un paramètre PR1a déjà existant de la fonction cible F1a ou d’un nouveau paramètre PR1a qui est appliqué à la fonction cible F1a. Le calculateur principal CL1 enregistre alors la valeur courante V1 en association avec la fonction cible F1a dans les données de configuration DT2. Cette enregistrement permet au calculateur principal CL1 de suivre au fil du temps l’évolution de l’état de configuration de la fonction F1a associée au calculateur secondaire CL2a. En particulier, en réponse à une commande de lecture CMD2 relative à la fonction cible F1a reçue depuis le serveur SV1, le calculateur principal CL1 peut alors envoyer au serveur SV1 la valeur courante V1 du paramètre PR1a associé à ladite fonction cible F1a comme spécifié dans les données de configuration DT2. La commande de gestion CMD1 peut alors être reçue (première opération) en réponse à l’envoi dudit au moins un paramètre courant PR1 au calculateur principal CL1. Cette commande gestion CMD1 peut par exemple commander l’écriture du paramètre PR1a de la fonction cible F1a pour remplacer sa valeur courante V1 pour une nouvelle valeur V2. Ainsi, préalablement à la réception de la commande de gestion CMD1 provenant du serveur SV1 (première opération), le calculateur principal CL1 peut recevoir et stocker la valeur courante V1 d’un paramètre PR1a de la fonction cible F1a, en vue de transmettre cette valeur au serveur SV1 sur demande de ce dernier. Le serveur SV1 peut ultérieurement déclencher l’écriture ou modification de la valeur du paramètre PR1a, en envoyant au calculateur principal CL1 la commande de gestion CMD1 relative à la fonction cible F1a, causant l’exécution des opérations du processus de contrôle, par exemple pour remplacer la valeur courante V1 du paramètre PR1a par la nouvelle valeur V2. La FIG. 3 illustre schématiquement la calculateur CL1 configuré en tant que calculateur principal pour contrôler le véhicule 2 comme précédemment décrit en référence aux figures 1-2, selon un exemple de réalisation particulier et non limitatif de la présente invention. Le calculateur principal CL1 est par exemple configuré pour la mise en œuvre des opérations du processus de contrôle tel que précédemment décrit en regard des figures 1-2 et/ou des étapes du procédé décrit ci-après en regard de la FIG. 4 . Plus généralement, le calculateur principal CL1 tel que précédemment décrit peut être, sans y être limités, un calculateur électronique ou tous autres équipements aptes à réaliser le processus (ou procédé) de contrôle. Les éléments du calculateur principal CL1, 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 calculateur principal CL1 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. Comme représenté en FIG. 4 , le calculateur principal CL1 peut comprendre un (ou plusieurs) processeur(s) 12 configurés pour exécuter des instructions pour la réalisation des étapes du procédé (ou du processus) de contrôle et/ou pour l’exécution des instructions du ou des logiciels embarqués dans le calculateur principal CL1. Le processeur 11 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 calculateur principal CL1 comprend en outre au moins une mémoire 41 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 11 est par exemple stocké sur la mémoire 41. La mémoire 41 (correspondant par exemple à la mémoire 14 en FIG. 1 ) peut constituer un support d’informations selon un mode de réalisation particulier en ce qu’elle comprend un programme d’ordinateur (par exemple PG1 en FIG. 1 ) comportant des instructions pour la réalisation des étapes du procédé (ou du processus) de contrôle de l’invention. Selon différents exemples de réalisation particuliers et non limitatifs, le calculateur principal CL1 est couplé en communication avec d’autres dispositifs ou systèmes similaires et/ou avec des dispositifs de communication, par exemple à des calculateurs secondaires CL2 comme déjà décrit, 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 calculateur principal CL1 comprend un bloc 42 d’éléments d’interface agissant en tant que première interface de communication pour communiquer avec des dispositifs externes, par exemple un serveur distant ou le « cloud », tel que le serveur SV1 représenté en FIG. 1 . Les éléments d’interface du bloc 42 comprennent une ou plusieurs des interfaces suivantes : - interface radiofréquence RF, par exemple de type Wi-Fi® (selon IEEE 802.11), par exemple dans les bandes de fréquence à 2,4 ou 5 GHz, ou de type Bluetooth® (selon IEEE 802.15.1), dans la bande de fréquence à 2,4 GHz, ou de type Sigfox utilisant une technologie radio UBN (de l’anglais Ultra Narrow Band, en français bande ultra étroite), ou LoRa dans la bande de fréquence 868 MHz, LTE (de l’anglais « Long-Term Evolution » ou en français « Evolution à long terme »), LTE-Advanced (ou en français LTE-avancé) ; - interface USB (de l’anglais « Universal Serial Bus » ou « Bus Universel en Série » en français) ; - interface HDMI (de l’anglais « High Definition Multimedia Interface », ou « Interface Multimedia Haute Definition » en français). Selon un autre exemple de réalisation particulier et non limitatif, calculateur principal CL1 comprend une interface de communication 43, agissant en tant que deuxième interface de communication, pour permettre l’établissement d’une communication avec d’autres dispositifs (tels que des calculateurs secondaires CL2) via un canal de communication 45. La deuxième interface de communication 43 correspond par exemple à un transmetteur configuré pour transmettre et recevoir des informations et/ou des données via le canal de communication 45. La deuxième interface de communication 43 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), Ethernet (standardisé par la norme ISO/IEC 802-3) ou LIN (de l’anglais « Local Interconnect Network », ou en français « Réseau interconnecté local »). Le calculateur principal CL1 coopère par exemple le serveur SV1 au moyen du bloc 42 d’éléments d’interface et avec le calculateur cible CL2a au moyen de l’interface de communication 43 de sorte à réaliser le processus (ou procédé) de contrôle de l’invention. La FIG. 4 illustre un diagramme des différentes étapes d’un procédé de contrôle d’une fonction F1 dans un véhicule, par exemple du véhicule 2 comme précédemment décrit en référence aux figures 1-2. Le procédé est par exemple mis en œuvre par le calculateur principal CL1 précédemment décrit, ce calculateur étant embarqué dans ledit véhicule 2 pour contrôler en particulier une fonction cible F1a associée à un autre calculateur secondaire CL2a, également embarqué dans le véhicule 2. Dans une première étape S1, est reçue, au moyen de la première interface de communication 16, depuis un serveur SV1 distant du véhicule 2, une commande de gestion CMD1 relative à une fonction F1a, dite fonction cible, dudit véhicule Dans une deuxième étape S2, un calculateur secondaire, dit calculateur cible, associé à ladite fonction cible F1a est identifié. Dans une troisième étape S3, la commande de gestion CMD1 est transmise, au calculateur cible CL2a, au moyen de la deuxième interface de communication 18. Selon des variantes de réalisation, les variantes et exemples des opérations décrits ci-avant en relation avec les figures 1-3 s’appliquent aux étapes du procédé de contrôle de la FIG. 4 . Comme le comprend l’homme du métier, tous les modes de réalisation et variantes décrits ci-avant dont certains ont été simplifiés à dessein pour faciliter les explications, ne constituent que des exemples non limitatifs de mise en œuvre de la présente divulgation. En particulier, l’homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant, afin de répondre à un besoin particulier. La présente invention ne se limite donc pas aux exemples de réalisation décrits ci-avant mais s’étend notamment à un procédé de contrôle 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 calculateur 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 à moteur terrestre, comprenant le calculateur principal CL1 de la FIG. 1 . Procédé de contrôle mis en œuvre par un calculateur principal (CL1) dans un véhicule (2) embarquant ledit calculateur principal et au moins un autre calculateur (CL2) secondaire, ledit calculateur principal comprenant une première interface de communication (16) et une deuxième interface de communication (18), le ledit procédé comprenant : - réception (S1), au moyen de la première interface de communication, depuis un serveur (SV1) distant du véhicule, d’une commande de gestion (CMD1) relative à une fonction (F1a), dite fonction cible, dudit véhicule ; - identification (S2) d’un calculateur secondaire (CL2a), dit calculateur cible, associé à ladite fonction cible ; et - transmission (S3), au moyen de la deuxième interface de communication (18), de la commande de gestion (CMD1) au calculateur cible (CL2a). Procédé selon la revendication 1 comprenant, préalablement à la réception (S1) de la commande de gestion (CMD1), enregistrement de données d’attribution (DT1) associant des fonctions (F1) du véhicule à des calculateurs secondaires (CL2) respectifs dudit véhicule ; dans lequel l’identification du calculateur cible (CL2a) est réalisée en déterminant le calculateur secondaire associé à la fonction cible (F1a) selon les données d’attribution. Procédé selon la revendication 1 ou 2, dans lequel le procédé comprend une phase d’attente d’une commande provenant de l’extérieur du véhicule, le calculateur principal (CL1) étant, pendant ladite phase d’attente, dans un état actif permettant de recevoir une commande provenant de l’extérieur du véhicule (2) via la première interface de communication (16), indépendamment d’un état courant dans lequel se trouve chaque calculateur secondaire (CL2) pendant ladite phase d’attente ; la commande de gestion (CMD1) étant reçue au cours de ladite phase d’attente. Procédé selon l’une quelconque des revendications précédentes, dans lequel le procédé comprend, après l’identification (S2) du calculateur cible (CL2a) : - vérification de si le calculateur cible est dans un état actif permettant une configuration de la fonction cible (F1a) ; - mise en attente de la commande de gestion (CMD1) tant que le calculateur cible est dans un état inactif ; et - sur détection que le calculateur cible est à l’état actif, déclenchement de la transmission (S3), au moyen de la deuxième interface de communication (18), de la commande de gestion au calculateur cible (CL2a). Procédé selon l’une quelconque des revendications précédentes, dans lequel la commande de gestion (CMD1) transmise au calculateur cible (CL2a) cause au moins l’une parmi les opérations de configuration suivantes : - paramétrage de la fonction cible ; - activation de ladite fonction cible ; et - désactivation de ladite fonction cible. Procédé selon l’une quelconque des revendications précédentes, dans lequel le procédé comprend, préalablement à la réception (S1) de la commande de gestion : - réception, au moyen de la deuxième interface de communication (18) depuis le calculateur cible (CL2a), d’une valeur courante (V1) d’un paramètre (PR1a) de la fonction cible ; - enregistrement de la valeur courante (V2) en association avec la fonction cible (F1a) dans des données de configuration (DT2) ; et - en réponse à une commande de lecture (CMD2), relative à la fonction cible (F1a), provenant du serveur distant (SV1), envoi au serveur distant de ladite valeur courante (V1) associée à ladite fonction cible selon les données de configuration (DT2) ; la commande de gestion (CMD1) étant reçue (S1) en réponse audit envoi de la valeur courante (V1). Programme d’ordinateur (PG1) 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 (12). Calculateur (CL1), dit calculateur principal, comprenant : - une première interface de communication (16) configurée pour communiquer avec un serveur (SV1) distant d’un véhicule (2) dans lequel est embarqué le calculateur ; - une deuxième interface de communication (18) configurée pour communiquer avec au moins un calculateur secondaire (CL2) embarqué dans le véhicule ; et - une mémoire (18 ; 41) associée à au moins un processeur (12) configuré pour la mise en œuvre des étapes du procédé selon l’une quelconque des revendications 1 à 6. Véhicule (2) comprenant le calculateur principal (CL1) selon la revendication 8. Véhicule selon la revendication 9, dans lequel le calculateur principal (CL1) et ledit au moins un calculateur secondaire (CL2) font partie d’un réseau de communication embarqué du véhicule, dans lequel le calculateur principal est l’unique calculateur, dans le réseau de communication, comprenant une dite première interface de communication (16) permettant de communiquer avec le serveur distant (SV1), ledit calculateur principal étant configuré pour agir en tant qu’agent centralisé à l’interface entre le réseau de communication embarqué et le serveur distant.