FR3151458A1 - Method and device for controlling the configuration of a vehicle network infrastructure - Google Patents

Abstract

The present invention relates to a method and a device for controlling the configuration of a network infrastructure of a vehicle following a context change detection at the network infrastructure. For this purpose, a configuration for a set of applications is selected (51) according to the context change. A reconfiguration request is transmitted (52) to each application currently running and a response accepting or refusing to implement the reconfiguration is received (53) from each application currently running. The feasibility of implementing the selected configuration is determined (54) according to the responses received and the selected configuration is implemented or not (55) according to the feasibility. Figure for abstract: Figure 5

Description

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

The present invention relates to methods and devices or systems for controlling the configuration of a network infrastructure of a vehicle, in particular a motor vehicle. The present invention also relates to a method and a device 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 in which each application is implemented in the vehicle.

Technological background

Contemporary vehicles have a number of computers, each of which performs one or more functions, such as, for example, the management of driving assistance, anti-skid, 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 embargo") and/or other systems embedded in the vehicle such as, for example, the air conditioning system and the vehicle's navigation system.

These calculators are also called ECUs ("Electronic Control Units"). These calculators have embedded 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 others), process this data and send control signals to various components (actuators) of the engine.

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.

These on-board applications are designed to be updated, for example to improve the operation of these applications or to offer more services to vehicle users, by downloading update data using a communication method called OTA (Over The Air) or FOTA (Firmware Over-The-Air), vehicles having a communication system configured to communicate via a wireless network with one or more remote devices in the cloud, for example. The on-board applications can also be supplemented by installing new applications, thereby enriching the range of on-board services offered to vehicle users.

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 done with a hardware architecture planned during the design of the vehicle, 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.

Furthermore, the complexity of the electronic architecture combined with the heterogeneity of the multitude of interconnected systems in contemporary vehicles makes it difficult to manage dynamic reconfigurations of the vehicle's software and network infrastructure. Existing solutions do not guarantee the absence of malfunctions of certain applications and/or loss of data packets exchanged between the different network components when implementing a reconfiguration while the vehicle is in circulation, which potentially impacts the safety of the vehicle.

Summary of the present invention

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

Another object of the present invention is to improve the management of the dynamic configuration or reconfiguration of a vehicle network infrastructure.

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.

According to a first aspect, the present invention relates to a method for controlling the configuration of a network infrastructure of a vehicle, the method comprising the following steps:
- obtaining data representative of a configuration of a set of on-board applications selected from a plurality of configurations recorded in a memory of the vehicle 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 piece of information representative of a maximum implementation time of the selected configuration being included in the data;
- transmission, to each application of the set of applications currently running at the network infrastructure level, of a first request for reconfiguration of each application currently running according to the set of parameters associated with each application currently running;
- receiving, from each running application, 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:
● a first response representative of an acceptance of implementation of the reconfiguration according to a nominal execution mode,
● a second response representing an acceptance of implementation of the reconfiguration in a degraded execution mode compared to the nominal execution mode,
the first and second responses each comprising a second minimum time period information for implementing the reconfiguration, and
● a third response representing a refusal to implement the reconfiguration;
- determination of the feasibility of implementing the selected configuration based on the responses received from the running applications;
- implementation control of the selected configuration based on feasibility.

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 application currently running whether even a temporary reconfiguration of these applications is acceptable and within what time frame.

Depending on the feasibility, the vehicle network infrastructure configuration is implemented or not, which reduces the risk of application failure, especially safety-critical applications for the vehicle.

Alternatively, the feasibility determination includes the following steps:
- determination, for each application being executed, of a first execution mode as a function of the response and the selected configuration, the first execution mode corresponding to the nominal mode, the degraded mode or a shutdown mode of each application being executed;
- determination of a duration necessary for the implementation of the selected configuration based on the first execution modes determined for the set of applications currently running and the second information received;
- comparison of the time required to implement the selected configuration with the maximum time,
the implementation of the selected configuration being determined to be feasible when the time required to implement the selected configuration is less than the maximum time.

According to another variant, when the implementation of the selected configuration is feasible, the method further comprises the following steps:
- transmission, to each application currently running, of a second reconfiguration request according to the first execution mode determined;
- control of 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 end of processing of the set of data packets;
- implementation of a specific stabilization period of the network infrastructure following the implementation of the selected configuration;
- execution control of each application of the set of applications according to a second execution mode corresponding to the nominal mode.

