Hybrid embedded system for road vehicles, method and corresponding program

Abstract

Hybrid embedded system for road vehicles, method and corresponding program The present invention relates to an embedded computer system (SiE) within a road vehicle, which includes an embedded electronic device (D1) comprising a processor (Px), a random access memory (Mem) of predefined size and a mass storage (MS) in which is stored a software image (IMG) for the execution of an automotive operating system and applications.The automotive operating system is compiled according to a first architecture, and the applications are divided into two groups: a first group of applications compiled and optimized for operation according to said first architecture, and a second group of applications compiled and optimized for operation according to a second architecture distinct from the first architecture. This software image (IMG) has been built to take into account the execution resources available to said embedded electronic device (D1). Figure 1 for the abbreviation.

Description

Title of the invention: Hybrid on-board system for road vehicles, method and corresponding program Domain

[0001] The invention relates to on-board computer systems for road vehicles. The invention relates more particularly to an on-board electronic device for a road vehicle which supports the execution of applications associated with different processor architectures, for example 32-bit and 64-bit applications, or other dual architecture typology, by means of a hybrid automotive operating system. The invention relates more particularly to such a device and such an operating system which operates in a constrained hardware environment. Previous Art

[0002] With technological advancements, road vehicles include many features that are managed through a computerized system. These computerized systems for road vehicles are computers, also called electronic control units (ECUs), that run an operating system. An automotive operating system is a specialized software platform that provides a basis for managing and coordinating various functions and subsystems in a modern automotive environment. An automotive operating system thus provides real-time capabilities, reliability, and integration with vehicle hardware components and networks.

[0003] These automotive operating systems are thus designed to handle real-time tasks, where critical operations must be performed within specific timeframes. This is crucial for functions such as engine control, anti-lock braking, stability control, and other safety-critical systems. Furthermore, the automotive operating system facilitates communication and coordination between the various ECUs in the vehicle. It allows for seamless data exchange and coordination of functionality between different systems, including the powertrain, chassis, infotainment systems, and driver assistance systems. It also manages interaction with various devices and sensors in the vehicle, such as engine sensors, cameras, radars, lidars, and other input / output devices.It provides standardized interfaces and protocols for communication and data exchange with these components.

[0004] To implement these functionalities, the automotive operating system manages the allocation of memory and resources (particularly computing) available in order to to ensure efficient use of computing resources. The system is therefore responsible for prioritizing and scheduling tasks, managing memory allocation for different applications, and managing system resources such as CPU usage, network bandwidth, and storage space.

[0005] Examples of automotive operating systems include QNX Neutrino, AUTOSAR (AUTomotive Open System Architecture), Android Automotive OS, and Linux-based platforms such as Automotive Grade Linux (AGL) and GENIVI.

[0006] Automotive computer systems, on which automotive operating systems run, are built either using a 32-bit architecture to optimize memory and storage consumption, or using a 64-bit architecture to optimize performance.

[0007] Such a dichotomy has the disadvantage of not adapting to the evolution of applications and computer programs that are executed by automotive operating systems. This dichotomy has the disadvantage of not taking into consideration certain economic factors linked to the use of one architecture rather than another, in particular the price of the computer platform used for the operation of automotive operating systems and the applications and programs that it embeds. This dichotomy also has the disadvantage of not offering a platform that is correctly sized according to needs.

[0008] No solution has been proposed to design an automotive system that automatically finds the best compromise for each software component and their dependencies. Summary

[0009] The invention was designed to resolve this problem of resource consumption which is posed by the systems of the prior art.

[0010] For this purpose, the subject of the invention is a computerized system embedded in a road vehicle, the system comprising an embedded electronic device comprising a processor, a RAM of predefined size, and a mass memory in which a software image is recorded for the execution of an automotive operating system and applications. According to the invention, this automotive operating system is compiled according to a first architecture and the applications are divided into two groups, a first group of applications compiled and optimized for operation according to said first architecture and a second group of applications compiled and optimized for operation according to a second architecture distinct from the first architecture, said software image having been constructed to take into account available execution resources of the embedded electronic device.

