Processing method and device for vehicle software update

Abstract

The present invention relates to a method and a processing device (10) for assisting in updating at least one software (PG1) of at least one vehicle (2), said method comprising: determining a number N of possible versions (V) that said at least one software (PG1) may have, N being an integer at least equal to 2; determining an update profile defining at least one condition to be met by an update (OP) of said at least one software (PG1); determining, from the number N and the update profile, a complexity index (C) representative of a complexity of said at least one software (PG1); and evaluating a capacity (RS) to update said at least one software (PG1) by comparing the complexity index (C) with a reference value. Figure for abstract: Figure 1

Description

Title of the invention: Processing method and device for vehicle software update Technical field

[0001] The present invention relates to processing methods and devices for assisting in updating one or more vehicle software programs, and in particular but not exclusively for automobile-type vehicles. The invention aims in particular at evaluating or monitoring the complexity of at least one software program that can be implemented in one or more vehicles to assist in updating the software program(s). Technological background

[0002] Current vehicles, particularly automobiles or equivalent, are becoming more complex over time and are increasingly software-oriented. Thus, the development of certain new vehicle architectures is accompanied by the implementation of new technological platforms implementing software of various types configured to implement very varied functions.

[0003] The increasing presence of software in vehicles requires frequent software updates in order to carry out maintenance (for cybersecurity purposes, for example) and the necessary corrections on this software (corrections of defects or bugs, for example) and to regularly introduce improvements (new functionalities, for example). For this purpose, wireless communication technologies (also known as OTA for "Over The Air" in English) can be used to remotely transfer software or data to / from a vehicle, and thus carry out the necessary software updates. It is thus possible to update vehicles throughout their life cycle and thus ensure an optimal experience for the user.

[0004] However, the maintenance, and in particular the keeping up to date, of vehicle software constitutes a significant challenge due in particular to the increasing complexity of vehicles and their on-board software. Thus, the increase in the number of computers on board vehicles, the growing sophistication of software or even the interdependence of computers with each other imposes strong constraints on the maintenance of this software and can make software updates difficult.

[0005] These difficulties also result from the fact that software and hardware embedded in vehicles are often closely correlated and dependent on each other in many existing vehicle architectures. This hinders the ability of market players to evolve software without impacting or modifying Hardware. In a context where vehicles are increasingly becoming service providers, it is necessary to be able to upgrade vehicle software throughout the vehicle's lifespan, if possible without changing the hardware.

[0006] These difficulties are likely to increase significantly in the future. It is critical to be able to ensure these updates effectively in order to enable stakeholders to continue to innovate, develop and maintain high-performance, high-quality vehicles. Summary of the present invention

[0007] It has been found that the ability to maintain and upgrade software embedded in vehicles is closely dependent on the complexity of the software in question. Software of limited complexity is notably easier to keep up to date. Low complexity of vehicle software also results in better quality and reliability of vehicles (fewer bugs, etc.) and reduced maintenance costs as well as a better customer experience.

[0008] It has also been observed that it is possible to evaluate the complexity of software based on the algorithm level of the code content, which however requires the use of particularly complex algorithms and therefore difficult to implement (use for example of neural networks to measure software complexity). Such algorithms require a specific software framework that must be set up and developed, which imposes significant costs in resources (time, hardware / software, financial, etc.).

[0009] One of the objects of the present invention is to solve at least one of the problems or deficiencies of what has been described previously.

[0010] Another object of the present invention is to improve software maintenance in one or more vehicles, for example but not exclusively of the automobile type, in particular to allow rapid and efficient software updates.

[0011] Another object of the present invention is to assist in updating at least one software implementable (or implemented) in one or more vehicles, with a view to enabling rapid and efficient software updates.

[0012] According to a first aspect, the present invention relates to a processing method implemented by a processing device to help update at least one software implementable in a group of at least one vehicle, said method comprising: - determining a number N of possible versions that said at least one software can have, N being an integer at least equal to 2, the N versions being organized in chronological order from an oldest version to a most up-to-date version; - determination of an update profile P defining at least one condition to be met by an update of said at least one software from an initial version to a target version of said software; - determination, from the number N and the profile P, of a complexity index C representative of a complexity of said at least one software; and - assessment of a capacity to update said at least one software by comparing the complexity index C with a reference value.

[0013] The invention advantageously makes it possible to improve software maintenance in one or more vehicles, for example but not exclusively of the automobile type, in particular to allow rapid and efficient software updates. Thanks to the complexity index C which constitutes a new metric taking into account N and P, it is possible to effectively evaluate a capacity to update software in one or more vehicles, such as in a fleet of vehicles for example. It is thus possible to help update at least one software implementable (or implemented) in one or more vehicles, with a view to allowing rapid and efficient software updates. To do this, the processing device simulates or models the update(s) to be carried out on the software(s) by determining a complexity index C as well as an update capacity as previously indicated.In this way, for example, critical situations can be detected and / or a software update strategy adapted. The processing device can optionally be further configured to carry out the updates itself.

[0014] The complexity index C can be determined quickly and reliably. Furthermore, it is possible to apply the processing method to software not yet implemented in vehicles or retroactively to existing software already installed in vehicles.

[0015] The method according to the invention may include other characteristics which may be taken separately or in combination, in particular among the embodiments which follow.

[0016] According to a particular embodiment, the update profile defines at least one of the following conditions: (a) the update is performed incrementally from the initial version to the target version or the update is performed directly from the initial version to the target version; (b) the target version of the update is the most up-to-date version or the target version is any version more up-to-date than the initial version; and (c) the update includes a downgrade of the version of said at least one software from an intermediate version to the final version.

