Method and device for controlling embedded applications in a vehicle

Abstract

The present invention relates to a method and device for controlling a set of applications embedded in a vehicle, each application having multiple execution modes and associated resource requirements. To this end, a configuration request for the set of applications is received (61). One or more execution modes are determined (62) for each application based on resource requirements and available resources. A user acceptance level associated with each execution mode is further determined. An execution mode is selected (63) based on the user acceptance levels. The execution of the set of applications is controlled (64) according to the selected execution modes. Figure for the abstract: Figure 6

Description

Title of the invention: Method and device for controlling applications embedded in a vehicle Technical field

[0001] The present invention relates to methods and devices or systems for controlling a set of applications embedded in a vehicle, in particular a motor vehicle. The present invention also relates to a method and a device for controlling the execution mode according to which each application is implemented in the vehicle. Technological background

[0002] Contemporary vehicles have a number of computers on board, each performing one or more functions, such as, for example, the management of driving assistance, anti-skid, electronic brake distribution, the control of actuators to ensure optimal operation of an engine, the piloting and control of the infotainment system, also called IVI system (from the English "In-Vehicle Infotainment" or in French "Infodivertissement embargo") and / or other systems embedded in the vehicle such as, for example, the air conditioning system and the vehicle's navigation system.

[0003] These calculators are also called ECU ("Electronic Control Unit"). These calculators contain software that is executed to perform the functions for which they are responsible. For example, an engine calculator, also called an "engine control unit" or "engine control unit", is configured to collect input data (from sensors or other), process this data and send control signals to various components (actuators) of the engine.

[0004] These applications correspond to software modules implemented by one or more vehicle computers, some of these applications corresponding to interactive applications, also called interactive widgets.

[0005] These on-board applications are intended to be updated, for example to improve the operation of these applications or to offer more services to users of the vehicle, via the downloading of update data according to a communication mode called OTA (from the English “Over The Air” or in French “par voie aérien”) or FOTA (from the English “Firmware Over-The-Air” or in French “firmware by radio link”), the vehicles having a communication system configured to communicate via a wireless network with one or more devices remote positives from the "cloud" (or "cloud" in French) for example. On-board applications can also be supplemented by the installation of new applications, thus enriching the range of on-board services offered to vehicle users.

[0006] One of the problems that arises is that the software evolution of the vehicle, with the resulting increase in resource requirements (in terms of computing power, memory footprint, bandwidth, etc.), is carried out with a hardware architecture provided during the design of the vehicle, which may sometimes prove insufficient to ensure the implementation of several applications in parallel. The simultaneous execution of several applications can thus generate problems with degraded operation of one or more applications, an interruption in the implementation of one or more applications, which degrades the user experience. Summary of the present invention

[0007] An object of the present invention is to solve at least one of the problems of the technological background described above.

[0008] Another object of the present invention is to improve the operation of applications embedded in a vehicle.

[0009] Another object of the present invention is, for example, to improve the user experience with regard to the execution of applications embedded in the vehicle.

[0010] According to a first aspect, the present invention relates to a method for controlling a set of applications embedded in a vehicle, a plurality of execution modes being associated with each application of the set of applications, first data representative of resource requirements being associated with each execution mode of the plurality of execution modes, the method comprising the following steps: - receiving a configuration request from the set of applications, the request comprising second data representative of current available resources associated with the vehicle; - determination, for each application in the set of applications, of: • a set of execution modes in the plurality of execution modes based on the first and second data, the set of execution modes comprising at least one execution mode, and • information representing the user acceptance level associated with each execution mode of the set of execution modes, called AXIL information; - selection, for each application in the set of applications, of an execution mode in the set of execution modes based on the AXIL information; - execution control of the application set according to the selected execution modes.

[0011] Such a method makes it possible to select one or more execution modes for each application to be implemented by the vehicle according to the resource requirements associated with this or these execution modes and according to the resources available at the vehicle level. Taking into account a level of acceptance of each execution mode by a user makes it possible to choose the most suitable execution modes to improve the user experience. The introduction of a new criterion relating to the user experience for the selection of the operating or execution mode of the set of applications makes it possible to improve user satisfaction, while taking into account the physical reality (available resources and necessary resources) for the implementation or execution of the applications in a given context.

[0012] According to a variant, the plurality of execution modes associated with each application comprises a nominal execution mode representative of a mode according to which each application is executed to operate according to a reference performance level, a deactivated execution mode according to which each application is not executed and at least one additional execution mode according to which each application is executed to operate in a degraded mode with a performance level lower than the reference performance level or in an augmented mode with a performance level higher than the reference performance level.

[0013] According to another variant, the AXIL information is determined from: - metadata representative of a user acceptance level associated with each execution mode of the plurality of execution modes; and / or - rules for calculating the user acceptance level associated with each execution mode of the plurality of execution modes based on a set of user profile parameters and / or execution context parameters.

