FR3151458A1 - Procédé et dispositif de contrôle de configuration d’une infrastructure réseau d’un véhicule - Google Patents

Abstract

La présente invention concerne un procédé et un dispositif de contrôle de configuration d’une infrastructure réseau d’un véhicule suivant une détection de changement de contexte au niveau de l’infrastructure réseau. A cet effet, une configuration pour un ensemble d’application est sélectionnée (51) en fonction du changement de contexte. Une requête de reconfiguration est transmise (52) à chaque application en cours d’exécution et une réponse d’acceptation ou de refus de mise en œuvre de la reconfiguration est reçue (53) de chaque application en cours d’exécution. La faisabilité de la mise en œuvre de la configuration sélectionnée est déterminée (54) en fonction des réponses reçues et la configuration sélectionnée est mise en œuvre ou non (55) en fonction de la faisabilité. Figure pour l’abrégé : Figure 5

Description

Procédé et dispositif de contrôle de configuration d’une infrastructure réseau d’un véhicule

La présente invention concerne les procédés et dispositifs ou systèmes de contrôle de configuration d’une infrastructure réseau d’un véhicule, notamment un véhicule automobile. La présente invention concerne également un procédé et un dispositif 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.

Par ailleurs, la complexité de l’architecture électronique associée à l’hétérogénéité de la multitude de systèmes interconnectés des véhicules contemporains rendent difficiles la gestion des reconfigurations dynamiques de l’infrastructure logicielle et réseau du véhicule. Les solutions existantes ne permettent pas de garantir l’absence de dysfonctionnement de certaines applications et/ou de pertes de paquets de données échangés entre les différents composants du réseau lors de la mise en œuvre d’une reconfiguration alors que le véhicule est en circulation, ce qui impacte potentiellement la sécurité du véhicule.

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 la gestion de la configuration ou reconfiguration dynamique d’une infrastructure réseau d’un véhicule.

Un autre objet de la présente invention est de garantir le bon fonctionnement des applications embarquées dans un véhicule lors d’une reconfiguration de l’infrastructure réseau du véhicule.

Selon un premier aspect, la présente invention concerne un procédé de contrôle de configuration d’une infrastructure réseau d’un véhicule, le procédé comprenant les étapes suivantes :
- obtention de données représentatives d’une configuration d’un ensemble d’applications embarquées sélectionnée parmi une pluralité de configurations enregistrées dans une mémoire du véhicule suivant un changement de contexte d’exécution détecté au niveau de l’infrastructure réseau, un ensemble de paramètres représentatifs de la configuration sélectionnée étant associé à chaque application de l’ensemble d’applications, une première information représentative d’un délai maximal de mise en œuvre de la configuration sélectionnée étant comprise dans les données ;
- transmission, à destination de chaque application de l’ensemble d’application en cours d’exécution au niveau de l’infrastructure réseau, d’une première requête de reconfiguration de chaque application en cours d’exécution en fonction de l’ensemble de paramètres associé à chaque application en cours d’exécution ;
- réception, depuis chaque application en cours d’exécution, d’une réponse à la première requête, la réponse étant déterminée par chaque application en cours d’exécution à partir d’un contexte courant d’exécution de chaque application en cours d’exécution et de l’ensemble de paramètres, la réponse appartenant à un ensemble de réponses comprenant :
● une première réponse représentative d’une acceptation de mise en œuvre de la reconfiguration selon un mode d’exécution nominal,
● une deuxième réponse représentative d’une acceptation de mise en œuvre de la reconfiguration dans un mode d’exécution dégradé par rapport au mode d’exécution nominal,
les première et deuxième réponses comprenant chacune une deuxième information de délai minimal de mise en œuvre de la reconfiguration, et
● une troisième réponse représentative d’un refus de mise en œuvre de la reconfiguration ;
- détermination d’une faisabilité de la mise en œuvre de la configuration sélectionnée en fonction des réponses reçues des applications en cours d’exécution ;
- contrôle de mise en œuvre de la configuration sélectionnée en fonction de la faisabilité.

Un tel procédé permet de déterminer si une configuration requise pour répondre à un changement de contexte détecté au niveau de l’infrastructure réseau d’un véhicule est possible en vérifiant auprès de chaque application en cours d’exécution si une reconfiguration même temporaire de ces applications est acceptable et dans quel délai.

En fonction de la faisabilité, la configuration de l’infrastructure réseau du véhicule est mise en œuvre ou non, ce qui réduit les risques de défaillance des applications, notamment des applications critiques en termes de sécurité pour le véhicule.

