Brevet FR3150609A1 — publié le 20250103

Système embarqué hybride pour véhicules routiers, procédé et programme correspondant La présente invention concerne un système informatisé embarqué (SiE) au sein d’un véhicule routier, qui comprend un dispositif électronique embarqué (D1) comprenant un processeur (Px), une mémoire vive (Mem) de taille prédéfinie et une mémoire de masse (MS) au sein de laquelle est enregistrée une image logicielle (IMG) pour l’exécution d’un système d’exploitation automobile et d’applications. Le système d’exploitation automobile est compilé selon une première architecture et les applications sont divisées en deux groupes, un premier groupe d’applications compilées et optimisées pour un fonctionnement selon ladite première architecture et un deuxième groupe d’applications compilées et optimisées pour un fonctionnement selon une deuxième architecture distincte de la première architecture, ladite image logicielle (IMG) ayant été construite pour tenir compte de ressources d’exécution disponibles dudit dispositif électronique embarqué (D1). Figure pour l'abrégé : Figure 1 Système embarqué hybride pour véhicules routiers, procédé et programme correspondant Domaine L’invention se rapporte aux systèmes informatiques embarqués pour véhicule routiers. L’invention se rapporte plus particulièrement à un dispositif électronique embarqué pour véhicule routier qui supporte l’exécution d’applications associées à des architectures de processeur différentes, par exemple des applications 32bits et 64bits, ou autre typologie de double architecture, par l’intermédiaire d’un système d’exploitation automobile hybride. L’invention se rapporte plus particulièrement à un tel dispositif et à un tel système d’exploitation qui fonctionne dans un environnement matériel contraint. Art Antérieur Avec les progrès technologiques, les véhicules routiers comprennent de nombreuses fonctionnalités qui sont gérées par l’intermédiaire d’un système informatisé. Ces systèmes informatisés pour véhicules routiers sont des ordinateurs, également appelés unités de contrôle électronique (ECU), qui exécutent un système d’exploitation. Un système d'exploitation automobile est une plateforme logicielle spécialisée qui fournit une base pour la gestion et la coordination de diverses fonctions et sous-systèmes dans un environnement automobile moderne. Un système d'exploitation automobile offre ainsi des capacités en temps réel, une fiabilité et une intégration avec les composants matériels et les réseaux de véhicules. Ces systèmes d’exploitation automobiles sont ainsi conçus pour gérer des tâches en temps réel, où les opérations critiques doivent être effectuées dans des délais précis. Cela est crucial pour des fonctions telles que le contrôle du moteur, le freinage antiblocage, le contrôle de la stabilité et d'autres systèmes critiques pour la sécurité. Par ailleurs, le système d'exploitation automobile facilite la communication et la coordination entre les différents calculateurs du véhicule. Il permet un échange de données transparent et la coordination des fonctionnalités entre différents systèmes, notamment le groupe motopropulseur, le châssis, les systèmes d'infodivertissement et les systèmes d'aide à la conduite. Il gère également l'interaction avec divers dispositifs et capteurs dans le véhicule, tels que les capteurs du moteur, les caméras, les radars, les lidars et d'autres dispositifs d'entrée/sortie. Il fournit des interfaces et des protocoles normalisés pour la communication et l'échange de données avec ces composants. Pour mettre en œuvre ces fonctionnalités, le système d'exploitation automobile gère l'allocation de la mémoire et des ressources (notamment de calcul) disponibles afin d'assurer une utilisation efficace des ressources informatiques. Le système est donc en charge de la hiérarchisation et de la planification des tâches, gère l'allocation de la mémoire pour les différentes applications et gère les ressources du système telles que l'utilisation du processeur, la bande passante du réseau et l'espace de stockage. Parmi les systèmes d'exploitation automobiles, on peut citer QNX Neutrino, AUTOSAR (de l’anglais pour « AUTomotive Open System Architecture » ), Android Automotive OS et des plateformes basées sur Linux comme Automotive Grade Linux (AGL) et GENIVI. Les systèmes informatiques automobiles, sur lesquels fonctionnent les systèmes d’exploitation automobile, sont construits soit en utilisant une architecture 32bits pour optimiser la consommation de mémoire et de stockage, soit en utilisant une architecture 64bits pour optimiser les performances. Une telle dichotomie présente le désavantage de ne pas s’adapter à l’évolution des applications et des programmes informatiques qui sont exécutés par les systèmes d'exploitation automobiles. Cette dichotomie présente le désavantage de ne pas prendre en considération certains facteurs économiques liés à l’utilisation d’une architecture plutôt qu’une autre, notamment le prix de la plateforme informatique utilisée pour le fonctionnement des systèmes d'exploitation automobiles et des applications et programmes qu’il embarque. Cette dichotomie présente encore le désavantage de ne pas offrir de plateforme qui soit correctement dimensionnée en fonction des besoins. Aucune solution n'a été proposée pour concevoir un système automobile qui trouve automatiquement le meilleur compromis pour chaque composant logiciel et leurs dépendances. Résumé L’invention a été conçue pour résoudre cette problématique de consommation de ressources qui est posée par les systèmes de l’art antérieur. A cet effet, l’invention a pour objet un système informatisé embarqué au sein d’un véhicule routier, le système comprenant un dispositif électronique embarqué comprenant un processeur, une mémoire vive de taille prédéfinie, et une mémoire de masse au sein de laquelle est enregistrée une image logicielle pour l’exécution d’un système d’exploitation automobile et d’applications. Selon l’invention, ce système d’exploitation automobile est compilé selon une première architecture et les applications sont divisées en deux groupes, un premier groupe d’applications compilées et optimisées pour un fonctionnement selon ladite première architecture et un deuxième groupe d’applications compilées et optimisées pour un fonctionnement selon une deuxième architecture distincte de la première architecture, ladite image logicielle ayant été construite pour tenir compte de ressources d’exécution disponibles du dispositif électronique embarqué. Selon une caractéristique particulière, ladite image est construite en mettant en œuvre un dispositif de création d'une image logicielle d'un système d'exploitation automobile comprenant : un module d'obtention, à partir d’un fichier de configuration, d’un ensemble d’applications à installer dans le système d’exploitation automobile; un module de détermination, à partir de l’ensemble d’applications à installer, du premier groupe d’applications pour lesquelles la performance est une condition impérative d’exécution ; un module de détermination, à partir de l’ensemble d’applications à installer, du deuxième groupe d’applications pour lesquelles l’économie de ressources est une condition acceptable d’exécution, le deuxième groupe étant distinct du premier groupe ; un module de configuration des applications du premier groupe d’applications selon la première architecture de compilation, identique à une architecture du système d’exploitation automobile, délivrant un premier groupe d’applications configurées ; un module de configuration des applications du deuxième groupe d’applications selon la deuxième architecture de compilation, délivrant un deuxième groupe d’applications configurées ; un module de création de l’image logicielle comprenant le système d’exploitation automobile, lesdites applications configurées du premier groupe et les applications configurées du deuxième groupe. Selon une caractéristique particulière, le module de détermination du premier groupe d'applications met en œuvre une sélection basée sur un premier indicateur prédéfini associé à au moins une application de l’ensemble d’applications à installer et/ou le module de détermination du deuxième groupe d’applications met en œuvre une sélection basée sur un deuxième indicateur prédéfini de ressources associé à au moins une application de l’ensemble d’applications à installer, le deuxième indicateur étant distinct du premier indicateur. Selon une caractéristique particulière, le module de détermination du premier groupe d’applications et le module de détermination du deuxième groupe d’applications mettent en œuvre un module de mesure des ressources utilisées par au moins une application de l’ensemble d’applications à installer, lesdites ressources appartenant au groupe comprenant la quantité de mémoire utilisée, le nombre de cœur(s) de processeur utilisé(s) et la quantité de mémoire disponible. Selon une caractéristique particulière, le module de détermination du premier groupe d’applications et le module de détermination du deuxième groupe d’applications mettent en œuvre un module de résolution d’un arbre de dépendance des composants logiciels utilisés par au moins une application de l’ensemble d’applications à installer. Selon une caractéristique particulière, le module de détermination du deuxième groupe d’applications détermine que lorsqu’une application courante, assignable au deuxième groupe, comprend une dépendance logicielle compilée selon la première architecture, elle est déplacée vers le premier groupe. Selon une caractéristique particulière, le module de détermination du deuxième groupe d’applications met en œuvre des moyens de détermination d’une transférabilité, vers le premier groupe, d’une application courante, assignable au deuxième groupe, en fonction d’une stratégie d’assignation de ressources du système informatisé embarqué. Selon un autre aspect, l’invention se rapporte également à un procédé de création d’une image logicielle d’un système d’exploitation automobile et d’applications, le procédé étant mis en œuvre par un dispositif électronique de création de l’image logicielle du système d'exploitation automobile. Selon l’invention, le système d’exploitation est compilé selon une première architecture et les applications sont divisées en deux groupes, un premier groupe d’applications compilées et optimisées pour un fonctionnement selon ladite première architecture et un deuxième groupe d’applications compilées et optimisées pour un fonctionnement selon une deuxième architecture distincte de la première architecture, ladite image logicielle ayant été construite pour tenir compte de ressources d’exécution disponibles d’un dispositif électronique embarqué comprenant un processeur et une mémoire vive de taille prédéfinie, une mémoire de masse au sein de laquelle est enregistrée ladite image logicielle, le dispositif électronique étant compris dans un système informatisé embarqué au sein d’un véhicule routier. Selon une caractéristique particulière, le procédé de création d’une image logicielle comprend les étapes suivantes : obtention, à partir d’un fichier de configuration, d’un ensemble d’applications à installer dans le système d’exploitation automobile ; une première détermination, à partir de l’ensemble d’applications à installer, du premier groupe d’applications pour lesquelles la performance est une condition impérative d’exécution ; une deuxième détermination, à partir de l’ensemble d’applications à installer, du deuxième groupe d’applications pour lesquelles l’économie de ressources est une condition acceptable d’exécution, le deuxième groupe étant distinct du premier groupe ; une première configuration des applications du premier groupe d’applications selon une première architecture de compilation identique à une architecture du système d’exploitation automobile, délivrant un premier groupe d’applications configurées ; une deuxième configuration des applications du deuxième groupe d’applications selon la deuxième architecture de compilation distincte de la première architecture, délivrant un deuxième groupe d’applications configurées ; création de l’image logicielle comprenant le système d’exploitation automobile, lesdites applications configurées du premier groupe et les applications configurées du deuxième groupe. Selon un autre aspect, l’invention se rapporte également à un programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un dispositif électronique programmable, mettent en œuvre un procédé création d’une image logicielle tel que défini ci-dessus. Brève description des figures L’invention apparaîtra plus clairement à la lecture de la description qui va suivre, donnée uniquement à titre d’exemple non limitatif, et faite en référence aux dessins dans lesquels : illustre un système informatisé embarqué pour l’exécution d’un système d’exploitation automobile selon l’invention ; illustre un dispositif électronique de création d’une image logicielle d’un système d’exploitation automobile ; explicite les différentes étapes du procédé de création d’une image logicielle d’un système d’exploitation automobile. Description d’un mode de réalisation Comme indiqué précédemment, l’invention porte sur un dispositif électronique embarqué pour véhicule routier qui supporte l’exécution optimisée d’applications selon une première architecture (par exemple 64bits) et supporte l’exécution optimisée d’applications selon une deuxième architecture (par exemple 32bits) grâce à un système d’exploitation automobile adapté. Plus particulièrement, les inventeurs ont conçu un système d’exploitation automobile s’exécutant sur la première architecture matérielle, le système d’exploitation automobile comprenant des moyens d’exécution d’applications selon la deuxième architecture. La répartition des applications en fonction de l’architecture est effectuée lors de la création d’une image logicielle du système d’exploitation automobile et des applications qu’il contient, en fonction de contraintes provenant du dispositif électronique embarqué et de la plateforme matérielle qui lui est associée. En relation avec la , le dispositif électronique embarqué D1 pour véhicule routier est intégré au sein d’un système informatisé embarqué SiE, se présentant sous la forme d’une plateforme matérielle. Le dispositif électronique embarqué comprend un processeur Px et de la mémoire vive Mem. Le processeur est par exemple un processeur multicoeurs, basé sur la première architecture. La mémoire Mem attachée à ce processeur est d’une taille prédéterminée. Ces paramètres (type de processeur, nombre de cœurs, taille de mémoire prédéterminée) sont des spécifications imposées par le constructeur du véhicule automobile, en fonction notamment de contraintes économiques. Le dispositif électronique D1 comprend également une mémoire de masse MS au sien de laquelle une image logicielle IMG du système d’exploitation automobile et des applications est enregistré. Tout ou partie des applications contenues dans cette image logicielle IMG est chargé en mémoire au démarrage du véhicule. La plateforme matérielle, au sein de laquelle le dispositif électronique est intégré, comprend quant à elle un ensemble de composants CMP (par exemple réseau), de capteurs SENS (caméras, capteurs des différents sous-systèmes du véhicule, p.ex. capteur d’oxygène des gaz d’échappement, capteur de vitesse, capteur de pression des pneus, capteurs de température, capteur de luminosité, capteur de collision, capteur d’airbag, capteurs de caméra, capteur de navigation, etc.), d’actionneurs ACTN, pour la gestion et la coordination de diverses fonctions et sous-systèmes du véhicule (par exemple guidage, freinage d’urgence, antiblocage de frein, état du moteur, etc.). Sur le dispositif électronique embarqué D1, le système d’exploitation automobile fonctionne en mode natif, à savoir selon la première architecture. Les applications s'exécutant sur le système d’exploitation automobile, telles que les applications pour lesquelles la performance d’exécution est le facteur déterminant, sont des applications fonctionnant nativement selon la première architecture. Le processeur du dispositif électronique fonctionne selon la première architecture lors de l'exécution d'une application selon la première architecture. Le processeur du dispositif électronique embarqué fonctionne en mode de compatibilité lors de l'exécution d'une application selon la deuxième architecture. Ce mode de compatibilité est géré par le système d’exploitation automobile. Un objet de l’invention est de minimiser, autant que faire se peut, les caractéristiques du dispositif électronique embarqué (processeur, nombre de cœurs, quantité de mémoire) tout en assurant l’exécution de l’ensemble des applications dans des conditions optimales, notamment de sécurité. En d’autre termes l’objet de l’invention est de permettre l’exécution d’un maximum d’applications dans un environnement d’exécution contraint (nombre de processeurs, quantité de mémoire). Ainsi, une stratégie globale d’allocation des ressources d’exécution des applications est définie, dans laquelle par exemple, le nombre d’applications associées à un profil de performance maximum (i.e. les applications fonctionnant selon la première architecture) est limité et dans laquelle on favorise l’utilisation d’application peu gourmandes en ressources (i.e. les applications fonctionnant selon la deuxième architecture). L’invention se rapporte également à une méthode de construction de l’image logicielle IMG du système d'exploitation automobile dans laquelle chaque application est configurée et optimisée pour fonctionner selon la première architecture ou selon la deuxième architecture. On rappelle qu’une image logicielle d'un système d'exploitation est un fichier binaire qui représente une version spécifique d'un système d'exploitation prêt à être installé sur un ordinateur ou un autre appareil. L'image logicielle du système d'exploitation automobile contient tous les fichiers, les configurations et les programmes nécessaires pour exécuter le système d'exploitation automobile sur le dispositif électronique embarqué. Dans le cadre de l’invention, une telle image logicielle comprend également un ensemble d’applications, chaque application de cet ensemble d’applications étant configurée pour fonctionner soit selon la première architecture, soit selon la deuxième architecture. Selon l’invention par ailleurs, une telle image logicielle est construite pour s’adapter aux ressources du dispositif électronique embarqué cible et à la plateforme cible qui l’accueille. La décrit un dispositif électronique D2 de création de l’image logicielle d’un système d’exploitation automobile. Ce dispositif D2 peut être mis en œuvre dans une phase de préparation d’une ou de plusieurs images logicielles à installer dans des véhicules routiers de différents types, avec des configurations matérielles différentes. Dans l’exemple de la , le dispositif électronique D2 de création de l’image logicielle IMG d’un système d’exploitation automobile comprend une unité de mémoire électronique 16, au moins un processeur de calcul 18 et une interface 80 de communication avec des dispositifs distants, par un protocole de communication choisi, par exemple un protocole filaire et/ou un protocole de communication radio. Les éléments du dispositif D2 sont adaptés à communiquer via un bus de communication 15. Dans l’exemple de la , le dispositif de création D2 comprend un module d'obtention 20 d’une liste d'applications à installer dans le système d'exploitation automobile, un module de détermination 25 d’un premier groupe d'applications GpA1, illustré dans la , pour lesquelles la performance est une condition impérative d'exécution, un module de détermination 30 d’un deuxième groupe d'applications GpA2, illustré dans la , pour lesquelles l'économie de ressources d’exécution est une condition acceptable d'exécution, un module de configuration 35 des applications du premier groupe selon la première architecture de configuration, identique à l'architecture de configuration du système d'exploitation automobile, un module de deuxième configuration 40 des applications du deuxième groupe selon la deuxième architecture, différente de l'architecture de compilation du système d'exploitation automobile, et un module de création 45 configuré pour assembler le système d'exploitation automobile et les applications du premier et du deuxième groupe pour former l'image logicielle IMG. Ces modules sont réalisés chacun sous forme d’un logiciel, ou d’une brique logicielle, exécutable par le processeur. La mémoire du dispositif électronique D2 est alors apte à stocker les logiciels correspondants aux modules précités. Le processeur est alors apte à exécuter chacun de ces logiciels. En variante non représentée, ces modules sont réalisés chacun sous forme d’un composant logique programmable, tel qu’un FPGA (de l’anglais « Field Programmable Gate Array »), ou encore d’un circuit intégré, tel qu’un ASIC (de l’anglais « Application Specific Integrated Circuit »). Lorsque le dispositif de création D2 est réalisé sous forme d’un ou plusieurs logiciels, c’est-à-dire sous forme d’un programme d’ordinateur, également appelé produit programme d’ordinateur, il est en outre apte à être enregistré sur un support, non représenté, lisible par ordinateur. Le support lisible par ordinateur est par exemple un medium apte à mémoriser des instructions électroniques et à être couplé à un bus d’un système informatique. A titre d’exemple, le support lisible est un disque optique, un disque magnéto-optique, une mémoire ROM, une mémoire RAM, tout type de mémoire non-volatile (par exemple FLASH ou NVRAM) ou une carte magnétique. Sur le support lisible est alors mémorisé un programme d’ordinateur comprenant des instructions logicielles. En résumé, ce dispositif électronique D2 permet d'obtenir un ensemble d'applications à partir d'un fichier de configuration, de déterminer des groupes d'applications en fonction de leurs exigences de performance et d'économie de ressources, de configurer les applications selon différentes architectures, et de créer l’image logicielle comprenant le système d'exploitation automobile et les applications configurées. Le procédé de création de l’image logicielle du système d’exploitation automobile SEA est décrit en relation avec la et elle comprend les étapes suivantes : obtention 01, à partir d’un fichier de configuration FCnf, d’un ensemble d’applications EnsApp à installer dans le système d’exploitation automobile ; une première détermination 02, à partir dudit ensemble d’applications à installer EnsApp, d’un premier groupe d’applications GpA1 pour lesquelles la performance est une condition impérative d’exécution ; une deuxième détermination 03, à partir dudit ensemble d’applications à installer, d’un deuxième groupe d’applications GpA2 pour lesquelles l’économie de ressources est une condition acceptable d’exécution ; une première configuration 04 des applications du premier groupe d’applications GpA1 selon la première architecture de compilation, identique à une architecture de compilation du système d’exploitation automobile (p.ex. architecture 64bits), délivrant un premier groupe d’applications configurées ImgA1 ; une deuxième configuration 05 des applications du deuxième groupe d’applications GpA2 selon la deuxième architecture de compilation, différente de l’architecture de compilation du système d’exploitation automobile (p.ex. architecture 32bits), délivrant un deuxième groupe d’applications configurées ImgA2 ; création 06 de l’image logicielle IMG comprenant le système d’exploitation automobile SEA, lesdites applications configurées ImgA1 du premier groupe GpA1 et les applications configurées ImgA2 dudit deuxième groupe GpA2. Selon l’invention, la première étape de détermination 02 comprend une étape d’évaluation, en fonction d’un fichier de spécification d’applications, pour chaque application de l’ensemble d’applications, d’une condition d’exécution d’application. Ainsi, selon l’invention, dans l’ensemble d’applications qui doivent être installées (et fournies) avec le système d’exploitation automobile, au moins certaines d’entre elles (les applications sensibles, pour lesquelles un niveau de performance d’exécution est attendu) disposent d’un premier indicateur, qui précise les conditions d’exécution de cette application. Le premier indicateur est par exemple prédéfini et de type booléen (« vrai » signifiant « performance impérative », « faux » signifiant « performance non impérative » et l’absence de valorisation (ou l’absence de l’indicateur) signifiant « inconnu/non spécifié »). Pour chaque application concernée, un premier indicateur respectif est typiquement contenu dans le fichier de spécification d’applications. D’autres formalisations du premier indicateur peuvent bien entendu être mises en œuvre en fonction des besoins. La première étape de détermination consiste par exemple à placer, dans le premier groupe, les applications de l’ensemble d’applications pour lesquelles la valeur du premier indicateur précise que la condition d’exécution est la performance. Pour chaque application placée dans le premier groupe, optionnellement, la quantité prévisible de ressources d’exécution attribuée/associée à cette application est adjointe dans une structure de données, par exemple sous la forme d’un triplet de données {identifiant d’application/mémoire vive/nombre de processeurs}. Optionnellement, des valeurs de ressources restantes peuvent être diminuées en fonction des valeurs attribuées à chaque application placée dans le premier groupe. A l’issue du placement de ces applications dans le premier groupe, une quantité prévue de ressources consommée peut être prédite, lorsque le comptage de ces ressources est effectué au fur et à mesure du placement des applications dans le premier groupe GpA1. Selon l’invention, la deuxième étape de détermination 03 comprend une étape d’évaluation, en fonction du fichier de spécification d’applications, de la même condition d’exécution d’application. Dans un exemple de réalisation, toutes les applications de l’ensemble d’applications qui ne font pas partie du premier groupe d’applications GpA1 sont placées dans le deuxième groupe d’applications GpA2. Dans un deuxième exemple de réalisation, seules les applications dont un deuxième indicateur est valorisé pour indiquer une économie de ressources sont placées dans ce deuxième groupe d’applications GpA2. Ainsi, dans ce deuxième exemple de réalisation, le deuxième indicateur, complémentaire du premier indicateur exemplifié précédemment, est par exemple présent dans le fichier de spécification d’applications. En fonction des modalités de réalisation, à l’issue de l’exécution des deux étapes de détermination, les applications de la liste d’applications sont placées soit dans le premier groupe GpA1, soit dans le deuxième groupe GpA2. Des applications peuvent ne pas être placées dans l’un ou l’autre de ces deux groupes, par exemple lorsqu’elles n’ont pas de premier indicateur (relatif à la première architecture, par exemple relatif à la performance) et lorsqu’elles n’ont pas de deuxième indicateur (relatif à la deuxième architecture, par exemple relatif à l’économie de ressources) ou dans d’autres circonstances. Auquel cas, il est nécessaire de déterminer à quel groupe associer ces applications. Une première méthode d’association consiste par exemple à affecter, sans plus de considération, l’ensemble des applications n’ayant aucun indicateur dans le deuxième groupe GpA2. L’avantage de cette affectation est qu’elle permet d’assurer que les ressources de la plateforme d’exécution du système d’exploitation automobile seront encore plus économisées. Le désavantage est que potentiellement, une application orientée performance peut se trouver dans le deuxième groupe, alors qu’elle ne devrait pas y être. Une deuxième méthode d’association consiste par exemple à déterminer quels sont les composants matériels additionnels de la plateforme auxquels chaque application accède. Plus particulièrement, dans cette deuxième méthode, le dispositif électronique D2 se base sur les entrées sorties de l’application pour déterminer son groupe d’affectation. Pour mettre en œuvre cette deuxième méthode d’association, le dispositif électronique D2 utilise, pour une plateforme matérielle cible (processeur, quantité de mémoire disponible), non seulement des caractéristiques du processeur du dispositif électronique embarqué mais également des différents composants (caméras, capteurs, actionneurs) qu’elle embarque. La décision de classement d’une application courante dans le premier groupe d’applications (s’exécutant nativement dans la première architecture) ou dans le deuxième groupe, consiste par exemple à effectuer un ou plusieurs tests fonctionnels d’une instance de cette application courante. Ces tests fonctionnels sont par exemple conduits dans un environnement virtualisé. Ils permettent de déterminer quels sont les composants (capteurs, actionneurs, etc.) de la plateforme auxquels l’application courante accède. En fonction des composants accédés et de la fréquence de ces accès, l’application peut ainsi être placée dans le premier ou dans le deuxième groupe. Par exemple, les applications qui accèdent à des capteurs se rapportant à la sécurité du véhicule (pression de pneus, température moteur, frein, vitesse, par exemple) sont considérées comme prioritaires et donc placées dans le premier groupe tandis que les applications qui n’accèdent qu’à des capteurs considérés comme non essentiels au fonctionnement et à la sécurité du véhicule (p.ex. capteur de position, audio, caméra, climatisation, etc.) sont placées dans le deuxième groupe. A chaque fois qu’une application est placée dans le premier groupe GpA1, ou dans le deuxième groupe GpA2, optionnellement, la quantité prévisible (ou mesurée, si par exemple le dispositif électronique D2 a utilisé un environnement virtualisé pour tester les applications, ou bien en fonction de tout autre moyens d’obtention) de ressources d’exécution attribuée/associée à cette application est adjointe dans une structure de données, par exemple sous la forme d’un triplet de données {identifiant d’application/mémoire vive/nombre de processeurs}. Optionnellement, des valeurs de ressources restantes peuvent être diminuées en fonction des valeurs attribuées à chaque application placée dans le premier groupe GpA1. On peut noter que cette deuxième méthode d’association peut tout à fait être utilisée comme seule et unique méthode d’association : elle peut être utilisée en lieu et place de tout ou partie des indicateurs précédemment mentionnés, pour déterminer automatiquement le groupe dans lequel une application doit être placée. Optionnellement ou alternativement, les indicateurs précédemment mentionnés peuvent être issus d’une exécution préalable, par exemple dans un environnement virtualisé tel que présenté précédemment, de l’ensemble de ces applications, pour, précisément, valoriser ces indicateurs par anticipation. En d’autres termes, l’association d’une application de l’ensemble d’applications à l’un ou l’autre du premier ou du deuxième groupe peut être mise en œuvre lors d’une étape de mesure des ressources utilisées par tout ou partie des applications de l’ensemble d’applications, lors de la première et/ou de la deuxième étape de détermination et/ou lors d’une étape préalable d’association d’un indicateur de détermination des conditions d’exécution des applications de l’ensemble d’applications, tels que ceux présentés précédemment. Les applications du premier groupe sont configurées dans la même architecture de compilation que celle du système d’exploitation automobile, à savoir la première architecture. Par exemple, si le système d’exploitation automobile est basé sur une architecture 64bits, les applications du premier groupe sont configurées en architecture 64bits. Cette étape de configuration garantit que les applications du premier groupe bénéficieront des performances les plus élevées, compte tenu de leur compatibilité directe avec les bibliothèques natives du système d’exploitation. Plus particulièrement, lors de l’étape de configuration des applications du premier groupe (ou préalablement à cette étape de configuration, en fonction de la mise en œuvre, par exemple dans un environnement virtualisé tel que décrit précédemment), le dispositif électronique D2 procède à une résolution de l'arbre de dépendance des composants de ces applications (il peut s’agir de paquets et/ou de bibliothèques logicielles). Cette résolution est effectuée par l’intermédiaire d’un gestionnaire de composants auquel le dispositif électronique D2 a accès, et qu’il pilote. Selon l’invention, la mise en œuvre de la résolution de l’arbre de dépendance des applications comprend les étapes suivantes : analyse des dépendances : le gestionnaire de composants analyse les métadonnées des composants logiciels des applications du premier groupe pour identifier les dépendances requises par chaque composant logiciel des applications appartenant à ce premier groupe : ces métadonnées sont stockées dans des fichiers de configuration ou des emplacements spécifiques à chaque composant ; construction de l'arbre de dépendance : à partir des informations recueillies, un arbre de dépendance est construit, chaque nœud de l'arbre représentant un composant, et les dépendances étant représentées par des liens entre les nœuds ; cette construction est effectuée itérativement ; vérification de la disponibilité des composants : avant de procéder à une compilation dans l’architecture souhaitée, le gestionnaire de composants vérifie la disponibilité des composants précompilés dans des dépôts ou des sources de logiciels configurés : cela garantit que les composants nécessaires sont accessibles et peuvent être téléchargés, sans qu’il soit nécessaire de procéder à leur compilation dans l’architecture souhaitée : lorsque le composant est déjà compilé dans l’architecture cible et que sa version convient, le composant n’est pas recompilé ; lorsque le composant n’est pas compilé dans l’architecture cible ou que sa version ne convient pas, le composant sera recompilé ; résolution des conflits de dépendances : lorsqu'il existe des conflits de dépendances, c'est-à-dire lorsque deux composants nécessitent des versions incompatibles d'une même dépendance, le gestionnaire de composants résout ces conflits en recherchant des versions alternatives compatibles et/ou en sélectionnant des mises à jour de composants existants lorsque de telles mises à jour existent ; détermination de l'ordre de compilation et/ou d'installation : une fois que l'arbre de dépendance est construit et que les conflits sont résolus (éventuellement de manière itérative), le gestionnaire de composants détermine l'ordre dans lequel les composants doivent être compilés et installés (ou directement installés s’ils sont déjà compilés dans une version correcte pour l’architecture cible) pour satisfaire toutes les dépendances ; compilation et installation des composants : une fois que toutes les dépendances ont été résolues, le gestionnaire de composants procède à la compilation (lorsque nécessaire) et à l'installation des composants dans l'ordre déterminé : cette étape implique par exemple le téléchargement des composants depuis les sources configurées, leur extraction et leur configuration pour le système d’exploitation automobile. vérification de la cohérence du système : après la compilation et l'installation des composants, le gestionnaire de composants effectue des vérifications pour s'assurer de la cohérence du système d’exploitation automobile : cela inclus par exemple des vérifications de dépendances manquantes, des tests de fonctionnalité. A l’issue de la mise en œuvre de ces étapes, la résolution de l'arbre de dépendance de composants permet de garantir que toutes les dépendances requises par les applications du premier groupe sont satisfaites, dans l’architecture native du système d’exploitation automobile, assurant ainsi un système fonctionnel et cohérent pour la mise en œuvre de ces applications dont la performance d’exécution est le critère de sélection. Les applications du deuxième groupe, quant à elles, sont prioritairement configurées pour être compatibles avec une architecture différente de l’architecture (native) du système d’exploitation. Par exemple, si le système d’exploitation automobile est basé sur une architecture 64bits, les applications du deuxième groupe sont configurées en architecture 32bits. Comme pour les applications du premier groupe, une phase de résolution des dépendances de composants et de bibliothèque est mise en œuvre lors de la configuration des applications du deuxième groupe, par le dispositif électronique D2 qui pilote le gestionnaire de composants (ou préalablement à cette étape de configuration, en fonction de la mise en œuvre, par exemple dans l’environnement virtualisé décrit précédemment). Toutefois, certaines des étapes peuvent être mises en œuvre de manière différente. Par exemple, dans une phase de résolution de dépendances pour les applications du deuxième groupe (et/ou dans une phase préalable de sélection des applications du deuxième groupe), il est tenu compte des dépendances déjà résolues pour les applications du premier groupe et/ou de la stratégie d’allocation des ressources, et notamment des ressources disponibles à l’issue de la configuration des applications du premier groupe : par exemple lorsque les ressources consommées par les applications du premier groupe sont faibles, comme par exemple moins de 25% ou de 30% de la mémoire vive, certaines applications du deuxième groupe peuvent être transférées au premier groupe. Par exemple, lors de la construction de l’arbre de dépendance, si une dépendance d’une application existe pour la première architecture, mais pas pour la deuxième architecture, l’application associée à cette dépendance peut être marquée. Par exemple, lors de la sélection des applications, s’il advient qu’une dépendance ou que l’application est déjà connue comme étant disponible pour la première architecture, l’application peut être marquée. Ce marquage place l’application en question dans une liste d’applications transférables (potentiellement) dans le premier groupe. Cette opération de marquage est par exemple effectuée pour tout ou partie des applications dont par exemple une dépendance existe dans la première architecture. D’autres situations de marquage de ce type peuvent également être rencontrées, par exemple lorsqu’une application n’est disponible que dans la première architecture, mais pas dans la deuxième architecture. Puis, lorsque toutes les applications du deuxième groupe ont été inspectées, une étape de ségrégation des applications marquées comme potentiellement transférables est mise en œuvre. Cette étape de ségrégation consiste par exemple, en fonction de la stratégie globale d’allocation des ressources, à déterminer s’il est possible de basculer tout ou partie des applications marquées dans le premier groupe. La détermination de cette bascule dans le premier groupe tient compte, par exemple : du nombre ou du pourcentage d’applications déjà présent dans le premier groupe (par exemple si plus de 50% du total des applications se trouve déjà dans le premier groupe, la bascule dans le premier groupe n’est pas effectuée) ; de la consommation de ressources engendrée par le passage de l’application dans le premier groupe (si la consommation de ressource engendrée par la passage dans le premier groupe excède un seuil prédéterminée, par exemple une quantité de mémoire déterminée, par exemple supérieure à 250MB, la bascule dans le premier groupe n’est pas effectuée) ; de la consommation totale de ressources des applications déjà affectées au premier groupe ; de la disponibilité, ou non, d’une version des dépendances adaptée à la deuxième architecture (par exemple, s’il n’existe aucune version des dépendances dans la deuxième architecture, l’application est basculée dans le premier groupe) ; La détermination de cette bascule, par le dispositif électronique D2, est effectuée itérativement, de sorte à permettre une configuration progressive des applications. Si une ou plusieurs applications du deuxième groupe est basculée dans le premier groupe, tout ou partie de l’étape de configuration du premier groupe d’applications peut être à nouveau mise en œuvre, de manière à optimiser au maximum l’utilisation des ressources (par exemple en résolvant de nouvelles dépendances). Cette étape de configuration garantit que les applications du deuxième groupe permettront, lors de leur exécution, de minimiser l’utilisation notamment de la mémoire physique disponible sur le dispositif électronique embarqué D1 exécutant le système d’exploitation automobile par ces applications appartenant au deuxième groupe : une telle configuration permet d’assurer in fine que les applications du premier groupe -qui s’exécutent en parallèle des applications du deuxième groupe- bénéficient de ressources plus importantes (nombre de processeurs et/ou quantité de mémoire allouée) que les applications du deuxième groupe. En conséquence, il est possible d’exécuter, sur des dispositifs électroniques dont les ressources sont limitées, des applications de manière plus efficace, sans grever les possibilités d’exécution de plusieurs applications en parallèle. On évite ainsi d’avoir recours à des dispositifs électroniques trop couteux ou inutilement surdimensionnés. Alternativement, la configuration peut également être mise en œuvre, par le dispositif électronique D2, en effectuant une première compilation de l’ensemble des applications et des composants associés dans la première architecture, qui est l’architecture native du système d’exploitation automobile. La configuration se poursuit ensuite en effectuant une deuxième compilation de l’ensemble des applications et des composants associés dans la deuxième architecture, qui est distincte de la première architecture. Une fois l’ensemble des applications et composants compilés dans les deux architectures, les applications du premier groupe GpA1 sont sélectionnées, par exemple à l’aide d’une ou de plusieurs des méthodes présentées précédemment, tout comme les applications du deuxième groupe GpA2. L’image du système d’exploitation est ensuite construite en sélectionnant les fichiers compilés (i.e. le fichiers binaires), correspondants à chacune des applications, dans la version idoine, en fonction de l’appartenance de l’application. Système informatisé embarqué (SiE) au sein d’un véhicule routier, ledit système comprenant un dispositif électronique embarqué (D1) comprenant un processeur (Px), une mémoire vive (Mem) de taille prédéfinie, et une mémoire de masse (MS) au sein de laquelle est enregistrée une image logicielle (IMG) pour l’exécution d’un système d’exploitation automobile (SEA) et d’applications, caractérisé en ce que le système d’exploitation automobile (SEA) est compilé selon une première architecture et les applications sont divisées en deux groupes, un premier groupe d’applications (GpA1) compilées et optimisées pour un fonctionnement selon ladite première architecture et un deuxième groupe d’applications (GpA2) compilées et optimisées pour un fonctionnement selon une deuxième architecture distincte de la première architecture, ladite image logicielle (IMG) ayant été construite pour tenir compte de ressources d’exécution disponibles dudit dispositif électronique embarqué (D1). Système informatisé embarqué (SiE) selon la revendication 1, caractérisé en ce que ladite image (IMG) est construite en mettant en œuvre un dispositif (D2) de création d'une image logicielle d'un système d'exploitation automobile (SEA) comprenant : un module d'obtention (20), à partir d’un fichier de configuration (FCnf), d’un ensemble d’applications (EnsApp) à installer dans le système d’exploitation automobile; un module de détermination (25), à partir dudit ensemble d’applications à installer (EnsApp), du premier groupe d’applications (GpA1) pour lesquelles la performance est une condition impérative d’exécution ; un module de détermination (30), à partir dudit ensemble d’applications à installer (EnsApp), du deuxième groupe d’applications (GpA2) pour lesquelles l’économie de ressources est une condition acceptable d’exécution, le deuxième groupe étant distinct du premier groupe ; un module de configuration (35) des applications du premier groupe d’applications (GpA1) selon la première architecture de compilation, identique à une architecture du système d’exploitation automobile, délivrant un premier groupe d’applications configurées (ImgA1) ; un module de configuration (40) des applications du deuxième groupe d’applications (GpA2) selon la deuxième architecture de compilation, délivrant un deuxième groupe d’applications configurées (ImgA2) ; un module de création (45) de l’image logicielle (IMG) comprenant ledit système d’exploitation automobile (SEA), lesdites applications configurées (ImgA1) du premier groupe (GpA1) et les applications configurées (ImgA2) dudit deuxième groupe (GpA2). Système informatisé embarqué (SiE) selon la revendication 2, caractérisé en ce que le module de détermination (25) du premier groupe d'applications (GpA1) met en œuvre une sélection basée sur un premier indicateur prédéfini associé à au moins une application dudit ensemble d’applications (EnsApp) à installer et/ou le module de détermination (30) du deuxième groupe d’applications (GpA2) met en œuvre une sélection basée sur un deuxième indicateur prédéfini de ressources associé à au moins une application dudit ensemble d’applications (EnsApp) à installer, le deuxième indicateur étant distinct du premier indicateur. Système informatisé embarqué (SiE) selon la revendication 2, caractérisé en ce que le module de détermination (25) du premier groupe d’applications (GpA1) et le module de détermination (30) du deuxième groupe d’applications (GpA2) mettent en œuvre un module de mesure des ressources utilisées par au moins une application dudit ensemble d’applications (EnsApp) à installer, lesdites ressources appartenant au groupe comprenant la quantité de mémoire utilisée, le nombre de cœur(s) de processeur utilisé(s) et la quantité de mémoire disponible. Système informatisé embarqué (SiE) selon la revendication 2, caractérisé en ce que le module de détermination (25) du premier groupe d’applications (GpA1) et le module de détermination (30) du deuxième groupe d’applications (GpA2) mettent en œuvre un module de résolution d’un arbre de dépendance des composants logiciels utilisés par au moins une application dudit ensemble d’applications (EnsApp) à installer. Système informatisé embarqué (SiE) selon la revendication 5, caractérisé en ce que le module de détermination (30) du deuxième groupe d’applications (GpA2) détermine que lorsqu’une application courante, assignable au deuxième groupe, comprend une dépendance logicielle compilée selon la première architecture, elle est déplacée vers le premier groupe. Système informatisé embarqué (SiE) selon la revendication 2, caractérisé en ce que le module de détermination (30) du deuxième groupe d’applications (GpA2) met en œuvre des moyens de détermination d’une transférabilité, vers le premier groupe, d’une application courante, assignable au deuxième groupe, en fonction d’une stratégie d’assignation de ressources dudit système informatisé embarqué. Procédé de création d’une image logicielle (IMG) d’un système d’exploitation automobile (SEA) et d’applications, le procédé étant mis en œuvre par un dispositif électronique (D2) de création d'une image logicielle d'un système d'exploitation automobile et caractérisé en ce que le système d’exploitation (SEA) est compilé selon une première architecture et les applications sont divisées en deux groupes, un premier groupe d’applications (GpA1) compilées et optimisées pour un fonctionnement selon ladite première architecture et un deuxième groupe d’applications (GpA2) compilées et optimisées pour un fonctionnement selon une deuxième architecture distincte de la première architecture, ladite image logicielle (IMG) ayant été construite pour tenir compte de ressources d’exécution disponibles d’un dispositif électronique embarqué (D1) comprenant un processeur (Px) et une mémoire vive (Mem) de taille prédéfinie, une mémoire de masse (MS) au sein de laquelle est enregistrée ladite image logicielle (IMG), ledit dispositif électronique étant compris dans un système informatisé embarqué (SiE) au sein d’un véhicule routier. Procédé de création d’une image logicielle (IMG) selon la revendication 8, caractérisé en ce qu’il comprend les étapes suivantes : obtention (01), à partir d’un fichier de configuration (FCnf), d’un ensemble d’applications (EnsApp) à installer dans le système d’exploitation automobile ; une première détermination (02), à partir dudit ensemble d’applications à installer (EnsApp), du premier groupe d’applications (GpA1) pour lesquelles la performance est une condition impérative d’exécution ; une deuxième détermination (03), à partir dudit ensemble d’applications à installer, du deuxième groupe d’applications (GpA2) pour lesquelles l’économie de ressources est une condition acceptable d’exécution, le deuxième groupe étant distinct du premier groupe ; une première configuration (04) des applications du premier groupe d’applications (GpA1) selon une première architecture de compilation identique à une architecture du système d’exploitation automobile, délivrant un premier groupe d’applications configurées (ImgA1) ; une deuxième configuration (05) des applications du deuxième groupe d’applications (GpA2) selon la deuxième architecture de compilation distincte de la première architecture, délivrant un deuxième groupe d’applications configurées (ImgA2) ; création (06) de l’image logicielle (IMG) comprenant ledit système d’exploitation automobile (SEA), lesdites applications configurées (ImgA1) du premier groupe (GpA1) et les applications configurées (ImgA2) dudit deuxième groupe (GpA2). Programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un dispositif électronique programmable, mettent en œuvre un procédé création d’une image logicielle d’un système d’exploitation automobile conforme à la revendication 8 ou 9.