[0014] According to an additional variant, the user acceptance level is a function of a set of evaluation criteria comprising: - a first criterion representative of a level of ease in ensuring a function without assistance of each application; - a second criterion representative of a rate of use of each application; and - a third criterion representative of a level of quality of service perceived for each execution mode.

[0015] According to an additional variant, the execution control is furthermore a function of: - a parameter representative of a minimum switching duration for changing execution mode, the minimum switching duration being a function of a current execution context of each application; and / or - a parameter representative of energy consumption by each application in the selected execution mode.

[0016] According to a further variant, the resources of the resource requirements and the current resources belong to a set of resources comprising: - computing resources; - memory resources; and - network resources.

[0017] According to a second aspect, the present invention relates to a device for controlling a set of applications embedded in a vehicle, the device comprising a memory associated with a processor configured for implementing the steps of the method according to the first aspect of the present invention.

[0018] According to a third aspect, the present invention relates to a vehicle, for example of the automobile type, comprising a device as described above according to the second aspect of the present invention.

[0019] According to a fourth aspect, the present invention relates to a computer program which comprises instructions adapted for executing the steps of the method according to the first aspect of the present invention, in particular when the computer program is executed by at least one processor.

[0020] Such a computer program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0021] According to a fifth aspect, the present invention relates to a computer-readable recording medium on which is recorded a computer program comprising instructions for carrying out the steps of the method according to the first aspect of the present invention.

[0022] On the one hand, the recording medium may be any entity or device capable of storing the program. For example, the medium may comprise a storage means, such as a ROM memory, a RAM memory, a CD-ROM or a microelectronic circuit type ROM memory, or a magnetic recording means or a hard disk.

[0023] Furthermore, this recording medium may also be a transmissible medium such as an electrical or optical signal, such a signal being able to be conveyed via an electrical or optical cable, by conventional or hertzian radio or by self-directed laser beam or by other means. The computer program according to the present invention may in particular be downloaded from an Internet-type network.

[0024] Alternatively, the recording medium may be an integrated circuit in which the computer program is incorporated, the integrated circuit being adapted to execute or for use in carrying out the process in question. Brief description of the figures

[0025] Other characteristics and advantages of the present invention will emerge from the description of the particular and non-limiting exemplary embodiments of the present invention below, with reference to the appended figures 1 to 6, in which:

[0026] [Fig-1] schematically illustrates an on-board vehicle system, according to an example particular and non-limiting embodiment of the present invention.

[0027] [Fig.2] schematically illustrates a table defining a set of user acceptance levels of execution modes for applications implemented by the on-board system of the vehicle of [Fig.l], according to a particular and non-limiting exemplary embodiment of the present invention.

[0028] [Fig.3] schematically illustrates a process for determining the user acceptance level for each mode of execution of a set of applications implemented by the on-board system of the vehicle of [Fig.l], according to a particular and non-limiting exemplary embodiment of the present invention.

[0029] [Fig.4] schematically illustrates a process for optimizing the user acceptance level for each mode of execution of a set of applications implemented by the on-board system of the vehicle of [Fig.l], according to a particular and non-limiting exemplary embodiment of the present invention.

[0030] [Fig.5] schematically illustrates a device for controlling a set of applications embedded in the vehicle of [Fig.l], according to particular and non-limiting exemplary embodiments of the present invention; and

[0031] [Fig.6] illustrates a flowchart of the different steps of a method for controlling a set of applications embedded in the vehicle of [Fig.l], according to a particular and non-limiting exemplary embodiment of the present invention. Description of examples of implementation

[0032] A method and a device for controlling a set of applications embedded in a vehicle will now be described in what follows with joint reference to Figures 1 to 6. The same elements are identified with the same reference signs throughout the description which follows.

[0033] The terms "first(s)", "second(s)" (or "first(s)", "second(s)"), etc. are used in this document by arbitrary convention to enable different elements (such as operations, means, etc.) implemented in the embodiments described below to be identified and distinguished. Such elements may be distinct or correspond to a single element, depending on the embodiment.

[0034] According to a particular and non-limiting example of embodiment of the present invention, the control of the execution or implementation of a set of applications em embedded in a vehicle, for example by one or more computers of the vehicle's on-board system, includes receiving a request to configure the set of applications. Such a request is for example received by a computer of the on-board system when one or more conditions of a current context of implementation of the applications vary (for example with the reception of a request to execute a new application, when vehicle resources are mobilized for the triggering of a new service, when the bandwidth available at the level of the network to which the vehicle is connected varies, etc.). Such a request includes second data representative of current available resources associated with the vehicle, for example computing resources, memory resources or network resources.For each application in the set of applications, a set of execution modes is determined from among a plurality of execution modes associated with each application in the set based on first data representative of the resource requirements associated with each execution mode and based on the second data. Information representative of a user acceptance level associated with each execution mode in the set of execution modes, called AXIL information (from the English . "Automotive eXperience Integrity Level" or in French "automotive experience integrity level"). This AXIL information is for example associated with each execution mode available for an application or is determined according to rules taking as input criteria parameters of a user profile and / or a current execution context of the set of applications. The AXIL information is used to select, for each application, an execution mode from the execution mode(s) determined for each application according to the first and second data. The execution of the set of applications is controlled according to the execution modes selected for the set of applications.