Selon une variante, la détermination de la faisabilité comprend les étapes suivantes :
- détermination, pour chaque application en cours d’exécution, d’un premier mode d’exécution en fonction de la réponse et de la configuration sélectionnée, le premier mode d’exécution correspondant au mode nominal, au mode dégradé ou à un mode d’arrêt de chaque application en cours d’exécution ;
- détermination d’une durée nécessaire à la mise en œuvre de la configuration sélectionnée en fonction des premiers modes d’exécution déterminés pour l’ensemble d’applications en cours d’exécution et des deuxièmes informations reçues ;
- comparaison de la durée nécessaire à la mise en œuvre de la configuration sélectionnée au délai maximal,
la mise en œuvre de la configuration sélectionnée étant déterminée comme faisable lorsque la durée nécessaire à la mise en œuvre de la configuration sélectionnée est inférieure au délai maximal.

Selon une autre variante, lorsque la mise en œuvre de la configuration sélectionnée est faisable, le procédé comprend en outre les étapes suivantes :
- transmission, à destination de chaque application en cours d’exécution, d’une deuxième requête de reconfiguration selon le premier mode d’exécution déterminé ;
- contrôle de traitement d’un ensemble de paquets de données émis par au moins une partie de l’ensemble d’applications en cours d’exécution sur l’infrastructure réseau ;
- mise en œuvre de la configuration sélectionnée au niveau de l’infrastructure réseau suivant une fin de traitement de l’ensemble de paquets de données ;
- mise en œuvre d’un délai de stabilisation déterminé de l’infrastructure réseau suivant la mise en œuvre de la configuration sélectionnée ;
- contrôle d’exécution de chaque application de l’ensemble d’applications selon un deuxième mode d’exécution correspondant au mode nominal.

Selon une variante supplémentaire, le premier mode d’exécution est déterminé en fonction d’un niveau d’acceptation utilisateur associé à chaque mode d’exécution candidat d’un ensemble de modes d’exécution candidats associés à chaque application en cours d’exécution.

Selon une variante additionnelle, la deuxième requête est transmise à échéance d’un délai correspondant au délai minimal de plus grande valeur compris dans les première et deuxième réponses.

Selon encore une variante, un niveau de priorité est associé à au moins une partie de l’ensemble d’applications, la détermination du premier mode d’exécution étant en outre fonction du niveau de priorité.

Selon un deuxième aspect, la présente invention concerne un dispositif de contrôle de configuration d’une infrastructure réseau d’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 à 5 annexées, sur lesquelles :

illustre schématiquement un environnement de communication pour véhicule, selon un exemple de réalisation particulier et non limitatif de la présente invention

illustre schématiquement un 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 contrôle de configuration d’une infrastructure réseau 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 de configuration d’une infrastructure réseau du 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 de configuration d’une infrastructure réseau du 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 de configuration d’une infrastructure réseau d’un véhicule vont maintenant être décrits dans ce qui va suivre en référence conjointement aux figures 1 à 5. 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 la configuration d’un infrastructure réseau d’un véhicule, notamment d’applications mises en œuvre au niveau de l’infrastructure réseau et d’un ensemble de composants (mémoire, mémoire tampon (de l’anglais « buffer »), files d’attente, contrôleurs, etc.) associés à la mise en œuvre des applications, par exemple par un ou plusieurs calculateurs du système embarqué du véhicule, comprend la réception de données représentatives d’une configuration d’un ensemble d’applications embarquées dans le véhicule sélectionnée dans un ensemble de configurations disponibles dans une mémoire du véhicule. Cette sélection est déclenchée par une détection d’un changement de contexte au niveau de l’infrastructure réseau. Les données comprennent avantageusement des paramètres de configurations pour chaque application et une première information représentative d’un délai maximal pour la mise en œuvre de la configuration sélectionnée pour répondre aux besoins du changement de contexte. Un changement de contexte comprend par exemple la réception d’une requête d’exécution d’une nouvelle application, de mise en œuvre d’un nouveau service, d’un évènement réseau, etc. La configuration sélectionnée est adaptée et spécifique au nouveau contexte de l’infrastructure réseau du véhicule. La configuration sélectionnée comprend pour chaque application un ensemble de paramètres de configuration spécifiant par exemple les ressources allouées à cette application. Une première requête est transmise à destination de chaque application de l’ensemble en cours d’exécution au niveau de l’infrastructure réseau pour déterminer si cette application accepte ou refuse de mettre en œuvre la reconfiguration requise selon les paramètres de configuration qui la concernent. En retour, une réponse à la première requête est reçue, une telle réponse étant déterminée par chaque application en fonction d’un contexte courant d’exécution propre à chaque application. La réponse correspond par exemple à une acceptation de mise en œuvre de la reconfiguration dans un mode d’exécution nominal ou standard, une acceptation de mise en œuvre de la reconfiguration dans un mode dégradé par rapport au mode d’exécution nominal ou un refus de mise en œuvre de la reconfiguration. La réponse comprend en outre un délai minimal requis par chaque application pour mettre en œuvre la reconfiguration selon le mode d’exécution choisi. La faisabilité de la mise en œuvre de la configuration de l’ensemble d’application est alors déterminée en fonction des réponses reçues. La configuration est mise en œuvre ou déclinée selon la faisabilité déterminée.