[0017] According to a particular embodiment, N being an integer at least equal to 3 or at least equal to 4.

[0018] According to a particular embodiment, the reference value is a threshold value, the evaluation of said capacity comprising: - issue of an alert if the complexity index C reaches the threshold value.

[0019] According to a particular embodiment, the method comprises at least one of: - evaluation, from the complexity index C and / or the capacity to update, of a capacity to carry out over a given period an update campaign on said at least one software implemented in the group of at least one vehicle; and - definition, from the complexity index C and / or the capacity to update, of a strategy for updating said at least one software implemented in the group of at least one vehicle.

[0020] According to a particular embodiment, the method is such that: - at least two different pairs (N, P) are determined to update said at least one software according to at least two different update configurations respectively; and - a complexity index C is determined for each pair (N, P) respectively; the method further comprising: - determining a complexity ratio between said at least two update configurations by comparing their respective complexity indices.

[0021] According to a particular embodiment, the method comprises: - determination, from the complexity ratio, of the least complex update configuration; and - selection of the least complex update configuration to update said at least one software.

[0022] According to a particular embodiment, the complexity index C is determined from a calculation formula taking N as input, said calculation formula being selected as a function of the update profile P.

[0023] According to a second aspect, the present invention relates to a processing device (or supervision device) for helping to update at least one software implementable in a group of at least one vehicle, the device comprising a memory associated with a processor configured for implementing the steps of the processing method according to the first aspect of the present invention.

[0024] It should be noted that the various embodiments mentioned above in relation to the treatment method according to the first aspect of the invention as well as the associated advantages apply in a similar manner to the treatment device according to the second aspect of the invention.

[0025] According to a third aspect, the present invention relates to a computer program which comprises instructions adapted for executing the steps of the processing method according to the first aspect of the present invention, in particular when the computer program is executed by at least one processor. In other words, the different steps of the processing method are determined by computer program instructions. This computer program is configured to be implemented in a processing device of the second aspect of the invention, or more generally in a computer (for example a server).

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

[0027] According to a fourth aspect, the present invention relates to a recording medium (or information medium), readable by the processing device according to the second aspect or more generally by a computer (or a processor), on which is recorded a computer program comprising instructions for executing the steps of the processing method according to the first aspect of the present invention.

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

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

[0030] 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

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

[0032] [Fig. 1] schematically illustrates a processing device configured to assist in updating at least one software implementable in at least one vehicle, according to at least one particular and non-limiting exemplary embodiment of the present invention;

[0033] [Fig.2] schematically illustrates vehicle software as shown in [Fig.l], according to at least one particular and non-limiting exemplary embodiment of the present invention;

[0034] [Fig.3] schematically illustrates the determination of a complexity index, according to at least one particular and non-limiting exemplary embodiment of the present invention;

[0035] [Fig.4] schematically illustrates the determination of a complexity index, according to at least one particular and non-limiting exemplary embodiment of the present invention;

[0036] [Fig.5] schematically illustrates the determination of a complexity index, according to at least one particular and non-limiting exemplary embodiment of the present invention;

[0037] [Fig.6] schematically illustrates the determination of a complexity index, according to at least one particular and non-limiting exemplary embodiment of the present invention;

[0038] [Fig.7] schematically illustrates the determination of a complexity index, according to at least one particular and non-limiting exemplary embodiment of the present invention;

[0039] [Fig.8] schematically illustrates the determination of a complexity index, according to at least one particular and non-limiting exemplary embodiment of the present invention;

[0040] [Fig.9] schematically illustrates the determination of a complexity index, according to at least one particular and non-limiting exemplary embodiment of the present invention;

[0041] [Fig. 10] schematically illustrates a processing device configured to assist in updating at least one software as illustrated in Figures 1-9, according to at least one particular and non-limiting exemplary embodiment of the present invention; and

[0042] [Fig. 11] illustrates a diagram of different steps of a method for processing at least one vehicle software as illustrated in Figures 1-2, according to at least one particular and non-limiting exemplary embodiment of the present invention. Description of examples of implementation

[0043] A method and a device for controlling a vehicle will now be described in the following with reference to Figures 1-11. Unless otherwise indicated, elements common or similar to several figures bear the same reference signs and have identical or similar characteristics, so that these common elements are generally not described again for the sake of simplicity.

[0044] The terms "first(s)", "second(s)", etc.) are used in this document by arbitrary convention to enable different elements (such as operations, computer programs, software versions, etc.) implemented in the embodiments described below to be identified and distinguished.

[0045] As previously indicated, the invention relates in particular to a processing method implemented by a processing device to assist (or simulate, or allow, or facilitate) the updating of at least one software implementable (or implemented) in a group of at least one vehicle, such as automobile or other type vehicles, or more generally in motorized land vehicle type vehicles.

[0046] According to a particular and non-limiting example of embodiment, the treatment method of the present invention comprises: - determination of a number N of possible versions that said at least one software program may present, N being an integer at least equal to 2, the N versions being organized in chronological order from the oldest version to the most up-to-date version; - determination of an update profile P defining at least one condition to be met by an update of said at least one software from an initial version to a target version of said software; and - determination, from the number N and the profile P, of a complexity index C representative of a complexity of said at least one software; and - assessment of a capacity to update said at least one software by comparing the complexity index C with a reference value.