[0035] Such a method thus makes it possible to take into account a criterion relating to the user experience in the management or control of the execution of a set of on-board applications, thus making it possible to maximize the user experience depending on the applications to be operated in parallel according to the resources available at the vehicle level, in a given execution context. This thus makes it possible to ensure a certain level of quality of service as defined for example in a document of the SLA type (from the English “Service-Level Agreement” or in French “accord de niveau de service”) provided to the manufacturer or designer of an application.

[0036] Such a method also makes it possible to adapt the execution conditions (or "runtime" in English) of the applications on the basis of the available network and hardware capacities. The use of the AXIL level makes it possible, for example, to optimize the user experience. general by using, for example, degraded execution modes for some of the applications, rather than completely disabling one or more applications to allow other applications to run to provide the associated services.

[0037] The method thus makes it possible to execute more applications in parallel, even if it means operating some of these applications in a degraded mode acceptable to the user, the acceptance level being defined by the AXIL information.

[0038] This thus makes it possible to develop the vehicle from an application point of view by authorizing the implementation of more applications with the same hardware configuration of the vehicle.

[0039] [Fig. 1] schematically illustrates the electronic and electrical architecture, called E / E architecture, of a vehicle 10, according to a particular and non-limiting exemplary embodiment of the present invention.

[0040] The E / E architecture comprises a set of computers or ECUs 101, 102, 13 connected to each other by data buses to form a network mixing for example several technologies such as Ethemet (according to the ISO / IEC 802-3 standard) on the one hand and CAN (from the English “Controller Area Network” or in French “Réseau de contrôles”), CAN FD (from the English “Controller Area Network Flexible Data-Rate” or in French “Réseau de contrôles à débit de données flexible”), LIN (from the English “Local Interconnect Network”, or in French “Réseau interconnecté local”) or FlexRay (according to the ISO 17458 standard) on the other hand.

[0041] Such an architecture corresponds for example to a so-called ZOA architecture (from the English "Zonal Oriented Architecture" or in French "zone-oriented architecture"), such an architecture being service-oriented (or SOA, from the English "Service Oriented Architecture"). Such an architecture is known to those skilled in the art and is for example described in the document entitled "Making the Case for Centralized Automotive E / E Architectures" published by Victir Bandur, Gehan Selim, Vera Pantelic at Mark Lawford on February 2, 2021.

[0042] The set of computers comprises, for example, first computers, each illustrated by a white rectangle 101 in [Fig. 1], connected to each other by a backbone of the Ethernet type. These first computers correspond, for example, to HPC (High Performance Computing) type ECUs.

[0043] The set of computers further comprises second computers each illustrated by a gray rectangle 102 of dimensions smaller than the white rectangle 101 and third computers each illustrated by a black rectangle 103 of dimensions smaller than the gray rectangle 102. These second and third computers are connected to each other and to the first computers 101 to form networks of the CAN, CAN FD or LIN type for example, these first and second computers corresponding to specialized calculators and / or controlling actuators and / or sensors.

[0044] The services offered to a vehicle user and obtained via the implementation or execution of one or more applications share the Ethernet backbone despite the very varied needs in terms of QoS (Quality-of-Service). An entertainment application for streaming video (a best-effort application) thus does not have the same resource requirements as a real-time engine control application (a time-sensitive application), for example in terms of bandwidth, latency, jitter, loss rate, quality of service, computing load (CPU), memory footprint, etc.

[0045] Of course, the E / E architecture embedded in the vehicle 10 is not limited to the example above but extends to any type of architecture, for example a domain-oriented architecture or even a centralized architecture (with centralized gateway), such architectures also being described in the document entitled “Making the Case for Centralized Automotive E / E Architectures”.

[0046] A process for controlling a set of applications embedded in the vehicle for the vehicle 10 is advantageously implemented by one or more processors of one or more computers of the vehicle 10, for example a computer 101 of the E / E architecture of the vehicle 10 acting as a controller for example.

[0047] In a first operation of the process, a request to configure or reconfigure a set of applications is received. The set of applications comprises, for example, a plurality of applications currently running or being executed at the time the request is received.

