Method and device for controlling the configuration of a vehicle's network infrastructure

Abstract

The present invention relates to a method and device for controlling the configuration of a vehicle's network infrastructure based on context change detection at the network infrastructure level. To this end, a configuration for a set of applications is selected (51) according to the context change. A reconfiguration request is sent (52) to each running application, and a response accepting or rejecting the reconfiguration is received (53) from each running application. The feasibility of implementing the selected configuration is determined (54) based on the responses received, and the selected configuration is implemented or not (55) depending on the feasibility. Figure for the abstract: Figure 5

Description

Title of the invention: Method and device for controlling the configuration of a vehicle's network infrastructure. Technical field

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

[0002] Contemporary vehicles carry a number of computers, each ensuring one or more functions, such as, for example, the management of driving assistance, traction control, electronic brake distribution, the control of actuators to ensure the 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 étoilé") and / or other systems embedded in the vehicle such as, for example, the air conditioning system and the vehicle navigation system.

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

[0004] These applications correspond to software modules implemented by one or more computers of the vehicle, some of these applications corresponding to interactive applications, also called interactive vignette (from the English "widget").

[0005] These embedded applications are designed to be updated, for example to improve the operation of these applications or to offer more services to vehicle users, via the downloading of update data using a communication method known as OTA (Over The Air) or FOTA (Firmware Over-The-Air). French "radio-link firmware"), vehicles equipped with a communication system configured to communicate wirelessly with one or more remote devices in the "cloud," for example. Embedded applications can also be enhanced by installing new applications, thus enriching the range of embedded 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 planned during the vehicle's design phase, which can 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.

[0007] Furthermore, the complexity of the electronic architecture, combined with the heterogeneity of the multitude of interconnected systems in contemporary vehicles, makes managing dynamic reconfigurations of the vehicle's software and network infrastructure difficult. Existing solutions cannot guarantee the absence of malfunctions in certain applications and / or the absence of data packet loss between the various network components during reconfiguration while the vehicle is in motion, which potentially impacts vehicle safety. Summary of the present invention

[0008] One 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 management of the dynamic configuration or reconfiguration of a vehicle's network infrastructure.

[0010] Another object of the present invention is to ensure the proper functioning of applications embedded in a vehicle during a reconfiguration of the vehicle's network infrastructure.

[0011] According to a first aspect, the present invention relates to a method for controlling the configuration of a vehicle's network infrastructure, the method comprising the following steps: - obtaining representative data of a configuration of a set of embedded applications selected from a plurality of configurations recorded in the vehicle's memory following a change in execution context detected at the network infrastructure level, a set of parameters representative of the selected configuration being associated with each application in the set of applications, a first representative piece of information of a maximum implementation time of the selected configuration being included in the data; - transmission, to each application in the set of applications running at the network infrastructure level, of an initial reconfiguration request for each running application based on the set of parameters associated with each running application; - receipt, from each running application, of a response to the first request, the response being determined by each running application from a current execution context of each running application and the set of parameters, the response belonging to a set of responses comprising: • an initial response indicating acceptance of the reconfiguration implementation according to a nominal execution mode, • a second response representative of an acceptance of implementing the reconfiguration in a degraded execution mode compared to the nominal execution mode, the first and second responses each including a second piece of information regarding the minimum implementation time for the reconfiguration, and • a third response representing a refusal to implement the reconfiguration; - determining the feasibility of implementing the selected configuration based on responses received from running applications; - monitoring the implementation of the selected configuration based on feasibility.

[0012] Such a method makes it possible to determine whether a configuration required to respond to a change of context detected at the level of the network infrastructure of a vehicle is possible by checking with each running application whether a reconfiguration even temporary of these applications is acceptable and within what time frame.

[0013] Depending on feasibility, the vehicle's network infrastructure configuration is implemented or not, which reduces the risks of application failure, particularly applications critical in terms of vehicle safety.