[0047] As indicated previously, it has been observed that the maintenance and evolution capacity of software embedded in vehicles is closely dependent on the complexity of the software concerned. The invention is therefore based in particular on a rapid and efficient solution for evaluating the complexity of one or a plurality of vehicle software programs, in order to help update these software programs. This solution involves in particular the introduction of a new metric representative of the complexity of one or more vehicle software programs. This new metric, called complexity index (or software complexity index), capable of being determined quickly and at low resource cost, makes it possible to reliably represent the complexity of a vehicle software code and / or the complexity of an associated technological platform (for example of the OTA type).

[0048] From this complexity index, it is thus possible to evaluate a capacity to update the software(s) concerned. To do this, a comparison is made between the complexity index and a reference value, the nature of which may vary depending on the case. It is for example possible, from the result of this comparison, to detect or anticipate risks or problems linked to an update or to design or adapt said update before its application to the software(s) concerned.

[0049] Other aspects and advantages of the present invention will emerge from the exemplary embodiments described below with reference to the drawings mentioned above.

[0050] [Fig.l] schematically illustrates a processing device 10 configured to assist or facilitate the updating of at least one software PG1 implementable in a group 3 of at least one vehicle 2. The device 10 and the group 3 of at least one vehicle 2 together form a system SYL

[0051] This processing device (also called modeling device or device) 10 aims firstly to assist or facilitate the updating of the PG1 software(s) intended to be implemented in the vehicles 2. The device 10 can thus simulate or model the update(s) to be carried out on these PGL software. In this way, it is possible in particular to detect critical situations and / or adapt an update strategy. As described in more detail later, the device 10 can optionally be further configured to carry out the updates themselves.

[0052] As illustrated in [Fig.l], a group (or fleet) 3 of a plurality of vehicles 2 is considered here, although the invention is also applicable for a single vehicle 2. In other words, the invention can be applied more generally to a group 3 of at least one such vehicle 2.

[0053] The type and characteristics of the vehicles 2 may be adapted as appropriate. The vehicles 2 are, for example, of the automobile type or equivalent. Alternatively, each vehicle 2 may be a coach, a bus, a truck, a utility vehicle or a motorcycle, or more generally a vehicle of the motorized land vehicle type, or even a maritime (or river) or air vehicle.

[0054] Each vehicle 2 of group 3 has at least one PG1 software package implemented in at least one on-board device 4. It is subsequently considered by way of example that the vehicles 2 each have at least one computer 4 configured to implement a PGL software package. It should be noted, however, that the number of computers and PG1 software packages implemented may vary depending on the case.

[0055] It is subsequently assumed that each computer 4 is configured to implement the same PG1 software, this software possibly comprising a plurality of software or sub-software. As described below, the version of the PG1 software implemented in each vehicle 2 may however vary.

[0056] Each vehicle 2 may for example comprise one or a plurality of computers 4. According to a particular example, the vehicles 2 comprise a central computer 4 cooperating with at least one other secondary computer 4.

[0057] The nature, configuration and operation of the PG1 software implemented in each vehicle 2 may vary depending on the case. This PG1 software may be any computer program, or application, configured to implement at least one appropriate function in the vehicle 2. Among the possible functions, the computers 4 may for example implement control functions of the vehicle (of at least one element of the vehicle), navigation assistance, multimedia content management, etc.

[0058] The processing device 10 may comprise at least one processor and a non-volatile memory (not shown in [Fig.l]). The device 10 is configured to implement a processing method (or process) (also called a modeling method / process) as described below. For this purpose, the device 10 may comprise a second computer program PG2 stored in its non-volatile memory (e.g., Flash or ROM type memory), this computer program PG2 comprising instructions for implementing the processing method (or process) as described below. The processor of the device 10 may thus be configured to execute in particular the instructions defined by the computer program PG2.

[0059] The processing device 10 may be any device, such as a computer or server for example, capable of implementing the processing method (or process) of the invention. This device 10 may for example take the form of a (or comprise a) calculator, or a combination of calculators. At least one example of implementation of the device 10 is described later.

[0060] As illustrated in [Fig.l], the device 10 can further be configured to perform at least one update OP operation in cooperation with the vehicles 2 of the group 3, in order to update the on-board software PG1. An update OP operation is configured to update at least one PG1 software.

[0061] Such an OP operation (figures 1-2) may comprise for example the sending and / or receiving of data to and / or from at least one vehicle 2. To do this, it is subsequently assumed that the device 10 comprises interface means for cooperating with the vehicles 2, or more particularly with the computers 4, via appropriate communication channels. These communication channels established between the device 10 and the vehicles 2 may for example be of the wireless type. In other words, the device 10 may for example be configured to communicate in OTA (“Over The Air”) mode with the vehicles 2 (or with their computers 4) to carry out OP operations for updating the PG1 software.

[0062] In this document, an update may cover any OP operation of modification, alteration, improvement, correction, etc. of a PG1 software.

[0063] As illustrated in [Fig.2], each PG1 vehicle software has (or is characterized by) a software version generally noted V, or more precisely V; where i is an integer (or index) between 1 and N. N is considered an integer at least equal to 2. According to a particular example, N is at least equal to 3 or at least equal to 4. The number N can be adapted according to the case.

[0064] In the following, it is assumed for illustrative purposes that N = 4, although other examples are possible. In other words, the PG1 software of each vehicle 2 may have any one of the possible versions Vb V2, V3 and V4.

