FR 3157954 A1 20250704 FR 2315471 A 20231229 Procédé de gestion d’affichage dans un véhicule, et procédé et système d’assistance à la conduite pour véhicule l’utilisant L’invention concerne un procédé de gestion d’affichage dans un véhicule automobile (EGO) comportant, d’une part, un système d’assistance à la conduite comprenant un composant logiciel (PP) planificateur de trajectoires et des applications (APP 1, APP 2, APP N) et, d’autre part, une pluralité d’interfaces homme-machine (IHM) pour l’affichage ou la signalisation d’informations et un composant logiciel (GIHM) gestionnaire desdites interfaces homme-machine (IHM), l’utilisation d’au moins une interface (IHM) pouvant être sollicitée simultanément par au moins deux applications (APP 1, APP 2, APP N) différentes. Procédé caractérisé en ce qu’il consiste, pour chaque application (APP 1, APP 2, APP N) pour laquelle une contrainte/requête a été soumise au composant logiciel planificateur (PP) et arbitrée par ce dernier, à adresser une demande d’affichage au composant logiciel gestionnaire (GIHM), et à décider au niveau dudit composant logiciel gestionnaire (GIHM) de la suite positive ou négative à donner à cette demande, et commander ladite au moins une interface (IHM) concernée en accord avec des modalités d’affichage ou de signalisation prédéterminées. Figure à publier avec l’abrégé : Fig. 1 Procédé de gestion d’affichage dans un véhicule, et procédé et système d’assistance à la conduite pour véhicule l’utilisant La présente invention concerne le domaine de la signalisation et de la communication automatiques et sélectives d’informations au conducteur et/ou aux passagers d’un véhicule par le biais d’interfaces homme-machine (IHM) équipant celui-ci, notamment à la suite d’actions affectant le véhicule et déclenchées par différentes applications logicielles de sécurité ou de confort. Dans ce contexte, l’invention a pour objet un procédé de gestion d’affichage dans un véhicule, ainsi qu’un procédé et un système d’assistance à la conduite pour véhicule utilisant ledit procédé de gestion d’affichage. Dans un véhicule automobile, les d’interfaces homme-machine (IHM) sont de nature règlementaire et/ou informative. Leur nombre est forcément limité et il est important de ne pas trop surcharger les affichages pour avoir une information à la fois succincte, facilement assimilable et complète pour les utilisateurs. Par ailleurs, les véhicules sont de plus en plus équipés d’applications logicielles de sécurité ou de confort développées par des entités différentes, généralement sans contraintes en termes d’interopérabilité ou de compatibilité, sauf à pouvoir être mise en œuvre et remplir leurs fonctions dans le véhicule concerné. Dans ces conditions, il existe par conséquent une nécessité pour les différentes applications présentes à pouvoir partager et utiliser (le cas échéant solliciter simultanément) les mêmes IHM, au moins une ou plusieurs d’entre elles. Par exemple, deux applications peuvent allumer un même pictogramme, ou un même emplacement d’un écran peut afficher deux informations différentes en relations avec deux applications différentes. Le problème principal posé à la présente invention consiste à pouvoir proposer une solution permettant à différentes applications implémentées simultanément, et donc fonctionnant ensemble, dans un même véhicule d’utiliser, au moins à deux, la même IHM, ce sans connaitre la nature, la constitution ou le mode de fonctionnement de cette IHM (LED, écran TFT, pictogramme à rétroéclairage caché dans une pièce de garniture, …) et en s’affranchissant de toute communication entre applications, au moins de toute communication directe entre elles. De plus, la solution proposée devrait permettre de fournir un affichage qui demeure cohérent indépendamment du nombre et de la nature des applications mises en œuvre. Ce problème est résolu, selon un premier aspect de l’invention, par un procédé de gestion d’affichage dans un véhicule automobile comportant, d’une part, un système d’assistance à la conduite comprenant un composant logiciel planificateur de trajectoires et des applications de confort ou de sécurité transmettant séparément des requêtes ou contraintes audit composant logiciel planificateur pour exécution par le véhicule et, d’autre part, une pluralité d’interfaces homme-machine pour l’affichage ou la signalisation d’informations, dont certaines au moins provenant des applications précitées, et un composant logiciel gestionnaire desdites interfaces homme-machine, l’utilisation d’au moins une interface pouvant être sollicitée simultanément par au moins deux applications différentes, ne communiquant pas entre elles, procédé caractérisé en ce qu’il consiste, pour chaque application pour laquelle une contrainte/requête a été soumise au composant logiciel planificateur et arbitrée par ce dernier selon des règles de priorisation prédéfinies, à adresser une demande d’affichage au composant logiciel gestionnaire en accord avec le résultat de l’arbitrage et selon un protocole prédéfini commun aux différentes applications, et à décider au niveau dudit composant logiciel gestionnaire de la suite positive ou négative à donner à cette demande, et le cas échéant commander ladite au moins une interface concernée en accord avec des modalités d’affichage ou de signalisation prédéterminées. L'invention sera mieux comprise, grâce à la description ci-après, qui se rapporte à un mode de réalisation préféré, donné à titre d'exemple non limitatif, et expliqué avec référence aux dessins schématiques annexés, dans lesquels : FIG. 1 représente de manière schématique et simplifiée une architecture de système d’aide à la conduite pour véhicule automobile, et, FIG. 2 est une représentation partielle de l’architecture de la FIG. 1 illustrant un exemple de processus décisionnel pouvant être suivi par le procédé d’assistance à la conduite selon l’invention. L’invention concerne, selon un premier aspect, un procédé de gestion d’affichage dans un véhicule automobile (EGO) comportant, d’une part, un système d’assistance à la conduite comprenant un composant logiciel (PP) planificateur de trajectoires et des applications (APP 1, APP 2, APP N) de confort ou de sécurité transmettant séparément des requêtes ou contraintes audit composant logiciel planificateur (PP) pour exécution par le véhicule (EGO) et, d’autre part, une pluralité d’interfaces homme-machine (IHM) pour l’affichage ou la signalisation d’informations, dont certaines au moins provenant des applications précitées, et un composant logiciel (GIHM) gestionnaire desdites interfaces homme-machine (IHM), l’utilisation d’au moins une interface (IHM) pouvant être sollicitée simultanément par au moins deux applications (APP 1, APP 2, APP N) différentes, ne communiquant pas entre elles. Conformément à l’invention, ce procédé consiste, pour chaque application (APP 1, APP 2, APP N) pour laquelle une contrainte/requête a été soumise au composant logiciel planificateur (PP) et arbitrée par ce dernier selon des règles de priorisation prédéfinies, à adresser une demande d’affichage au composant logiciel gestionnaire (GIHM) en accord avec le résultat de l’arbitrage et selon un protocole prédéfini commun aux différentes applications, et à décider au niveau dudit composant logiciel gestionnaire (GIHM) de la suite positive ou négative à donner à cette demande, et le cas échéant commander ladite au moins une interface (IHM) concernée en accord avec des modalités d’affichage ou de signalisation prédéterminées. Grâce aux dispositions précitées, et notamment à la mise en œuvre d’un composant logiciel (GIHM) gestionnaire des interfaces homme-machine (IHM), l’invention permet à des applications différentes (APP1, APP2, …, APPi, …, APPN), le cas échéant développées indépendamment par des entités différentes, de « cohabiter » entre elles en utilisant la ou les même(s) interface(s) homme-machine (IHM), sans avoir connaissance de l’IHM utilisée, sans avoir à communiquer avec une quelconque autre application et en proposant une affichage d’ensemble cohérent. En confiant la gestion de l’affichage pour toutes les applications à un unique composant logiciel (GIHM), ces dernières se limitent à l’envoi de demandes et ne sont impliquées ni dans le traitement, ni dans l’implémentation visuelle et/ou sonore, de ces dernières. La solution proposée par l’invention est donc à la fois générique, extensible et évolutive : pour une même demande d’affichage un véhicule d’entrée de gamme peut allumer une diode, alors qu’un véhicule plus haut de gamme peut afficher un pictogramme sur un écran TFT. En accord avec un mode de réalisation simple et efficient du procédé, limitant les contraintes au niveau des applications tout en permettant l’acceptation d’applications diverses, ledit procédé de gestion d’affichage peut consister à mettre en œuvre un protocole de communication défini par le composant logiciel gestionnaire (GIHM) et dans lequel chaque message de demande envoyé par une application (APP 1, APP 2, APP N) au composant logiciel gestionnaire (GIHM) comprend les champs suivants : le type de caractéristique liée au véhicule (EGO) et/ou à l’environnement concernée par la requête/contrainte, le degré d’urgence de cette caractéristique, l’état de cette caractéristique, la raison du changement d’état de la caractéristique et éventuellement un champ informatif spécifique à l’application concernée. A titre d’exemples pratiques possibles, les messages de demandes peuvent comprendre les champs suivants A) à D) : A) Type de caractéristique, comme par exemples : Longitudinal « non urgent » : par exemple système adaptatif de régulation de vitesse (Adaptative Cruise Control - ACC), Auto-régénérateur contextuel (Contextual Auto Regenerator - CARB), etc. Longitudinal « urgent » : par exemple Système de freinage d’urgence autonome (Autonomous Emergency Braking - AEB), Usagers de la route vulnérables (VRU – Vulnerable Road User), Système de freinage d’urgence autonome de voiture à voiture (Autonomous Emergency Braking Car to Car), etc. Lateral « non urgent » : par exemple Assistance au centrage de voie (Lane Centering Assist - LCA), Changement de voie semi-automatique (Semi Automatic Lane Change - SALC), … Latéral « urgent » : par exemple Aide au suivi de voie (Lane Keep Assist - LKA), LKA d’urgence (e-LKA), … Informatif : des caractéristiques qui n’ont pas d’action sur les actionneurs du véhicule, telles que IHM réaliste (R-HMI), Adaptation intelligente de la vitesse (Intelligent Speed Assist ou ISA), Alerte de franchissement involontaire de ligne (Lane Departure Warning - LDW), etc. B) Etat de la caractéristique (par exemple) : Activée. Désactivée. Stand-by. Annulée. C) Raison d’annulation (source de l’annulation) : Désactivation conducteur. Caméra bloquée temporaire. Caméra bloquée permanente. ODD non respecté. D) Champs spécifiques optionnels (qui ne sont pas utilisés par toutes les applications) : Vitesse de consigne : utilisé par exemple par l’ACC. Dépassement de ligne latérale : utilisé par exemple par le LKA. Ce protocole défini par le composant logiciel gestionnaire (GIHM) et qui doit être utilisé par toutes les applications sollicitant un affichage peut bien entendu évoluer pour s’adapter à des offres d’IHM variées et à de possibles évolutions des IHM disponibles. De manière avantageuse, le procédé de gestion d’affichage peut consister à hiérarchiser, au niveau du composant logiciel gestionnaire (GIHM), les demandes d’affichage reçues des applications (APP 1, APP 2, APP N) en appliquant des règles et/ou des critères prédéfinis, prenant par exemple en compte le type de caractéristique liée au véhicule (EGO) et/ou à l’environnement concernée par la requête/contrainte liée à une demande, le degré d’urgence ou d’importance de la caractéristique concernée par cette demande et/ou l’éventuelle interdépendance de la caractéristique concernée par cette demande avec une autre caractéristique concernée par une autre demande. A titre d’exemple de règles de hiérarchisation et d’arbitrage mises en œuvre par le composant logiciel gestionnaire (GIHM), le procédé peut par exemple prévoir : Un premier niveau d’arbitrage par type de caractéristique : Si le composant logiciel gestionnaire (GIHM) ne reçoit qu’une seule demande par type de caractéristique alors l’arbitrage est simple (chaque caractéristique a sa demande acceptée à ce premier niveau d’arbitrage). Si le composant logiciel gestionnaire (GIHM) reçoit plus d’une demande sur un même type de caractéristique (par exemple une demande ACC/ISA sur le longitudinal « non-urgent ») alors ledit gestionnaire (GIHM) priorise chaque champ en fonction de sa valeur. Par exemple : un ISA activé est prioritaire par rapport à un ACC désactivé. La demande globale reste « longitudinal non-urgent activé ». A la fin de cette étape il ne reste qu’une demande unique par type de caractéristique (concernant la modularité, si on rajoute une application qui émet sur un type de caractéristique, l’arbitrage reste inchangé). Un deuxième niveau d’arbitrage est relatif à l’interdépendance des types de caractéristiques : Par exemple, si une demande « longitudinal urgent » est présente, on fait le choix de ne pas afficher de demande (quelle qu’elle soit) provenant d’un « longitudinal non urgent ». L’ensemble des statuts résultant des arbitrages produit un affichage sur l’IHM en question : écran de tableau de bord / LED / IVI (Infodivertissement) / compteur/ ou analogue. De cette façon l'affichage est cohérent, chaque application est indépendante des autres et l’arbitre (PP) et le gestionnaire (GIHM) peuvent gérer autant d'applications que nécessaire (pas de limite pour la quantité d'applications). Bien entendu, le composant logiciel gestionnaire (GIHM) peut solliciter ou commander au moins deux interfaces (IHM) différentes pour une même demande d’affichage. L’invention concerne également, comme le montre à titre d’exemple schématiquement la FIG. 2 , considérée en relation avec la FIG. 1 , un procédé d’assistance à la conduite d’un véhicule (EGO) dont le déplacement est au moins partiellement contrôlé par des applications (APP 1, APP 2, APP N) par le biais de contraintes/requêtes, caractérisé en ce qu’il consiste, pour une application (APP 1, APP 2, APP N) donnée, 1) à transmettre une requête ou contrainte à un composant logiciel planificateur (PP) lorsque ladite application l’estime nécessaire, 2) à renvoyer vers ladite application une confirmation de prise en compte ou non de ladite requête/contrainte par ledit composant logiciel planificateur, 3) à transmettre par ladite application une demande d’affichage à un composant logiciel (GIHM) gestionnaire des interfaces homme-machine (IHM) du véhicule (EGO) en fonction de la confirmation du composant logiciel planificateur et d’éventuelles informations complémentaires à sa disposition, 4) à arbitrer la demande d’affichage au niveau dudit composant logiciel gestionnaire, en tenant compte des demandes provenant d’autres applications (APP 1, APP 2, APP N) et à adresser des commandes résultantes aux interfaces homme-machine (IHM) concernées, ce en mettant en œuvre le procédé de gestion d’affichage décrit ci-dessus. Ainsi, en plus de la gestion de l’affichage décrite précédemment, le procédé d’assistance à la conduite met en œuvre une fonction préalable d’arbitrage entre les différentes contraintes émises par la pluralité applications (APP 1, APP 2, …, APPN) avant que ces dernières ne communiquent avec le composant logiciel (GIHM) gestionnaire des interfaces homme-machine (IHM). Dans le cadre de la présente invention, cette fonction d’arbitrage est remplie par un logiciel (PP) de planification du trajet du véhicule (EGO) qui reçoit les différentes requêtes/contraintes, par exemple du type : éviter collision, suivre cible, changer de voie, allumer éclairage, mettre en route les essuie-glaces, … Le premier étage du composant logiciel (PP) de planification est avantageusement constitué d’un bloc d’arbitrage des contraintes reçues. Il n’y a pas de limite au nombre d’applications qui émettent des contraintes et le logiciel (PP) de planification s’appuie sur des règles prédétermination pour la priorisation. Ces règles tiennent compte du type de contrainte (par exemple urgence ou confort) ainsi que des conditions environnantes (ODD pour certaines fonctions, cible la plus limitante dans le cas de suivi de cible, etc.). Le logiciel (PP) de planification répond à chaque application qui aura envoyé une contrainte pour l’informer si cette contrainte est acceptée ou non. S’il accepte la contrainte cette dernière est mise à l’exécution par le véhicule, s’il la refuse, elle ne l’est pas. Par exemple, si une application émet une contrainte « changer de voie » et une autre application émet une contrainte « suivre cible devant », le logiciel (PP) de planification peut choisir de refuser le « changer de voie » et accepter « suivre cible devant ». Cela implique que le véhicule (EGO) restera dans sa voie en mode suivi de cible. Lorsqu’une application reçoit l’acceptation/ le refus de sa demande une IHM spécifique peut être demandée par cette application. Par exemple, l’application ACC en suivi de cible activée demandera un pictogramme d’activation (un véhicule vert au tableau de bord). En cas de désactivation temporaire, un pictogramme différent s’affichera (un véhicule orange au tableau de bord). En cas de désactivation durable, un autre troisième pictogramme sera visible (un véhicule gris au tableau de bord). D’autres applications peuvent avoir besoin d’utiliser ce même pictogramme déjà utilisé par l’ACC en suivi de cible. Par exemple, une application AEB pourrait afficher un pictogramme rouge à la même place que les pictogrammes de l’ACC. Il peut aussi être envisager que l’AEB n’affiche rien sur ce pictogramme précité et affiche un message ailleurs, mais que pendant cette activation il est souhaité de faire disparaître le pictogramme de l’ACC. Il ressort de ce qui précède que le procédé d’assistance précité repose essentiellement sur les trois procédures fondamentales suivantes : Une fonction d’arbitrage commune : toutes les applications (APP 1, APP 2, …, APPN) émettent des requêtes/contraintes à un arbitre, à savoir un logiciel (PP) de planification du trajet du véhicule (EGO). Cela est important pour la modularité, les applications ne communiquent pas « entre elles ». Les applications ne dialoguent qu’avec l’arbitre : elles font une demande et reçoivent une réponse. C’est à l’arbitre de décider quelles applications ont leurs demandes acceptées/refusées. L’arbitre met en œuvre un jeu de règles prédéterminé pour décider. Une fonction de gestion globale d’affichage : le composant logiciel (GIHM) gestionnaire des interfaces homme-machine (IHM) décide de ce qu’est allumé/affiché (ou pas) sur les IHM du véhicule. Les applications ignorent comment leurs demandes d’affichage/signalisation sont concrétisées : LED, pictogramme sur un TFT, animation visuelle ou sonore, … Les règles de fonctionnement du composant logiciel (GIHM) gestionnaire peuvent évoluer dans le temps en fonction du véhicule. L’utilisation d’un protocole commun : toutes les applications utilisent le même formalisme pour communiquer avec le composant logiciel (GIHM) gestionnaire des interfaces homme-machine (IHM). Ce protocole commun permet audit composant logiciel (GIHM) gestionnaire de pouvoir appliquer ses règles. Tant que le protocole est le même de nouvelles applications peuvent être ajoutées à celles déjà existantes. Bien entendu, chaque application peut utiliser un codage et une structure qui lui est propre, mais le procédé d’assistance présente toujours les quatre étapes successives représentées sur la FIG. 2 . Sur cette dernière, les applications comportent deux sous-blocs fonctionnels à savoir une unité décisionnelle (DU) qui génère ls requêtes lorsque les conditions sont données et les envoient à l’arbitre, et une unité de génération et d’envoi (selon le protocole fixé) de demandes d’affichage (IU). L’invention porte aussi sur un système embarqué d’assistance à la conduite pour un véhicule automobile (EGO) comprenant, d’une part, un composant logiciel (PP) planificateur de trajectoires et des applications (APP 1, APP 2, APP N) de confort ou de sécurité transmettant séparément des requêtes ou contraintes audit composant logiciel planificateur (PP) pour exécution par le véhicule (EGO) et, d’autre part, une pluralité d’interfaces homme-machine (IHM) pour l’affichage ou la signalisation d’informations, dont certaines au moins provenant des applications précitées, et un composant logiciel (GIHM) gestionnaire desdites interfaces homme-machine (IHM), l’utilisation d’au moins une interface (IHM) pouvant être sollicitée simultanément par au moins deux applications (APP 1, APP 2, APP N) différentes, ne communiquant pas entre elles. Conformément à l’invention, ce système est caractérisé en ce que le composant logiciel planificateur (PP) est configuré pour recevoir et arbitrer selon des règles de priorisation prédéfinies des contraintes/requêtes provenant des applications (APP 1, APP 2, APP N), en ce que lesdites applications (APP 1, APP 2, APP N) sont configurées pour adresser chacune une demande d’affichage au composant logiciel gestionnaire (GIHM) en accord avec le résultat de l’arbitrage et selon un protocole prédéfini commun aux différentes applications, et en ce que le composant logiciel gestionnaire (GIHM) est configuré pour décider de la suite positive ou négative à donner à cette demande, et le cas échéant du choix de l’interface (IHM) et des modalités d’affichage ou de signalisation sur ce dernier. Dans un souci de simplicité et d’universalité de communication, le protocole de communication unique utilisé par les applications (APP 1, APP 2, APP N) pour l’envoi de messages de demandes au composant logiciel gestionnaire (GIHM), chaque message de demande d’affichage comprend les champs suivants : le type de caractéristique liée au véhicule (EGO) et/ou à l’environnement concernée par la requête/contrainte, le degré d’urgence de cette caractéristique, l’état de cette caractéristique, la raison du changement d’état de la caractéristique et éventuellement un champ informatif spécifique à l’application concernée. Selon une caractéristique de l’invention et comme évoqué précédemment, le composant logiciel gestionnaire (GIHM) est configuré pour hiérarchiser les demandes d’affichage reçues des applications (APP 1, APP 2, APP N) en appliquant des règles et/ou des critères prédéfinis, prenant par exemple en compte le type de caractéristique liée au véhicule (EGO) et/ou à l’environnement concernée par la requête/contrainte liée à une demande, le degré d’urgence ou d’importance de la caractéristique concernée par cette demande et/ou l’éventuelle interdépendance de la caractéristique concernée par cette demande avec une autre caractéristique concernée par une autre demande. Avantageusement, et comme cela ressort par exemple de la FIG. 2 , chaque application (APP 1, APP 2, APP N) comprend une composante (DU) analytique et décisionnaire configurée pour transmettre sélectivement des requêtes ou contraintes au composant logiciel planificateur (PP) et une composante (IU) de commande d’affichage configuré pour générer et transmettre sélectivement des messages de demande d’affichage au composant logiciel gestionnaire (GIHM). En variante ou additionnellement à l’intégration d’une telle composante (DU), et comme cela ressort de la FIG. 1 , l’application (APP 1, APP 2, APP N) concernée peut aussi faire appel à, interroger ou être sollicitée par une composante logicielle (SU) globale de compréhension de l’environnement et de la situation et de l’état du véhicule (EGO), en relation avec l’établissement et de la transmission sélective de requêtes ou contraintes au composant logiciel planificateur (PP). Comme le montre à titre d’exemple la FIG. 1 , le système comprend préférentiellement également des moyens (C, WM, SU) de détection et d’évaluation de l’environnement du véhicule et de la situation courante de ce dernier, d’une part, et des moyens (PP, TMC, A) de détermination de la trajectoire et de contrôle du déplacement du véhicule, dont fait partie le composant logiciel planificateur (PP), d’autre part, ces différents moyens collaborant mutuellement et avec le composant logiciel gestionnaire (GIHM) et les différentes interfaces homme-machine (IHM) pour réaliser les fonctions attendues d’assistance à la conduite et en informer le conducteur du véhicule (EGO) et éventuellement ses occupants. Une possible architecture globale d’un système d’aide à la conduite selon l’invention est représentée de manière simplifiée à la FIG. 1 . Elle comprend trois couches fonctionnelles matérielles/logicielles représentées de manière superposée sur cette figure, à savoir : une couche inférieure comprenant les moyens matériels équipant le véhicule (« HW véhicule EGO ») et comprenant les capteurs et détecteurs internes et externes (C) fournissant les données d’état et de situation, les actionneurs (A) exécutant les instructions de commande de contrôle du déplacement du véhicule (EGO) et les interfaces homme-machine (IHM) pour l’affichage réglementaire et informatif une couche intermédiaire des intergiciels (« middleware ») propres au véhicule et comprenant un logiciel (WM) de modélisation du véhicule (EGO) et de son environnement, un logiciel (SU) de compréhension de l’environnement et de la situation et de l’état du véhicule (EGO), un logiciel (PP) de planification du trajet du véhicule (EGO) et un logiciel (TMC) de contrôle /commande de la trajectoire et du déplacement du véhicule (EGO). Cette couche intermédiaire comprend également le composant logiciel (GIHM) gestionnaire des interfaces homme-machine (IHM) recevant les demandes d’affichage des applications fonction des décisions du logiciel de planification (PP) et commandant les affichages sur les IHM, après arbitrage une couche supérieure (« Applications ») des applications (APP 1, APP 2, …, APPN), pouvant par exemple comprendre une application correspondant au système de freinage d’urgence (AEB) et une application correspondant au système adaptatif de régulation de vitesse (ACC). Dans cette architecture, les données d’entrées proviennent des capteurs (C), tels que caméra, LIDAR, sonar, traqueur ou analogue, ou encore détecteurs internes au véhicule (EGO). Ces données sont traitées (e.g. fusionnées) par le composant logiciel (WM), puis envoyées au composant logiciel (SU) afin que ce dernier puisse analyser des situations (telles qu’une collision) en prédisant la position d’objets dans le futur. Cet ensemble d’éléments matériels et logiciels compose la montée d’informations vers les applications. Les applications (APP 1, APP 2, …, APPi, …, APP N) s’abonnent alors à des situations du composant logiciel (SU) pour analyser un risque (par exemple l’application AEB) ou demander de suivre un véhicule (par exemple l’application ACC). Les applications envoient des contraintes ou requêtes (du type requête de manœuvre) au composant logiciel (PP) de planification du trajet du véhicule (EGO) dont le but est de générer une trajectoire pour satisfaire aux contraintes qu’il a reçu, en arbitrant notamment entre les différentes requêtes/contraintes émises par les applications. Le logiciel (TMC) de contrôle /commande de la trajectoire et du déplacement permet de générer les données/instructions permettant de contrôler les actionneurs du véhicule comme les freins, la direction (par les interfaces châssis) ou encore les moyens de propulsion. Simultanément, le composant logiciel (GIHM) gestionnaire des interfaces homme-machine (IHM) commande en conséquence l’affichage sur la ou les IHM concernée(s). Cet ensemble d’éléments matériels et logiciels compose la partie descendante de l’information. Préférentiellement, le système d’assistance met en œuvre les procédés décrits ci-dessus. Enfin l’invention concerne aussi un véhicule automobile (EGO) caractérisé en qu’il comprend un système d’assistance à la conduite tel que décrit précédemment. Bien entendu, l'invention n'est pas limitée au mode de réalisation décrit et représenté aux dessins annexés. Des modifications restent possibles, notamment du point de vue de la constitution des divers éléments ou par substitution d'équivalents techniques, sans sortir pour autant du domaine de protection de l'invention. Procédé de gestion d’affichage dans un véhicule automobile (EGO) comportant, d’une part, un système d’assistance à la conduite comprenant un composant logiciel (PP) planificateur de trajectoires et des applications (APP 1, APP 2, APP N) de confort ou de sécurité transmettant séparément des requêtes ou contraintes audit composant logiciel planificateur (PP) pour exécution par le véhicule (EGO) et, d’autre part, une pluralité d’interfaces homme-machine (IHM) pour l’affichage ou la signalisation d’informations, dont certaines au moins provenant des applications précitées, et un composant logiciel (GIHM) gestionnaire desdites interfaces homme-machine (IHM), l’utilisation d’au moins une interface (IHM) pouvant être sollicitée simultanément par au moins deux applications (APP 1, APP 2, APP N) différentes, ne communiquant pas entre elles, procédé caractérisé en ce qu’il consiste, pour chaque application (APP 1, APP 2, APP N) pour laquelle une contrainte/requête a été soumise au composant logiciel planificateur (PP) et arbitrée par ce dernier selon des règles de priorisation prédéfinies, à adresser une demande d’affichage au composant logiciel gestionnaire (GIHM) en accord avec le résultat de l’arbitrage et selon un protocole prédéfini commun aux différentes applications, et à décider au niveau dudit composant logiciel gestionnaire (GIHM) de la suite positive ou négative à donner à cette demande, et le cas échéant commander ladite au moins une interface (IHM) concernée en accord avec des modalités d’affichage ou de signalisation prédéterminées. Procédé selon la revendication 1, caractérisé en ce qu’il consiste à mettre en œuvre un protocole de communication défini par le composant logiciel gestionnaire (GIHM) et dans lequel chaque message de demande envoyé par une application (APP 1, APP 2, APP N) au composant logiciel gestionnaire (GIHM) comprend les champs suivants : le type de caractéristique liée au véhicule (EGO) et/ou à l’environnement concernée par la requête/contrainte, le degré d’urgence de cette caractéristique, l’état de cette caractéristique, la raison du changement d’état de la caractéristique et éventuellement un champ informatif spécifique à l’application concernée. Procédé selon la revendication 1 ou 2, caractérisé en ce qu’il consiste à hiérarchiser, au niveau du composant logiciel gestionnaire (GIHM), les demandes d’affichage reçues des applications (APP 1, APP 2, APP N) en appliquant des règles et/ou des critères prédéfinis, prenant par exemple en compte le type de caractéristique liée au véhicule (EGO) et/ou à l’environnement concernée par la requête/contrainte liée à une demande, le degré d’urgence ou d’importance de la caractéristique concernée par cette demande et/ou l’éventuelle interdépendance de la caractéristique concernée par cette demande avec une autre caractéristique concernée par une autre demande. Procédé selon l’une quelconque des revendications 1 à 3, caractérisé en ce qu’il consiste à solliciter ou commander au moins deux interfaces (IHM) différentes pour une même demande d’affichage. Procédé d’assistance à la conduite d’un véhicule (EGO) dont le déplacement est au moins partiellement contrôlé par des applications (APP 1, APP 2, APP N) par le biais de contraintes/requêtes, caractérisé en ce qu’il consiste, pour une application (APP 1, APP 2, APP N) donnée, 1) à transmettre une requête ou contrainte à un composant logiciel planificateur (PP) lorsque ladite application l’estime nécessaire, 2) à renvoyer vers ladite application une confirmation de prise en compte ou non de ladite requête/contrainte par ledit composant logiciel planificateur, 3) à transmettre par ladite application une demande d’affichage à un composant logiciel (GIHM) gestionnaire des interfaces homme-machine (IHM) du véhicule (EGO) en fonction de la confirmation du composant logiciel planificateur et d’éventuelles informations complémentaires à sa disposition, 4) à arbitrer la demande d’affichage au niveau dudit composant logiciel gestionnaire, en tenant compte des demandes provenant d’autres applications (APP 1, APP 2, APP N) et à adresser des commandes résultantes aux interfaces homme-machine (IHM) concernées, ce en mettant en œuvre le procédé de gestion d’affichage selon l’une quelconque des revendications 1 à 4. Système embarqué d’assistance à la conduite pour un véhicule automobile (EGO) comprenant, d’une part, un composant logiciel (PP) planificateur de trajectoires et des applications (APP 1, APP 2, APP N) de confort ou de sécurité transmettant séparément des requêtes ou contraintes audit composant logiciel planificateur (PP) pour exécution par le véhicule (EGO) et, d’autre part, une pluralité d’interfaces homme-machine (IHM) pour l’affichage ou la signalisation d’informations, dont certaines au moins provenant des applications précitées, et un composant logiciel (GIHM) gestionnaire desdites interfaces homme-machine (IHM), l’utilisation d’au moins une interface (IHM) pouvant être sollicitée simultanément par au moins deux applications (APP 1, APP 2, APP N) différentes, ne communiquant pas entre elles, système caractérisé en ce que le composant logiciel planificateur (PP) est configuré pour recevoir et arbitrer selon des règles de priorisation prédéfinies des contraintes/requêtes provenant des applications (APP 1, APP 2, APP N), en ce que lesdites applications (APP 1, APP 2, APP N) sont configurées pour adresser chacune une demande d’affichage au composant logiciel gestionnaire (GIHM) en accord avec le résultat de l’arbitrage et selon un protocole prédéfini commun aux différentes applications, et en ce que le composant logiciel gestionnaire (GIHM) est configuré pour décider de la suite positive ou négative à donner à cette demande, et le cas échéant du choix de l’interface (IHM) et des modalités d’affichage ou de signalisation sur ce dernier. Système selon la revendication 6, caractérisé en ce que dans le protocole de communication unique utilisé par les applications (APP 1, APP 2, APP N) pour l’envoi de messages de demandes au composant logiciel gestionnaire (GIHM), chaque message de demande d’affichage comprend les champs suivants : le type de caractéristique liée au véhicule (EGO) et/ou à l’environnement concernée par la requête/contrainte, le degré d’urgence de cette caractéristique, l’état de cette caractéristique, la raison du changement d’état de la caractéristique et éventuellement un champ informatif spécifique à l’application concernée. Système selon la revendication 6 ou 7, caractérisé en ce que le composant logiciel gestionnaire (GIHM) est configuré pour hiérarchiser les demandes d’affichage reçues des applications (APP 1, APP 2, APP N) en appliquant des règles et/ou des critères prédéfinis, prenant par exemple en compte le type de caractéristique liée au véhicule (EGO) et/ou à l’environnement concernée par la requête/contrainte liée à une demande, le degré d’urgence ou d’importance de la caractéristique concernée par cette demande et/ou l’éventuelle interdépendance de la caractéristique concernée par cette demande avec une autre caractéristique concernée par une autre demande. Système selon l’une quelconque des revendications 6 à 8, caractérisé en ce que chaque application (APP 1, APP 2, APP N) comprend une composante (DU) analytique et décisionnaire configurée pour transmettre sélectivement des requêtes ou contraintes au composant logiciel planificateur (PP) et une composante (IU) de commande d’affichage configuré pour générer et transmettre sélectivement des messages de demande d’affichage au composant logiciel gestionnaire (GIHM). Système selon l’une quelconque des revendications 6 à 9, caractérisé en ce qu’il comprend également des moyens (C, WM, SU) de détection et d’évaluation de l’environnement du véhicule et de la situation courante de ce dernier, d’une part, et des moyens (PP, TMC, A) de détermination de la trajectoire et de contrôle du déplacement du véhicule, dont fait partie le composant logiciel planificateur (PP), d’autre part, ces différents moyens collaborant mutuellement et avec le composant logiciel gestionnaire (GIHM) et les différentes interfaces homme-machine (IHM) pour réaliser les fonctions attendues d’assistance à la conduite et en informer le conducteur du véhicule (EGO) et éventuellement ses occupants. Système selon l’une quelconque des revendications 6 à 10, caractérisé en ce qu’il met en œuvre le procédé de gestion d’affichage selon l’une quelconque des revendications 1 à 4 et le procédé d’assistance à la conduite selon la revendication 5. Véhicule automobile (EGO) caractérisé en qu’il comprend un système d’assistance à la conduite selon l’une quelconque des revendications 6 à 11.