[0014] According to one variant, the determination of feasibility includes the following steps: - determination, for each running application, of a first execution mode based on the response and the selected configuration, the first execution mode corresponding to the nominal mode, the degraded mode or a shutdown mode of each running application; - determination of a duration required to implement the selected configuration based on the first execution modes determined for the set of applications in execution and the second information received; - comparison of the time required to implement the selected configuration to the maximum time allowed, The implementation of the selected configuration is determined to be feasible when the time required to implement the selected configuration is less than the maximum time limit.

[0015] According to another variant, when implementation of the selected configuration is feasible, the process further comprises the following steps: - transmission, to each running application, of a second reconfiguration request according to the first determined execution mode; - control of the processing of a set of data packets emitted by at least part of the set of applications running on the network infrastructure; - implementation of the selected configuration at the network infrastructure level following the completion of the processing of the entire data packet; - implementation of a determined stabilization period for the network infrastructure following the implementation of the selected configuration; - execution control of each application in the application set according to a second execution mode corresponding to the nominal mode.

[0016] According to a further variant, the first execution mode is determined based on a level of user acceptance associated with each candidate execution mode of a set of candidate execution modes associated with each running application.

[0017] According to an additional variant, the second request is transmitted after a period corresponding to the minimum period of greatest value included in the first and second responses.

[0018] According to yet another variant, a priority level is associated with at least part of the set of applications, the determination of the first execution mode being further dependent on the priority level.

[0019] According to a second aspect, the present invention relates to a configuration control device for a network infrastructure of a vehicle, the device comprising a memory associated with a processor configured for the implementation of the steps of the process according to the first aspect of the present invention.

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

[0021] According to a fourth aspect, the present invention relates to a computer program which includes instructions adapted for carrying out the steps of the process 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 an 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 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 process according to the first aspect of the present invention.

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

[0025] On the other hand, this recording medium can also be a transmissible medium such as an electrical or optical signal, such a signal being able to be transmitted via an electrical or optical cable, by conventional or radio frequency, by self-directing 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 execute or to be used in the execution of the process in question. Brief description of the figures

[0027] Other features and advantages of the present invention will become apparent from the description of the particular and non-limiting embodiments of the present invention below, with reference to the attached Figures 1 to 5, in which:

[0028] [Fig. 1] schematically illustrates a vehicle communication environment, according to a particular and non-limiting embodiment of the present invention

[0029] [Fig.2] schematically illustrates an embedded system of the vehicle of [Fig.1], according to a particular and non-limiting embodiment of the present invention.

[0030] [Fig.3] schematically illustrates a configuration control process of a network infrastructure of the vehicle of [Fig.1], according to a particular and non-limiting embodiment of the present invention.

[0031] [Fig.4] schematically illustrates a configuration control device for a network infrastructure of the vehicle of [Fig.1], according to particular and non-limiting embodiments of the present invention; and

[0032] [Fig.5] illustrates a flowchart of the different stages of a configuration control process of a network infrastructure of the vehicle of [Fig.1], according to a particular and non-limiting embodiment of the present invention. Description of examples of achievements

[0033] A method and a configuration control device for a vehicle network infrastructure will now be described in what follows with joint reference to Figures 1 to 5. The same elements are identified with the same reference signs throughout the following description.

[0034] The terms "first," "second" (or "firsts," "seconds"), etc., are used in this document by arbitrary convention to allow for the identification and distinction of different elements (such as operations, means, etc.) implemented in the embodiments described below. Such elements may be distinct or correspond to a single element, depending on the embodiment.