[0011] According to a particular characteristic, said image is constructed by implementing a device for creating a software image of an automobile operating system comprising: - a module for obtaining, from a configuration file, a set of applications to be installed in the automotive operating system; - a module for determining, from the set of applications to be installed, the first group of applications for which performance is an imperative condition of execution; - a module for determining, from the set of applications to be installed, the second group of applications for which saving resources is an acceptable condition of execution, the second group being distinct from the first group; - a module for configuring the applications of the first group of applications according to the first compilation architecture, identical to an architecture of the automotive operating system, delivering a first group of configured applications; - a module for configuring the applications of the second group of applications according to the second compilation architecture, delivering a second group of configured applications; - a module for creating the software image comprising the automotive operating system, said configured applications of the first group and the configured applications of the second group.

[0012] According to a particular characteristic, the module for determining the first group of applications implements a selection based on a first predefined indicator associated with at least one application from the set of applications to be installed and / or the module for determining the second group of applications implements a selection based on a second predefined resource indicator associated with at least one application from the set of applications to be installed, the second indicator being distinct from the first indicator.

[0013] According to a particular characteristic, the module for determining the first group of applications and the module for determining the second group of applications implement a module for measuring the resources used by at least one application of the set of applications to be installed, said resources belonging to the group comprising the quantity of memory used, the number of processor core(s) used and the quantity of memory available.

[0014] According to a particular characteristic, the module for determining the first group of applications and the module for determining the second group of applications implement a module for resolving a component dependency tree software used by at least one application in the set of applications to be installed.

[0015] According to a particular characteristic, the module for determining the second group of applications determines that when a current application, assignable to the second group, includes a software dependency compiled according to the first architecture, it is moved to the first group.

[0016] According to a particular characteristic, the module for determining the second group of applications implements means for determining a transferability, to the first group, of a current application, assignable to the second group, as a function of a resource allocation strategy of the on-board computer system.

[0017] According to another aspect, the invention also relates to a method for creating a software image of an automotive operating system and applications, the method being implemented by an electronic device for creating the software image of the automotive operating system.According to the invention, the operating system is compiled according to a first architecture and the applications are divided into two groups, a first group of applications compiled and optimized for operation according to said first architecture and a second group of applications compiled and optimized for operation according to a second architecture distinct from the first architecture, said software image having been constructed to take into account available execution resources of an on-board electronic device comprising a processor and a RAM of predefined size, a mass memory within which said software image is recorded, the electronic device being included in a computerized system on board a road vehicle.

[0018] According to a particular characteristic, the method of creating a software image comprises the following steps: - obtaining, from a configuration file, a set of applications to be installed in the automotive operating system; - a first determination, from the set of applications to be installed, of the first group of applications for which performance is an imperative condition of execution; - a second determination, from the set of applications to be installed, of the second group of applications for which saving resources is an acceptable condition of execution, the second group being distinct from the first group; - a first configuration of the applications of the first group of applications according to a first compilation architecture identical to an architecture of the automotive operating system, delivering a first group of configured applications; - a second configuration of the applications of the second group of applications according to the second compilation architecture distinct from the first architecture, delivering a second group of configured applications; - creation of the software image comprising the automotive operating system, said configured applications of the first group and the configured applications of the second group.

[0019] According to another aspect, the invention also relates to a computer program comprising software instructions which, when executed by a programmable electronic device, implement a method of creating a software image as defined above. Brief description of the figures

[0020] The invention will appear more clearly on reading the description which follows, given solely by way of non-limiting example, and made with reference to the drawings in which: - [Fig.l] illustrates an on-board computer system for executing an automotive operating system according to the invention; - [Fig.2] illustrates an electronic device for creating a software image of an automotive operating system; - [Fig.3] explains the different stages of the process of creating a software image of an automotive operating system. Description of an embodiment

[0021] As indicated previously, the invention relates to an on-board electronic device for a road vehicle which supports the optimized execution of applications according to a first architecture (for example 64 bits) and supports the optimized execution of applications according to a second architecture (for example 32 bits) thanks to a suitable automotive operating system. More particularly, the inventors have designed an automotive operating system running on the first hardware architecture, the automotive operating system comprising means for executing applications according to the second architecture. The distribution of the applications according to the architecture is carried out during the creation of a software image of the automotive operating system and the applications it contains, according to constraints originating from the on-board electronic device and the hardware platform associated therewith.