In a further variation, the 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 each running application.

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.

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.

According to a second aspect, the present invention relates to a device for controlling the configuration of a network infrastructure of 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.

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.

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

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

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

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

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 hertzian radio or by self-directed laser beam or by other means. The computer program according to the present invention may in particular be downloaded from a network such as the Internet.

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

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 5, in which:

schematically illustrates a vehicle communication environment, according to a particular and non-limiting exemplary embodiment of the present invention

schematically illustrates an on-board system of the vehicle of the , according to a particular and non-limiting exemplary embodiment of the present invention.

schematically illustrates a configuration control process of a vehicle network infrastructure of the , according to a particular and non-limiting exemplary embodiment of the present invention.

schematically illustrates a configuration control device of a vehicle network infrastructure of the , according to particular and non-limiting exemplary embodiments of the present invention; and

illustrates a flowchart of the different steps of a configuration control process of a vehicle network infrastructure of the , according to a particular and non-limiting exemplary embodiment of the present invention.

Description of examples of implementation

A method and a device for controlling the configuration of a network infrastructure of a vehicle will now be described in the following with joint reference to FIGS. 1 to 5. The same elements are identified with the same reference signs throughout the description which follows.

The terms “first(s)”, “second(s)” (or “first(s)”, “second(s)”), etc. are used in this document by arbitrary convention to allow 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 and unique element, depending on the embodiment.

According to a particular and non-limiting example of embodiment of the present invention, the control of the configuration of a network infrastructure of a vehicle, in particular of applications implemented at the level of the network infrastructure and of a set of components (memory, buffer memory, queues, controllers, etc.) associated with the implementation of the applications, for example by one or more computers of the on-board system of the vehicle, comprises the reception of data representative of a configuration of a set of applications on-board the vehicle selected from a set of configurations available in a memory of the vehicle. This selection is triggered by a detection of a change of context at the level of the network infrastructure. The data advantageously comprise configuration parameters for each application and a first information representative of a maximum time for the implementation of the configuration selected to meet the needs of the change of context. A change of context comprises for example the reception of a request to execute a new application, to implement a new service, a network event, etc. The selected configuration is adapted and specific to the new context of the vehicle's network infrastructure. The selected configuration includes for each application a set of configuration parameters specifying for example the resources allocated to this application. A first request is transmitted to each application of the set currently running at the network infrastructure level to determine whether this application accepts or refuses to implement the required reconfiguration according to the configuration parameters that concern it. In return, a response to the first request is received, such a response being determined by each application according to a current execution context specific to each application. The response corresponds for example to an acceptance of implementation of the reconfiguration in a nominal or standard execution mode, an acceptance of implementation of 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 application set configuration is then determined based on the responses received. The configuration is implemented or declined based on the feasibility determined.

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

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

There schematically illustrates a communication environment for a vehicle 10, according to a particular and non-limiting exemplary embodiment of the present invention.

There 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 car park, in a garage, etc.

The vehicle 10 corresponds for example to a vehicle with a thermal engine, with electric motor(s) or even a hybrid vehicle with a thermal engine and one or more electric motors. The vehicle 10 thus corresponds for example to a land vehicle, for example an automobile, a truck, a coach, a motorcycle.

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 according to an OTA or FOTA (Firmware Over-The-Air) type connection via an infrastructure of a wireless communication network of the terrestrial cellular network type using for example a wireless communication mode of the LTE (Long Term Evolution) 4G or 5G type.