[0035] According to a particular and non-limiting embodiment of the present invention, controlling the configuration of a vehicle's network infrastructure, in particular applications implemented at the network infrastructure level and a set of components (memory, buffer, queues, controllers, etc.) associated with the implementation of the applications, for example by one or more computers of the vehicle's embedded system, includes receiving data representative of a configuration of a set of applications embedded in the vehicle selected from a set of configurations available in the vehicle's memory. This selection is triggered by the detection of a context change at the network infrastructure level.The data advantageously includes configuration parameters for each application and an initial estimate of the maximum time required to implement the selected configuration to meet the needs of the context change. A context change includes, for example, receiving a request to execute a new application, implement a new service, or trigger a network event. The selected configuration is tailored and specific to the new context of the vehicle's network infrastructure. For each application, the selected configuration includes a set of configuration parameters specifying, for example, the resources allocated to that application.An initial request is sent to each application in the set running at the network infrastructure level to determine whether that application accepts or refuses to implement the required reconfiguration according to the parameters of . configurations that concern it. In return, a response to the first request is received, such a response being determined by each application based on its specific current execution context. The response might correspond, for example, to an acceptance of implementing the reconfiguration in a nominal or standard execution mode, an acceptance of implementing the reconfiguration in a degraded mode compared to the nominal execution mode, or a refusal to implement the reconfiguration. The response also includes a minimum time required by each application to implement the reconfiguration according to the chosen execution mode. The feasibility of implementing the configuration for the entire application set is then determined based on the responses received. The configuration is implemented or declined depending on the determined feasibility.

[0036] Such a process thus makes it possible to take into account the current execution contexts of running applications impacted by the configuration required by the context change. This makes it possible to offer a network infrastructure reconfiguration methodology that takes into account the constraints of running applications before launching the network infrastructure reconfiguration, for example by proposing a temporary configuration phase for the running applications.

[0037] Such a methodology, for example, allows running applications to complete processes that have already started and that cannot be interrupted before launching a new configuration. A smooth and gradual transition between a current configuration and a new one is thus possible, improving the management or implementation of dynamic reconfiguration of the network infrastructure.

[0038] Fig. 1 schematically illustrates a communication environment for a vehicle 10, according to a particular and non-limiting embodiment of the present invention.

[0039] Fig. 1 illustrates a vehicle 10 in a communication environment 1, the vehicle 10 being for example in a road environment or on a parking area or parking lot, in a garage, etc.

[0040] Vehicle 10 corresponds, for example, to a vehicle with an internal combustion engine, with electric motor(s), or even a hybrid vehicle with an internal combustion engine and one or more electric motors. Vehicle 10 thus corresponds, for example, to a land vehicle, such as a car, a truck, a bus, or a motorcycle.

[0041] The vehicle 10 advantageously carries a communication system configured to communicate with one or more remote devices 111. Such a remote device 111 is, for example, configured to communicate with the vehicle 10 via an OTA or FOTA (Firmware Over-The-Air) connection. French "firmware by radio link") via a wireless communication network infrastructure of the terrestrial cellular network type using for example a wireless communication mode of type LTE (from the English "Long Term Evolution" or in French "Evolution à long terme") 4G or 5G.

[0042] According to one embodiment, the vehicle 10 communicates with the remote device in OTA or FOTA mode via a wireless local area network, known as WLAN (Wireless Local Area Network), for example of the Wifi® type. The WLAN is, for example, connected to the cloud via a wired network infrastructure and / or via the wireless communication network infrastructure.

[0043] Each remote device 111 is, for example, configured to manage the software (from the English "software," corresponding, for example, to firmware or any software necessary for the proper functioning of the vehicle 10) embedded in the vehicle 10, including interactive application software. The remote device 111 is, for example, designed to provide a set of configurations for the network infrastructure of the vehicle 10, each configuration being specific to a particular context (for example, for implementing a set of applications or services in parallel with the sharing of available resources). Such a remote device 111 is, for example, controlled by the manufacturer of the vehicle 10 and / or by a supplier of software or hardware components for the vehicle 10, including the network infrastructure of the vehicle 10.

[0044] The remote device 111 corresponds, for example, to a server in the "cloud" 100. The wireless communication infrastructure includes, for example, a set of communication devices such as cellular network antennas 110.