Un tel procédé permet ainsi de prendre en compte les contextes d’exécution courant des applications en cours d’exécution impactées par la configuration requise par le changement de contexte. Cela permet d’offrir une méthodologie de reconfiguration de l’infrastructure réseau prenant en compte les contraintes des applications en cours d’exécution avant de lancer la reconfiguration de l’infrastructure réseau, en proposant par exemple une phase de configuration temporaire des applications en cours d’exécution.

Une telle méthodologie laisse par exemple l’opportunité aux applications en cours d’exécution de terminer des processus déjà lancés et qui ne peuvent pas être interrompus avant de lancer une nouvelle configuration. Une transition douce et graduelle entre une configuration courante et une nouvelle configuration est ainsi possible, améliorant la gestion ou la mise en œuvre de reconfiguration dynamique de l’infrastructure réseau.

La illustre schématiquement un environnement de communication pour un véhicule 10, selon un exemple de réalisation particulier et non limitatif de la présente invention.

La illustre un véhicule 10 dans un environnement de communication 1, le véhicule 10 étant par exemple dans un environnement routier ou sur une aire de stationnement ou parking, dans un garage, etc.

Le véhicule 10 correspond par exemple à un véhicule à moteur thermique, à moteur(s) électrique(s) ou encore un véhicule hybride avec un moteur thermique et un ou plusieurs moteurs électriques. Le véhicule 10 correspond ainsi par exemple à un véhicule terrestre, par exemple une automobile, un camion, un car, une moto.

Le véhicule 10 embarque avantageusement un système de communication configuré pour communiquer avec un ou plusieurs dispositifs distants 111. Un tel dispositif distant 111 est par exemple configuré pour communiquer avec le véhicule 10 selon une connexion de type OTA ou FOTA (de l’anglais « Firmware Over-The-Air » ou en français « firmware par liaison radio ») par l’intermédiaire d’une infrastructure d’un réseau de communication sans fil de type réseau cellulaire terrestre en utilisant par exemple un mode de communication sans fil de type LTE (de l’anglais « Long Term Evolution » ou en français « Evolution à long terme ») 4G ou 5G.

Selon une variante de réalisation, le véhicule 10 communique avec le dispositif distant en mode OTA ou FOTA par l’intermédiaire d’un réseau local sans fil, dit WLAN (de l’anglais « Wireless Local Area Network »), par exemple de type Wifi®. Le WLAN est par exemple relié au « cloud » via une infrastructure d’un réseau filaire et/ou via l’infrastructure de réseau de communication sans fil.

Chaque dispositif distant 111 est par exemple configuré pour gérer les logiciels (de l’anglais « software », correspondant par exemple à un firmware ou à tout logiciel nécessaire au bon fonctionnement du véhicule 10) embarqués dans le véhicule 10, notamment les logiciels de type application interactive. Le dispositif distant 111 est par exemple prévu pour fournir un ensemble de configurations de l’infrastructure réseau du véhicule 10, chaque configuration étant spécifique à un contexte particulier (par exemple pour la mise en œuvre d’un ensemble d’applications ou services en parallèle avec le partage des ressources disponibles). Un tel dispositif distant 111 est par exemple contrôlé par le constructeur du véhicule 10 et/ou par un fournisseur de composants logiciels ou matériels du véhicule 10, notamment de l’infrastructure réseau du véhicule 10.

Le dispositif distant 111 correspond par exemple à un serveur du « cloud » 100 (ou « nuage » en français). L’infrastructure de communication sans fil comprend par exemple un ensemble de dispositifs de communication de type antenne de réseau cellulaire 110.

Le véhicule 10 embarque avantageusement un système de communication configuré pour communiquer avec le dispositif distant 111 via l’infrastructure de communication sans fil. Le système de communication comprend par exemple une ou plusieurs antennes de communication reliées à une unité de contrôle télématique, dite TCU (de l’anglais « Telematic Control Unit »), elle-même reliée à un ou plusieurs calculateurs du système embarqué du véhicule 10. La ou les antennes, l’unité TCU et le ou les calculateurs forment par exemple une architecture multiplexée pour la réalisation de différents services utiles pour le bon fonctionnement du véhicule et pour assister le conducteur et/ou les passagers du véhicule dans le contrôle du véhicule 10. Le ou les calculateurs et l’unité TCU communiquent et échangent des données entre eux par l’intermédiaire d’un ou plusieurs bus informatiques, par exemple un bus de communication de type bus de données 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 (selon la norme ISO 17458) ou Ethernet (selon la norme ISO/IEC 802-3).