According to an alternative embodiment, the vehicle 10 communicates with the remote device in OTA or FOTA mode via a wireless local area network, called WLAN (from the English “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.

Each remote device 111 is for example configured to manage the software (from the English “software”, corresponding for example to a firmware or to any software necessary for the proper functioning of the vehicle 10) embedded in the vehicle 10, in particular the interactive application type software. The remote device 111 is for example provided to provide a set of configurations of the network infrastructure of the vehicle 10, each configuration being specific to a particular context (for example for the implementation of 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 of the vehicle 10, in particular of the network infrastructure of the vehicle 10.

The remote device 111 corresponds for example to a server of the “cloud” 100 (or “cloud” in French). The wireless communication infrastructure comprises for example a set of communication devices of the cellular network antenna type 110.

The vehicle 10 advantageously carries a communication system configured to communicate with the remote device 111 via the wireless communication infrastructure. The communication system comprises, for example, one or more communication antennas connected to a telematic control unit, called a TCU (Telematic Control Unit), itself connected to one or more computers of the on-board system of the vehicle 10. The antenna(s), the TCU and the computer(s) form, for example, a multiplexed architecture for the production of various services useful for the proper operation of the vehicle and for assisting the driver and/or passengers of the vehicle 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 communication bus of the CAN (Controller Area Network) type, CAN FD (Controller Area Network Flexible Data-Rate), FlexRay (according to the ISO 17458 standard) or Ethernet (according to the ISO/IEC 10001 standard). 802-3).

There schematically illustrates a network infrastructure of the vehicle corresponding to the electronic and electrical architecture, called E/E architecture, of the vehicle 10, according to a particular and non-limiting exemplary embodiment of the present invention.

The E/E architecture comprises a set of computers or ECUs 101, 102, 13 connected to each other by data buses to form a network mixing, for example, several technologies such as Ethernet (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.

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.

The set of calculators includes for example first calculators each illustrated by a white rectangle 101 on the connected to each other by an Ethernet-type backbone. These first computers correspond, for example, to HPC-type ECUs (from the English "High Performance Computing").

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

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) does not have the same resource needs 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.

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 a centralized architecture (with centralized gateway), such architectures also being described in the document entitled “Making the Case for Centralized Automotive E/E Architectures”.

There illustrates a process for controlling the configuration of the network infrastructure or E/E architecture of the vehicle 10, according to a particular and non-limiting exemplary embodiment of the present invention.

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.

Configuring or reconfiguring the network infrastructure or E/E architecture includes configuring a set of applications and the set of network infrastructure components (e.g. memories associated with computers) following a detection or prediction of a change of context at the network infrastructure level.

In a preliminary operation not illustrated on the , the vehicle 10 downloads a set of dynamic configurations determined in advance for a set of determined 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 downloading via the wireless communication infrastructure for example. This makes it possible for example to evolve the set of available configurations by gradually increasing the particular configurations, for example when the number of applications available for downloading for the vehicle 10 increases. As the number of applications increases, the number of execution contexts of these applications (i.e. all possible combinations of applications executed in parallel) also increases. A configuration associated with a particular context is configured to distribute or distribute the resources (network and computing) available at the level of the E/E architecture between the applications to be executed concomitantly, for example according to priority levels associated with each application.

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

The different precalculated configurations are advantageously stored in one or more memories of the vehicle 10. A set of configurations is for example available at the factory, this set evolving over time with the downloading by the vehicle 10 of the new configurations available on the remote device 111 via an OTA link.

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.

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 on-board applications.

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

A change of context is for example detected when receiving a request to execute one or more new applications in addition to the application(s) already running. A request to execute a new application is for example received from a human-machine interface of the vehicle 10 when the request comes from a user wishing to implement one or more services via this new application. According to another example, a request to execute a new application is for example generated by a computer of the vehicle 10 controlling an ADAS (Advanced Driver-Assistance System) system of the vehicle 10. For example, the vehicle 10 can receive data via a V2X (Vehicle-to-Everything) type communication mode requiring the implementation of a particular service to optimize traffic 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 reducing for example the resources available for the implementation of the associated applications and services.

The data includes, for example:
- a list of applications running at the time of the context switch to be stopped or terminated; and/or
- a list of 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 switch was detected; and/or
- a first piece of information representing a maximum delay, denoted 'T', for the implementation of the selected configuration, this delay T being for example determined by a component having detected the change of context, by the calculator having selected the configuration or this delay being included 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 (such as V2X) in a safety-critical situation for the vehicle has a higher priority level than the execution of an entertainment application); and/or
- the resources allocated to each application.

The selection of the configuration marks for example the beginning of a so-called negotiation phase of duration δ1 with the applications currently running.

In a second operation 302, a first request for reconfiguration of each application currently running according to the set of parameters associated with each application currently running is transmitted to each application of the set of applications currently running at the network infrastructure. This first request is for example transmitted to a module or component 32 controlling the applications or to each computer 32 controlling an application of the set of applications currently running. The first request comprises the configuration parameters.

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 (computation, memory, bandwidth, etc.) allocated to each application.

