EP4649392A1 - Procédé et dispositif de traitement pour la mise à jour logicielle de véhicule - Google Patents

Procédé et dispositif de traitement pour la mise à jour logicielle de véhicule

Info

Publication number
EP4649392A1
EP4649392A1 EP23836558.9A EP23836558A EP4649392A1 EP 4649392 A1 EP4649392 A1 EP 4649392A1 EP 23836558 A EP23836558 A EP 23836558A EP 4649392 A1 EP4649392 A1 EP 4649392A1
Authority
EP
European Patent Office
Prior art keywords
update
software
version
complexity
vehicle
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23836558.9A
Other languages
German (de)
English (en)
Inventor
Priscilla LARGE PEK
Ludovic Casset
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Stellantis Auto SAS
Original Assignee
Stellantis Auto SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Stellantis Auto SAS filed Critical Stellantis Auto SAS
Publication of EP4649392A1 publication Critical patent/EP4649392A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates

Definitions

  • the present invention relates to processing methods and devices for helping to update one or more vehicle software, 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 piece of software that can be implemented in one or more vehicles to help update the software(s).
  • One of the objects of the present invention is to resolve at least one of the problems or deficiencies of what has been described previously.
  • Another object of the present invention is to improve software maintenance in one or more vehicles, for example but exclusively of the automobile type, in particular to allow rapid and efficient software updates.
  • Another object of the present invention is to help update at least one implementable software (or implemented) in one or more vehicles, with a view to allowing rapid and efficient software updates.
  • 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:
  • N an integer at least equal to 2
  • the N versions being organized in chronological order from an oldest version to a newest version more up to date;
  • the invention advantageously makes it possible to improve software maintenance in one or more vehicles, for example but exclusively of the automobile type, in particular to enable rapid and efficient software updates.
  • the complexity index C which constitutes a new metric taking into account N and P
  • 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, we can, for example, detect critical situations and/or adapt a software update strategy.
  • the processing device can optionally be further configured to perform the updates themselves.
  • 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.
  • the method according to the invention may include other characteristics which can be taken separately or in combination, in particular among the embodiments which follow.
  • the update profile defines at least one of the following conditions: a) the update is carried out incrementally from the initial version to the target version or the update updating is carried out 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 version downgrade of said at least one piece of software from an intermediate version to the final version.
  • N being an integer at least equal to 3 or at least equal to 4.
  • the reference value is a threshold value, the evaluation of said capacity comprising:
  • the method comprises at least one of:
  • the process is such that:
  • the method comprises:
  • the present invention relates to a processing device (or supervision device) to help 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.
  • the present invention relates to a computer program which comprises instructions adapted for the execution of the steps of the processing method according to the first aspect of the present invention, this in particular when the computer program is executed by at least one processor.
  • the different stages of the processing process 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).
  • Such a computer program can use any programming language, and be in the form of a source code, an object code, or an intermediate code between a source code and an object code , such as in partially compiled form, or in any other desirable form.
  • 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 carrying out the steps of the processing method according to the first aspect of the present invention.
  • the recording medium can be any entity or device capable of storing the program.
  • the support can include a storage means, such as a ROM memory, a CD-ROM or a ROM memory of the microelectronic circuit type, or even a magnetic recording means or a hard disk.
  • this recording medium can also be a transmissible medium such as an electrical or optical signal, such a signal being able to be conveyed via an electrical or optical cable, by conventional or terrestrial radio or by laser beam. self-directed or by other means.
  • the computer program according to the present invention can in particular be downloaded onto an Internet type network.
  • the recording medium may be an integrated circuit in which the computer program is incorporated, the integrated circuit being adapted to execute or to be used in the execution of the method in question.
  • FIG. 1 schematically illustrates a processing device configured to help update at least one software implementable in at least one vehicle, according to at least one particular and non-limiting embodiment of the present invention
  • FIG. 2 schematically illustrates vehicle software as shown in Figure 1, according to at least one particular and non-limiting embodiment of the present invention
  • FIG. 3 schematically illustrates the determination of a complexity index, according to at least one particular and non-limiting embodiment of the present invention
  • FIG. 4 schematically illustrates the determination of a complexity index, according to at least one particular and non-limiting embodiment of the present invention
  • FIG. 5 schematically illustrates the determination of a complexity index, according to at least one particular and non-limiting embodiment of the present invention
  • FIG. 6 schematically illustrates the determination of a complexity index, according to at least one particular and non-limiting embodiment of the present invention
  • FIG. 7 schematically illustrates the determination of a complexity index, according to at least one particular and non-limiting embodiment of the present invention
  • FIG. 8 schematically illustrates the determination of a complexity index, according to at least one particular and non-limiting embodiment of the present invention
  • FIG. 9 schematically illustrates the determination of a complexity index, according to at least one particular and non-limiting embodiment of the present invention.
  • FIG. 10 schematically illustrates a processing device configured to help update at least one software as illustrated in Figures 1 -9, according to at least one particular and non-limiting embodiment of the present invention.
  • FIG. 11 illustrates a diagram of different stages of a process for processing at least one vehicle software as illustrated in Figures 1-2, according to at least one particular and non-limiting embodiment of the present invention.
  • first(s) or first(s)
  • second(s) are used in this document by arbitrary convention to make it possible to identify and distinguish different elements (such as operations, computer programs, software versions, etc.) implemented in the embodiments described below.
  • the invention aims in particular at a processing method implemented by a processing device to help (or simulate, or or allow, or facilitate) the updating of at least one implementable software (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.
  • the treatment method of the present invention comprises:
  • N an integer at least equal to 2
  • the N versions being organized in chronological order from an oldest version to a newest version more up to date;
  • the invention is therefore based in particular on a rapid and effective solution for evaluating the complexity of one or a plurality of vehicle software, in order to help update this software.
  • This solution notably involves the introduction of a new metric representative of the complexity of one or more vehicle software.
  • 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 OTA type).
  • Figure 1 schematically illustrates a processing device 10 configured to help 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 d At least one vehicle 2 together forms a system SY1.
  • This processing device 10 aims firstly to help or facilitate the updating of the software PG1 intended to be implemented in the vehicles 2.
  • the device 10 can thus simulate or model the update(s) to be made on this PG1 software. In this way, it is possible to detect critical situations and/or adapt an update strategy.
  • the device 10 can optionally be further configured to perform the updates themselves.
  • each vehicle 2 can 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.
  • Each vehicle 2 of group 3 carries at least one software PG1 implemented in at least one on-board device 4.
  • the vehicles 2 each carry at least one computer 4 configured to implement software PG1.
  • the number of computers and PG1 software implemented may vary depending on the case.
  • 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 PG1 software implemented in each vehicle 2 may however vary.
  • Each vehicle 2 can for example comprise one or a plurality of computers 4.
  • the vehicles 2 include a central computer 4 cooperating with at least one other secondary computer 4.
  • This software PG1 can be any computer program, or application, configured to implement at least one appropriate function in the vehicle 2.
  • the computers 4 can for example implement vehicle control functions (of at least one element of the vehicle), navigation assistance, multimedia content management, etc.
  • the processing device 10 may comprise at least one processor and a non-volatile memory (not shown in Figure 1).
  • the device 10 is configured to implement a processing method (or process) (also called modeling method/process) as described below.
  • 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.
  • the processing device 10 can 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 can for example take the form of (or include a) calculator, or a combination of calculators. At least one example of implementation of the device 10 is described later.
  • the device 10 can also be configured to carry out at least one update operation OP in cooperation with the vehicles 2 of group 3, in order to update the on-board software PG1.
  • An update OP operation is configured to update at least one PG1 software.
  • Such an operation OP can include for example the sending and/or reception of data to and/or from at least one vehicle 2.
  • the device 10 includes 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 can for example be of the wireless type.
  • the device 10 can 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 software PG1.
  • OTA Over The Air
  • an update may cover any OP operation of modification, alteration, improvement, correction, etc. PG1 software.
  • each PG1 software for vehicle presents (or is characterized by) a software version generally denoted V, or more precisely Vi where i is an integer number (or index) between 1 and N.
  • N an integer at least equal to 2.
  • N is at least equal to 3 or at least equal to 4.
  • the number N can be adapted depending on the case.
  • N 4, although other examples are possible.
  • the software PG1 of each vehicle 2 can present any one of the possible versions Vi, V2, V3 and V 4 .
  • 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. i.e. the most recent version).
  • VN most up-to-date version
  • VI-VN versions are classified according to the following chronological order: Vi, V2, V 3 and V 4 .
  • an OP update (or update operation) is configured to modify the version of vehicle software PG1.
  • an OP update converts PG1 software from an initial version (or starting version) to a target version (or final version) Vb.
  • an OP update can in certain examples be carried out via at least one intermediate version between the initial version Va and the target version Vb.
  • an OP update can be carried out directly from the initial version Va in the target version Vb, that is to say without the software PG1 being converted into any intermediate version during the process. update.
  • the device 10 is configured to implement a processing (or modeling) process. This process is now described jointly in Figures 1 and 2 according to particular embodiments.
  • the processing process aims in particular to help update software PG1 implementable in vehicles 2, and more particularly, executable by on-board devices 4.
  • This software PG1 can already be implemented in all or part of the vehicles 2 when the processing process is carried out. Alternatively, the processing process can be carried out even before the PG1 software is implemented or loaded into the vehicles 2.
  • the processing device 10 determines the number N of possible versions V that the software PG1 implementable (or implemented) can present in the group 3 of vehicles 2.
  • 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.
  • N 4 and that the VI-VN versions are classified according to the following chronological order: Vi, V2, V3 and V4.
  • the number N can be determined in various ways depending on the case considered.
  • 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 also receive this value from an external entity.
  • 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 PG1 software in vehicles 2 from an initial version Va up to a target version Vb.
  • an update profile P or an update policy, or an update configuration
  • the update profile P defines the way in which the update OP must be carried out from version Va to version Vb.
  • Various update configurations are possible depending on the situation and needs and can therefore be adapted on a case-by-case basis.
  • 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 update OP 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 version downgrade of the PG1 software from an intermediate version to the final version Vb.
  • the profile P defines at least either the condition a1), or the condition a2).
  • the profile P defines at least either the condition b1), or the condition b2).
  • the profile P defines at least condition c).
  • the profile P defines any combination or sub-combination among the conditions a1)-a2), b1)-b2) and c).
  • a so-called incremental update OP means that the transition from the initial version Va to the final version Vb is done by passing successively through each intermediate version V located (if applicable) between Va and Vb according to the chronological order of the V versions (i.e. switching the versions from Va to Vb one by one in chronological order).
  • the same formalism for representing the successive stages of an OP update will be adopted in what follows.
  • 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 chronological order versions V.
  • an OP update can include a version downgrade of the software 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.
  • a version downgrade of the software PG1 in other words a version rollback according to the chronological order of the versions V
  • Version downgrading 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 again to configure the software according to particular constraints (customer wishes, etc.).
  • 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 an algorithm) which takes as input the parameter N and which at least one parameter defined by the update profile P.
  • the complexity of the software PG1 increases with the number N.
  • the complexity of the software PG1 is linked to the update strategy which is applied. For example, it is more complex to update the PG1 software incrementally than directly due to the need to convert the software through intermediate versions between Va and Vb if Va and Vb are not two consecutive versions according to the chronological order of 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 software PG1.
  • the complexity index C can in particular be defined (or calculated) so as to be representative (or function) of the number of possible paths (or links) between the different versions V (VI-VN) of the software PG1. This number of paths depends on the number N of possible versions V and the update profile P applied.
  • the profile P can be defined by at least one parameter representative of the aforementioned condition(s).
  • 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 P profile.
  • the calculation method (or algorithm) used may vary depending on the P profile applied in order to take into account the specificities of the OP update.
  • the device 10 evaluates an RS capacity to update at least one software by comparing the complexity index C with a reference value (figure 1). We can thus assess the feasibility or difficulty of updating PG1 software for vehicles from a modeling of said software, or a modeling of the updating of this software.
  • the device 10 can thus help (or simulate, or facilitate) the update of the software PG1 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 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 OP update or to design or adapt said OP update even before its application on the PG1 software.
  • the evaluation of the RS capacity to update the software PG1 can also take into account the resources available at a given moment or over a given period of time. Thus, the greater the resources available, the greater the RS capacity.
  • the reference value used during the fourth operation can for example be a threshold value.
  • the evaluation of the RS capacity to update the software PG1 can include 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, we can detect, anticipate and/or avoid a critical situation in which it would be particularly difficult to carry out the OP update.
  • the reference value can for example be predefined to allow detection of a possible explosion (or peak) in the complexity of the PG1 software which would result in a reduced ability 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.
  • 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 profile P of update and/or the number N of possible versions.
  • the result of the evaluation carried out during the fourth operation can for example be used to control the update OP of the software PG1, for example by blocking or postponing this update or by adapting its configuration.
  • the complexity C and/or the capacity RS can be used to guide the development of a strategy for updating the software PG1 in the vehicle fleet 2.
  • 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.
  • the complexity C and/or the capacity RS can be used to select one among at least two different update configurations to update the software PG1.
  • Each update configuration can be defined by a respective pair (N; P) defining the number N of possible versions and the update profile P used.
  • the device 10 determines at least two different pairs (N, P) to update 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.
  • This report 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 presenting the lowest complexity index or the one satisfying at least one predefined criterion taking take into account this relationship of superiority.
  • 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 software PG1.
  • the device 10 carries out 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 or the complexity index C (as previously described).
  • This OP update is for example carried out by contactless communication (OTA mode) between the device 10 and the vehicles 2 (or with their on-board computers 4 via communication interfaces).
  • OTA mode contactless communication
  • 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 exclusively of the automobile type, in particular to allow rapid software updates and effective.
  • the complexity index C which constitutes a new metric taking into account N and P
  • 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, we can, for example, detect critical situations and/or adapt a software update strategy.
  • the device 10 can optionally be further configured to carry out the updates themselves.
  • the complexity index C can be determined quickly and reliably. In addition, it is possible to apply the processing process to software not yet implemented in vehicles 2 or retroactively to existing software already installed in vehicles 2.
  • V-VN all possible versions of the PG1 software are compatible with each other, although variants are possible where this is not the case.
  • compatibility between V versions this means that all V versions share the same architecture and that you 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 chronological order).
  • the update OP1 can be any one of:
  • the complexity index C is therefore equal to 6.
  • the number N can be initialized to 0.
  • the update OP2 can be any one of:
  • the complexity index C is therefore equal to 3.
  • the complexity of the software is lower here than in the example of Figure 3 due to the fact that the possible update paths are more limited in number and simpler.
  • the number N can be initialized to 1 in order to carry out a new iteration of the treatment process.
  • the update OP3 can be any one of:
  • the complexity index C is therefore equal to 6.
  • the number N can for example be kept unchanged (N is not reset for a next iteration of the processing process).
  • the update OP - denoted OP4 - must be carried out directly from the initial version Va to 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)).
  • the update OP4 can be any one of: V2 ->V3; V2 ->V4; And
  • the complexity index C is therefore equal to 6.
  • the number N can for example be kept unchanged for a subsequent iteration of the treatment process.
  • the OP5 update also includes a version downgrade of the PG1 software from the intermediate version to the target version Vb (condition c)). This downgrade (downward update following the order of the versions) can be a step back by d versions V from the intermediate version, where d is an integer number of downgrade such that d ⁇ N.
  • This scenario therefore includes two stages, namely an upgrade of version V according to the chronological order of the versions to an intermediate version then a descent to the target version Vb.
  • a downgrade can be advantageous as already explained previously.
  • the number N can for example be kept unchanged for a subsequent iteration of the treatment process.
  • the OP6 update also includes a version downgrade of the PG1 software from the intermediate version to the target version Vb (condition c)). This downgrade (downward update following the order of the versions) can be a step back by d versions V from the intermediate version, where d is an integer number of downgrade such that d ⁇ N.
  • update OP6 can be any one of:
  • This scenario therefore comprises two stages, namely an upgrade of version V according to the chronological order of the versions up to an intermediate version then a descent towards the target version Vb.
  • a downgrade can be advantageous as already explained previously.
  • the number N can for example be reset to 2 for a subsequent iteration of the processing process.
  • the invention can be applied to a plurality of PG1 software programs that can be implemented (or implemented) in each vehicle 2.
  • group 3 comprises a plurality of vehicles 2 and a plurality of software PG1 can be implemented in each vehicle 2.
  • the device 10 :
  • the device 10 can thus respectively determine a complexity index Ci to carry out an update OP - denoted OP7-i - for each software PG1 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.
  • the complexity index of all the PG1 software can be expressed as follows:
  • This variant is advantageous insofar as the vehicles are increasingly moving towards a situation of updating several computers at the same time.
  • a global update data package 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, especially because the package can contain software that is consistent with each other.
  • this package update technique does not necessarily reduce the complexity from the point of view of implementation variants (dedicated packages necessary for a subset of vehicles).
  • the respective complexity indices C of several computers 4 are taken into account because the computers have dependencies between them.
  • the overall C-complexity index can integrate the level of complexity of each individual calculator.
  • the data packets transmitted by the device 10, possibly by contactless communication (OTA), can then be composed of a set of software versions.
  • OTA contactless communication
  • FIG. 10 schematically illustrates a processing device 10 configured to assist with a software update, as previously described with reference to Figures 1-9, according to a particular and non-limiting embodiment of the present invention.
  • the device 10 corresponds for example to a remote server with respect to the vehicle(s) 2, for example a computer.
  • 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 Figures 1-9 and/or the steps of the method described below. after next to figure 11.
  • Examples of such a processing device 10 include, without being limited to, on-board electronic equipment such as an on-board computer of a vehicle, an electronic computer such as an ECU (“Electronic Control Unit”), a smartphone, a tablet, a laptop.
  • ECU Electronic Control Unit
  • the elements of the control device 10, individually or in combination, can 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.
  • 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 processes) and/or for executing the instructions of the processing device(s). software 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.
  • 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 41.
  • the memory 41 can constitute an information medium according to a particular embodiment in that it comprises a computer program (for example PG2 in Figure 1) comprising instructions for carrying out the steps of the method (or process) control of the invention.
  • 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 communications bus or through dedicated input/output ports.
  • a TCU from the English “Telematic Control Unit” or in French “Telematic Control Unit”
  • a communications bus or through dedicated input/output ports.
  • 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 vehicle 2.
  • the interface elements of block 42 may include one or more of the following interfaces:
  • radio frequency interface for example of the Wi-Fi® type (according to IEEE 802.11), for example in the 2.4 or 5 GHz frequency bands, or of the Bluetooth® type (according to IEEE 802.15.1), in the band frequency at 2.4 GHz, or Sigfox type using UBN radio technology (from the English Ultra Narrow Band, in French ultra narrow band), or LoRa in the 868 MHz frequency band, LTE (from the English " Long-Term Evolution” or in French “Long-Term Evolution”), LTE-Advanced (or in French LTE-advanced);
  • USB interface from the English “Universal Serial Bus” or “Bus Universel en Série” in French);
  • 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 type (from the English “Controller Area Network” or in French “Réseau de controlleres”), CAN FD (from the English “Controller Area Network Flexible Data-Rate” or in French “Flexible Data Rate Controller Network”), FlexRay (standardized by ISO 17458), Ethernet (standardized by ISO/IEC 802-3) or LIN (local interconnect network), or French “Local Interconnected Network”).
  • 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.
  • the processing device 10 can provide output signals to one or more external devices, such as a display screen, touch or not, one or more speakers. and/or other peripherals (projection system) via respective output interfaces.
  • one or the other of the external devices is integrated into the control device 10.
  • FIG 11 illustrates a diagram of the different stages of a processing method for updating at least one software, such as for example software PG1 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 remote server with respect to the vehicles 2.
  • a number N of possible versions that said at least one software PG1 can present is determined, N being an integer at least equal to 2, the N versions being organized in chronological order from a version the oldest version to the most up-to-date version.
  • 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 condition. less PG1 software from an initial version Goes to a Vb target version of said software
  • a complexity index C representative of a complexity of said at least software PG1 is determined from the number N and the profile P.
  • a capacity to update said at least one software PG1 is evaluated by comparing the complexity index C with a reference value.
  • the present invention is therefore not limited to the exemplary embodiments described above but extends in particular to a treatment process which would include secondary steps without thereby departing from the scope of the present invention. The same would apply to a device configured for implementing such a process.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