[0065] Thus, there is a number N (=4) of possible versions V that each software PG1 can present. These N possible software versions are organized in chronological order (i.e., an increasing order of update) from an oldest version Vi to a most up-to-date version VN (i.e., the most recent version). In the following, it is thus considered as an example that the versions VrVN are classified in the following chronological order: Vj, V2, V3 and V4.

[0066] As illustrated in [Fig.2] according to a particular example, an OP update (or update operation) is configured to modify the version of a vehicle software PG1. Thus, an OP update converts a PG1 software from an initial version (or starting version) Va into a target version (or final version) Vb. As described below, an OP update may in certain examples be carried out via at least one intermediate version between the initial version Va and the target version Vb. According to other examples, an OP update may be carried out directly from the initial version Va into the target version Vb, i.e. without the PG1 software being converted into any intermediate version during the update process.

[0067] As indicated above, the device 10 is configured to implement a processing (or modeling) process. This process is now described in conjunction with FIGS. 1 and 2 according to particular embodiments.

[0068] As already indicated, it is assumed subsequently that the processing process aims in particular to help update a PG1 software implementable in the vehicles 2, and more particularly, executable by the on-board devices 4. PG1 therefore designates here the same software implementable in each vehicle 2 but whose version V can vary from one vehicle 2 to another (between versions Vi and VN=V4 inclusive).

[0069] This PG1 software may already be implemented in all or part of the vehicles 2 when the processing process is carried out. Alternatively, the processing process may be carried out even before the PG1 software is implemented or loaded into the vehicles 2.

[0070] In a first operation, the processing device 10 determines the number N of possible versions V that the PG1 software can present (or implemented) in the group 3 of vehicles 2. As already indicated, N is an integer at least equal to 2 and the N versions V are organized in chronological order from an oldest version to a most up-to-date version. We then consider that N=4 and that the VrVN versions are classified in the following chronological order: Vi, V2, V3 and V4.

[0071] The number N can be determined in various ways depending on the case considered. For example, the device 10 can retrieve the number N by consulting a local memory, or can receive this value in the form of an instruction (for example a user instruction), or can still receive this value from an external entity.

[0072] In a second operation, the processing device 10 determines an update profile P (or an update policy, or an update configuration) defining at least one condition to be respected by an update OP of the software PG1 in the vehicles 2 from an initial version Va to a target version Vb. It is considered in the following that the target version Vb is more advanced than the initial version Va according to the chronological order of the versions V.

[0073] The update profile P defines how the OP update should be performed from version Va to version Vb. Various update configurations are possible depending on the situation and requirements and can therefore be adapted on a case-by-case basis.

[0074] According to a particular example, the update profile P defines at least one of the following conditions: al) the OP update is performed incrementally from the initial version Va to the target version Vb or a2) the update is performed directly from the initial version Va to the target version Vb; bl) the target version Vb of the OP update is the most up-to-date version or b2) the target version Vb is any version more up-to-date than the initial version Va; and c) the update includes a downgrade of the PG1 software version from an intermediate version to the final version Vb.

[0075] According to a particular example, the profile P defines at least either the condition a1), or the condition a2).

[0076] According to a particular example, the profile P defines at least either the condition b1), or the condition b2).

[0077] According to a particular example, the profile P defines at least the condition c).

[0078] According to a particular example, the profile P defines any combination or subcombination among conditions al)-a2), b 1 )-b2) and c).

[0079] A so-called incremental OP update means that the transition from the initial version Va to the final version Vb is done by successively passing through each intermediate version V located (if applicable) between Va and Vb according to the chronological order of the versions V (i.e. by passing one by one the versions from Va to Vb according to the chronological order). For example, an incremental update from Va=Vi to Vb=V4 involves the successive conversions of the PG1 software from version Vi to V2, then from V2 to V3, then from V3 to V4, which can be symbolized by Vi to V2 to V3 to V4. The same formalism for representing the successive stages of an OP update will be adopted in what follows.

[0080] On the contrary, a direct OP update means that the transition from the initial version Va to the final version Vb is done without going through any intermediate version V likely to be located between Va and Vb according to the chronological order of the versions V. For example, a direct update from Va=Vi to Vb=V4 implies the direct conversion of the PG1 software from version Vi to V4 without going through either V3 or V4, which can be symbolized by Vi to V4.

[0081] As expressed above in condition bl), an OP update may require that the PG1 software be systematically updated to the most up-to-date version, namely VN=V4 in this example. On the contrary, an OP update may authorize that the PG1 software be converted to a more up-to-date version than the initial version Vb but not necessarily the most up-to-date version V, namely VN=V4 in this example.

[0082] As expressed above in condition c), an OP update may comprise a downgrade of the version of the PG1 software (in other words a version rollback according to the chronological order of the versions V) from an intermediate version to the final version Vb. For example, such an OP update may be carried out from Va=Vi to Vb=V3 with successively a conversion - direct for example - from Vi to V4 (intermediate version) then a downgrade from V4 to V3, which may be symbolized by Vi to V4 to V3.

[0083] Downgrading the version may be useful or desirable in certain situations, for example for security reasons, technical reasons, reasons relating to the quality of a service implemented by the PG1 software, or to configure the software according to specific constraints (customer wishes, etc.).

[0084] In a third operation, the processing device 10 determines, from the number N and the profile P, a complexity index C representative of a complexity of the software PG1. To do this, the device 10 can apply a calculation method (or algorithm) which takes as input the parameter N and which at least one parameter defined by the update profile P.