[0022] In relation to [Fig.l], the on-board electronic device DI for a road vehicle is integrated within an on-board computer system SiE, in the form of a hardware platform. The on-board electronic device comprises a Px processor and Mem RAM. The processor is for example a multi-core processor, based on the first architecture. The Mem memory attached to this processor is of a predetermined size. These parameters (type of processor, number of cores, predetermined memory size) are specifications imposed by the manufacturer of the motor vehicle, in particular based on economic constraints. The electronic device DI also includes a mass memory MS in which a software image IMG of the automotive operating system and applications is recorded. All or part of the applications contained in this software image IMG is loaded into memory when the vehicle is started. The hardware platform, within which the electronic device is integrated, includes a set of CMP components (for example network), SENS sensors (cameras, sensors of the various subsystems of the vehicle, e.g.exhaust gas oxygen sensor, speed sensor, tire pressure sensor, temperature sensors, light sensor, collision sensor, airbag sensor, camera sensors, navigation sensor, etc.), ACTN actuators, for the management and coordination of various vehicle functions and subsystems (e.g. guidance, emergency braking, anti-lock braking, engine status, etc.).

[0023] On the on-board electronic device D1, the automotive operating system operates in native mode, namely according to the first architecture. The applications running on the automotive operating system, such as applications for which execution performance is the determining factor, are applications operating natively according to the first architecture. The processor of the electronic device operates according to the first architecture when executing an application according to the first architecture. The processor of the on-board electronic device operates in compatibility mode when executing an application according to the second architecture. This compatibility mode is managed by the automotive operating system.

[0024] An object of the invention is to minimize, as much as possible, the characteristics of the embedded electronic device (processor, number of cores, amount of memory) while ensuring the execution of all the applications under optimal conditions, in particular security conditions. In other words, the object of the invention is to allow the execution of a maximum number of applications in a constrained execution environment (number of processors, amount of memory). Thus, a global strategy for allocating application execution resources is defined, in which, for example, the number of applications associated with a maximum performance profile (i.e., applications operating according to the first architecture) is limited and in which the use of applications that are not very resource-intensive is favored (i.e., applications operating according to the second architecture).

[0025] The invention also relates to a method for constructing the IMG software image of the automotive operating system in which each application is configured and optimized to operate according to the first architecture or according to the second architecture. It is recalled that a software image of an operating system is a binary file which represents a specific version of an operating system ready to be installed on a computer or another device. The software image of the automotive operating system contains all the files, configurations and programs necessary to run the automotive operating system on the on-board electronic device. In the context of the invention, such a software image also comprises a set of applications, each application of this set of applications being configured to operate either according to the first architecture or according to the second architecture.According to the invention, moreover, such a software image is constructed to adapt to the resources of the target embedded electronic device and to the target platform which hosts it.

[0026] [Fig.2] describes an electronic device D2 for creating the software image of an automotive operating system. This device D2 can be implemented in a phase of preparing one or more software images to be installed in road vehicles of different types, with different hardware configurations.

[0027] In the example of [Fig.2], the electronic device D2 for creating the software image IMG of an automobile operating system comprises an electronic memory unit 16, at least one calculation processor 18 and an interface 80 for communication with remote devices, by a chosen communication protocol, for example a wired protocol and / or a radio communication protocol. The elements of the device D2 are adapted to communicate via a communication bus 15.

[0028] In the example of [Fig. 2], the creation device D2 comprises a module 20 for obtaining a list of applications to be installed in the automotive operating system, a module 25 for determining a first group of applications GpAl, illustrated in [Fig. 3], for which performance is an imperative condition of execution, a module 30 for determining a second group of applications GpA2, illustrated in [Fig.3], for which saving execution resources is an acceptable execution condition, a configuration module 35 of the applications of the first group according to the first configuration architecture, identical to the configuration architecture of the automotive operating system, a second configuration module 40 of the applications of the second group according to the second architecture, different from the compilation architecture of the automotive operating system, and a creation module 45 configured to assemble the automotive operating system and the applications of the first and second groups to form the software image IMG. These modules are each produced in the form of a . software, or a software brick, executable by the processor. The memory of the electronic device D2 is then able to store the software corresponding to the aforementioned modules. The processor is then able to execute each of these software programs. In a variant not shown, these modules are each produced in the form of a programmable logic component, such as an FPGA (from the English "Field Programmable Gate Array"), or an integrated circuit, such as an ASIC (from the English "Application Specified Integrated Circuit").

[0029] When the creation device D2 is produced in the form of one or more software programs, that is to say in the form of a computer program, also called a computer program product, it is also capable of being recorded on a medium, not shown, readable by a computer. The computer-readable medium is for example a medium capable of storing electronic instructions and of being coupled to a bus of a computer system. By way of example, the readable medium is an optical disk, a magneto-optical disk, a ROM memory, a RAM memory, any type of non-volatile memory (for example FLASH or NVRAM) or a magnetic card. A computer program comprising software instructions is then stored on the readable medium.