[0048] The request is for example generated during a change of context at the level of the vehicle 10, for example a change of context at the level of the E / E architecture.

[0049] A change of context is for example detected when receiving a request to execute one or more new applications in addition to the application(s) already running. A request to execute a new application is for example received from a human-machine interface of the vehicle 10 when the request comes from a user wishing to implement one or more services via this new application. According to another example, a request to execute a new application is for example generated by a computer of the vehicle 10 controlling an AD AS (Advanced Driver-Assistance System) system of the vehicle 10. For example, the vehicle 10 can receive data via a V2X (Vehicle-to-Everything) type communication mode requiring the implementation of a particular service to optimize traffic by example, the implementation of the associated application being for example a priority over the "best effort" type applications. According to another example, a context change is detected when a component of the E / E architecture encounters a problem reducing for example the resources available for the implementation of the associated applications and services.

[0050] The configuration or reconfiguration request advantageously comprises second data representative of current resources available at the vehicle 10, for example in terms of available computing power, available memory size, available peripherals or even in terms of network resources (bandwidth, latency, jitter).

[0051] In a second operation of the process, the computer in charge of the process determines for each application of the set of applications (application(s) currently running when the request is received as well as the new application(s) and / or new service(s) whose implementation is required): - a set of execution modes from among a plurality of execution modes available for each application based on the first data representative of the resource requirements of each application and the second data representative of the available resources, and - information representative of a user acceptance level associated with each execution mode of the set of execution modes, called AXIL information.

[0052] Each application is configured to be implemented or executed according to a plurality of execution modes (from the English "runtime mode"), which are for example defined by the designer or developer of the application. Each execution mode is for example identified via a unique identifier (for example coded on 2 or more bits), the request for execution of an application advantageously comprising the information relating to the identification of the execution mode according to which the application must operate or be implemented.

[0053] The number of execution modes associated with or available for an application depends for example on the type of application and varies for example from one application to another.

[0054] The plurality of execution modes associated with a given application comprises at least 2 execution modes, namely: - a first mode corresponding to a so-called nominal or standard execution mode, such a first mode being representative of a mode according to which the application is executed to operate according to a reference performance level (all the services obtained by the application are implemented as expected); and - a second mode corresponding to a so-called deactivated execution mode according to which the application is not executed, that is to say that the execution of the application is postponed or simply canceled.

[0055] For at least some of the embedded applications, the plurality of available execution modes further comprises one or more additional execution modes, for example: - one or more degraded execution modes, i.e. the performance level obtained in such a degraded mode is lower than the reference performance level, i.e. only part of the services associated with the application is implemented, the quality of service is lower than the quality of service expected in the first execution mode, etc.; a degraded execution mode requires fewer resources than the nominal execution mode; and / or - one or more augmented execution modes, i.e. the performance level obtained in such an augmented mode is higher than the reference performance level, i.e. the quality of service is higher than the quality of service expected in the first execution mode; an augmented execution mode requires more resources than the nominal execution mode.

[0056] Taking a video streaming application as an example, the reference execution mode provides for example a video broadcast with a definition equal to 1080p, a first degraded mode provides a video broadcast with a definition equal to 720p, a second degraded mode provides a definition equal to 360p, a fourth degraded mode provides a definition equal to 144p, a fifth degraded mode provides for pausing the broadcast for a determined duration (for example 5 or 10 seconds), etc.

[0057] Taking as an example a content downloading application, an augmented execution mode provides for example a downloading of data with a higher throughput than the throughput provided in the nominal mode, such an augmented mode being for example implemented when the context allows it (available bandwidth) and in particular situations (for example before the vehicle enters an area without network coverage (for example a white zone, a tunnel)) so that the application can continue to operate while the vehicle crosses this area without network coverage.

[0058] Each execution mode is accompanied by initial data describing the requirements in terms of necessary resources (computing power, memory footprint, bandwidth, latency, jitter, etc.) for the implementation of the execution mode concerned.

[0059] Thus, each application is associated with a plurality of execution modes and each execution mode is associated with a list of necessary (minimum) resources for implementing the execution mode. This information, corresponding to the second data, is for example stored in a memory of the computer. implementing the process or in a memory of the computer implementing the application, for example in the form of one or more LUTs (from the English “Look-Up Table” or in French “correspondence table”). This information is for example recorded in the vehicle 10 during the installation of the associated application.

[0060] It is thus determined, for each application of the set of applications to be implemented, a list or a set of execution modes compatible (comprising at least one execution mode) with the resources available in the vehicle 10, knowing the first data providing the resources available according to the current execution context and the second data describing the resource requirements for each execution mode of the plurality of execution modes associated with each on-board application.

[0061] In this second operation, AXIL information is further determined for each application and for each execution mode of the set of execution modes compatible with the current context of the E / E architecture.