[0085] It has been observed in particular that there is a correlation between the complexity of the PG1 software and the number N of possible versions of the software at a given time. Thus, the complexity of the PG1 software increases with the number N. In addition, the complexity of the PG1 software is linked to the update strategy that is applied. For example, it is more complex to update the PG1 software incrementally than directly because of the need to convert the software by versions intermediate between Va and Vb if Va and Vb are not two consecutive versions according to the chronological order of the versions. The device 10 can therefore be configured to implement a modeling algorithm which takes into account the parameters N and P to determine the complexity index C of the PG1 software.

[0086] The complexity index C can in particular be defined (or calculated) so as to be representative (or a function) of the number of possible paths (or links) between the different versions V (VrVN) of the PGL software. This number of paths depends on the number N of possible versions V and the update profile P applied.

[0087] Note that the profile P can be defined by at least one parameter representative of the aforementioned condition(s). According to a particular example, the device 10 selects the calculation method (or calculation algorithm), used to determine the complexity index C, as a function of the update profile P, or more precisely as a function of the condition(s) that the update OP must respect in accordance with said profile P. Thus, the calculation method (or algorithm) used can vary as a function of the profile P applied in order to take into account the specificities of the update OP.

[0088] Examples of determining the complexity index C will be described below in particular embodiments.

[0089] In a fourth operation, the device 10 evaluates a capacity RS to update at least one software by comparing the complexity index C with a reference value ([Fig. 1]). It is thus possible to assess the feasibility or the difficulty of updating a PG1 software for a vehicle from a modeling of said software, or a modeling of the update of this software.

[0090] The device 10 can thus help (or simulate, or facilitate) the updating of the PG1 software implementable (or implemented) in the vehicles 2. From the complexity index C, the device 10 can evaluate a capacity RS to update the PG1 software by comparing the complexity index C and a reference value whose nature can vary depending on the case. It is for example possible, from the result of this comparison, to detect or anticipate risks or problems linked to an OP update or to design or adapt said OP update even before its application to the PGL software.

[0091] According to a particular example, the evaluation of the RS capacity to update the PG1 software can also take into account resources available at a given time or over a given period of time. Thus, the greater the available resources, the greater the RS capacity.

[0092] The reference value used during the fourth operation may for example be a threshold value. Thus, the evaluation of the capacity RS to update the software PG1 may comprise the emission of an alert AL ([Fig.l]) by the device 10 if the complexity index C reaches (or is greater than or equal to) the threshold value. In this way, a critical situation in which it would be particularly difficult to perform the OP update can be detected, anticipated and / or avoided. The reference value can, for example, be predefined to allow the detection of a possible explosion (or peak) in the complexity of the PG1 software which would result in a reduced capacity to update the software. Conversely, it is thus possible to detect or confirm that an OP update can be performed without difficulty or with acceptable efficiency.

[0093] The result of the evaluation carried out during the fourth operation can for example be used to adapt the update OP and / or design an update strategy applicable to the software PG1, for example by adapting the update profile P and / or the number N of possible versions.

[0094] The result of the evaluation carried out during the fourth operation can for example be used to control the OP update of the PG1 software, for example by blocking or deferring this update or by adapting its configuration.

[0095] According to a particular example, the complexity C and / or the capacity RS can be used to guide the development of an update strategy for the software PG1 in the vehicle fleet 2.

[0096] According to a particular example, the complexity C and / or the capacity RS can be used to evaluate a capacity to carry out over a given period an update campaign on the PG1 software implemented in group 3 of vehicles 2.

[0097] According to a particular example, the complexity C and / or the capacity RS may be used to select one of at least two different update configurations for updating the software PG1. Each update configuration may be defined by a respective pair (N; P) defining the number N of possible versions and the update profile P used.

[0098] According to a particular example, the device 10 determines at least two different pairs (N, P) for updating the software PG1 according to respectively at least two different update configurations, and determines a complexity index C for respectively each pair (N, P). The device 10 can thus determine a superiority ratio (or complexity ratio) between said at least two update configurations by comparing their respective complexity indices C. It can thus be determined for example that a first update configuration has a higher complexity C than that of a second update configuration. This ratio can define an order of complexity between a plurality of different update configurations.From the superiority ratio thus determined, the device 10 can select one or other of the update configurations, for example the one having the lowest complexity index or the one satisfying at least one predefined criterion taking this superiority ratio into account.

[0099] According to a particular example, the device 10 further determines, from the aforementioned complexity ratio, the least complex update configuration, and selects the least complex update configuration to update the PG1 software.

[0100] According to a particular example, after the fourth operation, the device 10 performs the OP update on the PG1 software implemented in the vehicles 2, possibly after having adapted or controlled this update as a function of the RS capacity and / or the complexity index C (as previously described). This OP update is for example performed by contactless communication (OTA mode) between the device 10 and the vehicles 2 (or with their on-board computers 4 via communication interfaces).

[0101] The processing process described above in particular embodiments advantageously makes it possible to improve software maintenance in one or more vehicles 2, for example but not exclusively of the automobile type, in particular to allow rapid and efficient software updates. Thanks to the complexity index C which constitutes a new metric taking into account N and P, it is possible to effectively evaluate a capacity RS to update a software PG1 in one or more vehicles, such as in a vehicle fleet for example. It is thus possible to help update at least one software implementable (or implemented) in one or more vehicles 2, with a view to allowing rapid and efficient software updates. To do this, the device 10 simulates or models the update(s) to be carried out on the software PG1 by determining a complexity index C as well as an update capacity RS as previously described.In this way, for example, critical situations can be detected and / or a software update strategy adapted. The device 10 can optionally be further configured to carry out the updates themselves.