La illustre schématiquement une infrastructure réseau du véhicule correspondant à l’architecture électronique et électrique, dite architecture E/E, du 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 ».

La illustre un processus de contrôle de la configuration de l’infrastructure réseau ou architecture E/E du véhicule 10, selon un exemple de réalisation particulier et non limitatif de la présente invention.

Un tel processus 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 31 par exemple.

La configuration ou la reconfiguration de l’infrastructure réseau ou architecture E/E comprend la configuration d’un ensemble d’applications et de l’ensemble de composants de l’infrastructure réseau (par exemple les mémoires associées aux calculateurs) suivant une détection ou une prévision de changement de contexte au niveau de l’infrastructure réseau.

Dans une opération préalable non illustrée sur la , le véhicule 10 télécharge un ensemble de configurations dynamiques déterminées au préalable pour un ensemble de contextes d’application ou d’exécution déterminés. Cet ensemble de configurations dynamiques est par exemple calculées par un ou plusieurs dispositifs de calcul ou de traitement de données tel que le dispositif distant 111 et est mis à disposition des véhicules pour téléchargement via l’infrastructure de communication sans fil par exemple. Cela permet par exemple de faire évoluer l’ensemble de configurations disponibles en augmentant au fur et à mesures les configurations particulières, par exemple lorsque le nombre d’applications disponibles en téléchargement pour le véhicule 10 augmente. Le nombre d’applications augmentant, le nombre de contextes d’exécution de ces applications (c’est-à-dire l’ensemble des combinaisons possibles d’applications exécutées en parallèle) augmente également. Une configuration associée à un contexte particulier est configurée pour répartir ou distribuer les ressources (réseau et de calcul) disponibles au niveau de l’architecture E/E entre les applications à exécutées de manière concomitante, par exemple en fonction de niveaux de priorité associés à chaque application.

Une configuration comprend par exemple en outre des contraintes particulières selon les applications, tels que des délais maximums de mise en œuvre, un ordre d’exécution des applications, etc.

Les différentes configurations précalculées sont avantageusement stockées dans une ou plusieurs mémoires du véhicule 10. Un ensemble de configurations est par exemple disponible en sortie d’usine, cet ensemble évoluant dans le temps avec le téléchargement par le véhicule 10 des nouvelles configurations disponibles sur le dispositif distant 111 via une liaison OTA.

Dans une première opération 301, des données représentatives d’une configuration d’un ensemble d’applications embarquées dans le véhicule 10 sont obtenues, par exemple reçues ou générées.

Cette configuration particulière est sélectionnée dans l’ensemble de configurations enregistrées dans une mémoire du véhicule 10, c’est-à-dire parmi l’ensemble de configurations disponibles dans le véhicule au moment et en fonction d’une détection d’un changement de contexte d’exécution de cet ensemble d’applications embarquées.

Ces données sont obtenues suite à et en fonction d’une détection d’un changement de contexte d’exécution d’un ensemble d’applications embarquées dans le véhicule 10 au niveau de l’infrastructure réseau sont reçues par le contrôleur 31.

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.

Les données comprennent ainsi par exemple :
- une liste d’applications en cours d’exécution lors du changement de contexte à stopper ou arrêter ; et/ou
- une liste d’applications en cours d’exécution à conserver en fonctionnement ; et/ou
- une liste de nouvelles applications à lancer, c’est-à-dire une ou plusieurs applications qui n’étaient pas en fonctionnement lors de la détection du changement de contexte ; et/ou
- une première information représentative d’un délai maximal, noté ‘T’, pour la mise en œuvre de la configuration sélectionnée, ce délai T étant par exemple déterminé par un composant ayant détecté le changement de contexte, par le calculateur ayant sélectionné la configuration ou bien ce délai étant compris comme métadonnée dans les données ; et/ou
- un niveau de priorité pour l’exécution de chaque application (par exemple l’exécution d’une application ou d’un service coopératif (de type V2X par exemple) dans une situation de sécurité critique pour le véhicule possède un niveau de priorité plus important que l’exécution d’une application de divertissement) ; et/ou
- les ressources allouées à chaque application.

La sélection de la configuration marque par exemple le début d’une phase dite de négociation de durée δ1 avec les applications en cours d’exécution.