[0062] This AXIL information is for example obtained from the application itself or from a memory, this information being for example stored in a LUT opposite each execution mode of the plurality of execution modes available for each application embedded in the vehicle 10.

[0063] According to an alternative embodiment, this AXIL information is determined according to a calculation rule associated with each execution mode of the plurality of execution modes available for each application embedded in the vehicle 10. These calculation rules are each a function of particular parameters which depend for example on each application and / or the type of application.

[0064] The AXIL information corresponds for example to a level of acceptance by the use of an execution mode in a particular context, this level belonging to a defined set of levels comprising for example 5 levels: level 'QM' (a user does not attach importance to such an execution mode, even if the latter corresponds to a degraded mode), level 'A' (a user can feel a difference compared to the nominal mode but accepts it without problem), level 'B' (some users feel frustration for the implementation according to this execution mode), level 'C' (many users feel frustration for the implementation according to this execution mode) and level 'D' (unacceptable execution mode in terms of user experience).

[0065] The AXIL level associated with each execution mode is for example determined during the development or design of the execution mode, this AXIL level then being fixed and static over time. Such a static level represents for example an average user.

[0066] According to another example, the AXIL level is determined dynamically from rules taking into account a set of parameters or criteria such as parameters of a user profile (for example the age of the user, the interests of the user, the habits of the user, a history of use of the application including in particular a frequency of use of the application, a history of use of degraded execution modes, a subscription level, etc.) and / or context parameters (for example conditions for accepting an execution mode, a link or a dependency with other applications, etc.).

[0067] The AXIL level is for example determined according to evaluation criteria corresponding for example to the following criteria: - a first criterion representative of a level of ease in ensuring a function without assistance of each application in the execution mode considered, that is to say the ease with which the user can do without the service offered by the application while succeeding in implementing the function, this first criterion taking for example 3 levels (levels SI to S3, SI meaning that the user can do without the application easily, S2 moderately and S3 difficultly): for example for a parking assistance application, the unavailability of the reversing camera does not prevent an average user from carrying out the parking maneuver without assistance from the camera, or again, if the quality of music rendering of an application for streaming audio content is poor, the user can temporarily use his smartphone connected via Bluetooth® to the vehicle 10 to listen to music; - a second criterion representative of a rate of use of each application in the execution mode considered (comprising for example 4 levels El to E4, with El for a minimal and low frequency of use and E4 a maximum and very high frequency); and - a third criterion representing a level of perceived quality of service for each mode of execution (comprising for example 4 levels Q1 to Q4, with level Q1 corresponding to 'frustrating', level Q2 corresponding to 'boring', level Q3 corresponding to 'acceptable' and level Q4 to 'pleasant').

[0068] Table 20 illustrated in [Fig.2] provides an example of assignment of AXIL levels to each execution mode of an application according to the 3 evaluation criteria defined above, the 'SUBSTITUTION' column corresponding to the first criterion, the 'USE' column corresponding to the second criterion and the 'QUALITY OF SERVICE' column corresponding to the third criterion.

[0069] When the AXIL level is determined according to calculation rules, the 3 criteria defined above are for example determined dynamically from rules defined for each criterion, the AXIL level then being calculated as a function taking into account input the value obtained for each of the 3 criteria and providing as output an AXIL value for example between 0 and 1 (floating value).

[0070] An example of a process for determining the AXIL information or level is illustrated in [Fig.3], according to a particular embodiment.

[0071] In an operation 31, when a change of context is detected at the level of the E / E infrastructure (request to execute a new application, launch of a new service, detection of an event impacting the available resources), a request is transmitted to each application currently running to request the available execution modes, the resource requirements associated with each execution mode and the associated AXIL levels.

[0072] In an operation 32, the available execution modes and the associated resource requirements are received in response to the request transmitted to the operation 31. This information is for example received from a related component associated with each application.

[0073] In an operation 33, the AXIL level is determined. When the AXIL level corresponds to fixed information received from the application (for example in the form of metadata) or from a table stored in a memory, the determined AXIL level corresponds to that received, which corresponds for example to an average user.

[0074] When the AXIL level is dynamic, the information relating to the AXIL level received from the application corresponds for example to rule parameters (parametric equations for example) so that the AXIL levels are calculated, for each execution mode.

[0075] Information 310 representative of an execution context for each execution or operating mode of the application is further received.

[0076] The AXIL level is thus defined as a function of the context information 310, of parameters 330 representative of a user profile and / or of the context of use of the application. According to a variant, data 34 representative of a history of the application (for example the execution modes already used) are further taken into account for the determination of the AXIL level.

[0077] An AXIL 331 level is thus determined dynamically.