[0102] The complexity index C can be determined quickly and reliably. Furthermore, it is possible to apply the processing procedure to software not yet implemented in vehicles 2 or retroactively to existing software already installed in vehicles 2.

[0103] Examples of carrying out the third operation of the processing process, namely the determination of the complexity index C, are now described below in conjunction with Figures 3-9. In these examples, the complexity index is determined by applying a calculation method taking as input the number N (where N=4 in the examples considered), said calculation method being selected as a function of the update profile P applied. Thus, various calculation methods are described for different update profiles P applied.

[0104] For example, we can consider that all possible versions (VrVN) of the PG1 software are compatible with each other, although variants are possible where this is not the case. In the case of compatibility between V versions, this means that all V versions share the same architecture and that we can move from one version to another by going up or down in the chronological order of the versions (upward and downward compatibility according to the chronological order).

[0105] As illustrated in [Fig.3] in a particular embodiment, it is considered that, in accordance with the update profile P, the update OP - noted OP1 - must be carried out incrementally from the initial version Va to the target version Vb (condition al)) and the target version Vb is necessarily the most up-to-date version VN (condition bl)), namely V4 in this example.

[0106] Also, in this example, the update OP1 can be any one of: VI to V2 to V3 to V4; V2 to V3 to V4; and V3 to V4.

[0107] In this case, the following calculation method is selected:

[0108] [Math.l] C = N*(Nl) / 2

[0109] In the example considered, the complexity index C is therefore equal to 6.

[0110] Once the complexity index C has been determined, the number N can be initialized to 0. Thus, during a next iteration of the processing process, the fact that the software has already been updated to version V4 will be taken into account.

[0111] As illustrated in [Fig.4] in a particular embodiment, it is considered that, in accordance with the update profile P, the update OP - noted OP2 - must be carried out directly (condition a2)) and the target version Vb is necessarily the most up-to-date version VN (condition bl)), namely V4 in this example.

[0112] Also, in this example, the OP2 update can be any one of: VI to V4; V2 to V4; and V3 to V4.

[0113] In this case, the following calculation method is selected:

[0114] [Math.2] C = N-1

[0115] In the example considered, the complexity index C is therefore equal to 3. The complexity of the software is lower here than in the example of [Fig.3] due to the fact that the possible update paths are more limited in number and simpler.

[0116] Once the complexity index C has been determined, the number N can be initialized to 1 in order to carry out a new iteration of the processing process.

[0117] As illustrated in [Fig.5] in a particular embodiment, it is considered that, in accordance with the update profile P, the update OP - noted OP3 - must be carried out incrementally from the initial version Va to the target version Vb (condition a1)) and the target version Vb is any version more up to date than the initial version Va (condition b2)).

[0118] Also, in this example, the OP3 update can be any one of: VI to V2; VI to V2 to V3; VI to V2 to V3 to V4; V2 to V3; V2 to V3 to V4; and V3 to V4.

[0119] The incremental nature of the update allows for good traceability of the history of the versions of the PG1 software of each vehicle 2. On the other hand, this imposes a constraint in that it is necessary to keep available all possible versions V which are not the most up-to-date version.

[0120] In this case, the following calculation method is selected:

[0121] [Math.3] C = N*(Nl) / 2

[0122] In the example considered, the complexity index C is therefore equal to 6.

[0123] Once the complexity index C has been determined, we can, for example, keep the number N unchanged (N is not reset for a future iteration of the processing process).

[0124] As illustrated in [Fig.6] in a particular embodiment, it is considered that, in accordance with the update profile P, the update OP - noted OP4 - must be carried out directly from the initial version Va to the target version Vb (condition a2)) and the target version Vb is any version more up to date than the initial version Va (condition b2)).

[0125] Also, in this example, the OP4 update can be any one of: VI to V2; VI to V3; VI to V4; V2 to V3; V2 to V4; and V3 to V4.

[0126] The direct nature of the update makes it possible to limit the complexity of the software and therefore to facilitate updates. On the other hand, this requires keeping old versions V of the software available. In addition, the different vehicles 2 of the fleet 3 may be inhomogeneous in terms of the version V implemented. Multiple different versions of the PG1 software can therefore be installed across the fleet 3 of vehicles 2.

[0127] In this case, the following calculation method is selected:

[0128] [Math.4] C = N>(Nl) / 2

[0129] In the example considered, the complexity index C is therefore equal to 6.

[0130] Once the complexity index C has been determined, the number N can, for example, be kept unchanged for a subsequent iteration of the processing process.

[0131] As illustrated in [Fig.7] in a particular embodiment, it is considered that, in accordance with the update profile P, the update OP - noted OP5 - must be carried out incrementally from the initial version Va to an intermediate version corresponding to the most up-to-date version, namely VN=V4 in this example (this first phase corresponds for example to the example of [Fig.3]). The update OP5 further comprises a downgrade of the software version PG1 from the intermediate version to the target version Vb (condition c)). This downgrade (downward update following the order of the versions) can be a rollback of d versions V from the intermediate version, where d is an integer number of downgrades such that d < N.

[0132] Also, in this example, the OP5 update can be any one of: VI to V2 to V3 to V4 to V3; and V2 to V3 to V4 to V3; or possibly also V3 to V4 to V3 if we consider that the particular case where Va=Vb constitutes in itself an update operation.