[0030] In summary, this electronic device D2 makes it possible to obtain a set of applications from a configuration file, to determine groups of applications according to their performance and resource saving requirements, to configure the applications according to different architectures, and to create the software image comprising the automotive operating system and the configured applications.

[0031] The method for creating the software image of the automotive operating system SEA is described in relation to [Fig.3] and it comprises the following steps: - obtaining 01, from a configuration file FCnf, a set of applications EnsApp to be installed in the automotive operating system; - a first determination 02, from said set of applications to be installed EnsApp, of a first group of applications GpAl for which performance is an imperative condition of execution; - a second determination 03, from said set of applications to be installed, of a second group of GpA2 applications for which saving resources is an acceptable condition of execution; - a first configuration 04 of the applications of the first group of applications GpAl according to the first compilation architecture, identical to a compilation architecture of the automotive operating system (e.g. 64-bit architecture), delivering a first group of configured applications ImgAl; - a second configuration 05 of the applications of the second group of GpA2 applications according to the second compilation architecture, different from the compilation architecture of the automotive operating system (e.g. 32-bit architecture), delivering a second group of ImgA2 configured applications; - creation 06 of the software image IMG comprising the automotive operating system SEA, said configured applications ImgAl of the first group GpAl and the configured applications ImgA2 of said second group GpA2.

[0032] According to the invention, the first determination step 02 comprises a step of evaluating, as a function of an application specification file, for each application of the set of applications, an application execution condition. Thus, according to the invention, in the set of applications which must be installed (and provided) with the automotive operating system, at least some of them (the sensitive applications, for which a level of execution performance is expected) have a first indicator, which specifies the execution conditions of this application.The first indicator is for example predefined and of Boolean type (“true” meaning “performance imperative”, “false” meaning “performance not imperative” and the absence of valuation (or the absence of the indicator) meaning “unknown / unspecified”). For each application concerned, a respective first indicator is typically contained in the application specification file. Other formalizations of the first indicator can of course be implemented depending on the needs. The first determination step consists for example in placing, in the first group, the applications of the set of applications for which the value of the first indicator specifies that the execution condition is performance.For each application placed in the first group, optionally, the expected amount of execution resources assigned / associated with this application is added in a data structure, for example in the form of a data triplet {application identifier / RAM / number of processors}. Optionally, remaining resource values ​​may be decreased based on the values ​​assigned to each application placed in the first group. After placing these applications in the first group, an expected amount of consumed resources may be predicted, when the counting of these resources is carried out as the applications are placed in the first group GpAl.

[0033] According to the invention, the second determination step 03 comprises a step of evaluating, as a function of the application specification file, the same application execution condition. In an exemplary embodiment, all the applications of the set of applications which are not part of the first application group GpA1 are placed in the second application group GpA2. In a second exemplary embodiment, only applications for which a second indicator is valued to indicate a saving of resources are placed in this second group of applications GpA2. Thus, in this second exemplary embodiment, the second indicator, complementary to the first indicator exemplified previously, is for example present in the application specification file.

[0034] Depending on the implementation methods, at the end of the execution of the two determination steps, the applications of the list of applications are placed either in the first group GpAl, or in the second group GpA2.

[0035] Applications may not be placed in either of these two groups, for example when they do not have a first indicator (relating to the first architecture, for example relating to performance) and when they do not have a second indicator (relating to the second architecture, for example relating to resource saving) or in other circumstances. In which case, it is necessary to determine which group to associate these applications with.

[0036] A first method of association consists, for example, in assigning, without further consideration, all the applications having no indicator in the second group GpA2. The advantage of this assignment is that it ensures that the resources of the execution platform of the automotive operating system will be even more saved. The disadvantage is that potentially, a performance-oriented application may be in the second group, when it should not be there.

