Brevet FR3104794A1 — publié le 20210618

Dispositif d’affichage multimédia (1) pour véhicule automobile, comprenant un écran d’affichage principal (2) comprenant un système d’exploitation de type Android™ (5) avec des couches basses basées sur un système Linux, et une dalle pixélisée monolithique (20) comprenant au moins une première portion (21) dédiée à l’affichage des applications compatibles Android™, et une deuxième portion (22) dédiée à l’affichage d’applications natives du véhicule, l’écran d’affichage principal comprenant en outre un microprocesseur principal (3) sur lequel tourne le système d’exploitation Android™ qui commande la dalle pixelisée monolithique (20) et un microcontrôleur auxiliaire (4) en charge de la surveillance de la bonne exécution des opérations sur le microprocesseur principal, le microcontrôleur auxiliaire (4) étant en charge de commander l’alimentation électrique de l’écran d’affichage principal, la totalité de la surface de la dalle pixélisée étant commandée par la fonction « gestionnaire et composition des fenêtres d’affichage » du système d’exploitation Android™. Dispositif d’affichage multimédia pour véhicule La présente invention est relative aux dispositifs d’affichage multimédia utilisés à l’intérieur des véhicules automobiles, qui mettent à disposition des occupants des informations de type info-divertissement (‘infotainment’) et des informations classiquement affichées dans un combiné d’instruments. On cherche notamment à accepter et accueillir dans le contexte automobile des applications qui viennent du domaine des appareils nomades de type tablette ou téléphone multifonction (‘Smartphone’). Il a déjà été proposé d’utiliser un système nommé Hyperviseur (‘hypervisor’ en anglais’) pour gérer dans un seul afficheur principal des informations de type combiné instrument avec des informations d’info-divertissement. Il s’avère toutefois que cette solution est très gourmande en ressources, difficile à mettre en place et très dispendieuse. De plus, le temps de démarrage d’un tel système d’exploitation Hypervisor peut s’avèrer trop long pour une application automobile. Il est donc apparu un besoin pour proposer une solution plus simple et plus optimisée, convenant pour une application de combiné d’instruments de véhicule, tout en ne négligeant pas les aspects de sureté de fonctionnement. À cet effet, il est donc proposé un dispositif d’affichage multimédia pour véhicule automobile, notamment combinant des fonctions d’info divertissement et des fonctions de tableau de bord, ledit dispositif comprenant : - un écran d’affichage principal (2) comprenant un système d’exploitation pour téléphones intelligents (typiquement de type Android™) acceptant l’exécution d’applications compatibles avec ledit système d’exploitation (c’est-à-dire des applications compatibles Android™), avec des couches basses basées sur un système Linux™, et une dalle pixélisée monolithique comprenant au moins une première portion (21) dédiée à l’affichage des applications compatibles pour téléphones intelligents, et au moins une deuxième portion (22) dédiée à l’affichage d’une ou plusieurs applications natives du véhicule, l’écran d’affichage principal comprenant en outre un microprocesseur principal (3) sur lequel tourne le système d’exploitation pour téléphones intelligents qui commande la dalle pixelisée monolithique et un microcontrôleur auxiliaire (4) en charge de la surveillance de la bonne exécution des opérations sur le microprocesseur principal avec au moins une fonction dite chien de garde, le microcontrôleur auxiliaire (4) étant en charge de commander l’alimentation électrique de l’écran d’affichage principal, la totalité de la surface de la dalle pixélisée étant commandée par la fonction « gestionnaire et composition des fenêtres d’affichage » du système d’exploitation de type Android™. Moyennant quoi, des informations affichées habituellement sur un combiné d’instruments sont affichées ici dans un afficheur tournant sous Android™, qui respecte les prescriptions d’un niveau requis de sûreté de fonctionnement et un temps de démarrage suffisamment court pour les applications natives du véhicule. Nota : le terme « système d’exploitation pour téléphones intelligents » a été utilisé pour désigner en langue française un système d’exploitation à code ouvert (‘open source’) développé par la société Google™ et équipant un très grand nombre de téléphones intelligents dit Smartphones depuis au moins les années 2010, et pour lequel un très grand nombre d’applications sont disponibles. Le terme « système d’exploitation pour téléphones intelligents » désigne toutes les évolutions futures du système d’exploitation Android™ et de son ou ses éventuels successeurs. Sous le terme « gestionnaire et composition des fenêtres d’affichage », il faut comprendre les fonctions « Window Manager » et « Window Composer » du système d’exploitation de type Android™, ou autrement appelée ensemble « Window Manager / Composer ». Ici, il faut comprendre que sous le terme « dispositif d’affichage multimédia » on désigne un dispositif qui inclut à la fois des fonctions d’info divertissement et des fonctions de tableau de bord conventionnel (‘combiné d’instruments’), le tout étant mutualisé dans un seul organe. Avantageusement, la fonction « Window Manager / Composer » sous Linux démarre (i.e. est prête) avant les applications compatibles Android™. On note que la fonction « Window Manager / Composer » définit pour les applications compatibles Android™ une taille d’affichage plus petite que la taille disponible de la dalle pixélisée monolithique, le restant étant dédié à l’insertion de l’affichage relatif aux applications natives du véhicule. Notons que les applications Android™ n’ont pas à être modifiées. Elles s’exécutent sans avoir conscience de l’environnement mis en place par l’invention. On entend ici par « applications natives du véhicule » des fonctions propres au fonctionnement du véhicule, notamment à la conduite du véhicule, et qui sont indépendantes fonctionnellement des applications info-divertissement venant du monde des appareils nomades de type Smartphone ou tablette. Une application native est généralement connectée aux données du véhicule. Comme exemples d’applications natives du véhicule, on peut citer l’affichage de la vitesse de déplacement courante du véhicule (c’est-à-dire le « compteur de vitesse »), de différentes informations liées à la manœuvre du véhicule, comme par exemple l’affichage d’une caméra de recul ; on peut citer aussi l’affichage de l’autonomie restante dans la batterie électrique, de la jauge de carburant, diverses informations de température et/ou de régime moteur. Selon un autre aspect avantageux, la fonction « Window Manager / Composer » de Android™ est considéré stable et n’est pas affectée par les fréquentes mises à jour du système complet Android™. Ainsi, il ne sera pas nécessaire de modifier et rendre compatible la fonction affichage des applications natives du véhicule à chaque fois que Android™ sera mise à jour. Dans divers modes de réalisation de l’invention, on peut éventuellement avoir recours en outre à l’une et/ou à l’autre des dispositions suivantes, prises isolément ou en combinaison. Selon un aspect avantageux, le microcontrôleur auxiliaire (4) est configuré pour générer un reset du microprocesseur principal (3), dans le cas où le microcontrôleur auxiliaire (4) constate un dysfonctionnement du microprocesseur principal (3). Il s’agit ici de la fonction chien de garde c’est-à-dire de la fonction connue dans le métier sous le terme anglais « Watchdog » qui surveille une émission régulière d’un ou plusieurs messages répétitifs du microprocesseur principal à destination du microcontrôleur auxiliaire, et dans le cas où la réception des messages attendus n’est pas correcte ou absente, alors le microcontrôleur auxiliaire peut générer un reset hardware sur une entrée du microprocesseur principal. Selon un aspect, la durée de démarrage pour l’affichage des applications natives du véhicule est substantiellement inférieure à la durée de démarrage pour l’affichage des d’applications compatibles avec ledit système d’exploitation pour téléphones intelligents. Comme la fonction « Window Manager / Composer » tournant sous Linux démarre (i.e. est prête) avant que les applications compatibles Android™ ne démarrent, dès que les applications natives ont démarré, l’affichage est opérationnel et disponible sur la deuxième portion (22) de l’écran d’affichage principal (2), alors que la première portion de l’écran mettra plus de temps pour être disponible. Par exemple on peut avoir moins de 10 secondes maximum, voire moins de 5 secondes, et même 3 secondes ou moins, pour le démarrage effectif de la deuxième portion (22) de l’écran ; alors qu’à l’inverse pour la première portion de l’écran, il faut compter typiquement plus de 10 secondes, voire 15 secondes pour avoir l’affichage des applications Android™. Selon un aspect, il est prévu deux zones mémoire spécifiques distinctes, une première zone mémoire pour l’exécution des applications compatibles avec ledit système d’exploitation pour téléphones intelligents, et une deuxième zone mémoire pour l’exécution des applications natives véhicule. Autrement dit il est prévu dans la machine virtuelle Android™ (ART Android RunTime), deux zones mémoire distinctes respectivement pour l’exécution des applications compatibles Android™ et pour l’exécution des applications natives véhicule. On obtient ainsi une certaine indépendance entre les applications info-divertissement et les fonctions natives du véhicule. Selon un aspect, la dalle pixélisée monolithique est tactile, au moins sur la première portion. Ceci permet une interaction tactile, en particulier pour les applications info-divertissement, qui viennent du domaine des appareils nomades de type tablette ou Smartphone, pour lesquels la fonction tactile est essentielle. On note que la deuxième portion peut être elle aussi tactile le cas échéant, mais dans le cas d’usage d’un tableau de bord, ceci n’est généralement pas nécessaire. Selon un aspect, la première portion de la dalle pixélisée et la deuxième portion de la dalle pixélisée sont séparées par une ligne de séparation verticale et la première portion de la dalle pixélisée est située du côté du poste de conduite, i.e. à gauche pour un véhicule conduite à gauche. Ainsi l’affichage des fonctions Android™ se trouve à portée des doigts de la main pour le conducteur et donc ceci procure une bonne ergonomie, notamment pour les personnes de petite taille. Selon un aspect, la dalle pixélisée monolithique comprend au moins 1000 pixels dans la direction horizontale et au moins 500 pixels dans la direction verticale. On a ainsi une grande taille, avec largesse et bonne visibilité et une fine résolution, procurant ainsi une facilité et un confort de lecture pour le conducteur mais aussi les autres occupants du véhicule. Selon un aspect, les applications natives du véhicule comprennent une fonction compteur de vitesse et une fonction caméra de recul. Ce sont des modules conçus comme des modules indépendants, notamment vis-à-vis des applications Android™, ces modules sont établis en code source en C++, compilées et assemblées. Ces modules sont exécutés sur le microprocesseur principal. Selon un aspect, le dispositif peut comprendre en outre un afficheur auxiliaire commandé par le microcontrôleur auxiliaire. Cet afficheur auxiliaire comprend des fonctions d’indicateurs lumineux qui regroupe les signaux « vitaux » du véhicule comme par exemple les témoins de clignotants, des feux de détresse, des phares et des feux de signalisation. Avantageusement, le démarrage de l’afficheur auxiliaire est immédiat, par exemple inférieur à 500 millisecondes. L’afficheur auxiliaire peut inclure également un voyant « stop », et il est prévu d’allumer ce voyant « stop » dans le cas où le microcontrôleur auxiliaire constate un dysfonctionnement établi et/ou caractérisé du microprocesseur principal. Selon un aspect, la dalle pixélisée peut comprendre au moins une troisième portion, dont la taille et la position peuvent être définies par un utilisateur dudit dispositif d’affichage. Exemple : une barre de menu ou un système de multi fenêtrage dans la première portion. Selon un aspect, la première portion de la dalle pixélisée occupe 2/3 de la surface et la deuxième portion de la dalle pixélisée occupe 1/3 de la surface. Ceci procure généralement une bonne ergonomie de lecture, la zone dédiée à l’info divertissement étant sensiblement deux fois plus large que la zone dédiée aux applications natives du véhicule. Selon un aspect, la première portion et la deuxième portion de la dalle pixélisée peuvent être séparées par une ligne de séparation verticale qui peut être déplacée dans une direction horizontale par un utilisateur dudit dispositif d’affichage. Ceci procure une bonne ergonomie car on peut ainsi ajuster les tailles respectives des première et deuxième portions suivant les préférences utilisateur. Selon un aspect, le microcontrôleur auxiliaire comprend au moins une interface de réseau CAN pour échanger des informations avec d’autres entités du véhicule. Ainsi, les fonctions « vitales » du véhicule ne dépendent pas d’Android™. Et donc même si un aléa se présente sur les fonctions de type Android™, cela n’affecte pas le fonctionnement de base du véhicule. Selon un aspect, le microcontrôleur auxiliaire comprend un système d’exploitation temps réel pour les systèmes embarqués automobile, de préférence un système d’exploitation répondant aux critères Autosar™. Ainsi, les fonctions « vitales » du véhicule sont gérées par un système d’exploitation bien connu, orientée vers le temps réel et la fiabilité exécution, à l’inverse de certaines applications tournant sous-système Android™. Selon un aspect, le microprocesseur principal (3) commande à la fois l’affichage des informations sur la première portion et sur la deuxième portion de la dalle pixélisée. Avantageusement, il est prévu de limiter la taille de la fenêtre relative aux applications info divertissement et d’insérer l’affichage des applications natives dans la zone restant disponible, ce processus étend géré par le gestionnaire de fenêtres du microprocesseur principal. Selon un aspect, il peut être prévu dans l’écran d’affichage principal (2) au moins une ou plusieurs interfaces de communication sans fil, cellulaire 4G et/ou 5G, WIFI, Bluetooth. Ceci permet de supporter les fonctions de communication pour la réception et l’envoi de données par exemple pour le système de navigation, pour la communication avec un appareil nomade à bord du véhicule par exemple pour la fonction téléphonie mains libres. Selon un aspect, il peut être prévu au moins dans l’écran d’affichage principal une ou plusieurs antennes et tuners AM/FM/DAB. Ces éléments concourent à la fonction autoradio. La présente invention vise également un véhicule comportant un dispositif d’affichage tel que défini ci-dessus. D’autres aspects, buts et avantages de l’invention apparaîtront à la lecture de la description suivante d’un mode de réalisation de l’invention, donné à titre d’exemple non limitatif. L’invention sera également mieux comprise en regard des dessins joints sur lesquels : - la figure 1 est un schéma de principe général d’un mode de réalisation de l’invention, - la figure 2 représente un exemple de bloc diagramme concernant l’écran d’affichage principal, - la figure 3 représente une vue schématique fonctionnelle concernant l’écran d’affichage principal, - la figure 4 illustre un exemple de chronographe de démarrage. Sur les différentes figures, les mêmes références désignent des éléments identiques ou similaires. Sur la figure 1 , on a représenté schématiquement un intérieur de véhicule automobile avec une planche de bord 8 qui peut s’étendre sur toute la largeur du véhicule en face du conducteur et du passager avant. Comme classiquement, il est prévu un volant de conduite repéré 19 . Il a été représenté une configuration de conduite à gauche (donc avec le volant côté gauche), mais l’invention vise tout autant une configuration de conduite à droite obtenue par symétrie droite-gauche. Dans le contexte de la présente invention, on dispose un écran d’affichage principal 2 , ici dans une position substantiellement centrale véhicule. Selon cette disposition, l’ensemble des occupants du véhicule peut voir le contenu des informations affichées sur l’écran d’affichage principal 2 . Le fonctionnement et le contenu de l’affichage sur cet écran d’affichage principal seront vues plus loin. Dans le contexte de la présente invention, on prévoit préférentiellement bien que cela reste optionnel, un afficheur auxiliaire repéré 9 . Cet afficheur auxiliaire 9 comprend des indicateurs lumineux sur des informations « vitales » du véhicule comme par exemple les témoins de clignotants, des feux de détresse, des phares et des feux de signalisation. Cet afficheur auxiliaire 9 peut se trouver typiquement dans la zone du volant de conduite c’est-à-dire dédiée particulièrement au conducteur et pas aux autres occupants du véhicule. L’afficheur auxiliaire 9 peut comporter son propre microcontrôleur ou bien être commandé par un microcontrôleur auxiliaire dont il sera question plus loin. L’afficheur auxiliaire 9 peut comporter un témoin d’alerte représentatif d’un dysfonctionnement affectant l’écran d’affichage principal. Ce témoin d’alerte peut être similaire à ou confondu avec un voyant « stop » connu dans l’art. Le conducteur peut alors être notifié d’un dysfonctionnement grave de l’écran d’affichage principal, même si ce défaut n’apparaît pas explicitement sur la dalle de l’écran d’affichage principal ce qui permet de renforcer la sureté de fonctionnement. Avantageusement, le démarrage de l’afficheur auxiliaire est immédiat, par exemple inférieur à 500 ms. L’écran d’affichage principal 2 présente, dans sa partie visible de l’extérieur, une dalle pixélisée monolithique 20 . En pratique il peut s’agir d’un écran LCD matricielle ou d’un écran à base de matrice de composants OLEDs. Dans l’exemple illustré, la dalle pixélisée monolithique de l’écran comprend une première portion (notée 21 ) dédiée à l’affichage d’une ou plusieurs applications compatibles Android™, et une deuxième portion (notée 22 ) dédiée à l’affichage d’une ou plusieurs applications natives du véhicule. La première portion est configurée pour mettre à disposition des occupants des informations de type info-divertissement (‘infotainment’) en provenance d’applications émanant du domaine des appareils nomades de type tablette ou téléphone multifonction (Smartphone). La deuxième portion de la dalle d’affichage est configurée pour mettre à disposition des informations classiquement affichées dans un combiné d’instruments du véhicule, comme par exemple le compteur de vitesse où la réserve restante en énergie électrique ou de carburant. Il peut être prévu optionnellement une troisième portion d’affichage, pour héberger par exemple une barre de menu général de configuration. La taille et la position de cette troisième portion d’affichage peuvent être définies par un utilisateur dudit dispositif d’affichage. La troisième portion d’affichage peut se présenter aussi comme une incrustation « Picture-in-Picture » dans la première portion affichage 21. Dans l’exemple illustré, la première portion de la dalle pixélisée occupe 2/3 de la surface et la deuxième portion de la dalle pixélisée occupe 1/3 de la surface, ce qui procure généralement une bonne ergonomie de lecture. On remarque que dans ce cas la zone dédiée à l’info divertissement étant sensiblement deux fois plus large que la zone dédiée aux applications natives du véhicule. Toutefois les proportions respectives pourraient être différentes. Par exemple, la première portion et la deuxième portion de la dalle pixélisée pourrait être séparées par une ligne de séparation verticale 23 qui peut être déplacée dans une direction horizontale par une opération tactile de l’utilisateur dudit dispositif d’affichage. Ceci peut procurer une bonne ergonomie car on peut ainsi ajuster les tailles respectives des première et deuxième portions suivant les préférences utilisateur. On peut aussi remarquer que les premières et deuxièmes portions pourraient être échangées (swap 21 22 ). Dans l’exemple illustré, pour une conduite à gauche, la première portion de la dalle pixélisée est située du côté du poste de conduite, i.e. à gauche pour un véhicule conduite à gauche, ce qui facilite une interaction tactile entre le conducteur et la première portion 21 relative à l’affichage des fonctions info divertissement. La fonction d’échange droite-gauche permet donc d’utiliser le même écran d’affichage principal 2 configuré soit pour un véhicule de type conduite à gauche ou un véhicule de type conduite à droite. Pour faciliter les interactions entre l’utilisateur et des applications de type Android™, la dalle pixélisée monolithique est de préférence tactile, au moins sur la première portion. Il peut être prévu que la deuxième portion soit aussi tactile en vue de permettre à l’utilisateur de modifier la configuration de l’affichage des fonctions natives du véhicule. Il est prévu que l’utilisateur puisse utiliser des éléments externes pour contrôler l’affichage, comme des commutateurs et/ou des manettes disposées dans la zone du volant de conduite, ou encore un ou des joystick(s) disposé(s) à portée de main du conducteur sur la console centrale. Il est aussi prévu d’utiliser un système de reconnaissance vocale pour interagir avec l’écran principal. L’écran d’affichage principal 2 incorpore un système d’exploitation de type Android™ 5 acceptant l’exécution d’applications compatibles Android™, ainsi que des applications dites natives conçues pour fonctionner sur des couches basses Android™ qui sont basées sur un système Linux. Le système d’exploitation de type Android™ 5 tourne sur un microprocesseur principal noté 3 installé dans l’écran d’affichage 2 . Le microprocesseur principal 3 est de type ‘SOC’ c’est-à-dire « système sur une puce », avec notamment plusieurs types de ressources hardware notamment de la mémoire flash. Parmi les applications compatibles Android™ considérées, on trouve des applications de navigation informée en temps réel (par exemple Waze™ ou équivalent), un ou plusieurs navigateurs Internet, différentes applications liées aux véhicules électriques y compris aux bornes de recharge, la réception de flux audio ou vidéo via Internet, ces exemples ne constituant aucunement une limitation, des lecteurs de fichiers au format MP3 ou MP4. La liste ci-dessus née bien entendue pas limitative. De façon avantageuse, n’importe quelle application compatible Android™ peut être téléchargée et rendu opérative sur le microprocesseur principal 3 du système d’exploitation de l’écran d’affichage. Il faut remarquer de plus que les applications compatibles Android™ peuvent être exécutées sans aucun changement, telles qu’elles ont été téléchargées, sans aucun changement nécessaire. De même, le système peut recevoir une mise à jour du système d’exploitation Android™ lui-même c’est-à-dire une nouvelle version d’Android™. En marge du microprocesseur principal 3 , il est prévu, dans l’écran d’affichage, un microcontrôleur auxiliaire 4 . Le microcontrôleur auxiliaire 4 est en charge en particulier de commander l’alimentation électrique de l’écran d’affichage principal. Par ailleurs, le microcontrôleur auxiliaire 4 est en charge de surveiller la bonne exécution des opérations sur le microprocesseur principal avec au moins une fonction dite chien de garde. Le microcontrôleur auxiliaire 4 fonctionne grâce à un système d’exploitation temps réel pour les systèmes embarqués automobile, de préférence un système d’exploitation répondant aux critères Autosar™. Un tel système d’exploitation est particulièrement adapté pour les exigences de fiabilité dans le contexte des systèmes embarqués automobile où les erreurs d’exécution ne sont pas autorisées ou à minima doivent être complètement transparentes. En pratique, le microcontrôleur auxiliaire attend des messages spécifiques périodiques en provenance du microprocesseur principal ; dans l’éventualité où la réception de ces messages n’est pas correcte ou ne se produit pas du tout, le microcontrôleur auxiliaire 4 peut provoquer un reset hardware du microprocesseur principal 3 . À la figure 2 , on remarque la ligne alimentation ‘ Alim’ , et la ligne reset ‘ Rst’ , qui vont du microcontrôleur auxiliaire vers le microprocesseur principal. À l’inverse, la ligne qui porte les messages de surveillance périodique est notée ‘ WD’ . Ainsi même si le système d’activation Android™ venait à se bloquer, pour une raison ou pour une autre, le microcontrôleur auxiliaire 4 pourra relancer le programme du microprocesseur principal 3 sans aucune action nécessaire de la part de l’utilisateur du véhicule afin de garantir un niveau de sûreté de fonctionnement suffisant pour le système d’affichage multimédia. En pratique, la durée de démarrage pour l’affichage des applications natives du véhicule est inférieure, voire très inférieure, à la durée de démarrage pour l’affichage des d’applications compatibles Android™. Comme la fonction « Window Manager / Composer » tournant sous Linux démarre (i.e. est prête) avant que les applications compatibles Android™ ne démarrent, dès que les applications natives ont démarré, l’affichage est opérationnel et disponible sur la deuxième portion 22 de l’écran d’affichage principal, alors que la première portion 21 de l’écran mettra plus de temps pour être disponible. On vise typiquement un temps de mise à disposition de la partie deuxième portion de l’affichage inférieur à cinq secondes, de préférence inférieure à trois secondes, voire inférieure à deux secondes. Parmi les applications natives du véhicule, on peut avoir typiquement une fonction compteur de vitesse et une fonction caméra de recul. On peut également avoir des informations de synthèse à propos du véhicule électrique si tel est le cas par exemple la réserve d’énergie électrique présente dans la batterie, l’autonomie correspondant en kilomètres ou miles, la distance à la prochaine borne de recharge disponible. On peut alternativement avoir une information concernant la jauge à carburant du véhicule. Dans l’exemple illustré la figure 1 et à la figure 2, on voit dans la deuxième portion de l’écran d’affichage de la vitesse courante, à savoir 102 km/h, de la température ambiante extérieure, à savoir 21°C, de la position du levier de vitesse, sur D, de l’heure courante, à savoir 4:28h, d’un odomètre partiel, à savoir 120 km et de la réserve d’énergie sous forme d’un graphique à 60 % de remplissage. En référence à la figure 2 , l’écran d’affichage principal comprend des coupleurs de communication pour la connectivité Internet par exemple 4G/5G. L’écran d’affichage principal peut comprendre en outre un coupleur Wi-Fi et/ou un coupleur Bluetooth pour la connexion un appareil nomade présent à bord du véhicule. Par ailleurs l’écran d’affichage principal peut comprendre une ou plusieurs syntoniseurs de réception des ondes radio pour recevoir via une antenne FM/AM les programmes audio radiodiffusés, et les diffuser sur des haut-parleurs présents à bord du véhicule. Par ailleurs l’écran d’affichage reçoit le flux de signaux numériques en provenance d’une caméra de recul situé sur l’arrière du véhicule. On remarque qu’il est prévu deux zones mémoire spécifiques distinctes, une première pour l’exécution des applications compatibles Android™, et une deuxième pour l’exécution des applications natives véhicule. Il est prévu une première zone mémoire M1 utilisée pour les éléments d’affichage relatifs aux applications Android™. Il est prévu une deuxième zone mémoire M2 distincte de la première utilisée pour les éléments d’affichage relatifs aux applications native du véhicule. Bien que les zones mémoire M1 , M2 aient été représentées à l’extérieur du microprocesseur principal 3 sur la figure 2, il faut comprendre que dans la pratique ces zones mémoire sont intégrées à l’intérieur de la puce SOC du microprocesseur principal 3 . Le microcontrôleur auxiliaire 4 gère les alimentations électriques, c’est-à-dire en pratique, il va réveiller les composants contenus dans l’écran d’affichage principal lorsque l’écran d’affichage principal est mis sous tension ou bien reçoit l’ordre d’un nouvel allumage. Le microcontrôleur auxiliaire 4 gère également les communications avec d’autres unités de contrôle électronique à bord du véhicule, notamment via l’interface de réseau CAN. (‘ Contrôleur Aera Network’). En revanche, c’est le microprocesseur principal 3 qui commande via la ligne de données 32 l’ensemble de l’affichage présenté sur la dalle pixelisée monolithique 20 , c’est-à-dire à la fois les première et deuxième portions d’affichage 21 , 22 . Plus précisément, le microprocesseur principal comprend un module appelé GPU (Graphical processing unit) en charge de transformer les données prêtes pour affichage en signaux de commande de la dalle pixelisée. En référence à la figure 3, on a représenté le flux des données correspondant à l’affichage des fonctions natives du véhicule par le trait en pointillés repéré 7 . Le flux de données à afficher par les applications natives du véhicule passe par le bloc 61 nommé ‘Open GL’ puis par le bloc 62 nommé ‘NATIVE FRAMEWORK’. Dans le bloc 65 nommé « WINDOW MANAGER », il est prévu que le gestionnaire de fenêtres procède à une opération de ‘ sizing’ qui consiste à limiter la taille occupée par l’affichage relatif aux applications Android™. En pratique cela permet d’insérer l’affichage des applications natives dans la zone qui se retrouve disponible par la réduction de taille de l’affichage relatif aux applications Android™. Dans le bloc 66 nommé « IMAGE STREAM CONSUMER » que l’on peut appeler aussi compositeur graphique, les deux parties d’affichage sont concaténées pour former un affichage qui va occuper l’ensemble de la surface de la dalle monolithique 20 . Il faut remarquer que les éléments d’affichage relatifs aux applications natives sont prêtes très rapidement après la mise en action de l’écran d’affichage, alors qu’à l’inverse les éléments d’affichage relatifs aux applications Android™ mettront généralement plus de temps pour être disponibles. On obtient ainsi le résultat remarquable que la durée de démarrage pour l’affichage des applications natives du véhicule est substantiellement inférieure à la durée de démarrage pour l’affichage des d’applications compatibles Android™. Plus précisément, sur les tailles respectives des premières et deuxièmes portions d’affichage 21 , 22 , il peut être prévu une répartition d’environ 2/3 1/3, s’agissant des tailles respectives en largeur des premières et deuxièmes portions d’affichage. Selon un exemple, la dalle pixélisée monolithique 20 peut comprendre au moins 1000 pixels dans la direction horizontale et au moins 500 pixels dans la direction verticale. Dans une implémentation type, la dalle pixélisée monolithique comprend 1980 pixels dans la direction horizontale et 720 pixels dans la direction verticale. Dans ces conditions, la première portion d’affichage comprend 1280 pixels dans la direction horizontale et la deuxième d’affichage comprend 700 pixels dans la direction horizontale, les deux portions présentant toutes deux 720 pixels dans la direction verticale. S’agissant des temps de démarrage des deux portions d’affichage, en référence à la figure 4, le temps de réaction T22 pour la mise à disposition opérationnelle des données d’affichage sur la seconde portion de la dalle est inférieur à 5 secondes et dans la pratique souvent inférieur à 3 secondes. À l’inverse le temps de réaction T21 pour la mise à disposition opérationnelle des données d’affichage sur la première portion de la dalle est supérieur à 5 secondes et dans la pratique souvent supérieure à 10 secondes. 1 . Dispositif d’affichage multimédia (1) pour véhicule automobile, ledit dispositif comprenant : - un écran d’affichage principal (2) comprenant un système d’exploitation pour téléphones intelligents (5) acceptant l’exécution d’applications compatibles avec ledit système d’exploitation, avec des couches basses basées sur un système Linux™, et - une dalle pixélisée monolithique (20) comprenant au moins une première portion (21) dédiée à l’affichage des applications compatibles et au moins une deuxième portion (22) dédiée à l’affichage d’une ou plusieurs applications natives du véhicule, l’écran d’affichage principal comprenant en outre un microprocesseur principal (3) sur lequel tourne le système d’exploitation pour téléphones intelligents qui commande la dalle pixelisée monolithique (20) et un microcontrôleur auxiliaire (4) en charge de la surveillance de la bonne exécution des opérations sur le microprocesseur principal avec au moins une fonction dite chien de garde, le microcontrôleur auxiliaire (4) étant en charge de commander l’alimentation électrique de l’écran d’affichage principal, la totalité de la surface de la dalle pixélisée étant commandée par la fonction « gestionnaire et composition des fenêtres d’affichage » du système d’exploitation de type pour téléphones intelligents . 2 . Dispositif d’affichage selon la revendication 1, dans lequel la durée de démarrage pour l’affichage des applications natives du véhicule est substantiellement inférieure à la durée de démarrage pour l’affichage des d’applications compatibles avec ledit système d’exploitation pour téléphones intelligents. 3 . Dispositif d’affichage selon la revendication 1, dans lequel il est prévu deux zones mémoire spécifiques distinctes (M1,M2), une première zone mémoire pour l’exécution des applications compatibles avec ledit système d’exploitation pour téléphones intelligents, et une deuxième zone mémoire pour l’exécution des applications natives véhicule. 4 . Dispositif d’affichage selon l'une des revendications 1 à 3, dans lequel la dalle pixélisée monolithique est tactile, au moins sur la première portion. 5 . Dispositif d’affichage selon la revendication 4, dans lequel la première portion de la dalle pixélisée et la deuxième portion de la dalle pixélisée sont séparées par une ligne de séparation verticale et la première portion de la dalle pixélisée est située du côté du poste de conduite, i.e. à gauche pour un véhicule conduite à gauche. 6 . Dispositif d’affichage selon l'une des revendications 1 à 5, dans lequel les applications natives du véhicule comprennent une fonction compteur de vitesse et une fonction caméra de recul. 7 . Dispositif d’affichage selon l'une des revendications 1 à 6, comprenant en outre un afficheur auxiliaire (9) commandé par le microcontrôleur auxiliaire (4). 8 . Dispositif d’affichage selon l'une des revendications 1 à 7, dans lequel le microcontrôleur auxiliaire (4) comprend au moins une interface de réseau CAN pour échanger des informations avec d’autres entités du véhicule. 9 . Dispositif d’affichage selon l'une des revendications 1 à 8, dans lequel le microprocesseur principal (3) commande à la fois l’affichage des informations sur la première portion (21) et sur la deuxième portion (22) de la dalle pixélisée. 10 . Véhicule comprenant dispositif d’affichage selon l'une des revendications précédentes.