[0078] According to a variant, one or more additional parameters are determined in operation 31, such that: - a parameter 332 representative of a minimum switching duration for changing execution mode, the minimum switching duration being a function of the current execution context 310 of each application; the current context of an application may impact a required change of execution mode, for example when tasks are being executed and they must not be interrupted (for example when the downloading of a file is in progress, when the vehicle 10 performs a maneuver under the supervision of an AD AS module controlled by the application (for example, an insertion on a motorway lane), etc.); and / or - a parameter 333 representative of an energy consumption by each application in the selected execution mode: an estimate of the energy needs is for example implemented to provide them to the infrastructure, these needs being a function of the resource needs associated with each execution mode (network resource needs and / or computing power). The information 333 relating to the energy consumption needs of each execution mode is for example used to select one execution mode rather than another, for example when the vehicle 10 has been configured (via an HMI for example) to travel in an energy saving mode with for example a maximum energy consumption setpoint not to be exceeded.

[0079] The input parameters 310, 330, 34 are useful for providing or calculating an AXIL level depending on the context and the user profile, when the AXIL level is determined dynamically. For example, if an application must interrupt for 't' seconds at a time instant 'T' (depending on the resources available over this interval) but the application has already been interrupted 'n' seconds ago (information obtained from the usage history or the history of the execution modes used), a new interruption would imply an AXIL level defined by a function 'F taking into consideration the parameters 't', 'T' and 'n' (function f(t,T,n))

[0080] In a third operation of the process, an execution mode is selected from the set of execution modes meeting the criteria of the available resources based on the AXIL information obtained in the second operation, for each application of the set of applications.

[0081] The selection of execution modes for the application set is implemented taking into account the AXIL levels in order to optimize the AXIL level for the application set and maximize the user experience.

[0082] Such a process is illustrated according to a particular exemplary embodiment in [Fig.4].

[0083] Elements 41 to 44 of [Fig.4] correspond for example to modules or hardware or functional bricks of one or more hardware components, for example an ECU, of the vehicle infrastructure 10.

[0084] The constraints of the E / E infrastructure are provided by one or more controllers 41 of the E / E infrastructure of the vehicle 10 when a change of state of the infrastructure is required. These constraints of the E / E infrastructure of the vehicle 10 include for example: - a description of the physical topology of the vehicle infrastructure 10 (e.g. the list of ECUs, the topology of the network connecting the ECUs, the capabilities of each network link, computing (CPU) and memory capacities, etc.); - one or more lists of constraints that must be respected when a configuration is selected, for example: • a valid network configuration must be found before changing the infrastructure state, • the total energy consumption of a new configuration must respect a maximum value (threshold) set (for example by a user of vehicle 10), and • a part of the bandwidth must remain available (for example 10 Mbit / s) in all network links.

[0085] A module 42 corresponding to an application planner or controller transmits one or more requests to a module 43 configured to determine which execution modes best meet the various constraints. A request transmitted by the module 42 to the module 43 includes, for example, a list of applications to be implemented.

[0086] Module 43 controls the selection of execution modes for the list of applications to be implemented or executed, in particular based on the constraints received from module 41.

[0087] The module 43 notably comprises a (software) brick 433 configured to optimize the AXIL level of the new required configuration. This brick 433 requires, for example, from each application 431 the available execution modes with the associated resource requirements and the AXIL level (or the calculation rules for determining the AXIL level for each execution mode). Each application 431 transmits to a brick 432 the information relating to the execution context of the application with the calculation rules, the brick 432 determining for each application and each execution mode an AXIL level (for example as described with regard to [Fig. 3]). These AXIL levels are provided to the brick 433 to select an execution mode for each application so as to optimize the AXIL level for all the applications.

[0088] Brick 433 implements an optimization to find an optimal compromise between the AXIL levels of the execution modes allowing the constraints to be respected, or decides to deactivate one or more applications having a lower AXIL level (for example a 'QM' or 'A' level).

[0089] The brick 433 transmits as output a list of execution modes for the set of applications (1 execution mode per application) to a module 44 controlling the configuration of the applications, which module 44 transmits to each application brick 431 the execution mode to be activated or executed.

[0090] If no solution is found by the brick 433, an error status is returned. A new configuration is then sought by the module 42, for example by reducing the number of applications to be executed (a message is for example displayed on a screen of the vehicle 10 to ask the user to choose a reduced number of applications to be implemented).

[0091] A new configuration determined by the brick 433 takes for example the form of a matrix with a column for each application of the set of applications and a row for each available execution mode, the matrix comprising the AXIL levels for each application and each execution mode, the selected execution modes being identified in the matrix (for example by a pair of identifiers Column number / Row number).

[0092] In a fourth operation of the process, the execution of the set of applications is controlled according to the selected execution modes, as described above with respect to [Fig. 4]. Each application of the set of applications receives an execution request according to the execution mode selected for this application (according to the nominal execution mode, according to a degraded or augmented mode or according to the deactivated execution mode).

