FR 3096807 A1 20201204 FR 1905688 A 20190528 Description Titre de l'invention : Architecture procédé de mise à jour de tels composants Domaine technique [0001] La présente invention se rapporte de manière générale des systèmes embarqués dans le domaine automobile, et concerne plus particulièrement une architecture à la virtualisation Etat de la technique [0002] Depuis quelques années, la télématique a fait son apparition dans les applications au- tomobiles, notamment dans le contexte des véhicules connectés intelligents exploitant l'Internet-des-Objets (h10, ou IoT de l'anglais « Internet-of-Things ») et/ou de la conduite autonome. [0003] Plusieurs organisations spécialisées en télécommunications, comme la « 5G Au- tomotive Association » (5GAA) et la « Telematics Industry Application Alliance » (TIRA), par exemple, fédèrent des constructeurs automobiles et équipementiers automobiles (ou OEM, de l'anglais « Original Equipment Manufacturer ») d'une part, et des industriels des télécommunications d'autre part, afin de faire émerger des technologies de communication adaptées aux cas d'utilisation (« 'use cases » en anglais) dans le domaine automobile. Ainsi, de nouvelles technologies de communication, comme la technologie V2XTM (de l'anglais « Vehicle-to-Everything ») du Groupe PSA, non seulement offrent aux conducteurs l'accès à de nouveaux services connectés tels que la navigation et la reconnaissance vocale, mais aussi apportent des solutions de communication entre le véhicule et son environnement (autres véhicules, infrastructures, piétons, etc.). [0004] Les véhicules du Groupe PSA équipés de la technologie LTE-V2XTm (« Long Term Evolution V2X »), par exemple, pourront ainsi communiquer avec les infrastructures en bordure de route et recevoir des informations sur la circulation en temps réel par le biais des feux de signalisation, des autres véhicules ou de piétons situés hors du champ de vision du conducteur. Ces données peuvent servir à optimiser la vitesse afin de mieux négocier le franchissement d'une intersection, à être alerté d'un danger imminent grâce à des caméras intelligentes disposées sur la route ou à recevoir des informations tout au long d'un trajet. Les véhicules du Groupe PSA pourront également communiquer directement entre eux ainsi qu'avec les piétons. Le conducteur pourra, par exemple, être alerté si un véhicule qui le précède fait un freinage d'urgence ou si un piéton s'apprête à traverser la chaussée. Ainsi, le nombre va croissant des cas d'utilisation de modules électroniques conçus pour la communication des véhicules 2 avec leur environnement, notamment. [0005] Il s'ensuit que la tendance actuelle est d'embarquer de nombreux modules élec- troniques dans le véhicule, qui sont très divers. Ces modules fonctionnent en harmonie les uns avec les autres, sous la forme de composants applicatifs autonomes. Mais ils n'ont pas le même matériel (« Hardware » en anglais), et peuvent aussi reposer sur des systèmes d'exploitation (souvent appelés OS, de l'anglais « Operating System ») différents, comme LinuxTM, AndroidTM, iOSTM, RTOS (de l'anglais « Real Time Operating System») etc. [0006] En outre, l'activité des autorités de réglementation et d'autres organismes impose d'effectuer de nombreuses mises à jour des composants applicatifs embarqués dans un tel véhicule connecté. Ces mises à jour sont nécessaires voire obligatoires, par exemple, dans les cas d'applications critiques pour la sécurité, pour les appels d'urgence réglementés (ou E-Call, de l'anglais « Etnergency Call »), pour des spécifications OEM, pour les applications OTA (de l'anglais « Over-the-Air ») ayant une incidence sur le spectre radio, pour des applications tierces (en anglais « third party applications »), pour les passerelles provisionnelles (en anglais « Provisional Gateway »), etc. [0007] Or, dans les réalisations actuelles il n'y a pas de notion de ségrégation, c'est-à-dire pas d'isolation entre les différents composants applicatifs. Il s'ensuit qu'à chaque mise à jour d'un composant applicatif d'un système déterminé, il est nécessaire de réhomologuer individuellement chacun des autres composants applicatifs du système et/ou des autres systèmes. En effet, leur fonctionnement est susceptible d'être affecté par la modification d'un composant applicatif avec lequel ils interagissent, le cas échéant, ou avec lequel ils partagent des données. [0008] La mise en oeuvre des homologations, notamment lors des mises à jour d'un système ou d'un modèle (comme par exemple la règlementation relative aux E-call) est donc longue, chère et fastidieuse étant donné qu'il faut alors réhomologuer tous les systèmes un par un. [0009] Également, il y a une difficulté de communication entre les différents composants ap- plicatifs de systèmes respectifs, et/ou entre les différents composants applicatifs d'un système donné car ils n'ont pas le même Hardware. [0010] L'absence de ségrégation entre les différents modules applicatifs embarqués induit aussi des risques au niveau de la cybersécurité. Résumé de l'invention [0011] L'invention vise à supprimer, ou du moins atténuer, tout ou partie des inconvénients de l'art antérieur précités. [0012] A cet effet, un premier aspect de l'invention propose une architecture de système té- 3 lématique embarqué dans un véhicule automobile, comprenant : [0013] - une pluralité de composants applicatif ; [0014] - une plateforme matérielle commune aux composants applicatifs ; [0015] - un hyperviseur de type 1 s'exécutant sur la plateforme matérielle, pour contrôler l'accès aux ressources matérielles de la plateforme matérielle par les composants applicatifs en tant que machines virtuelles, [0016] l'architecture comprenant en outre des moyens pour propager une requête de mise à jour d'un programme d'application capable de s'exécuter dans un composant applicatif déterminé, vers ledit composant applicatif à travers l'hyperviseur de type 1. [0017] L'invention a notamment pour avantage de faciliter la mise à jour de composants ap- plicatifs nécessitant des mises à jour relativement fréquentes. En outre, un hyperviseur de type 1 est un dispositif particulièrement efficace. [0018] En effet, l'invention permet en particulier d'éviter le besoin de mettre en oeuvre un processus de re-certification pour tous les composants partageant le même logiciel, suite à la mise d'un jour de tout ou partie de cc logiciel. [0019] Des modes de réalisation pris isolément ou en combinaison, prévoient en outre que : [0020] - l'hyperviseur de type 1 est implémenté sous la forme d'un micrologiciel (Firmware) ; [0021] - la plateformc matérielle comprend un processeur exécutant un micrologiciel (Firmware), et l'hyperviseur de type 1 est intégré dans ledit micrologiciel de la plateforme matérielle ; [0022] le composant applicatif est compris dans la liste constituée de : [0023] - une application critique pour la sécurité informatique du système ; [0024] - une application de type SOTA (de l'anglais « Software Over-the-Air ») ou FOTA (de l'anglais « Firmware Over-the-Air ») ; [0025] - une application critique pour la sécurité du véhicule et/ou de ses passagers ; [0026] - une application de communication entre le véhicule et son environnement ; [0027] - une application gérant des appels d'urgence réglementés ; [0028] - une application gérant une passerelle provisionnelle ; [0029] - une application tierce ; et, [0030] - une application spécifique d'un OEM. [0031] Dans un deuxième aspect, l'invention concerne également un procédé de mise à jour d'un programme d'application capable de s'exécuter dans un composant applicatif d'une architecture selon le premier aspect ci-dessus, comprenant la propagation d'une requête de mise à jour du programme d'application vers le composant applicatif à travers l'hyperviseur de type 1. [0032] Un troisième et dernier aspect de l'invention se rapporte à un véhicule automobile comprenant une architecture de système télématique embarqué selon le premier aspect. Brève description des figures [0033] D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels : [0034] [fig.1] est un diagramme fonctionnel d'une architecture selon l'art antérieur ; [0035] [fig.2] est un diagramme fonctionnel d'une architecture selon des modes de réa- lisation ; et, [0036] [fig.1] est un schéma illustrant la mise à jour du programme d'utilisateur dans un composant applicatif de l'architecture de la figure 2. Description des modes de réalisation [0037] Dans la description de modes de réalisation qui va suivre et dans les Figures des dessins annexés, les mêmes éléments ou des éléments similaires portent les mêmes références numériques aux dessins. [0038] Dans la suite du présent exposé, les expressions suivantes sont utilisées en se référant à leur définition dans le domaine de l'informatique : [0039] - un Firmware est un micrologiciel (ou microcode, logiciel interne, logiciel embarqué ou encore microprogramme) c'est-à-dire un programme, qui est intégré dans un matériel d'un système électronique embarqué dans un véhicule (calculateur, disque dur, routeur, etc.) pour qu'il puisse fonctionner ; [0040] - un OS est un système d'exploitation (« Operating System » en anglais, comme Androidtm, LinuxiM, iOSTM, RTOS, etc. ; 100411 - une passerelle (« Gateway » en anglais) désigne un dispositif permettant de relier deux réseaux informatiques de types différents, par exemple un réseau local et un réseau internez: 100421 - un logiciel tiers (« Third party Application » en anglais) est un logiciel qui peut être ajouté à un autre logiciel, bien qu'il n'ait pas été développé par l'éditeur du logiciel auquel il est ajouté ; 100431 - un OEM (« Original Equipment Manufacturer » en anglais) est une entreprise qui fabrique des pièces détachées (c'est-à-dire un équipementier) ; 100441 - une machine virtuelle (ou VM, de l'anglais « Virtual Machine ») ; et, 100451 - un hyperviseur est une plate-forme de virtualisation qui permet à plusieurs systèmes d'exploitation de travailler en même temps sur une même machine physique ayant des ressources matérielles partagées. 100461 En informatique, le concept de virtualisation permet de disposer d'une couche d'abstraction au-dessus du matériel. Ainsi, l'environnement d'exécution des composants applicatifs d'un système complexe (ou logiciels d'application, ou applications, ou encore programmes d'utilisateur) peut être vu comme une machine virtuelle. En particulier, cela facilite sa maintenance par rapport à un environnement dépendant du matériel sous-jacent. [0047] En référence à la figure 1, une architecture de système télématique embarqué dans un véhicule automobile selon l'art antérieur comprend des composants applicatifs 11 à 18 déterminé, ayant chacun une couche matérielle HW1 à HW8, respectivement, sur laquelle s'exécute un système d'exploitation OS1 à 058, respectivement, sur lequel peut s'exécuter au moins un programme d'application AP1 à AP8, respectivement. [0048] La communication entre les différents composants applicatifs 11 à 18 est assurée par un medium de communication 10, par exemple un bus de communication. Cette communication pose des problèmes car les composants applicatifs n'ont pas le même Hardware. De plus, la mise en oeuvre des homologations, notamment lors des mises à jour du programme d'application d'un composant applicatif est longue, chère et fastidieuse, car il faut réhomologuer, un par un, tous les composants applicatifs impactés par le programme mis à jour. En outre, il n'y a pas de notion de ségrégation entre les composants applicatifs, cc qui induit des risques au niveau de la cybersécurité du système. [0049] Afin de pallier ces inconvénients, des modes de réalisation font appel au concept de la virtualisation. Dans le contexte des systèmes embarqués, un hyperviseur de virtualisation apporte principalement l'avantage de la sécurité. En effet, la virtualisation permet d'isoler les différents composants applicatifs d'un système embarqué. Plus spécifiquement, une faille de sécurité dans un espace applicatif y reste cloisonnée et ne peut donc pas affecter un autre espace applicatif ni, le cas échéant, le système d'exploitation temps réel (ou RTOS, mis pour « Real-Time Operating System » en anglais) qui peut être regardé comme un composant applicatif particulier et qui, généralement, gère des informations critiques en termes de sécurité. [0050] La virtualisation des systèmes embarqués doit toutefois prendre en compte certaines limites et spécificités par rapport aux systèmes de virtualisation traditionnelle. En effet, la plupart des systèmes embarqués ont des ressources limitées et disposent de contraintes de temps réel. Par conséquent, l'hyperviseur ne doit pas prendre une part trop importante dans le temps de calcul du (ou des) processeur(s), et la méthode de communication entre les différents composants à travers l'hyperviseur doit rester légère. [0051] En référence à la figure 2, il va maintenant être décrit une architecture de système té- lématique embarqué dans un véhicule automobile selon des modes de réalisation de l'invention. [0052] L'architecture comprend une plateforme matérielle 20 (« hardware platform » en anglais) sur laquelle s'exécute un hyperviseur 29, et plus particulièrement un hyperviseur de type 1 aussi appelé hyperviseur natif, ou encore « bare metal hypervisor » 6 en anglais ce qui signifie littéralement « hyperviseur métal nu ». Un tel hyperviseur s'installe directement sur la couche matérielle du système. Il prend directement le contrôle du matériel (machine physique correspondant à la plateforme matérielle 20) au démarrage du système. [0053] Des composants applicatifs, par exemple les composants 21 à 28 tels que représentés, sont implémentés en tant que machines virtuelles respectives, sur la pile Hardware. Dans un exemple non-limitatif, et afin d'illustrer des cas d'usage de l'invention : [0054] - le composant 21 peut être une application critique pour la sécurité informatique (« Cyber Security », en anglais) du système ; le composant 22 peut être une application de type SOTA (de « Software Over-the-Air ») ou FOTA (de l'anglais « Firmware Over-the-Air ») ; [0055] - le composant 23 peut être une application critique pour la sécurité (« Safcty ») du véhicule et/ou de ses passagers ; [0056] - le composant 24 peut être une application de type V2X, c'est-à-dire une application de communication entre le véhicule et son environnement ; [0057] - le composant 25 peut être une application gérant des appels d'urgence réglementés (ou E-Call, de l'anglais « Emergency Call ») ; [0058] - le composant 26 peut être une application gérant une passerelle provisionnelle (en anglais « Provisional Gateway ») ; [0059] - le composant 27 peut être une application tierce ; et, [0060] - le composant 28 peut être une application spécifique d'un OEM. [0061] Dans un mode de réalisation tout ou partie de ces composants peuvent être intégrés dans un seul boitier avec une pile Hardware commune et un hyperviseur faisant l'interface entre les composants et la plateforme matérielle. [0062] Dans un mode de réalisation, ces composants applicatifs sont regroupés dans un même boîtier physique qui contient les éléments de la plateforme matérielle 20. [0063] La plateforme matérielle 20 comprend par exemple de la mémoire (un ou plusieurs disques durs, un ou plusieurs disques optiques, des périphériques de type USB, etc.), au moins un processeur qui exécute un micrologiciel (« firmware » en anglais), un bus de communication, éventuellement des périphériques matériels, etc. Dans des modes de réalisation, la plateforme matérielle 20 est de type «baye metal ». Il s'agit d'un environnement à locataire unique (c'est-à-dire géré par un unique système d'exploitation) offrant un accès direct aux ressources matérielles sous-jacentes. Une telle platefonne matérielle se comporte comme un serveur dédié d'accès aux ressources matérielles et, avantageusement, prend en charge plusieurs types de systèmes d'exploitation, y compris les hyperviseurs. [0064] Ainsi, de manière avantageuse, l'hyperviseur de type 1 implémente une couche sup- plémentaire entre les machines virtuelles qui correspondent aux composants applicatifs 7 21-28, d'une part, et les ressources matérielles de la plateforme 20, d'autre part. Cela améliore la performance et la latence. Cela introduit par ailleurs de la ségrégation entre les composants applicatifs exécutés sur les machines virtuelles en procurant un isolement des machines virtuelles, ce qui est favorable à la cybersécurité du système. Enfin, cela est également favorable à l'évolutivité du système, puisque l'ajout d'un composant applicatif revient à la mise en place d'une nouvelle machine virtuelle, qui n'implique pas de devoir réhomologuer ou ré-certifier les autres composants applicatifs. [0065] Toutefois, contrairement à un hyperviseur de type 2, ou hyperviseur hébergé, qui exige un système d'exploitation pour être exécuté, un hyperviseur de type 1 comme l'hyperviseur 29 montré à la figure 2 est implémenté directement entre la(les) machine(s) virtuelle(s) 21-28 et la plateforme matérielle 20. Ainsi, l'hyperviscur 29 est un logiciel, ou système d'exploitation primaire, qui s'exécute directement sur la plateforme matérielle 20, et qui contrôle toutes les requêtes d'accès aux ressources matérielles de la plateforme matérielle 20. On parle de pile hardware commune, c'est-à-dire commune à tous les composants applicatifs, pour désigner la combinaison de r hyperviscur et de la plateforme matérielle commune sous-jacente. Les requêtes d'accès aux ressources matérielles dont il s'agit sont par exemple des requêtes d'accès à la mémoire, des transactions sur le bus de communication de la plateforme matérielle, des interruptions des processeurs, des requêtes d'accès aux périphériques matériels le cas échéant, etc. Cet hyperviseur de type 1 agit donc comme un gestionnaire de machines virtuelles qui est plus rapide, notamment pour l'implémentation des mises à jour des composants applicatifs qui s'exécutent sur les machines virtuelles 21 à 28. [0066] En d'autres termes, l'hyperviseur est une plate-forme de virtualisation ayant la fonction d'un gestionnaire de machines virtuelles, qui permet à plusieurs systèmes d'exploitation de travailler en même temps sur une même machine physique ayant des ressources matérielles partagées. Ainsi, les composants applicatifs 21 à 28 ayant chacun un système d'exploitation secondaire OSI à 0S8, respectivement, ou système d'exploitation « invité », peuvent être exécutés au-dessus de l'hyperviseur 29. Ces composants applicatifs 21 à 28 implémentent un logiciel d'application API à AP8, respectivement. Ces composants applicatifs peuvent accéder aux ressources matérielles de la plateforme 20 et/ou communiquer entre eux à travers l'hyperviseur 29. [0067] Des exemples d'hyperviseurs du marché, généralement utilisé dans les serveurs in- formatiques, mais parfois aussi dans les ordinateurs de bureau pour virtualiser certaines applications, sont VMware vSphereTM, Citrix XenServerTM, Microsoft Hyper-VTM (intégré à Windows ServerTM), ou encore Linux KVMTm. [0068] Dans des modes de réalisation, l'hyperviseur 29 peut être implémenté sous la forme 8 d'un micrologiciel (« Firmware ») exécuté sur la plateforme matérielle 20. [0069] Plus particulièrement, l'hyperviseur 29 peut être intégré dans le Firmware natif de la plateforme matérielle 20. Dans ce cas, r hyperviscur de type 1 est à la fois le système d'exploitation gérant la plateforme matérielle, et r hyperviscur. Cela est plus rapide et plus efficace, avec une isolation et une indépendance des composants applicatifs, car on n'exécute qu'une seule couche de plusieurs systèmes d'exploitation, via le Firmware natif de la plateforme matérielle 20. [0070] On notera que, ainsi qu'il est connu le Firmware de la plateforme matérielle (non re- présenté à la figure 2), implémente par ailleurs les fonctionnalités suivantes, parmi d'autres : [0071] - une gestion de la mémoire de la plateforme matérielle 20 ; [0072] - une gestion des interruptions pour les processeurs de la plateforme matérielle 20 ; [0073] - une gestion de l'horloge et des timers utilisés pour cadencer les accès au bus de communication de la plateforme matérielle 20. [0074] L'homme du métier appréciera qu'il est possible de modifier le Firmware par l'installation de mises à jour afin de profiter d'améliorations ou de corrections de bug. A cet effet, le Firmware peut résider dans certains types de mémoires ROM (de l'anglais « Rcad-only Memory ») de la plateforme matérielle 20, qui sont reprogrammahles. Il peut s'agir, par exemple d'EEPROM (de l'anglais « Electrically Erasahle ROM ») ou plus généralement de mémoires flash (c'est-à-dire des EEPROM rapides). [0075] En référence à la figure 3, des requêtes de mise à jour d'un programme d'application API (pour i compris entre 1 et 8, en référence à l'architecture montrée à la figure 2) capable d'être exécuté dans une ou plusieurs des machines virtuelles 21 à 28, peuvent avantageusement être effectuées à partir de la plateforme matérielle 20 du système. Elles sont alors propagées vers le composant applicatif 2i concerné par l'intermédiaire de la pile hardware commune comprenant la plateforme matérielle 20 et l'hyperviseur 29 de type 1. [0076] Ce processus de mise à jour est illustré à la figure 3 par la flèche épaisse 30, qui symbolise le cheminement d'une requête Update_APi de mise à jour du programme applicatif APi d'un composant applicatif déterminé 2i. Une telle requête peut provenir de l'exécution par l'hyperviseur 29 d'un fichier exécutable lu sur un périphérique connecté à la plateforme matérielle 20 pour les besoins de cette mise à jour. Un tel périphérique peut par exemple être une clé USB, une valise de diagnostic, etc. [0077] L'avantage procuré par l'architecture en partie virtualisée du système conforme aux modes de réalisation est que, grâce à l'isolation permise par la virtualisation des composants applicatifs du système, on évite la nécessité d'un processus de recertification pour tous les autres composants applicatifs 2j (avec j compris entre 1 et 8 9 en référence encore à l'architecture montrée à la figure 2, et en outre avec j différent de i) qui partagent des données avec, et/ou qui utilisent tout ou partie du logiciel APi mis à jour dans l'applicatif 2i. [0078] Dit autrement, grâce à l'invention il est plus facile et avec une moindre incidence sur la rentabilité, de ré-certifier fréquemment des composants applicatifs isolés tels que les composants critiques pour la sécurité, réglementaires et autres, sans affecter les autres composants et les piles de logiciels. [0079] Un autre avantage concerne la sécurité, car un bloc de composants applicatifs dédiés qui est conçu pour des mises à jour isolées permet d'être plus sécurisé par rapport à une pile de conteneurs (Hardware et Software) monolithiques comme dans le cas de l'architecture de la figure 1. [0080] L'allocation de ressources à la demande et la gestion qui sont permises par la virtua- lisation des composants applicatifs sont, en outre, mieux adaptées à chaque composant applicatif en fonction par exemple d'un niveau de priorité. Cela permet in fine aux performances globales du système de répondre aux meilleurs indicateurs de performance clés qui lui sont destinés. [0081] Par ailleurs, la performance de chaque composant applicatif a un gain significatif et est plus stable par rapport à l'art antérieur, ce qui garantit la fiabilité des composants individuels et du système dans son ensemble. [0082] Enfin, l'architecture proposée est simple et évolutive, car elle permet d'ajouter fa- cilement de nouveaux composants applicatifs, lorsque de nouveaux cas d'utilisation et/ ou de nouvelles applications à héberger apparaissent. [0083] La présente invention a été décrite et illustrée dans la présente description détaillée et dans les figures des dessins annexés, dans des formes de réalisation possibles. La présente invention ne se limite pas, toutefois, aux formes de réalisation présentées. D'autres variantes et modes de réalisation peuvent être déduits et mis en oeuvre par la personne du métier à la lecture de la présente description et des dessins annexés. [0084] Dans le présent exposé, le terme "comprendre" ou "comporter" n'exclut pas d'autres éléments ou d'autres étapes. Un seul processeur ou plusieurs autres unités peuvent être utilisées pour mettre en oeuvre l'invention. Les différentes caractéristiques présentées peuvent être avantageusement combinées. Leur présence dans des parties différentes, n'excluent pas cette possibilité. Les signes de référence ne sauraient être compris comme limitant la portée de l'invention. 10 REVENDICATIONS[Revendication 1] Architecture de système télématique embarqué dans un véhicule au- tomobile, comprenant : - une pluralité de composants applicatif (21-28) ; - une plateforme matérielle (20) commune aux composants applicatifs ; - un hyperviseur de type 1 (29) s'exécutant sur la plateforme matérielle, pour contrôler l'accès aux ressources matérielles de la plateforme matérielle par les composants applicatifs en tant que machines virtuelles, l'architecture comprenant en outre des moyens pour propager une requête (Update_APi) de mise à jour d'un programme d'application (APi) capable de s'exécuter dans un composant applicatif (2i) déterminé, vers ledit composant applicatif à travers l'hyperviseur de type 1. [Revendication 2] Architecture selon la revendication 1, dans laquelle l'hyperviseur de type 1 est implémenté sous la forme d'un micrologiciel. [Revendication 3] Architecture selon la revendication 1 ou la revendication 2, dans laquelle la plateforme matérielle comprend un processeur exécutant un micrologiciel de gestion des ressources matérielles de la plateforme matérielle, et dans laquelle fhyperviseur est intégré dans ledit micro-logiciel. [Revendication 4] Architecture selon rune quelconque des revendications 1 à 3, dans laquelle le composant applicatif est compris dans la liste constituée de : - une application critique pour la sécurité informatique du système ; - une application de type SOTA (de l'anglais « Software Overthe-Air ») ou FOTA (de l'anglais « Firmware Over-the-Air ») ; - une application critique pour la sécurité du véhicule et/ou de ses passagers ; - une application de communication entre le véhicule et son envi- ronnement ; - une application gérant des appels (l'urgence réglementés ; - une application gérant une passerelle provisionnelle; - une application tierce ; et., - une application spécifique d'un OEM. [Revendication 5] 5. Procédé de mise à jour d'un programme d'application capable de s'exécuter dans un composant applicatif d'une architecture selon l'une quelconque des revendications 1 à 4, comprenant la propagation d'une requête de mise à jour du programme d'application vers le composant 11 applicatif à travers l'hyperviseur de type 1. [Revendication 6] 6. Véhicule automobile comprenant une architecture de système té- lématique selon l'une quelconque des revendications 1 à 4.