Processing method and device for vehicle software updating

Abstract

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

Description

DESCRIPTION Title: Processing method and device for vehicle software update The present invention claims priority from French application 2300328 filed on 13.01.2023, the content of which (text, drawings and claims) is incorporated herein by reference. 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 using software of various types configured to implement very varied functions.

[0003] The increasing presence of software in vehicles requires frequent software updates, in particular to carry out maintenance (for cybersecurity purposes, for example) and the necessary corrections to 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 software updates. necessary. This makes it possible to update vehicles throughout their life cycle and thus ensure an optimal user experience.

[0004] However, maintaining, and in particular keeping up to date, vehicle software is a significant challenge, particularly due to the increasing complexity of vehicles and their embedded software. Thus, the increase in the number of computers embedded in vehicles, the growing sophistication of software and the interdependence of computers between them impose significant constraints on the maintenance of this software and can make software updates difficult.

[0005] These challenges also arise from the fact that in-vehicle software and hardware are often closely interrelated and dependent on each other in many existing vehicle architectures. This hinders the ability of market players to upgrade software without impacting or modifying hardware. As vehicles increasingly become service providers, it is necessary to be able to upgrade vehicle software throughout the vehicle's lifetime, preferably without changing 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 maintainability and upgradeability of embedded software in vehicles is closely dependent on the complexity of the software in question. In particular, software with limited complexity is easier to keep up to date. Lower vehicle software complexity also results in better vehicle quality and reliability (fewer bugs, etc.), lower maintenance costs, and a better customer experience.

[0008] It has also been observed that it is possible to assess the complexity of software based on the algorithmic level of the code content, which requires However, the use of particularly complex algorithms and therefore difficult to implement (for example, the use of neural networks to measure software complexity). Such algorithms require a specific software framework that must be implemented and developed, which imposes significant resource costs (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: - 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; - 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 enable fast 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 vehicle fleet for example. It is thus possible to help update at least one implementable (or implemented) software in one or more vehicles, with a view to enabling fast 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, it is possible, for example, to detect critical situations and / or adapt a software update strategy. The processing device may optionally be further configured to carry out the updates themselves.

[0014] The complexity index C can be determined quickly and reliably. In addition, the processing method can be applied 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 comprises 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, based on 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, based on 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 respectively (N, P); 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 according to 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 may 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 can be any entity or device capable of storing the program. For example, the medium can include a storage medium, such as a ROM memory, a CD-ROM or a microelectronic circuit type ROM memory, or a magnetic recording medium 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 a network such as the Internet.

[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 Figure 1, 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 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 identify and distinguish different elements (such as operations, computer programs, software versions, etc.) implemented in the embodiments described below.

[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 previously indicated, 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] Based on this complexity index, it is possible to assess the ability 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. For example, based on the result of this comparison, it is possible to detect or anticipate risks or problems related 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] Figure 1 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 SY1.

[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 PG1 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 Figure 1, we consider here a group (or fleet) 3 of a plurality of vehicles 2, 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 PG1 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 software PG1, this software possibly comprising a plurality of software or sub-software. As described below, the version of the software PG1 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 vehicle control functions (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. 1). 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 (Flash or ROM type memory for example), this computer program PG2 comprising instructions for implementing implementation of the processing method (or process) as described below. The processor of the device 10 can 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. 1, 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 Figure 2, each PG1 vehicle software has (or is characterized by) a software version generally noted V, or more precisely Vi where i is an integer number (or index) between 1 and N. We consider N 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. That is, the PG1 software of each vehicle 2 can have any of the possible versions Vi, V2, V3 and V4.

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

[0066] As illustrated in Figure 2 according to a particular example, an OP update (or update operation) is configured to modify the version of a vehicle PG1 software. 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 some examples be performed 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 performed 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 subsequently assumed that the processing process aims in particular to help update 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 V1 and VN=V4 inclusive).

[0069] This PG1 software may already be implemented in all or some of the vehicles 2 when the treatment process is carried out. Alternatively, the treatment 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 software PG1 can have that can be implemented (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. It is subsequently considered that N=4 and that the versions VI-VN 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: a1) the update OP is carried out incrementally from the initial version Va to the target version Vb or a2) the update is carried out directly from the initial version Va to the target version Vb; b1) 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, profile P defines at least either condition b1) or condition b2).

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

[0078] According to a particular example, the profile P defines any combination or sub-combination among the conditions a1)-a2), b1)-b2) and c).

[0079] An 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 any) 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 V-, -> V2 -> V3 -> 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 V1 to V4 without going through either V3 or V4, which can be symbolized by V1 V4.

[0081] As expressed above in condition b1), 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 software version PG1 (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 V1 -> V4 -> V3.

[0083] Downgrading a 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] In particular, it has been observed 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 due to the need to convert the software by intermediate versions 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 that 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 (VI-VN) of the PG1 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 OP update 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 OP update.