[0133] This scenario therefore comprises two stages, namely an upgrade from version V according to the chronological order of the versions up to an intermediate version then a descent towards the target version Vb. Such a downgrade can be advantageous as already explained previously.

[0134] In this case, the following calculation method is selected:

[0135] [Math.5] C = d>(Nd)+N> (Nl) / 2+d^dl) / 2

[0136] whered <n.

[0137] In the example considered, in the case where d=1, the complexity index C is therefore equal to (4-1) + 4(4-1) / 2 + 0 = 9.

[0138] Once the complexity index C has been determined, the number N can, for example, be kept unchanged for a subsequent iteration of the processing process.

[0139] As illustrated in [Fig.8] in a particular embodiment, it is considered that, in accordance with the update profile P, the update OP - noted OP6 - must be carried out directly from the initial version Va to an intermediate version corresponding to the most up-to-date version, namely VN=V4 in this example. The update OP6 further comprises a downgrade of the software version PG1 from the intermediate version to the target version Vb (condition c)). This downgrade (downward update following the order of the versions) can be a drop of d versions V from the intermediate version, where d is an integer number of downgrades such that d <n.

[0140] We consider as an example that d = 1. Also, in this example, the update OP6 can be any one of: VI to V4 to V3; V2 to V4 to V3; and V3 to V4 to V3.

[0141] This scenario therefore comprises two stages, namely an upgrade from version V according to the chronological order of the versions up to an intermediate version then a descent towards the target version Vb. Such a downgrade can be advantageous as already explained previously.

[0142] In this case, the following calculation method is selected:

[0143] [Math.6] C = 2« (AM)

[0144] In the example considered, in the case where d=1, the complexity index C is therefore equal to 6.

[0145] Once the complexity index C has been determined, the number N can for example be reset to 2 for a subsequent iteration of the processing process.

[0146] As already indicated, the invention can be applied to a plurality of PG1 software programs that can be implemented (or implemented) in each vehicle 2.

[0147] According to a particular example, the group 3 comprises a plurality of vehicles 2 and a plurality of PG1 software programs are implementable in each vehicle 2. During the processing process, the device 10: - determines a number N and an update profile P to respectively update each PG1 software; - determines a complexity index C for each PG1 software to be updated; and - determines, from the sum S of the complexity indices C, an overall complexity index representative of the complexity of updating the plurality of PG1 software.

[0148] As illustrated in [Fig.9] in a particular embodiment, the device 10 can thus respectively determine a complexity index C; to carry out an update OP - noted OP7-i - for each PG1 software implementable in a given vehicle 2, where i is an integer between 1 and M, M being the number of PG1 software considered per vehicle 2.

[0149] In this case, the complexity index of the set of PG1 software can be expressed as follows:

[0150] [Math.7] ^ = 2(^1+^+^3--)

[0151] By thus summing the complexity indices for each PG1 software (for example in as many computers 4 of a vehicle 2), it is thus possible to evaluate the complexity associated with all of the PG1 software and to deduce a capacity RS to update this set of software by comparing the overall complexity index with a reference value as already described.

[0152] This variant is advantageous insofar as vehicles are increasingly evolving towards a situation of updating several computers at the same time. Thus, a global package of update data can be sent to a vehicle 2. A central computer of the vehicle 2 can then be configured to address the software concerned to the other computers concerned of the vehicle 2. This package solution can advantageously help to reduce the complexity of the deployment of updates, in particular due to the fact that the package can contain software that is consistent with each other. On the other hand, this package update technique does not necessarily reduce the complexity from the point of view of the implementation variants (dedicated packages necessary for a subset of vehicles).

[0153] According to a particular example, the respective complexity indices C of several computers 4 are taken into account because the computers have dependencies between them. The overall complexity index C can integrate the complexity level of each individual computer. The data packets transmitted by the device 10, possibly by contactless communication (OTA), can then be composed of a set of software versions. However, there may be a significant increase in the number of data packets. This may result in the summation of the complexity of several computers in a software upgrade packet.

[0154] In a particular example, we can consider an OP update which respects a hybrid incremental mode, that is to say with a level corresponding to 2 versions (Vi+2) or plus (Vi+3, etc.) per version jump. The method for calculating the complexity index C can then be calculated in a similar way to what is described in this document for a classic incremental mode with a level corresponding to 1 version V per version jump.

[0155] [Fig. 10] schematically illustrates a processing device 10 configured to assist in a software update, as previously described with reference to Figures 1-9, according to a particular and non-limiting exemplary embodiment of the present invention. The device 10 corresponds for example to a server remote from the vehicle(s) 2, for example a computer.

[0156] The processing device 10 is for example configured for implementing the operations of the processing process (or modeling process) as previously described with reference to FIGS. 1-9 and / or the steps of the method described below with reference to [Fig. 1 1]. Examples of such a processing device 10 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 smartphone, a tablet, a laptop. The elements of the control device 10, individually or in combination, may be integrated into a single integrated circuit, into several integrated circuits, and / or into discrete components.The processing device 10 can be produced in the form of electronic circuits or software (or computer) modules or even a combination of electronic circuits and software modules.

[0157] The processing device 10 comprises one (or more) processor(s) 40 configured to execute instructions for carrying out the steps of the processing method (or process) and / or for executing the instructions of the software(s) embedded in the processing device 10. The processor 40 may include integrated memory, an input / output interface, and various circuits known to those skilled in the art. The processing device 10 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.