Dans une deuxième opération 302, une première requête de reconfiguration de chaque application en cours d’exécution en fonction de l’ensemble de paramètres associé à chaque application en cours d’exécution est transmise à destination de de chaque application de l’ensemble d’application en cours d’exécution au niveau de l’infrastructure réseau. Cette première requête est par exemple transmise à un module ou composant 32 contrôlant les applications ou à chaque calculateur 32 contrôlant une application de l’ensemble d’applications en cours d’exécution. La première requête comprend les paramètres de configuration.

Dans une troisième opération 303, chaque module ou composant 32 détermine une réponse à la première requête en fonction des paramètres de configuration associées à chaque application, de tels paramètres comprenant par exemple les ressources (calcul, mémoire, bande passante, etc.) allouées à chaque application.

La réponse appartient à un ensemble de réponses comprenant :
- une première réponse représentative d’une acceptation de mise en œuvre de la reconfiguration selon un mode d’exécution nominal,
- une deuxième réponse représentative d’une acceptation de mise en œuvre de la reconfiguration dans un mode d’exécution dégradé par rapport au mode d’exécution nominal, et
- une troisième réponse représentative d’un refus de mise en œuvre de la reconfiguration

La première requête comprend par exemple le mode d’exécution selon lequel chaque application en cours d’exécution doit être reconfigurée (mode d’exécution nominal, mode d’exécution dégradé ou mode d’arrêt d’exécution).

Selon une variante de réalisation, une application en cours d’exécution sélectionne un ou plusieurs modes d’exécution parmi un ensemble de modes d’exécution disponibles associés à l’application, en fonction des données reçues dans la première requête.

Le mode d’exécution est ainsi sélectionné parmi les modes suivants :
- un mode d’exécution dite nominale ou standard, c’est-à-dire 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) ;
- 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
- un mode d’arrêt d’exécution ou mode désactivé 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.

Dans une quatrième opération 304, le contrôleur 31 reçoit de chaque module 32 la réponse à la première requête, chaque application retournant des données représentatives de :
- une première réponse représentative d’une acceptation de mise en œuvre de la reconfiguration selon un mode d’exécution nominal,
- une deuxième réponse représentative d’une acceptation de mise en œuvre de la reconfiguration dans un mode d’exécution dégradé par rapport au mode d’exécution nominal, le mode dégradé étant requis dans la première requête ou sélectionné par l’application concernée en fonction des ressources qui lui sont allouées dans la première requête, et
- une troisième réponse représentative d’un refus de mise en œuvre de la reconfiguration (par exemple refus de passer en mode d’arrêt d’exécution ou refus de passer dans un mode d’exécution dégradé).

Chaque réponse, ou pour le moins les réponses relatives à une acceptation de fonctionner en mode nominal ou dégradé, comprend en outre une deuxième information relative au délai minimal nécessaire à la mise en œuvre de la reconfiguration dans le mode d’exécution requis ou sélectionné. Ce délai minimal correspond par exemple à une durée nécessaire à chaque application pour terminer les tâches en cours (téléchargement de données, traitement de données, etc.) avant de pouvoir initier une reconfiguration.

La réception de l’ensemble des réponses marque la fin de la phase dite de négociation avec les applications en cours d’exécution.

Dans une cinquième opération 305, le contrôleur 31 détermine quelle combinaison des modes d’exécution possibles minimise le coût de reconfiguration totale et les perturbations réseau, un premier mode d’exécution étant déterminé pour chaque application (mode nominal, mode dégradé ou mode d’arrêt).

Selon une variante, la détermination de la combinaison prend en outre en considération un critère d’acceptation utilisateur des modes d’exécution, chaque mode d’exécution associé à une application étant par exemple associé à un tel critère (déterminé par le concepteur de l’application ou en fonction de règles de calcul déterminées). Un tel critère est par exemple appelé niveau AXIL (de l’anglais « Automotive eXperience Integrity Level » ou en français « niveau d’intégrité d’expérience automobile »).

Le niveau 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).

Lorsqu’une application refuse de mettre en œuvre la reconfiguration requise (par exemple une application refuse de stopper), le contrôleur 31 peut décider de forcer l’arrêt de l’application lorsqu’un niveau de priorité élevé est associée à la configuration sélectionnée (par exemple lorsque la configuration sélectionnée comprend l’exécution d’une ou plusieurs nouvelles applications fournissant des services critiques en termes de sécurité) et que l’arrêt de la ou les applications en cours d’exécution concernées n’a pas d’impact sur la sécurité ou le fonctionnement du véhicule, autre qu’un agrément d’un ou plusieurs utilisateurs.

Cette opération 305 correspond à une phase dite de sélection de modes d’exécution de durée δ2.

Dans une sixième opération 306, le contrôleur détermine la durée nécessaire à la mise en œuvre de la configuration sélectionnée, notée Δ, par exemple en fonction des deuxièmes informations reçues.