[0037] A second association method consists, for example, in determining which additional hardware components of the platform each application accesses. More particularly, in this second method, the electronic device D2 relies on the inputs and outputs of the application to determine its allocation group. To implement this second association method, the electronic device D2 uses, for a target hardware platform (processor, amount of available memory), not only characteristics of the processor of the embedded electronic device but also of the various components (cameras, sensors, actuators) that it embeds. The decision to classify a current application in the first group of applications (running natively in the first architecture) or in the second group, consists, for example, in carrying out one or more functional tests of an instance of this current application.These functional tests are, for example, conducted in a virtualized environment. They allow us to determine which components (sensors, actuators, etc.) of the platform are accessed by the current application. Depending on the components accessed and the frequency of these accesses, the application can be placed in the first or second group. For example, applications that access sensors are . related to vehicle safety (e.g. tire pressure, engine temperature, brake, speed) are considered priority and therefore placed in the first group while applications that only access sensors considered non-essential to the operation and safety of the vehicle (e.g. position sensor, audio, camera, air conditioning, etc.) are placed in the second group.

[0038] Each time an application is placed in the first group GpAl, or in the second group GpA2, optionally, the predictable (or measured, if for example the electronic device D2 has used a virtualized environment to test the applications, or depending on any other means of obtaining) quantity of execution resources allocated / associated with this application is added in a data structure, for example in the form of a data triplet {application identifier / RAM / number of processors}. Optionally, remaining resource values ​​may be decreased depending on the values ​​allocated to each application placed in the first group GpAl.

[0039] It can be noted that this second association method can be used as the sole and unique association method: it can be used instead of all or part of the previously mentioned indicators, to automatically determine the group in which an application must be placed. Optionally or alternatively, the previously mentioned indicators can come from a prior execution, for example in a virtualized environment as presented previously, of all of these applications, in order, precisely, to value these indicators in anticipation.In other words, the association of an application from the set of applications to one or other of the first or second group can be implemented during a step of measuring the resources used by all or part of the applications from the set of applications, during the first and / or second determination step and / or during a prior step of associating an indicator for determining the execution conditions of the applications from the set of applications, such as those presented previously.

[0040] The applications of the first group are configured in the same compilation architecture as that of the automotive operating system, namely the first architecture. For example, if the automotive operating system is based on a 64-bit architecture, the applications of the first group are configured in 64-bit architecture. This configuration step ensures that the applications of the first group will benefit from the highest performance, given their direct compatibility with the native libraries of the operating system.

[0041] More particularly, during the configuration step of the applications of the first group (or prior to this configuration step, depending on the implementation, for example in a virtualized environment as described previously), the electronic device D2 carries out a resolution of the dependency tree of the components of these applications (these may be packages and / or software libraries). This resolution is carried out via a component manager to which the electronic device D2 has access, and which it controls. According to the invention, the implementation of the resolution of the dependency tree of the applications comprises the following steps: - dependency analysis: the component manager analyzes the metadata of the software components of the applications of the first group to identify the dependencies required by each software component of the applications belonging to this first group: this metadata is stored in configuration files or locations specific to each component; - construction of the dependency tree: from the information collected, a dependency tree is constructed, each node of the tree representing a component, and the dependencies being represented by links between the nodes; this construction is carried out iteratively; - component availability check: before compiling into the desired architecture, the component manager checks the availability of precompiled components in configured software repositories or sources: this ensures that the necessary components are accessible and can be downloaded, without the need to compile them into the desired architecture: - when the component is already compiled in the target architecture and its version is suitable, the component is not recompiled; - when the component is not compiled in the target architecture or its version is not suitable, the component will be recompiled; - resolution of dependency conflicts: when dependency conflicts exist, i.e. when two components require incompatible versions of the same dependency, the component manager resolves these conflicts by searching for compatible alternative versions and / or by selecting updates to existing components when such updates exist; - determination of compilation and / or installation order: once the dependency tree is built and conflicts are resolved (possibly iteratively), the component manager determines the order in which components must be compiled and installed (or directly installed if they are already compiled in a correct version for the target architecture) to satisfy all dependencies; - compilation and installation of components: once all dependencies have been resolved, the component manager proceeds to compile (when necessary) and install the components in the determined order: this step involves, for example, downloading the components from the configured sources, extracting them and configuring them for the automotive operating system. - system consistency check: after compiling and installing components, the component manager performs checks to ensure the consistency of the automotive operating system: this includes, for example, missing dependency checks and functionality tests.

[0042] At the end of the implementation of these steps, the resolution of the component dependency tree makes it possible to guarantee that all the dependencies required by the applications of the first group are satisfied, in the native architecture of the automotive operating system, thus ensuring a functional and coherent system for the implementation of these applications for which execution performance is the selection criterion.