[0045] The vehicle 10 advantageously incorporates a communication system configured to communicate with the remote device 111 via the wireless communication infrastructure. The communication system includes, for example, one or more communication antennas connected to a telematic control unit, known as a TCU (Telematic Control Unit), which is itself connected to one or more computers of the vehicle 10's embedded system. The antenna(s), the TCU, and the computer(s) form, for example, a multiplexed architecture for providing various services useful for the proper functioning of the vehicle and for assisting the driver and / or passengers in controlling the vehicle 10.The computer(s) and the TCU communicate and exchange data with each other via one or more computer buses, for example a CAN (Controller Area Network) data bus, CAN FD (Controller Area Network Flexible Data-Rate). flexible data”), FlexRay (according to ISO 17458) or Ethernet (according to ISO / IEC 802-3).

[0046] Fig. 2 schematically illustrates a network infrastructure of the vehicle corresponding to the electronic and electrical architecture, known as E / E architecture, of the vehicle 10, according to a particular and non-limiting embodiment of the present invention.

[0047] The E / E architecture comprises a set of computers or ECUs 101, 102, 13 connected together 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ôlers"), CAN FD (from the English "Controller Area Network Flexible Data-Rate" or in French "Réseau de contrôlers à 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.

[0048] Such an architecture corresponds, for example, to a so-called ZOA (Zonal Oriented Architecture), such an architecture being service-oriented (or SOA, Service Oriented Architecture). Such an architecture is known to those skilled in the art and is described, for example, 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.

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

[0050] The set of computers further includes second computers, each illustrated by a grey 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 grey 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.

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

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

[0053] Fig. 3 illustrates a process for controlling the configuration of the network infrastructure or I / E architecture of the vehicle 10, according to a particular and non-limiting embodiment of the present invention.

[0054] Such a process 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 31 for example.

[0055] The configuration or reconfiguration of the network infrastructure or I / E architecture includes the configuration of a set of applications and the set of network infrastructure components (for example, memories associated with computers) following a detection or prediction of a change of context at the network infrastructure level.

[0056] In a preliminary operation not shown in [Fig. 3], the vehicle 10 downloads a set of predetermined dynamic configurations for a set of predetermined application or execution contexts. This set of dynamic configurations is, for example, calculated by one or more computing or data processing devices such as the remote device 111 and is made available to the vehicles for download via the wireless communication infrastructure, for example. This allows, for example, the set of available configurations to evolve by progressively increasing the specific configurations, for example, as the number of applications available for download to the vehicle 10 increases. As the number of applications increases, the number of execution contexts for these applications (i.e., the set of possible combinations of applications executed in parallel) also increases.A configuration associated with a particular context is set up to allocate or distribute the resources (network and computing) available at the I / E architecture level between applications to be executed concurrently, for example, according to priority levels associated with each application.

[0057] A configuration includes, for example, further specific constraints depending on the applications, such as maximum implementation times, an order of execution of applications, etc.

[0058] The various pre-calculated configurations are advantageously stored in one or more memories of the vehicle 10. A set of configurations is available for example at the factory exit, this set evolving over time with the download by the vehicle 10 of the new configurations available on the remote device 111 via an OTA link.

[0059] In a first operation 301, data representative of a configuration of a set of applications embedded in the vehicle 10 are obtained, for example received or generated.

[0060] This particular configuration is selected from the set of configurations recorded in a memory of the vehicle 10, that is to say from the set of configurations available in the vehicle at the time and according to a detection of a change in the execution context of this set of embedded applications.

[0061] These data are obtained following and based on the detection of a change in the execution context of a set of applications embedded in the vehicle 10 at the network infrastructure level and are received by the controller 31.