[0158] The computer code of the embedded software(s) comprising the instructions to be loaded and executed by the processor 40 is for example stored on the memory 4L. The memory 41 can constitute an information medium according to a particular embodiment in that it comprises a computer program (for example PG2 in [Fig.l]) comprising instructions for carrying out the steps of the control method (or process) of the invention.

[0159] According to various particular and non-limiting embodiments, the processing device 10 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.

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

[0161] According to another particular and non-limiting embodiment, the processing device 10 comprises a communication interface 43 which makes it possible to establish communication with other devices via a communication channel 45. The communication interface 43 corresponds for example to a transmitter configured to transmit and receive information and / or data via the communication channel 45. 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), Ethernet (standardized by the ISO / IEC 802-3 standard) or LIN (Local Interconnect Network).

[0162] The processing device 10 cooperates for example with the vehicles 2 by means of the block 42 of interface elements or the communication interface 43, as described previously.

[0163] According to a particular and non-limiting exemplary embodiment, the processing device 10 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 (projection system) via respective output interfaces. According to a variant, one or other of the external devices is integrated into the control device 10.

[0164] [Fig. 11] illustrates a diagram of the different stages of a treatment process for updating at least one software, such as for example the PG1 software in the vehicle(s) 2 as previously described. The method is for example implemented by the processing device 10 previously described, this device being able to be a server remote from the vehicles 2.

[0165] In a first step 51, a number N of possible versions that said at least one PG1 software program can present is determined, N being an integer at least equal to 2, the N versions being organized in chronological order from an oldest version to a most up-to-date version.

[0166] In a second step 52, an update profile P is determined, this profile P defining at least one condition to be respected by an update OP of said at least one software PG1 from an initial version Va to a target version Vb of said software

[0167] In a third step 53, a complexity index C representative of a complexity of said at least one software PG1 is determined from the number N and the profile P.

[0168] In a third step 54, a capacity to update said at least one PG1 software is evaluated by comparing the complexity index C with a reference value.

[0169] According to alternative embodiments, the variants and examples of the operations described above in relation to figures 1-10 apply to the steps of the treatment method of [Fig.1 1].

[0170] As understood by a person skilled in the art, all the embodiments and variants described above, some of which have been deliberately simplified to facilitate explanations, constitute only non-limiting examples of implementation of the present disclosure. In particular, a person skilled in the art may envisage any adaptation or combination of the embodiments and variants described above, in order to meet a particular need.

[0171] The present invention is therefore not limited to the embodiments described above but extends in particular to a treatment method which would include secondary steps without thereby departing from the scope of the present invention. The same would apply to a device configured for the implementation of such a method.

Claims

Claims

1. Processing method implemented by a processing device (10) to help update at least one software (PG1) implementable in a group (3) of at least one vehicle (2), said method comprising: - determining (51) a number N of possible versions (V) that said at least one software can have, N being an integer at least equal to 2, the N versions being organized in chronological order from an oldest version to a most up-to-date version; - determining (52) an update profile P defining at least one condition to be respected by an update (OP) of said at least one software from an initial version (Va) to a target version (Vb) of said software;- determination (53), from the number N and the profile P, of a complexity index C representative of a complexity of said at least one software (PG1), the complexity index C being representative of a number of possible paths between the different versions (V) of the software (PG1); and - evaluation (54) of a capacity (RS) to update said at least one software by comparison of the complexity index C with a reference value, the evaluation of said capacity (RS) to update the software taking into account resources available at a given time or over a given period of time, in which the reference value is a threshold value, the evaluation of said capacity (RS) comprising: - emission of an alert (AL) if the complexity index C reaches the threshold value.;

2. Method according to claim 1, wherein the update profile (P) defines at least one of the following conditions: a) the update is performed incrementally from the initial version (Va) to the target version (Vb) or the update is performed directly from the initial version (Va) to the target version (Vb); b) the target version (Vb) of the update is the most up-to-date version or the target version (Vb) is any version more up-to-date than the initial version (Va); and (c) the update (OP) includes a downgrade of the version of said at least one software from an intermediate version to the final version (Vb).

3. Method according to claim 1 or 2, N being an integer at least equal to 3 or at least equal to 4.

4. Method according to any one of the preceding claims, in which the method comprises at least one of: - evaluation, from the complexity index C and / or the capacity (RS) to update, of a capacity to carry out over a given period an update campaign on said at least one software implemented in the group of at least one vehicle; and - definition, from the complexity index C and / or the capacity (RS) to update, of an update strategy for said at least one software (PG1) implemented in the group of at least one vehicle.

5. Method according to any one of the preceding claims, in which: - at least two different pairs (N, P) are determined to update said at least one software (PG1) according to respectively at least two different update configurations; and - a complexity index C is determined for respectively each pair (N, P); the method further comprising: - determining a complexity ratio between said at least two update configurations by comparing their respective complexity indices.

6. Method according to claim 5, comprising: - determining, from the complexity ratio, the least complex update configuration; and - selecting the least complex update configuration for updating said at least one software (PG1).

7. Method according to any one of the preceding claims, in which the complexity index C is determined from a calculation formula taking N as input, said calculation formula being selected as a function of the update profile P.

8. Processing device (10) for assisting in updating at least one software (PG1) implemented in a group (3) of at least one vehicle (2), said device (10) comprising a memory (41) associated with at least one processor (40) configured for the implementation of the steps of the method according to any one of claims 1 to 7.

Images