[0043] The applications of the second group, for their part, are configured as a priority to be compatible with an architecture different from the (native) architecture of the operating system. For example, if the automobile operating system is based on a 64-bit architecture, the applications of the second group are configured in 32-bit architecture.

[0044] As for the applications of the first group, a phase of resolving component and library dependencies is implemented during the configuration of the applications of the second group, by the electronic device D2 which controls the component manager (or prior to this configuration step, depending on the implementation, for example in the virtualized environment described previously).

[0045] However, some of the steps may be implemented differently. For example, in a dependency resolution phase for the applications of the second group (and / or in a prior phase of selecting the applications of the second group), account is taken of the dependencies already resolved for the applications of the first group and / or of the resource allocation strategy, and in particular of the resources available following the configuration of the applications of the first group: for example, when the resources consumed by the applications of the first group are low, such as for example less than 25% or 30% of the RAM, certain applications of the second group may be transferred to the first group.

[0046] For example, when building the dependency tree, if a dependency of an application exists for the first architecture, but not for the second architecture, the application associated with this dependency can be marked. For example, when selecting applications, if it happens that a dependency or the application is already known to be available for the first architecture, the application can be marked. This marking places the application in question in a list of applications that can be (potentially) transferred to the first group. This marking operation is for example carried out for all or some of the applications for which, for example, a dependency exists in the first architecture. Other marking situations of this type can also be encountered, for example when an application is only available in the first architecture, but not in the second architecture.Then, when all applications in the second group have been inspected, a segregation step for applications marked as potentially transferable is implemented. This segregation step consists, for example, depending on the overall resource allocation strategy, in determining whether it is possible to switch all or part of the applications marked in the first group. The determination of this switch in the first group takes into account, for example: . - the number or percentage of applications already present in the first group (for example, if more than 50% of the total applications are already in the first group, the switch to the first group is not carried out); - the resource consumption generated by the application moving to the first group (if the resource consumption generated by the move to the first group exceeds a predetermined threshold, for example a determined amount of memory, for example greater than 250MB, the switch to the first group is not carried out); - the total resource consumption of applications already assigned to the first group; - the availability, or not, of a version of the dependencies adapted to the second architecture (for example, if there is no version of the dependencies in the second architecture, the application is switched to the first group);

[0047] The determination of this switch, by the electronic device D2, is carried out iteratively, so as to allow a progressive configuration of the applications. If one or more applications of the second group is switched into the first group, all or part of the configuration step of the first group of applications can be implemented again, so as to optimize the use of resources as much as possible (for example by resolving new dependencies).

[0048] This configuration step ensures that the applications of the second group will, during their execution, minimize the use in particular of the physical memory available on the on-board electronic device DI running the automotive operating system by these applications belonging to the second group: such a configuration ultimately ensures that the applications of the first group - which run in parallel with the applications of the second group - benefit from greater resources (number of processors and / or quantity of allocated memory) than the applications of the second group. Consequently, it is possible to execute, on electronic devices whose resources are limited, applications more efficiently, without burdening the possibilities of running several applications in parallel. This avoids having to resort to electronic devices that are too expensive or unnecessarily oversized.

[0049] Alternatively, the configuration can also be implemented, by the electronic device D2, by performing a first compilation of all the applications and associated components in the first architecture, which is the native architecture of the automotive operating system. The configuration then continues by performing a second compilation of all the applications and associated components in the second architecture, which is distinct from the first architecture. Once all the applications and components have been compiled in both architectures, the applications of the first group GpA1 are selected, for example using one or more of the methods presented previously, just like the applications of the second group GpA2. The operating system image is then built by selecting the compiled files (i.e.the binary files), corresponding to each of the applications, in the appropriate version, depending on the application's membership.

Claims

Claims

1. Embedded computer system (SiE) within a road vehicle, said system comprising an embedded electronic device (Dl) comprising a processor (Px), a random access memory (Mem) of predefined size, and a mass memory (MS) within which is recorded a software image (IMG) for the execution of an automotive operating system (SEA) and applications, characterized in that the automotive operating system (SEA) is compiled according to a first architecture and the applications are divided into two groups, a first group of applications (GpAl) compiled and optimized for operation according to said first architecture and a second group of applications (GpA2) compiled and optimized for operation according to a second architecture distinct from the first architecture, said software image (IMG) having been constructed to take into account available execution resources of said embedded electronic device (Dl).

