Brevet FR3151110A1 — publié le 20250117

La présente invention concerne un procédé et un dispositif de contrôle d’un ensemble d’applications embarquées dans un véhicule, une pluralité de modes d’exécution étant associés à chaque application, des besoins en ressources étant associées à chaque mode d’exécution. A cet effet, une requête de configuration de l’ensemble d’applications est reçue (61). Un ou plusieurs modes d’exécution sont déterminés (62) pour chaque application en fonction des besoins en ressources et des ressources disponibles. Un niveau d’acceptation utilisateur associé à chaque mode d’exécution est en outre déterminé. Un mode d’exécution est sélectionné (63) en fonction des niveaux d’acceptation utilisateur. L’exécution de l’ensemble d’applications est contrôlée (64) en fonction des modes d’exécution sélectionnés. Figure pour l’abrégé : Figure 6 Procédé et dispositif de contrôle d’applications embarquées dans un véhicule La présente invention concerne les procédés et dispositifs ou systèmes de contrôle d’un ensemble d’applications embarquées dans un véhicule, notamment un véhicule automobile. La présente invention concerne également un procédé et un dispositif de contrôle du mode d’exécution selon lequel chaque application est mise en œuvre dans le véhicule. Arrière-plan technologique Les véhicules contemporains embarquent nombre de calculateurs assurant chacun une ou plusieurs fonctions, telles que par exemple la gestion de l’aide à la conduite, de l’antipatinage, de la répartition électronique du freinage, la commande d’actionneurs pour assurer le fonctionnement optimal d’un moteur, le pilotage et le contrôle du système d’infodivertissement, aussi appelé système IVI (de l’anglais « In-Vehicle Infotainment » ou en français « Infodivertissement embarqué ») et/ou d’autres systèmes embarqués dans le véhicule tels que par exemple le système de climatisation et le système de navigation du véhicule. Ces calculateurs sont aussi appelés UCE (« Unité de Commande Electronique » ou en anglais ECU « Electronic Control Unit »). Ces calculateurs embarquent des logiciels qui sont exécutés pour assurer les fonctions dont ils ont la charge. A titre d’exemple, un calculateur moteur, aussi appelé « boîtier de servitude moteur » ou « unité de commande moteur », est configuré pour collecter des données d’entrée (de capteurs ou autres), traiter ces données et envoyer des signaux de commande à divers composants (actionneurs) du moteur. Ces applications correspondent à des modules logiciels mis en œuvre par un ou plusieurs calculateurs du véhicule, certaines de ces applications correspondant à des applications interactives, également appelées vignette interactive (de l’anglais « widget »). Ces applications embarquées sont prévues pour être mises à jour, par exemple pour améliorer le fonctionnement de ces applications ou pour offrir plus de services aux utilisateurs du véhicule, via le téléchargement de données de mises à jour selon un mode de communication dit OTA (de l’anglais « Over The Air » ou en français « par voie aérienne ») ou FOTA (de l’anglais « Firmware Over-The-Air » ou en français « firmware par liaison radio »), les véhicules disposant d’un système de communication configuré pour communiquer via un réseau sans fil avec un ou plusieurs dispositifs distants du « cloud » (ou « nuage » en français) par exemple. Les applications embarquées peuvent en outre être complétées par l’installation de nouvelles applications, enrichissant ainsi l’offre de services embarqués proposés aux utilisateurs du véhicule. Un des problèmes qui se pose est que l’évolution logicielle du véhicule, avec l’accroissement des besoins en ressources (en termes de puissance de calcul, d’empreinte mémoire, de bande passante, etc.) qui en découle, se fait avec une architecture matérielle prévue lors de la conception du véhicule, laquelle peut se révéler parfois insuffisante pour assurer la mise en œuvre de plusieurs applications en parallèle. L’exécution simultanée de plusieurs applications peut ainsi générer des problèmes avec un fonctionnement dégradé d’une ou plusieurs applications, une interruption de la mise en œuvre d’une ou plusieurs applications, ce qui dégrade l’expérience utilisateur. Résumé de la présente invention Un objet de la présente invention est de résoudre au moins l’un des problèmes de l’arrière-plan technologique décrit précédemment. Un autre objet de la présente invention est d’améliorer le fonctionnement des applications embarquées dans un véhicule. Un autre objet de la présente invention est par exemple d’améliorer l’expérience utilisateur vis-à-vis de l’exécution des applications embarquées dans le véhicule. Selon un premier aspect, la présente invention concerne un procédé de contrôle d’un ensemble d’applications embarquées dans un véhicule, une pluralité de modes d’exécution étant associés à chaque application de l’ensemble d’application, des premières données représentatives de besoins en ressources étant associées à chaque mode d’exécution de la pluralité de modes d’exécution, le procédé comprenant les étapes suivantes : - réception d’une requête de configuration de l’ensemble d’applications, la requête comprenant des deuxièmes données représentatives de ressources courantes disponibles associées au véhicule ; - détermination, pour chaque application de l’ensemble d’applications, de : ● un ensemble de modes d’exécution dans la pluralité de modes d’exécution en fonction des premières et deuxièmes données, l’ensemble de modes d’exécution comprenant au moins un mode d’exécution, et ● une information représentative de niveau d’acceptation utilisateur associé à chaque mode d’exécution de l’ensemble de modes d’exécution, dite information AXIL ; - sélection, pour chaque application de l’ensemble d’applications, d’un mode d’exécution dans l’ensemble de modes d’exécution en fonction des informations AXIL ; - contrôle d’exécution de l’ensemble d’applications en fonction des modes d’exécution sélectionnés. Un tel procédé permet de sélectionner un ou plusieurs modes d’exécution pour chaque application à mettre en œuvre par le véhicule en fonctions des besoins en ressources associées à ce ou ces modes d’exécution et en fonction des ressources disponibles au niveau du véhicule. La prise en compte d’un niveau d’acceptation de chaque mode d’exécution par un utilisateur permet de choisir les modes d’exécution les plus adaptés pour améliorer l’expérience utilisateur. L’introduction d’un nouveau critère relatif à l’expérience utilisateur pour la sélection du mode de fonctionnement ou d’exécution de l’ensemble d’applications permet d’améliorer la satisfaction des utilisateurs, tout en prenant en compte la réalité physique (ressources disponibles et ressources nécessaires) pour la mise en œuvre ou l’exécution des applications dans un contexte donné. Selon une variante, la pluralité de modes d’exécution associés à chaque application comprend un mode d’exécution nominal représentatif d’un mode selon lequel chaque application est exécutée pour fonctionner selon un niveau de performance de référence, un mode d’exécution désactivée selon lequel chaque application n’est pas exécutée et au moins un mode d’exécution additionnel selon lequel chaque application est exécutée pour fonctionner dans un mode dégradé avec un niveau de performance inférieur au niveau de performance de référence ou dans un mode augmenté avec un niveau de performance supérieur au niveau de performance de référence. Selon une autre variante, l’information AXIL est déterminée à partir de : - métadonnées représentatives d’un niveau d’acceptation utilisateur associées à chaque mode d’exécution de la pluralité de modes d’exécution ; et/ou - règles de calcul du niveau d’acceptation utilisateur associées à chaque mode d’exécution de la pluralité de modes d’exécution en fonction d’un ensemble de paramètres de profil utilisateur et/ou de paramètres de contexte d’exécution. Selon une variante supplémentaire, le niveau d’acceptation utilisateur est fonction d’un ensemble de critères d’évaluation comprenant : - un premier critère représentatif d’un niveau de facilité à assurer une fonction sans assistance de chaque application ; - un deuxième critère représentatif d’un taux d’utilisation de chaque application ; et - un troisième critère représentatif d’un niveau de qualité de service perçue pour chaque mode d’exécution. Selon une variante additionnelle, le contrôle d’exécution est en outre fonction de : - un paramètre représentatif d’une durée minimale de commutation pour changer de mode d’exécution, la durée minimale de commutation étant fonction d’un contexte courant d’exécution de chaque application ; et/ou - un paramètre représentatif d’une consommation d’énergie par chaque application dans le mode d’exécution sélectionné. Selon encore une variante, les ressources des besoins en ressources et les ressources courantes appartiennent à un ensemble de ressources comprenant : - des ressources de calcul ; - des ressources mémoire ; et - des ressources réseau. Selon un deuxième aspect, la présente invention concerne un dispositif de contrôle d’un ensemble d’applications embarquées dans un véhicule, le dispositif comprenant une mémoire associée à un processeur configuré pour la mise en œuvre des étapes du procédé selon le premier aspect de la présente invention. Selon un troisième aspect, la présente invention concerne un véhicule, par exemple de type automobile, comprenant un dispositif tel que décrit ci-dessus selon le deuxième aspect de la présente invention. Selon un quatrième aspect, la présente invention concerne un programme d’ordinateur qui comporte des instructions adaptées pour l’exécution des étapes du procédé selon le premier aspect de la présente invention, ceci notamment lorsque le programme d’ordinateur est exécuté par au moins un processeur. Un tel programme d’ordinateur peut utiliser n’importe quel langage de programmation, et être sous la forme d’un code source, d’un code objet, ou d’un code intermédiaire entre un code source et un code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. Selon un cinquième aspect, la présente invention concerne un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé selon le premier aspect de la présente invention. D’une part, le support d’enregistrement peut être n'importe quel entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire ROM, une mémoire RAM, 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 à 6 annexées, sur lesquelles : illustre schématiquement un système embarqué de véhicule, selon un exemple de réalisation particulier et non limitatif de la présente invention. illustre schématiquement une table définissant un ensemble de niveaux d’acceptation utilisateur de modes d’exécution pour des applications mises en œuvre par le système embarqué du véhicule de la , selon un exemple de réalisation particulier et non limitatif de la présente invention. illustre schématiquement un processus de détermination de niveau d’acceptation utilisateur pour chaque mode d’exécution d’un ensemble d’applications mises en œuvre par le système embarqué du véhicule de la , selon un exemple de réalisation particulier et non limitatif de la présente invention. illustre schématiquement un processus d’optimisation de niveau d’acceptation utilisateur pour chaque mode d’exécution d’un ensemble d’applications mises en œuvre par le système embarqué du véhicule de la , selon un exemple de réalisation particulier et non limitatif de la présente invention. illustre schématiquement un dispositif de contrôle d’un ensemble d’applications embarquées dans le véhicule de la , selon des exemples de réalisation particuliers et non limitatifs de la présente invention ; et illustre un organigramme des différentes étapes d’un procédé de contrôle d’un ensemble d’applications embarquées dans le véhicule de la , selon un exemple de réalisation particulier et non limitatif de la présente invention. Description des exemples de réalisation Un procédé et un dispositif de contrôle d’un ensemble d’applications embarquées dans un véhicule vont maintenant être décrits dans ce qui va suivre en référence conjointement aux figures 1 à 6. Des mêmes éléments sont identifiés avec des mêmes signes de référence tout au long de la description qui va suivre. Les termes « premier(s) », « deuxième(s) » (ou « première(s) », « deuxième(s) »), etc. sont utilisés dans ce document par convention arbitraire pour permettre d’identifier et de distinguer différents éléments (tels que des opérations, des moyens, etc.) mis en œuvre dans les modes de réalisation décrits ci-après. De tels éléments peuvent être distincts ou correspondre à un seul et unique élément, selon le mode de réalisation. Selon un exemple particulier et non limitatif de réalisation de la présente invention, le contrôle de l’exécution ou de la mise en œuvre d’un ensemble d’applications embarquées dans un véhicule, par exemple par un ou plusieurs calculateurs du système embarqué du véhicule, comprend la réception d’une requête de configuration de l’ensemble d’applications. Une telle requête est par exemple reçue par un calculateur du système embarqué lorsqu’une ou plusieurs conditions d’un contexte courant de mise en œuvre des applications varient (par exemple avec la réception d’une requête pour exécuter une nouvelle application, lorsque des ressources du véhicule sont mobilisées pour le déclenchement d’un nouveau service, lorsque la bande passante disponible au niveau du réseau auquel est connecté lé véhicule varie, etc.). Une telle requête comprend des deuxièmes données représentatives de ressources courantes disponibles associées au véhicule, par exemple des ressources de calcul, de mémoire ou des ressources réseau. Il est déterminé pour chaque application de l’ensemble d’applications un ensemble de modes d’exécution parmi une pluralité de modes d’exécution associées à chaque application de l’ensemble en fonction de premières données représentatives des besoins en ressources associés à chaque mode d’exécution et en fonction des deuxièmes données. Il est également déterminé une information représentative d’un niveau d’acceptation utilisateur associé à chaque mode d’exécution de l’ensemble de modes d’exécution, dite information AXIL (de l’anglais « Automotive eXperience Integrity Level » ou en français « niveau d’intégrité d’expérience automobile »). Cette information AXIL est par exemple associée à chaque mode d’exécution disponible pour une application ou est déterminée en fonction de règles prenant comme critères d’entrée des paramètres d’un profil utilisateur et/ou d’un contexte d’exécution courant de l’ensemble d’applications. L’information AXIL est utilisée pour sélectionne, pour chaque application, un mode d’exécution parmi le ou les modes d’exécutions déterminés pour chaque application en fonction des premières et deuxièmes données. L’exécution de l’ensemble d’applications est contrôlée selon les modes d’exécution sélectionnés pour l’ensemble d’applications. Un tel procédé permet ainsi de prendre en compte un critère relatif à l’expérience utilisateur dans la gestion ou le contrôle de l’exécution d’un ensemble d’applications embarquées, permettant ainsi de maximiser l’expérience utilisateur en fonction des applications à faire fonctionner en parallèle selon les ressources disponibles au niveau du véhicule, dans un contexte d’exécution donné. Cela permet ainsi de d’assurer un certain niveau de qualité service tel que défini par exemple dans un document de type SLA (de l’anglais « Service-Level Agreement » ou en français « accord de niveau de service ») fourni au fabricant ou au concepteur d’une application. Un tel procédé permet en outre d’adapter les conditions d’exécution (ou « runtime » en anglais) des applications sur la base des capacités réseau et matériel disponibles. L’utilisation du niveau AXIL permet par exemple d’optimiser l’expérience utilisateur générale en utilisant par exemple des modes d’exécution dégradés pour certaines des applications, plutôt que de désactiver totalement une ou plusieurs applications pour permettre aux autres applications de tourner pour assurer les services associés. Le procédé permet ainsi d’exécuter plus d’applications en parallèle, quitte à faire fonctionner certaines de ces applications dans un mode dégradé acceptable par l’utilisateur, le niveau d’acceptation étant défini par l’information AXIL. Cela permet ainsi de faire évoluer le véhicule d’un point de vue applicatif en autorisant la mise en œuvre de plus d’applications avec une même configuration matérielle du véhicule. La illustre schématiquement l’architecture électronique et électrique, dite architecture E/E, d’un véhicule 10, selon un exemple de réalisation particulier et non limitatif de la présente invention. L’architecture E/E comprend un ensemble de calculateurs ou ECUs 101, 102, 13 reliés entre eux par des bus de données pour former un réseau mixant par exemple plusieurs technologies telles qu’Ethernet (selon la norme ISO/IEC 802-3) d’une part et 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 »), LIN (de l’anglais « Local Interconnect Network », ou en français « Réseau interconnecté local ») ou FlexRay (selon la norme ISO 17458) d’autre part. Une telle architecture correspond par exemple à une architecture dite ZOA (de l’anglais « Zonal Oriented Architecture » ou en français « architecture orientée zones »), une telle architecture étant orienté service (ou SOA, de l’anglais « Service Oriented Architecture »). Une telle architecture est connue de l’homme du métier et est par exemple décrite dans le document intitulé « Making the Case for Centralized Automotive E/E Architectures » publié par Victir Bandur, Gehan Selim, Vera Pantelic at Mark Lawford le 02 février 2021. L’ensemble de calculateurs comprend par exemple des premiers calculateurs chacun illustré par un rectangle blanc 101 sur la reliés entre eux par une dorsale (de l’anglais « backbone ») de type Ethernet. Ces premiers calculateurs correspondent par exemple à des ECU de type HPC (de l’anglais « High Performance Computing » ou en français « Calcul haute performance »). L’ensemble de calculateurs comprend en outre des deuxièmes calculateurs chacun illustré par un rectangle gris 102 de dimensions inférieures au rectangle blanc 101 et des troisièmes calculateurs chacun illustré par un rectangle noir 103 de dimensions inférieures au rectangle gris 102. Ces deuxièmes et troisièmes calculateurs sont reliés entre eux et aux premiers calculateurs 101 pour former des réseaux de type CAN, CAN FD ou LIN par exemple, ces premiers et deuxièmes calculateurs correspondant à des calculateurs spécialisés et/ou contrôlant des actionneurs et/ou capteurs. Les services proposés à un utilisateur du véhicule et obtenus via la mise en œuvre ou l’exécution d’une ou plusieurs applications partagent la dorsale Ethernet malgré les besoins très variés en termes de QoS (de l’anglais « Quality-of-Service » ou en français « Qualité de service »). Une application de divertissement pour la diffusion en flux continu (de l’anglais « streaming ») de vidéo (application de type « au mieux » ou « best-effort application » en anglais) n’a ainsi pas les mêmes besoins en termes de ressources qu’une application de contrôle du moteur temps réel (application sensible au temps), par exemple en termes de bande passante, latence, gigue (de l’anglais « jitter »), taux de perte (de l’anglais « loss rate »), qualité de service, charge de calcul (CPU), empreinte mémoire, etc. Bien entendu, l’architecture E/E embarquée dans le véhicule 10 ne se limite pas à l’exemple ci-dessus mais s’étend à tout type d’architecture, par exemple une architecture orientée domaine ou encore une architecture centralisée (avec passerelle centralisée), de telles architectures étant également décrites dans le document intitulé « Making the Case for Centralized Automotive E/E Architectures ». Un processus de contrôle d’un ensemble d’applications embarquées dans le véhicule pour le véhicule 10 est avantageusement mis en œuvre par un ou plusieurs processeurs d’un ou plusieurs calculateurs du véhicule 10, par exemple un calculateur 101 de l’architecture E/E du véhicule 10 faisant office de contrôleur par exemple. Dans une première opération du processus, une requête de configuration ou de reconfiguration d’un ensemble d’applications est reçue. L’ensemble d’applications comprend par exemple une pluralité d’applications en cours de fonctionnement ou en cours d’exécution au moment de la réception de la requête. La requête est par exemple générée lors d’un changement de contexte au niveau du véhicule 10, par exemple un changement de contexte au niveau de l’architecture E/E. Un changement de contexte est par exemple détecté lors de la réception d’une requête d’exécution d’une ou plusieurs nouvelles applications en plus de la ou les applications déjà en cours d’exécution. Une requête d’exécution d’une nouvelle application est par exemple reçue d’une interface homme-machine du véhicule 10 lorsque la requête émane d’un utilisateur souhaitant la mise en œuvre d’un ou plusieurs services via cette nouvelle application. Selon un autre exemple, une requête d’exécution d’une nouvelle application est par exemple générée par un calculateur du véhicule 10 contrôlant un système ADAS (de l’anglais « Advanced Driver-Assistance System » ou en français « Système d’aide à la conduite avancé ») du véhicule 10. Par exemple, le véhicule 10 peut recevoir des données via un mode de communication de type V2X (de l’anglais « Vehicle-to-Everything » ou en français « Véhicule vers tout ») requérant la mise en œuvre d’un service particulier pour optimiser le trafic par exemple, la mise en œuvre de l’application associée étant par exemple prioritaire par rapport aux applications de type « au mieux ». Selon encore un exemple, un changement de contexte est détecté lorsqu’un composant de l’architecture E/E rencontre un problème réduisant par exemple les ressources disponibles pour la mise en œuvre des applications et services associés. La requête de configuration ou de reconfiguration comprend avantageusement des deuxièmes données représentatives de ressources courantes disponibles au niveau du véhicule 10, par exemple en termes de puissance de calcul disponibles, de taille mémoire disponible, de périphériques disponibles ou encore en termes de ressources réseau (bande passante, latence, gigue). Dans une deuxième opération du processus, le calculateur en charge du processus détermine pour chaque application de l’ensemble d’applications (application(s) en cours d’exécution lors de la réception de la requête ainsi que la ou les nouvelles applications et/ou nouveau(x) service(s) dont la mise en œuvre est requise) : - un ensemble de modes d’exécution parmi une pluralité de modes d’exécution disponibles pour chaque application en fonction des premières données représentatives des besoins en ressources de chaque application et des deuxièmes données représentatives des ressources disponibles, et - une information représentative d’un niveau d’acceptation utilisateur associé à chaque mode d’exécution de l’ensemble de modes d’exécution, dite information AXIL. Chaque application est configurée pour être mise en œuvre ou exécutée selon une pluralité de modes d’exécutions (de l’anglais « runtime mode »), lesquels sont par exemple définis par le concepteur ou le développeur de l’application. Chaque mode d’exécution est par exemple identifiée via un identifiant unique (par exemple codée sur 2 ou plus de bits), la requête d’exécution d’une application comprenant avantageusement l’information relative à l’identification du mode d’exécution selon lequel l’application doit fonctionner ou être mise en œuvre. Le nombre de modes d’exécution associés à ou disponibles pour une application dépend par exemple du type d’application et varie par exemple d’une application à une autre. La pluralité de modes d’exécution associées à une application données comprend au minimum 2 modes d’exécution, à savoir : - un premier mode correspondant à un mode d’exécution dite nominale ou standard, un tel premier mode étant représentatif d’un mode selon lequel l’application est exécutée pour fonctionner selon un niveau de performance de référence (tous les services obtenus par l’application sont mis en œuvre tels qu’attendu) ; et - un deuxième mode correspondant à un mode d’exécution dite désactivée selon lequel l’application n’est pas exécutée, c’est-à-dire que l’exécution de l’application est reportée ou tout simplement annulée. Pour au moins une partie des applications embarquées, la pluralité de modes d’exécution disponibles comprend en outre un ou plusieurs modes d’exécutions additionnels, avec par exemple : - un ou plusieurs modes d’exécution dégradés, c’est-à-dire que le niveau de performance obtenu dans un tel mode dégradé est inférieur au niveau de performance de référence, c’est-à-dire que seule une partie des services associés à l’application est mise en œuvre, la qualité de service est inférieure à la qualité de service attendue dans le premier mode d’exécution, etc. ; un mode d’exécution dégradé requiert moins de ressources que le mode d’exécution nominal ; et/ou - un ou plusieurs modes d’exécution augmentés, c’est-à-dire que le niveau de performance obtenu dans un tel mode augmenté est supérieur au niveau de performance de référence, c’est-à-dire que la qualité de service est supérieure à la qualité de service attendue dans le premier mode d’exécution ; un mode d’exécution augmenté requiert plus de ressources que le mode d’exécution nominal. En prenant comme exemple une application de diffusion de vidéo en continu, le mode d’exécution de référence prévoit par exemple une diffusion de vidéo avec une définition égale à 1080p, un premier mode dégradé prévoit une diffusion de vidéo avec une définition égale à 720p, un deuxième mode dégradé prévoit une définition égale à 360p, un quatrième mode dégradé prévoit une définition égale à 144p, un cinquième mode dégradé prévoit de mettre en pause la diffusion pendant une durée déterminée (par exemple 5 ou 10 secondes), etc. En prenant comme exemple une application de téléchargement de contenu, un mode d’exécution augmenté prévoit par exemple un téléchargement de données avec un débit plus important que le débit prévu dans le mode nominal, un tel mode augmenté étant par exemple mis en œuvre lorsque le contexte le permet (bande passante disponible) et dans des situations particulières (par exemple avant que le véhicule ne pénètre dans une zone sans couverture réseau (par exemple une zone blanche, un tunnel)) pour que l’application puisse continuer de fonctionner pendant que le véhicule traverse cette zone sans couverture réseau. Chaque mode d’exécution est accompagné de premières données décrivant les besoins en termes de ressources nécessaires (puissance de calcul, empreinte mémoire, bande passante, latence, gigue, etc.) pour la mise en œuvre du mode d’exécution concerné. Ainsi, à chaque application est associée une pluralité de modes d’exécution et à chaque mode d’exécution est associée une liste de ressources nécessaires (minimales) pour la mise en œuvre du mode d’exécution. Ces informations, correspondant aux deuxièmes données, sont par exemple stockées dans une mémoire du calculateur mettant en œuvre le processus ou dans une mémoire du calculateur mettant en œuvre l’application, par exemple sous la forme d’une ou plusieurs LUT (de l’anglais « Look-Up Table » ou en français « table de correspondance »). Ces informations sont par exemple enregistrées dans le véhicule 10 lors de l’installation de l’application associée. Il est ainsi déterminé, pour chaque application de l’ensemble d’applications à mettre en œuvre, une liste ou un ensemble de modes d’exécution compatibles (comprenant au moins un mode d’exécution) avec les ressources disponibles dans le véhicule 10, connaissant les premières données fournissant les ressources disponibles selon le contexte courant d’exécution et les deuxièmes données décrivant les besoins en ressources pour chaque mode d’exécution de la pluralité de modes d’exécutions associée à chaque application embarquée. Il est en outre déterminé dans cette deuxième opération une information AXIL pour chaque application et pour chaque mode d’exécution de l’ensemble de modes d’exécution compatibles avec le contexte courant de l’architecture E/E. Cette information AXIL est par exemple obtenue de l’application elle-même ou d’une mémoire, cette information étant par exemple stockée dans une LUT en regard de chaque mode d’exécution de la pluralité de modes d’exécution disponibles pour chaque application embarquée dans le véhicule 10. Selon une variante de réalisation, cette information AXIL est déterminée selon une règle de calcul associée à chaque mode d’exécution de la pluralité de modes d’exécution disponibles pour chaque application embarquée dans le véhicule 10. Ces règles de calcul sont chacune fonction de paramètres particuliers qui dépendent par exemple de chaque application et/ou du type de l’application. L’information AXIL correspond par exemple à un niveau d’acceptation par l’utilisation d’un mode d’exécution dans un contexte particulier, ce niveau appartenant à un ensemble défini de niveaux comprenant par exemple 5 niveaux : niveau ‘QM’ (un utilisateur n’attache pas d’importance à un tel mode d’exécution, même si ce dernier correspond à un mode dégradé), niveau ‘A’ (un utilisateur peut ressentir une différence par rapport au mode nominal mais l’accepte sans problème), niveau ‘B’ (quelques utilisateurs ressentent une frustration pour la mise en œuvre selon ce mode d’exécution), niveau ‘C’ (de nombreux utilisateurs ressentent une frustration pour la mise en œuvre selon ce mode d’exécution) et niveau ‘D’ (mode d’exécution inacceptable en terme d’expérience utilisateur). Le niveau AXIL associé à chaque mode d’exécution est par exemple déterminé lors du développement ou de la conception du mode d’exécution, ce niveau AXIL étant alors fixé et statique dans le temps. Un tel niveau statique représente par exemple un utilisateur moyen. Selon un autre exemple, le niveau AXIL est déterminé dynamiquement à partir de règles prenant en compte un ensemble de paramètres ou critères tels que des paramètres d’un profil utilisateur (par exemple l’âge de l’utilisateur, les centres d’intérêts de l’utilisateur, les habitudes de l’utilisateur, un historique d’utilisation de l’application comprenant notamment une fréquence d’utilisation de l’application, un historique d’utilisation de modes d’exécution dégradé, un niveau d’abonnement, etc.) et/ou des paramètres de contexte (par exemple des conditions pour accepter un mode d’exécution, un lien ou une dépendance avec d’autres applications, etc.). Le niveau d’AXIL est par exemple déterminé en fonction de critères d’évaluations correspondant par exemple aux critères suivants : - un premier critère représentatif d’un niveau de facilité à assurer une fonction sans assistance de chaque application dans le mode d’exécution considéré, c’est-à-dire la facilité selon laquelle l’utilisateur peut se passer du service offert par l’application tout en réussissant à mettre en œuvre la fonction, ce premier critère prenant par exemple 3 niveaux (niveaux S1 à S3, S1 signifiant que l’utilisateur peur se passer facilement de l’application, S2 moyennement et S3 difficilement) : par exemple pour une application d’aide au stationnement, l’indisponibilité de la caméra de recul n’empêche pas un utilisateur moyen d’effectuer la manœuvre de stationnement sans assistance de la caméra, ou encore, si la qualité de rendu de musique d’une application de diffusion en continu de contenus audios est mauvaise, l’utilisateur peut utiliser temporairement son téléphone intelligent (de l’anglais « Smartphone ») connecté en Bluetooth® au véhicule 10 pour écouter de la musique ; - un deuxième critère représentatif d’un taux d’utilisation de chaque application dans le mode d’exécution considéré (comportant par exemple 4 niveaux E1 à E4, avec E1 pour une fréquence d’utilisation minimale et faible et E4 une fréquence maximale et très élevée) ; et - un troisième critère représentatif d’un niveau de qualité de service perçue pour chaque mode d’exécution (comportant par exemple 4 niveaux Q1 à Q4, avec le niveau Q1 correspondant à ‘frustrant’, le niveau Q2 correspondant à ‘ennuyeux’, le niveau Q3 correspondant à ‘acceptable’ et le niveau Q4 à ‘plaisant’). La table 20 illustré en fournit un exemple d’assignation de niveaux AXIL à chaque mode d’exécution d’une application en fonction des 3 critères d’évaluation définis ci-dessus, la colonne ‘SUBSTITUTION’ correspondant au premier critère, la colonne ‘UTILISATION’ correspondant au deuxième critère et la colonne ‘QUALITE DE SERVICE’ correspondant au troisième critère. Lorsque le niveau AXIL est déterminé selon des règles de calcul, les 3 critères définis ci-dessus sont par exemple déterminés dynamiquement à partir de règles définis pour chaque critère, le niveau AXIL étant alors calculé comme une fonction prenant en entrée la valeur obtenue pour chacun des 3 critères et fournissant en sortie une valeur d’AXIL par exemple comprise entre 0 et 1 (valeur flottante). Un exemple de processus de détermination de l’information ou du niveau AXIL est illustré sur la , selon un exemple de réalisation particulier. Dans une opération 31, lorsqu’un changement de contexte est détecté au niveau de l’infrastructure E/E (demande d’exécution d’une nouvelle application, lancement d’un nouveau service, détection d’un évènement impactant les ressources disponibles), une requête est transmise à chaque application en cours d’exécution pour requérir les modes d’exécution disponibles, les besoins en ressources associés à chaque mode d’exécution et les niveaux AXIL associés. Dans une opération 32, les modes d’exécutions disponibles et les besoins en ressources associés sont reçus en réponse à la requête transmise à l’opération 31. Ces informations sont par exemple reçues d’un composant connexe associé à chaque application. Dans une opération 33, le niveau AXIL est déterminé. Lorsque le niveau AXIL correspond à une information fixe reçue de l’application (par exemple sous la forme de métadonnées) ou d’une table enregistrée dans une mémoire, le niveau AXIL déterminé correspond à celle reçue, qui correspond par exemple à un utilisateur moyen. Lorsque le niveau AXIL est dynamique, les informations relatives au niveau AXIL reçues de l’application correspondent par exemple à des paramètres de règles (équations paramétriques par exemple) pour que soient calculés les niveaux AXIL, pour chaque mode d’exécution. Des informations 310 représentatives d’un contexte d’exécution pour chaque mode d’exécution ou de fonctionnement de l’application sont en outre reçues. Le niveau AXIL est ainsi défini en fonction des informations de contexte 310, de paramètres 330 représentatifs d’un profil utilisateur et/ou de contexte d’utilisation de l’application. Selon une variante, des données 34 représentatives d’un historique de l’application (par exemple les modes d’exécution déjà utilisés) sont en outre pris en compte pour la détermination du niveau AXIL. Un niveau AXIL 331 est ainsi déterminé dynamiquement. Selon une variante, un ou plusieurs paramètres additionnels sont déterminés à l’opération 31, tel que : - un paramètre 332 représentatif d’une durée minimale de commutation pour changer de mode d’exécution, la durée minimale de commutation étant fonction du contexte courant d’exécution 310 de chaque application ; le contexte courant d’une application peut impacter un changement de mode d’exécution requis, par exemple lorsque des tâches sont en cours d’exécution et qu’elles ne doivent pas être interrompues (par exemple lorsque le téléchargement d’un fichier est en cours, lorsque le véhicule 10 effectue une manœuvre sous la supervision d’un module ADAS contrôlé par l’application (par exemple une insertion sur une voie d’autoroute), etc.) ;et/ou - un paramètre 333 représentatif d’une consommation d’énergie par chaque application dans le mode d’exécution sélectionné : une estimation des besoins en énergie est par exemple mise en œuvre pour les fournir à l’infrastructure, ces besoins étant fonction des besoins en ressources associés à chaque mode d’exécution (besoins en ressources réseau et/ou en puissance de calcul). L’information 333 relative aux besoins en consommation d’énergie de chaque mode d’exécution est par exemple utilisée pour sélectionner un mode d’exécution plutôt qu’un autre, par exemple lorsque le véhicule 10 a été configuré (via une IHM par exemple) pour circuler dans un mode d’économie d’énergie avec par exemple une consigne de consommation maximale d’énergie à ne pas dépasser. Les paramètres d’entrée 310, 330, 34 sont utiles pour fournir ou calculer un niveau AXIL dépendant du contexte et du profil de l’utilisateur, lorsque le niveau AXIL est déterminé de manière dynamique. Par exemple, si une application doit s’interrompre pendant ‘t’ secondes à un instant temporel ‘T’ (en fonction des ressources disponibles sur cet intervalle) mais que l’application a déjà été interrompue il y a ‘n’ secondes (information obtenue de l’historique d’utilisation ou de l’historique des modes d’exécution utilisés), une nouvelle interruption impliquerait un niveau AXIL défini par une fonction ‘f’ prenant en considération les paramètres ‘t’, ‘T’ et ‘n’ (fonction f(t,T,n)) Dans une troisième opération du processus, un mode d’exécution est sélectionné parmi l’ensemble de modes d’exécution répondant aux critères des ressources disponibles en fonction des informations AXIL obtenues à la deuxième opération, pour chaque application de l’ensemble d’applications. La sélection des modes d’exécution pour l’ensemble d’application est mise en œuvre en prenant en compte les niveaux AXIL afin d’optimiser le niveau AXIL pour l’ensemble des applications et maximiser l’expérience utilisateur. Un tel processus est illustré selon un exemple de réalisation particulier sur la . Les éléments 41 à 44 de la correspondent par exemple à des modules ou briques matérielles ou fonctionnelles d’un ou plusieurs composants matériels, par exemple un ECU, de l’infrastructure du véhicule 10. Les contraintes de l’infrastructure E/E sont fournies dans par un ou plusieurs contrôleurs 41 de l’infrastructure E/E du véhicule 10 lorsqu’un changement d’état de l’infrastructure est requis. Ces contraintes de l’infrastructure E/E du véhicule 10 comprennent par exemple : - une description de la topologie physique de l’infrastructure du véhicule 10 (par exemple la liste des ECU, la topologie du réseau reliant les ECU, les capacités de chaque liaison du réseau, les capacités en termes de calcul (CPU) et mémoire, etc.) ; - une ou plusieurs listes de contraintes qui doivent être respectées lorsqu’une configuration est sélectionnée, par exemple : • une configuration réseau valide doit être trouvée avant changement d’état de l’infrastructure, • la consommation totale d’énergie d’une nouvelle configuration doit respecter une valeur maximale (seuil) fixé (par exemple par un utilisateur du véhicule 10), et • une partie de la bande passante doit rester disponible (par exemple 10 Mbit/s) dans toutes les liaisons du réseau. Un module 42 correspondant à un planificateur ou contrôleur des applications transmet une ou plusieurs requêtes à destination d’un module 43 configuré pour déterminer quels modes d’exécution répondent le mieux aux différentes contraintes. Une requête transmise par le module 42 au module 43 comprend par exemple une liste des applications à mettre en œuvre. Le module 43 contrôle la sélection des modes d’exécution pour la liste des applications à mettre en œuvre ou exécuter, en fonction notamment des contraintes reçues du module 41. Le module 43 comprend notamment une brique (logicielle) 433 configurée pour optimiser le niveau AXIL de la nouvelle configuration requise. Cette brique 433 requiert par exemple de chaque application 431 les modes d’exécutions disponibles avec les besoins en ressources associées et le niveau AXIL (ou les règles de calcul permettant de déterminer le niveau AXIL pour chaque mode d’exécution). Chaque application 431 transmet à une brique 432 les informations relatives au contexte d’exécution de l’application avec les règles de calcul, la brique 432 déterminant pour chaque application et chaque mode d’exécution un niveau AXIL (par exemple tel que décrit en regard de la ). Ces niveaux AXIL sont fournis à la brique 433 pour sélectionner un mode d’exécution pour chaque application de manière à optimiser le niveau AXIL pour l’ensemble des applications. La brique 433 met en œuvre une optimisation pour trouver un compromis optimal entre les niveaux AXIL des modes d’exécution permettant de respecter les contraintes, ou décide de désactiver une ou plusieurs applications ayant un niveau AXIL inférieur (par exemple un niveau ‘QM’ ou ‘A’). La brique 433 transmet en sortie une liste de modes d’exécution pour l’ensemble d’applications (1 mode d’exécution par application) à un module 44 contrôlant la configuration des applications, lequel module 44 transmet à destination de chaque brique applicative 431 le mode d’exécution à activer ou exécuter. Si aucune solution n’est trouvée par la brique 433, un état d’erreur est retourné. Une nouvelle configuration est alors recherchée par le module 42, par exemple en réduisant le nombre d’application à exécuter (un message est par exemple rendu sur un écran du véhicule 10 pour demander à l’utilisateur de choisir un nombre réduit d’applications à mettre en œuvre). Une nouvelle configuration déterminée par la brique 433 prend par exemple la forme d’une matrice avec une colonne pour chaque application de l’ensemble d’application et une ligne pour chaque mode d’exécution disponible, la matrice comprenant les niveaux AXIL pour chaque application et chaque mode d’exécution, les modes d’exécutions sélectionnés étant identifiées dans la matrice (par exemple par un couple d’identifiants Numéro de colonne / Numéro de ligne). Dans une quatrième opération du processus, l’exécution de l’ensemble d’applications est contrôlée en fonction des modes d’exécution sélectionnés, tel que décrit ci-dessus en regard de la . Chaque application de l’ensemble d’application reçoit une requête d’exécution selon le mode d’exécution sélectionné pour cette application (selon le mode d’exécution nominal, selon un mode dégradé ou augmenté ou encore selon le mode d’exécution désactivée). Pour illustrer le processus ci-dessous, il est considéré un exemple selon lequel le véhicule embarque les 4 applications suivantes : - une application de diffusion en continu de contenu vidéo (notée N) avec 5 modes d’exécution : mode 1080p, mode 720p, mode 360p, mode 144p, mode ‘interruption pour 5 secondes’ et mode arrêt ; - une application de diffusion en continu de contenu audio (notée M) avec 4 modes d’exécution : mode ‘haute qualité’, mode ‘basse qualité’, mode ‘interruption pour 5 secondes’ et mode arrêt ; - une application d’aide à la conduite, par exemple pour optimisation du trafic avec communication de données en V2X (notée V) avec 2 modes d’exécution : mode actif (application activée en mode nominal) et mode arrêt (application stoppée) ; et - une application de jeu (notée G) avec 3 modes d’exécution : mode actif, mode pause (ou interruption) et mode arrêt. Chaque mode d’exécution possède ses besoins en ressources de calcul (CPU, mémoire, périphériques) et ressources réseau (flux, utilisation de la bande passante, niveau de priorité). Lors du démarrage du véhicule 10, l’utilisateur requiert l’exécution de l’application M et un passager requiert l’exécution de l’application G. L’état courant ‘S’ du véhicule 10 défini par les applications à exécuter est ainsi S={M, G}. L’infrastructure requiert alors à la brique 433 de déterminer les modes d’exécutions optimaux pour S selon les contraintes courantes de l’infrastructure E/E. La brique 433 détermine par exemple que l’application M peut être exécutée selon le mode nominal (mode 1080p) et que l’application G peut également être exécutée selon mode nominal (mode actif). Lors du parcours du véhicule 10, une intersection est atteinte et le véhicule 10 détecte que l’intersection bénéficie d’un équipement de régulation du trafic utilisant un service V2X. Une requête d’exécution de l’application V est alors générée par le véhicule 10 (par exemple par le module 42) et la brique 433 reçoit une requête pour déterminer quels modes d’exécution pour l’état S = {M, G, V} sont possibles, selon les contraintes courantes et les niveaux AXIL déterminés pour chaque mode d’exécution. Cela aboutit par exemple à une exécution des applications M et V dans leur mode optimal et à une exécution de l’application G dans le mode dégradé dit de pause le temps que le véhicule 10 passe l’intersection et que l’application V ne soit plus nécessaire. La illustre schématiquement un dispositif 5 configuré pour contrôler un ensemble d’applications embarquées dans un véhicule, par exemple le véhicule 10, selon un exemple de réalisation particulier et non limitatif de la présente invention. Le dispositif 5 correspond par exemple à un dispositif embarqué dans le véhicule 10, par exemple un calculateur. Le dispositif 5 est par exemple configuré pour la mise en œuvre des opérations décrites en regard des figures 1 à 4 et/ou des étapes du procédé décrit en regard de la . Des exemples d’un tel dispositif 5 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 »), une unité TCU (de l’anglais « Telematic Control Unit » ou en français « Unité de Contrôle Télématique ») ou tout dispositif de traitement de données d’un système embarqué de véhicule. Les éléments du dispositif 5, 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 5 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 5 comprend un (ou plusieurs) processeur(s) 50 configurés pour exécuter des instructions pour la réalisation des étapes du procédé et/ou pour l’exécution des instructions du ou des logiciels embarqués dans le dispositif 5. Le processeur 50 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 5 comprend en outre au moins une mémoire 51 correspondant par exemple à une mémoire volatile et/ou non volatile et/ou comprend un dispositif de stockage mémoire qui peut comprendre de la mémoire volatile et/ou non volatile, telle que EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, disque magnétique ou optique. Le code informatique du ou des logiciels embarqués comprenant les instructions à charger et exécuter par le processeur est par exemple stocké sur la mémoire 51. Selon différents exemples de réalisation particuliers et non limitatifs, le dispositif 5 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 5 comprend un bloc 52 d’éléments d’interface pour communiquer avec des dispositifs externes. Les éléments d’interface du bloc 52 comprennent une ou plusieurs des interfaces suivantes : - interface radiofréquence RF, par exemple de type Wi-Fi® (selon IEEE 802.11), par exemple dans les bandes de fréquence à 2,4 ou 5 GHz, ou de type Bluetooth® (selon IEEE 802.15.1), dans la bande de fréquence à 2,4 GHz, ou de type Sigfox utilisant une technologie radio UBN (de l’anglais Ultra Narrow Band, en français bande ultra étroite), ou LoRa dans la bande de fréquence 868 MHz, LTE (de l’anglais « Long-Term Evolution » ou en français « Evolution à long terme »), LTE-Advanced (ou en français LTE-avancé) ; - interface USB (de l’anglais « Universal Serial Bus » ou « Bus Universel en Série » en français) ; - interface HDMI (de l’anglais « High Definition Multimedia Interface », ou « Interface Multimedia Haute Definition » en français) ; - interface LIN (de l’anglais « Local Interconnect Network », ou en français « Réseau interconnecté local »). Selon un autre exemple de réalisation particulier et non limitatif, le dispositif 5 comprend une interface de communication 53 qui permet d’établir une communication avec d’autres dispositifs (tels que d’autres calculateurs du système embarqué) via un canal de communication 530. L’interface de communication 53 correspond par exemple à un transmetteur configuré pour transmettre et recevoir des informations et/ou des données via le canal de communication 530. L’interface de communication 53 correspond par exemple à un réseau filaire de type CAN (de l’anglais « Controller Area Network » ou en français « Réseau de contrôleurs »), CAN FD (de l’anglais « Controller Area Network Flexible Data-Rate » ou en français « Réseau de contrôleurs à débit de données flexible »), FlexRay (standardisé par la norme ISO 17458) ou Ethernet (standardisé par la norme ISO/IEC 802-3). Selon un exemple de réalisation particulier et non limitatif, le dispositif 5 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 via des interfaces de sortie respectives. La illustre un organigramme des différentes étapes d’un procédé de contrôle d’un ensemble d’applications embarquées dans un véhicule, par exemple le véhicule 10, selon un exemple de réalisation particulier et non limitatif de la présente invention. Le procédé est par exemple mis en œuvre par un dispositif embarqué dans le véhicule 10 ou par le dispositif 5 de la . Dans une première étape 61, une requête de configuration de l’ensemble d’applications est reçue, la requête comprenant des deuxièmes données représentatives de ressources courantes disponibles associées au véhicule. Dans une deuxième étape 62, il est déterminé pour chaque application de l’ensemble d’applications : ● un ensemble de modes d’exécution dans la pluralité de modes d’exécution associés à chaque application de l’ensemble d’applications en fonction de premières données représentatives de besoins en ressources associées à chaque mode d’exécution de la pluralité de modes d’exécution et des deuxièmes données, l’ensemble de modes d’exécution comprenant au moins un mode d’exécution, et ● une information représentative de niveau d’acceptation utilisateur associé à chaque mode d’exécution de l’ensemble de modes d’exécution, dite information AXIL. Dans une troisième étape 63, un mode d’exécution est sélectionné dans l’ensemble de modes d’exécution en fonction des informations AXIL pour chaque application de l’ensemble d’applications. Dans une quatrième étape 64, l’exécution de l’ensemble d’applications est contrôlée en fonction des modes d’exécution sélectionnés. Selon une variante, les variantes et exemples des opérations décrits en relation avec les figures 1 à 4 s’appliquent aux étapes du procédé de la . Bien entendu, la présente invention ne se limite pas aux exemples de réalisation décrits ci-avant mais s’étend à un procédé d’optimisation de l’expérience utilisateur vis-à-vis de la mise en œuvre d’applications dans un véhicule qui inclurait des étapes secondaires sans pour cela sortir de la portée de la présente invention. Il en serait de même d’un dispositif configuré pour la mise en œuvre d’un tel procédé. La présente invention concerne également un véhicule, par exemple automobile ou plus généralement un véhicule autonome à moteur terrestre, comprenant le dispositif 5 de la . Procédé de contrôle d’un ensemble d’applications embarquées dans un véhicule (10), une pluralité de modes d’exécution étant associés à chaque application dudit ensemble d’applications, des premières données représentatives de besoins en ressources étant associées à chaque mode d’exécution de ladite pluralité de modes d’exécution, ledit procédé comprenant les étapes suivantes : - réception (61) d’une requête de configuration dudit ensemble d’applications, ladite requête comprenant des deuxièmes données représentatives de ressources courantes disponibles associées audit véhicule (10) ; - détermination (62), pour chaque application dudit ensemble d’applications, de : ● un ensemble de modes d’exécution dans ladite pluralité de modes d’exécution en fonction desdites premières et deuxièmes données, ledit ensemble de modes d’exécution comprenant au moins un mode d’exécution, et ● une information représentative de niveau d’acceptation utilisateur associé à chaque mode d’exécution dudit ensemble de modes d’exécution, dite information AXIL (331) ; - sélection (63), pour chaque application dudit ensemble d’applications, d’un mode d’exécution dans ledit ensemble de modes d’exécution en fonction des informations AXIL (331) ; - contrôle (64) d’exécution dudit ensemble d’applications en fonction des modes d’exécution sélectionnés. Procédé selon la revendication 1, pour lequel ladite pluralité de modes d’exécution associés à ladite chaque application comprend un mode d’exécution nominal représentatif d’un mode selon lequel ladite chaque application est exécutée pour fonctionner selon un niveau de performance de référence, un mode d’exécution désactivée selon lequel ladite chaque application n’est pas exécutée et au moins un mode d’exécution additionnel selon lequel ladite chaque application est exécutée pour fonctionner dans un mode dégradé avec un niveau de performance inférieur audit niveau de performance de référence ou dans un mode augmenté avec un niveau de performance supérieur audit niveau de performance de référence. Procédé selon la revendication 1 ou 2, pour lequel ladite information AXIL (331) est déterminée à partir de : - métadonnées représentatives d’un niveau d’acceptation utilisateur associées à chaque mode d’exécution de ladite pluralité de modes d’exécution ; et/ou - règles de calcul dudit niveau d’acceptation utilisateur associées à chaque mode d’exécution de ladite pluralité de modes d’exécution en fonction d’un ensemble de paramètres de profil utilisateur et/ou de paramètres de contexte d’exécution (330). Procédé selon la revendication 3, pour lequel ledit niveau d’acceptation utilisateur est fonction d’un ensemble de critères d’évaluation comprenant : - un premier critère représentatif d’un niveau de facilité à assurer une fonction sans assistance de ladite chaque application ; - un deuxième critère représentatif d’un taux d’utilisation de ladite chaque application ; et - un troisième critère représentatif d’un niveau de qualité de service perçue pour ledit chaque mode d’exécution. Procédé selon l’une des revendications 1 à 4, pour lequel ledit contrôle d’exécution est en outre fonction de : - un paramètre (332) représentatif d’une durée minimale de commutation pour changer de mode d’exécution, ladite durée minimale de commutation étant fonction d’un contexte courant d’exécution de ladite chaque application ; et/ou - un paramètre (333) représentatif d’une consommation d’énergie par ladite chaque application dans ledit mode d’exécution sélectionné. Procédé selon l’une des revendications 1 à 5, pour lequel les ressources des besoins en ressources et les ressources courantes appartiennent à un ensemble de ressources comprenant : - des ressources de calcul ; - des ressources mémoire ; et - des ressources réseau. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé selon l’une quelconque des revendications 1 à 6. Programme d’ordinateur comportant des instructions pour la mise en œuvre du procédé selon l’une quelconque des revendications 1 à 6, lorsque ces instructions sont exécutées par un processeur. Dispositif (5) de contrôle d’un ensemble d’applications embarquées dans un véhicule, ledit dispositif (5) comprenant une mémoire (51) associée à au moins un processeur (50) configuré pour la mise en œuvre des étapes du procédé selon l’une quelconque des revendications 1 à 6. Véhicule (10) comprenant le dispositif (5) selon la revendication 9.