The answer belongs to a set of answers including:
- a first response representing an acceptance of implementation of the reconfiguration according to a nominal execution mode,
- a second response representing an acceptance of implementation of the reconfiguration in a degraded execution mode compared to the nominal execution mode, and
- a third response representing a refusal to implement the reconfiguration

The first query includes, for example, the execution mode to which each running application should be reconfigured (nominal execution mode, degraded execution mode, or execution shutdown mode).

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 data received in the first request.

The execution mode is thus selected from the following modes:
- a so-called nominal or standard execution mode, i.e. a mode in which the application is executed to operate according to a reference performance level (all the services obtained by the application are implemented as expected);
- one or more degraded execution modes, i.e. the performance level obtained in such a degraded mode is lower than the reference performance level, i.e. only part of the services associated with the application 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 canceled.

In a fourth operation 304, the controller 31 receives from each module 32 the response to the first request, each application returning data representative of:
- a first response representing an acceptance of implementation of the reconfiguration according to a nominal execution mode,
- a second response representing an acceptance of implementation of 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 according to the resources allocated to it in the first request, and
- a third response representing a refusal to implement the reconfiguration (for example refusal to switch to execution stop mode or refusal to switch to a degraded execution mode).

Each response, or at least the responses relating to an acceptance to operate in nominal or degraded mode, also includes a second piece of information relating to the minimum time required to implement the reconfiguration in the required or selected execution mode. This minimum time corresponds, for example, to a duration required for each application to complete the tasks in progress (data downloading, data processing, etc.) before being able to initiate a reconfiguration.

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

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

According to a variant, the determination of the combination also takes into consideration a user acceptance criterion of the execution modes, each execution mode associated with an application being for example associated with such a criterion (determined by the designer of the application or according to determined calculation rules). Such a criterion is for example called AXIL level (from the English “Automotive eXperience Integrity Level” or in French “niveau d’intégrage d’expérience automobile”).

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

When an application refuses to implement the required reconfiguration (for example an application refuses to stop), the controller 31 can decide to force the stopping of the application 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 critical services in terms of safety) and the stopping of the application(s) currently running in question has no impact on the safety or operation of the vehicle, other than an approval of one or more users.

This operation 305 corresponds to a phase called execution mode selection of duration δ2.

In a sixth operation 306, the controller determines the duration necessary for the implementation of the selected configuration, noted Δ, for example as a function of the second information received.

In a seventh operation 307, the duration Δ necessary for the implementation of the selected configuration is compared to the maximum delay T.

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

Otherwise, if Δ is greater than T, then the implementation of the selected configuration is deemed infeasible and the configuration process is interrupted or canceled, cancellation information being transmitted in an operation 307 to the instance having detected or requested the context change.

Operations 306 and 307, where applicable, form a so-called confirmation phase of duration δ3.

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 determined duration corresponding to the minimum duration required by the applications whose value is the highest. The controller 31 thus allows time for the applications currently running concerned by the reconfiguration to complete the tasks in progress before initiating the reconfiguration.

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 execution mode determined (degraded mode or shutdown mode).

The second request also includes, for example, a third piece of information representing the duration during which each application must remain in degraded mode, or even in shutdown mode.

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

In an optional eleventh operation 311, each application transmits an acknowledgment to the controller 31 to confirm the correct implementation of the reconfiguration in degraded mode or the end of execution of the application.

Operations 309 to 311 form a so-called disengagement phase of duration δ5.

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

According to one variant, one or more treatments of the data emitted by these applications are implemented during this network stabilization phase, such as filtering the data to remove the emitted data, which makes it possible to improve the network convergence time.

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

In a fourteenth operation 314, the reconfiguration is implemented at the level of all network components. Certain applications stopped or executed in degraded mode return, for example, to nominal execution mode.

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

Operations 313 to 315 form a so-called reconfiguration phase of duration δ7.

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

In a seventeenth operation 317, the controller 31 transmits a request to each new application (i.e. each application which was not currently running at the time of the context change and concerned by the selected configuration) to be executed to trigger the execution of each new application in a determined execution mode conforming to the selected configuration.

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

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.

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

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

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

The device 4 comprises one (or more) processor(s) 40 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 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 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.

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

According to various particular and non-limiting exemplary embodiments, the device 4 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.