Dans une septième opération 307, la durée Δ nécessaire à la mise en œuvre de la configuration sélectionnée est comparée au délai maximum T.

Si Δ est inférieure à T, alors la mise en œuvre de la configuration sélectionnée est jugée faisable et le processus de configuration se poursuit avec les opérations 308 à 320.

Sinon, Si Δ est supérieure à T, alors la mise en œuvre de la configuration sélectionnée est jugée infaisable et le processus de configuration s’interrompt ou est annulé, une information d’annulation étant transmise dans une opération 307 à l’instance ayant détecté ou requis le changement de contexte.

Les opérations 306 et 307, le cas échéant, forment une phase dite de confirmation de durée δ3.

Dans une huitième opération 308 formant une phase dite d’attente avant lancement de la configuration sélectionnée et de durée δ4, le contrôleur attend pendant une durée déterminée correspondant à la durée minimale requise par les applications dont la valeur est la plus élevée. Le contrôleur 31 laisse ainsi le temps aux applications en cours d’exécution concernées par la reconfiguration de terminer les tâches en cours avant d’initier la reconfiguration.

Dans une neuvième opération 309, le contrôleur 31 transmet à chaque application en cours d’exécution 32 concernée par la reconfiguration une deuxième requête de reconfiguration selon le premier mode d’exécution déterminé (mode dégradé ou mode d’arrêt).

La deuxième requête comprend par exemple en outre une troisième information représentative de la durée pendant laquelle chaque application doit rester en mode dégradé, voire en mode d’arrêt.

Dans une dixième opération 310, chaque application 32 ayant reçu une deuxième requête met en œuvre la reconfiguration selon le premier mode d’exécution requis (mode dégradé ou mode d’arrêt ou stop).

Dans une onzième opération 311 optionnelle, chaque application transmet un acquittement au contrôleur 31 pour confirmer la bonne mise en œuvre de la reconfiguration en mode dégradé ou la fin d’exécution de l’application.

Les opérations 309 à 311 forment une phase dite de désengagement de durée δ5.

Dans une douzième opération 312, le contrôleur 31 met en œuvre une phase dite de stabilisation du réseau de durée δ6 correspondant à une phase d’attente permettant une convergence réseau. Une telle phase est prévue pour permettre le transit des paquets de données émis par les anciennes applications (applications stoppées lors de la reconfiguration et/ou paquets de données relatifs à des services stoppés lorsqu’une application passe en mode dégradé).

Selon une variante, un ou plusieurs traitements des données émises par ces applications sont mis en œuvre pendant cette phase de stabilisation du réseau, tels qu’un filtrage des données pour supprimer les données émises, ce qui permet d’améliorer la durée de convergence du réseau.

Dans une treizième opération 313, une requête de reconfiguration est transmise à chaque composante 33 de l’infrastructure réseau. Cette reconfiguration est par exemple déclenchée à un instant déterminé commun à toutes les composantes réseau pour synchroniser la reconfiguration de manière à ce que toutes les transactions informatiques soient mises en œuvre à un même instant déterminé.

Dans une quatorzième opération 314, la reconfiguration est mise en œuvre au niveau de l’ensemble des composantes réseau. Certaines applications stoppées ou exécutées en mode dégradé repassent par exemple en mode d’exécution nominal.

Dans une quinzième opération 315 optionnelle, chaque composante réseau transmet un acquittement au contrôleur 31 pour confirmer la bonne mise en œuvre de la reconfiguration.

Les opérations 313 à 315 forment une phase dite de reconfiguration de durée δ7.

Dans une seizième opération 316, le contrôleur 31 met en œuvre une phase dite de convergence du réseau de durée δ8 correspondant à une phase d’attente permettant une convergence réseau (traitement des paquets de données en transit, stabilisation des mémoires tampons).

Dans une dix-septième opération 317, le contrôleur 31 transmet une requête à destination de chaque nouvelle application (c’est-à-dire chaque application qui n’était pas en cours d’exécution au moment du changement de contexte et concernée par la configuration sélectionnée) à exécuter pour déclencher l’exécution de chaque nouvelle application dans un mode d’exécution déterminé conforme à la configuration sélectionnée.

Dans une dix-huitième opération 318, l’exécution de chaque nouvelle application est mise en œuvre selon la requête transmise par le contrôleur 31.

Dans une dix-neuvième opération 319 optionnelle, chaque nouvelle application exécutée transmet un acquittement au contrôleur 31 pour confirmer la bonne mise en œuvre de la configuration sélectionnée.

Dans une vingtième opération 320, le contrôleur 320 transmet un acquittement ou une confirmation de changement de contexte à l’instance ayant détecté ou requis ce changement de contexte.