La présente invention concerne un procédé et un dispositif de traitement (10) pour aider à mettre à jour au moins un logiciel (PG1 ) d'au moins un véhicule (2), ledit procédé comprenant : détermination d'un nombre N de versions (V) possibles que peut présenter ledit au moins un logiciel (PG1 ), N étant un entier au moins égal à 2; détermination d'un profil de mise à jour définissant au moins une condition à respecter par une mise à jour (OP) dudit au moins logiciel (PG1 ); détermination, à partir du nombre N et du profil de mise à jour, d'un indice de complexité (C) représentatif d'une complexité dudit au moins logiciel (PG1 ); et évaluation d'une capacité (RS) à mettre à jour ledit au moins un logiciel (PG1 ) par comparaison de l'indice de complexité (C) avec une valeur de référence.

Description

DESCRIPTION
Titre : Procédé et dispositif de traitement pour la mise à jour logicielle de véhicule
La présente invention revendique la priorité de la demande française 2300328 déposée le 13.01.2023 dont le contenu (texte, dessins et revendications) est ici incorporé par référence.
Domaine technique
[0001] La présente invention concerne les procédés et dispositifs de traitement pour aider à la mise à jour d’un ou plusieurs logiciels pour véhicule, et notamment mais pas exclusivement pour des véhicules de type automobile. L’invention vise en particulier l’évaluation ou le suivi de la complexité d’au moins un logiciel implémentable dans un ou des véhicules pour aider à la mise à jour du ou des logiciels.
Arrière-plan technologique
[0002] Les véhicules actuels, notamment de type automobiles ou équivalents, se complexifient avec le temps et sont de plus en plus orientés logiciel. Ainsi, le développement de certaines nouvelles architectures de véhicule s’accompagne de l’implémentation de nouvelles plates-formes technologiques mettant en oeuvre des logiciels de diverses natures configurés pour mettre en oeuvre des fonctions très variées.
[0003] La présence croissante de logiciels dans les véhicules nécessite des mises à jour logicielles fréquentes afin notamment de réaliser la maintenance (à des fins de cybersécurité par exemple) et les corrections nécessaires sur ces logiciels (corrections de défauts ou bugs par exemple) et introduire régulièrement des améliorations (de nouvelles fonctionnalités par exemple). A cet effet, les technologies de communication sans fil (dites aussi OTA pour « Over The Air » en anglais) peuvent être utilisées pour transférer à distance des logiciels ou des données vers/depuis un véhicule, et ainsi effectuer les mises à jour logicielles nécessaires. Il est ainsi possible de mettre à jour des véhicules tout au long de leur cycle de vie et ainsi assurer une expérience optimale pour l’utilisateur.
[0004] Cependant, la maintenance, et notamment le maintien à jour, des logiciels pour véhicule constituent un défi important en raison notamment de la complexification des véhicules et de leurs logiciels embarqués. Ainsi, l’augmentation du nombre de calculateurs embarqués dans les véhicules, la sophistication croissante des logiciels ou encore l’interdépendance des calculateurs entre eux imposent des contraintes fortes sur la maintenance de ces logiciels et peuvent rendre difficile les mises à jour logicielles.
[0005] Ces difficultés résultent également du fait que les logiciels et le matériel embarqués dans les véhicules sont souvent étroitement corrélés et dépendants les uns avec les autre dans de nombreuses architectures existantes de véhicule. Cela entrave la capacité des acteurs du marché à faire évoluer les logiciels sans impacter ou modifier le matériel. Dans un contexte où les véhicules sont amenés à être de plus en plus fournisseurs de services, il est nécessaire de pouvoir faire évoluer les logiciels de véhicule tout au long de la durée de vie des véhicules, si possible sans changer le matériel.
[0006] Ces difficultés sont encore amenées à croître sensiblement dans le futur. Il est critique de pouvoir assurer ces mises à jour de façon efficace afin de permettre notamment aux acteurs de continuer à innover, développer et maintenir des véhicules performants et de qualité.
Résumé de la présente invention
[0007] Il a été constaté que la capacité de maintenance et d'évolution des logiciels embarqués dans des véhicules est étroitement dépendante de la complexité des logiciels en question. Des logiciels de complexité limitées sont notamment plus faciles à garder à jour. Une faible complexité des logiciels de véhicule se traduit en outre par une meilleure qualité et fiabilité des véhicules (moins de bugs, etc.) et des coûts de maintenance réduits ainsi qu'une meilleure expérience client.
[0008] Il a également été observé qu’il est possible d’évaluer la complexité d’un logiciel en fonction du niveau d'algorithme du contenu du code, ce qui nécessite toutefois l’utilisation d’algorithmes particulièrement complexes et donc difficiles à mettre en oeuvre (utilisation par exemple de réseaux de neurones pour mesurer la complexité logicielle). De tels algorithmes nécessitent un cadre logiciel spécifique qui doit être mis en place et développé, ce qui impose des coûts en importants en ressources (de temps, matérielles/logicielles, financières, etc.).
[0009] L’un des objets de la présente invention est de résoudre au moins l’un des problèmes ou déficiences de ce qui a été décrit précédemment.
[0010] Un autre objet de la présente invention est d’améliorer la maintenance logicielle dans un ou des véhicules, par exemple mais par exclusivement de type automobile, notamment pour permettre des mises à jour logicielles rapides et efficaces.
[0011] Un autre objet de la présente invention est d’aider à mettre à jour au moins un logiciel implémentable (ou implémenté) dans un ou des véhicules, en vue de permettre des mises à jour logicielles rapides et efficaces.
[0012] Selon un premier aspect, la présente invention concerne un procédé de traitement mis en oeuvre par un dispositif de traitement pour aider à mettre à jour au moins un logiciel implémentable dans un groupe d’au moins un véhicule, ledit procédé comprenant :
- détermination d’un nombre N de versions possibles que peut présenter ledit au moins un logiciel, N étant un entier au moins égal à 2, les N versions étant organisées selon un ordre chronologique depuis une version la plus ancienne jusqu’à une version la plus à jour ;
- détermination d’un profil P de mise à jour définissant au moins une condition à respecter par une mise à jour dudit au moins logiciel depuis une version initiale vers une version cible dudit logiciel ;
- détermination, à partir du nombre N et du profil P, d’un indice de complexité C représentatif d’une complexité dudit au moins logiciel ; et
- évaluation d’une capacité à mettre à jour ledit au moins un logiciel par comparaison de l’indice de complexité C avec une valeur de référence.
[0013] L’invention permet avantageusement d’améliorer la maintenance logicielle dans un ou des véhicules, par exemple mais par exclusivement de type automobile, notamment pour permettre des mises à jour logicielles rapides et efficaces. Grâce à l’indice de complexité C qui constitue une nouvelle métrique prenant en compte N et P, on peut évaluer efficacement une capacité à mettre à jour un logiciel dans un ou plusieurs véhicules, tels que dans un parc automobile par exemple. On peut ainsi aider à mettre à jour au moins un logiciel implémentable (ou implémenté) dans un ou des véhicules, en vue de permettre des mises à jour logicielles rapides et efficaces. Pour ce faire, le dispositif de traitement simule ou modélise la ou les mises à jour à réaliser sur le(s) logiciel(s) en déterminant un indice de complexité C ainsi qu’une capacité de mise à jour comme précédemment indiqué. De cette manière, on peut par exemple détecter des situations critiques et/ou adapter une stratégie de mise à jour logicielle. Le dispositif de traitement peut éventuellement être en outre configuré pour réaliser les mises à jour elles-mêmes.
[0014] L’indice de complexité C peut être déterminé de façon rapide et fiable. En outre, il est possible d’appliquer le procédé de traitement à des logiciels non encore implémentés dans des véhicules ou de façon rétroactive à des logiciels existants déjà installés dans des véhicules.
[0015] Le procédé selon l’invention peut comporter d’autres caractéristiques qui peuvent être prises séparément ou en combinaison, notamment parmi les modes de réalisation qui suivent.
[0016] Selon un mode particulier de réalisation, le profil de mise à jour définit au moins l’une des conditions suivantes : a) la mise à jour est réalisée de façon incrémentale depuis la version initiale jusqu’à la version cible ou la mise à jour est réalisée de façon directe depuis la version initiale jusqu’à la version cible ; b) la version cible de la mise à jour est la version la plus à jour ou la version cible est une quelconque version plus à jour que la version initiale ; et c) la mise à jour comprend une rétrogradation de version dudit au moins un logiciel depuis une version intermédiaire vers la version finale.
[0017] Selon un mode particulier de réalisation, N étant un entier au moins égal à 3 ou au moins égal à 4. [0018] Selon un mode particulier de réalisation, la valeur de référence est une valeur seuil, l’évaluation de ladite capacité comprenant :
- émission d’une alerte si l’indice de complexité C atteint la valeur seuil.
[0019] Selon un mode particulier de réalisation, le procédé comprend au moins l’un parmi :
- évaluation, à partir de l’indice de complexité C et/ou de la capacité à mettre à jour, d’une capacité à réaliser sur une période donnée une campagne de mises à jour sur ledit au moins un logiciel implémenté dans le groupe d’au moins un véhicule ; et - définition, à partir de l’indice de complexité C et/ou de la capacité à mettre à jour, d’une stratégie de mise à jour dudit au moins un logiciel implémenté dans le groupe d’au moins un véhicule.
[0020] Selon un mode particulier de réalisation, le procédé est tel que :
- au moins deux couples différents (N, P) sont déterminés pour mettre à jour ledit au moins logiciel selon respectivement au moins deux configurations différentes de mise à jour ; et
- un indice de complexité C est déterminé pour respectivement chaque couple
(N, P) ; le procédé comprenant en outre : - détermination d’un rapport de complexité entre lesdites au moins deux configurations de mise à jour par comparaison de leurs indices de complexité respectifs.
[0021] Selon un mode particulier de réalisation, le procédé comprend :
- détermination, à partir du rapport de complexité, de la configuration de mise à jour la moins complexe ; et
- sélection de la configuration de mise à jour la moins complexe pour mettre à jour ledit au moins un logiciel.
[0022] Selon un mode particulier de réalisation, l’indice de complexité C est déterminé à partir d’une formule de calcul prenant en entrée N, ladite formule de calcul étant sélectionnée en fonction du profil P de mise à jour. [0023] Selon un deuxième aspect, la présente invention concerne un dispositif de traitement (ou dispositif de supervision) pour aider à mettre à jour au moins un logiciel implémentable dans un groupe d’au moins un véhicule, le dispositif comprenant une mémoire associée à un processeur configuré pour la mise en oeuvre des étapes du procédé de traitement selon le premier aspect de la présente invention.
[0024] A noter que les différents modes de réalisation mentionnés ci-avant en relation avec le procédé de traitement selon le premier aspect de l’invention ainsi que les avantages associés s’appliquent de façon analogue au dispositif de traitement selon le deuxième aspect de l’invention.
[0025] Selon un troisième aspect, la présente invention concerne un programme d’ordinateur qui comporte des instructions adaptées pour l’exécution des étapes du procédé de traitement selon le premier aspect de la présente invention, ceci notamment lorsque le programme d’ordinateur est exécuté par au moins un processeur. Autrement dit, les différentes étapes du procédé de traitement sont déterminées par des instructions de programmes d’ordinateurs. Ce programme d’ordinateur est configuré pour être mis en oeuvre dans un dispositif de traitement du deuxième aspect de l’invention, ou plus généralement dans un ordinateur (par exemple un serveur).
[0026] Un tel programme d’ordinateur peut utiliser n’importe quel langage de programmation, et être sous la forme d’un code source, d’un code objet, ou d’un code intermédiaire entre un code source et un code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
[0027] Selon un quatrième aspect, la présente invention concerne un support d’enregistrement (ou support d’informations), lisible par le dispositif de traitement selon le deuxième aspect ou plus généralement par un ordinateur (ou un processeur), sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé de traitement selon le premier aspect de la présente invention.
[0028] D’une part, le support d’enregistrement peut être n'importe quel entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire ROM, un CD-ROM ou une mémoire ROM de type circuit microélectronique, ou encore un moyen d'enregistrement magnétique ou un disque dur.
[0029] D'autre part, ce support d’enregistrement peut également être un support transmissible tel qu'un signal électrique ou optique, un tel signal pouvant être acheminé via un câble électrique ou optique, par radio classique ou hertzienne ou par faisceau laser autodirigé ou par d'autres moyens. Le programme d’ordinateur selon la présente invention peut être en particulier téléchargé sur un réseau de type Internet.
[0030] Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme d’ordinateur est incorporé, le circuit intégré étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Brève description des figures
[0031] D’autres caractéristiques et avantages de la présente invention ressortiront de la description des exemples de réalisation particuliers et non limitatifs de la présente invention ci-après, en référence aux figures 1 à 11 annexées, sur lesquelles :
[0032] [Fig. 1] illustre schématiquement un dispositif de traitement configuré pour aider à la mise à jour d’au moins un logiciel implémentable dans au moins un véhicule, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ;
[0033] [Fig. 2] illustre schématiquement un logiciel de véhicule comme représenté en figure 1 , selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ;
[0034] [Fig. 3] illustre schématiquement la détermination d’un indice de complexité, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ;
[0035] [Fig. 4] illustre schématiquement la détermination d’un indice de complexité, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; [0036] [Fig. 5] illustre schématiquement la détermination d’un indice de complexité, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ;
[0037] [Fig. 6] illustre schématiquement la détermination d’un indice de complexité, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ;
[0038] [Fig. 7] illustre schématiquement la détermination d’un indice de complexité, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ;
[0039] [Fig. 8] illustre schématiquement la détermination d’un indice de complexité, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ;
[0040] [Fig. 9] illustre schématiquement la détermination d’un indice de complexité, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ;
[0041] [Fig. 10] illustre schématiquement un dispositif de traitement configuré pour aider la mise à jour d’au moins un logiciel comme illustré en figures 1 -9, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; et
[0042] [Fig. 11] illustre un diagramme de différentes étapes d’un procédé de traitement d’au moins un logiciel de véhicule comme illustré en figures 1-2, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention.
Description des exemples de réalisation
[0043] Un procédé et un dispositif de contrôle d’un véhicule vont maintenant être décrits dans ce qui va suivre en référence conjointement aux figures 1-11. Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité. [0044] Les termes « premier(s) » (ou première(s)), « deuxième(s) », etc.) sont utilisés dans ce document par convention arbitraire pour permettre d’identifier et de distinguer différents éléments (tels que des opérations, des programmes d’ordinateur, des versions de logiciel, etc.) mis en oeuvre dans les modes de réalisation décrits ci-après.
[0045] Comme précédemment indiqué, l’invention vise notamment un procédé de traitement mis en oeuvre par un dispositif de traitement pour aider (ou simuler, ou ou permettre, ou faciliter) la mise à jour d’au moins un logiciel implémentable (ou implémenté) dans un groupe d’au moins un véhicule, tels que des véhicules de type automobile ou autre, ou plus généralement dans des véhicules de type véhicule terrestre motorisé.
[0046] Selon un exemple particulier et non limitatif de réalisation, le procédé de traitement de la présente invention comprend :
- détermination d’un nombre N de versions possibles que peut présenter ledit au moins un logiciel, N étant un entier au moins égal à 2, les N versions étant organisées selon un ordre chronologique depuis une version la plus ancienne jusqu’à une version la plus à jour ;
- détermination d’une profil P de mise à jour définissant au moins une condition à respecter par une mise à jour dudit au moins logiciel depuis une version initiale vers une version cible dudit logiciel ; et
- détermination, à partir du nombre N et du profil P, d’un indice de complexité C représentatif d’une complexité dudit au moins logiciel ; et
- évaluation d’une capacité à mettre à jour ledit au moins un logiciel par comparaison de l’indice de complexité C avec une valeur de référence.
[0047] Comme indiqué précédemment, il a été observé que la capacité de maintenance et d'évolution des logiciels embarqués dans des véhicules est étroitement dépendante de la complexité des logiciels concernés. L’invention repose donc en particulier sur une solution rapide et efficace pour évaluer la complexité d’un ou d’une pluralité de logiciels de véhicule, afin d’aider à mettre à jour ces logiciels. Cette solution implique notamment l’introduction d’une nouvelle métrique représentative de la complexité d’un ou plusieurs logiciels de véhicule. Cette nouvelle métrique, dite indice de complexité (ou indice de complexité logicielle), capable d’être déterminée rapidement et à faible coût en ressources, permet de représenter de façon fiable la complexité d’un code logiciel pour véhicule et/ou la complexité d’une plateforme technologique associée (par exemple de type OTA).
[0048] A partir de cette indice de complexité, on peut ainsi évaluer une capacité à mettre à jour le ou les logiciels concernés. Pour ce faire, une comparaison est réalisée entre l’indice de complexité et une valeur de référence dont la nature peut varier selon le cas. Il est par exemple possible, à partir du résultat de cette comparaison, de détecter ou anticiper des risques ou problèmes liés à une mise à jour ou encore de concevoir ou adapter ladite mise à jour avant son application sur le ou les logiciels concernés.
[0049] D’autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant.
[0050] La figure 1 illustre schématiquement un dispositif de traitement 10 configuré pour aider ou faciliter la mise à jour d’au moins un logiciel PG1 implémentable dans un groupe 3 d’au moins un véhicule 2. Le dispositif 10 et le groupe 3 d’au moins un véhicule 2 forme ensemble un système SY1 .
[0051 ] Ce dispositif de traitement (dit aussi dispositif de modélisation ou dispositif) 10 vise en premier lieu à aider ou faciliter la mise à jour du ou des logiciels PG1 destinées à être implémentés dans les véhicules 2. Le dispositif 10 peut ainsi simuler ou modéliser la ou les mises à jour à réaliser sur ces logiciels PG1 . De cette manière, on peut notamment détecter des situations critiques et/ou adapter une stratégie de mise à jour. Comme décrit plus en détail ultérieurement, le dispositif 10 peut éventuellement être en outre configuré pour réaliser les mises à jour elles-mêmes.
[0052] Comme illustré en figure 1 , on considère ici un groupe (ou parc) 3 d’une pluralité de véhicules 2, bien que l’invention soit également applicable pour un seul véhicule 2. Autrement dit, l’invention peut s’appliquer plus généralement à un groupe 3 d’au moins un tel véhicule 2. [0053] Le type et les caractéristiques des véhicules 2 peuvent être adaptés selon le cas. Les véhicules 2 sont par exemple de type automobile ou équivalent. En variante, chaque véhicule 2 peut être un car, un bus, un camion, un véhicule utilitaire ou une motocyclette, ou plus généralement un véhicule de type véhicule terrestre motorisé, voire un véhicule maritime (ou fluvial) ou aérien.
[0054] Chaque véhicule 2 du groupe 3 embarque au moins un logiciel PG1 implémenté dans au moins un dispositif embarqué 4. On considère par la suite à titre d’exemple que les véhicules 2 embarquent chacun au moins un calculateur 4 configuré pour implémenter un logiciel PG1 . A noter toutefois que le nombre de calculateurs et de logiciels PG1 implémentés peuvent varier selon le cas.
[0055] On suppose par la suite que chaque calculateur 4 est configuré pour implémenter un même logiciel PG1 , ce logiciel pouvant éventuellement comprendre une pluralité de logiciels ou sous-logiciels. Comme décrit ci-après, la version du logiciel PG1 implémenté dans chaque véhicule 2 peut toutefois varier.
[0056] Chaque véhicule 2 peut par exemple comprendre un ou une pluralité de calculateurs 4. Selon un exemple particulier, les véhicules 2 comprennent un calculateur central 4 coopérant avec au moins un autre calculateur secondaire 4.
[0057] La nature, la configuration et le fonctionnement du logiciel PG1 implémenté dans chaque véhicule 2 peuvent varier selon le cas. Ce logiciel PG1 peut être un quelconque programme d’ordinateur, ou application, configurés pour mettre en oeuvre au moins une fonction appropriée dans le véhicule 2. Parmi les fonctions possibles, les calculateurs 4 peuvent par exemple mettre en oeuvre des fonctions de contrôle du véhicule (d’au moins un élément du véhicule), d’aide à la navigation, de gestion de contenus multimédia, etc.
[0058] Le dispositif de traitement 10 peut comprendre au moins un processeur et une mémoire non volatile (non représentés en figure 1 ). Le dispositif 10 est configuré pour mettre en oeuvre un procédé (ou processus) de traitement (dit aussi procédé/processus de modélisation) comme décrit ci-après. A cet effet, le dispositif 10 peut comprendre un deuxième programme d’ordinateur PG2 stocké dans sa mémoire non volatile (mémoire de type Flash ou ROM par exemple), ce programme d’ordinateur PG2 comprenant des instructions pour la mise en œuvre du procédé (ou processus) de traitement comme décrit ci-après. Le processeur du dispositif 10 peut ainsi être configuré pour exécuter notamment les instructions définies par le programme d’ordinateur PG2.
[0059] Le dispositif de traitement 10 peut être un quelconque dispositif, tel qu’un ordinateur ou serveur par exemple, apte à mettre en œuvre le procédé (ou processus) de traitement de l’invention. Ce dispositif 10 peut par exemple prendre la forme d’un (ou comprendre un) calculateur, ou une combinaison de calculateurs. Au moins un exemple de mise en œuvre du dispositif 10 est décrit ultérieurement.
[0060] Comme illustré en figure 1 , le dispositif 10 peut en outre être configuré pour réaliser au moins une opération OP de mise à jour en coopération avec les véhicules 2 du groupe 3, afin de mettre à jour les logiciels embarqués PG1. Une opération OP de mise à jour est configurée pour mettre à jour au moins un logiciel PG1.
[0061] Une telle opération OP (figures 1 -2) peut comprendre par exemple l’envoi et/ou la réception de données vers et/ou depuis au moins un véhicule 2. Pour ce faire, on suppose par la suite que le dispositif 10 comprend des moyens d’interface pour coopérer avec les véhicules 2, ou plus particulièrement avec les calculateurs 4, via des canaux de communication appropriés. Ces canaux de communication établis entre le dispositif 10 et les véhicules 2 peuvent par exemple être de type sans fil. Autrement dit, le dispositif 10 peut par exemple être configuré pour communiquer en mode OTA (« Over The Air ») avec les véhicules 2 (ou avec leurs calculateurs 4) pour réaliser des opérations OP de mise à jour des logiciels PG1 .
[0062] Dans le présent document, une mise à jour peut couvrir une quelconque opération OP de modification, altération, amélioration, correction, etc. d’un logiciel PG1.
[0063] Comme illustré en figure 2, chaque logiciel PG1 pour véhicule présente (ou se caractérise par) une version de logiciel notée généralement V, ou plus précisément Vi où i est un nombre (ou indice) entier compris entre 1 et N. On considère N un entier au moins égal à 2. Selon un exemple particulier, N est au moins égal à 3 ou au moins égal à 4. Le nombre N peut être adapté selon le cas.
[0064] Dans ce qui suit, on suppose à titre illustratif que N = 4, bien que d’autres exemples soient possibles. Autrement dit, le logiciel PG1 de chaque véhicule 2 peut présenter l’une quelconque parmi les versions possibles Vi, V2, V3 et V4.
[0065] Ainsi, il existe un nombre N (=4) de versions V possibles que peuvent présenter chaque logiciel PG1. Ces N versions de logiciel possibles sont organisées selon un ordre chronologique (c’est-à-dire un ordre croissant de mise à jour) depuis une version la plus ancienne V1 jusqu’à une version la plus à jour VN (c’est-à-dire la version la plus récente). Dans ce qui suit, on considère ainsi à titre d’exemple que les versions VI-VN sont classées selon l’ordre chronologique suivant : Vi, V2, V3 et V4.
[0066] Comme illustré en figure 2 selon un exemple particulier, une mise à jour OP (ou opération de mise à jour) est configurée pour modifier la version d’un logiciel PG1 de véhicule. Ainsi, une mise à jour OP convertit un logiciel PG1 depuis une version initiale (ou version de départ) Va dans une version cible (ou version finale) Vb. Comme décrit par la suite, une mise à jour OP peut dans certains exemples être réalisée via au moins une version intermédiaire entre la version initiale Va et la version cible Vb. Selon d’autres exemples, une mise à jour OP peut être réalisée directement depuis la version initiale Va dans la version cible Vb, c’est-à-dire sans que le logiciel PG1 ne soit converti dans une quelconque version intermédiaire au cours du processus de mise à jour.
[0067] Comme indiqué ci-avant, le dispositif 10 est configuré pour mettre en oeuvre un processus de traitement (ou de modélisation). Ce processus est à présent décrit conjointement aux figures 1 et 2 selon des modes de réalisation particuliers.
[0068] Comme déjà indiqué, on suppose par la suite que le processus de traitement vise en particulier à aider à mettre à jour un logiciel PG1 implémentable dans les véhicules 2, et plus particulièrement, exécutables par les dispositifs embarqués 4. PG1 désigne donc ici un même logiciel implémentable dans chaque véhicule 2 mais dont la version V peut varier d’un véhicule 2 à un autre (entre les versions V1 et VN=V4 incluses). [0069] Ce logiciel PG1 peut être déjà implémenté dans tous ou partie des véhicules 2 lorsque le processus de traitement est réalisé. En variante, le processus de traitement peut être réalisé avant même que le logiciel PG1 ne soit implémenté ou chargé dans les véhicules 2.
[0070] Dans une première opération, le dispositif de traitement 10 détermine le nombre N de versions V possibles que peut présenter le logiciel PG1 implémentable (ou implémentés) dans le groupe 3 de véhicules 2. Comme déjà indiqué, N est un nombre entier au moins égal à 2 et les N versions V sont organisées selon un ordre chronologique depuis une version la plus ancienne jusqu’à une version la plus à jour. On considère par la suite que N=4 et que les versions VI-VN sont classées selon l’ordre chronologique suivant : Vi, V2, V3 et V4.
[0071] Le nombre N peut être déterminé de diverses manières selon le cas considérés. A titre d’exemple, le dispositif 10 peut récupérer le nombre N en consultant une mémoire locale, ou peut recevoir cette valeur sous forme d’instruction (par exemple une instruction utilisateur), ou peut encore recevoir cette valeur depuis une entité externe.
[0072] Dans une deuxième opération, le dispositif de traitement 10 détermine un profil P de mise à jour (ou une politique de mise à jour, ou une configuration de mise à jour) définissant au moins une condition à respecter par une mise à jour OP du logiciel PG1 dans les véhicules 2 depuis une version initiale Va jusqu’à une version cible Vb. On considère dans ce qui suit que la version cible Vb est plus avancée que la version de départ Va selon l’ordre chronologique des versions V.
[0073] Le profil P de mise à jour définit la manière dont la mise à jour OP doit être réalisée depuis la version Va jusqu’à la version Vb. Diverses configurations de mise à jour sont possibles selon la situation et les besoins et peuvent donc être adaptées au cas par cas.
[0074] Selon un exemple particulier, le profil P de mise à jour définit au moins l’une des conditions suivantes : a1 ) la mise à jour OP est réalisée de façon incrémentale depuis la version initiale Va jusqu’à la version cible Vb ou a2) la mise à jour est réalisée de façon directe depuis la version initiale Va jusqu’à la version cible Vb ; b1 ) la version cible Vb de la mise à jour OP est la version la plus à jour ou b2) la version cible Vb est une quelconque version plus à jour que la version initiale Va ; et c) la mise à jour comprend une rétrogradation de version du logiciel PG1 depuis une version intermédiaire vers la version finale Vb.
[0075] Selon un exemple particulier, le profil P définit au moins soit la condition a1 ), soit la condition a2).
[0076] Selon un exemple particulier, le profil P définit au moins soit la condition b1 ), soit la condition b2).
[0077] Selon un exemple particulier, le profil P définit au moins la condition c).
[0078] Selon un exemple particulier, le profil P définit une quelconque combinaison ou sous-combinaison parmi les conditions a1 )-a2), b1 )-b2) et c).
[0079] Une mise à jour OP dite incrémentale signifie que le passage depuis la version initiale Va à la version finale Vb se fait en passant successivement par chaque version intermédiaire V située (le cas échéant) entre Va et Vb selon l’ordre chronologique des versions V (c’est-à-dire en passant une à une les versions depuis Va à Vb selon l’ordre chronologique). Par exemple, une mise à jour incrémentale depuis Va=Vi à Vb=V4 implique les conversions successives du logiciel PG1 depuis la version Vi à V2, puis de V2 à V3, puis de V3 à V4, ce qui peut se symboliser par V-, -> V2 -> V3 -> V4. Le même formalisme de représentation des étapes successives d’une mise à jour OP sera adopté dans ce qui suit.
[0080] A contrario, une mise à jour OP directe signifie que le passage depuis la version initiale Va à la version finale Vb se fait sans passer par une quelconque version intermédiaire V susceptible d’être située entre Va et Vb selon l’ordre chronologique des versions V. Par exemple, une mise à jour directe depuis Va=Vi à Vb=V4 implique la conversion directe du logiciel PG1 depuis la version V1 à V4 sans passer ni par V3 ni par V4, ce qui peut se symboliser par V1 V4.
[0081 ] Comme exprimé ci-avant dans la condition b1 ), une mise à jour OP peut imposer que le logiciel PG1 soit systématiquement mis à jour à la version la plus à jour, à savoir VN=V4 dans cet exemple. Au contraire, une mise à jour OP peut autoriser que le logiciel PG1 soit converti dans une version plus à jour que la version initiale Vb mais pas nécessairement la version la plus à jour V, à savoir VN=V4 dans cet exemple.
[0082] Comme exprimé ci-avant dans la condition c), une mise à jour OP peut comprendre une rétrogradation de version du logiciel PG1 (autrement dit un recul de version selon l’ordre chronologique des versions V) depuis une version intermédiaire vers la version finale Vb. Par exemple, une telle mise à jour OP peut être réalisée depuis Va=Vi à Vb=V3 avec successivement une conversion - directe par exemple - depuis Vi à V4 (version intermédiaire) puis une rétrogradation depuis V4 à V3, ce qui peut se symboliser par V1 -> V4 -> V3.
[0083] La rétrogradation de version peut être utile ou souhaitable dans certaines situations, par exemple pour des raisons d’ordre sécuritaire, d’ordre technique, des raisons relatives à la qualité d’un service mise en oeuvre par le logiciel PG1 , ou encore pour configurer le logiciel selon des contraintes particulières (souhait du client, etc.).
[0084] Dans une troisième opération, le dispositif de traitement 10 détermine, à partir du nombre N et du profil P, un indice de complexité C représentatif d’une complexité du logiciel PG1 . Pour ce faire, le dispositif 10 peut appliquer une méthode (ou un algorithme) de calcul qui prend en entrée le paramètre N et qui au moins un paramètre défini par le profil P de mise à jour.
[0085] Il a notamment été observé qu’il y a une corrélation entre la complexité du logiciel PG1 et le nombre N de versions possibles du logiciel à un instant donné. Ainsi, la complexité du logiciel PG1 croît avec le nombre N. De plus, la complexité du logiciel PG1 est liée à la stratégie de mise à jour qui est appliquée. Il est par exemple plus complexe de mettre à jour le logiciel PG1 de façon incrémentale que de façon directe en raison de la nécessité de convertir le logiciel par des versions intermédiaires entre Va et Vb si Va et Vb ne sont pas deux versions consécutives selon l’ordre chronologique des versions. Le dispositif 10 peut donc être configuré pour implémenter un algorithme de modélisation qui prend en compte les paramètres N et P pour déterminer l’indice de complexité C du logiciel PG1. [0086] L’indice de complexité C peut en particulier être défini (ou calculé) de sorte à être représentatif (ou fonction) du nombre de chemins (ou liens) possibles entre les différentes versions V (VI-VN) du logiciel PG1. Ce nombre de chemins dépend du nombre N de version V possibles et du profil P de mise à jour appliqué.
[0087] A noter que le profil P peut être défini par au moins un paramètre représentatif du ou des conditions précitées. Selon un exemple particulier, le dispositif 10 sélectionne la méthode de calcul (ou algorithme de calcul), utilisée pour déterminer l’indice de complexité C, en fonction du profil P de mise à jour, ou plus précisément en fonction de la ou des conditions que la mise à jour OP doit respecter conformément audit profil P. Ainsi, la méthode (ou algorithme) de calcul utilisée peut varier en fonction du profil P appliqué afin de prendre en compte les spécificités de la mise à jour OP.
[0088] Des exemples de détermination de l’indice de complexité C seront décrits ci- après dans des modes de réalisation particuliers.
[0089] Dans une quatrième opération, le dispositif 10 évalue une capacité RS à mettre à jour au moins un logiciel par comparaison de l’indice de complexité C avec une valeur de référence (figure 1 ). On peut ainsi apprécier la faisabilité ou la difficulté à mettre à jour un logiciel PG1 pour véhicule à partir d’une modélisation dudit logiciel, ou une modélisation de la mise à jour de ce logiciel.
[0090] Le dispositif 10 peut ainsi aider (ou simuler, ou faciliter) la mise à jour du logiciel PG1 implémentable (ou implémenté) dans les véhicules 2. A partir de l’indice de complexité C, le dispositif 10 peut évaluer une capacité RS à mettre à jour le logiciel PG1 en comparant l’indice de complexité C et une valeur de référence dont la nature peut varier selon le cas. Il est par exemple possible, à partir du résultat de cette comparaison, de détecter ou anticiper des risques ou problèmes liés à une mise à jour OP ou encore de concevoir ou adapter ladite mise à jour OP avant même son application sur le logiciel PG1 .
[0091] Selon un exemple particulier, l’évaluation de la capacité RS à mettre à jour le logiciel PG1 peut également prendre en compte des ressources disponibles à un instant donné ou sur une période de temps donnée. Ainsi, plus les ressources disponibles seront importantes, plus la capacité RS est importante. [0092] La valeur de référence utilisée au cours de la quatrième opération peut par exemple être une valeur seuil. Ainsi, l’évaluation de la capacité RS à mettre à jour le logiciel PG1 peut comprendre l’émission d’une alerte AL (figure 1 ) par le dispositif 10 si l’indice de complexité C atteint (ou est supérieur ou égal à) la valeur seuil. De cette manière, on peut détecter, anticiper et/ou éviter une situation critique dans laquelle il serait particulièrement difficile de réaliser la mise à jour OP. La valeur de référence peut par exemple être prédéfinie pour permettre la détection d’une éventuelle explosion (ou d’un pic) de la complexité du logiciel PG1 qui se traduirait par une capacité réduite à mettre à jour le logiciel. A contrario, il est ainsi possible de détecter ou confirmer qu’une mise à jour OP peut être réaliser sans difficulté ou selon une efficacité acceptable.
[0093] Le résultat de l’évaluation réalisée au cours de la quatrième opération peut par exemple être utilisée pour adapter la mise à jour OP et/ou concevoir une stratégie de mise à jour applicable au le logiciel PG1 , par exemple en adaptant le profil P de mise à jour et/ou le nombre N de versions possibles.
[0094] Le résultat de l’évaluation réalisée au cours de la quatrième opération peut par exemple être utilisée pour contrôler la mise à jour OP du logiciel PG1 , par exemple en bloquant ou différant cette mise à jour ou en adaptant sa configuration.
[0095] Selon un exemple particulier, la complexité C et/ou la capacité RS peuvent être utilisées pour guider le développement d’une stratégie de mise à jour du logiciel PG1 dans le parc de véhicules 2.
[0096] Selon un exemple particulier, la complexité C et/ou la capacité RS peuvent être utilisées pour évaluer une capacité à réaliser sur une période donnée une campagne de mises à jour sur le logiciel PG1 implémenté dans le groupe 3 de véhicules 2.
[0097] Selon un exemple particulier, la complexité C et/ou la capacité RS peuvent être utilisées pour sélectionner l’une parmi au moins deux configurations différentes de mise à jour pour mettre à jour le logiciel PG1 . Chaque configuration de mise à jour peut être définie par un couple respectif (N ; P) définissant le nombre N de versions possibles et le profil P de mise à jour utilisé. [0098] Selon un exemple particulier, le dispositif 10 détermine au moins deux couples différents (N, P) pour mettre à jour le logiciel PG1 selon respectivement au moins deux configurations différentes de mise à jour, et détermine un indice de complexité C pour respectivement chaque couple (N, P). Le dispositif 10 peut ainsi déterminer un rapport de supériorité (ou rapport de complexité) entre lesdites au moins deux configurations de mise à jour par comparaison de leurs indices de complexité C respectifs. On peut ainsi déterminer par exemple qu’une première configuration de mise à jour présente une complexité C plus élevée que celle d’une deuxième configuration de mise à jour. Ce rapport peut définir un ordre de complexité entre une pluralité de configurations différentes de mise à jour. A partir du rapport de supériorité ainsi déterminé, le dispositif 10 peut sélectionner l’une ou l’autre des configurations de mise à jour, par exemple celle présentant l’indice de complexité la plus basse ou encore celle satisfaisant au moins un critère prédéfini prenant en compte ce rapport de supériorité.
[0099] Selon un exemple particulier, le dispositif 10 détermine en outre, à partir du rapport de complexité précité, la configuration de mise à jour la moins complexe, et sélectionne la configuration de mise à jour la moins complexe pour mettre à jour le logiciel PG1.
[0100] Selon un exemple particulier, après la quatrième opération, le dispositif 10 réalise la mise à jour OP sur le logiciel PG1 implémenté dans les véhicules 2, éventuellement après avoir adapté ou contrôlé cette mise à jour en fonction de la capacité RS et/ou de l’indice de complexité C (comme précédemment décrit). Cette mise à jour OP est par exemple réalisée par communication sans contact (mode OTA) entre le dispositif 10 et les véhicules 2 (ou avec leurs calculateurs embarqués 4 via des interfaces de communication).
[0101] Le processus de traitement décrit ci-avant dans des modes de réalisation particulier permet avantageusement d’améliorer la maintenance logicielle dans un ou des véhicules 2, par exemple mais par exclusivement de type automobile, notamment pour permettre des mises à jour logicielles rapides et efficaces. Grâce à l’indice de complexité C qui constitue une nouvelle métrique prenant en compte N et P, on peut évaluer efficacement une capacité RS à mettre à jour un logiciel PG1 dans un ou plusieurs véhicules, tels que dans un parc automobile par exemple. On peut ainsi aider à mettre à jour au moins un logiciel implémentable (ou implémenté) dans un ou des véhicules 2, en vue de permettre des mises à jour logicielles rapides et efficaces. Pour ce faire, le dispositif 10 simule ou modélise la ou les mises à jour à réaliser sur le logiciel PG1 en déterminant un indice de complexité C ainsi qu’une capacité RS de mise à jour comme précédemment décrit. De cette manière, on peut par exemple détecter des situations critiques et/ou adapter une stratégie de mise à jour logicielle. Le dispositif 10 peut éventuellement être en outre configuré pour réaliser les mises à jour elles-mêmes.
[0102] L’indice de complexité C peut être déterminé de façon rapide et fiable. En outre, il est possible d’appliquer le processus de traitement à des logiciels non encore implémentés dans des véhicules 2 ou de façon rétroactive à des logiciels existants déjà installés dans des véhicules 2.
[0103] Des exemples de réalisation de la troisième opération du processus de traitement, à savoir de la détermination de l’indice de complexité C, sont à présent décrits ci-après conjointement aux figures 3-9. Dans ces exemples, l’indice de complexité est déterminé en appliquant une méthode de calcul prenant en entrée le nombre N (où N=4 dans les exemples considérés), ladite méthode de calcul étant sélectionnée en fonction du profil P de mise à jour appliqué. Ainsi, diverses méthodes de calcul sont décrites pour différents profils P de mise à jour appliqués.
[0104] On peut par exemple considérer que toutes les versions possibles (VI-VN) du logiciel PG1 sont compatibles entre elles, bien que des variantes soient possibles où cela n’est pas le cas. En cas de compatibilité entre versions V, cela signifie que tous les versions V partagent une même architecture et que l’on peut passer d’une version à une autre en montant ou descendant dans l’ordre chronologique des versions (compatibilité ascendante et descendante selon l’ordre chronologique).
[0105] Comme illustré en figure 3 dans un mode de réalisation particulier, on considère que, conformément au profil P de mise à jour, la mise à jour OP - notée OP1 - doit être réalisée de façon incrémentale depuis la version initiale Va jusqu’à la version cible Vb (condition a1 )) et la version cible Vb est nécessairement la version VN la plus à jour (condition b1 )), à savoir V4 dans cet exemple.
[0106] Aussi, dans cet exemple, la mise à jour OP1 peut être l’une quelconque parmi :
[0107] Dans ce cas, la méthode de calcul suivante est sélectionnée :
[0108] [Math. 1]
C = N • (N — l)/2
[0109] Dans l’exemple considéré, l’indice de complexité C est donc égal à 6.
[0110] Une fois l’indice de complexité C déterminé, le nombre N peut être initialisé à 0.
Ainsi, lors d’une prochaine itération du processus de traitement, il sera pris en compte le fait que le logiciel a déjà été mis à jour à la version V4.
[0111] Comme illustré en figure 4 dans un mode de réalisation particulier, on considère que, conformément au profil P de mise à jour, la mise à jour OP - notée OP2 - doit être réalisée de façon directe (condition a2)) et la version cible Vb est nécessairement la version VN la plus à jour (condition b1 )), à savoir V4 dans cet exemple.
[0112] Aussi, dans cet exemple, la mise à jour OP2 peut être l’une quelconque parmi : et
[0113] Dans ce cas, la méthode de calcul suivante est sélectionnée :
[0114] [Math. 2]
C = N - 1
[0115] Dans l’exemple considéré, l’indice de complexité C est donc égal à 3. La complexité du logiciel est ici plus faible que dans l’exemple de la figure 3 en raison du fait les chemins possibles de mise à jour sont plus limités en nombre et plus simples. [0116] Une fois l’indice de complexité C déterminé, le nombre N peut être initialisé à 1 en vue d’effectuer une nouvelle itération du processus de traitement.
[0117] Comme illustré en figure 5 dans un mode de réalisation particulier, on considère que, conformément au profil P de mise à jour, la mise à jour OP - notée OP3 - doit être réalisée de façon incrémentale depuis la version initiale Va jusqu’à la version cible Vb (condition a1 )) et la version cible Vb est une quelconque version plus à jour que la version initiale Va (condition b2)).
[0118] Aussi, dans cet exemple, la mise à jour OP3 peut être l’une quelconque parmi :
[0119] Le caractère incrémental de la mise à jour permet d’avoir une bonne traçabilité de l’historique des versions du logiciel PG1 de chaque véhicule 2. En revanche, cela impose une contrainte en ce qu’il est nécessaire de conserver à disposition toutes les versions V possibles qui ne sont pas la version la plus à jour.
[0120] Dans ce cas, la méthode de calcul suivante est sélectionnée :
[0121] [Math. 3]
C = N • (N — l)/2
[0122] Dans l’exemple considéré, l’indice de complexité C est donc égal à 6.
[0123] Une fois l’indice de complexité C déterminé, on peut par exemple conserver le nombre N inchangé (N n’est pas réinitialisé en vue d’une prochaine itération du processus de traitement).
[0124] Comme illustré en figure 6 dans un mode de réalisation particulier, on considère que, conformément au profil P de mise à jour, la mise à jour OP - notée OP4 - doit être réalisée de façon directe depuis la version initiale Va jusqu’à la version cible Vb (condition a2)) et la version cible Vb est une quelconque version plus à jour que la version initiale Va (condition b2)). [0125] Aussi, dans cet exemple, la mise à jour OP4 peut être l’une quelconque parmi : V2 -> V3 ; V2 -> V4 ; et
[0126] Le caractère direct de la mise à jour permet de limiter la complexité du logiciel et donc de faciliter les mises à jour. En revanche, cela impose de conserver à disposition d’anciennes version V du logiciel. En outre, les différents véhicules 2 du parc 3 peuvent être inhomogènes en termes de version V implémentée. De multiples versions différentes du logiciel PG1 peuvent donc être installée à travers le parc 3 de véhicules 2.
[0127] Dans ce cas, la méthode de calcul suivante est sélectionnée :
[0128] [Math. 4]
C = N • (N — l)/2
[0129] Dans l’exemple considéré, l’indice de complexité C est donc égal à 6.
[0130] Une fois l’indice de complexité C déterminé, le nombre N peut par exemple être conservé inchangé en vue d’une itération ultérieure du processus de traitement.
[0131] Comme illustré en figure 7 dans un mode de réalisation particulier, on considère que, conformément au profil P de mise à jour, la mise à jour OP - notée OP5 - doit être réalisée de façon incrémentale depuis la version initiale Va jusqu’à une version intermédiaire correspondant à la version la plus à jour, à savoir VN=V4 dans cet exemple (cette première phase correspond par exemple à l’exemple de la figure 3). La mise à jour OP5 comprend en outre une rétrogradation de version du logiciel PG1 depuis la version intermédiaire dans la version cible Vb (condition c)). Cette rétrogradation (mise à jour descendante suivant l’ordre des versions) peut être un recul de d versions V depuis la version intermédiaire, où d est un nombre entier de rétrogradation tel que d < N.
[0132] Aussi, dans cet exemple, la mise à jour OP5 peut être l’une quelconque parmi : voire éventuellement aussi V3 -> V4 -> V3 si l’on considère que le cas particulier où Va=Vb constitue en soi une opération de mise à jour.
[0133] Ce scénario comprend donc deux étapes, à savoir une montée de version V selon l’ordre chronologique des versions jusqu’à une version intermédiaire puis une descente vers la version cible Vb. Une telle rétrogradation peut être avantageuse comme déjà expliqué précédemment.
[0134] Dans ce cas, la méthode de calcul suivante est sélectionnée :
[0135] [Math. 5]
C = d ■ QV - d) + N ■ QV - l)/2 + d ■ (d - l)/2
[0136] où d < N.
[0137] Dans l’exemple considéré, dans le cas où d=1 , l’indice de complexité C est donc égal à (4-1 ) + 4(4-1 )/2 + 0 = 9.
[0138] Une fois l’indice de complexité C déterminé, le nombre N peut par exemple être conservé inchangé en vue d’une itération ultérieure du processus de traitement.
[0139] Comme illustré en figure 8 dans un mode de réalisation particulier, on considère que, conformément au profil P de mise à jour, la mise à jour OP - notée OP6 - doit être réalisée de façon directe depuis la version initiale Va jusqu’à une version intermédiaire correspondant à la version la plus à jour, à savoir VN=V4 dans cet exemple. La mise à jour OP6 comprend en outre une rétrogradation de version du logiciel PG1 depuis la version intermédiaire dans la version cible Vb (condition c)). Cette rétrogradation (mise à jour descendante suivant l’ordre des versions) peut être un recul de d versions V depuis la version intermédiaire, où d est un nombre entier de rétrogradation tel que d < N.
[0140] On considère à titre d’exemple que d = 1 . Aussi, dans cet exemple, la mise à jour OP6 peut être l’une quelconque parmi :
[0141] Ce scénario comprend donc deux étapes, à savoir une montée de version V selon l’ordre chronologique des versions jusqu’à une version intermédiaire puis une descente vers la version cible Vb. Une telle rétrogradation peut être avantageuse comme déjà expliqué précédemment.
[0142] Dans ce cas, la méthode de calcul suivante est sélectionnée :
[0143] [Math. 6]
C = 2 ■ QV - 1)
[0144] Dans l’exemple considéré, dans le cas où d=1 , l’indice de complexité C est donc égal à 6.
[0145] Une fois l’indice de complexité C déterminé, le nombre N peut par exemple être réinitialisé à 2 en vue d’une itération ultérieure du processus de traitement.
[0146] Comme déjà indiqué, l’invention peut s’appliquer à une pluralité de logiciels PG1 implémentables (ou implémentés) dans chaque véhicule 2.
[0147] Selon un exemple particulier, le groupe 3 comprend une pluralité de véhicules 2 et une pluralité de logiciels PG1 sont implémentables dans chaque véhicule 2. Au cours du processus de traitement, le dispositif 10 :
- détermine un nombre N et un profil P de mise à jour pour respectivement mettre à jour chaque logiciel PG1 ;
- détermine un indice de complexité C pour respectivement chaque logiciel PG1 à mettre à jour ; et
- détermine, à partir de la somme Z des indices de complexité C, un indice de complexité global représentatif de la complexité à mettre à jour la pluralité de logiciels PG1.
[0148] Comme illustré en figure 9 dans un mode de réalisation particulier, le dispositif 10 peut ainsi déterminer respectivement un indice de complexité Ci pour effectuer une mise à jour OP - notée OP7-i - pour chaque logiciel PG1 implémentable dans un véhicule 2 donné, où i est un entier compris entre 1 et M, M étant le nombre de logiciels PG1 considérés par véhicule 2.
[0149] Dans ce cas, l’indice de complexité de l’ensemble des logiciels PG1 peut s’exprimer comme suit :
[0150] [Math. 7]
[0151] En sommant ainsi les indices de complexité pour chaque logiciels PG1 (par exemple dans autant de calculateurs 4 d’un véhicule 2), on peut ainsi évaluer la complexité associé à l’ensemble des logiciels PG1 et en déduire une capacité RS à mettre à jour cet ensemble de logiciels par comparaison l’indice de complexité global avec une valeur de référence comme déjà décrit.
[0152] Cette variante est avantageuse dans la mesure où les véhicules sont amenés à évolués de plus en plus vers une situation de mise à jour de plusieurs calculateurs en même temps. Ainsi, un package global de données de mise à jour peut être envoyé à un véhicule 2. Un calculateur central du véhicule 2 peut alors être configuré pour adresser les logiciels concernés aux autres calculateurs concernés du véhicule 2. Cette solution de package peut avantageusement aider à réduire la complexité du déploiement des mises à jour, notamment en raison du fait que le package peut contenir des logiciels cohérents les uns avec les autres. En revanche, cette technique de mise à jour par package ne réduit pas nécessairement la complexité d'un point de vue des variantes de réalisation (packages dédiés nécessaires pour un sous-ensemble de véhicules).
[0153] Selon un exemple particulier, les indices de complexité C respectifs de plusieurs calculateurs 4 sont pris en compte car les calculateurs ont des dépendances entre eux. L'indice de complexité C global peut intégrer le niveau de complexité de chaque calculateur individuel. Les paquets de données transmis par le dispositif 10, éventuellement par communication sans contact (OTA), peuvent alors être composés d'un ensemble de versions logicielles. Cependant, il peut y avoir une augmentation importante du nombre de paquets de données. Cela peut entraîner la sommation de la complexité de plusieurs calculateurs dans un paquet de mise à niveau logiciel.
[0154] Dans un exemple particulier, on peut considérer une mise à jour OP qui respecte un mode incrémental hybride, c’est-à-dire avec un palier correspond à 2 versions (Vi+2) ou plus (Vi+3, etc.) par saut de version. La méthode de calcul de l’indice de complexité C peut alors être calculé de façon analogue à ce qui est décrit dans le ZI présent document pour un mode incrémental classique avec un palier correspondant à 1 version V par saut de version.
[0155] La figure 10 illustre schématiquement un dispositif de traitement 10 configuré pour aider à une mise à jour logicielle, comme précédemment décrit en référence aux figures 1-9, selon un exemple de réalisation particulier et non limitatif de la présente invention. Le dispositif 10 correspond par exemple à un serveur distant vis-à-vis du ou des véhicules 2, par exemple un calculateur.
[0156] Le dispositif de traitement 10 est par exemple configuré pour la mise en oeuvre des opérations du processus de traitement (ou processus de modélisation) tel que précédemment décrit en regard des figures 1-9 et/ou des étapes du procédé décrit ci-après en regard de la figure 11 . Des exemples d’un tel dispositif de traitement 10 comprennent, sans y être limités, un équipement électronique embarqué tel qu’un ordinateur de bord d’un véhicule, un calculateur électronique tel qu’une UCE (« Unité de Commande Electronique »), un téléphone intelligent (de l’anglais « smartphone »), une tablette, un ordinateur portable. Les éléments du dispositif de contrôle 10, individuellement ou en combinaison, peuvent être intégrés dans un unique circuit intégré, dans plusieurs circuits intégrés, et/ou dans des composants discrets. Le dispositif de traitement 10 peut être réalisé sous la forme de circuits électroniques ou de modules logiciels (ou informatiques) ou encore d’une combinaison de circuits électroniques et de modules logiciels.
[0157] Le dispositif de traitement 10 comprend un (ou plusieurs) processeur(s) 40 configurés pour exécuter des instructions pour la réalisation des étapes du procédé (ou du processus) de traitement et/ou pour l’exécution des instructions du ou des logiciels embarqués dans le dispositif de traitement 10. Le processeur 40 peut inclure de la mémoire intégrée, une interface d’entrée/sortie, et différents circuits connus de l’homme du métier. Le dispositif de traitement 10 comprend en outre au moins une mémoire 41 correspondant par exemple à une mémoire volatile et/ou non volatile et/ou comprend un dispositif de stockage mémoire qui peut comprendre de la mémoire volatile et/ou non volatile, telle que EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, disque magnétique ou optique. [0158] Le code informatique du ou des logiciels embarqués comprenant les instructions à charger et exécuter par le processeur 40 est par exemple stocké sur la mémoire 41 . La mémoire 41 peut constituer un support d’informations selon un mode de réalisation particulier en ce qu’elle comprend un programme d’ordinateur (par exemple PG2 en figure 1) comportant des instructions pour la réalisation des étapes du procédé (ou du processus) de contrôle de l’invention.
[0159] Selon différents exemples de réalisation particuliers et non limitatifs, le dispositif de traitement 10 est couplé en communication avec d’autres dispositifs ou systèmes similaires et/ou avec des dispositifs de communication, par exemple une TCU (de l’anglais « Telematic Control Unit » ou en français « Unité de Contrôle Télématique »), par exemple par l’intermédiaire d’un bus de communication ou au travers de ports d’entrée / sortie dédiés.
[0160] Selon un exemple de réalisation particulier et non limitatif, le dispositif de traitement 10 comprend un bloc 42 d’éléments d’interface pour communiquer avec des dispositifs externes, par exemple un serveur distant ou le « cloud » ou les véhicule 2. Les éléments d’interface du bloc 42 peuvent comprendre une ou plusieurs des interfaces suivantes :
- interface radiofréquence RF, par exemple de type Wi-Fi® (selon IEEE 802.11 ), par exemple dans les bandes de fréquence à 2,4 ou 5 GHz, ou de type Bluetooth® (selon IEEE 802.15.1 ), dans la bande de fréquence à 2,4 GHz, ou de type Sigfox utilisant une technologie radio UBN (de l’anglais Ultra Narrow Band, en français bande ultra étroite), ou LoRa dans la bande de fréquence 868 MHz, LTE (de l’anglais « Long-Term Evolution » ou en français « Evolution à long terme »), LTE-Advanced (ou en français LTE-avancé) ;
- interface USB (de l’anglais « Universal Serial Bus » ou « Bus Universel en Série » en français) ;
- interface HDMI (de l’anglais « High Definition Multimedia Interface », ou « Interface Multimedia Haute Definition » en français).
[0161] Selon un autre exemple de réalisation particulier et non limitatif, le dispositif de traitement 10 comprend une interface de communication 43 qui permet d’établir une communication avec d’autres dispositifs via un canal de communication 45. L’interface de communication 43 correspond par exemple à un transmetteur configuré pour transmettre et recevoir des informations et/ou des données via le canal de communication 45. L’interface de communication 43 correspond par exemple à un réseau filaire de type CAN (de l’anglais « Controller Area Network » ou en français « Réseau de contrôleurs »), CAN FD (de l’anglais « Controller Area Network Flexible Data-Rate » ou en français « Réseau de contrôleurs à débit de données flexible »), FlexRay (standardisé par la norme ISO 17458), Ethernet (standardisé par la norme ISO/IEC 802-3) ou LIN (de l’anglais « Local Interconnect Network », ou en français « Réseau interconnecté local »).
[0162] Le dispositif de traitement 10 coopèrent par exemple avec les véhicules 2 au moyen du bloc 42 d’éléments d’interface ou de l’interface de communication 43, comme décrit précédemment.
[0163] Selon un exemple de réalisation particulier et non limitatif, le dispositif de traitement 10 peut fournir des signaux de sortie à un ou plusieurs dispositifs externes, tels qu’un écran d’affichage, tactile ou non, un ou des haut-parleurs et/ou d’autres périphériques (système de projection) via des interfaces de sortie respectives. Selon une variante, l’un ou l’autre des dispositifs externes est intégré au dispositif de contrôle 10.
[0164] La figure 11 illustre un diagramme des différentes étapes d’un procédé de traitement pour la mise à jour d’au moins un logiciel, tel que par exemple du logiciel PG1 dans le ou les véhicules 2 comme précédemment décrit. Le procédé est par exemple mis en oeuvre par le dispositif de traitement 10 précédemment décrit, ce dispositif pouvant être un serveur distant vis-à-vis des véhicules 2.
[0165] Dans une première étape 51 , un nombre N de versions possibles que peut présenter ledit au moins un logiciel PG1 est déterminé, N étant un entier au moins égal à 2, les N versions étant organisées selon un ordre chronologique depuis une version la plus ancienne jusqu’à une version la plus à jour.
[0166] Dans une deuxième étape 52, un profil P de mise à jour est déterminé, ce profil P définissant au moins une condition à respecter par une mise à jour OP dudit au moins logiciel PG1 depuis une version initiale Va vers une version cible Vb dudit logiciel
[0167] Dans une troisième étape 53, un indice de complexité C représentatif d’une complexité dudit au moins logiciel PG1 est déterminé à partir du nombre N et du profil P.
[0168] Dans une troisième étape 54, une capacité à mettre à jour ledit au moins un logiciel PG1 est évaluée par comparaison de l’indice de complexité C avec une valeur de référence.
[0169] Selon des variantes de réalisation, les variantes et exemples des opérations décrits ci-avant en relation avec les figures 1 -10 s’appliquent aux étapes du procédé de traitement de la figure 11 .
[0170] Comme le comprend l’homme du métier, tous les modes de réalisation et variantes décrits ci-avant dont certains ont été simplifiés à dessein pour faciliter les explications, ne constituent que des exemples non limitatifs de mise en oeuvre de la présente divulgation. En particulier, l’homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant, afin de répondre à un besoin particulier.
[0171] La présente invention ne se limite donc pas aux exemples de réalisation décrits ci-avant mais s’étend notamment à un procédé de traitement qui inclurait des étapes secondaires sans pour cela sortir de la portée de la présente invention. Il en serait de même d’un dispositif configuré pour la mise en oeuvre d’un tel procédé.

