Method and device for controlling applications embedded in a vehicle

Abstract

The present invention relates to a method and a device for controlling a set of applications embedded in a vehicle, a plurality of execution modes being associated with each application, resource requirements and local scores being associated with each execution mode. For this purpose, a configuration request for the set of applications is received (61). Global scores associated with each execution mode are determined (62) from the local scores and weights making it possible to prioritize the execution modes. One or more execution modes are determined (63) for each application according to the resource requirements and the available resources. A user acceptance level associated with each execution mode is further determined from the global scores. An execution mode is selected (64) according to the user acceptance levels.The execution of the application set is controlled (65) according to the selected execution modes. Figure for 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 using 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 par lien radio”), the vehicles having a communication system configured to communicate via a wireless network with one or several remote devices 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. In addition, such a situation depends on the ecosystem of applications embedded in the vehicle, that is to say all the applications present or installed in the system or in an embedded subsystem of the vehicle.

[0007] Another problem that arises is to manage embedded applications when machine resources are insufficient in a manner acceptable from the user's point of view while the expectations of one user to another may be different. Summary of the present invention

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

[0009] Another object of the present invention is to improve the operation of applications embedded in a vehicle according to their ecosystem.

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

[0011] 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 and second data representative of at least one local rating attributed to a user experience being associated with each execution mode of the plurality of execution modes, the method being implemented by at least one processor and comprising the following steps: - receiving a configuration request for the set of applications, the request comprising third data representative of current available resources associated with the vehicle; - determination of fourth data representative of at least one overall score associated with each execution mode in the plurality of execution modes from the second data and data representative of a set of at least one weight; - determination, for each application of the set of applications, of: • a set of execution modes in the plurality of execution modes based on the first and third 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 level, based on the fourth data; - selection, for each application in the set of applications, of an execution mode in the set of execution modes according to the AXIL levels; - execution control of the set of applications according to the selected execution modes.

[0012] Such a method makes it possible to select one or more execution modes for each application to be implemented by the vehicle as a function of the set of applications, the resource requirements associated with this or these execution modes and as a function of 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 user experience criterion 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 while the introduction of weights makes it possible to prioritize the relative importance of each application in relation to the set of applications.

[0013] According to a variant, the set of at least one weight is determined for each execution mode of each application relative to the set of applications.

[0014] According to another variant, the set of at least one weight is associated with a user profile.

[0015] According to another variant, the method further comprises a step of receiving data representative of a user evaluation, the set of at least one weight being determined by a weight prediction model from the data representative of a user evaluation.

[0016] According to an additional variant of the method, the at least one local score and the at least one global score each comprise 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 mode of execution of each application.

[0017] According to yet another variant of the method, the determination step is implemented by a remote server, the fourth data being sent by the remote server to a computer on board the vehicle.

[0018] 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.

[0019] 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.

[0020] According to a fourth aspect, the present invention relates to a system comprising a vehicle as described above according to the third aspect of the present invention and a server, the system being configured for implementing the steps of the method according to the first aspect of the present invention.

[0021] According to a fifth 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.

[0022] 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.

[0023] According to a sixth 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.

[0024] 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.

[0025] On the other hand, 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 terrestrial radio or by self-directed laser beam or by other means. The computer program according to the present invention can in particular be downloaded from an Internet-type network.

[0026] Alternatively, the recording medium may be an integrated circuit in which the computer program is incorporated, the integrated circuit being adapted to perform or to be used in performing the method in question. Brief description of the figures

[0027] 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 7, in which:

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

[0029] [Fig.2] schematically illustrates a table defining a set of levels user acceptance 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;

[0030] [Fig.3] schematically illustrates a level determination process user acceptance 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;

[0031] [Fig.4] schematically illustrates an acceptance level optimization process user 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;

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

[0033] [Fig.6] illustrates a flowchart of the different stages of a control process of a set of applications embedded in the vehicle of [Fig.l], according to a particular and non-limiting exemplary embodiment of the present invention; and

[0034] [Fig.7] schematically illustrates a process of generating the table of [Fig.2], according to particular and non-limiting exemplary embodiments of the present invention. Description of the exemplary embodiments

[0035] 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 7. The same elements are identified with the same reference signs throughout the description which follows.

[0036] 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.

