Brevet FR3145056A1 — publié le 20240719

La présente invention concerne un procédé et un dispositif de traitement (10) pour aider à mettre à jour au moins un logiciel (PG1) d’au moins un véhicule (2), ledit procédé comprenant : détermination d’un nombre N de versions (V) possibles que peut présenter ledit au moins un logiciel (PG1), N étant un entier au moins égal à 2 ; détermination d’un profil de mise à jour définissant au moins une condition à respecter par une mise à jour (OP) dudit au moins logiciel (PG1) ; détermination, à partir du nombre N et du profil de mise à jour, d’un indice de complexité (C) représentatif d’une complexité dudit au moins logiciel (PG1) ; et évaluation d’une capacité (RS) à mettre à jour ledit au moins un logiciel (PG1) par comparaison de l’indice de complexité (C) avec une valeur de référence. Figure pour l’abrégé : Figure 1 Procédé et dispositif de traitement pour la mise à jour logicielle de véhicule La présente invention concerne les procédés et dispositifs de traitement pour aider à la mise à jour d’un ou plusieurs logiciels pour véhicule, et notamment mais pas exclusivement pour des véhicules de type automobile. L’invention vise en particulier l’évaluation ou le suivi de la complexité d’au moins un logiciel implémentable dans un ou des véhicules pour aider à la mise à jour du ou des logiciels. Arrière-plan technologique Les véhicules actuels, notamment de type automobiles ou équivalents, se complexifient avec le temps et sont de plus en plus orientés logiciel. Ainsi, le développement de certaines nouvelles architectures de véhicule s’accompagne de l’implémentation de nouvelles plates-formes technologiques mettant en œuvre des logiciels de diverses natures configurés pour mettre en œuvre des fonctions très variées. La présence croissante de logiciels dans les véhicules nécessite des mises à jour logicielles fréquentes afin notamment de réaliser la maintenance (à des fins de cybersécurité par exemple) et les corrections nécessaires sur ces logiciels (corrections de défauts ou bugs par exemple) et introduire régulièrement des améliorations (de nouvelles fonctionnalités par exemple). A cet effet, les technologies de communication sans fil (dites aussi OTA pour « Over The Air » en anglais) peuvent être utilisées pour transférer à distance des logiciels ou des données vers/depuis un véhicule, et ainsi effectuer les mises à jour logicielles nécessaires. Il est ainsi possible de mettre à jour des véhicules tout au long de leur cycle de vie et ainsi assurer une expérience optimale pour l’utilisateur. Cependant, la maintenance, et notamment le maintien à jour, des logiciels pour véhicule constituent un défi important en raison notamment de la complexification des véhicules et de leurs logiciels embarqués. Ainsi, l’augmentation du nombre de calculateurs embarqués dans les véhicules, la sophistication croissante des logiciels ou encore l’interdépendance des calculateurs entre eux imposent des contraintes fortes sur la maintenance de ces logiciels et peuvent rendre difficile les mises à jour logicielles. Ces difficultés résultent également du fait que les logiciels et le matériel embarqués dans les véhicules sont souvent étroitement corrélés et dépendants les uns avec les autre dans de nombreuses architectures existantes de véhicule. Cela entrave la capacité des acteurs du marché à faire évoluer les logiciels sans impacter ou modifier le matériel. Dans un contexte où les véhicules sont amenés à être de plus en plus fournisseurs de services, il est nécessaire de pouvoir faire évoluer les logiciels de véhicule tout au long de la durée de vie des véhicules, si possible sans changer le matériel. Ces difficultés sont encore amenées à croître sensiblement dans le futur. Il est critique de pouvoir assurer ces mises à jour de façon efficace afin de permettre notamment aux acteurs de continuer à innover, développer et maintenir des véhicules performants et de qualité. Résumé de la présente invention Il a été constaté que la capacité de maintenance et d'évolution des logiciels embarqués dans des véhicules est étroitement dépendante de la complexité des logiciels en question. Des logiciels de complexité limitées sont notamment plus faciles à garder à jour. Une faible complexité des logiciels de véhicule se traduit en outre par une meilleure qualité et fiabilité des véhicules (moins de bugs, etc.) et des coûts de maintenance réduits ainsi qu'une meilleure expérience client. Il a également été observé qu’il est possible d’évaluer la complexité d’un logiciel en fonction du niveau d'algorithme du contenu du code, ce qui nécessite toutefois l’utilisation d’algorithmes particulièrement complexes et donc difficiles à mettre en œuvre (utilisation par exemple de réseaux de neurones pour mesurer la complexité logicielle). De tels algorithmes nécessitent un cadre logiciel spécifique qui doit être mis en place et développé, ce qui impose des coûts en importants en ressources (de temps, matérielles/logicielles, financières, etc.). L’un des objets de la présente invention est de résoudre au moins l’un des problèmes ou déficiences de ce qui a été décrit précédemment. Un autre objet de la présente invention est d’améliorer la maintenance logicielle dans un ou des véhicules, par exemple mais par exclusivement de type automobile, notamment pour permettre des mises à jour logicielles rapides et efficaces. Un autre objet de la présente invention est d’aider à mettre à jour au moins un logiciel implémentable (ou implémenté) dans un ou des véhicules, en vue de permettre des mises à jour logicielles rapides et efficaces. Selon un premier aspect, la présente invention concerne un procédé de traitement mis en œuvre par un dispositif de traitement pour aider à mettre à jour au moins un logiciel implémentable dans un groupe d’au moins un véhicule, ledit procédé comprenant : - détermination d’un nombre N de versions possibles que peut présenter ledit au moins un logiciel, N étant un entier au moins égal à 2, les N versions étant organisées selon un ordre chronologique depuis une version la plus ancienne jusqu’à une version la plus à jour ; - détermination d’un profil P de mise à jour définissant au moins une condition à respecter par une mise à jour dudit au moins logiciel depuis une version initiale vers une version cible dudit logiciel ; - détermination, à partir du nombre N et du profil P, d’un indice de complexité C représentatif d’une complexité dudit au moins logiciel ; et - évaluation d’une capacité à mettre à jour ledit au moins un logiciel par comparaison de l’indice de complexité C avec une valeur de référence. L’invention permet avantageusement d’améliorer la maintenance logicielle dans un ou des véhicules, par exemple mais par exclusivement de type automobile, notamment pour permettre des mises à jour logicielles rapides et efficaces. Grâce à l’indice de complexité C qui constitue une nouvelle métrique prenant en compte N et P, on peut évaluer efficacement une capacité à mettre à jour un logiciel dans un ou plusieurs véhicules, tels que dans un parc automobile par exemple. On peut ainsi aider à mettre à jour au moins un logiciel implémentable (ou implémenté) dans un ou des véhicules, en vue de permettre des mises à jour logicielles rapides et efficaces. Pour ce faire, le dispositif de traitement simule ou modélise la ou les mises à jour à réaliser sur le(s) logiciel(s) en déterminant un indice de complexité C ainsi qu’une capacité de mise à jour comme précédemment indiqué. De cette manière, on peut par exemple détecter des situations critiques et/ou adapter une stratégie de mise à jour logicielle. Le dispositif de traitement peut éventuellement être en outre configuré pour réaliser les mises à jour elles-mêmes. L’indice de complexité C peut être déterminé de façon rapide et fiable. En outre, il est possible d’appliquer le procédé de traitement à des logiciels non encore implémentés dans des véhicules ou de façon rétroactive à des logiciels existants déjà installés dans des véhicules. Le procédé selon l’invention peut comporter d’autres caractéristiques qui peuvent être prises séparément ou en combinaison, notamment parmi les modes de réalisation qui suivent. Selon un mode particulier de réalisation, le profil de mise à jour définit au moins l’une des conditions suivantes : a) la mise à jour est réalisée de façon incrémentale depuis la version initiale jusqu’à la version cible ou la mise à jour est réalisée de façon directe depuis la version initiale jusqu’à la version cible ; b) la version cible de la mise à jour est la version la plus à jour ou la version cible est une quelconque version plus à jour que la version initiale ; et c) la mise à jour comprend une rétrogradation de version dudit au moins un logiciel depuis une version intermédiaire vers la version finale. Selon un mode particulier de réalisation, N étant un entier au moins égal à 3 ou au moins égal à 4. Selon un mode particulier de réalisation, la valeur de référence est une valeur seuil, l’évaluation de ladite capacité comprenant : - émission d’une alerte si l’indice de complexité C atteint la valeur seuil. Selon un mode particulier de réalisation, le procédé comprend au moins l’un parmi : - évaluation, à partir de l’indice de complexité C et/ou de la capacité à mettre à jour, d’une capacité à réaliser sur une période donnée une campagne de mises à jour sur ledit au moins un logiciel implémenté dans le groupe d’au moins un véhicule ; et - définition, à partir de l’indice de complexité C et/ou de la capacité à mettre à jour, d’une stratégie de mise à jour dudit au moins un logiciel implémenté dans le groupe d’au moins un véhicule. Selon un mode particulier de réalisation, le procédé est tel que : - au moins deux couples différents (N, P) sont déterminés pour mettre à jour ledit au moins logiciel selon respectivement au moins deux configurations différentes de mise à jour ; et - un indice de complexité C est déterminé pour respectivement chaque couple (N, P) ; le procédé comprenant en outre : - détermination d’un rapport de complexité entre lesdites au moins deux configurations de mise à jour par comparaison de leurs indices de complexité respectifs. Selon un mode particulier de réalisation, le procédé comprend : - détermination, à partir du rapport de complexité, de la configuration de mise à jour la moins complexe ; et - sélection de la configuration de mise à jour la moins complexe pour mettre à jour ledit au moins un logiciel. Selon un mode particulier de réalisation, l’indice de complexité C est déterminé à partir d’une formule de calcul prenant en entrée N, ladite formule de calcul étant sélectionnée en fonction du profil P de mise à jour. Selon un deuxième aspect, la présente invention concerne un dispositif de traitement (ou dispositif de supervision) pour aider à mettre à jour au moins un logiciel implémentable dans un groupe d’au moins un véhicule, le dispositif comprenant une mémoire associée à un processeur configuré pour la mise en œuvre des étapes du procédé de traitement selon le premier aspect de la présente invention. A noter que les différents modes de réalisation mentionnés ci-avant en relation avec le procédé de traitement selon le premier aspect de l’invention ainsi que les avantages associés s’appliquent de façon analogue au dispositif de traitement selon le deuxième aspect de l’invention. Selon un troisième aspect, la présente invention concerne un programme d’ordinateur qui comporte des instructions adaptées pour l’exécution des étapes du procédé de traitement selon le premier aspect de la présente invention, ceci notamment lorsque le programme d’ordinateur est exécuté par au moins un processeur. Autrement dit, les différentes étapes du procédé de traitement sont déterminées par des instructions de programmes d’ordinateurs. Ce programme d’ordinateur est configuré pour être mis en œuvre dans un dispositif de traitement du deuxième aspect de l’invention, ou plus généralement dans un ordinateur (par exemple un serveur). Un tel programme d’ordinateur peut utiliser n’importe quel langage de programmation, et être sous la forme d’un code source, d’un code objet, ou d’un code intermédiaire entre un code source et un code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. Selon un quatrième aspect, la présente invention concerne un support d’enregistrement (ou support d’informations), lisible par le dispositif de traitement selon le deuxième aspect ou plus généralement par un ordinateur (ou un processeur), sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé de traitement selon le premier aspect de la présente invention. D’une part, le support d’enregistrement peut être n'importe quel entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire ROM, un CD-ROM ou une mémoire ROM de type circuit microélectronique, ou encore un moyen d'enregistrement magnétique ou un disque dur. D'autre part, ce support d’enregistrement peut également être un support transmissible tel qu'un signal électrique ou optique, un tel signal pouvant être acheminé via un câble électrique ou optique, par radio classique ou hertzienne ou par faisceau laser autodirigé ou par d'autres moyens. Le programme d’ordinateur selon la présente invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme d’ordinateur est incorporé, le circuit intégré étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève description des figures D’autres caractéristiques et avantages de la présente invention ressortiront de la description des exemples de réalisation particuliers et non limitatifs de la présente invention ci-après, en référence aux figures 1 à 11 annexées, sur lesquelles : illustre schématiquement un dispositif de traitement configuré pour aider à la mise à jour d’au moins un logiciel implémentable dans au moins un véhicule, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; illustre schématiquement un logiciel de véhicule comme représenté en , selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; illustre schématiquement la détermination d’un indice de complexité, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; illustre schématiquement la détermination d’un indice de complexité, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; illustre schématiquement la détermination d’un indice de complexité, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; illustre schématiquement la détermination d’un indice de complexité, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; illustre schématiquement la détermination d’un indice de complexité, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; illustre schématiquement la détermination d’un indice de complexité, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; illustre schématiquement la détermination d’un indice de complexité, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; illustre schématiquement un dispositif de traitement configuré pour aider la mise à jour d’au moins un logiciel comme illustré en figures 1-9, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; et illustre un diagramme de différentes étapes d’un procédé de traitement d’au moins un logiciel de véhicule comme illustré en figures 1-2, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention. Description des exemples de réalisation Un procédé et un dispositif de contrôle d’un véhicule vont maintenant être décrits dans ce qui va suivre en référence conjointement aux figures 1-11. Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité. Les termes « premier(s) » (ou première(s)), « deuxième(s) », etc.) sont utilisés dans ce document par convention arbitraire pour permettre d’identifier et de distinguer différents éléments (tels que des opérations, des programmes d’ordinateur, des versions de logiciel, etc.) mis en œuvre dans les modes de réalisation décrits ci-après. Comme précédemment indiqué, l’invention vise notamment un procédé de traitement mis en œuvre par un dispositif de traitement pour aider (ou simuler, ou ou permettre, ou faciliter) la mise à jour d’au moins un logiciel implémentable (ou implémenté) dans un groupe d’au moins un véhicule, tels que des véhicules de type automobile ou autre, ou plus généralement dans des véhicules de type véhicule terrestre motorisé. Selon un exemple particulier et non limitatif de réalisation, le procédé de traitement de la présente invention comprend : - détermination d’un nombre N de versions possibles que peut présenter ledit au moins un logiciel, N étant un entier au moins égal à 2, les N versions étant organisées selon un ordre chronologique depuis une version la plus ancienne jusqu’à une version la plus à jour ; - détermination d’une profil P de mise à jour définissant au moins une condition à respecter par une mise à jour dudit au moins logiciel depuis une version initiale vers une version cible dudit logiciel ; et - détermination, à partir du nombre N et du profil P, d’un indice de complexité C représentatif d’une complexité dudit au moins logiciel ; et - évaluation d’une capacité à mettre à jour ledit au moins un logiciel par comparaison de l’indice de complexité C avec une valeur de référence. Comme indiqué précédemment, il a été observé que la capacité de maintenance et d'évolution des logiciels embarqués dans des véhicules est étroitement dépendante de la complexité des logiciels concernés. L’invention repose donc en particulier sur une solution rapide et efficace pour évaluer la complexité d’un ou d’une pluralité de logiciels de véhicule, afin d’aider à mettre à jour ces logiciels. Cette solution implique notamment l’introduction d’une nouvelle métrique représentative de la complexité d’un ou plusieurs logiciels de véhicule. Cette nouvelle métrique, dite indice de complexité (ou indice de complexité logicielle), capable d’être déterminée rapidement et à faible coût en ressources, permet de représenter de façon fiable la complexité d’un code logiciel pour véhicule et/ou la complexité d’une plateforme technologique associée (par exemple de type OTA). A partir de cette indice de complexité, on peut ainsi évaluer une capacité à mettre à jour le ou les logiciels concernés. Pour ce faire, une comparaison est réalisée entre l’indice de complexité et une valeur de référence dont la nature peut varier selon le cas. Il est par exemple possible, à partir du résultat de cette comparaison, de détecter ou anticiper des risques ou problèmes liés à une mise à jour ou encore de concevoir ou adapter ladite mise à jour avant son application sur le ou les logiciels concernés. D’autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant. La illustre schématiquement un dispositif de traitement 10 configuré pour aider ou faciliter la mise à jour d’au moins un logiciel PG1 implémentable dans un groupe 3 d’au moins un véhicule 2. Le dispositif 10 et le groupe 3 d’au moins un véhicule 2 forme ensemble un système SY1. Ce dispositif de traitement (dit aussi dispositif de modélisation ou dispositif) 10 vise en premier lieu à aider ou faciliter la mise à jour du ou des logiciels PG1 destinées à être implémentés dans les véhicules 2. Le dispositif 10 peut ainsi simuler ou modéliser la ou les mises à jour à réaliser sur ces logiciels PG1. De cette manière, on peut notamment détecter des situations critiques et/ou adapter une stratégie de mise à jour. Comme décrit plus en détail ultérieurement, le dispositif 10 peut éventuellement être en outre configuré pour réaliser les mises à jour elles-mêmes. Comme illustré en , on considère ici un groupe (ou parc) 3 d’une pluralité de véhicules 2, bien que l’invention soit également applicable pour un seul véhicule 2. Autrement dit, l’invention peut s’appliquer plus généralement à un groupe 3 d’au moins un tel véhicule 2. Le type et les caractéristiques des véhicules 2 peuvent être adaptés selon le cas. Les véhicules 2 sont par exemple de type automobile ou équivalent. En variante, chaque véhicule 2 peut être un car, un bus, un camion, un véhicule utilitaire ou une motocyclette, ou plus généralement un véhicule de type véhicule terrestre motorisé, voire un véhicule maritime (ou fluvial) ou aérien. Chaque véhicule 2 du groupe 3 embarque au moins un logiciel PG1 implémenté dans au moins un dispositif embarqué 4. On considère par la suite à titre d’exemple que les véhicules 2 embarquent chacun au moins un calculateur 4 configuré pour implémenter un logiciel PG1. A noter toutefois que le nombre de calculateurs et de logiciels PG1 implémentés peuvent varier selon le cas. On suppose par la suite que chaque calculateur 4 est configuré pour implémenter un même logiciel PG1, ce logiciel pouvant éventuellement comprendre une pluralité de logiciels ou sous-logiciels. Comme décrit ci-après, la version du logiciel PG1 implémenté dans chaque véhicule 2 peut toutefois varier. Chaque véhicule 2 peut par exemple comprendre un ou une pluralité de calculateurs 4. Selon un exemple particulier, les véhicules 2 comprennent un calculateur central 4 coopérant avec au moins un autre calculateur secondaire 4. La nature, la configuration et le fonctionnement du logiciel PG1 implémenté dans chaque véhicule 2 peuvent varier selon le cas. Ce logiciel PG1 peut être un quelconque programme d’ordinateur, ou application, configurés pour mettre en œuvre au moins une fonction appropriée dans le véhicule 2. Parmi les fonctions possibles, les calculateurs 4 peuvent par exemple mettre en œuvre des fonctions de contrôle du véhicule (d’au moins un élément du véhicule), d’aide à la navigation, de gestion de contenus multimédia, etc. Le dispositif de traitement 10 peut comprendre au moins un processeur et une mémoire non volatile (non représentés en ). Le dispositif 10 est configuré pour mettre en œuvre un procédé (ou processus) de traitement (dit aussi procédé/processus de modélisation) comme décrit ci-après. A cet effet, le dispositif 10 peut comprendre un deuxième programme d’ordinateur PG2 stocké dans sa mémoire non volatile (mémoire de type Flash ou ROM par exemple), ce programme d’ordinateur PG2 comprenant des instructions pour la mise en œuvre du procédé (ou processus) de traitement comme décrit ci-après. Le processeur du dispositif 10 peut ainsi être configuré pour exécuter notamment les instructions définies par le programme d’ordinateur PG2. Le dispositif de traitement 10 peut être un quelconque dispositif, tel qu’un ordinateur ou serveur par exemple, apte à mettre en œuvre le procédé (ou processus) de traitement de l’invention. Ce dispositif 10 peut par exemple prendre la forme d’un (ou comprendre un) calculateur, ou une combinaison de calculateurs. Au moins un exemple de mise en œuvre du dispositif 10 est décrit ultérieurement. Comme illustré en , le dispositif 10 peut en outre être configuré pour réaliser au moins une opération OP de mise à jour en coopération avec les véhicules 2 du groupe 3, afin de mettre à jour les logiciels embarqués PG1. Une opération OP de mise à jour est configurée pour mettre à jour au moins un logiciel PG1. Une telle opération OP (figures 1-2) peut comprendre par exemple l’envoi et/ou la réception de données vers et/ou depuis au moins un véhicule 2. Pour ce faire, on suppose par la suite que le dispositif 10 comprend des moyens d’interface pour coopérer avec les véhicules 2, ou plus particulièrement avec les calculateurs 4, via des canaux de communication appropriés. Ces canaux de communication établis entre le dispositif 10 et les véhicules 2 peuvent par exemple être de type sans fil. Autrement dit, le dispositif 10 peut par exemple être configuré pour communiquer en mode OTA (« Over The Air ») avec les véhicules 2 (ou avec leurs calculateurs 4) pour réaliser des opérations OP de mise à jour des logiciels PG1. Dans le présent document, une mise à jour peut couvrir une quelconque opération OP de modification, altération, amélioration, correction,etc. d’un logiciel PG1. Comme illustré en , chaque logiciel PG1 pour véhicule présente (ou se caractérise par) une version de logiciel notée généralement V, ou plus précisément V i où i est un nombre (ou indice) entier compris entre 1 et N. On considère N un entier au moins égal à 2. Selon un exemple particulier, N est au moins égal à 3 ou au moins égal à 4. Le nombre N peut être adapté selon le cas. Dans ce qui suit, on suppose à titre illustratif que N = 4, bien que d’autres exemples soient possibles. Autrement dit, le logiciel PG1 de chaque véhicule 2 peut présenter l’une quelconque parmi les versions possibles V 1 , V 2 , V 3 et V 4 . Ainsi, il existe un nombre N (=4) de versions V possibles que peuvent présenter chaque logiciel PG1. Ces N versions de logiciel possibles sont organisées selon un ordre chronologique (c’est-à-dire un ordre croissant de mise à jour) depuis une version la plus ancienne V 1 jusqu’à une version la plus à jour V N (c’est-à-dire la version la plus récente). Dans ce qui suit, on considère ainsi à titre d’exemple que les versions V 1 -V N sont classées selon l’ordre chronologique suivant : V 1 , V 2 , V 3 et V 4 . Comme illustré en selon un exemple particulier, une mise à jour OP (ou opération de mise à jour) est configurée pour modifier la version d’un logiciel PG1 de véhicule. Ainsi, une mise à jour OP convertit un logiciel PG1 depuis une version initiale (ou version de départ) Va dans une version cible (ou version finale) Vb. Comme décrit par la suite, une mise à jour OP peut dans certains exemples être réalisée via au moins une version intermédiaire entre la version initiale Va et la version cible Vb. Selon d’autres exemples, une mise à jour OP peut être réalisée directement depuis la version initiale Va dans la version cible Vb, c’est-à-dire sans que le logiciel PG1 ne soit converti dans une quelconque version intermédiaire au cours du processus de mise à jour. Comme indiqué ci-avant, le dispositif 10 est configuré pour mettre en œuvre un processus de traitement (ou de modélisation). Ce processus est à présent décrit conjointement aux figures 1 et 2 selon des modes de réalisation particuliers. Comme déjà indiqué, on suppose par la suite que le processus de traitement vise en particulier à aider à mettre à jour un logiciel PG1 implémentable dans les véhicules 2, et plus particulièrement, exécutables par les dispositifs embarqués 4. PG1 désigne donc ici un même logiciel implémentable dans chaque véhicule 2 mais dont la version V peut varier d’un véhicule 2 à un autre (entre les versions V 1 et V N =V 4 incluses). Ce logiciel PG1 peut être déjà implémenté dans tous ou partie des véhicules 2 lorsque le processus de traitement est réalisé. En variante, le processus de traitement peut être réalisé avant même que le logiciel PG1 ne soit implémenté ou chargé dans les véhicules 2. Dans une première opération, le dispositif de traitement 10 détermine le nombre N de versions V possibles que peut présenter le logiciel PG1 implémentable (ou implémentés) dans le groupe 3 de véhicules 2. Comme déjà indiqué, N est un nombre entier au moins égal à 2 et les N versions V sont organisées selon un ordre chronologique depuis une version la plus ancienne jusqu’à une version la plus à jour. On considère par la suite que N=4 et que les versions V 1 -V N sont classées selon l’ordre chronologique suivant : V 1 , V 2 , V 3 et V 4 . Le nombre N peut être déterminé de diverses manières selon le cas considérés. A titre d’exemple, le dispositif 10 peut récupérer le nombre N en consultant une mémoire locale, ou peut recevoir cette valeur sous forme d’instruction (par exemple une instruction utilisateur), ou peut encore recevoir cette valeur depuis une entité externe. Dans une deuxième opération, le dispositif de traitement 10 détermine un profil P de mise à jour (ou une politique de mise à jour, ou une configuration de mise à jour) définissant au moins une condition à respecter par une mise à jour OP du logiciel PG1 dans les véhicules 2 depuis une version initiale Va jusqu’à une version cible Vb. On considère dans ce qui suit que la version cible Vb est plus avancée que la version de départ Va selon l’ordre chronologique des versions V. Le profil P de mise à jour définit la manière dont la mise à jour OP doit être réalisée depuis la version Va jusqu’à la version Vb. Diverses configurations de mise à jour sont possibles selon la situation et les besoins et peuvent donc être adaptées au cas par cas. Selon un exemple particulier, le profil P de mise à jour définit au moins l’une des conditions suivantes : a1) la mise à jour OP est réalisée de façon incrémentale depuis la version initiale Va jusqu’à la version cible Vb ou a2) la mise à jour est réalisée de façon directe depuis la version initiale Va jusqu’à la version cible Vb ; b1) la version cible Vb de la mise à jour OP est la version la plus à jour ou b2) la version cible Vb est une quelconque version plus à jour que la version initiale Va ; et c) la mise à jour comprend une rétrogradation de version du logiciel PG1 depuis une version intermédiaire vers la version finale Vb. Selon un exemple particulier, le profil P définit au moins soit la condition a1), soit la condition a2). Selon un exemple particulier, le profil P définit au moins soit la condition b1), soit la condition b2). Selon un exemple particulier, le profil P définit au moins la condition c). Selon un exemple particulier, le profil P définit une quelconque combinaison ou sous-combinaison parmi les conditions a1)-a2), b1)-b2) et c). Une mise à jour OP dite incrémentale signifie que le passage depuis la version initiale Va à la version finale Vb se fait en passant successivement par chaque version intermédiaire V située (le cas échéant) entre Va et Vb selon l’ordre chronologique des versions V (c’est-à-dire en passant une à une les versions depuis Va à Vb selon l’ordre chronologique). Par exemple, une mise à jour incrémentale depuis Va=V 1 à Vb=V 4 implique les conversions successives du logiciel PG1 depuis la version V 1 à V 2 , puis de V 2 à V 3 , puis de V 3 à V 4 , ce qui peut se symboliser par V 1 à V 2 à V 3 à V 4 . Le même formalisme de représentation des étapes successives d’une mise à jour OP sera adopté dans ce qui suit. A contrario, une mise à jour OP directe signifie que le passage depuis la version initiale Va à la version finale Vb se fait sans passer par une quelconque version intermédiaire V susceptible d’être située entre Va et Vb selon l’ordre chronologique des versions V. Par exemple, une mise à jour directe depuis Va=V 1 à Vb=V 4 implique la conversion directe du logiciel PG1 depuis la version V 1 à V 4 sans passer ni par V 3 ni par V 4 , ce qui peut se symboliser par V 1 à V 4 . Comme exprimé ci-avant dans la condition b1), une mise à jour OP peut imposer que le logiciel PG1 soit systématiquement mis à jour à la version la plus à jour, à savoir V N =V 4 dans cet exemple. Au contraire, une mise à jour OP peut autoriser que le logiciel PG1 soit converti dans une version plus à jour que la version initiale Vb mais pas nécessairement la version la plus à jour V, à savoir V N =V 4 dans cet exemple. Comme exprimé ci-avant dans la condition c), une mise à jour OP peut comprendre une rétrogradation de version du logiciel PG1 (autrement dit un recul de version selon l’ordre chronologique des versions V) depuis une version intermédiaire vers la version finale Vb. Par exemple, une telle mise à jour OP peut être réalisée depuis Va=V 1 à Vb=V 3 avec successivement une conversion – directe par exemple – depuis V 1 à V 4 (version intermédiaire) puis une rétrogradation depuis V 4 à V 3 , ce qui peut se symboliser par V 1 à V 4 à V 3 . La rétrogradation de version peut être utile ou souhaitable dans certaines situations, par exemple pour des raisons d’ordre sécuritaire, d’ordre technique, des raisons relatives à la qualité d’un service mise en œuvre par le logiciel PG1, ou encore pour configurer le logiciel selon des contraintes particulières (souhait du client, etc.). Dans une troisième opération, le dispositif de traitement 10 détermine, à partir du nombre N et du profil P, un indice de complexité C représentatif d’une complexité du logiciel PG1. Pour ce faire, le dispositif 10 peut appliquer une méthode (ou un algorithme) de calcul qui prend en entrée le paramètre N et qui au moins un paramètre défini par le profil P de mise à jour. Il a notamment été observé qu’il y a une corrélation entre la complexité du logiciel PG1 et le nombre N de versions possibles du logiciel à un instant donné. Ainsi, la complexité du logiciel PG1 croît avec le nombre N. De plus, la complexité du logiciel PG1 est liée à la stratégie de mise à jour qui est appliquée. Il est par exemple plus complexe de mettre à jour le logiciel PG1 de façon incrémentale que de façon directe en raison de la nécessité de convertir le logiciel par des versions intermédiaires entre Va et Vb si Va et Vb ne sont pas deux versions consécutives selon l’ordre chronologique des versions. Le dispositif 10 peut donc être configuré pour implémenter un algorithme de modélisation qui prend en compte les paramètres N et P pour déterminer l’indice de complexité C du logiciel PG1. L’indice de complexité C peut en particulier être défini (ou calculé) de sorte à être représentatif (ou fonction) du nombre de chemins (ou liens) possibles entre les différentes versions V (V 1 -V N ) du logiciel PG1. Ce nombre de chemins dépend du nombre N de version V possibles et du profil P de mise à jour appliqué. A noter que le profil P peut être défini par au moins un paramètre représentatif du ou des conditions précitées. Selon un exemple particulier, le dispositif 10 sélectionne la méthode de calcul (ou algorithme de calcul), utilisée pour déterminer l’indice de complexité C, en fonction du profil P de mise à jour, ou plus précisément en fonction de la ou des conditions que la mise à jour OP doit respecter conformément audit profil P. Ainsi, la méthode (ou algorithme) de calcul utilisée peut varier en fonction du profil P appliqué afin de prendre en compte les spécificités de la mise à jour OP. Des exemples de détermination de l’indice de complexité C seront décrits ci-après dans des modes de réalisation particuliers. Dans une quatrième opération, le dispositif 10 évalue une capacité RS à mettre à jour au moins un logiciel par comparaison de l’indice de complexité C avec une valeur de référence ( ). On peut ainsi apprécier la faisabilité ou la difficulté à mettre à jour un logiciel PG1 pour véhicule à partir d’une modélisation dudit logiciel, ou une modélisation de la mise à jour de ce logiciel. Le dispositif 10 peut ainsi aider (ou simuler, ou faciliter) la mise à jour du logiciel PG1 implémentable (ou implémenté) dans les véhicules 2. A partir de l’indice de complexité C, le dispositif 10 peut évaluer une capacité RS à mettre à jour le logiciel PG1 en comparant l’indice de complexité C et une valeur de référence dont la nature peut varier selon le cas. Il est par exemple possible, à partir du résultat de cette comparaison, de détecter ou anticiper des risques ou problèmes liés à une mise à jour OP ou encore de concevoir ou adapter ladite mise à jour OP avant même son application sur le logiciel PG1. Selon un exemple particulier, l’évaluation de la capacité RS à mettre à jour le logiciel PG1 peut également prendre en compte des ressources disponibles à un instant donné ou sur une période de temps donnée. Ainsi, plus les ressources disponibles seront importantes, plus la capacité RS est importante. La valeur de référence utilisée au cours de la quatrième opération peut par exemple être une valeur seuil. Ainsi, l’évaluation de la capacité RS à mettre à jour le logiciel PG1 peut comprendre l’émission d’une alerte AL ( ) par le dispositif 10 si l’indice de complexité C atteint (ou est supérieur ou égal à) la valeur seuil. De cette manière, on peut détecter, anticiper et/ou éviter une situation critique dans laquelle il serait particulièrement difficile de réaliser la mise à jour OP. La valeur de référence peut par exemple être prédéfinie pour permettre la détection d’une éventuelle explosion (ou d’un pic) de la complexité du logiciel PG1 qui se traduirait par une capacité réduite à mettre à jour le logiciel. A contrario, il est ainsi possible de détecter ou confirmer qu’une mise à jour OP peut être réaliser sans difficulté ou selon une efficacité acceptable. Le résultat de l’évaluation réalisée au cours de la quatrième opération peut par exemple être utilisée pour adapter la mise à jour OP et/ou concevoir une stratégie de mise à jour applicable au le logiciel PG1, par exemple en adaptant le profil P de mise à jour et/ou le nombre N de versions possibles. Le résultat de l’évaluation réalisée au cours de la quatrième opération peut par exemple être utilisée pour contrôler la mise à jour OP du logiciel PG1, par exemple en bloquant ou différant cette mise à jour ou en adaptant sa configuration. Selon un exemple particulier, la complexité C et/ou la capacité RS peuvent être utilisées pour guider le développement d’une stratégie de mise à jour du logiciel PG1 dans le parc de véhicules 2. Selon un exemple particulier, la complexité C et/ou la capacité RS peuvent être utilisées pour évaluer une capacité à réaliser sur une période donnée une campagne de mises à jour sur le logiciel PG1 implémenté dans le groupe 3 de véhicules 2. Selon un exemple particulier, la complexité C et/ou la capacité RS peuvent être utilisées pour sélectionner l’une parmi au moins deux configurations différentes de mise à jour pour mettre à jour le logiciel PG1. Chaque configuration de mise à jour peut être définie par un couple respectif (N ; P) définissant le nombre N de versions possibles et le profil P de mise à jour utilisé. Selon un exemple particulier, le dispositif 10 détermine au moins deux couples différents (N, P) pour mettre à jour le logiciel PG1 selon respectivement au moins deux configurations différentes de mise à jour, et détermine un indice de complexité C pour respectivement chaque couple (N, P). Le dispositif 10 peut ainsi déterminer un rapport de supériorité (ou rapport de complexité) entre lesdites au moins deux configurations de mise à jour par comparaison de leurs indices de complexité C respectifs. On peut ainsi déterminer par exemple qu’une première configuration de mise à jour présente une complexité C plus élevée que celle d’une deuxième configuration de mise à jour. Ce rapport peut définir un ordre de complexité entre une pluralité de configurations différentes de mise à jour. A partir du rapport de supériorité ainsi déterminé, le dispositif 10 peut sélectionner l’une ou l’autre des configurations de mise à jour, par exemple celle présentant l’indice de complexité la plus basse ou encore celle satisfaisant au moins un critère prédéfini prenant en compte ce rapport de supériorité. Selon un exemple particulier, le dispositif 10 détermine en outre, à partir du rapport de complexité précité, la configuration de mise à jour la moins complexe, et sélectionne la configuration de mise à jour la moins complexe pour mettre à jour le logiciel PG1. Selon un exemple particulier, après la quatrième opération, le dispositif 10 réalise la mise à jour OP sur le logiciel PG1 implémenté dans les véhicules 2, éventuellement après avoir adapté ou contrôlé cette mise à jour en fonction de la capacité RS et/ou de l’indice de complexité C (comme précédemment décrit). Cette mise à jour OP est par exemple réalisée par communication sans contact (mode OTA) entre le dispositif 10 et les véhicules 2 (ou avec leurs calculateurs embarqués 4 via des interfaces de communication). Le processus de traitement décrit ci-avant dans des modes de réalisation particulier permet avantageusement d’améliorer la maintenance logicielle dans un ou des véhicules 2, par exemple mais par exclusivement de type automobile, notamment pour permettre des mises à jour logicielles rapides et efficaces. Grâce à l’indice de complexité C qui constitue une nouvelle métrique prenant en compte N et P, on peut évaluer efficacement une capacité RS à mettre à jour un logiciel PG1 dans un ou plusieurs véhicules, tels que dans un parc automobile par exemple. On peut ainsi aider à mettre à jour au moins un logiciel implémentable (ou implémenté) dans un ou des véhicules 2, en vue de permettre des mises à jour logicielles rapides et efficaces. Pour ce faire, le dispositif 10 simule ou modélise la ou les mises à jour à réaliser sur le logiciel PG1 en déterminant un indice de complexité C ainsi qu’une capacité RS de mise à jour comme précédemment décrit. De cette manière, on peut par exemple détecter des situations critiques et/ou adapter une stratégie de mise à jour logicielle. Le dispositif 10 peut éventuellement être en outre configuré pour réaliser les mises à jour elles-mêmes. L’indice de complexité C peut être déterminé de façon rapide et fiable. En outre, il est possible d’appliquer le processus de traitement à des logiciels non encore implémentés dans des véhicules 2 ou de façon rétroactive à des logiciels existants déjà installés dans des véhicules 2. Des exemples de réalisation de la troisième opération du processus de traitement, à savoir de la détermination de l’indice de complexité C, sont à présent décrits ci-après conjointement aux figures 3-9. Dans ces exemples, l’indice de complexité est déterminé en appliquant une méthode de calcul prenant en entrée le nombre N (où N=4 dans les exemples considérés), ladite méthode de calcul étant sélectionnée en fonction du profil P de mise à jour appliqué. Ainsi, diverses méthodes de calcul sont décrites pour différents profils P de mise à jour appliqués. On peut par exemple considérer que toutes les versions possibles (V 1 -V N ) du logiciel PG1 sont compatibles entre elles, bien que des variantes soient possibles où cela n’est pas le cas. En cas de compatibilité entre versions V, cela signifie que tous les versions V partagent une même architecture et que l’on peut passer d’une version à une autre en montant ou descendant dans l’ordre chronologique des versions (compatibilité ascendante et descendante selon l’ordre chronologique). Comme illustré en dans un mode de réalisation particulier, on considère que, conformément au profil P de mise à jour, la mise à jour OP – notée OP1 – doit être réalisée de façon incrémentale depuis la version initiale Va jusqu’à la version cible Vb (condition a1)) et la version cible Vb est nécessairement la version V N la plus à jour (condition b1)), à savoir V 4 dans cet exemple. Aussi, dans cet exemple, la mise à jour OP1 peut être l’une quelconque parmi : V1 à V2 à V3 à V4 ; V2 à V3 à V4 ; et V3 à V4. Dans ce cas, la méthode de calcul suivante est sélectionnée : Dans l’exemple considéré, l’indice de complexité C est donc égal à 6. Une fois l’indice de complexité C déterminé, le nombre N peut être initialisé à 0. Ainsi, lors d’une prochaine itération du processus de traitement, il sera pris en compte le fait que le logiciel a déjà été mis à jour à la version V 4 . Comme illustré en dans un mode de réalisation particulier, on considère que, conformément au profil P de mise à jour, la mise à jour OP – notée OP2 – doit être réalisée de façon directe (condition a2)) et la version cible Vb est nécessairement la version V N la plus à jour (condition b1)), à savoir V 4 dans cet exemple. Aussi, dans cet exemple, la mise à jour OP2 peut être l’une quelconque parmi : V1 à V4 ; V2 à V4 ; et V3 à V4. Dans ce cas, la méthode de calcul suivante est sélectionnée : Dans l’exemple considéré, l’indice de complexité C est donc égal à 3. La complexité du logiciel est ici plus faible que dans l’exemple de la en raison du fait les chemins possibles de mise à jour sont plus limités en nombre et plus simples. Une fois l’indice de complexité C déterminé, le nombre N peut être initialisé à 1 en vue d’effectuer une nouvelle itération du processus de traitement. Comme illustré en dans un mode de réalisation particulier, on considère que, conformément au profil P de mise à jour, la mise à jour OP – notée OP3 – doit être réalisée de façon incrémentale depuis la version initiale Va jusqu’à la version cible Vb (condition a1)) et la version cible Vb est une quelconque version plus à jour que la version initiale Va (condition b2)). Aussi, dans cet exemple, la mise à jour OP3 peut être l’une quelconque parmi : V1 à V2 ; V1 à V2 à V3 ; V1 à V2 à V3 à V4 ; V2 à V3 ; V2 à V3 à V4 ; et V3 à V4. Le caractère incrémental de la mise à jour permet d’avoir une bonne traçabilité de l’historique des versions du logiciel PG1 de chaque véhicule 2. En revanche, cela impose une contrainte en ce qu’il est nécessaire de conserver à disposition toutes les versions V possibles qui ne sont pas la version la plus à jour. Dans ce cas, la méthode de calcul suivante est sélectionnée : Dans l’exemple considéré, l’indice de complexité C est donc égal à 6. Une fois l’indice de complexité C déterminé, on peut par exemple conserver le nombre N inchangé (N n’est pas réinitialisé en vue d’une prochaine itération du processus de traitement). Comme illustré en dans un mode de réalisation particulier, on considère que, conformément au profil P de mise à jour, la mise à jour OP – notée OP4 – doit être réalisée de façon directe depuis la version initiale Va jusqu’à la version cible Vb (condition a2)) et la version cible Vb est une quelconque version plus à jour que la version initiale Va (condition b2)). Aussi, dans cet exemple, la mise à jour OP4 peut être l’une quelconque parmi : V1 à V2 ; V1 à V3 ; V1 à V4 ; V2 à V3 ; V2 à V4 ; et V3 à V4. Le caractère direct de la mise à jour permet de limiter la complexité du logiciel et donc de faciliter les mises à jour. En revanche, cela impose de conserver à disposition d’anciennes version V du logiciel. En outre, les différents véhicules 2 du parc 3 peuvent être inhomogènes en termes de version V implémentée. De multiples versions différentes du logiciel PG1 peuvent donc être installée à travers le parc 3 de véhicules 2. Dans ce cas, la méthode de calcul suivante est sélectionnée : Dans l’exemple considéré, l’indice de complexité C est donc égal à 6. Une fois l’indice de complexité C déterminé, le nombre N peut par exemple être conservé inchangé en vue d’une itération ultérieure du processus de traitement. Comme illustré en dans un mode de réalisation particulier, on considère que, conformément au profil P de mise à jour, la mise à jour OP – notée OP5 – doit être réalisée de façon incrémentale depuis la version initiale Va jusqu’à une version intermédiaire correspondant à la version la plus à jour, à savoir V N =V 4 dans cet exemple (cette première phase correspond par exemple à l’exemple de la ). La mise à jour OP5 comprend en outre une rétrogradation de version du logiciel PG1 depuis la version intermédiaire dans la version cible Vb (condition c)). Cette rétrogradation (mise à jour descendante suivant l’ordre des versions) peut être un recul de d versions V depuis la version intermédiaire, où d est un nombre entier de rétrogradation tel que d Aussi, dans cet exemple, la mise à jour OP5 peut être l’une quelconque parmi : V1 à V2 à V3 à V4 à V3 ; et V2 à V3 à V4 à V3 ; voire éventuellement aussi V3 à V4 à V3 si l’on considère que le cas particulier où Va=Vb constitue en soi une opération de mise à jour. Ce scénario comprend donc deux étapes, à savoir une montée de version V selon l’ordre chronologique des versions jusqu’à une version intermédiaire puis une descente vers la version cible Vb. Une telle rétrogradation peut être avantageuse comme déjà expliqué précédemment. Dans ce cas, la méthode de calcul suivante est sélectionnée : où d Dans l’exemple considéré, dans le cas où d=1, l’indice de complexité C est donc égal à (4-1) + 4(4-1)/2 + 0 = 9. Une fois l’indice de complexité C déterminé, le nombre N peut par exemple être conservé inchangé en vue d’une itération ultérieure du processus de traitement. Comme illustré en dans un mode de réalisation particulier, on considère que, conformément au profil P de mise à jour, la mise à jour OP – notée OP6 – doit être réalisée de façon directe depuis la version initiale Va jusqu’à une version intermédiaire correspondant à la version la plus à jour, à savoir V N =V 4 dans cet exemple. La mise à jour OP6 comprend en outre une rétrogradation de version du logiciel PG1 depuis la version intermédiaire dans la version cible Vb (condition c)). Cette rétrogradation (mise à jour descendante suivant l’ordre des versions) peut être un recul de d versions V depuis la version intermédiaire, où d est un nombre entier de rétrogradation tel que d On considère à titre d’exemple que d = 1. Aussi, dans cet exemple, la mise à jour OP6 peut être l’une quelconque parmi : V1 à V4 à V3 ; V2 à V4 à V3 ; et V3 à V4 à V3. Ce scénario comprend donc deux étapes, à savoir une montée de version V selon l’ordre chronologique des versions jusqu’à une version intermédiaire puis une descente vers la version cible Vb. Une telle rétrogradation peut être avantageuse comme déjà expliqué précédemment. Dans ce cas, la méthode de calcul suivante est sélectionnée : Dans l’exemple considéré, dans le cas où d=1, l’indice de complexité C est donc égal à 6. Une fois l’indice de complexité C déterminé, le nombre N peut par exemple être réinitialisé à 2 en vue d’une itération ultérieure du processus de traitement. Comme déjà indiqué, l’invention peut s’appliquer à une pluralité de logiciels PG1 implémentables (ou implémentés) dans chaque véhicule 2. Selon un exemple particulier, le groupe 3 comprend une pluralité de véhicules 2 et une pluralité de logiciels PG1 sont implémentables dans chaque véhicule 2. Au cours du processus de traitement, le dispositif 10 : - détermine un nombre N et un profil P de mise à jour pour respectivement mettre à jour chaque logiciel PG1 ; - détermine un indice de complexité C pour respectivement chaque logiciel PG1 à mettre à jour ; et - détermine, à partir de la somme Σ des indices de complexité C, un indice de complexité global représentatif de la complexité à mettre à jour la pluralité de logiciels PG1. Comme illustré en dans un mode de réalisation particulier, le dispositif 10 peut ainsi déterminer respectivement un indice de complexité C i pour effectuer une mise à jour OP – notée OP7-i – pour chaque logiciel PG1 implémentable dans un véhicule 2 donné, où i est un entier compris entre 1 et M, M étant le nombre de logiciels PG1 considérés par véhicule 2. Dans ce cas, l’indice de complexité de l’ensemble des logiciels PG1 peut s’exprimer comme suit : En sommant ainsi les indices de complexité pour chaque logiciels PG1 (par exemple dans autant de calculateurs 4 d’un véhicule 2), on peut ainsi évaluer la complexité associé à l’ensemble des logiciels PG1 et en déduire une capacité RS à mettre à jour cet ensemble de logiciels par comparaison l’indice de complexité global avec une valeur de référence comme déjà décrit. Cette variante est avantageuse dans la mesure où les véhicules sont amenés à évolués de plus en plus vers une situation de mise à jour de plusieurs calculateurs en même temps. Ainsi, un package global de données de mise à jour peut être envoyé à un véhicule 2. Un calculateur central du véhicule 2 peut alors être configuré pour adresser les logiciels concernés aux autres calculateurs concernés du véhicule 2. Cette solution de package peut avantageusement aider à réduire la complexité du déploiement des mises à jour, notamment en raison du fait que le package peut contenir des logiciels cohérents les uns avec les autres. En revanche, cette technique de mise à jour par package ne réduit pas nécessairement la complexité d'un point de vue des variantes de réalisation (packages dédiés nécessaires pour un sous-ensemble de véhicules). Selon un exemple particulier, les indices de complexité C respectifs de plusieurs calculateurs 4 sont pris en compte car les calculateurs ont des dépendances entre eux. L'indice de complexité C global peut intégrer le niveau de complexité de chaque calculateur individuel. Les paquets de données transmis par le dispositif 10, éventuellement par communication sans contact (OTA), peuvent alors être composés d'un ensemble de versions logicielles. Cependant, il peut y avoir une augmentation importante du nombre de paquets de données. Cela peut entraîner la sommation de la complexité de plusieurs calculateurs dans un paquet de mise à niveau logiciel. Dans un exemple particulier, on peut considérer une mise à jour OP qui respecte un mode incrémental hybride, c’est-à-dire avec un palier correspond à 2 versions (V i+2 ) ou plus (V i+3 , etc.) par saut de version. La méthode de calcul de l’indice de complexité C peut alors être calculé de façon analogue à ce qui est décrit dans le présent document pour un mode incrémental classique avec un palier correspondant à 1 version V par saut de version. La illustre schématiquement un dispositif de traitement 10 configuré pour aider à une mise à jour logicielle, comme précédemment décrit en référence aux figures 1-9, selon un exemple de réalisation particulier et non limitatif de la présente invention. Le dispositif 10 correspond par exemple à un serveur distant vis-à-vis du ou des véhicules 2, par exemple un calculateur. Le dispositif de traitement 10 est par exemple configuré pour la mise en œuvre des opérations du processus de traitement (ou processus de modélisation) tel que précédemment décrit en regard des figures 1-9 et/ou des étapes du procédé décrit ci-après en regard de la . Des exemples d’un tel dispositif de traitement 10 comprennent, sans y être limités, un équipement électronique embarqué tel qu’un ordinateur de bord d’un véhicule, un calculateur électronique tel qu’une UCE (« Unité de Commande Electronique »), un téléphone intelligent (de l’anglais « smartphone »), une tablette, un ordinateur portable. Les éléments du dispositif de contrôle 10, individuellement ou en combinaison, peuvent être intégrés dans un unique circuit intégré, dans plusieurs circuits intégrés, et/ou dans des composants discrets. Le dispositif de traitement 10 peut être réalisé sous la forme de circuits électroniques ou de modules logiciels (ou informatiques) ou encore d’une combinaison de circuits électroniques et de modules logiciels. Le dispositif de traitement 10 comprend un (ou plusieurs) processeur(s) 40 configurés pour exécuter des instructions pour la réalisation des étapes du procédé (ou du processus) de traitement et/ou pour l’exécution des instructions du ou des logiciels embarqués dans le dispositif de traitement 10. Le processeur 40 peut inclure de la mémoire intégrée, une interface d’entrée/sortie, et différents circuits connus de l’homme du métier. Le dispositif de traitement 10 comprend en outre au moins une mémoire 41 correspondant par exemple à une mémoire volatile et/ou non volatile et/ou comprend un dispositif de stockage mémoire qui peut comprendre de la mémoire volatile et/ou non volatile, telle que EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, disque magnétique ou optique. Le code informatique du ou des logiciels embarqués comprenant les instructions à charger et exécuter par le processeur 40 est par exemple stocké sur la mémoire 41. La mémoire 41 peut constituer un support d’informations selon un mode de réalisation particulier en ce qu’elle comprend un programme d’ordinateur (par exemple PG2 en ) comportant des instructions pour la réalisation des étapes du procédé (ou du processus) de contrôle de l’invention. Selon différents exemples de réalisation particuliers et non limitatifs, le dispositif de traitement 10 est couplé en communication avec d’autres dispositifs ou systèmes similaires et/ou avec des dispositifs de communication, par exemple une TCU (de l’anglais « Telematic Control Unit » ou en français « Unité de Contrôle Télématique »), par exemple par l’intermédiaire d’un bus de communication ou au travers de ports d’entrée / sortie dédiés. Selon un exemple de réalisation particulier et non limitatif, le dispositif de traitement 10 comprend un bloc 42 d’éléments d’interface pour communiquer avec des dispositifs externes, par exemple un serveur distant ou le « cloud » ou les véhicule 2. Les éléments d’interface du bloc 42 peuvent comprendre une ou plusieurs des interfaces suivantes : interface radiofréquence RF, par exemple de type Wi-Fi® (selon IEEE 802.11), par exemple dans les bandes de fréquence à 2,4 ou 5 GHz, ou de type Bluetooth® (selon IEEE 802.15.1), dans la bande de fréquence à 2,4 GHz, ou de type Sigfox utilisant une technologie radio UBN (de l’anglais Ultra Narrow Band, en français bande ultra étroite), ou LoRa dans la bande de fréquence 868 MHz, LTE (de l’anglais « Long-Term Evolution » ou en français « Evolution à long terme »), LTE-Advanced (ou en français LTE-avancé) ; interface USB (de l’anglais « Universal Serial Bus » ou « Bus Universel en Série » en français) ; interface HDMI (de l’anglais « High Definition Multimedia Interface », ou « Interface Multimedia Haute Definition » en français). Selon un autre exemple de réalisation particulier et non limitatif, le dispositif de traitement 10 comprend une interface de communication 43 qui permet d’établir une communication avec d’autres dispositifs via un canal de communication 45. L’interface de communication 43 correspond par exemple à un transmetteur configuré pour transmettre et recevoir des informations et/ou des données via le canal de communication 45. L’interface de communication 43 correspond par exemple à un réseau filaire de type CAN (de l’anglais « Controller Area Network » ou en français « Réseau de contrôleurs »), CAN FD (de l’anglais « Controller Area Network Flexible Data-Rate » ou en français « Réseau de contrôleurs à débit de données flexible »), FlexRay (standardisé par la norme ISO 17458), Ethernet (standardisé par la norme ISO/IEC 802-3) ou LIN (de l’anglais « Local Interconnect Network », ou en français « Réseau interconnecté local »). Le dispositif de traitement 10 coopèrent par exemple avec les véhicules 2 au moyen du bloc 42 d’éléments d’interface ou de l’interface de communication 43, comme décrit précédemment. Selon un exemple de réalisation particulier et non limitatif, le dispositif de traitement 10 peut fournir des signaux de sortie à un ou plusieurs dispositifs externes, tels qu’un écran d’affichage, tactile ou non, un ou des haut-parleurs et/ou d’autres périphériques (système de projection) via des interfaces de sortie respectives. Selon une variante, l’un ou l’autre des dispositifs externes est intégré au dispositif de contrôle 10. La illustre un diagramme des différentes étapes d’un procédé de traitement pour la mise à jour d’au moins un logiciel, tel que par exemple du logiciel PG1 dans le ou les véhicules 2 comme précédemment décrit. Le procédé est par exemple mis en œuvre par le dispositif de traitement 10 précédemment décrit, ce dispositif pouvant être un serveur distant vis-à-vis des véhicules 2. Dans une première étape 51, un nombre N de versions possibles que peut présenter ledit au moins un logiciel PG1 est déterminé, N étant un entier au moins égal à 2, les N versions étant organisées selon un ordre chronologique depuis une version la plus ancienne jusqu’à une version la plus à jour. Dans une deuxième étape 52, un profil P de mise à jour est déterminé, ce profil P définissant au moins une condition à respecter par une mise à jour OP dudit au moins logiciel PG1 depuis une version initiale Va vers une version cible Vb dudit logiciel Dans une troisième étape 53, un indice de complexité C représentatif d’une complexité dudit au moins logiciel PG1 est déterminé à partir du nombre N et du profil P. Dans une troisième étape 54, une capacité à mettre à jour ledit au moins un logiciel PG1 est évaluée par comparaison de l’indice de complexité C avec une valeur de référence. Selon des variantes de réalisation, les variantes et exemples des opérations décrits ci-avant en relation avec les figures 1-10 s’appliquent aux étapes du procédé de traitement de la . Comme le comprend l’homme du métier, tous les modes de réalisation et variantes décrits ci-avant dont certains ont été simplifiés à dessein pour faciliter les explications, ne constituent que des exemples non limitatifs de mise en œuvre de la présente divulgation. En particulier, l’homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant, afin de répondre à un besoin particulier. La présente invention ne se limite donc pas aux exemples de réalisation décrits ci-avant mais s’étend notamment à un procédé de traitement qui inclurait des étapes secondaires sans pour cela sortir de la portée de la présente invention. Il en serait de même d’un dispositif configuré pour la mise en œuvre d’un tel procédé. Procédé de traitement mis en œuvre par un dispositif de traitement (10) pour aider à mettre à jour au moins un logiciel (PG1) implémentable dans un groupe (3) d’au moins un véhicule (2), ledit procédé comprenant : - détermination (51) d’un nombre N de versions (V) possibles que peut présenter ledit au moins un logiciel, N étant un entier au moins égal à 2, les N versions étant organisées selon un ordre chronologique depuis une version la plus ancienne jusqu’à une version la plus à jour ; - détermination (52) d’un profil P de mise à jour définissant au moins une condition à respecter par une mise à jour (OP) dudit au moins logiciel depuis une version initiale (Va) vers une version cible (Vb) dudit logiciel ; - détermination (53), à partir du nombre N et du profil P, d’un indice de complexité C représentatif d’une complexité dudit au moins logiciel (PG1) ; et - évaluation (54) d’une capacité (RS) à mettre à jour ledit au moins un logiciel par comparaison de l’indice de complexité C avec une valeur de référence. Procédé selon la revendication 1, dans lequel le profil (P) de mise à jour définit au moins l’une des conditions suivantes : a) la mise à jour est réalisée de façon incrémentale depuis la version initiale (Va) jusqu’à la version cible (Vb) ou la mise à jour est réalisée de façon directe depuis la version initiale (Va) jusqu’à la version cible (Vb) ; b) la version cible (Vb) de la mise à jour est la version la plus à jour ou la version cible (Vb) est une quelconque version plus à jour que la version initiale (Va) ; et c) la mise à jour (OP) comprend une rétrogradation de version dudit au moins un logiciel depuis une version intermédiaire vers la version finale (Vb). Procédé selon la revendication 1 ou 2, N étant un entier au moins égal à 3 ou au moins égal à 4. Procédé selon l’une quelconque des revendications précédentes, dans lequel la valeur de référence est une valeur seuil, l’évaluation de ladite capacité (RS) comprenant : - émission d’une alerte (AL) si l’indice de complexité C atteint la valeur seuil. Procédé selon l’une quelconque des revendications précédentes, dans lequel le procédé comprend au moins l’un parmi : - évaluation, à partir de l’indice de complexité C et/ou de la capacité (RS) à mettre à jour, d’une capacité à réaliser sur une période donnée une campagne de mises à jour sur ledit au moins un logiciel implémenté dans le groupe d’au moins un véhicule ; et - définition, à partir de l’indice de complexité C et/ou de la capacité (RS) à mettre à jour, d’une stratégie de mise à jour dudit au moins un logiciel (PG1) implémenté dans le groupe d’au moins un véhicule. Procédé selon l’une quelconque des revendications précédentes, dans lequel : - au moins deux couples différents (N, P) sont déterminés pour mettre à jour ledit au moins logiciel (PG1) selon respectivement au moins deux configurations différentes de mise à jour ; et - un indice de complexité C est déterminé pour respectivement chaque couple (N, P) ; le procédé comprenant en outre : - détermination d’un rapport de complexité entre lesdites au moins deux configurations de mise à jour par comparaison de leurs indices de complexité respectifs. Procédé selon la revendication 6, comprenant : - détermination, à partir du rapport de complexité, de la configuration de mise à jour la moins complexe ; et - sélection de la configuration de mise à jour la moins complexe pour mettre à jour ledit au moins un logiciel (PG1). Procédé selon l’une quelconque des revendications précédentes, dans lequel l’indice de complexité C est déterminé à partir d’une formule de calcul prenant en entrée N, ladite formule de calcul étant sélectionnée en fonction du profil P de mise à jour. Programme d’ordinateur (PG2) comportant des instructions pour la mise en œuvre du procédé selon l’une quelconque des revendications précédentes, lorsque ces instructions sont exécutées par un processeur. Dispositif de traitement (10) pour aider à mettre à jour au moins un logiciel (PG1) implémenté dans un groupe (3) d’au moins un véhicule (2), ledit dispositif (10) comprenant une mémoire (41) associée à au moins un processeur (40) configuré pour la mise en œuvre des étapes du procédé selon l’une quelconque des revendications 1 à 8.