[0093] To illustrate the process below, an example is considered in which the vehicle has the following 4 applications: - a video content streaming application (rated N) with 5 execution modes: 1080p mode, 720p mode, 360p mode, 144p mode, '5-second pause' mode and stop mode; - an audio streaming application (rated M) with 4 execution modes: 'high quality' mode, 'low quality' mode, 'interrupt for 5 seconds' mode and stop mode; - a driving assistance application, for example for traffic optimization with V2X data communication (noted V) with 2 execution modes: active mode (application activated in nominal mode) and stop mode (application stopped); and - a game application (rated G) with 3 execution modes: active mode, pause (or interruption) mode and stop mode.

[0094] Each execution mode has its own requirements in terms of computing resources (CPU, memory, peripherals) and network resources (flows, bandwidth usage, priority level).

[0095] When starting the vehicle 10, the user requests the execution of the application M and a passenger requests the execution of the application G. The current state 'S' of the vehicle 10 defined by the applications to be executed is thus S={M, G}. The infrastructure then requires the brick 433 to determine the optimal execution modes for S according to the current constraints of the E / E infrastructure.

[0096] Brick 433 determines for example that application M can be executed according to the nominal mode (1080p mode) and that application G can also be executed according to nominal mode (active mode).

[0097] During the journey of the vehicle 10, an intersection is reached and the vehicle 10 detects that the intersection benefits from traffic control equipment using a V2X service. A request to execute the application V is then generated by the vehicle 10 (for example by the module 42) and the brick 433 receives a request to determine which execution modes for the state S = {M, G, V] are possible, according to the current constraints and the AXIL levels determined for each execution mode.

[0098] This results, for example, in the execution of applications M and V in their optimal mode and in the execution of application G in the degraded mode known as pause mode while the vehicle 10 passes the intersection and application V is no longer necessary.

[0099] [Fig. 5] schematically illustrates a device 5 configured to control a set of applications embedded in a vehicle, for example the vehicle 10, according to a particular and non-limiting exemplary embodiment of the present invention. The device 5 corresponds for example to a device embedded in the vehicle 10, for example a computer.

[0100] The device 5 is for example configured for the implementation of the operations described with regard to figures 1 to 4 and / or the steps of the method described with regard to [Fig.6]. Examples of such a device 5 include, but are not limited to, on-board electronic equipment such as an on-board computer of a vehicle, an electronic calculator such as an ECU (“Electronic Control Unit”), a TCU (Telematic Control Unit) or any data processing device of an on-board vehicle system. The elements of the device 5, individually or in combination, can be integrated in a single integrated circuit, in several integrated circuits, and / or in discrete components. The device 5 can be produced in the form of electronic circuits or software (or computer) modules or even a combination of electronic circuits and software modules.

[0101] The device 5 comprises one (or more) processor(s) 50 configured to execute instructions for carrying out the steps of the method and / or for executing the instructions of the software(s) embedded in the device 5. The processor 50 may include integrated memory, an input / output interface, and various circuits known to those skilled in the art. The device 5 further comprises at least one memory 51 corresponding for example to a volatile and / or non-volatile memory and / or comprises a memory storage device which may comprise volatile and / or non-volatile memory, such as EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, magnetic or optical disk.

[0102] The computer code of the embedded software(s) comprising the instructions to loaded and executed by the processor is for example stored in memory 51.

[0103] According to various particular and non-limiting embodiments, the device 5 is coupled in communication with other similar devices or systems and / or with communication devices, for example a TCU (from the English “Telematic Control Unit” or in French “Telematic Control Unit”), for example via a communication bus or through dedicated input / output ports.

[0104] According to a particular and non-limiting exemplary embodiment, the device 5 comprises a block 52 of interface elements for communicating with external devices. The interface elements of the block 52 comprise one or more of the following interfaces: - RF radio frequency interface, for example Wi-Fi® type (according to IEEE 802.11), for example in the 2.4 or 5 GHz frequency bands, or Bluetooth® type (according to IEEE 802.15.1), in the 2.4 GHz frequency band, or Sigfox type using UBN (Ultra Narrow Band) radio technology, or LoRa in the 868 MHz frequency band, LTE (Long-Term Evolution), LTE-Advanced; - USB interface (from the English “Universal Serial Bus” or “Universal Serial Bus” in French); - HDMI interface (from the English “High Definition Multimedia Interface” or “High Definition Multimedia Interface” in French); - LIN interface (from the English “Local Interconnect Network”).

