FR 3103926 A1 20210604 FR 1913530 A 20191129 Procédé de mise à jour de système numérique. Dans un véhicule (4) comprenant un système numérique qui comporte un calculateur client (10) embarqué apte à communiquer avec un serveur distant (101, 102), une unité de contrôle-commande embarquée ( 20, 11, 21, 22, 30, 31, 32, 33, 23) connectée, directement ou indirectement, au calculateur client (10) par un réseau embarqué de communication (5, 6, 7, 8), et comprenant un dispositif d’accumulation d’énergie électrique pour alimenter le calculateur embarqué et ladite unité de contrôle-commande embarquée ( 20, 11, 21, 22, 30, 31, 32, 33, 23), le procédé de mise à jour du système numérique comprend des étapes de : - téléchargement dans laquelle le calculateur client (10) télécharge un fichier à partir du serveur distant à condition que le dispositif d’accumulation d’énergie électrique est en état de pouvoir être rechargé ; - distribution dans laquelle le calculateur client (10) distribue au moins une partie du fichier téléchargé à destination de l’unité de contrôle-commande embarquée ( 20, 11, 21, 22, 30, 31, 32, 33, 23) ; - installation dans laquelle toute partie distribuée du fichier téléchargé est installée dans l’unité de contrôle-commande embarquée ( 20, 11, 21, 22, 30, 31, 32, 33, 23). Figure à publier avec l’abrégé : Fig. 1. Procédé de mise à jour de système numérique. L’invention concerne un procédé de mise à jour de système numérique dans un véhicule, notamment dans un véhicule automobile. De manière connue en soi, un système numérique dans un véhicule comprend un ou plusieurs calculateurs embarqués communiquant entre eux par un ou plusieurs bus embarqués. On rappelle qu’un calculateur embarqué comprend généralement une mémoire permanente pour stocker au moins des données numériques permanentes, un micrologiciel et/ou un programme informatique. Le calculateur embarqué comprend généralement aussi une mémoire vive pour mémoriser des données numériques variables, et au moins un processeur pour écrire et/ou lire les données numériques variables en mémoire vive en exécutant le programme informatique à partir de tout ou partie des données numériques permanentes et des données numériques variables. Une mise à jour du système numérique consiste à modifier un contenu numérique de la mémoire permanente d’au moins un calculateur embarqué. Le document FR2775363 divulgue un calculateur de véhicule adapté pour être raccordé à un outil de mise à jour de données stockées mais il est préférable d’arrêter le véhicule pour raccorder l’outil de mise à jour. Le document FR3011651 divulgue un procédé de mise à jour d’un calculateur de véhicule utilisant un boîtier d’interface, cependant la mise en œuvre du procédé nécessite un arrêt du véhicule pour brancher le boîtier. Le document FR2775371 divulgue un procédé pour télécharger un fichier de mise à jour en mémoire réinscriptible d’un calculateur de véhicule. Aujourd’hui, un large éventail de possibilités de télétransmissions sans fil, offre des opportunités pour télécharger des fichiers de mise à jour dans des unités de contrôle-commande embarqués de véhicule sans avoir à brancher un connecteur physique sur le véhicule. Cependant les procédés et dispositifs connus, nécessitent encore une durée plus ou moins prolongée du véhicule pour mettre à jour un fichier de données ou de programme dans une unité de contrôle-commande embarquée. L’écriture à partir d’un serveur distant dans une mémoire réinscriptible d’unité de contrôle-commande embarquée nécessite plus de temps que dans une mémoire conventionnelle d’ordinateur ou de téléphone mobile. Un arrêt du véhicule reste préconisé pour éviter un changement impromptu de comportement du véhicule en roulage, lié à la mise à jour. Un besoin se fait sentir pour réduire au minimum une durée de mise à jour d’unité de contrôle-commande, notamment pour réduire au minimum une durée d’indisponibilité du véhicule, pour passer d’une configuration antérieure d’unité de contrôle-commande embarquée à une nouvelle configuration par mise à jour de programme ou de données. Le document EP2249251A1 divulgue un dispositif de mise à jour comprenant un serveur, une unité de contrôle-commande embarquée dans un véhicule, des moyens de communication pour connecter le serveur et l’unité de contrôle-commande embarquée, dans lequel lorsque le serveur exécute un processus de réécriture d’un programme de l’unité de contrôle-commande embarquée via les moyens de communication, le serveur détermine s’il doit exécuter ou non la réécriture du programme en se référant à un contenu mémoire de l’unité de contrôle-commande embarquée. Si une anomalie ou une rupture de communication se produit au cours de la tâche de réécriture, le processus de réécriture n’est pas mené à terme, une remise à zéro est exécutée, le programme antérieur est démarré. Le dispositif divulgué par le document ci-dessus cité présente de nombreux inconvénients dont notamment celui de différer à une date intolérablement éloignée la mise à jour de l’unité de contrôle-commande embarquée en cas d’anomalies et/ou de ruptures de communications répétées. De tels cas peuvent se produire dans un véhicule, par exemple lorsqu’il est sous un tunnel ou dans un parking sous-terrain, par exemple aussi en cas de baisse de tension sur le réseau électrique embarqué du véhicule à laquelle sont sensibles les télécommunications et l’écriture en mémoire réinscriptible, par ailleurs fortement consommatrice d’électricité. Chaque tentative de réécriture d’un programme nécessaire au fonctionnement du véhicule, rend le véhicule indisponible jusqu’à démarrer le programme réécrit ou le programme antérieur selon que la réécriture s’est exécutée correctement ou non. Pour remédier aux inconvénients présentés par l’état antérieur de la technique, l’invention a pour objet un procédé de de mise à jour de système numérique dans un véhicule comprenant un calculateur client embarqué, notamment de type multimédia, apte à communiquer avec un serveur distant, une unité de contrôle-commande embarquée connectée, directement ou indirectement, au calculateur client par un réseau embarqué de communication, et un dispositif d’accumulation d’énergie électrique pour alimenter le calculateur embarqué et l’unité de contrôle-commande embarquée. Le procédé est remarquable en ce qu’il comprend : - une étape de téléchargement dans laquelle le calculateur client télécharge un fichier à partir du serveur distant lorsque le dispositif d’accumulation d’énergie électrique est en état de pouvoir être rechargé ; - une étape de distribution dans laquelle le calculateur client distribue, directement ou indirectement, au moins une partie du fichier téléchargé à destination de l’unité de contrôle-commande embarquée ; - une étape d’installation dans laquelle toute ou portion de ladite au moins une partie distribuée du fichier téléchargé est installée dans l’unité de contrôle-commande embarquée ; - une étape d’activation dans laquelle l’unité de contrôle-commande embarquée active la ou les portions de fichier installées après mise à l’arrêt du véhicule. Le calculateur est dit client en ce qu’il se distingue de l’unité de contrôle-commande par sa capacité à traiter d’autres média ou support que des contrôle-commandes d’actionneurs et de capteurs du véhicule, comme par exemple à traiter un téléchargement au protocole FTP. En utilisant les ressources de traitement du calculateur client pour télécharger un fichier de mise à jour, on allège les ressources nécessaires à la mise à jour dans l’unité de contrôle-commande, et par là même son coût, effet d’autant plus intéressant qu’un système numérique embarqué comprend généralement de nombreuses unités de contrôle-commande. La durée de téléchargement est totalement transparente pour l’unité de contrôle-commande car cette dernière n’est pas impactée par le téléchargement. Le dispositif d’accumulation d’énergie électrique en état de pouvoir être rechargé pendant le téléchargement assure de ne pas perturber non seulement le téléchargement, mais aussi d’autres consommateurs électriques du véhicule par la consommation électrique du téléchargement. Les étapes de distribution et d’installation effectuées après le téléchargement, décorrélées de l’étape de téléchargement, ne nécessitent pas de connexion au serveur distant pour être exécutées. Un calculateur multimédia est un exemple de calculateur client. L’unité de contrôle-commande embarquée est connectée, directement ou indirectement, au calculateur client, il s’agit donc de tout type d’unité de contrôle commande quelle que soit la manière dont elle est reliée au calculateur client, que ce soit par exemple directement par une liaison de communication, ou encore via un calculateur passerelle et des liaisons de communications, ou encore par les deux manières. De par ses ressources, le calculateur client est mis en interface avec un serveur distant et pilote directement ou indirectement les différentes étapes du procédé selon l’invention, par exemple il distribue indirectement une partie du fichier téléchargé à destination de certaines unités de contrôle-commande embarquées pour lesquelles la distribution est pilotée par le calculateur client puis gérée par le calculateur passerelle. Avantageusement dans l’étape de téléchargement, le calculateur client mémorise constamment un point de progression du téléchargement de manière à arrêter le téléchargement lorsqu’une dégradation effective ou risquée de communication avec le serveur distant est détectée, et reprend le téléchargement à partir du point de progression mémorisé lorsqu’il détecte une disparition de dégradation effective ou risquée de communication avec le serveur distant. Il est ainsi possible d’interrompre le téléchargement autant de fois que nécessaire en cas de dégradation de communication effective ou risquée puis de le reprendre lorsque de bonnes conditions sont retrouvées, sans nuire aux étapes suivantes qui peuvent ensuite se faire hors connexion. Les causes de dégradations effectives de communication sont multiples, passage du véhicule dans un tunnel ou dans un parking souterrain, interruption par un autre processus prioritaire sur le téléchargement, panne du serveur distant ou autres. Particulièrement, le dispositif d’accumulation d’énergie électrique hors d’état de pouvoir être rechargé est considéré par le procédé constituer une condition de détection de dégradation risquée de communication avec le serveur distant. Plus particulièrement, lorsque le véhicule comprend un moteur thermique, le dispositif d’accumulation d’énergie électrique est considéré en état de pouvoir être rechargé si le moteur thermique est en rotation. Le moteur thermique en rotation, permet par exemple de recharger dispositif d’accumulation d’énergie électrique au moyen d’un alternateur ou d’un alternodémarreur. Plus particulièrement aussi, lorsque le véhicule comprend une batterie de traction électrique, le dispositif d’accumulation d’énergie électrique est considéré en état de pouvoir être rechargé si la batterie de traction électrique est branchée sur un réseau électrique de rechargement externe. Ce cas peut se produire non seulement pour un véhicule à traction purement électrique, mais aussi pour un véhicule hybride rechargeable sur réseau électrique externe ou au moyen du moteur thermique. Avantageusement, le réseau embarqué de communication comporte une première liaison embarquée reliée au calculateur client, une deuxième liaison embarquée reliée à l’unité de contrôle-commande embarquée et un calculateur passerelle relié au calculateur client et à l’unité de contrôle-commande embarquée, une exécution de l’étape d’installation de tout ou partie distribuée du fichier téléchargé dans l’unité de contrôle-commande embarquée par le calculateur passerelle, permet de décharger l’unité de contrôle-commande embarquée, des tâches d’installation, gardant ainsi l’unité de contrôle-commande embarquée intégralement disponible pour ses tâches de contrôle commande, pour toute unité de contrôle-commande dont au moins un processeur est relié indirectement au calculateur client via la passerelle. Avantageusement, en équipant le réseau embarqué de communication avec un premier bus embarqué relié au calculateur client, un deuxième bus embarqué relié à l’unité de contrôle-commande embarquée, et un calculateur passerelle relié aux deux dits bus embarqués, une exécution de l’étape d’installation de tout ou partie distribuée du fichier téléchargé dans l’unité de contrôle-commande embarquée, par le calculateur passerelle permet de décharger l’unité de contrôle-commande embarquée, des tâches d’installation, gardant ainsi l’unité de contrôle-commande embarquée intégralement disponible pour ses tâches de contrôle commande, notamment pour toute unité de contrôle-commande reliée indirectement au calculateur client via la passerelle. Particulièrement, en équipant l’unité de contrôle-commande embarquée avec deux banques de mémoire réinscriptible exécutable, le procédé consiste à faire fonctionner l’unité de contrôle-commande embarquée sur une première banque de mémoire réinscriptible pendant que l’étape d’installation est appliquée sur une deuxième banque de mémoire réinscriptible. Ainsi il suffit de faire commuter l’unité de contrôle commande de la première banque de mémoire réinscriptible exécutable sur la deuxième banque pour activer la mise à jour, la première banque jouant alors le rôle de la deuxième banque en vue d’une mise à jour ultérieure. Un arrêt bref du véhicule peut suffire car la disponibilité de l’unité de contrôle commande pendant les étapes de téléchargement, de distribution et d’installation qui précèdent, permet de laisser fonctionner le véhicule jusqu’à l’arrêt, alors exécuté simplement pour éviter à l’utilisateur du véhicule d’être surpris par un changement de comportement en cours de fonctionnement du véhicule. Avantageusement, le procédé comporte une étape de pré téléchargement de données descriptives, qui permettront de caractériser les contenus numériques des fichiers téléchargés et de configurer dynamiquement l’expérience utilisateur lors de chaque mise à jour. Particulièrement, le fichier téléchargé obtenu à l’issue de l’étape de téléchargement comporte d’autres données descriptives, qui permettront notamment de sécuriser les contenus numériques des fichiers téléchargés pour les unités de contrôle commande directement reliés au calculateur client. Avantageusement, au moins une partie des données descriptives pré téléchargées comporte des métadonnées de configuration. Plus particulièrement le procédé comporte au moins une étape de vérification d’au moins une condition d’activation, ladite au moins une condition d’activation étant fonction d’au moins une partie des données descriptives ce qui permet la configuration dynamique c’est à dire une gestion diversifiée et dynamique des campagnes de mises à jour, qui peut ainsi être définie en amont de manière débarquée. De manière avantageuse, au moins une desdites étapes du procédé de mise à jour de système numérique comporte une sous-étape d’interaction entre l’appareil d’interface homme-machine et l’utilisateur via l’appareil d’interface homme-machine selon un mode d’interaction spécifique, notamment fonction de ladite étape en cours. Par exemple, le confort de l’utilisateur est encore amélioré lorsque l’étape d’activation nécessite un accord d’un utilisateur du véhicule pour être exécutée. L’invention a aussi pour objet un système numérique embarqué dans un véhicule comprenant un calculateur client embarqué apte à communiquer avec un serveur distant, une unité de contrôle-commande embarquée connectée au calculateur client par un réseau embarqué de communication, alimentés chacun par un dispositif d’accumulation d’énergie électrique, caractérisé en ce que le calculateur client embarqué et l’unité de contrôle-commande embarquée sont programmés pour exécuter le procédé selon l’invention. Avantageusement dans le système numérique embarqué, le réseau embarqué de communication comporte un premier bus embarqué relié au calculateur client, un deuxième bus embarqué relié à l’unité de contrôle-commande embarquée, et un calculateur passerelle relié aux deux dits bus embarqués, de sorte que le calculateur passerelle est programmé pour exécuter l’étape d’installation conforme au procédé. L’invention a aussi pour objet un véhicule automobile comprenant un système numérique embarqué selon l’invention. D’autres avantages et caractéristiques de l’invention apparaîtront à la lecture de la description détaillée de modes de mise en œuvre et de réalisation, à titre d’exemples illustratifs et non limitatif, en référence aux dessins annexés dans lesquels : montre schématiquement un véhicule comprenant un système numérique sur lequel est mise en œuvre l’invention ; montre des étapes de séquence de pré téléchargement et de séquence de téléchargement au sein du procédé conforme à l’invention ; montre des étapes de distribution et d’installation pour un premier type de calculateur embarqué ; montre des étapes de distribution et d’installation pour un deuxième type de calculateur embarqué; montre le schéma de distribution et d’installation pour un troisième type de calculateur embarqué ; montre des étapes d’activation pour un premier type de calculateur embarqué mis à jour ; montre des étapes d’activation pour un deuxième type de calculateur embarqué mis à jour . Pour plus de clarté, les étapes identiques ou similaires sont repérées par des signes de référence identiques sur l’ensemble des figures. montre un véhicule 4 comprenant un système numérique dans lequel est mise en œuvre l’invention. Le système numérique comprend au moins deux calculateurs embarqués 10, 11, 21, 22, 23 agencés pour communiquer entre eux sur un premier bus de communication embarqué 5. Un appareil d’interface homme-machine 12 équipé d’un ou plusieurs écrans, peut comprendre un coupleur de communication sur le bus embarqué 5. Le calculateur embarqué client 10 calculateur embarqué client 10 comprend un ou plusieurs processeurs et une capacité mémoire dimensionnée pour lui donner des ressources de calcul adaptées au traitement d’information numérique volumineuse, comme celle nécessaire à l’affichage pictographique et à la perception de commandes humaines par le bus embarqué 5 ou par liaison directe sur l’appareil d’interface homme-machine 12, aux échanges avec d’autres calculateurs embarqués du système numérique, à une communication extérieure au véhicule, et à l’exécution de programmes informatiques de niveau opérationnel et/ou applicatif. Le calculateur embarqué client 10 calculateur embarqué client 10 est par exemple souvent désigné par l’acronyme IVI (In-Vehicle Infotainment en anglais pour Info-divertissement Dans le Véhicule). Pour la communication extérieure, on peut équiper le calculateur embarqué client 10 calculateur embarqué client 10 avec une ou plusieurs prises 3 de type USB, OBD ou autre. Une prise 3 de type USB permet par exemple des transferts de fichiers stockés ou à stocker en mémoire d’une clé USB. On peut aussi équiper le calculateur embarqué client 10 avec des moyens de communication par voie aérienne OTA (Over The Air en anglais), pour établir des communications 1, par exemple à un standard de type 802.11 avec un serveur distant 101. En dehors du calculateur client 10, les autres calculateurs sont des unités de contrôle-commande embarquée, qui peuvent être de trois types différents. Le premier type désignant les unités de contrôle-commande directement reliées au calculateur client 10 par le bus 5, ils sont intelligents et dotés de capacités de dé-encapsulation car ils se trouvent dans une zone non sécuritaire car située avant le calculateur passerelle 21 et reçoivent donc des contenus sécurisés par encapsulation(s), leurs mémoires sont préférentiellement de nature interne double banque , c’est-à-dire deux banques de mémoire réinscriptible exécutable (par exemple Flash, EEPROM) ou de nature mémoire tampon interne. Le second type désignant les unités de contrôle -commande indirectement reliées au calculateur client 10 via le calculateur passerelle 21, ils sont donc en zone sécuritaire et de nature plus basique, leurs mémoires sont préférentiellement de nature interne double banque (deux banques de mémoire réinscriptible exécutable, par exemple Flash, EEPROM) ou de nature mémoire externe. Le troisième type désigne les calculateurs hybrides qui ont deux processeurs, l’un étant donc en liaison avec le calculateur client 10 et l’autre en liaison avec le calculateur passerelle 21. Le calculateur embarqué 21 est de type passerelle (GW pour Gate Way en anglais). Le calculateur embarqué 21 permet d’échanger de l’information numérique entre le premier bus embarqué 5 et un deuxième bus embarqué 6 du système numérique. Le système numérique comprend un ou plusieurs calculateurs embarqués 31, 32, 33 agencés pour communiquer entre eux et avec le calculateur embarqué 21, sur le deuxième bus embarqué 6. Le ou les calculateurs embarqués 31, 32, 33 sont de type UCE (acronyme de Unité de Commande Electronique). De manière connue en soi par ailleurs, une unité de commande électronique comprend une ou plusieurs sorties reliées chacune à un actionneur du véhicule, un coupleur de communication sur le bus embarqué 6, et un circuit électronique de traitement numérique pour commander, de manière connue en soi par ailleurs au moyen d’un micrologiciel, le ou les actionneurs en fonction de données numériques circulant sur le bus embarqué de communication 6. Chaque calculateur embarqué 31, 32, 33 constituant une unité de commande électronique, peut aussi comprendre une ou plusieurs entrées reliées à des capteurs et/ou à des organes de commande du véhicule, pour exécuter le micrologiciel. Le bus embarqué 6 est représenté de manière simplifiée en figure 1, il peut comprendre plusieurs ramifications reliées les unes aux autres par des passerelles secondaires non représentées et sans impact particulier sur le fonctionnement de l’invention. Selon différentes réalisations possibles, le système numérique du véhicule 4 peut aussi comprendre un calculateur embarqué 11 qui comprend des moyens de communication par voie aérienne à plus longue distance que par exemple celle au standard 802.11. Les moyens de communication par voie aérienne (OTA) du calculateur embarqué 11, permettent par exemple de manière connue en soi par ailleurs, d’établir une communication 2 par réseau de téléphonie cellulaire de version 4G ou supérieure avec un serveur distant 102, identique, distinct et ou connecté au serveur distant 101. D’autres type de communication peuvent être envisagés pour le calculateur embarqué 11, comme par exemple à titre purement illustratif et non exhaustif, un mode de communication satellitaire ou un mode mixte de communication hertzienne descendante et de communication GSM montante. Le calculateur embarqué 11 n’est pas nécessairement distinct du calculateur embarqué 10. En d’autres termes, on peut envisager des versions de système numérique dans lesquelles le calculateur embarqué client 10 calculateur embarqué client 10 intègre les fonctionnalités du calculateur embarqué 11. Lorsqu’il est distinct du calculateur embarqué 10, le calculateur embarqué 11 tel qu’il est illustré sur la figure 1, est relié au calculateur embarqué client 10 calculateur embarqué client 10 par le bus 5 ou par une liaison directe, pour faire bénéficier le calculateur embarqué client 10 calculateur embarqué client 10 de ses possibilités de communication à longue distance. Le calculateur embarqué 11 est alors par exemple du type souvent désigné par l’acronyme IVC (In-Vehicle Communication en anglais pour Communication Dans le Véhicule). Selon différentes réalisations possibles, le système numérique du véhicule 4 peut aussi comprendre un calculateur embarqué 22 sans incidence directe sur le fonctionnement du véhicule, et relié pour cette raison au bus embarqué 5. Selon différentes réalisations possibles, le système numérique du véhicule 4 peut aussi comprendre un calculateur embarqué 23 de type unité de commande électronique à haute capacité de traitement numérique, par exemple pour superviser et/ou gérer plusieurs fonctions du véhicule 4. Le calculateur embarqué 23 est alors relié au bus embarqué 5 pour traiter des données sans incidence directe sur le fonctionnement du véhicule ou des données sur lesquelles il peut exercer un contrôle de sécurité. Le calculateur 23 est relié au bus embarqué 5 pour traiter des données avec incidence sur le fonctionnement du véhicule. Le calculateur 23 peut aussi être relié au calculateur 10 par une liaison directe 7 (par exemple via protocole CAN, FTP, Ethernet) et au calculateur passerelle par un bus embarqué de communication 8. Le calculateur embarqué client 10 calculateur embarqué client 10 et au moins l’un des calculateurs embarqués 21, 22, 23 relié au bus embarqué 5, notamment le calculateur embarqué 21, hébergent un programme informatique réparti, comprenant des instructions informatiques pour mettre en œuvre le procédé de mise à jour expliqué ci-après, lorsque le programme informatique réparti est exécuté par les calculateurs sur lesquels il est hébergé. Les étapes du procédé décrites dans les figures suivantes se divisent en trois phases, à savoir la première phase d’échanges entre un serveur distant 101 et le calculateur embarqué client 10 , contenant des étapes de pré téléchargement de données descriptives et de téléchargement des contenus numériques en fonction des données descriptives , illustrée notamment par la figure 2, la deuxième phase d’échanges entre le calculateur embarqué client 10 et un type de calculateur embarqué 20,30, 23, (indirectement via le calculateur passerelle 21 pour les calculateurs de deuxième ou troisième type) contenant des étapes de distribution et d’installation des contenus numériques, illustrée notamment par les figures 3 et 4 et 5 en fonction du type de calculateur, la troisième phase d’échanges entre le calculateur embarqué client 10 et un type de calculateur embarqué 20,30, 23, (indirectement via le calculateur passerelle 21 pour les calculateurs de deuxième ou troisième type) contenant des étapes d’activation d’un ou plusieurs calculateurs embarqués 20, 30, 23 mis à jour, illustrée notamment par les figures 6 et 7 en fonction du type de calculateur. Seule la première phase du procédé nécessite d’être connecté au monde extérieur via un réseau de télécommunication, les autres phases étant exécutables déconnectées du monde extérieur. montre des étapes de procédé conforme à l’invention pour effectuer un pré téléchargement et un téléchargement de contenu numérique à partir d’un serveur de téléchargement distant 101. A partir d’une première étape de veille du procédé exécuté dans le calculateur embarqué 10, une transition 1001 est validée lorsque l’existence d’une mise à jour à réaliser, est signalée, notamment via un logiciel d’interface avec le monde extérieur, en mémoire du calculateur embarqué client 10 par le serveur distant 101 et que le véhicule 4 est en conditions satisfaisantes pour effectuer un pré téléchargement. Le calculateur embarqué client 10 constitue un calculateur embarqué client de téléchargement au regard du procédé de mise à jour de système numérique exposé. L’existence d’une mise à jour à réaliser, résulte d’un processus amont connu en soi par ailleurs. Le fait pour le véhicule 4 de disposer d’un niveau suffisant de connectivité à un réseau de télécommunication, génère une condition satisfaisante pour effectuer un pré téléchargement. Un état du véhicule 4 lorsqu’il est à propulsion électrique ou à propulsion hybride rechargeable, dans lequel il est branché sur un réseau électrique de rechargement de batterie, ou s’il est en mouvement, dans lequel il est en phase de décélération, génère une condition satisfaisante pour effectuer un pré téléchargement. Un état du véhicule 4 lorsqu’il est à propulsion thermique ou à propulsion hybride, dans lequel son moteur à combustion interne tourne, génère une condition satisfaisante pour effectuer un pré téléchargement, que le véhicule soit en roulage ou à l’arrêt. Une validation de la transition 1001 fait passer le procédé dans une étape 1002 qui consiste à pré télécharger des données descriptives de contenu à télécharger. Ces données descriptives, notamment sous forme de métadata en fichier .xml, comportent par exemple le numéro VIN (Vehicle Identification Number en anglais), l’adresse des contenus numériques à télécharger (par exemple URL), la liste d’ordonnancement des contenus à télécharger, des métadonnées de configuration spécifiant notamment le mode d’interaction sans demande utilisateur (background) ou avec demande utilisateur (foreground). En étape 1002, le calculateur embarqué client 10 commence par envoyer une requête de pré téléchargement au serveur 101 puis stocke en mémoire tampon les données descriptives de contenu au fur et à mesure de leur arrivée. La requête de pré téléchargement contient notamment un numéro VIN du véhicule 4 auquel appartient le calculateur embarqué 10. Le calculateur embarqué client 10 vérifie notamment que les données descriptives reçues correspondent bien aux spécifications du véhicule identifié par le numéro VIN. A partir d’une deuxième étape de veille du procédé exécuté dans le serveur 101, une transition 10101 est validée lorsque le serveur reçoit la requête de pré téléchargement émise par le calculateur embarqué client 10 à l’étape 1002 de pré téléchargement. Une validation de la transition 10101 fait passer le procédé dans une étape 10102 qui consiste à émettre les données descriptives de contenu à télécharger vers le calculateur embarqué 10. A titre illustratif, le serveur distant 101 peut utiliser le protocole FTP pour transférer les données descriptives sous forme de fichier ou UDP sur une voie de télécommunication disponible par ondes électromagnétiques, 802.11, téléphonie cellulaire, réseau ad hoc (WANET, MANET, VANET…) ou autre, la mieux appropriée selon que le véhicule est à l’arrêt ou en mouvement, et/ou selon l’environnement du véhicule 4, c’est à dire des moyens de télécommunication disponible en sa localisation. Une voie de télécommunication filaire (802.3 sur câble Ethernet ou par Courant Porteur en Ligne) peut aussi être utilisée par exemple sur un véhicule électrique lorsqu’il est branché sur une station de rechargement de batterie. Parallèlement à l’étape 10102 d’émission de données descriptives exécutée dans le serveur 101, l’étape 1002 exécutée dans le calculateur embarqué 10, consiste à stocker en mémoire interne les fichiers ou trames reçues du serveur 101 directement par voie de communications 1 sur un coupleur de télécommunications propre au calculateur embarqué 10, ou indirectement via un autre serveur 102 de cœur de réseau de téléphonie cellulaire, un autre calculateur embarqué 11 (IVC) dédié aux télécommunications et un bus embarqué 5. A partir de l’étape 1002 de pré téléchargement, une transition 1003 est validée en cas de perte par le véhicule 4 d’une condition satisfaisante pour effectuer un pré téléchargement. La perte de condition satisfaisante peut résulter d’une perte de connectivité au réseau de télécommunication, par exemple lorsque le véhicule passe dans un tunnel ou entre dans une zone à faible couverture réseau. La perte de condition satisfaisante peut résulter d’un arrêt du moteur à combustion interne lorsque le véhicule 4 est à propulsion thermique ou à propulsion hybride non rechargeable, par exemple lorsque le conducteur quitte le véhicule pour aller acheter une baguette de pain. Une coupure d’alimentation batterie peut aussi constituer une perte de condition satisfaisante. Une validation de la transition 1003 fait passer le procédé dans une étape 1004 qui consiste à mettre le calculateur embarqué en attente de conditions satisfaisantes pour effectuer un pré téléchargement. En cas de coupure d’alimentation batterie, le calculateur embarqué client 10 peut utiliser une méthode de type STR (acronyme de l’expression anglaise Suspend To RAM) relative à la gestion de l’énergie permettant de suspendre l’exécution des processus et de mémoriser leur état afin de les restaurer à l’identique après extinction du calculateur embarqué. A partir de l’étape 1004, une transition 1005 est validée lorsque toutes les conditions satisfaisantes au pré téléchargement sont retrouvées, reconnexion à un réseau de télécommunication par exemple en sortie de tunnel, redémarrage du moteur thermique, par exemple au retour du conducteur avec sa baguette de pain. Une validation de la transition 1005 fait repasser le procédé dans l’étape 1002 qui consiste à informer le serveur 101 de sa disponibilité et à poursuivre le stockage des données descriptives envoyées par le serveur 101. Pendant l’interruption de réception par le calculateur embarqué en étape 1004, le serveur 101 reste simplement en attente en étape 10102 de manière habituellement prévue dans les protocoles FTP et UDP pour reprendre l’émission là où elle s’était interrompue. A partir de l’étape 1002 de pré téléchargement, une transition 1007 est validée lorsque toutes les données descriptives ont été stockées en mémoire tampon du calculateur embarqué 10. Une validation de la transition 1007 fait passer le procédé dans une étape 1008 qui consiste à télécharger des contenus numériques comportant des données descriptives les caractérisant (notamment des données de sécurisation liées notamment aux contenus sécurisés destinés à des calculateurs du premier type (en zone non sécurisée) ou à un calculateur destinataire passerelle 21 en vue de la mise à jour d’un calculateur de deuxième type ou hybride (dans ce cas ces données contiennent par exemple des informations du destinataire de la mise à jour, de la cible de la mise à jour, de taille,…), et par exemple à envoyer les données descriptives de configuration pré téléchargées au module de gestion des configurations dynamiques HMI-proxy (dans ce cas ces données contiennent, comme mentionné précédemment des métadonnées de configuration déterminant notamment le mode d’interaction sans demande utilisateur (background) ou avec demande utilisateur (foreground)). En étape 1008, le calculateur embarqué client 10 commence par envoyer une requête de téléchargement au serveur 101 par exemple sur le port FTP du calculateur embarqué 10 lorsque le protocole FTP est utilisé, ou via un autre port en fonction du type de communication (Wifi, Ethernet...). A partir de l’étape 10102 du procédé exécuté dans le serveur 101, une transition 10103 est validée lorsque le serveur reçoit la requête de téléchargement émise par le calculateur embarqué client 10 à l’étape 1008. Une validation de la transition 10103 fait passer le procédé dans une étape 10104 qui consiste à émettre les contenus requis vers le calculateur embarqué 10. A titre illustratif, le serveur distant utilise de préférence un protocole de type FTP pour transférer les contenus sous forme d’un ou plusieurs fichiers sur une voie de télécommunication disponible de manière semblable au mode opératoire de l’étape 10102. Parallèlement à l’étape 10104 exécutée dans le serveur 101, l’étape 1008 est exécutée dans le calculateur embarqué 10, de manière comparable à l’étape 1002 de pré téléchargement avec stockage en mémoire tampon interne. L’utilisation notamment du protocole FTP sur un port de l’IVI, permet une exécution en parallèle sans interruption avec des étapes d’autres procédés de télécommunication sur d’autres ports ou utilisant d’autres protocoles. Par exemple, si le calculateur embarqué client 10 reçoit sur le bus embarqué 5 en provenance du calculateur embarqué 11 ou d’une prise de diagnostic OBD, des trames liées à un procédé de diagnostic à distance ou local, exécuté en parallèle, les trames sont simplement aiguillées, notamment en interne du calculateur embarqué client 10, sans besoin d’interrompre l’étape 1008 à aucun moment. Pendant le téléchargement, le calculateur 10 fait différents contrôles sur les fichiers téléchargés, comme par exemple des vérifications de conformité des fichiers aux données descriptives de contenu précédemment reçues en étape 1002 de pré téléchargement, et/ou des contrôles connus de parité sur des trames reçues pour véhiculer les fichiers téléchargés. A partir de l’étape 1008, une transition 1009 est validée en cas de perte par le véhicule 4 d’une condition satisfaisante pour effectuer un téléchargement. La perte de condition satisfaisante peut ici encore résulter d’une perte de connectivité au réseau de télécommunication, d’un arrêt du moteur à combustion interne lorsque le véhicule 4 est à propulsion thermique ou à propulsion hybride non rechargeable, ou d’un débranchement de station de chargement batterie lorsque le véhicule 4 est à propulsion électrique. La transition 1009 peut aussi être validée en cas de contrôle négatif sur un fichier téléchargé. Une validation de la transition 1009 fait passer le procédé dans une étape 1010 qui consiste à mettre le calculateur embarqué en attente de conditions satisfaisantes pour continuer à effectuer le téléchargement. En étape 1010, le calculateur 10 conserve un pointeur sur le dernier fichier correctement téléchargé. A partir de l’étape 1010, une transition 1011 est validée lorsque toutes les conditions satisfaisantes au téléchargement sont retrouvées, par exemple : reconnexion à un réseau de télécommunication, redémarrage du moteur à combustion interne pour un véhicule thermique, rebranchement à une station de charge de batterie pour un véhicule électrique, comme à l’étape 1005. Une validation de la transition 1011 fait repasser le procédé dans l’étape 1008 qui consiste à informer le serveur 101 de sa disponibilité et à poursuivre le stockage des fichiers envoyés par le serveur 101. A son retour en étape 1008 par validation de la transition 1011, le calculateur embarqué client 10 envoie au serveur 101, une référence de dernier fichier correctement téléchargé, que ce soit suite à une interruption de conditions satisfaisantes du véhicule ou suite à un contrôle négatif sur un fichier en cours de téléchargement. Pendant l’interruption de réception par le calculateur embarqué en étape 1010, le serveur 101 reste simplement en attente en étape 10104 de manière habituellement prévue dans les protocoles de type FTP pour reprendre l’émission là où elle s’était interrompue dès la disponibilité du calculateur embarqué 10, pour envoyer le fichier à télécharger à la suite du dernier fichier correctement téléchargé. A partir de l’étape 1008, une transition 1013 est validée lorsque le téléchargement terminé est signalé au calculateur embarqué client 10 par le serveur distant 101, les fichiers téléchargés comprennent donc tout le nouveau contenu numérique de la mise à jour, ce contenu est donc complet. Une validation de la transition 1013 fait passer le procédé dans une étape 1014 qui consiste à envoyer au serveur 101 un accusé de bonne réception accompagné préférentiellement d’un rapport de téléchargement effectué. Après envoi de l’accusé de bonne réception, accompagné selon le cas de mise en œuvre, du rapport de téléchargement effectué, le calculateur 10 retourne en étape de veille du procédé, c’est-à-dire en attente de la transition suivante du procédé. On notera que les étapes exécutées par le calculateur embarqué client 10 de la transition 1001 à la transition 1013, peuvent être interrompues de nombreuses fois par les transitions 1003 et/ou 1009, sans interférer avec le fonctionnement du véhicule 4. En effet les deux phases de pré téléchargement et de téléchargement se limitent à un stockage dans le véhicule, par exemple ici dans le calculateur embarqué 10, du contenu utile pour la mise à jour du système numérique. Peu importe que le déroulement des étapes 1002 à 1014 dure quelques minutes ou plusieurs jours, car les étapes 1002 à 1014 sont exécutées en temps masqué par rapport au fonctionnement du véhicule. Les deux phases du procédé qui viennent d’être exposées ci-dessus, sont ainsi mises en œuvre en mode connecté au monde extérieur sans mettre en danger l’état de charge de la ou des batteries électriques du véhicule, rechargées par le moteur à combustion interne tournant pour un véhicule thermique ou hybride, ou rechargées par la station de rechargement sur laquelle est branché le véhicule électrique ou hybride rechargeable. A partir de l’étape 10104, une transition 10105 est validée lorsque le serveur 101 reçoit l’accusé de bonne réception, accompagné selon le cas de mise en œuvre, du rapport de téléchargement effectué. Une validation de la transition 10105 fait passer le procédé dans une étape 10106 qui consiste à consigner l’accusé de bonne réception, accompagné selon le cas de mise en œuvre, du rapport de téléchargement effectué, dans une base de consignation d’états de téléchargements pour un ensemble de véhicules gérés par le serveur 101 en matière de mises à jour de systèmes numériques dans lesdits véhicules. Le serveur 101 retourne ensuite en étape de veille pour les étapes du procédé ci-dessus exposées, de manière connue ensoi par ailleurs pour les serveurs habituellement aptes à traiter plusieurs procédés en parallèle. En outre, au moins une desdites étapes du procédé de mise à jour de système numérique peut comporter une sous-étape d’interaction entre l’appareil d’interface homme-machine 12 et l’utilisateur via l’appareil d’interface homme-machine 12 selon un mode d’interaction spécifique, notamment fonction de ladite étape en cours. Pour ce faire, comme mentionné précédemment, les données descriptives pré téléchargées peuvent comporter des métadonnées (de type xml par exemple) de configuration de l’appareil d’interface homme-machine 12. Ces métadonnées de configuration sont transmises par le calculateur embarqué client 10 à l’appareil d’interface homme-machine 12 par liaison directe interne (représentée, mais non référencée) et stockées dans un module de gestion des configurations dynamiques, aussi appelé HMI proxy, en fin d’étape 1008. En outre, de manière préférentielle, l’appareil d’interface homme-machine 12 est hébergé par le calculateur embarqué client 10. Les métadonnées de configuration caractérisent le contenu numérique pour mettre à jour un calculateur embarqué du fait qu’elles définissent le mode d’interaction entre l’appareil d’interface homme-machine 12 et l’utilisateur lors des étapes de distribution, d’installation et d’activation du contenu numérique associé. En effet, pour chaque étape de la mise à jour et en fonction du contenu numérique, une politique de gestion diversifiée des campagnes de mises à jour peut ainsi être définie en amont de manière débarquée et proposer ainsi des modes d’interaction entre l’appareil d’interface homme-machine 12 et l’utilisateur via l’appareil d’interface homme-machine 12 qui soient différents en fonction de la mise à jour concernée et de l’étape en cours de mise à jour du système numérique. En effet, le calculateur embarqué client 10 intervenant tout au long du procédé de distribution, installation et activation des contenus, il a connaissance de l’étape de la mise à jour en cours. Ainsi, en fonction de la mise à jour et de l’étape d’installation en cours, les différents modes d’interaction avec l’utilisateur, notamment au moyen d’un écran de l’appareil d’interface homme-machine 12, prennent par exemple la forme d’un accord qui peut être demandé à l’utilisateur au moyen d’un bouton virtuel affiché sur l’IHM sur lequel l’utilisateur devra appuyer, ou d’une information à l’utilisateur sous forme de texte, ou encore être invisible à l’utilisateur, par exemple s’il s’agit d’une campagne critique. De plus, les métadonnées de configuration caractérisant le contenu numérique pour mettre à jour un calculateur embarqué peuvent aussi définir les conditions véhicule requises pour déclencher l’interaction entre l’appareil d’interface homme-machine 12 et l’utilisateur. Par exemple, si la phase d’installation se termine en cours de mission, ce qui est très probable, la condition imposera par exemple que le moteur soit éteint et le mode d’interaction par demande de consentement ne sera donc proposé à l’utilisateur en phase d’activation qu’en fin de mission, c’est-à-dire en fin de trajet, une fois le moteur éteint. montre des étapes de procédé conforme à l’invention pour effectuer une distribution et une installation de contenu numérique à l’intérieur du système numérique (on board en anglais) à partir du calculateur embarqué client 10. Les étapes à présent décrites sont exécutées déconnectées du monde extérieur (off board en anglais). Plus précisément, la phase de distribution et d’installation illustrées par la figure 3 sont effectuées en vue de mettre à jour un premier type de calculateur embarqué 20 correspondant à l’un des calculateurs embarqués 11, 21, 22 directement connecté sur le bus embarqué 5 sur lequel est connecté le calculateur embarqué client 10. Ces derniers 11, 21, 22 sont équipés chacun de ressources informatiques suffisantes pour traiter le contenu téléchargé qui lui est destiné. Consécutivement à l’étape 1014 d’envoi d’accusé de bonne réception du procédé exécuté dans le calculateur embarqué 10, une transition 1015 est validée lorsque l’existence d’un contenu numérique complet pour mettre à jour un calculateur embarqué, est signalée en mémoire du calculateur embarqué client 10 par notification interne et que le véhicule 4 est en conditions satisfaisantes pour effectuer une distribution et une installation des contenus numériques à l’intérieur du système numérique. Ce contenu numérique complet prend notamment la forme d’une liste des contenus numériques téléchargés, sachant que l’enchaînement des contenus dans la liste n’a pas d’ordre nécessairement lié aux types de calculateurs, par exemple deux contenus qui se suivent peuvent être destinés à des calculateurs de type différent (à l’image de l’enchaînement suivant premier type puis deuxième type puis premier type puis deuxième type puis troisième type puis deuxième type, par exemple). Les deux phases du procédé relatives à la distribution et à l’installation des contenus dans un ou plusieurs calculateurs embarqués, ne nécessitant pas de connexion avec l’extérieur, le véhicule 4 est en conditions satisfaisantes lorsque le véhicule 4 est à même d’alimenter les calculateurs du système numérique concernés par la distribution et l’installation de contenu, c’est-à-dire par exemple de maintenir un niveau suffisant de charge des batteries, moteur à combustion interne tournant pour un véhicule thermique, batteries branchées sur une station de charge pour un véhicule électrique. Une validation de la transition 1015 fait passer le procédé dans une étape 1016 dans laquelle le calculateur embarqué client 10 distribue un premier contenu numérique téléchargé en mémoire tampon interne vers la mémoire tampon interne du calculateur embarqué 20. En étape 1016, le calculateur embarqué client 10 commence par définir le calculateur embarqué destinataire du contenu numérique par lecture des données descriptives du contenu qui caractérisent ledit contenu, puis envoie une requête de distribution au calculateur embarqué destinataire puis commence à distribuer le contenu numérique vers ce calculateur. En effet, ici le calculateur cible devant être mis à jour par ce contenu numérique est du premier type 20, à savoir l’un des calculateurs 11, 21, 22 relié au calculateur client 10 directement via le bus embarqué 5 et de fait le calculateur destinataire du contenu numérique est identifié comme étant le calculateur cible en question 11, 21, 22. Parallèlement, dans le calculateur destinataire 20, une transition 2001 est validée lorsqu’il 20 reçoit la requête de distribution émise par le calculateur embarqué client 10 à l’étape 1016 de distribution. A titre illustratif, le calculateur embarqué client 10 peut utiliser les protocoles CAN ou FTP pour distribuer le contenu numérique, en l’espèce ce contenu est ici sécurisé (encapsulation(s)) puisque ce calculateur n’est pas en zone sécurisée et comporte des données descriptives téléchargées de sécurisation, au calculateur destinataire 20, en l’espèce via le bus 5 embarqué, indépendamment du niveau de connectivité à un réseau de télécommunication puisque ces étapes sont exécutées déconnectées du monde extérieur. Une validation de la transition 2001 fait passer le procédé dans une étape 2002 qui consiste à stocker le contenu numérique dans le calculateur destinataire 20. Parallèlement à l’étape 1016 de distribution du contenu numérique exécutée par le calculateur client 10, l’étape 2002 de stockage du contenu numérique est exécutée dans le calculateur destinataire 20, il s’agit de désencapsuler le contenu sécurisé puis vérifier que le contenu est bien destiné à audit calculateur 20 (sinon, comme pour tout cas d’échec lors d’une étape, il y a rejet et effacement mémoire, comme explicité pour la phase d’activation dans la suite du texte, en l’espèce mémoire tampon) puis à stocker en mémoire tampon interne du calculateur destinataire 20 les fichiers ou trames reçues du calculateur client 10 via le bus embarqué 5. A partir de l’étape 1016 de distribution, une transition 1017 est validée lorsque la distribution du contenu numérique terminée est signalée au calculateur client 10 par le calculateur embarqué destinataire 20, en l’espèce via le bus 5. En effet, quand bien même le calculateur client 10 sait quand il a fini de distribuer, le signal du calculateur destinataire 20 lui confirme que tout a bien été reçu. Une validation de la transition 1017 fait passer le procédé dans une étape 1018 qui consiste à envoyer une requête d’installation au calculateur destinataire 20. En étape 1018, le calculateur embarqué client 10 envoie une requête de d’installation au calculateur destinataire 20 via le bus embarqué 5. A partir de l’étape 2002 de stockage exécuté dans le calculateur destinataire 20, une transition 2003 est validée lorsque le calculateur destinataire 20 reçoit la requête d’installation émise par le calculateur embarqué client 10 à l’étape 1018. Une validation de la transition 2003 fait passer le procédé dans une étape 2004 qui consiste pour le calculateur destinataire 20 à installer directement pour lui-même le contenu numérique préalablement stocké dans sa mémoire tampon interne, puis notamment à notifier au calculateur client 10 l’achèvement de l’installation. Par installer on entend préparer à l’activation future, c’est-à-dire en l’espèce si le calculateur destinataire 20 est double banque on y copie le contenu numérique nouveau dans la banque inactive, et si le calculateur ne dispose que de mémoire tampon il n’y a rien de plus à faire. A partir de l’étape 1018 de requête d’installation exécutée dans le calculateur client 10, une transition 1019 est validée lorsque l’installation terminée est signalée au calculateur client 10 par le calculateur embarqué destinataire 20 via le bus 5, notamment au moyen de la réception de la notification d’achèvement d’installation émise par le calculateur destinataire 20. L’installation du contenu numérique dans le calculateur destinataire 20 est donc achevée. La validation de la transition 1019 fait passer le procédé dans une étape 1020 qui consiste à vérifier s’il existe ou non un autre contenu numérique à installer dans le système numérique. S’il existe un autre contenu numérique à installer dans le système numérique, c’est-à-dire sur un calculateur embarqué 11, 21, 22, la transition 1021 est validée lorsqu’un autre contenu numérique à installer est détecté dans la liste des contenus numériques téléchargés. La validation de la transition 1021 fait reboucler le procédé à l’étape 1016. S’il n’existe pas d’autre contenu numérique à installer dans le système numérique, c’est-à-dire qu’on vient d’installer le dernier contenu numérique de la liste des contenus numériques téléchargés, la transition 1023 est validée et fait passer le procédé dans une étape 1024 qui consiste à passer en phase de vérification des conditions d’activation des contenus numériques de la campagne de mise à jour en cours envoi d’une notification de fin d’installation au module de gestion des configurations dynamiques HMI-proxy. Cette requête au HMI-proxy déterminera les conditions d’activation requises en fonction des contenus numériques et/ou des calculateurs, c’est-à-dire par exemple le besoin ou non d’accord utilisateur, conditions dynamiques prédéfinies en amont, notamment à la création de la campagne. Après cette phase de distribution et d’installation pour un premier type de calculateur, le calculateur 10 retourne en étape de veille du procédé, il peut s’agir d’une attente de fin de mission ou par exemple d’une attente de fin de mission combinée à un accord utilisateur notamment, mais on ne pourra pas retourner en phase de distribution tant que le procédé n’est pas achevé, c’est-à-dire tant que la campagne de mise à jour ne sera pas terminée. montre des étapes de procédé conforme à l’invention pour effectuer une distribution et une installation de contenu numérique à l’intérieur du système numérique (on board en anglais) à partir du calculateur embarqué client 10. Les étapes à présent décrites sont également exécutées déconnectées du monde extérieur (off board en anglais). Plus précisément, la phase de distribution et d’installation illustrée par la figure 4 sont effectuées en vue de mettre à jour un deuxième type de calculateur embarqué 30 correspondant à un calculateur indirectement connecté au calculateur embarqué client 10 au travers du calculateur passerelle 21 et équipé de ressources informatiques suffisantes pour traiter le contenu téléchargé qui lui est destiné, en l’espèce l’un des calculateurs embarqués 31, 32, 33 connectés au deuxième bus embarqué 6. Consécutivement à l’étape 1014 d’envoi d’accusé de bonne réception du procédé exécuté dans le calculateur embarqué 10, une transition 1015 est validée lorsque l’existence d’un contenu numérique complet pour mettre à jour un calculateur embarqué, est signalée en mémoire du calculateur embarqué client 10 et que le véhicule 4 est en conditions satisfaisantes pour effectuer une distribution et une installation de contenu numérique à l’intérieur du système numérique. Comme déjà mentionné, ce contenu numérique complet prend notamment la forme d’une liste des contenus numériques téléchargés, sachant que l’enchaînement des contenus dans la liste n’a pas d’ordre nécessairement lié aux types de calculateurs. Les deux phases du procédé relatives à la distribution et à l’installation de contenus numériques dans un ou plusieurs calculateurs embarqués, ne nécessitant pas de connexion avec l’extérieur, le véhicule 4 est en conditions satisfaisantes lorsque le véhicule 4 est à même d’alimenter les calculateurs du système numérique concernés par la distribution et l’installation de contenu, c’est-à-dire par exemple de maintenir un niveau suffisant de charge des batteries, moteur à combustion interne tournant pour un véhicule thermique, batteries branchées sur une station de charge pour un véhicule électrique. Une validation de la transition 1015 fait passer le procédé dans une étape 1016 dans laquelle le calculateur embarqué client 10 distribue un premier contenu numérique téléchargé en mémoire tampon interne vers le calculateur embarqué 21. En étape 1016, le calculateur embarqué client 10 commence par définir le calculateur embarqué destinataire du contenu numérique par lecture des données descriptives du contenu, puis envoie une requête de distribution au calculateur embarqué destinataire 21 puis commence à lui distribuer le contenu numérique. En effet, ici le calculateur cible devant être mis à jour par ce contenu numérique est du deuxième type 30, à savoir l’un des calculateurs 31, 32, 33 sur le bus embarqué 6 et relié au calculateur client 10 via le calculateur passerelle 21 et de fait le calculateur destinataire du contenu numérique est identifié comme étant le calculateur passerelle 21. Parallèlement, dans le calculateur passerelle 21, une transition 2101 est validée lorsqu’il 21 reçoit la requête de distribution émise par le calculateur embarqué client 10 à l’étape 1016 de distribution. A titre illustratif, le calculateur embarqué client 10 peut par exemple utiliser les protocoles CAN, FTP, Ethernet, pour distribuer le contenu numérique au calculateur passerelle 21, en l’espèce via le bus 5 embarqué, indépendamment du niveau de connectivité à un réseau de télécommunication puisque ces étapes sont exécutées déconnectées du monde extérieur. Une validation de la transition 2101 fait passer le procédé dans une étape 2102 qui consiste à stocker le contenu numérique dans le calculateur passerelle 21. Parallèlement à l’étape 1016 de distribution du contenu numérique exécutée par le calculateur client 10, l’étape 2102 de stockage du contenu numérique est exécutée dans le calculateur passerelle 21, il s’agit de stocker en mémoire tampon interne du calculateur passerelle 21 les fichiers ou trames reçues du calculateur client 10 via le bus embarqué 5. Parallèlement, à partir de l’étape 1016 de distribution du procédé exécuté dans le calculateur client 10, une transition 1017 est validée lorsque l’achèvement de la distribution du contenu numérique au calculateur destinataire passerelle 21 est signalé au calculateur client 10 par le calculateur passerelle 21, en l’espèce via le bus 5. Une validation de la transition 1017 fait passer le procédé dans une étape 1018 qui consiste à envoyer une requête d’installation au calculateur cible 30. En étape 1018, le calculateur embarqué client 10 envoie une requête de d’installation au calculateur destinataire passerelle 21, en l’espèce via le bus embarqué 5. En effet ce contenu numérique apparait d’après ses données descriptives comme un contenu destiné au calculateur passerelle 21, le calculateur client 10 n’est donc pas en liaison directe avec le calculateur cible, mais avec le calculateur passerelle 21 et ce dernier activera les calculateurs 30 comme expliqué par la suite. A partir de l’étape 2102 de stockage exécuté dans le calculateur passerelle 21, une transition 2103 est validée lorsque le calculateur passerelle 21 a reçu la requête d’installation envoyée à l’étape 1018. La validation de la transition 2103 fait donc passer le procédé dans une étape 2104 dans laquelle le calculateur embarqué passerelle 21 définit le calculateur cible 30 du contenu (en fonction des données descriptives du contenu sécurisé) et lui 30 distribue le contenu numérique qu’il 21 avait stocké en mémoire tampon interne. En étape 2104, le calculateur embarqué destinataire passerelle 21 commence par envoyer une requête de distribution au calculateur cible 30 défini, en l’espèce via le bus embarqué 6, puis commence à distribuer le contenu numérique vers ce calculateur cible 30. En effet, ici le calculateur cible devant être mis à jour par ce contenu numérique est du premier type 30, à savoir l’un des calculateurs 31, 32, 33 relié au calculateur passerelle 21, notamment via le bus embarqué 6. Parallèlement, à partir d’une étape de veille du procédé exécuté dans le calculateur embarqué cible 30, une transition 3001 est validée lorsque le calculateur passerelle 30 reçoit la requête de distribution émise par le calculateur passerelle 21 à l’étape 2104 de distribution. A titre illustratif, le calculateur embarqué passerelle 21 peut utiliser les protocoles CAN, FTP, Ethernet pour distribuer le contenu numérique au calculateur cible 30 via le bus 6 embarqué, indépendamment du niveau de connectivité à un réseau de télécommunication puisque ces étapes sont exécutées déconnectées du monde extérieur. Une validation de la transition 3001 fait passer le procédé dans une étape 3002 qui consiste à stocker le contenu numérique dans le calculateur cible 30. Parallèlement à l’étape 2104 de distribution du contenu numérique exécutée par le calculateur passerelle 21, l’étape 3002 de stockage du contenu numérique est exécutée dans le calculateur cible 30, il s’agit de stocker en mémoire interne inactive en cas de calculateur cible 30 double banque et sinon en mémoire externe du calculateur cible 30 les fichiers ou trames reçues du calculateur passerelle 21, en l’espèce via le bus embarqué 6. Il convient de noter que le stockage en mémoire externe n’occupe pas toute la mémoire externe, mais qu’une partie de la mémoire externe, ce qui permet d’avoir à la fois en mémoire externe du calculateur destinataire le contenu numérique courant, c’est-à-dire d’une version passée (mais toujours actif à cette étape du procédé), celui-ci n’étant pas effacé, et ce nouveau contenu numérique de la mise à jour. Ce stockage en mémoire externe du contenu passé permettra dans la suite du procédé, lors de la phase d’activation, une sauvegarde pour un éventuel retour en arrière si nécessaire. A partir de l’étape 2104 de distribution du procédé exécuté dans le calculateur passerelle 21, une transition 2105 est validée lorsque la distribution du contenu numérique terminée est signalée au calculateur passerelle 21 par le calculateur embarqué cible 30, en l’espèce via le bus 6. Une validation de la transition 2105 fait passer le procédé dans une étape 2106 qui consiste pour le calculateur passerelle 21 à envoyer une requête d’installation du calculateur cible vers le calculateur cible 30. En étape 2106, le calculateur embarqué passerelle 21 envoie une requête d’installation du calculateur cible au calculateur cible 30 en l’espèce via le bus embarqué 6. A partir de l’étape 3002 de stockage exécuté dans le calculateur cible 30, une transition 3003 est validée lorsque le calculateur cible 30 reçoit la requête d’installation du calculateur cible émise par le calculateur passerelle 21 à l’étape 2106. Une validation de la transition 3003 fait passer le procédé dans une étape 3004 d’installation qui consiste pour le calculateur cible 30 à se constituer une sauvegarde du contenu courant en copiant, soit, en fonction de la nature de la mémoire du calculateur 30, les éléments manquants, à savoir ceux du contenu courant qui ne changent pas avec la mise à jour, dans la banque inactive dans le cas d’une mémoire interne double banque, soit, en cas de mémoire externe, en copiant l’intégralité du contenu numérique courant en mémoire externe du calculateur cible 30, puis notamment à notifier au calculateur passerelle 21 l’achèvement de l’installation. Par installer on entend préparer à l’activation future, et notamment pour un calculateur de deuxième type 30 à mémoire externe, il s’agit d’y sauvegarder le contenu courant pour permettre un éventuel retour en arrière. En effet, en cas de double banque une simple commutation suffit et permet de ne pas avoir à sauvegarder par copie tierce. De fait, si le calculateur cible 30 est double banque on copie dans la banque inactive les éléments du contenu courant du calculateur 30 présents dans la banque active qui n’ont pas fait l’objet de la mise à jour et ne figuraient donc pas dans les nouveaux contenus numériques, et si le calculateur cible 30 ne dispose que de mémoire externe on y copie l’ensemble des éléments du contenu courant du calculateur 30 (présents dans la mémoire active courante). A partir de l’étape 2106 d’installation exécutée par le calculateur passerelle 21, une transition 2107 est validée lorsque l’installation terminée est signalée au calculateur passerelle 21 par le calculateur embarqué cible 30, en l’espèce via le bus 6, notamment au moyen de la réception de la notification d’achèvement d’installation émise par le calculateur cible 30. L’installation du contenu numérique dans le calculateur cible 30 est donc achevée sans erreur. Une validation de la transition 2107 fait passer le procédé dans une étape 2108 qui consiste à envoyer, en fonction de la notification d’achèvement d’installation, au calculateur client 10 le statut (correct ou incorrect) de l’installation de du calculateur cible 30. Après envoi du statut le calculateur passerelle 21 retourne en étape de veille du procédé. A partir de l’étape 1018 d’installation exécutée par le calculateur client 10, une transition 1019 est validée à la réception du statut correct d’installation émis par le calculateur passerelle 21. La validation de la transition 1019 fait passer le procédé dans une étape 1020 qui consiste à vérifier s’il existe ou non un autre contenu numérique à installer dans le système numérique. S’il existe un autre contenu numérique à installer dans le système numérique, c’est-à-dire sur un calculateur embarqué quel qu’il soit 20, 30, 23, la transition 1021 est validée lorsqu’un autre contenu numérique à installer est détecté dans la liste des contenus numériques téléchargés. La validation de la transition 1021 fait reboucler le procédé à l’étape 1016. S’il n’existe pas d’autre contenu numérique à installer dans le système numérique, c’est-à-dire qu’on vient d’installer le dernier contenu numérique de la liste des contenus numériques téléchargés, la transition 1023 est validée et fait passer le procédé dans une étape 1024 qui consiste à passer en phase de vérification des conditions d’activation des contenus numériques de la campagne de mise à jour en cours par envoi d’une notification de fin d’installation au module de gestion des configurations dynamiques HMI-proxy. Comme précédemment décrit en figure 3, cette requête au HMI-proxy déterminera les conditions d’activation requises en fonction des contenus numériques et/ou des calculateurs, c’est-à-dire par exemple le besoin ou non d’accord utilisateur. Après cette phase de distribution et d’installation pour un deuxième type de calculateur, le calculateur 10 retourne en étape de veille du procédé, il s’agit donc d’une attente des conditions d’activation, mais on ne pourra pas retourner en phase de distribution tant que le procédé n’est pas achevé, c’est-à-dire tant que la campagne de mise à jour ne sera pas terminée. illustre schématiquement le procédé conforme à l’invention pour effectuer une distribution et une installation de contenu numérique à l’intérieur du système numérique (on board en anglais) à partir du calculateur embarqué client 10. Comme précédemment, les étapes à présent décrites sont exécutées déconnectées du monde extérieur (off board en anglais). Plus précisément, la phase de distribution et d’installation objet de la figure 5 est effectuée en vue de mettre à jour un troisième type de calculateur embarqué 23 de type hybride correspondant au calculateur embarqué 23, qui en l’espèce est un afficheur. Ce troisième type de calculateur se dénomme hybride car il comporte deux processeurs et que chaque processeur est considéré comme un calculateur de type différent, tel que représenté sur la figure. Ainsi un premier processeur est un calculateur du premier type et est connecté au calculateur embarqué client 10 en l’espèce via la liaison sécurisée 7 (le bus embarqué 5 reliant le calculateur hybride 23 au calculateur client 10, n’est pas utilisé ici, mais pourrait représenter une variante) dont le port côté premier processeur est sécurisé, et le deuxième processeur est un calculateur du deuxième type et est connecté au calculateur embarqué passerelle 21 via le bus 8. Il convient de noter que préférentiellement, pour des raisons de sécurité, et tel que présenté ici la liaison directe 7 n’est pas toujours ouverte, c’est-à-dire qu’avantageusement le port de communication sécurisé situé sur le premier processeur est par défaut fermé, empêchant toute communication de données par cette liaison. En outre, ce calculateur hybride 23 pourrait comporter d’autres parties. Ce calculateur hybride 23 est équipé de ressources informatiques suffisantes pour traiter le contenu téléchargé qui lui est destiné. De par sa structure la phase de distribution et d’installation de contenu dans un calculateur hybride 23 met en œuvre les étapes afférentes telles que décrites précédemment pour un calculateur de premier type, en figure 3, et un calculateur de deuxième, en figure 4, la mise à jour comporte donc deux contenus numériques téléchargés distincts caractérisés chacun par ses données descriptives distinctes. Ainsi, le premier contenu, sécurisé, désignera un calculateur destinataire 23, comme s’il était de premier type, et le second contenu un calculateur destinataire passerelle pour une mise à jour du calculateur cible 23, comme s’il était de deuxième type. Il est commencé par le second contenu, la flèche en trait plein entre le calculateur client 10 et le calculateur passerelle 21 représente les échanges entre ces deux calculateurs lors de la phase de distribution et d’installation du second contenu pour laquelle le calculateur passerelle 21 est destinataire alors que le calculateur hybride 23 est cible. De même, la flèche en trait plein entre le calculateur passerelle 21 et le calculateur hybride 23 représente les échanges entre ces deux calculateurs lors de la phase de distribution et d’installation du second contenu pour laquelle le calculateur passerelle 21 est destinataire alors que le calculateur hybride 23 est cible. Les étapes de procédé dont il est question sont donc à l’image de celles mises en œuvre pour un calculateur de deuxième type telles que décrites en figure 4. Ce calculateur étant de troisième type, à l’issue de l’installation de ce second contenu, il est procédé à une étape intermédiaire dans laquelle le second processeur envoie une requête d’ouverture du port sécurisé au premier processeur, en interne du calculateur hybride 23. Cet envoi de requête d’ouverture est illustré par la flèche en trait pointillé entre le calculateur passerelle 21 et le calculateur hybride 23. Une fois le port ouvert, la suite des étapes de la phase de distribution et d’installation du premier contenu peuvent alors se dérouler comme précédemment décrites en figure 3, en l’espèce via la liaison 7. La flèche en trait plein entre le calculateur client 10 et le premier processeur du calculateur hybride 23 représente la phase de distribution et d’installation du premier contenu dans la première partie de la mémoire externe du calculateur hybride 23 en tant que calculateur destinataire et cible. Les étapes de procédé dont il est question sont donc à l’image de celles mises en œuvre pour un calculateur de premier type telles que décrites en figure 3. A l’issue de la phase de distribution et d’installation, chaque calculateur cible est à jour, ce qui signifie donc pour un calculateur du premier type qu’il comporte le nouveau contenu numérique dans sa banque inactive interne ou dans sa mémoire tampon et pour un calculateur du deuxième type qu’il comporte le nouveau contenu numérique dans sa mémoire externe ou dans sa banque inactive interne, et donc les deux à la fois dans le cas d’un calculateur du troisième type. montre des étapes de procédé conforme à l’invention pour effectuer l’activation d’un calculateur embarqué cible du premier type après installation. Les étapes à présent décrites sont également exécutées déconnectées du monde extérieur (off board en anglais). Plus précisément, la phase d’activation illustrée par la figure 6 est effectuée en vue de mettre à jour un premier type de calculateur embarqué 20 correspondant à l’un des calculateurs embarqués 11, 21, 22 directement connecté sur le bus embarqué 5 sur lequel est connecté le calculateur embarqué client 10, et équipés chacun de ressources informatiques suffisantes pour traiter le contenu téléchargé qui lui est destiné. Consécutivement à l’étape 1024 d’envoi d’une notification de fin d’installation des contenus numériques de la campagne de mise à jour du procédé exécuté dans le calculateur embarqué 10, une transition 1025 est validée lorsque le véhicule 4 est dans les conditions d’activation requises par la campagne de mise à jour. Ces conditions sont déterminées par le module de gestion des configurations dynamiques HMI-proxy, sur la base des données descriptives (métadonnées) envoyées au module de gestion des configurations dynamiques HMI-proxy. Par exemple, chaque calculateur a ses propres conditions d’activations, parmi lesquelles certaines sont communes (fin de mission) et certaines plus précises (accord utilisateur : foreground) notamment dans le cas des calculateurs du deuxième type 30. Une condition satisfaisante pour effectuer l’activation de la mise à jour du calculateur du premier type 20 peut être générée par le fait pour le véhicule 4 d’être en fin de mission, c’est-à-dire que le moteur vient d’être arrêté. Une validation de la transition 1025 fait passer le procédé dans une étape 1026 qui consiste à déclencher l’activation du calculateur embarqué cible (et destinataire à la fois, puisque ce calculateur est du premier type) 20. En étape 1026, le calculateur embarqué client 10 commence par définir le calculateur embarqué cible 20 par lecture du contenu numérique caractérisé par ses données descriptives qui contiennent cette indication, puis à émettre une requête d’activation au calculateur embarqué cible 20. En effet, ici le calculateur cible devant être mis à jour par ce contenu numérique est du premier type 20, à savoir l’un des calculateurs 11, 21, 22 relié au calculateur client 10 directement via le sur le bus embarqué 5 et de fait le calculateur cible du contenu numérique, donc à activer, est identifié comme étant le calculateur cible en question 11, 21, 22. Parallèlement, dans le calculateur destinataire 20, postérieurement à l’étape 2004 d’installation directement pour lui-même du calculateur embarqué cible 20, une transition 2011 est validée lorsque le calculateur embarqué cible 20 reçoit la requête d’activation émise par le calculateur embarqué client 10 à l’étape 1026 de déclenchement d’activation. A titre illustratif, le calculateur embarqué client 10 peut utiliser les protocoles CAN, FTP, Ethernet pour émettre la requête d’activation au calculateur destinataire 20 via le bus 5 embarqué, indépendamment du niveau de connectivité à un réseau de télécommunication puisque ces étapes sont exécutées déconnectées du monde extérieur. Une validation de la transition 2011 fait passer le procédé dans une étape 2012 qui consiste à activer le contenu numérique installé à l’étape 3004 dans le calculateur destinataire 20, puis notamment à notifier au calculateur client 10 l’achèvement de l’activation, sachant que cette notification peut être une notification de réussite ou une notification d’échec de l’activation. Par activer, il est entendu, pour un calculateur du premier type, passer du contenu courant au nouveau contenu par commutation en cas de double banque et sinon par mise à jour de la mémoire courante interne en cas de mémoire tampon interne. En l’espèce cette notification est acheminée au moyen du bus 5. A partir de l’étape 1026 de déclenchement d’activation exécutée par le calculateur client 10, une transition 1027 est validée lorsque le rapport d’activation réussie du contenu numérique, émise par le calculateur embarqué cible 20 à l’étape 2012, est reçue par le calculateur client 10. Une validation de la transition 1027 fait passer le procédé dans une étape 1028 qui consiste à générer un rapport interne d’activation afférent au contenu numérique activé en question et à vérifier s’il existe ou non un autre contenu numérique à installer dans le système numérique. A partir de l’étape 1028 exécutée dans le calculateur client 10, une transition 1029 est validée s’il existe un autre contenu numérique à installer dans le système numérique, c’est-à-dire sur un calculateur embarqué 11, 21, 22, 30, 31, 32, 33 quel qu’il soit. La transition 1029 est donc validée lorsqu’un tel autre contenu numérique à installer est détecté dans la liste des contenus numériques téléchargés. La validation de la transition 1029 fait reboucler le procédé à l’étape 1026. S’il n’existe pas d’autre contenu numérique à installer dans le système numérique, c’est-à-dire qu’on vient d’installer le dernier contenu numérique de la liste des contenus numériques téléchargés, la transition 1030 est validée et fait passer le procédé dans une étape 1031 qui consiste pour le calculateur client 10 à envoyer une notification de fin de campagne de la mise à jour en cours au calculateur cible 20. C’est donc après l’activation réussie de tous les calculateurs cibles 20, 30, 23 de la liste, qu’est envoyée cette notification de fin de campagne à chacun des calculateurs cibles 20, 30, 23. Chacun des calculateurs (sauf le dernier) a donc attendu en veille de recevoir cette notification qui confirme la réussite de toutes les activations de la campagne de mise à jour. En effet, cette notification ne peut pas être émise avant au cas où un des calculateurs ne réussirait pas son activation, comme cela sera expliqué par la suite. A partir de l’étape 2012 d’activation exécutée et réussie par le calculateur cible 20, une transition 2013 est validée lorsque le calculateur cible 20 reçoit la notification de fin de campagne envoyée par le calculateur client 10 à l’étape 1031. Une validation de la transition 2013 fait passer le procédé dans une étape 2014 qui consiste à effacer le contenu numérique passé, désormais inactif à cette étape du procédé, et une fois cet effacement achevé à notifier le calculateur client 10 du statut « prêt pour une nouvelle mise à jour » du calculateur cible 20. A partir de l’étape 1031 d’envoi de notification de fin de campagne exécutée dans le calculateur client 10, une transition 1032 est validée lorsque le calculateur client 10 a reçu toutes les notifications de statut « prêt » envoyées par chaque calculateur cible 20 ou destinataire 30 à l’étape 2014 ou 2114. Une validation de la transition 1032 fait passer le procédé dans une étape 1033 qui consiste à générer un rapport global de réussite de campagne, le rapport généré étant mis à jour par agrégations successives à chaque statut « prêt » de calculateur cible 20 ou destinataire 21. Une fois que toutes les notifications de chaque calculateur 20, 30, 23 de la liste auront été envoyées, le rapport global généré à cette étape 2014 sera complet, ce rapport étant ensuite transmis au serveur distant 101 ou 102 (non représenté sur la figure 6). En revanche dès qu’une activation se solde par un échec à l’étape 2012 pour un calculateur cible 20, à la suite de l’étape 1026 de déclenchement d’activation exécutée par le calculateur client 10, une transition 1034 est validée lorsque la notification d’échec d’activation du contenu numérique, émise par le calculateur embarqué cible 20 à l’étape 2012, est reçue par le calculateur client 10. Une validation de la transition 1034 fait passer le procédé dans une étape 1035 qui consiste à déclencher un retour en arrière général de tous les calculateurs du système numérique faisant l’objet de la campagne de mise à jour. Par retour en arrière général, on entend retour à l’état initial avant le début de la campagne. En étape 1035, le calculateur embarqué client 10 commence par définir tous les calculateurs embarqués destinataires faisant l’objet de la campagne de mise à jour, puis à émettre une requête de retour en arrière à chacun de ces calculateurs embarqués destinataires 20, 21, 23 définis. En l’espèce, le calculateur cible défini et devant donc effectuer le retour en arrière est du premier type 20, à savoir l’un des calculateurs 11, 21, 22 relié au calculateur client 10 directement via le sur le bus embarqué 5. Parallèlement, dans le calculateur destinataire 20, la transition 2015 est validée lorsque le calculateur embarqué cible 20 reçoit la requête de retour en arrière émise par le calculateur embarqué client 10 à l’étape 1035. En l’espèce cette notification est acheminée au moyen du bus 5. Il convient de rappeler qu’à cette étape du procédé est encore présent en mémoire externe du calculateur cible 20 le contenu numérique passé (qui est désormais inactif si l’activation du nouveau contenu, de remplacement, a réussi, et toujours actif sinon), celui-ci n’étant pas effacé, et le nouveau contenu numérique de la mise à jour, désormais activé si son activation a réussi. Une validation de la transition 2015 fait passer le procédé dans une étape 2016 qui consiste à effectuer le retour en arrière, c’est-à-dire à réactiver le contenu numérique passé, rendant donc inactif le contenu numérique nouveau s’il ne l’était pas déjà, et une fois ce retour en arrière achevé à le notifier au calculateur client 10. A partir de l’étape 1035 de déclenchement de retour en arrière exécutée dans le calculateur client 10, une transition 1036 est validée lorsque le calculateur client 10 reçoit la notification d’achèvement de retour en arrière envoyée par le calculateur cible 20 à l’étape 2016. Une validation de la transition 1036 fait passer le procédé dans une étape 1037 qui consiste à générer un rapport d’échec de campagne puis une fois ce rapport complet à notifier au calculateur cible 20 la fin de campagne, le rapport généré étant mis à jour par agrégations successives à chaque calculateur cible 20 ayant effectué son retour en arrière. Une fois que toutes les notifications de tous les calculateurs cibles définis à l’étape 1035 auront été reçues, le rapport d’échec de campagne généré à cette étape 1037 sera complet, et ta notification de fin de campagne envoyée à chacun des calculateurs cibles définis à l’étape 1035. Parallèlement, dans le calculateur destinataire 20, la transition 2017 est alors validée lorsque le calculateur embarqué cible 20 reçoit la notification de fin de campagne émise par le calculateur embarqué client 10 à l’étape 1037. En l’espèce cette notification est acheminée au moyen du bus 5. Il convient de rappeler qu’à cette étape du procédé sont encore présents en mémoire externe du calculateur cible 20, le contenu numérique passé réactivé et le nouveau contenu numérique inactif. Une validation de la transition 2017 fait passer le procédé dans une étape 2018 qui consiste à effacer le contenu numérique nouveau de la mise à jour, désormais inactif à cette étape du procédé, pour ne garder donc que le contenu passé réactivé, et une fois cet effacement achevé à notifier le calculateur client 10 du statut « prêt pour une prochaine campagne » du calculateur cible 20. A partir de l’étape 1037 exécutée dans le calculateur client 10, une transition 1038 est validée lorsque le calculateur client 10 reçoit la notification de statut « prêt pour une prochaine campagne » envoyée par le calculateur cible 20 à l’étape 2018. Une validation de la transition 1038 fait passer le procédé dans une étape 1039 qui consiste à générer un rapport global d’échec de campagne, ce rapport une fois complet, étant alors transmis au serveur distant 101 ou 102 (non représenté sur la figure 6). Le rapport global d’échec de campagne généré à l’étape 1039 est mis à jour par agrégations successives des notifications reçues de chaque calculateur définis à l’étape 1035. Une fois que toutes les notifications de chaque calculateur 20, 21 (pour la passerelle 21 plusieurs notifications sont possibles puisque la mise à jour pouvait comprendre des contenus destinés à la passerelle en tant que telle (pour elle-même en tant que passerelle) et des contenus ayant une cible 30 ou 23), 23 définis à l’étape 1035 auront été envoyées, le rapport global généré à cette étape 1039 sera alors complet. Après cette phase d’activation, réussie ou non, pour un premier type de calculateur, le calculateur client 10 retourne en étape de veille du procédé, de même pour le calculateur cible 20, puis s’éteindront. montre des étapes de procédé conforme à l’invention pour effectuer l’activation d’un calculateur embarqué cible du deuxième type après installation. Les étapes à présent décrites sont également exécutées déconnectées du monde extérieur (off board en anglais). Plus précisément, la phase d’activation illustrée par la figure 7 est effectuée en vue de mettre à jour un deuxième type de calculateur embarqué 30 correspondant à l’un des calculateurs embarqués 31, 32, 33 connecté au calculateur embarqué passerelle 21, en l’espèce via le bus 6, et équipés chacun de ressources informatiques suffisantes pour traiter le contenu téléchargé qui lui est destiné. Consécutivement à l’étape 1024 d’envoi d’une notification de fin d’installation des contenus numériques de la campagne de mise à jour du procédé par le calculateur embarqué 10 au module de gestion des configurations dynamiques, aussi appelé HMI proxy, localisé dans l’interface homme machine 12, qui peut elle-même être une partie du calculateur client 10, une transition 1025 est validée lorsque le véhicule 4 est dans les conditions d’activation requises par la campagne de mise à jour tel que défini pour ce contenu numérique dans le module de gestion. Ces conditions sont issues des données descriptives pré téléchargées caractérisant chaque contenu numérique, tel que décrit précédemment. Par exemple, une condition satisfaisante pour effectuer l’activation de la mise à jour du calculateur du deuxième type 30 peut, comme précédemment décrit en figure 6, être générée par le fait pour le véhicule 4 d’être en fin de mission et une fois en fin de mission d’avoir demandé puis obtenu l’accord de l’utilisateur au moyen d’un bouton virtuel affiché sur l’IHM 12. En effet, cette demande utilisateur est préférée pour ce deuxième type de calculateur 30 car leur mise à jour est moins instantanée et nécessite de bloquer le redémarrage du moteur, ce qui nécessite d’alerter l’utilisateur. Ainsi, une fois l’accord utilisateur obtenu, on interdit le redémarrage moteur. Une validation de la transition 1025 fait passer le procédé dans une étape 1026 qui consiste à déclencher l’activation du calculateur embarqué destinataire du contenu, à savoir le calculateur passerelle 21 puisque la cible est ici un calculateur de deuxième type 30 c’est-à-dire situé en zone sécurisée derrière la passerelle. En étape 1026, le calculateur embarqué client 10 commence par définir le calculateur embarqué destinataire 21 par lecture du contenu numérique téléchargé caractérisé par ses données descriptives qui contiennent cette indication, puis à émettre une requête d’activation au calculateur embarqué destinataire, ici passerelle 21. En effet, ici le calculateur cible devant être mis à jour par ce contenu numérique est du deuxième type 30, situé derrière la passerelle, le destinataire identifié du contenu numérique est donc la passerelle, le calculateur client 10 ignorant que la cible est un calculateur du deuxième type, à savoir l’un des calculateurs 31, 32, 33 et de fait le calculateur destinataire à qui envoyer la requête d’activation est identifié comme étant le calculateur passerelle 21. Parallèlement, dans le calculateur destinataire passerelle 21, postérieurement à l’étape 2108 d’envoi du rapport, une transition 2111 est validée lorsque le calculateur passerelle 21 reçoit la requête d’activation émise par le calculateur embarqué client 10 à l’étape 1026 de déclenchement d’activation. A titre illustratif, le calculateur embarqué client 10 peut utiliser les protocoles CAN, FTP, Ethernet pour envoyer cette requête au calculateur destinataire 21 via le bus 5 embarqué, indépendamment du niveau de connectivité à un réseau de télécommunication puisque ces étapes sont exécutées déconnectées du monde extérieur. Une validation de la transition 2111 fait passer le procédé dans une étape 2112 qui consiste essentiellement à déclencher l’activation du calculateur embarqué cible 30. En étape 2112, le calculateur embarqué passerelle 21 commence par définir le calculateur embarqué cible 30, en l’espèce par lecture de la liste de téléchargement qui prend par exemple la forme d’une table avec pour chaque ligne de calculateur le statut de la mise à jour, puis à émettre une requête d’activation au calculateur embarqué cible 30. En effet, ici le calculateur cible devant être mis à jour, c’est-à-dire dont le contenu numérique doit être activé, est du deuxième type 30, à savoir l’un des calculateurs 31, 32, 33 relié indirectement au calculateur client 10 via le calculateur passerelle 21. Parallèlement, à partir d’une étape de veille du procédé exécuté dans le calculateur embarqué cible 30 postérieure à l’étape 3004 d’installation, une transition 3011 est validée lorsque le calculateur passerelle 30 reçoit la requête d’activation émise par le calculateur passerelle 21 à l’étape 2112. Une validation de la transition 3011 fait passer le procédé dans une étape 3012 qui consiste à activer le contenu numérique installé à l’étape 3004 dans le calculateur cible 30, puis notamment à notifier au calculateur passerelle 21 l’achèvement de l’activation, sachant que cette notification peut être une notification de réussite ou une notification d’échec de l’activation. L’activation consiste dans le cas de mémoire interne double banques à switcher de la banque active (courante) à la l’autre (contenant le nouveau contenu numérique) banque et dans le cas d’une mémoire externe à transférer le nouveau contenu numérique depuis la mémoire externe vers la mémoire interne. Il convient de rappeler que si c’est une mémoire externe dont dispose le calculateur 30, à cette étape du procédé le contenu numérique passé est toujours présent en mémoire externe (que l’activation du nouveau contenu, de remplacement, ait réussi ou non), celui-ci n’étant pas effacé, et si l’activation a réussi, ce nouveau contenu numérique, est aussi en mémoire active interne. Si le calculateur cible 30 dispose d’une mémoire interne double banque, par exemple EEPROM réinscriptible, cette mémoire contient dans la partie active le nouveau contenu ainsi que tout ce qui lui a été ajouté à l’étape 3004 et dans la partie inactive le contenu passé. En l’espèce, cette notification est acheminée au moyen du bus 6, par exemple par protocole FTP, CAN, Ethernet. La réception de cette notification par le calculateur passerelle 21 finalise l’étape 2112 avec un renvoi par le calculateur passerelle 21 au calculateur client 10 de la notification de réussite ou une notification d’échec de l’activation, le calculateur passerelle jouant ici un rôle de boîte aux lettres. A partir de l’étape 1026 de déclenchement d’activation exécutée par le calculateur client 10, une transition 1027 est validée lorsqu’une notification de réussite de l’activation notifiée par le calculateur passerelle 21 à l’étape 2112, est reçue par le calculateur client 10. Une validation de la transition 1027 fait passer le procédé dans une étape 1028 qui consiste à générer un rapport interne d’activation, qui sera complété à chaque réception de notification afférente à un nouveau contenu numérique activé, et à vérifier s’il existe ou non un autre contenu numérique à installer dans le système numérique. A partir de l’étape 1028 exécutée dans le calculateur client 10, une transition 1029 est validée s’il existe un autre contenu numérique à installer dans le système numérique, c’est-à-dire sur un calculateur embarqué quel qu’il soit. La transition 1029 est donc validée lorsqu’un autre contenu numérique à installer est détecté dans la liste des contenus numériques téléchargés. La validation de la transition 1029 fait reboucler le procédé à l’étape 1026. S’il n’existe pas d’autre contenu numérique à installer dans le système numérique, c’est-à-dire qu’on vient d’installer le dernier contenu numérique de la liste des contenus numériques téléchargés, la transition 1030 est validée et fait passer le procédé dans une étape 1031 qui consiste pour le calculateur client 10 à envoyer une notification de fin de campagne de la mise à jour en cours au calculateur destinataire passerelle 21. C’est donc après l’activation réussie de tous les calculateurs cibles 20, 30, 23 de la liste, qu’est envoyée cette notification de fin de campagne à chacun des calculateurs destinataires 20, 21, 23. Chacun des calculateurs (en l’espèce sauf le dernier) a donc attendu en veille de recevoir cette notification qui confirme la réussite de toutes les activations de la campagne de mise à jour. En effet, cette notification de fin de campagne ne peut pas être émise avant au cas où un des calculateurs ne réussirait pas son activation, comme cela sera expliqué par la suite. A partir de l’étape 2112 de déclenchement d’activation exécutée par le calculateur passerelle 21, une transition 2113 est validée lorsque la notification de fin de campagne, émise par le calculateur embarqué client 10 à l’étape 1031, est reçue par le calculateur passerelle 21. Une validation de la transition 2113 fait passer le procédé dans une étape 2114 qui consiste à émettre une notification de fin de campagne vers le calculateur cible 30. Parallèlement, A partir de l’étape 3012 d’activation exécutée et réussie par le calculateur cible 30, une transition 3013 est validée lorsque le calculateur cible 30 reçoit la notification de fin de campagne envoyée par le calculateur passerelle 21 à l’étape 2114. Une validation de la transition 3013 fait passer le procédé dans une étape 3014 qui consiste à effacer (que ce soit dans la banque de la mémoire inactive interne ou en mémoire externe) le contenu numérique passé, désormais inactif à cette étape du procédé, et une fois cet effacement achevé à notifier le calculateur passerelle 21 du statut « prêt pour une prochaine campagne » du calculateur cible 30. La réception de cette notification du statut « prêt pour une prochaine campagne » par le calculateur passerelle 21 finalise l’étape 2114 avec un renvoi par le calculateur passerelle 21 au calculateur client 10 du statut « prêt pour une prochaine campagne », le calculateur passerelle jouant ici un rôle de boîte aux lettres. Il convient de rappeler qu’en mémoire interne EEPROM, une banque non vidée n’est pas réinscriptible, d’où l’importance de l’effacement pour une prochaine campagne de mise à jour. A partir de l’étape 1031 d’envoi de notification de fin de campagne exécutée dans le calculateur client 10, une transition 1032 est validée lorsque le calculateur client 10 reçoit la dernière notification du statut « prêt pour une prochaine campagne » envoyée par le dernier calculateur de la liste à l’étape 2114 ou 2014. Une validation de la transition 1032 fait passer le procédé dans une étape 1033 qui consiste à générer un rapport global de réussite de campagne, le rapport généré étant mis à jour par agrégations successives à chaque statut « prêt » de calculateur cible 20 ou destinataire 21. Une fois que toutes les notifications de chaque calculateur 20, 30, 23 de la liste auront été envoyées, le rapport global généré à cette étape 2014 sera complet, ce rapport étant ensuite transmis au serveur distant 101 ou 102 (non représenté sur la figure 7). En revanche dès qu’une activation se solde par un échec à l’étape 3012 pour un calculateur cible 30, l’étape 2112 se finalise par un renvoi de notification d’échec de l’activation par le calculateur passerelle 21 au calculateur client 10 et à partir de l’étape 1026 de déclenchement d’activation exécutée par le calculateur client 10, une transition 1034 est validée dès que la notification d’échec de l’activation est reçue par le calculateur client 10. Une validation de la transition 1034 fait passer le procédé dans une étape 1035 qui consiste à déclencher un retour en arrière général de tous les calculateurs du système numérique faisant l’objet de la campagne de mise à jour. Par retour en arrière général, on entend retour à l’état initial avant le début de la campagne. En étape 1035, le calculateur embarqué client 10 commence par définir tous les calculateurs embarqués destinataires faisant l’objet de la campagne de mise à jour, puis à émettre une requête de retour en arrière à chacun de ces calculateurs embarqués destinataires 20, 21, 23 définis. En l’espèce, le calculateur cible est du second type 30 mais le calculateur client 10 sait seulement que le destinataire défini est le calculateur passerelle 21, la requête de retour est donc envoyée au calculateur passerelle 21. A partir de l’étape 2112 de déclenchement d’activation exécutée par le calculateur passerelle 21, une transition 2115 est validée lorsque la requête de retour, émise par le calculateur embarqué client 10 à l’étape 1035, est reçue par le calculateur passerelle 21. Une validation de la transition 2115 fait passer le procédé dans une étape 2116 qui consiste d’abord à déclencher le retour en arrière du calculateur cible 30 par émission d’une requête de retour en arrière au calculateur cible 30 (sera donc émise séquentiellement en suivant le procédé à chaque calculateur cible 30 défini à l’étape 1035). Parallèlement, dans le calculateur cible 30, la transition 3015 est validée lorsque le calculateur cible 30 reçoit la requête de retour en arrière émise par le calculateur passerelle 21 à l’étape 2116. En l’espèce cette requête est acheminée au moyen du bus 6. Une validation de la transition 3015 fait passer le procédé dans une étape 3016 qui consiste à effectuer le retour en arrière, rendant donc inactif le contenu numérique nouveau s’il ne l’était pas déjà, et une fois ce retour en arrière achevé à le notifier au calculateur passerelle 21 par envoi d’un rapport de retour à l’état initial. Ce retour en arrière se fait par commutation, ce qui rebascule sur l’autre banque, en cas de mémoire interne double banque et par restauration du contenu numérique sauvegardé en cas de mémoire externe. La réception de ce rapport de retour à l’état initial par le calculateur passerelle 21 finalise l’étape 2116 avec un renvoi par le calculateur passerelle 21 au calculateur client 10 du rapport de retour à l’état initial, le calculateur passerelle 21 jouant ici un rôle de boîte aux lettres. A partir de l’étape 1035 de déclenchement de retour en arrière exécutée dans le calculateur client 10, une transition 1036 est validée lorsque le calculateur client 10 reçoit le rapport de retour à l’état initial envoyé par le calculateur passerelle 21 à l’étape 2116. Une validation de la transition 1036 fait passer le procédé dans une étape 1037 qui consiste à générer un rapport d’échec de campagne qui sera complété par agrégations successives à chaque réception de rapport de retour à l’état initial (provenant de chaque calculateur défini à l’étape 1035), puis une fois que toutes les notifications de tous les calculateurs cibles définis à l’étape 1035 auront été reçues, le rapport d’échec de campagne généré à cette étape 1037 sera complet, et la notification de fin de campagne envoyée à chacun des calculateurs destinataires définis à l’étape 1035. En l’espèce, pour un calculateur de deuxième type, une fois ce rapport complet (c’est-à-dire une fois que tous les calculateurs définis à l’étape 1035 sont revenus à l’état initial) on notifie au calculateur destinataire passerelle 21 la fin de campagne. Parallèlement, dans le calculateur destinataire 21, la transition 2117 est alors validée lorsque le calculateur embarqué destinataire passerelle 21 reçoit la notification de fin de campagne émise par le calculateur embarqué client 10 à l’étape 1037. En l’espèce cette notification est acheminée au moyen du bus 5. Une validation de la transition 2117 fait passer le procédé dans une étape 2118 qui consiste d’abord à envoyer une requête d’effacement du contenu numérique nouveau de la mise à jour, désormais inactif à cette étape du procédé, pour ne garder donc que le contenu passé réactivé (initial avant la mise à jour). Parallèlement, dans le calculateur cible 30, la transition 3017 est validée lorsque le calculateur cible 30 reçoit la requête de retour en arrière émise par le calculateur passerelle 21 à l’étape 2118. En l’espèce cette requête est acheminée au moyen du bus 6. Une validation de la transition 3017 fait passer le procédé dans une étape 3018 qui consiste à effacer le nouveau contenu numérique de la mise à jour s’il ne l’était pas déjà, et une fois cet effacement achevé à le notifier au calculateur passerelle 21 par envoi d’un statut « prêt pour une prochaine campagne ». La réception de ce statut « prêt » par le calculateur passerelle 21 finalise l’étape 2118 avec un envoi par le calculateur passerelle 21 au calculateur client 10 du statut « prêt pour une prochaine campagne » du calculateur cible 30, le calculateur passerelle 21 jouant ici un rôle de boîte aux lettres. A partir de l’étape 1037 exécutée dans le calculateur client 10, une transition 1038 est validée lorsque le calculateur client 10 reçoit la notification de statut « prêt pour une prochaine campagne » envoyée par le calculateur passerelle 21 à l’étape 2118. Une validation de la transition 1038 fait passer le procédé dans une étape 1039 qui consiste à générer un rapport global d’échec de campagne, ce rapport une fois complet, étant alors transmis au serveur distant 101 ou 102 (non représenté sur la figure 7) et à relâcher l’interdiction de redémarrage. Le rapport global d’échec de campagne généré à l’étape 1039 est mis à jour par agrégations successives des notifications reçues de chaque calculateur définis à l’étape 1035. Une fois que toutes les notifications de chaque calculateur 20, 21 (pour la passerelle 21 plusieurs notifications sont possibles puisque la mise à jour pouvait comprendre des contenus destinés à la passerelle en tant que telle (pour elle-même en tant que passerelle) et des contenus ayant une cible 30 ou 23), 23 définis à l’étape 1035 auront été envoyées, le rapport global généré à cette étape 1039 sera alors complet. Après cette phase d’activation, réussie ou non, pour un deuxième type de calculateur, le calculateur client 10 retourne en étape de veille du procédé, de même pour le calculateur passerelle 21 et cible 30, puis s’éteindront. Dans le cas de la phase d’activation d’un calculateur du troisième type, c’est-à-dire hybride, la logique telle que présentée en figure 5 s’applique. Quel que soit le type de calculateur, en fin de phase d’activation réussie, le contenu numérique passé a été effacé de manière à être prêt pour une prochaine campagne et pour empêcher pour des raisons de sécurité tout retour à la version précédente. De manière générale, quand une étape du procédé ne se termine pas comme attendu, le procédé reste bloqué dans cette étape et une temporisation peut être prévue, par exemple dans le calculateur client 10 ou passerelle 21, à l’issue duquel un échec est détecté pour alors initier une remise à l’état initial de tout le système numérique, tel que défini précédemment, avec notification de l’échec au serveur. Procédé de mise à jour de système numérique dans un véhicule (4) comprenant un calculateur client embarqué (10) , notamment de type multimédia, apte à communiquer avec un serveur distant (101, 102), une unité de contrôle-commande embarquée ( 20, 11, 21, 22, 30, 31, 32, 33, 23) connectée, directement ou indirectement, au calculateur client (10) par un réseau embarqué de communication (5, 6, 7, 8), et un dispositif d’accumulation d’énergie électrique pour alimenter le calculateur embarqué (10) et ladite unité de contrôle-commande embarquée (20, 11, 21, 22, 30, 31, 32, 33, 23), caractérisé en ce qu’il comprend des étapes de : - téléchargement (1008) dans laquelle le calculateur client (10) télécharge un fichier à partir du serveur distant à condition que le dispositif d’accumulation d’énergie électrique est en état de pouvoir être rechargé ; - distribution (1016) dans laquelle le calculateur client (10) distribue, directement ou indirectement, au moins une partie du fichier téléchargé à destination de l’unité de contrôle-commande embarquée ( 20, 11, 21, 22, 30, 31, 32, 33, 23) ; - installation (2004, 3004) dans laquelle tout ou portion de ladite au moins une partie distribuée du fichier téléchargé est installée dans l’unité de contrôle-commande embarquée (20, 11, 21, 22, 30, 31, 32, 33, 23) ; - activation (2012, 3012) dans laquelle l’unité de contrôle-commande embarquée (20, 11, 21, 22, 30, 31, 32, 33, 23) active la ou les portions de fichier installées après mise à l’arrêt du véhicule. Procédé selon la revendication 1, caractérisé en ce que dans l’étape de téléchargement (1008), le calculateur client (10) mémorise constamment un point de progression du téléchargement de manière à arrêter (1010) le téléchargement lorsqu’une dégradation effective ou risquée de communication avec le serveur distant (101, 102) est détectée (1009), et reprend (1008) le téléchargement à partir du point de progression mémorisé lorsqu’il détecte (1011) une disparition de dégradation effective ou risquée de communication avec le serveur distant (101, 102). Procédé selon la revendication 2, caractérisé en ce que le dispositif d’accumulation d’énergie électrique hors d’état de pouvoir être rechargé constitue une condition de détection de dégradation risquée de communication avec le serveur distant (101, 102). Procédé selon l’une des revendications 1 à 3, caractérisé en ce que, lorsque le véhicule (4) comprend un moteur thermique, le dispositif d’accumulation d’énergie électrique est considéré en état de pouvoir être rechargé si le moteur thermique est en rotation. Procédé selon l’une des revendications 1 à 4, caractérisé en ce que, lorsque le véhicule comprend une batterie de traction électrique, le dispositif d’accumulation d’énergie électrique est considéré en état de pouvoir être rechargé si la batterie de traction électrique batterie de traction électrique est branchée sur un réseau électrique de rechargement externe. Procédé selon l’une des revendications 1 à 5, dans lequel le réseau embarqué de communication (5, 6, 7, 8) comporte une première liaison embarquée (5, 7) reliée au calculateur client (10), une deuxième liaison embarquée (6,8) reliée à l’unité de contrôle-commande embarquée (30, 31, 32, 33, 23), et un calculateur passerelle (21) relié au calculateur client (10) et à l’unité de contrôle-commande embarquée (30, 31, 32, 33, 23)), caractérisé en ce que l’étape d’installation (3004) de tout ou partie distribuée du fichier téléchargé dans l’unité de contrôle-commande embarquée (21), est exécutée par le calculateur passerelle (21). Procédé selon l’une des revendications 1 à 6, dans lequel l’unité de contrôle-commande embarquée comprend deux banques de mémoire réinscriptible exécutable, caractérisé en ce que l’unité de contrôle-commande embarquée fonctionne sur une première banque de mémoire réinscriptible pendant que l’étape d’installation est appliquée sur une deuxième banque de mémoire réinscriptible. Procédé selon au moins l’une des revendications 1 à 7, caractérisé en ce qu’il comporte une étape de pré téléchargement (1002) de données descriptives. Procédé selon la revendication précédente caractérisé en ce qu’au moins une partie des données descriptives comporte des métadonnées de configuration. Procédé selon la revendication précédente, caractérisé en ce qu’il comporte au moins une étape (1024) de vérification d’au moins une condition d’activation, ladite au moins une condition d’activation étant fonction d’au moins une partie des métadonnées de configuration. Procédé selon la revendication l’une quelconque des revendications précédentes, caractérisé en ce que l’étape d’activation (2012, 3012) nécessite un accord d’un utilisateur du véhicule pour être exécutée.