2. On-board computer system (SiE) according to claim 1, characterized in that said image (IMG) is constructed by implementing a device (D2) for creating a software image of an automotive operating system (SEA) comprising: - a module (20) for obtaining, from a configuration file (FCnf), a set of applications (EnsApp) to be installed in the automotive operating system; - a determination module (25), from said set of applications to be installed (EnsApp), of the first group of applications (GpAl) for which performance is an imperative condition of execution; - a determination module (30), from said set of applications to be installed (EnsApp), of the second group of applications (GpA2) for which saving resources is an acceptable condition of execution, the second group being distinct from the first group; - a configuration module (35) of the applications of the first group of applications (GpAl) according to the first compilation architecture, identical to an architecture of the automotive operating system, delivering a first group of configured applications (ImgAl); - a configuration module (40) for the applications of the second group of applications (GpA2) according to the second compilation architecture, delivering a second group of configured applications (ImgA2); - a creation module (45) for the software image (IMG) comprising said automotive operating system (SEA), said configured applications (ImgAl) of the first group (GpAl) and the configured applications (ImgA2) of said second group (GpA2).

3. Embedded computer system (SiE) according to claim 2, characterized in that the determination module (25) of the first group of applications (GpAl) implements a selection based on a first predefined indicator associated with at least one application of said set of applications (EnsApp) to be installed and / or the determination module (30) of the second group of applications (GpA2) implements a selection based on a second predefined resource indicator associated with at least one application of said set of applications (EnsApp) to be installed, the second indicator being distinct from the first indicator.

4. Embedded computer system (SiE) according to claim 2, characterized in that the determination module (25) of the first group of applications (GpAl) and the determination module (30) of the second group of applications (GpA2) implement a module for measuring the resources used by at least one application of said set of applications (EnsApp) to be installed, said resources belonging to the group comprising the quantity of memory used, the number of processor core(s) used and the quantity of memory available.

5. Embedded computer system (SiE) according to claim 2, characterized in that the determination module (25) of the first group of applications (GpAl) and the determination module (30) of the second group of applications (GpA2) implement a module for resolving a dependency tree of the software components used by at least one application of said set of applications (EnsApp) to be installed.

6. On-board computer system (SiE) according to claim 5, characterized in that the determination module (30) of the second group of applications (GpA2) determines that when a current application, assignable to the second group, includes a software dependency compiled according to the first architecture, it is moved to the first group.

7. Embedded computer system (SiE) according to claim 2, characterized in that the determination module (30) of the second group of applications (GpA2) implements means for determining a transferability, to the first group, of a current application, assignable to the second group, according to a resource allocation strategy of said embedded computer system.

8. Method for creating a software image (IMG) of an automotive operating system (SEA) and applications, the method being implemented by an electronic device (D2) for creating a software image of an automotive operating system and characterized in that the operating system (SEA) is compiled according to a first architecture and the applications are divided into two groups, a first group of applications (GpAl) compiled and optimized for operation according to said first architecture and a second group of applications (GpA2) compiled and optimized for operation according to a second architecture distinct from the first architecture, said software image (IMG) having been constructed to take into account available execution resources of an on-board electronic device (Dl) comprising a processor (Px) and a RAM (Mem) of predefined size,a mass memory (MS) in which said software image (IMG) is recorded, said electronic device being included in an on-board computer system (SiE) within a road vehicle.,

9. Method for creating a software image (IMG) according to claim 8, characterized in that it comprises the following steps: - obtaining (01), from a configuration file (FCnf), a set of applications (EnsApp) to be installed in the automotive operating system; - a first determination (02), from said set of applications to be installed (EnsApp), of the first group of applications (GpAl) for which performance is an imperative condition of execution; - a second determination (03), from said set of applications to be installed, from the second group of applications (GpA2) for which saving resources is an acceptable condition of execution, the second group being distinct from the first group; - a first configuration (04) of the applications of the first group of applications (GpAl) according to a first compilation architecture identical to an architecture of the automotive operating system, delivering a first group of configured applications (ImgAl); - a second configuration (05) of the applications of the second group of applications (GpA2) according to the second compilation architecture distinct from the first architecture, delivering a second group of configured applications (ImgA2); - creation (06) of the software image (IMG) comprising said automotive operating system (SEA), said configured applications (ImgAl) of the first group (GpAl) and the configured applications (ImgA2) of said second group (GpA2).

10. A computer program comprising software instructions which, when executed by a programmable electronic device, implement a method of creating a software image of an automotive operating system according to claim 8 or 9.

Images