La illustre schématiquement un dispositif 4 configuré pour contrôler la configuration d’une infrastructure réseau d’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 4 correspond par exemple à un dispositif embarqué dans le véhicule 10, par exemple un calculateur.

Le dispositif 4 est par exemple configuré pour la mise en œuvre des opérations décrites en regard des figures 1 à 3 et/ou des étapes du procédé décrit en regard de la . Des exemples d’un tel dispositif 4 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 4, 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 4 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 4 comprend un (ou plusieurs) processeur(s) 40 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 4. 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 4 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 est par exemple stocké sur la mémoire 41.

Selon différents exemples de réalisation particuliers et non limitatifs, le dispositif 4 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 4 comprend un bloc 42 d’éléments d’interface pour communiquer avec des dispositifs externes. Les éléments d’interface du bloc 42 comprennent une ou plusieurs des interfaces suivantes :
- interface radiofréquence RF, par exemple de type Wi-Fi® (selon IEEE 802.11), par exemple dans les bandes de fréquence à 2,4 ou 5 GHz, ou de type Bluetooth® (selon IEEE 802.15.1), dans la bande de fréquence à 2,4 GHz, ou de type Sigfox utilisant une technologie radio UBN (de l’anglais Ultra Narrow Band, en français bande ultra étroite), ou LoRa dans la bande de fréquence 868 MHz, LTE (de l’anglais « Long-Term Evolution » ou en français « Evolution à long terme »), LTE-Advanced (ou en français LTE-avancé) ;
- interface USB (de l’anglais « Universal Serial Bus » ou « Bus Universel en Série » en français) ;
- interface HDMI (de l’anglais « High Definition Multimedia Interface », ou « Interface Multimedia Haute Definition » en français) ;
- 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 4 comprend une interface de communication 43 qui permet d’établir une communication avec d’autres dispositifs (tels que d’autres calculateurs du système embarqué) via un canal de communication 430. 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 430. 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) ou Ethernet (standardisé par la norme ISO/IEC 802-3).

Selon un exemple de réalisation particulier et non limitatif, le dispositif 4 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 de configuration d’une infrastructure réseau d’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 4 de la .

Dans une première étape 51, des données représentatives d’une configuration d’un ensemble d’applications embarquées sélectionnée parmi une pluralité de configurations enregistrées dans une mémoire du véhicule sont obtenues suivant un changement de contexte d’exécution détecté au niveau de l’infrastructure réseau, un ensemble de paramètres représentatifs de la configuration sélectionnée étant associé à chaque application de l’ensemble d’applications, une première information représentative d’un délai maximal de mise en œuvre de la configuration sélectionnée étant comprise dans les données.

Dans une deuxième étape 52, une première requête de reconfiguration de chaque application en cours d’exécution en fonction de l’ensemble de paramètres associé à chaque application en cours d’exécution est transmise à destination de chaque application de l’ensemble d’application en cours d’exécution au niveau de l’infrastructure réseau.

Dans une troisième étape 53, une réponse à la première requête est reçue depuis chaque application en cours d’exécution, la réponse étant déterminée par chaque application en cours d’exécution à partir d’un contexte courant d’exécution de chaque application en cours d’exécution et de l’ensemble de paramètres, la réponse appartenant à un ensemble de réponses comprenant :
● une première réponse représentative d’une acceptation de mise en œuvre de la reconfiguration selon un mode d’exécution nominal,
● une deuxième réponse représentative d’une acceptation de mise en œuvre de la reconfiguration dans un mode d’exécution dégradé par rapport au mode d’exécution nominal,
les première et deuxième réponses comprenant chacune une deuxième information de délai minimal de mise en œuvre de la reconfiguration, et
● une troisième réponse représentative d’un refus de mise en œuvre de la reconfiguration.

Dans une quatrième étape 54, une faisabilité de la mise en œuvre de la configuration sélectionnée est déterminée en fonction des réponses reçues des applications en cours d’exécution.

Dans une cinquième étape 55, la mise en œuvre de la configuration sélectionnée est contrôlée en fonction de la faisabilité.

Selon une variante, les variantes et exemples des opérations décrits en relation avec les figures 1 à 3 s’appliquent aux étapes du procédé de la .

Bien entendu, la présente invention ne se limite pas aux exemples de réalisation décrits ci-avant mais s’étend à un procédé de reconfiguration d’un ensemble d’applications embarquées 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 4 de la .

Claims (10)