[0062] A change of context is detected, for example, when a request to execute one or more new applications is received in addition to the application(s) already running. A request to execute a new application is received, for example, from a human-machine interface of the vehicle 10 when the request originates from a user wishing to implement one or more services via this new application. In another example, a request to execute a new application is generated by a computer in the vehicle 10 controlling an ADAS (Advanced Driver-Assistance System) of the vehicle 10.For example, vehicle 10 can receive data via a V2X (Vehicle-to-Everything) communication mode, requiring the implementation of a specific service to optimize traffic, for instance, with the implementation of the associated application taking priority over "best-case" applications. As another example, a context change is detected when a component of the I / E architecture encounters a problem, reducing, for example, the resources available for implementing associated applications and services.

[0063] The data thus includes, for example: - a list of applications running at the time of the context change to be stopped or shut down; and / or - a list of currently running applications to keep running; and / or - a list of new applications to launch, i.e., one or more applications that were not running when the context change was detected; and / or - initial information representing a maximum delay, denoted 'T', for the implementation of the selected configuration, this delay T being determined, for example, by a component that detected the change of context, by the computer that selected the configuration, or this delay being understood as metadata in the data; and / or - a priority level for the execution of each application (for example, the execution of a cooperative application or service (of the V2X type for example) in a critical safety situation for the vehicle has a higher priority level than the execution of an entertainment application); and / or - the resources allocated to each application.

[0064] The selection of the configuration marks, for example, the beginning of a so-called duration negotiation phase with the running applications.

[0065] In a second operation 302, a first reconfiguration request for each running application, based on the parameter set associated with each running application, is transmitted to each application in the running application set at the network infrastructure level. This first request is, for example, transmitted to a module or component 32 controlling the applications or to each computer 32 controlling an application in the running application set. The first request includes the configuration parameters.

[0066] In a third operation 303, each module or component 32 determines a response to the first request based on the configuration parameters associated with each application, such parameters including, for example, the resources (computing, memory, bandwidth, etc.) allocated to each application.

[0067] The answer belongs to a set of answers comprising: - an initial response indicating acceptance of the reconfiguration implementation according to a nominal execution mode, - a second response representative of an acceptance of implementing the reconfiguration in a degraded execution mode compared to the nominal execution mode, and - a third response representative of a refusal to implement the reconfiguration

[0068] The first request includes, for example, the execution mode according to which each running application must be reconfigured (nominal execution mode, degraded execution mode or execution stop mode).

[0069] According to one embodiment, a running application selects one or more execution modes from a set of available execution modes associated with the application, based on the data received in the first request.

[0070] The execution mode is thus selected from the following modes: - a so-called nominal or standard execution mode, that is to say a mode in which the application is executed to operate according to a reference performance level (all services obtained by the application are implemented as expected); - one or more degraded execution modes, meaning that the performance level obtained in such a degraded mode is lower than the reference performance level; that is, only some 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. - a stop execution mode or disabled mode in which the application is not executed, i.e. the execution of the application is postponed or simply cancelled.

[0071] In a fourth operation 304, the controller 31 receives from each module 32. The response to the first query, each application returning data representative of: - an initial response indicating acceptance of the reconfiguration implementation according to a nominal execution mode, - a second response representative of an acceptance of implementing the reconfiguration in a degraded execution mode compared to the nominal execution mode, the degraded mode being required in the first request or selected by the application concerned based on the resources allocated to it in the first request, and - a third response representative of a refusal to implement the reconfiguration (for example refusal to switch to execution stop mode or refusal to switch to a degraded execution mode).

[0072] Each response, or at least the responses relating to acceptance of operating in nominal or degraded mode, also includes a second piece of information concerning the minimum time required to implement the reconfiguration in the required or selected execution mode. This minimum time corresponds, for example, to the time required for each application to complete ongoing tasks (data downloading, data processing, etc.) must be completed before a reconfiguration can be initiated.

[0073] The receipt of all responses marks the end of the so-called negotiation phase with the running applications.

[0074] In a fifth operation 305, the controller 31 determines which combination of possible execution modes minimizes the cost of total reconfiguration and network disturbances, a first execution mode being determined for each application (nominal mode, degraded mode or shutdown mode).