[0037] 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 embedded in a vehicle, for example by one or more computers of the embedded system of the vehicle, comprises the reception of a configuration request for the set of applications. Such a request is for example received by a computer of the embedded 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 resources of the vehicle 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 comprises third data representative of current available resources associated with the vehicle, for example computing resources, memory resources or network resources. For each application of the set of applications, a set of execution modes is determined from among a plurality of execution modes associated with each application of the set based on first data representative of the resource requirements associated with each execution mode and based on the third data. Information representative of a user acceptance level associated with each execution mode of the set of execution modes, called the AXIL level (from the English “Automotive eXperience Integrity Level” or in French “automotive experience integrity level”), is also determined.This AXIL level is determined based on fourth data representing overall scores associated with each execution mode determined from second data representing at least one local score attributed to a user experience associated with each execution mode and weights, also called weighting factors, the weights making it possible to put the execution modes of the applications into perspective in relation to the set of applications. This AXIL level is determined based on rules also taking as input criteria parameters of a user profile and / or a current execution context of the set of applications. The AXIL level is used to select, for each application, an execution mode from the execution mode(s) determined for each application. The execution of the set of applications is controlled according to the execution modes selected for the set of applications.

[0038] Such a method thus makes it possible to take into account a criterion relating to the user experience and / or to an ecosystem of applications embedded in the vehicle in the management or control of the execution of a set of embedded applications, thus making it possible to maximize the user experience according to 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.

[0039] 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 capabilities. The use of the AXIL level makes it possible, for example, to optimize the general user experience by using, for example, degraded execution modes for some of the applications, rather than completely disabling one or more applications to allow the other applications to run to provide the associated services. In addition, the AXIL level is determined by weighting for each application, for example according to the other embedded applications then forming the ecosystem of applications, and / or according to a user profile.

[0040] 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 level.

[0041] 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.

[0042] [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.

[0043] The E / E architecture comprises a set of computers or ECUs 101, 102, 103 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.

[0044] 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.

[0045] 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.

[0046] The set of computers further comprises second computers, each illustrated by a gray rectangle 102 with dimensions smaller than the white rectangle 101, and third computers, each illustrated by a black rectangle 103 with 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 computers and / or controlling actuators and / or sensors.

[0047] 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.

[0048] 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”.

[0049] 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.

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

[0051] 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.

[0052] 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 being executed. 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 system (from the English “Advanced Driver-Assistance System” or in French “Système d’aide à la conduite avance”) of the vehicle 10.For example, the vehicle 10 may receive data via a V2X (Vehicle-to-Everything) type communication mode requiring the implementation of a particular service to optimize traffic, for example, the implementation of the associated application being, for example, a priority over the “best effort” type applications. According to another example, a change of context is detected when a component of the E / E architecture encounters a problem, for example reducing the resources available for the implementation of the associated applications and services.

[0053] The configuration or reconfiguration request advantageously comprises third 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).

[0054] In a second operation of the process, as illustrated in [Fig.7], the computer in charge of the process determines fourth data representative of at least one overall score 76 associated with each execution mode in a plurality of execution modes associated with each application 431 of the set of applications from the second data and data representative of a set of at least one weight 74, also called a weighting factor.

[0055] According to a particular exemplary embodiment, the set of at least one weight 74 is determined for each execution mode of each application 431 with respect to the set of applications installed in the on-board system of the vehicle 10 or with respect to a set of applications available on a platform for downloading or obtaining applications. The set of applications installed in the system on-board the vehicle 10 or available on a platform for downloading or obtaining applications is subsequently called an ecosystem.

[0056] Indeed, for each execution mode, the developer of an application 431 defines local scores 75, also called local UX values, to describe the execution priority of each mode compared to the other modes. These local scores 75 are not taken into account in the ecosystem and are therefore not directly usable because they do not take into account the real interactions between several applications of the ecosystem in the vehicles.

[0057] It is then, for example, the manufacturer of the vehicle 10 who defines the weights 74 to be assigned to each of the local scores 75. These weights 74 are combined, for example, multiplied or combined using a function defined by user experience experts, called UX experts, with the local scores 75 to obtain global scores 76, also called global UX values. The weights 74 are representative of information on the overall use of each application 431 and its execution modes in relation to the ecosystem.For example, if a first application is used twice as often as another, the local scores of this first application are weighted with one or more weights greater than that or those weighting the local scores of the second application, thus making it possible to obtain global scores associated with the first application higher than global scores associated with the second application, the first application thus becoming a priority in its execution compared to the second application.