[0105] According to another particular and non-limiting embodiment, the device 5 comprises a communication interface 53 which makes it possible to establish communication with other devices (such as other computers of the on-board system) via a communication channel 530. The communication interface 53 corresponds for example to a transmitter configured to transmit and receive information and / or data via the communication channel 530. The communication interface 53 corresponds for example to a wired network of the CAN (Controller Area Network) type, CAN FD (Controller Area Network Flexible Data-Rate), FlexRay (standardized by the ISO 17458 standard) or Ethernet (standardized by the ISO / IEC 802-3 standard).

[0106] According to a particular and non-limiting exemplary embodiment, the device 5 can provide output signals to one or more external devices, such as a display screen, touch-sensitive or not, one or more speakers and / or other peripherals via respective output interfaces.

[0107] [Fig.6] illustrates a flowchart of the different steps of a method for controlling a set of applications embedded in a vehicle, for example the vehicle 10, according to a particular and non-limiting exemplary embodiment of the present invention. The method is for example implemented by a device embedded in the vehicle 10 or by the device 5 of [Fig.5].

[0108] In a first step 61, a configuration request for the set of applications is received, the request comprising second data representative of current available resources associated with the vehicle.

[0109] In a second step 62, it is determined for each application of the set of applications: • a set of execution modes in the plurality of execution modes associated with each application of the set of applications based on first data representative of resource requirements associated with each execution mode of the plurality of execution modes and the second data, the set of execution modes comprising at least one execution mode, and • information representative of the user acceptance level associated with each execution mode of the set of execution modes, called AXIL information.

[0110] In a third step 63, an execution mode is selected from the set of execution modes based on the AXIL information for each application in the set of applications.

[0111] In a fourth step 64, the execution of the set of applications is controlled according to the selected execution modes.

[0112] According to a variant, the variants and examples of the operations described in relation to figures 1 to 4 apply to the steps of the method of [Fig.6].

[0113] Of course, the present invention is not limited to the exemplary embodiments described above but extends to a method for optimizing the user experience with respect to the implementation of applications in a vehicle which would include secondary steps without thereby departing from the scope of the present invention. The same would apply to a device configured for the implementation of such a method.

[0114] The present invention also relates to a vehicle, for example an automobile or more generally an autonomous land-based motor vehicle, comprising the device 5 of [Fig.5].

Claims

Claims

1. Method for controlling a set of applications embedded in a vehicle (10), a plurality of execution modes being associated with each application of said set of applications, first data representative of resource requirements being associated with each execution mode of said plurality of execution modes, said method comprising the following steps: - receiving (61) a configuration request for said set of applications, said request comprising second data representative of current available resources associated with said vehicle (10);- determination (62), for each application of said set of applications, of: • a set of execution modes in said plurality of execution modes as a function of said first and second data, said set of execution modes comprising at least one execution mode, and • information representative of user acceptance level associated with each execution mode of said set of execution modes, called AXIL information (331); - selection (63), for each application of said set of applications, of an execution mode in said set of execution modes as a function of the AXIL information (331); - control (64) of execution of said set of applications as a function of the selected execution modes.;

2. The method of claim 1, wherein said plurality of execution modes associated with said each application comprises a nominal execution mode representative of a mode in which said each application is executed to operate at a reference performance level, a disabled execution mode in which said each application is not executed, and at least one additional execution mode in which said each application is executed to operate in a degraded mode with a performance level lower than said reference performance level or in an augmented mode with a performance level higher than said reference performance level.

3. A method according to claim 1 or 2, wherein said information AXIL (331) is determined from: - metadata representative of a user acceptance level associated with each execution mode of said plurality of execution modes; and / or - rules for calculating said user acceptance level associated with each execution mode of said plurality of execution modes as a function of a set of user profile parameters and / or execution context parameters (330).

4. Method according to claim 3, for which said user acceptance level is a function of a set of evaluation criteria comprising: - a first criterion representative of a level of ease of ensuring an unassisted function of said each application; - a second criterion representative of a rate of use of said each application; and - a third criterion representative of a level of perceived quality of service for said each execution mode.

5. Method according to one of claims 1 to 4, for which said execution control is furthermore a function of: - a parameter (332) representative of a minimum switching duration for changing execution mode, said minimum switching duration being a function of a current execution context of said each application; and / or - a parameter (333) representative of an energy consumption by said each application in said selected execution mode.

6. Method according to one of claims 1 to 5, for which the resources of the resource requirements and the current resources belong to a set of resources comprising: - computing resources; - memory resources; and - network resources.

7. A computer-readable recording medium on which is recorded a computer program comprising instructions for carrying out the steps of the method according to any one of claims 1 to 6.

8. Computer program comprising instructions for implementing the method according to any one of claims 1 to 6, when these instructions are executed by a processor.

9. Device (5) for controlling a set of applications embedded in a vehicle, said device (5) comprising a memory (51) associated with at least one processor (50) configured for implementing the steps of the method according to any one of claims 1 to 6.

10. Vehicle (10) comprising the device (5) according to claim 9.

Images