[0075] According to one variant, the determination of the combination further takes into account a user acceptance criterion for the execution modes, each execution mode associated with an application being, for example, associated with such a criterion (determined by the application designer or according to specific calculation rules). Such a criterion is, for example, called the AXIL level (from the English "Automotive eXperience Integrity Level").

[0076] The AXIL level corresponds, for example, to a level of acceptance of the use of an execution mode in a particular context, this level belonging to a defined set of levels including, 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 may feel a difference compared to the nominal mode but accepts it without problem), level 'B' (some users feel frustration with the implementation according to this execution mode), level 'C' (many users feel frustration with the implementation according to this execution mode) and level 'D' (execution mode unacceptable in terms of user experience).

[0077] When an application refuses to implement the required reconfiguration (for example, an application refuses to stop), the controller 31 may decide to force the application to stop when a high priority level is associated with the selected configuration (for example, when the selected configuration includes the execution of one or more new applications providing safety-critical services) and stopping the application(s) in question does not have an impact on the safety or operation of the vehicle, other than the approval of one or more users.

[0078] This operation 305 corresponds to a phase called selection of execution modes of duration ô2.

[0079] In a sixth operation 306, the controller determines the time required to implement the selected configuration, denoted A, for example based on the second information received.

[0080] In a seventh operation 307, the duration A required to implement the selected configuration is compared to the maximum delay T.

[0081] If A is less than T, then the implementation of the selected configuration is deemed feasible and the configuration process continues with operations 308 to 320.

[0082] Otherwise, if A is greater than T, then the implementation of the selected configuration is deemed unfeasible and the configuration process is interrupted or canceled, cancellation information being transmitted in a 307 operation to the instance that detected or requested the context change.

[0083] Operations 306 and 307, where applicable, form a so-called confirmation phase of duration ô3.

[0084] In an eighth operation 308, forming a so-called waiting phase before launching the selected configuration and of duration ô4, the controller waits for a predetermined duration corresponding to the minimum duration required by the applications with the highest value. The controller 31 thus allows time for the running applications involved in the reconfiguration to complete their ongoing tasks before initiating the reconfiguration.

[0085] In a ninth operation 309, the controller 31 transmits to each running application 32 concerned by the reconfiguration a second reconfiguration request according to the first determined execution mode (degraded mode or shutdown mode).

[0086] The second query includes, for example, a third piece of information representing the duration for which each application must remain in degraded mode, or even in shutdown mode.

[0087] In a tenth operation 310, each application 32 having received a second request implements the reconfiguration according to the first required execution mode (degraded mode or stop mode).

[0088] In an optional eleventh operation 311, each application transmits an acknowledgment to the controller 31 to confirm the successful implementation of the reconfiguration in degraded mode or the end of the application's execution.

[0089] Operations 309 to 311 form a so-called disengagement phase of duration 05.

[0090] In a twelfth operation 312, the controller 31 implements a so-called network stabilization phase of duration 06, corresponding to a waiting phase allowing network convergence. Such a phase is intended to allow the transit of data packets emitted by the old applications (applications stopped during reconfiguration and / or data packets relating to services stopped when an application switches to degraded mode).

[0091] According to one variant, one or more processing operations of the data emitted by these applications are implemented during this network stabilization phase, such as data filtering to remove emitted data, which improves the network convergence time.

[0092] In a thirteenth operation 313, a reconfiguration request is transmitted to each component 33 of the network infrastructure. This reconfiguration is triggered, for example, at a specific time common to all network components in order to synchronize the reconfiguration so that all computer transactions are implemented at the same specific time.

[0093] In a fourteenth operation 314, the reconfiguration is implemented at the level of all network components. Some applications that were stopped or running in degraded mode, for example, return to normal execution mode.

[0094] In an optional fifteenth operation 315, each network component transmits an acknowledgment to the controller 31 to confirm the correct implementation of the reconfiguration.