[0058] Various methods can be used to define these weights 74 or weighting factors: One method involves modeling by experts such as engineers, marketing specialists, and / or user experience researchers. Weights 74 for individual apps, but also for entire app categories, are defined based on assumed user expectations. For example, navigation apps should have a higher priority than infotainment apps.

[0059] A second method consists of establishing user surveys and using traditional user experience research techniques, also called UX research, such as regular targeted surveys of a set of users 71. Such a second method thus makes it possible to construct different user profiles, thus forming a set of user profiles 72, and to determine weights for each user profile in the set of user profiles 72. Thus, at least one weight 74 is associated with a user profile 73. The user profile 73 represents, for example, the preferences or expectations of the driver or a passenger of the vehicle 10, the weights 74 associated with this user profile 73 then make it possible to determine overall scores associated with each execution mode in the plurality of execution modes associated with each application 431 of the set of applications. Passengers can thus define preferences when developing their profile, for example on a human-machine interface, called HMI, on board the vehicle 10 or via a mobile communication device connected in communication with the vehicle 10 such as a smartphone or a laptop. The preferences take, for example, the form of questions created by automobile manufacturers to evaluate user preferences. These questions can take any form. For example, they can take the form of a rating of 1 to 5 stars for each category of applications, for example, navigation, infotainment, applications for children, ADAS functions, etc., 5 meaning "extremely important to me" and 1 meaning "not important to me".Furthermore, the user can define favorite applications or functions that should operate at their maximum capabilities, i.e., in the optimal execution mode of the plurality of execution modes, i.e., in a nominal or augmented execution mode as described below. Using, for example, the personal information of the driver or passenger of the vehicle 10 such as age, gender, and previously defined preferences, the users are represented in an N-dimensional space, where N is the number of personal data parameters. The population is therefore represented as a scatter plot, with users with similar profiles and interests being placed closer together in the scatter plot. The users are then divided into user groups (in English "clusters") using existing techniques such as K-Means or spatial embedding techniques.The number of clusters and the grouping objectives are left to the discretion of vehicle manufacturers or application integrators within the framework of the present invention.

[0060] It is also possible to combine the first and second methods. For each user group, vehicle manufacturers or application integrators conduct separate user studies to define their own aggregate usability metrics. The number of clusters is therefore a compromise between user personalization and logistical complexity. Weights generated from aggregate usability metrics for each group are applied to the local ratings or local UX values ​​of each application.

[0061] The first and second methods can, however, be tedious, requiring significant engineering and research efforts and, consequently, pose scalability problems. A third method is then proposed. This third method consists, for example, of determining initial local notes according to the first and / or the second method, these initial local notes being able to be approximate. Occasionally, for example at random times, at the end of a journey or at any other time decided by the vehicle manufacturer or application integrator, the driver or passenger of a vehicle is invited to evaluate their current experience by assigning a rating of 1 to 5 stars representative of their level of satisfaction, or even by assigning a rating to a specific aspect of their current experience. The assigned rating thus includes data representative of a user evaluation which is sent to a server and associated with the current state of the vehicle, i.e. the active application combinations, the previously active execution modes, the type of journey of the vehicle, the environmental context, etc., the rating assigned by the user and the associated current state of the vehicle then being represented as a point in a scatter plot.Optionally, vehicle manufacturers or application integrators may ask further questions following their evaluation to obtain additional details such as suggestions for improvement, preferences, etc. As a result, the point cloud is continuously enriched via the collection of feedback from a population of users. Different points of the point cloud are then grouped by user profiles of the set of user profiles 72. Following the receipt of data representative of a user evaluation, the set of at least one weight 74 is determined by a weight prediction model from the data representative of a user evaluation, i.e. from the points of the point cloud.An algorithm implemented in the weight prediction model predicts the best weights 74 based on the large amount of data associated with a user profile 73, the best weights 74 statistically leading to the best user rating. This can typically be solved using machine learning models, classification algorithms, or a combination of both. This weight prediction model produces at least one weight or even a collection of weights for different vehicle states and user profiles. These weights can be customized for each user or generalized into groups as in the previously discussed methods.