Claims

REVENDICATIONS
1 . Procédé de traitement mis en oeuvre par un dispositif de traitement (10) pour aider à mettre à jour au moins un logiciel (PG1 ) implémentable dans un groupe (3) d’au moins un véhicule (2), ledit procédé comprenant :
- détermination (51 ) d’un nombre N de versions (V) possibles que peut présenter ledit au moins un logiciel, N étant un entier au moins égal à 2, les N versions étant organisées selon un ordre chronologique depuis une version la plus ancienne jusqu’à une version la plus à jour ;
- détermination (52) d’un profil P de mise à jour définissant au moins une condition à respecter par une mise à jour (OP) dudit au moins logiciel depuis une version initiale (Va) vers une version cible (Vb) dudit logiciel ;
- détermination (53), à partir du nombre N et du profil P, d’un indice de complexité C représentatif d’une complexité dudit au moins logiciel (PG1 ) ; et
- évaluation (54) d’une capacité (RS) à mettre à jour ledit au moins un logiciel par comparaison de l’indice de complexité C avec une valeur de référence.
2. Procédé selon la revendication 1 , dans lequel le profil (P) de mise à jour définit au moins l’une des conditions suivantes : a) la mise à jour est réalisée de façon incrémentale depuis la version initiale (Va) jusqu’à la version cible (Vb) ou la mise à jour est réalisée de façon directe depuis la version initiale (Va) jusqu’à la version cible (Vb) ; b) la version cible (Vb) de la mise à jour est la version la plus à jour ou la version cible (Vb) est une quelconque version plus à jour que la version initiale (Va) ; et c) la mise à jour (OP) comprend une rétrogradation de version dudit au moins un logiciel depuis une version intermédiaire vers la version finale (Vb).
3. Procédé selon la revendication 1 ou 2, N étant un entier au moins égal à 3 ou au moins égal à 4.
4. Procédé selon l’une quelconque des revendications précédentes, dans lequel la valeur de référence est une valeur seuil, l’évaluation de ladite capacité (RS) comprenant :
- émission d’une alerte (AL) si l’indice de complexité C atteint la valeur seuil.
5. Procédé selon l’une quelconque des revendications précédentes, dans lequel le procédé comprend au moins l’un parmi :
- évaluation, à partir de l’indice de complexité C et/ou de la capacité (RS) à mettre à jour, d’une capacité à réaliser sur une période donnée une campagne de mises à jour sur ledit au moins un logiciel implémenté dans le groupe d’au moins un véhicule ; et
- définition, à partir de l’indice de complexité C et/ou de la capacité (RS) à mettre à jour, d’une stratégie de mise à jour dudit au moins un logiciel (PG1 ) implémenté dans le groupe d’au moins un véhicule.
6. Procédé selon l’une quelconque des revendications précédentes, dans lequel :
- au moins deux couples différents (N, P) sont déterminés pour mettre à jour ledit au moins logiciel (PG1 ) selon respectivement au moins deux configurations différentes de mise à jour ; et
- un indice de complexité C est déterminé pour respectivement chaque couple (N, P) ; le procédé comprenant en outre :
- détermination d’un rapport de complexité entre lesdites au moins deux configurations de mise à jour par comparaison de leurs indices de complexité respectifs.
7. Procédé selon la revendication 6, comprenant :
- détermination, à partir du rapport de complexité, de la configuration de mise à jour la moins complexe ; et
- sélection de la configuration de mise à jour la moins complexe pour mettre à jour ledit au moins un logiciel (PG1 ).
8. Procédé selon l’une quelconque des revendications précédentes, dans lequel l’indice de complexité C est déterminé à partir d’une formule de calcul prenant en entrée N, ladite formule de calcul étant sélectionnée en fonction du profil P de mise à jour.
9. Programme d’ordinateur (PG2) comportant des instructions pour la mise en oeuvre du procédé selon l’une quelconque des revendications précédentes, lorsque ces instructions sont exécutées par un processeur.
10. Dispositif de traitement (10) pour aider à mettre à jour au moins un logiciel (PG1 ) implémenté dans un groupe (3) d’au moins un véhicule (2), ledit dispositif (10) comprenant une mémoire (41 ) associée à au moins un processeur (40) configuré pour la mise en oeuvre des étapes du procédé selon l’une quelconque des revendications 1 à
8.
EP23836558.9A 2023-01-13 2023-12-11 Procédé et dispositif de traitement pour la mise à jour logicielle de véhicule Pending EP4649392A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2300328A FR3145056B1 (fr) 2023-01-13 2023-01-13 Procédé et dispositif de traitement pour la mise à jour logicielle de véhicule
PCT/FR2023/051972 WO2024149944A1 (fr) 2023-01-13 2023-12-11 Procédé et dispositif de traitement pour la mise à jour logicielle de véhicule