According to a particular and non-limiting exemplary embodiment, the device 4 comprises a block 42 of interface elements for communicating with external devices. The interface elements of the block 42 comprise one or more of the following interfaces:
- RF radio frequency interface, for example of the Wi-Fi® type (according to IEEE 802.11), for example in the 2.4 or 5 GHz frequency bands, or of the Bluetooth® type (according to IEEE 802.15.1), in the 2.4 GHz frequency band, or of the 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”);
- LIN interface (from the English “Local Interconnect Network”).

According to another particular and non-limiting exemplary embodiment, the device 4 comprises a communication interface 43 which makes it possible to establish communication with other devices (such as other computers of the on-board 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 the ISO 17458 standard) or Ethernet (standardized by the ISO/IEC 802-3 standard).

According to a particular and non-limiting exemplary embodiment, the device 4 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.

There illustrates a flowchart of the different steps of a method for controlling the configuration of a network infrastructure of 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 on board the vehicle 10 or by the device 4 of the .

In a first step 51, data representative of a configuration of a set of on-board applications selected from a plurality of configurations recorded in a memory of the vehicle are obtained following a change in 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 piece of information representative of a maximum time limit for implementing the selected configuration being included in the data.

In a second step 52, a first request for reconfiguration of each application currently running as a function of the set of parameters associated with each application currently running is transmitted to each application of the set of applications currently running at the network infrastructure level.

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 set of parameters, the response belonging to a set of responses comprising:
● a first response representative of an acceptance of implementation of the reconfiguration according to a nominal execution mode,
● a second response representing an acceptance of implementation of the reconfiguration in a degraded execution mode compared to the nominal execution mode,
the first and second responses each comprising a second minimum time period information for implementing the reconfiguration, and
● a third response representing a refusal to implement the reconfiguration.

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

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

Alternatively, the variants and examples of the operations described in relation to Figures 1 to 3 apply to the steps of the method of the .

Of course, the present invention is not limited to the exemplary embodiments described above but extends to a method for reconfiguring a set of applications embedded 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 implementing such a method.

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

Claims (10)

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 on-board 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 item of information representative of a maximum time (T) for implementing said selected configuration being included in said data;
- transmission (52), to each application (32) of said set of applications currently being executed at said network infrastructure, of a first request for reconfiguration of said each application currently being executed as a function of the set of parameters associated with said each application currently being executed;
- receiving (53), from said each running application, 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 an acceptance of implementation of said reconfiguration according to a nominal execution mode,
● a second response representing an acceptance of implementation of said reconfiguration in a degraded execution mode compared to said nominal execution mode,
said first and second responses each comprising a second piece of information on the minimum time for implementing said reconfiguration, and
● a third response representing a refusal to implement said reconfiguration;
- determining (54) a feasibility of implementing the selected configuration based on the responses received from the running applications;
- control (55) of implementation of said selected configuration according to said feasibility. The method of claim 1, wherein determining said feasibility comprises the following steps:
- determination, for said each application currently being executed, of a first execution mode as a function of said response and said selected configuration, said first execution mode corresponding to the nominal mode, to the degraded mode or to a shutdown mode of said each application currently being executed;
- determination of a duration required (Δ) for the implementation of the selected configuration based on the first execution modes determined for the set of applications currently running and said second information received;
- comparison of said duration required (Δ) for the implementation of said selected configuration with said maximum time (T),
the implementation of said configuration being determined as feasible when said duration necessary for the implementation of the selected configuration is less than said maximum time. The method of claim 2, wherein, when implementing the selected configuration is feasible, said method further comprises the following steps:
- transmission, to said each application currently running, of a second reconfiguration request according to said first determined execution mode;
- control of processing of a set of data packets emitted by at least part of said set of applications running on said network infrastructure;
- implementation of said selected configuration at the level of said network infrastructure following an end of processing of said set of data packets;
- implementation of a determined stabilization period 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. The method of claim 2 or 3, 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. The method of claim 3, wherein said second request is transmitted after a period corresponding to the minimum period of greatest value included in said first and second responses. Method according to one of claims 2 to 5, for which a priority level is associated with at least part of said set of applications, the determination of said first execution mode being furthermore a function of said priority level. Computer-readable recording medium on which is recorded a computer program comprising instructions for carrying out the steps of the method according to any one of claims 1 to 6. 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. Device (4) for controlling the configuration of a network infrastructure of a vehicle, said device (4) comprising a memory (41) associated with at least one processor (40) configured for implementing the steps of the method according to any one of claims 1 to 6. Vehicle (10) comprising the device (4) according to claim 9.