[0062] One or more of these methods are used to create overall usage metrics to assess the relative priorities of an application 431 relative to the ecosystem. Using a free description format, the weights 74 can be freely established for applications or execution modes, either individually or by group of applications, for example, a group of applications grouping applications by theme or by use.

[0063] According to a particular exemplary embodiment, this second operation of determining the fourth data is implemented by a remote server, the fourth data being transmitted by the remote server to a computer on board the vehicle 10. Thus, the remote server is for example in communication via a wireless link with the vehicle 10. This particular embodiment is particularly preferred in the case of the third method, which uses the point cloud generated from data acquired from users of other vehicles. Indeed, the remote server plays a central role, it thus collects the data and predicts the best weights from this data. These best weights are applied to the initial local scores or to local scores determined during previous iterations to obtain overall scores. Only the overall scores are transmitted to the vehicle 10, the collected data are then protected because they are not transmitted to different vehicles.

[0064] According to another particular exemplary embodiment, for each application 431, at least one local score 75 and at least one global score 76 each comprise a set of evaluation criteria comprising: - a first criterion, SL for a local score, SG for an overall score, representative of a level of ease for the user to perform a function without assistance from the application 431 in all the execution modes or in the execution mode considered, the first criterion SG also being called 'SUBSTITUTION', that is to say the ease with which the user can do without the service offered by the application while still managing to implement the function, this first criterion taking for example 3 levels (levels SI to S3, SI meaning that the user can easily do without the application, S2 moderately and S3 with difficulty): for example for a parking assistance application, the unavailability of the reversing camera does not prevent an average user from performing 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, EL for a local score, EG for an overall score, representative of a rate of use of the application 431 in all the execution modes or in the execution mode considered, also called 'USE' or in English 'EXPOSURE', 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, QL for a local rating, QG for an overall rating, representative of a level of quality of service perceived for each mode of execution of the application 431, also called 'QUALITY OF SERVICE', 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'.

[0065] In a third 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 as a function of the first data representative of the resource requirements associated with each execution mode of the plurality of execution modes and the third data representative of the current resources available associated with the vehicle 10, and - information representative of a user acceptance level associated with each execution mode of the set of execution modes, called AXIL level.

[0066] 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.

[0067] 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.

[0068] 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 in which the application is not executed, i.e. the execution of the application is postponed or simply cancelled.

[0069] 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 performance level reference, i.e. only part of the services associated with the application are 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.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] 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 first 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 (Look-Up Tables). This information is for example recorded in the vehicle 10 during the installation of the associated application.

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

[0075] In this third operation, an AXIL level 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.

[0076] This AXIL level 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.

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

[0078] 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.).

[0079] According to the particular embodiment described above in which each application 431 comprises at least one local score 75 and at least one global score 76 each comprising a set of three evaluation criteria, the global AXIL level is for example determined as a function of: • the first SG evaluation criterion representative of a level of ease for the user to ensure a function without assistance of each application in the execution mode considered, • the second EG criterion representative of a rate of use of each application in the execution mode considered; and • the third QG criterion representative of a level of perceived quality of service for each execution method.

[0080] 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 'SG' column corresponding to the first criterion, the 'EG' column corresponding to the second criterion and the 'QG' column corresponding to the third criterion.

[0081] 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 as 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).

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

[0083] 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.

[0084] 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.

[0085] In an operation 33, the AXIL level is determined. 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.

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

[0087] The AXIL level is thus defined according to the overall scores 76, the context information 310 and 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 also taken into account for the determination of the AXIL level. An AXIL level 331 is thus determined dynamically.

[0088] According to a variant, one or more additional parameters are determined at operation 33, 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 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 highway lane), etc.) ;and / or - a parameter 333 representative of an energy consumption by each application in the selected execution mode: an estimation of the energy requirements is for example implemented to provide them to the infrastructure, these requirements being a function of the resource requirements associated with each execution mode (network resource requirements and / or computing power requirements). The information 333 relating to the energy consumption requirements 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.

[0089] The input parameters 310, 330, 34 are useful for providing or calculating an AXIL level depending on the context and the user profile. 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)).

[0090] In a fourth 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 third operation, for each application of the set of applications.

[0091] 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.

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

[0093] 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.

[0094] 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 (for example the list of ECUs, the topology of the network connecting the ECUs, the capacities of each network link, the capacities in terms of calculation (CPU) and memory, etc.); - one or more lists of constraints which 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.

[0095] 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.