[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 (figure 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 even to design or adapt said OP update even before its application to the PG1 software.

[0091] In a particular example, the assessment of the RS capacity to update the PG1 software may also take into account the 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 RS capacity to update the PG1 software may comprise the emission of an alert AL (figure 1) by the device 10 if the complexity index C reaches (or is greater than or equal to) the threshold value. In this way, it is possible to detect, anticipate and / or avoid a critical situation in which it would be particularly difficult to carry out the OP update. The reference value may, for example, be predefined to allow the detection of a possible explosion (or a 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 carried out 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 OP update and / or design an update strategy applicable to the PG1 software, 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] In a particular example, complexity C and / or capacity RS may be used to guide the development of a PG1 software update strategy in vehicle fleet 2.

[0096] According to a particular example, the complexity C and / or the capacity RS can be used to assess 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 according to 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 an RS capacity to update a PG1 software 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, in order to allow rapid and efficient software updates. To do this, the device 10 simulates or models the update(s) to be carried out on the PG1 software by determining a complexity index C as well as an update capacity RS as previously described. In this way, it is possible, for example, to detect critical situations and / or adapt a software update strategy. The device 10 may optionally be further configured to carry out the updates themselves.

[0102] The complexity index C can be determined quickly and reliably. In addition, it is possible to apply the treatment process 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 depending on 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 (VI-VN) 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 Figure 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 a1 )) and the target version Vb is necessarily the most up-to-date version VN (condition b1 )), namely V4 in this example.

[0106] Also, in this example, the OP1 update can be any of:

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

[0108] [Math. 1] C = N • (N — l) / 2

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

[0110] Once the complexity index C is determined, the number N can be initialized to 0. Therefore, in a future iteration of the processing process, it will be taken into account that the software has already been updated to version V4.

[0111] As illustrated in Figure 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 b1)), namely V4 in this example.

[0112] Also, in this example, the OP2 update can be any of: and

[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 in Figure 3 because the possible update paths are more limited in number and simpler.

[0116] Once the complexity index C is 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 Figure 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 of:

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

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

[0121] [Math. 3] C = N • (N — l) / 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 Figure 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 of: V2 -> V3 ; V2 -> V4 ; and

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

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

[0128] [Math. 4] C = N • (N — l) / 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 treatment process.

[0131] As illustrated in Figure 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 Figure 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 decline 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 of: or possibly also V3 -> V4 -> V3 if we consider that the particular case where Va=Vb constitutes in itself an update operation.

[0133] This scenario therefore includes 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 ■ QV - d) + N ■ QV - l) / 2 + d ■ (d - l) / 2

[0136] where d < 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 treatment process.

[0139] As illustrated in Figure 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 decline of d versions V from the intermediate version, where d is an integer number of downgrades such that d < N.

[0140] For example, we consider that d = 1. Also, in this example, the OP6 update can be any one of:

[0141] This scenario therefore includes two stages, namely an upgrade from version V according to the chronological order of the versions up to an intermediate version then a downgrade to 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 ■ QV - 1)

[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 is determined, the number N can for example be reset to 2 for a subsequent iteration of the treatment process.

[0146] As already indicated, the invention can be applied to a plurality of PG1 software programs implementable (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 are implementable in each vehicle 2. During the treatment 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 Z of the complexity indices C, an overall complexity index representative of the complexity of updating the plurality of PG1 software.

[0148] As illustrated in figure 9 in a particular embodiment, the device 10 can thus respectively determine a complexity index Ci 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 all PG1 software can be expressed as follows:

[0150] [Math. 7]

[0151] By summing the complexity indices for each PG1 software (for example in as many calculators 4 of a vehicle 2), we can thus evaluate the complexity associated with all the PG1 software and deduce an RS capacity 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 deploying 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 package.

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

[0155] Figure 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. 11. 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 in the memory 41. The memory 41 may constitute an information medium according to a particular embodiment in that it comprises a computer program (for example PG2 in FIG. 1) comprising instructions for carrying out the steps of the control method (or process) of the invention.

[0159] According to various particular and non-limiting exemplary 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 exemplary 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) type, 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) type.

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

[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] Figure 11 illustrates a diagram of the different steps of a processing method 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 less PG1 software from an initial version Goes to a target Vb version 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 processing method of figure 11.

[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 exemplary 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: - determination (51) of a number N of possible versions (V) 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 an oldest version to a most up-to-date version; - determination (52) of 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); 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.

2. Method according to claim 1, wherein the update profile (P) defines at least one of the following conditions: a) the update is carried out incrementally from the initial version (Va) to the target version (Vb) or the update is carried out 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) comprises 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 reference value is a threshold value, the evaluation of said capacity (RS) comprising: - issue of an alert (AL) if the complexity index C reaches the threshold value.

5. A method according to any preceding claim, wherein the method comprises at least one of: - evaluation, based on 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, based on the complexity index C and / or the capacity (RS) to be updated, of an update strategy for said at least one software (PG1) implemented in the group of at least one vehicle.

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

7. Method according to claim 6, comprising: - 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 (PG1).

8. 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 according to the update profile P.

9. Computer program (PG2) comprising instructions for implementing the method according to any one of the preceding claims, when these instructions are executed by a processor.

10. Processing device (10) for helping to update 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 implementing the steps of the method according to any one of claims 1 to 8.

Images