[0095] Operations 313 to 315 form a so-called reconfiguration phase of duration ô7.

[0096] In a sixteenth operation 316, the controller 31 implements a so-called network convergence phase of duration ô8 corresponding to a waiting phase allowing network convergence (processing of data packets in transit, stabilization of buffer memories).

[0097] In a seventeenth operation 317, the controller 31 sends a request to each new application (i.e., each application that was not running at the time of the context change and is concerned with the selected configuration) to be executed to trigger the execution of each new application in a determined execution mode conforming to the selected configuration.

[0098] In an eighteenth operation 318, the execution of each new application is implemented according to the request transmitted by the controller 31.

[0099] In an optional nineteenth operation 319, each new application executed transmits an acknowledgment to the controller 31 to confirm the correct implementation of the selected configuration.

[0100] In a twentieth operation 320, the 320 controller transmits an acknowledgment or confirmation of context change to the instance that detected or requested this context change.

[0101] Figure 4 schematically illustrates a device 4 configured to control the configuration of a network infrastructure of a vehicle, for example vehicle 10, according to a particular and non-limiting embodiment of the present invention. Device 4 corresponds for example to a device embedded in vehicle 10, for example a computer.

[0102] Device 4 is, for example, configured to carry out the operations described opposite Figures 1 to 3 and / or the steps of the process described opposite [Fig. 5]. Examples of such a device 4 include, but are not limited to, embedded electronic equipment such as a vehicle's on-board computer, an electronic control unit such as an ECU (Electronic Control Unit), a TCU (Telematic Control Unit), or any data processing device of an embedded vehicle system. The elements of device 4, individually or in combination, may be integrated into a single integrated circuit, into several integrated circuits, and / or into discrete components. Device 4 may be implemented in the form of electronic circuits or software (or computer) modules, or a combination of electronic circuits and software modules.

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

[0104] The computer code of the embedded software(s), including the instructions to be loaded and executed by the processor, is for example stored in memory 4L

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

[0106] According to a particular and non-limiting embodiment, the device 4 includes a block 42 of interface elements for communicating with external devices. The interface elements of the block 42 include one or more of the following interfaces: - Radio frequency (RF) 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", or in French "Réseau interconnecté local").

[0107] According to another particular and non-limiting embodiment, the device 4 includes a communication interface 43 which enables communication with other devices (such as other computers in the embedded system) via a communication channel 430. The communication interface 43 corresponds, for example, to a transmitter configured to transmit and receive information and / or data via the communication channel 430. The communication interface 43 corresponds, for example, to a wired network of the CAN (Controller Area Network), CAN FD (Controller Area Network Flexible Data-Rate), FlexRay (standardized by ISO 17458) or Ethernet (standardized by ISO / IEC 802-3) type.

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

[0109] Figure 5 illustrates a flowchart of the different steps in a method for controlling the configuration of a network infrastructure of a vehicle, for example vehicle 10, according to a particular and non-limiting embodiment of the present invention. The method is implemented, for example, by a device embedded in vehicle 10 or by device 4 of Figure 4.

[0110] In a first step 51, data representative of a configuration of a set of embedded applications selected from a plurality of configurations recorded in a memory of the vehicle are obtained following a change of execution context detected at the level of the network infrastructure, a set of parameters representative of the selected configuration being associated with each application of the set of applications, a first information representative of a maximum implementation time of the selected configuration being included in the data.

[0111] In a second step 52, a first reconfiguration request for each running application based on the set of parameters associated with each running application is sent to each application in the set of running applications at the network infrastructure level.

[0112] In a third step 53, a response to the first request is received from each running application, the response being determined by each running application from a current execution context of each running application and the parameter set, the response belonging to a set of responses comprising: • an initial response indicating acceptance of the reconfiguration implementation according to a nominal execution mode, • a second response representative of an acceptance of implementing the reconfiguration in a degraded execution mode compared to the nominal execution mode, the first and second responses each including a second piece of information regarding the minimum implementation time for the reconfiguration, and • a third response representative of a refusal to implement the reconfiguration.