[0096] 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 4L.

[0097] 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 making it possible to determine 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 such that described with respect to [Fig.3]). These AXIL levels are provided to brick 433 to select an execution mode for each application so as to optimize the AXIL level for all applications.

[0098] 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).

[0099] 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.

[0100] 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).

[0101] 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).

[0102] In a fifth 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).

[0103] 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 (denoted V) with 2 execution modes: active mode (application activated in nominal mode) and stop mode (application stopped); and - a game application (denoted G) with 3 execution modes: active mode, pause (or interruption) mode and stop mode.

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

[0105] 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.

[0106] 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 the nominal mode (active mode).

[0107] 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.

[0108] 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.

[0109] [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.

[0110] The device 5 is for example configured for the implementation of the operations described with regard to figures 1 to 4 and 7 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 system of vehicle. The elements of the device 5, individually or in combination, can be integrated into a single integrated circuit, into several integrated circuits, and / or into 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.

[0111] 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.

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

[0113] 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.

[0114] 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”).

[0115] According to another particular and non-limiting exemplary 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).

[0116] 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.

[0117] [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].

[0118] A plurality of execution modes is associated with each application 431 of the set of applications, first data representative of resource requirements being associated with each execution mode of the plurality of execution modes and second data representative of at least one local rating 75 attributed to a user experience being associated with each execution mode of the plurality of execution modes. The method comprises the following steps.

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

[0120] In a second step 62, fourth data are determined from the second data and data representative of a set of at least one weight 74. The fourth data are representative of at least one overall score 76 associated with each execution mode in the plurality of execution modes.

[0121] In a third step 63, it is determined for each application of the set of applications: • a set of execution modes in said plurality of execution modes as a function of the first and third 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 331 level, based on the fourth data.

[0122] In a fourth step 64, for each application of the set of applications, an execution mode is selected from the set of execution modes according to the AXIL levels 331.

[0123] In a fifth step 65, the execution of the set of applications is controlled according to the selected execution modes.

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

[0125] 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.

[0126] 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].

[0127] The present invention also relates to a system comprising a vehicle comprising the device 5 of [Fig.5] as well as a remote server.

Claims

1. Claims Method for controlling a set of applications embedded in a vehicle (10), a plurality of execution modes being associated with each application (431) of said set of applications, first data representative of resource requirements being associated with each execution mode of said plurality of execution modes and second data representative of at least one local rating (75) attributed to a user experience being associated with each execution mode of said plurality of execution modes, said method being implemented by at least one processor and comprising the following steps: - receiving (61) a configuration request for said set of applications, said request comprising third data representative of current available resources associated with said vehicle (10); - determination (62) of fourth data representative of at least one overall score (76) associated with each execution mode in said plurality of execution modes from the second data and data representative of a set of at least one weight (74); - determination (63), 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 third data, said set of execution modes comprising at least one execution mode, and • information representative of the user acceptance level associated with each execution mode of said set of execution modes, called AXIL level (331), based on the fourth data; - selection (64), for each application of said set of applications, of an execution mode in said set of execution modes according to the AXIL levels (331); - control (65) of execution of said set of applications according to the selected execution modes.

2. The method of claim 1, wherein said set of at least one weight (74) is determined for each execution mode of each application (431) relative to said set of applications.

3. Method according to claim 1 or 2, wherein said set of at least one weight (74) is associated with a user profile (73).

4. Method according to one of claims 1 to 3, further comprising a step of receiving data representative of a user evaluation, said set of at least one weight (74) being determined by a weight prediction model from said data representative of a user evaluation.

5. Method according to one of claims 1 to 4, for which said at least one local score (75) and said at least one global score (76) each comprise a set of evaluation criteria comprising: - a first criterion representative of a level of ease of ensuring a function without assistance of said each application (431); - a second criterion representative of a rate of use of said each application (431); and - a third criterion representative of a level of perceived quality of service for said each mode of execution of said each application (431).

6. Method according to one of claims 1 to 5, for which the step of determining (62) fourth data is implemented by a remote server, said fourth data being transmitted by said remote server to a computer on board the vehicle (10).

7. 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.

8. 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 5.

9.

10. Vehicle (10) comprising the device (5) according to claim 8. System comprising the vehicle (10) according to claim 9 and a remote server, the system being configured for implementing the steps of the method according to any one of claims 1 to 6

Images