1. Procédé de contrôle de configuration d’une infrastructure réseau d’un véhicule (10), ledit procédé comprenant les étapes suivantes :
   - obtention (51) de données représentatives d’une configuration d’un ensemble d’applications (32) embarquées sélectionnée parmi une pluralité de configurations enregistrées dans une mémoire dudit véhicule (10) suivant un changement de contexte d’exécution détecté au niveau de ladite infrastructure réseau, un ensemble de paramètres représentatifs de la configuration sélectionnée étant associé à chaque application dudit ensemble d’applications, une première information représentative d’un délai maximal (T) de mise en œuvre de ladite configuration sélectionnée étant comprise dans lesdites données ;
   - transmission (52), à destination de chaque application (32) dudit ensemble d’application en cours d’exécution au niveau de ladite infrastructure réseau, d’une première requête de reconfiguration de ladite chaque application en cours d’exécution en fonction de l’ensemble de paramètres associé à ladite chaque application en cours d’exécution ;
   - réception (53), depuis ladite chaque application en cours d’exécution, d’une réponse à ladite première requête, ladite réponse étant déterminée par ladite chaque application en cours d’exécution à partir d’un contexte courant d’exécution de ladite chaque application en cours d’exécution et dudit ensemble de paramètres, ladite réponse appartenant à un ensemble de réponses comprenant :
   ● une première réponse représentative d’une acceptation de mise en œuvre de ladite reconfiguration selon un mode d’exécution nominal,
   ● une deuxième réponse représentative d’une acceptation de mise en œuvre de ladite reconfiguration dans un mode d’exécution dégradé par rapport audit mode d’exécution nominal,
   lesdites première et deuxième réponses comprenant chacune une deuxième information de délai minimal de mise en œuvre de ladite reconfiguration, et
   ● une troisième réponse représentative d’un refus de mise en œuvre de ladite reconfiguration ;
   - détermination (54) d’une faisabilité de la mise en œuvre de la configuration sélectionnée en fonction des réponses reçues des applications en cours d’exécution ;
   - contrôle (55) de mise en œuvre de ladite configuration sélectionnée en fonction de ladite faisabilité.
2. Procédé selon la revendication 1, pour lequel la détermination de ladite faisabilité comprend les étapes suivantes :
   - détermination, pour ladite chaque application en cours d’exécution, d’un premier mode d’exécution en fonction de ladite réponse et de ladite configuration sélectionnée, ledit premier mode d’exécution correspondant au mode nominal, au mode dégradé ou à un mode d’arrêt de ladite chaque application en cours d’exécution ;
   - détermination d’une durée nécessaire (Δ) à la mise en œuvre de la configuration sélectionnée en fonction des premiers modes d’exécution déterminés pour l’ensemble d’applications en cours d’exécution et desdites deuxièmes informations reçues ;
   - comparaison de ladite durée nécessaire (Δ) à la mise en œuvre de ladite configuration sélectionnée audit délai maximal (T),
   la mise en œuvre de ladite configuration étant déterminée comme faisable lorsque ladite durée nécessaire à la mise en œuvre de la configuration sélectionnée est inférieure audit délai maximal.
3. Procédé selon la revendication 2, pour lequel, lorsque la mise en œuvre de la configuration sélectionnée est faisable, ledit procédé comprend en outre les étapes suivantes :
   - transmission, à destination de ladite chaque application en cours d’exécution, d’une deuxième requête de reconfiguration selon ledit premier mode d’exécution déterminé ;
   - contrôle de traitement d’un ensemble de paquets de données émis par au moins une partie dudit ensemble d’applications en cours d’exécution sur ladite infrastructure réseau ;
   - mise en œuvre de ladite configuration sélectionnée au niveau de ladite infrastructure réseau suivant une fin de traitement dudit ensemble de paquets de données ;
   - mise en œuvre d’un délai de stabilisation déterminé de ladite infrastructure réseau suivant la mise en œuvre de ladite configuration sélectionnée ;
   - contrôle d’exécution de chaque application dudit ensemble d’applications selon un deuxième mode d’exécution correspondant au mode nominal.
4. Procédé selon la revendication 2 ou 3, pour lequel ledit premier mode d’exécution est déterminé en fonction d’un niveau d’acceptation utilisateur associé à chaque mode d’exécution candidat d’un ensemble de modes d’exécution candidats associés à ladite chaque application en cours d’exécution.
5. Procédé selon la revendication 3, pour lequel ladite deuxième requête est transmise à échéance d’un délai correspondant au délai minimal de plus grande valeur compris dans lesdites première et deuxième réponses.
6. Procédé selon l’une des revendications 2 à 5, pour lequel un niveau de priorité est associé à au moins une partie dudit ensemble d’applications, la détermination dudit premier mode d’exécution étant en outre fonction dudit niveau de priorité.
7. 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.
8. 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.
9. Dispositif (4) de contrôle de configuration d’une infrastructure réseau d’un véhicule, ledit dispositif (4) 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 à 6.
10. Véhicule (10) comprenant le dispositif (4) selon la revendication 9.