[0113] In a fourth step 54, the feasibility of implementing the selected configuration is determined based on the responses received from the running applications.

[0114] In a fifth step 55, the implementation of the selected configuration is checked according to feasibility.

[0115] According to one variant, the variants and examples of the operations described in relation to Figures 1 to 3 apply to the steps of the process in [Fig. 5].

[0116] Of course, the present invention is not limited to the embodiments described above but extends to a method for reconfiguring a set of embedded applications in a vehicle, which would include secondary steps without falling outside the scope of the present invention. The same would apply to a device configured for implementing such a method.

[0117] The present invention also relates to a vehicle, for example an automobile or more generally an autonomous land-powered vehicle, comprising the device 4 of [Fig.4].

Claims

1. Demands Method for controlling the configuration of a network infrastructure of a vehicle (10), said method comprising the following steps: - obtaining (51) data representative of a configuration of a set of embedded applications (32) selected from a plurality of configurations recorded in a memory of said vehicle (10) following a change in execution context detected at the level of said network infrastructure, a set of parameters representative of the selected configuration being associated with each application of said set of applications, a first piece of information representative of a maximum time (T) for the implementation of said selected configuration being included in said data; - transmission (52), to each application (32) of said set of applications running at the level of said network infrastructure, of a first reconfiguration request of said each running application according to the set of parameters associated with said each running application; - reception (53), from said each running application, of a response to said first request, said response being determined by said each running application from a current execution context of said each running application and said set of parameters, said response belonging to a set of responses comprising: • a first response representing acceptance of the implementation of said reconfiguration according to a nominal execution mode, • a second response representing acceptance of the implementation of said reconfiguration in a degraded execution mode compared to said nominal execution mode, said first and second responses each including a second piece of information regarding the minimum implementation time of said reconfiguration, and • a third response representing a refusal to implement said reconfiguration; - determination (54) of the feasibility of implementing the selected configuration based on responses received from running applications; - control (55) of implementation of said selected configuration according to said feasibility, the determination of said feasibility includes the following steps: - determination, for said each running application, of a first execution mode according to said response and said selected configuration, said first execution mode corresponding to the nominal mode, the degraded mode or a shutdown mode of said each running application; - determination of a time required (A) for the implementation of the selected configuration according to the first execution modes determined for the set of running applications and said second information received;- comparison of said time required (A) to implement said selected configuration with said maximum time (T), the implementation of said configuration being determined as feasible when said time required to implement the selected configuration is less than said maximum time.;

2. A method according to claim 1, wherein, when the implementation of the selected configuration is feasible, said method further comprises the following steps: - transmission, to said each running application, of a second reconfiguration request according to said first determined execution mode; - processing control of a set of data packets emitted by at least a part of said set of running applications on said network infrastructure; - implementation of said selected configuration at said network infrastructure following the completion of processing of said set of data packets; - implementation of a determined stabilization delay of said network infrastructure following the implementation of said selected configuration; - execution control of each application of said set of applications according to a second execution mode corresponding to the nominal mode.

3. A method according to claim 1 or 2, wherein said first execution mode is determined based on a user acceptance level associated with each candidate execution mode of a set of candidate execution modes associated with said each running application.

4. A method according to claim 2, wherein said second request is transmitted after a period corresponding to the minimum period of greater value included in said first and second responses.

5. A method according to any one of claims 1 to 4, wherein a priority level is associated with at least a part of said set of applications, the determination of said first mode of execution being further a function of said priority level.

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

7. Computer program comprising instructions for carrying out the method according to any one of claims 1 to 5, when such instructions are executed by a processor.

8. Device (4) for controlling the configuration of a vehicle network infrastructure, said device (4) comprising a memory (41) associated with at least one processor (40) configured for carrying out the steps of the method according to any one of claims 1 to 5.

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

Images