Publications (1)

Publication Number Publication Date
EP4649392A1 true EP4649392A1 (fr) 2025-11-19

Family

ID=85685697

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23836558.9A Pending EP4649392A1 (fr) 2023-01-13 2023-12-11 Procédé et dispositif de traitement pour la mise à jour logicielle de véhicule

Country Status (3)

Country Link
EP (1) EP4649392A1 (fr)
FR (1) FR3145056B1 (fr)
WO (1) WO2024149944A1 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2300328A1 (fr) 1975-02-07 1976-09-03 Cem Comp Electro Mec Procede et dispositif de mesure de la rugosite de surface
US9383989B1 (en) * 2014-06-16 2016-07-05 Symantec Corporation Systems and methods for updating applications
JP6930949B2 (ja) * 2018-08-02 2021-09-01 株式会社日立製作所 ソフトウェア配信システム、ソフトウェア配信サーバ、及びソフトウェア配信方法

Also Published As

Publication number Publication date
WO2024149944A1 (fr) 2024-07-18
FR3145056A1 (fr) 2024-07-19
FR3145056B1 (fr) 2025-10-03

Similar Documents

Publication Publication Date Title
EP3824389B1 (fr) Procédé de coordination d&#39;une pluralité de serveurs de gestion d&#39;équipements
FR2845175A1 (fr) Procede et systeme de commutation entre deux images ou plus d&#39;un progiciel sur un dispositif hote
EP1387261A1 (fr) Logiciel de generation de code d&#39;application informatique et langage de description de logiciel
WO2004016066A2 (fr) Editeur et procede d&#39;edition de formules de calcul du prix d&#39;un service et systeme de valorisation automatique d&#39;un service
WO2010034920A1 (fr) Determination et gestion de reseaux virtuels
EP3108361A2 (fr) Procédé de déploiement d&#39;un ensemble d&#39;application(s) logicielle(s)
EP4649392A1 (fr) Procédé et dispositif de traitement pour la mise à jour logicielle de véhicule
EP3506201B1 (fr) Système et procédé adaptatifs de suivi automatique d au moins une cible dans au moins un flux vidéo
WO2009044026A1 (fr) Dispositif d&#39;adaptation d&#39;un systeme multimedia dans un vehicule
EP3539259B1 (fr) Procédé et dispositif d&#39;actualisation d&#39;un modèle prédictif d&#39;une variable relative à un terminal mobile
FR2973131A1 (fr) Procede et dispositif de detection d&#39;incompatibilites d&#39;interfaces logiques d&#39;equipements de systemes embarques
WO2010060926A1 (fr) Procede et systeme pour la transformation de composants logiciel ccm en composant deployables dans un environnement compatible du standard sca
FR2864285A1 (fr) Procede de remontee automatique des exigences de modeles uml et de leur mise a jour
US12468722B1 (en) System, method, and computer program for autoscaling data lake connections
FR3136289A1 (fr) Procédé et dispositif de contrôle de calculateurs d’un véhicule
EP3506703B1 (fr) Procédé d&#39;allocation de ressources radio dans un réseau sans fil, par apprentissage
FR3160028A1 (fr) Procédé et dispositif de contrôle d’applications embarquées dans un véhicule
FR3154207A1 (fr) Procédé et dispositif de traitement de données de véhicules connectés à un réseau de communication sans fil
WO2025104386A1 (fr) Système et méthode pour la mise à jour logicielle d&#39;un véhicule
EP4288854A1 (fr) Procédé et dispositif de validation de synchronisation temporelle entre calculateurs embarqués de véhicule
FR3151110A1 (fr) Procédé et dispositif de contrôle d’applications embarquées dans un véhicule
EP2784680A2 (fr) Procédé d&#39;exécution d&#39;un logiciel sécuritaire et d&#39;un logiciel non sécuritaire entrelacés
FR3151458A1 (fr) Procédé et dispositif de contrôle de configuration d’une infrastructure réseau d’un véhicule
EP4206907A1 (fr) Procédé et système de supervision de mise à jour de logiciel de support dans une infrastructure de fourniture de services
EP4575756A1 (fr) Arbre de réduction produit pour la représentation machine

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250723

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)