WO2021105089A1 - Procédé de mise à jour de système numérique - Google Patents

Procédé de mise à jour de système numérique Download PDF

Info

Publication number
WO2021105089A1
WO2021105089A1 PCT/EP2020/083141 EP2020083141W WO2021105089A1 WO 2021105089 A1 WO2021105089 A1 WO 2021105089A1 EP 2020083141 W EP2020083141 W EP 2020083141W WO 2021105089 A1 WO2021105089 A1 WO 2021105089A1
Authority
WO
WIPO (PCT)
Prior art keywords
computer
board
vehicle
transition
digital content
Prior art date
Application number
PCT/EP2020/083141
Other languages
English (en)
Inventor
Eric Abadie
Marie-Cecile AFANTENOS
Sébastien BESSIERE
Solène GROS
Claire TENOR
Gregory Meunier
Original Assignee
Renault S.A.S
Nissan Motor Co., Ltd.
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 Renault S.A.S, Nissan Motor Co., Ltd. filed Critical Renault S.A.S
Priority to CN202080084016.9A priority Critical patent/CN114746838A/zh
Priority to US17/776,630 priority patent/US11928458B2/en
Priority to KR1020227022355A priority patent/KR20220108129A/ko
Priority to EP20808154.7A priority patent/EP4066103A1/fr
Priority to JP2022529428A priority patent/JP2023503288A/ja
Publication of WO2021105089A1 publication Critical patent/WO2021105089A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/656—Updates while running
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L50/00—Electric propulsion with power supplied within the vehicle
    • B60L50/50—Electric propulsion with power supplied within the vehicle using propulsion power supplied by batteries or fuel cells
    • B60L50/53—Electric propulsion with power supplied within the vehicle using propulsion power supplied by batteries or fuel cells in combination with an external power supply, e.g. from overhead contact lines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
    • G06F15/7803—System on board, i.e. computer system on one or more PCB, e.g. motherboards, daughterboards or blades
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60Y—INDEXING SCHEME RELATING TO ASPECTS CROSS-CUTTING VEHICLE TECHNOLOGY
    • B60Y2200/00—Type of vehicle
    • B60Y2200/90—Vehicles comprising electric prime movers
    • B60Y2200/91—Electric vehicles
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60Y—INDEXING SCHEME RELATING TO ASPECTS CROSS-CUTTING VEHICLE TECHNOLOGY
    • B60Y2200/00—Type of vehicle
    • B60Y2200/90—Vehicles comprising electric prime movers
    • B60Y2200/92—Hybrid vehicles
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00—Road transport of goods or passengers
    • Y02T10/60—Other road transportation technologies with climate change mitigation effect
    • Y02T10/70—Energy storage systems for electromobility, e.g. batteries
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00—Road transport of goods or passengers
    • Y02T10/60—Other road transportation technologies with climate change mitigation effect
    • Y02T10/7072—Electromobility specific charging systems or methods for batteries, ultracapacitors, supercapacitors or double-layer capacitors

Definitions

  • TITLE Digital system update process.
  • the invention relates to a method for updating a digital system in a vehicle, in particular in a motor vehicle.
  • a digital system in a vehicle comprises one or more on-board computers communicating with one another via one or more on-board buses.
  • an on-board computer generally comprises a permanent memory for storing at least permanent digital data, firmware and / or a computer program.
  • the on-board computer generally also comprises a random access memory for storing variable digital data, and at least one processor for writing and / or reading the variable digital data in random access memory by executing the computer program from all or part of the permanent digital data and variable digital data.
  • An update of the digital system consists of modifying digital content in the permanent memory of at least one on-board computer.
  • Document FR2775363 discloses a vehicle computer suitable for being connected to a stored data update tool, but it is preferable to stop the vehicle to connect the update tool.
  • Document FR3011651 discloses a method for updating a vehicle computer using an interface box, however the implementation of the method requires stopping the vehicle to connect the box.
  • Document FR2775371 discloses a method for downloading an update file in rewritable memory of a vehicle computer.
  • Today a wide range of wireless remote transmission possibilities provide opportunities for downloading update files into on-board vehicle control units without having to plug a physical connector into the vehicle.
  • the known methods and devices still require a more or less extended duration of the vehicle to update a data or program file in an on-board control-command unit.
  • Writing from a remote server to rewritable memory of an on-board control unit requires more time than to conventional computer or mobile phone memory. Stopping the vehicle is still recommended to avoid an unexpected change in driving behavior of the vehicle, linked to the update.
  • There is a need to reduce to minimum a control-command unit update time, in particular to reduce the downtime of the vehicle to a minimum, to switch from a previous on-board control-command unit configuration to a new configuration by updating program or data day.
  • Document EP2249251A1 discloses an update device comprising a server, an on-board control unit in a vehicle, communication means for connecting the server and on-board control unit, in which when the server executes a process of rewriting a program of the on-board control unit via the communication means, the server determines whether or not to execute the rewrite of the program by referring to a memory content of the control unit on-board control. If an abnormality or communication breakdown occurs during the rewrite task, the rewrite process is not completed, a reset is performed, the previous program is started.
  • the device disclosed by the document cited above has many drawbacks, including in particular that of postponing to an intolerably distant date the update of the on-board control unit in the event of anomalies and / or repeated communication breaks. .
  • Such cases can occur in a vehicle, for example when it is under a tunnel or in an underground car park, for example also in the event of a drop in voltage on the on-board electrical network of the vehicle to which telecommunications are sensitive and writing in rewritable memory, which also consumes a lot of electricity.
  • Each attempt to rewrite a program necessary for the operation of the vehicle renders the vehicle unavailable until the rewritten program or the previous program is started depending on whether the rewriting was performed correctly or not.
  • the subject of the invention is a method for updating a digital system in a vehicle comprising an on-board client computer, in particular of the multimedia type, capable of communicating with a server. remote, an on-board control unit connected, directly or indirectly, to the customer computer by an on-board communication network, and an electrical energy storage device for supplying the on-board computer and on-board control-command unit
  • the process is remarkable in that it includes:
  • the computer is said to be a customer in that it differs from the control-command unit by its ability to process media or support other than control-commands of actuators and sensors of the vehicle, as for example to process a download using the FTP protocol.
  • the processing resources of the client computer to download an update file, the resources necessary for the update in the control unit are reduced, and therefore its cost, an effect which is all the more advantageous.
  • an on-board digital system generally includes many control units.
  • the download time is completely transparent for the control unit because the latter is not affected by the download.
  • the electric energy storage device capable of being recharged during the download ensures not to disturb not only the download, but also other electrical consumers of the vehicle by the electricity consumption of the download.
  • a multimedia calculator is an example of a customer calculator.
  • the on-board instrumentation and control unit is connected, directly or indirectly, to the customer computer, it is therefore any type of control unit regardless of the way in which it is connected to the customer computer, whether by for example directly by a communication link, or again via a gateway computer and communication links, or else by both ways.
  • the client computer is interfaced with a remote server and directly or indirectly controls the various steps of the method according to the invention, for example it indirectly distributes a part of the downloaded file intended for certain control-command units.
  • on-board vehicles for which distribution is controlled by the customer computer and then managed by the gateway computer are examples of the downloaded file intended for certain control-command units.
  • the client computer constantly stores a download progress point so as to stop the download when an effective or risky degradation of communication with the remote server is detected, and resumes the download from the point of progress stored when it detects a disappearance of effective or risky degradation of communication with the remote server.
  • the causes of effective communication degradation are multiple, passage of the vehicle through a tunnel or in an underground car park, interruption by another priority process over the download, failure of the remote server or others.
  • the device for accumulating electrical energy that cannot be recharged is considered by the method to constitute a condition for detecting risky degradation of communication with the remote server.
  • the electric energy storage device is considered to be able to be recharged if the heat engine is rotating.
  • the rotating heat engine can, for example, recharge the electrical energy storage device by means of an alternator or an alternator starter.
  • the electric energy storage device is considered to be able to be recharged if the electric traction battery is connected to an external electric recharging network. This case can occur not only for a purely electric traction vehicle, but also for a plug-in hybrid vehicle on an external electrical network or by means of the heat engine.
  • the on-board communication network comprises a first on-board link connected to the customer computer, a second on-board link connected to the on-board control unit and a gateway computer connected to the customer computer and to the on-board control unit, an execution of the installation step of all or part of the distributed file downloaded in the control-command unit onboard by the computer gateway, allows the on-board control unit to be relieved of installation tasks, thus keeping the on-board control unit fully available for its control-command tasks, for any control-command unit of which at least one processor is indirectly linked to the customer computer via the gateway.
  • an execution of the installation step of all or part of the file downloaded in the on-board control unit, by the gateway computer makes it possible to unload the on-board control unit from installation tasks, thus keeping the control unit On-board instrumentation and control fully available for its monitoring and control tasks, in particular for any instrumentation and control unit indirectly linked to the customer computer via the gateway.
  • the method consists in making the on-board control unit operate on a first bank of rewritable memory while the installation step is being carried out. applied to a second rewritable memory bank.
  • a brief stop of the vehicle may be sufficient because the availability of the control unit during the download, distribution and installation steps above, allows the vehicle to be left running until the stop, then carried out simply to avoid the user of the vehicle to be surprised by a change in behavior during operation of the vehicle.
  • the method comprises a step of pre-downloading descriptive data, which will make it possible to characterize the digital contents of the downloaded files and to dynamically configure the user experience during each update.
  • the downloaded file obtained at the end of the downloading step includes other descriptive data, which will in particular make it possible to secure the content.
  • digital files downloaded for control units directly connected to the customer computer are directly connected to the customer computer.
  • At least part of the pre-downloaded descriptive data includes configuration metadata.
  • the method comprises at least one step of verifying at least one activation condition, said at least one activation condition being a function of at least part of the descriptive data, which allows dynamic configuration. to say a diversified and dynamic management of the update campaigns, which can thus be defined upstream in a disembarked way.
  • At least one of said steps of the digital system update method comprises a sub-step of interaction between the man-machine interface apparatus and the user via the man-machine interface apparatus. according to a specific mode of interaction, in particular as a function of said step in progress. For example, user comfort is further enhanced when the activation step requires consent from a user of the vehicle to be performed.
  • the subject of the invention is also a digital system embedded in a vehicle comprising an on-board client computer capable of communicating with a remote server, an on-board control-command unit connected to the client computer by an on-board communication network, each supplied by a device. for accumulating electrical energy, characterized in that the on-board customer computer and the on-board control unit are programmed to execute the method according to the invention.
  • the on-board communication network comprises a first on-board bus connected to the customer computer, a second on-board bus connected to the on-board control unit, and a gateway computer connected to the two said on-board buses, so that the gateway computer is programmed to perform the installation step in accordance with the method.
  • the subject of the invention is also a motor vehicle comprising an on-board digital system according to the invention.
  • FIG. 1 schematically shows a vehicle comprising a digital system on which the invention is implemented
  • FIG. 2 shows pre-download sequence and download sequence steps within the method according to the invention
  • FIG. 3 shows the distribution and installation steps for a first type of on-board computer
  • FIG. 4 shows distribution and installation steps for a second type of on-board computer
  • FIG. 5 shows the distribution and installation diagram for a third type of on-board computer
  • FIG. 6 shows the activation steps for a first type of updated on-board computer
  • FIG. 7 shows activation steps for a second type of updated on-board computer.
  • FIG. 1 shows a vehicle 4 comprising a digital system in which the invention is implemented.
  • the digital system comprises at least two on-board computers 10,
  • a man-machine interface device 12 equipped with one or more screens, can include a communication coupler on the on-board bus 5.
  • the customer on-board computer 10 Customer on-board computer 10 comprises one or more processors and a memory capacity sized to give it computing resources suitable for processing large digital information, such as that necessary for the pictographic display and the perception of human commands by the on-board bus 5 or by direct connection to the man-machine interface device 12, to exchanges with other on-board computers of the digital system, to communication outside the vehicle, and to the execution of level computer programs operational and / or application.
  • the customer on-board computer 10 Customer on-board computer 10 is for example often designated by the acronym IVI (In-Vehicle Infotainment).
  • IVI Intelligent Visual Informationtainment
  • the customer on-board computer 10 can be fitted to the customer's on-board computer 10 with one or more sockets 3 of the USB, OBD or other type.
  • a USB type socket 3 allows, for example, transfers of files stored or to be stored in the memory of a USB key. It is also possible to equip the customer on-board computer 10 with means of communication by air OTA (Over The Air in English), to establish communications 1, for example to an 802.11 type standard with a remote server 101.
  • air OTA Over The Air in English
  • control-command units Apart from the customer computer 10, the other computers are on-board control-command units, which can be of three different types.
  • the second type designating the control units indirectly linked to the customer computer 10 via the gateway computer 21, they are therefore in the secure zone and of a more basic nature, their memories are preferably of internal double bank nature (two banks of rewritable executable memory eg Flash, EEPROM) or external memory type.
  • the third type designates hybrid computers which have two processors, one therefore being in connection with the customer computer 10 and the other in connection with the gateway computer 21.
  • the on-board computer 21 is of the gateway type (GW for Gâte Way in English).
  • the on-board computer 21 makes it possible to exchange digital information between the first on-board bus 5 and a second on-board bus 6 of the digital system.
  • the digital system comprises one or more onboard computers 31, 32, 33 arranged to communicate with each other and with the onboard computer 21, on the second onboard bus 6.
  • the onboard computer (s) 31, 32, 33 are of the UCE type (acronym for Electronic Control Unit).
  • an electronic control unit comprises one or more outputs each connected to an actuator of the vehicle, a communication coupler on the on-board bus 6, and an electronic digital processing circuit for controlling, in a known manner. itself, moreover, by means of firmware, the actuator (s) as a function of digital data circulating on the on-board communication bus 6.
  • Each on-board computer 31, 32, 33 constituting an electronic control unit can also include one or more inputs connected to sensors and / or control units of the vehicle, to execute the firmware.
  • the on-board bus 6 is represented in a simplified manner in FIG. 1, it can comprise several branches connected to each other by secondary gateways not shown and without particular impact on the operation of the invention.
  • the digital system of the vehicle 4 can also include an on-board computer 11 which comprises means of communication by air at a longer distance than, for example, that of the 802.11 standard.
  • the means of communication by air (OTA) of the on-board computer 11, make it possible for example in a manner known per se moreover, to establish a communication 2 by cellular telephone network of version 4G or higher with a remote server 102, identical, separate and or connected to the remote server 101.
  • the on-board computer 11 can envisaged for the on-board computer 11, such as, for example, purely by way of illustration and not exhaustive, a satellite communication mode or a mixed mode of downlink wireless communication and of upstream GSM communication.
  • the on-board computer 11 is not necessarily distinct from the on-board computer 10.
  • digital system versions can be envisaged in which the customer on-board computer 10 on the customer's on-board computer
  • the on-board computer 11 integrates the functionalities of the on-board computer 11.
  • the on-board computer 11 is connected to the on-board customer computer 10 on-board customer computer 10 by the bus 5 or by a direct link, to allow the customer onboard computer 10 to benefit from its long-distance communication possibilities.
  • the on-board computer 11 is then for example of the type often designated by the acronym IVC (In-Vehicle Communication in English for Communication In the Vehicle).
  • the digital system of the vehicle 4 can also include an on-board computer 22 without direct impact on the operation of the vehicle, and for this reason connected to the on-board bus 5.
  • the digital system of the vehicle 4 can also include an on-board computer 23 of the electronic control unit type with high digital processing capacity, for example to supervise and / or manage several functions of the vehicle 4.
  • the on-board computer 23 is used. then connected to the on-board bus 5 to process data without direct impact on the operation of the vehicle or data on which
  • the computer 23 is connected to the on-board bus 5 to process data with an impact on the operation of the vehicle.
  • the computer 23 can also be connected to the computer 10 by a direct link 7 (for example via CAN, FTP, Ethernet protocol) and to the gateway computer by an on-board communication bus 8
  • the customer on-board computer 10 Customer on-board computer 10 and at least one of the on-board computers 21, 22, 23 connected to the on-board bus 5, in particular the on-board computer 21, host a distributed computer program, comprising computer instructions for implementing the updating method explained below, when the distributed computer program is executed by the computers on which it is hosted.
  • the steps of the method described in the following figures are divided into three phases, namely the first phase of exchanges between a remote server 101 and the client onboard computer 10, containing steps of pre-downloading descriptive data and downloading digital content.
  • the second phase of exchanges between the customer on-board computer 10 and a type of on-board computer 20, 30, 23, (indirectly via the gateway computer 21 for the second or second computers).
  • FIG. 2 shows process steps according to the invention for pre-downloading and downloading digital content from a remote download server 101
  • a transition 1001 is validated when the existence of an update to be carried out is signaled, in particular via interface software with the outside world , in memory of the client on-board computer 10 by the remote server 101 and that the vehicle 4 is in satisfactory conditions to perform a pre-download.
  • the client on-board computer 10 constitutes a download client on-board computer with regard to the digital system update process disclosed.
  • the existence of an update to be carried out results from an upstream process known per se elsewhere.
  • the fact that the vehicle 4 has a sufficient level of connectivity to a telecommunications network generates a satisfactory condition for performing a pre-download A state of the vehicle 4 when it is electrically powered or with rechargeable hybrid propulsion, in which it is connected to an electrical battery recharging network, or if it is in motion, in which it is in a deceleration phase, generates a satisfactory condition for pre-download. A state of the vehicle 4 when it is thermal propulsion or hybrid propulsion, in which its internal combustion engine is running, generates a satisfactory condition for performing a pre-download, whether the vehicle is running or stationary.
  • a validation of the transition 1001 passes the method to a step 1002 which consists in pre-downloading descriptive data of the content to be downloaded.
  • These descriptive data include for example the VIN number (Vehicle Identification Number in English), the address of the digital contents to download (for example URL), the ordering list of the contents to download, configuration metadata specifying in particular the mode of interaction without user request (background) or with user request (foreground).
  • the client on-board computer 10 begins by sending a pre-download request to the server 101 then stores the descriptive content data in buffer memory as they arrive.
  • the pre-download request contains in particular a VIN number of the vehicle 4 to which the on-board computer 10 belongs.
  • the customer on-board computer 10 checks in particular that the descriptive data received does indeed correspond to the specifications of the vehicle identified by the VIN number.
  • a transition 10101 is validated when the server receives the pre-download request sent by the client on-board computer 10 in the pre-download step 1002.
  • a validation of the transition 10101 passes the method into a step 10102 which consists in sending the descriptive data of the content to be downloaded to the onboard computer 10.
  • the remote server 101 can use the FTP protocol to transfer the descriptive data under form of file or UDP on a telecommunication channel available by electromagnetic waves, 802.11, cellular telephony, ad hoc network (WANET, MANET, VANET ...) or other, the most appropriate depending on whether the vehicle is stationary or in movement, and / or depending on the environment of the vehicle 4, ie the telecommunication means available in its location.
  • a wired telecommunication channel 802.3 over Ethernet cable or Power Line Carrier
  • step 1002 executed in the onboard computer 10 consists in storing in internal memory the files or frames received from the server 101 directly by means of communications 1 on a telecommunications coupler specific to the on-board computer 10, or indirectly via another server 102 at the heart of the cellular telephone network, another on-board computer 11 (IVC) dedicated to telecommunications and an on-board bus 5.
  • IVC on-board computer 11
  • a transition 1003 is validated in the event of loss by the vehicle 4 of a satisfactory condition for performing a pre-download.
  • the loss of satisfactory condition may result from a loss of connectivity to the telecommunications network, for example when the vehicle passes through a tunnel or enters an area with poor network coverage.
  • the loss of satisfactory condition may result from a shutdown of the internal combustion engine when the vehicle 4 is thermal propulsion or non-rechargeable hybrid propulsion, for example when the driver leaves the vehicle to buy a baguette.
  • a battery power cut can also constitute a loss of satisfactory condition.
  • a validation of the transition 1003 passes the method to a step 1004 which consists in placing the on-board computer on standby for satisfactory conditions in order to perform a pre-download.
  • the customer on-board computer 10 can use an STR (acronym for the English expression Suspend To RAM) type method relating to the management of the energy making it possible to suspend the execution of the processes and to memorize their state in order to restore them identically after switching off the on-board computer.
  • STR for the English expression Suspend To RAM
  • a transition 1005 is validated when all the conditions satisfactory to the pre-download are found, reconnection to a telecommunications network for example at the exit of the tunnel, restart of the heat engine, for example on the return of the driver with his French baguette.
  • Validating the transition 1005 returns the process to step 1002, which consists of informing the server 101 of its availability and continuing to store the descriptive data sent by the server 101.
  • the server 101 simply remains on standby in step 10102 in a manner usually provided for in the FTP and UDP protocols to resume the transmission where it was interrupted.
  • a transition 1007 is validated when all the descriptive data have been stored in the buffer memory of the on-board computer 10.
  • a validation of the transition 1007 passes the method into a step 1008 which consists in downloading digital content comprising descriptive data characterizing them (in particular security data linked in particular to secure content intended for computers of the first type (in an unsecured zone). ) or to a gateway computer 21 for the purpose of updating a second type or hybrid computer (in this case these data contain, for example, information on the recipient of the update, of the target of the update.
  • the computer embeds arched client 10 begins by sending a download request to the server 101, for example on the FTP port of the on-board computer 10 when the FTP protocol is used, or via another port depending on the type of communication (Wifi, Ethernet, etc.).
  • a transition 10103 is validated when the server receives the download request sent by the client onboard computer 10 in step 1008.
  • a validation of the transition 10103 passes the method into a step 10104 which consists in transmitting the required contents to the on-board computer 10.
  • the remote server preferably uses an FTP type protocol to transfer the contents in the form of. one or more files on an available telecommunications channel similar to the procedure of step 10102.
  • step 1008 is executed in onboard computer 10, in a manner comparable to step 1002 of pre-download with storage in internal buffer memory.
  • the use in particular of the FTP protocol on a port of the IVI allows execution in parallel without interruption with steps of other telecommunication methods on other ports or using other protocols. For example, if the customer on-board computer 10 receives on the on-board bus 5 from the on-board computer 11 or from an OBD diagnostic socket, frames linked to a remote or local diagnostic process, executed in parallel, the frames are simply routed, in particular internally from the customer on-board computer 10, without the need to interrupt step 1008 at any time.
  • the computer 10 performs various checks on the downloaded files, such as, for example, checks on the conformity of the files with the data. descriptions of content previously received in pre-download step 1002, and / or known parity checks on frames received to convey the downloaded files.
  • a transition 1009 is validated in the event of loss by the vehicle 4 of a satisfactory condition for performing a download.
  • the loss of satisfactory condition may here again result from a loss of connectivity to the telecommunications network, from stopping the internal combustion engine when the vehicle 4 is with thermal propulsion or non-rechargeable hybrid propulsion, or from a disconnection of the internal combustion engine. battery charging station when the vehicle 4 is electrically propelled.
  • Transition 1009 can also be validated in the event of negative control on a downloaded file.
  • Validation of the transition 1009 causes the process to pass into a step 1010 which consists in placing the onboard computer on standby for satisfactory conditions in order to continue carrying out the download.
  • step 1010 the computer 10 keeps a pointer to the last correctly downloaded file.
  • a transition 1011 is validated when all the conditions satisfying the download are found, for example: reconnection to a telecommunications network, restarting of the internal combustion engine for a thermal vehicle, reconnection to a charging station battery for an electric vehicle, as in step 1005.
  • Validating the transition 1011 returns the process to step 1008, which consists of informing the server 101 of its availability and continuing to store the files sent by the server 101.
  • the client on-board computer 10 sends the server 101 a reference to the last correctly downloaded file, whether this is following an interruption in satisfactory conditions of the vehicle or following a negative check on a file being downloaded.
  • the server 101 simply remains on standby in step 10104 in the manner usually provided for in the protocols of the FTP type in order to resume the transmission where it was interrupted as soon as the on-board computer 10, to send the file to be downloaded following the last correctly downloaded file.
  • a transition 1013 is validated when the finished download is signaled to the client on-board computer 10 by the remote server 101, the downloaded files therefore include all the new digital content of the update, this content is therefore full.
  • a validation of the transition 1013 passes the method to a step 1014 which consists in sending to the server 101 an acknowledgment of good reception preferably accompanied by a download report carried out. After sending the acknowledgment of receipt, accompanied, depending on the case of implementation, by the download report carried out, the computer 10 returns to the standby step of the method, that is to say waiting for the next transition of the process. process.
  • the steps executed by the customer on-board computer 10 from the transition 1001 to the transition 1013 can be interrupted many times by the transitions 1003 and / or 1009, without interfering with the operation of the vehicle 4.
  • the two phases pre-downloading and downloading are limited to storage in the vehicle, for example here in the on-board computer 10, of the content useful for updating the digital system. It is irrelevant whether the progress of steps 1002 to 1014 lasts a few minutes or several days, because steps 1002 to 1014 are executed in masked time with respect to the operation of the vehicle.
  • the two phases of the method which have just been explained above are thus implemented in mode connected to the outside world without endangering the state of charge of the electric battery (s) of the vehicle, recharged by the combustion engine. internal rotating for a thermal or hybrid vehicle, or recharged by the recharging station to which the electric or rechargeable hybrid vehicle is connected.
  • a transition 10105 is validated when the server 101 receives the acknowledgment of receipt, accompanied, depending on the case of implementation, by the download report performed.
  • a validation of the transition 10105 passes the method into a step 10106 which consists in recording the acknowledgment of good receipt, accompanied, depending on the case of implementation, by the download report carried out, in a database for logging download states. for a set of vehicles managed by the server 101 in terms of updates to digital systems in said vehicles.
  • the server 101 then returns to the standby step for the steps of the method described above, in a manner known also in addition for the servers usually capable of processing several methods in parallel.
  • At least one of said steps of the digital system update method may include a sub-step of interaction between the man-machine interface apparatus 12 and the user via the man-interface apparatus. machine 12 according to a specific mode of interaction, in particular as a function of said step in progress.
  • the pre-downloaded descriptive data can include metadata (of type xml by example) of configuration of the human-machine interface device 12.
  • These configuration metadata are transmitted by the customer on-board computer 10 to the human-machine interface device 12 by internal direct link (shown, but not referenced) and stored in a dynamic configuration management module, also called proxy HMI, at the end of step 1008.
  • the man-machine interface device 12 is hosted by the client on-board computer 10.
  • the configuration metadata characterize the digital content for updating an on-board computer because they define the mode of interaction between the man-machine interface device 12 and the user during the distribution, installation and activation of the associated digital content. Indeed, for each step of the update and depending on the digital content, a policy of diversified management of the update campaigns can thus be defined upstream in an unloaded manner and thus propose modes of interaction between the device. man-machine interface 12 and the user via the man-machine interface device 12 which are different depending on the update concerned and the step being updated of the digital system. Indeed, the customer on-board computer 10 intervening throughout the content distribution, installation and activation process, it is aware of the update step in progress.
  • the different modes of interaction with the user in particular by means of a screen of the man-machine interface device 12, take, for example, the form of an agreement which can be requested from the user by means of a virtual button displayed on the HMI on which the user must press, or of information to the user in the form of text, or still be invisible to the user, for example if it is a critical campaign.
  • the configuration metadata characterizing the digital content for updating an on-board computer can also define the vehicle conditions required to trigger the interaction between the man-machine interface device 12 and the user.
  • the condition will require, for example, that the engine is off and the mode of interaction by request for consent will therefore not be offered to the user.
  • the activation phase than at the end of the mission, that is to say at the end of the trip, once the engine has been switched off.
  • FIG. 3 shows method steps in accordance with the invention for performing a distribution and installation of digital content inside the digital system (on board in English) from the customer on-board computer 10.
  • the steps now described are executed disconnected from the outside world (off board in English). More precisely, the distribution and installation phase illustrated by FIG. 3 are carried out with a view to updating a first type of on-board computer 20 corresponding to one of the on-board computers 11, 21, 22 directly connected to the on-board bus 5 to which the client on-board computer 10 is connected.
  • the latter 11, 21, 22 are each equipped with sufficient computer resources to process the downloaded content intended for it.
  • a transition 1015 is validated when the existence of a complete digital content to update an on-board computer is signaled in memory of the customer on-board computer 10 by internal notification and that the vehicle 4 is in satisfactory condition for distributing and installing digital content within the digital system.
  • This complete digital content takes in particular the form of a list of the digital content downloaded, knowing that the sequence of the contents in the list does not necessarily have an order linked to the types of computers, for example two consecutive contents can be intended for computers of different types (like the sequence following first type then second type then first type then second type then third type then second type, for example).
  • the two phases of the process relating to the distribution and installation of the contents in one or more on-board computers, not requiring a connection to the outside, the vehicle 4 is in satisfactory conditions when the vehicle 4 is able to supply power.
  • the computers of the digital system concerned with the distribution and installation of content that is to say for example to maintain a sufficient level of charge of the batteries, internal combustion engine running for a thermal vehicle, batteries connected to a station charge for an electric vehicle.
  • Validation of the transition 1015 causes the process to go to a step 1016 in which the customer on-board computer 10 distributes a first digital content downloaded in internal buffer memory to the internal buffer memory of the on-board computer 20.
  • the customer on-board computer 10 begins by defining the on-board computer recipient of the digital content by reading the descriptive data of the content which characterizes said content, then sends a distribution request to the recipient on-board computer then begins to distribute the digital content to this computer.
  • the target computer to be updated by this digital content is of the first type 20, namely one of the computers 11, 21, 22 connected to the customer computer 10 directly via the on-board bus 5 and therefore the computer recipient of the digital content is identified as being the target computer in question 11, 21, 22.
  • a transition 2001 is validated when it receives the distribution request sent by the client on-board computer 10 at step 1016 of distribution
  • the client on-board computer 10 can use the CAN or FTP protocols to distribute the digital content, in this case this content is secure here (encapsulation (s)) since this computer is not in a secure zone and comprises descriptive security data downloaded to the destination computer 20, in this case via the onboard bus 5, independently of the level of connectivity to a telecommunications network since these steps are executed disconnected from the outside world.
  • a validation of the 2001 transition causes the method to pass into a step 2002 which consists in storing the digital content in the destination computer 20.
  • the step 2002 for storing the digital content is executed in the recipient computer 20, it is a matter of de-encapsulating the secure content and then verifying that the content is well intended for said computer 20 (otherwise, as in any case of failure during a step, there is rejection and memory erasure, as explained for the activation phase in the remainder of the text, in this case the buffer memory ) then to store in the internal buffer memory of the destination computer 20 the files or frames received from the client computer 10 via the on-board bus 5.
  • a transition 1017 is validated when the finished distribution of the digital content is signaled to the client computer 10 by the recipient on-board computer 20, in this case via the bus 5. Indeed, even if the client computer 10 knows when it has finished distributing, the signal from the destination computer 20 confirms to it that everything has been received.
  • a validation of the transition 1017 passes the method to a step 1018 which consists in sending an installation request to the recipient computer 20.
  • the client on-board computer 10 sends an installation request to the recipient computer 20 via the on-board bus 5.
  • a 2003 transition is validated when the recipient computer 20 receives the installation request sent by the client on-board computer 10 in step 1018.
  • a validation of the 2003 transition causes the process to pass into a step 2004 which consists for the recipient computer 20 in directly installing for itself the digital content previously stored in its internal buffer memory, then in particular in notifying the client computer 10 of the completion. of the installation.
  • installing is meant to prepare for future activation, that is to say in this case if the recipient computer 20 is dual bank, the content is copied therein. digital new in the inactive bank, and if the ECU only has a buffer memory, nothing more needs to be done.
  • a transition 1019 is validated when the completed installation is signaled to the client computer 10 by the recipient on-board computer 20 via the bus 5, in particular by means of the reception of the installation completion notification sent by the destination computer 20.
  • the installation of the digital content in the destination computer 20 is therefore completed.
  • the validation of the transition 1019 passes the method to a step 1020 which consists of verifying whether or not there is other digital content to be installed in the digital system.
  • transition 1021 If there is another digital content to be installed in the digital system, that is to say on an on-board computer 11, 21, 22, the transition 1021 is validated when another digital content to be installed is detected in the list downloaded digital content. Validating transition 1021 returns the process to step 1016.
  • the transition 1023 is validated. and passes the method to a step 1024 which consists in going to the phase of verifying the conditions for activating the digital content of the current update campaign sending a notification of the end of installation to the configuration management module dynamic HMI-proxy.
  • This request to the HMI-proxy will determine the activation conditions required according to the digital content and / or the computers, that is to say for example the need or not for user agreement, dynamic conditions predefined upstream, in particular to the creation of the campaign.
  • the computer 10 After this phase of distribution and installation for a first type of computer, the computer 10 returns to the process standby step, this may be a wait for the end of the mission or for example a wait for the end of mission combined with a user agreement in particular, but it will not be possible to return to the distribution phase as long as the process has not been completed, that is to say as long as the update campaign has not been completed.
  • FIG. 4 shows the process steps according to the invention for carrying out a distribution and an installation of digital content inside the digital system (on board in English) from the customer on-board computer 10.
  • the steps now described are also performed disconnected from the outside world (off board in English) More precisely, the phase distribution and installation illustrated in FIG. 4 are carried out with a view to updating a second type of on-board computer 30 corresponding to a computer indirectly connected to the customer on-board computer 10 through the gateway computer 21 and equipped with sufficient computer resources to process the downloaded content intended for it, in this case one of the onboard computers 31, 32, 33 connected to the second onboard bus 6.
  • step 1015 is validated when the existence of a complete digital content to update an on-board computer is signaled in memory of the customer on-board computer 10 and that the vehicle 4 is in satisfactory condition for carrying out a distribution and an installation of digital content within the digital system.
  • this complete digital content notably takes the form of a list of downloaded digital content, knowing that the sequence of content in the list does not necessarily have to be linked to the types of calculators. Since the two phases of the method relating to the distribution and installation of digital content in one or more on-board computers, not requiring any connection to the outside, the vehicle 4 is in satisfactory condition when the vehicle 4 is able to operate. supply the computers of the digital system concerned with the distribution and installation of content, that is to say for example to maintain a sufficient level of charge of the batteries, internal combustion engine running for a thermal vehicle, batteries connected to a charging station for an electric vehicle.
  • a validation of the transition 1015 passes the method to a step 1016 in which the customer on-board computer 10 distributes a first digital content downloaded in internal buffer memory to the on-board computer 21.
  • the customer on-board computer 10 begins by defining the on-board computer recipient of the digital content by reading descriptive data of the content, then sends a distribution request to the recipient on-board computer 21 then begins to distribute the digital content to it.
  • the target computer to be updated by this digital content is of the second type 30, namely one of the computers 31, 32, 33 on the on-board bus 6 and connected to the customer computer 10 via the gateway computer 21 and in fact the recipient computer of the digital content is identified as being the gateway computer 21.
  • a transition 2101 is validated when it 21 receives the distribution request sent by the customer on-board computer 10 at the distribution step 1016
  • the customer on-board computer 10 can for example use the CAN, FTP, Ethernet protocols, for distributing the digital content to the gateway computer 21, in this case via the onboard bus 5, independently of the level of connectivity to a telecommunications network since these steps are performed disconnected from the outside world.
  • a validation of the transition 2101 passes the method to a step 2102 which consists in storing the digital content in the gateway computer 21.
  • the step 2102 for storing the digital content is executed in the gateway computer 21, it is a matter of storing in the internal buffer memory of the gateway computer 21 the files or frames received from the client computer 10 via the on-board bus 5.
  • a transition 1017 is validated when the completion of the distribution of the digital content to the gateway computer 21 is signaled to the client computer 10 by the gateway computer 21, in this case via bus 5.
  • a validation of the transition 1017 passes the method to a step 1018 which consists in sending an installation request to the target computer 30.
  • the client on-board computer 10 sends an installation request to the destination gateway computer 21, in this case via the on-board bus 5.
  • this digital content appears as content intended for the gateway computer 21, the customer computer 10 is therefore not in direct connection with the target computer, but with the gateway computer 21 and the latter will activate the computers 30 as explained below.
  • a transition 2103 is validated when the gateway computer 21 has received the installation request sent in step 1018.
  • the validation of the transition 2103 therefore passes the method to a step 2104 in which the on-board gateway computer 21 defines the target computer 30 of the content (as a function of the descriptive data of the secure content) and 30 distributes the digital content that it 21 had stored in internal buffer memory
  • the gateway destination on-board computer 21 begins by sending a distribution request to the target computer 30 defined, in this case via the on-board bus 6, then begins to distribute the digital content to this target computer 30.
  • the target computer to be updated by this digital content is of the first type 30, namely one of the computers 31, 32, 33 connected to the gateway computer 21, in particular via the on-board bus 6.
  • a transition 3001 is validated when the gateway computer 30 receives the distribution request sent by the gateway computer 21 in the distribution step 2104.
  • the gateway on-board computer 21 can use the CAN, FTP, Ethernet protocols to distribute the digital content to the target computer 30 via the on-board bus 6, independently of the level of connectivity to a telecommunications network since these steps are executed disconnected from the outside world.
  • a validation of the transition 3001 passes the method to a step 3002 which consists in storing the digital content in the target computer 30.
  • the step 3002 of storing the digital content is executed in the target computer 30, it is a matter of storing in inactive internal memory in the event of a target computer 30 double bank and otherwise in the external memory of the target computer 30 the files or frames received from the gateway computer 21, in this case via the on-board bus 6.
  • the storage in external memory does not occupy all of the external memory , but only part of the external memory, which makes it possible to have both in the external memory of the destination computer the current digital content, that is to say of a past version (but still active at this step of the process), this one not being erased, and this new digital content of the update.
  • This storage in external memory of the past content will allow later in the process, during the activation phase, a backup for possible rollback if necessary.
  • a transition 2105 is validated when the distribution of the digital content completed is signaled to the gateway computer 21 by the target on-board computer 30, in this case via the bus 6.
  • a validation of the transition 2105 causes the process to pass into a step 2106 which, for the gateway computer 21, consists in sending a request to install the target computer to the target computer 30.
  • the on-board gateway computer 21 sends a request d installation of the target computer to the target computer 30 in this case via the on-board bus 6.
  • a transition 3003 is validated when the target computer 30 receives the target computer installation request sent by the gateway computer 21 in step 2106.
  • a validation of the transition 3003 causes the process to pass into an installation step 3004 which consists for the target computer 30 in constituting a backup of the current content by copying, that is, depending on the nature of the memory of the computer 30, the missing elements, namely those of the current content that do not change with the update, in the inactive bank in the case of a double-bank internal memory, or, in the case of external memory, by copying the entire digital content current in the external memory of the target computer 30, then in particular to notify the gateway computer 21 of the completion of the installation.
  • the term “install” is understood to mean preparing for future activation, and in particular for a second type computer 30 with external memory, it is a matter of saving the current content therein to allow possible rollback.
  • a simple switching is sufficient and avoids having to save using a third-party copy.
  • the target computer 30 is a double bank, the elements of the current content of the computer 30 present in the active bank which have not been updated and therefore did not appear in the inactive bank are copied into the inactive bank. the new digital contents, and if the target computer 30 has only external memory, all the elements of the current content of the computer 30 (present in the current active memory) are copied therein.
  • a transition 2107 is validated when the completed installation is signaled to the gateway computer 21 by the target on-board computer 30, in this case via the bus 6, in particular by receiving the installation completion notification from the target computer 30.
  • the installation of the digital content in the target computer 30 is therefore completed without error.
  • a validation of the transition 2107 passes the method into a step 2108 which consists in sending, as a function of the installation completion notification, to the customer computer 10 the status (correct or incorrect) of the installation of the target computer. 30. After sending the status, the gateway computer 21 returns to the process standby step.
  • a transition 1019 is validated upon receipt of the correct installation status issued by the gateway computer 21.
  • the validation of the transition 1019 passes the method to a step 1020 which consists of verifying whether or not there is other digital content to be installed in the digital system.
  • the transition 1021 is validated when another digital content to be installed is detected in the list of downloaded digital content.
  • the validation of the transition 1021 causes the process to loop back to step 1016.
  • the transition 1023 is validated. and passes the method to a step 1024 which consists of moving to the phase of verifying the conditions for activating the digital content of the current update campaign by sending a notification of the end of installation to the module for managing the digital content.
  • dynamic HMI-proxy configurations As previously described in Figure 3, this request to the HMI-proxy will determine the activation conditions required according to the digital content and / or the computers, that is to say for example the need or not for user agreement.
  • computer 10 After this distribution and installation phase for a second type of computer, computer 10 returns to the process standby step, so it is a matter of waiting for the activation conditions, but it will not be possible to return to phase distribution as long as the process is not completed, that is to say as long as the update campaign is not completed.
  • FIG. 5 schematically illustrates the method according to the invention for carrying out a distribution and an installation of digital content inside the digital system (on board in English) from the customer on-board computer 10.
  • the steps now described are performed disconnected from the outside world (off board in English).
  • the distribution and installation phase that is the subject of FIG. 5 is carried out with a view to updating a third type of on-board computer 23 of hybrid type corresponding to on-board computer 23, which in this case is a display.
  • This third type of computer is called hybrid because it comprises two processors and each processor is considered to be a computer of a different type, as shown in the figure.
  • a first processor is a computer of the first type and is connected to the customer on-board computer 10 in this case via the secure link 7 (the on-board bus 5 connecting the hybrid computer 23 to the customer computer 10 is not used here, but could represent a variant) of which the port on the first processor side is secure
  • the second processor is a computer of the second type and is connected to the gateway onboard computer 21 via the bus 8.
  • the direct link 7 is not always open, that is to say that advantageously the secure communication port located on the first processor is by default closed, preventing any data communication by this link.
  • this hybrid computer 23 could include other parts. This hybrid computer 23 is equipped with sufficient computer resources to process the downloaded content intended for it.
  • the content distribution and installation phase in a hybrid computer 23 implements the related steps as described above for a computer of the first type, in FIG. 3, and a second computer, in FIG. 4, the update therefore comprises two distinct downloaded digital contents each characterized by its distinct descriptive data.
  • the first content secure, will designate a recipient computer 23, as if it were of the first type, and the second content a gateway recipient computer for an update of the target computer 23, as if it were of the second type.
  • the solid arrow between the customer computer 10 and the gateway computer 21 represents the exchanges between these two computers during the distribution and installation phase of the second content for which the gateway computer 21 is recipient while the hybrid computer 23 is the target.
  • the solid line arrow between the gateway computer 21 and the hybrid computer 23 represents the exchanges between these two computers during the distribution and installation phase of the second content for which the gateway computer 21 is the recipient while the computer hybrid 23 is target.
  • This computer being of the third type, at the end of the installation of this second content, an intermediate step is carried out in which the second processor sends a request to open the secure port to the first processor, internally of the hybrid computer. 23 This sending of an opening request is illustrated by the dotted line arrow between the gateway computer 21 and the hybrid computer 23. Once the port is open, the rest of the steps in the distribution and installation phase of the first content can then proceed as previously described in Figure 3, in this case via link 7.
  • the solid arrow between the customer computer 10 and the first processor of the hybrid computer 23 represents the phase of distribution and installation of the first content in the first part of the external memory of the hybrid computer 23 as the destination and target computer.
  • the process steps in question are therefore similar to those implemented for a first type computer as described in Figure 3
  • each target computer is up to date, which therefore means for a computer of the first type that it includes the new content. digital in its internal inactive bank or in its buffer memory and for a computer of the second type that it includes the new digital content in its external memory or in its internal inactive bank, and therefore both at the same time in the case of a calculator of the third type.
  • FIG. 6 shows the process steps according to the invention for activating a target on-board computer of the first type after installation. The steps now described are also executed disconnected from the outside world (off board in English). More precisely, the activation phase illustrated by FIG. 6 is carried out with a view to updating a first type of on-board computer 20 corresponding to one of the on-board computers 11, 21, 22 directly connected to the on-board bus 5 on which the client on-board computer 10 is connected, and each equipped with sufficient computer resources to process the downloaded content intended for it.
  • step 1024 for sending a notification of the end of installation of the digital content of the update campaign for the method executed in the on-board computer 10 a transition 1025 is validated when the vehicle 4 is in the conditions. activation required by the update campaign. These conditions are determined by the HMI-proxy dynamic configuration management module, on the basis of the descriptive data (metadata) sent to the HMI-proxy dynamic configuration management module.
  • each computer has its own activation conditions, some of which are common (end of mission) and some more precise (user agreement: foreground), in particular in the case of computers of the second type 30
  • a satisfactory condition for carrying out the activation of the update of the computer of the first type 20 can be generated by the fact for the vehicle 4 of being at the end of the mission, that is to say that the engine has just been stopped.
  • a validation of the transition 1025 causes the process to pass into a step 1026 which consists in triggering the activation of the target on-board computer (and destination at the same time, since this computer is of the first type) 20.
  • the customer on-board computer 10 begins by defining the target on-board computer 20 by reading the digital content characterized by its descriptive data which contains this indication, then issuing an activation request to the target on-board computer 20.
  • the target computer to be updated by this digital content is of the first type 20, namely one of the computers 11, 21, 22 connected to the customer computer 10 directly via the on-board bus 5 and in fact the target computer of the digital content, therefore to be activated, is identified as being the target computer in question 11, 21, 22.
  • a 2011 transition is validated when the target on-board computer 20 receives the activation request sent by the on-board computer client 10 in activation trigger step 1026.
  • the client on-board computer 10 can use the CAN, FTP, Ethernet protocols to send the activation request to the destination computer 20 via the on-board bus 5, independently of the level of connectivity to a telecommunications network since these steps are executed. disconnected from the outside world.
  • Validation of the 2011 transition takes the process to a step 2012 which consists in activating the digital content installed in step 3004 in the recipient computer 20, then in particular in notifying the client computer 10 of the completion of the activation, knowing that this notification can be a success notification or an activation failure notification.
  • activate it is understood, for a computer of the first type, to pass from the current content to the new content by switching in the event of a double bank and otherwise by updating the internal current memory in the event of an internal buffer memory. In this case, this notification is routed by means of bus 5.
  • a transition 1027 is validated when the report of successful activation of the digital content, sent by the target on-board computer 20 in step 2012, is received. by the customer calculator 10.
  • a validation of the transition 1027 passes the method into a step 1028 which consists of generating an internal activation report relating to the activated digital content in question and verifying whether or not there is other digital content to be installed in the digital system
  • a transition 1029 is validated if there is other digital content to be installed in the digital system, that is to say on an on-board computer 11, 21, 22 , 30, 31, 32, 33 whatever it is.
  • the transition 1029 is therefore validated when such other digital content to be installed is detected in the list of downloaded digital content.
  • Validating transition 1029 returns the process to step 1026.
  • the transition 1030 is validated. and passes the method to a step 1031 which consists for the client computer 10 in sending an end of campaign notification of the current update to the target computer 20. It is therefore after the successful activation of all the computers. targets 20, 30, 23 of the list, that this end of campaign notification is sent to each of the target computers 20, 30, 23. Each of the computers (except the last) therefore waited on standby to receive this notification which confirms successful completion of all update campaign activations. In fact, this notification cannot be sent before if one of the computers does not succeed in activating it, as will be explained later.
  • a 2013 transition is validated when the target computer 20 receives the end of campaign notification sent by the customer computer 10 in step 1031.
  • a validation of the 2013 transition causes the process to pass into a step 2014 which consists in erasing the past digital content, now inactive at this stage of the process, and once this erasure has been completed, to notify the client computer 10 of the “ready for a new” status. update 'of the target computer 20
  • a transition 1032 is validated when the client computer 10 has received all the “ready” status notifications sent by each target computer 20 or more. recipient 30 at step 2014 or 2114.
  • a validation of the transition 1032 passes the method into a step 1033 which consists in generating an overall campaign success report, the generated report being updated by successive aggregations at each “ready” status of target computer 20 or recipient 21. Once all the notifications from each computer 20, 30, 23 in the list have been sent, the global report generated at this step 2014 will be complete, this report then being sent to the remote server 101 or 102 (not shown in FIG. 6 ).
  • a transition 1034 is validated when the digital content activation failure notification, sent by the target on-board computer 20 in step 2012, is received by the client computer 10.
  • a validation of the transition 1034 passes the method into a step 1035 which consists in triggering a general rollback of all the computers of the digital system which is the subject of the update campaign.
  • general rollback is meant return to the initial state before the start of the campaign.
  • the customer on-board computer 10 begins with defining all the recipient on-board computers forming the subject of the update campaign, then issuing a rollback request to each of these defined recipient on-board computers 20, 21, 23.
  • the target computer defined and therefore having to perform the rollback is of the first type 20, namely one of the computers 11, 21, 22 connected to the customer computer 10 directly via the on-board bus 5.
  • the 2015 transition is validated when the target on-board computer 20 receives the backtrack request sent by the client on-board computer 10 at step 1035.
  • this notification is sent by means of the bus 5. It should be remembered that at this stage of the method the past digital content is still present in the external memory of the target computer 20 (which is now inactive if the activation of the new, replacement content was successful, and still active. otherwise), this one not being erased, and the new digital content of the update, now activated if its activation was successful.
  • a validation of the 2015 transition takes the process to a 2016 step which consists of going back, that is to say reactivating the past digital content, therefore rendering the new digital content inactive if it does not. was not already, and once this rollback has been completed, notify the customer computer 10.
  • a transition 1036 is validated when the customer computer 10 receives the notification of completion of rollback sent by the target computer 20 in step 2016.
  • a validation of the transition 1036 passes the method into a step 1037 which consists in generating a campaign failure report then, once this report is complete, to be notified to the target computer 20 of the end of the campaign, the generated report being updated by successive aggregations to each target computer 20 having performed its rollback.
  • the transition 2017 is then validated when the target on-board computer 20 receives the end of campaign notification sent by the client on-board computer 10 in step 1037. In this case, this notification is sent to the means of the bus 5. It should be remembered that at this stage of the method, the past digital content reactivated and the new digital content inactive are still present in the external memory of the target computer 20.
  • a validation of the 2017 transition takes the process to a 2018 step which consists of erasing the new digital content of the update, now inactive at this stage of the process, to therefore keep only the past content reactivated, and once this erasure completed to notify the client computer 10 of the “ready for a next campaign” status of the target computer 20.
  • a transition 1038 is validated when the client computer 10 receives the "ready for a next campaign" status notification sent by the target computer 20 in step 2018.
  • a validation of the transition 1038 passes the method into a step 1039 which consists in generating an overall campaign failure report, this report once complete, then being transmitted to the remote server 101 or 102 (not shown in FIG. 6) .
  • the overall campaign failure report generated in step 1039 is updated by successive aggregations of the notifications received from each computer defined in step 1035. Once all the notifications from each computer 20, 21 (for the gateway 21 several notifications are possible since the update could include contents intended for the gateway as such (for itself as a gateway) and contents having a target 30 or 23), 23 defined in step 1035 have been sent, the global report generated at this step 1039 will then be complete.
  • the customer computer 10 After this activation phase, whether successful or not, for a first type of computer, the customer computer 10 returns to the process standby step, the same for the target computer 20, then will turn off.
  • FIG. 7 shows process steps according to the invention for activating a target on-board computer of the second type after installation. The steps now described are also executed disconnected from the outside world (off board in English). More precisely, the activation phase illustrated by FIG. 7 is carried out with a view to updating a second type of on-board computer 30 corresponding to one of the on-board computers 31, 32, 33 connected to the on-board gateway computer 21, at l 'species via bus 6, and each equipped with sufficient computer resources to process the downloaded content intended for it.
  • the dynamic configuration management module also called proxy HMI
  • a satisfactory condition for activating the update of the computer of the second type 30 can, as previously described in FIG. 6, be generated by the fact for the vehicle 4 of being at the end of the mission and once at the end of the mission to have requested and then obtained the user's agreement by means of a virtual button displayed on I ⁇ HM 12.
  • this user request is preferred for this second type of computer 30 because their update is less instantaneous and requires blocking the restart of the engine, which requires alerting the user. Thus, once the user agreement has been obtained, restarting the engine is prohibited.
  • a validation of the transition 1025 passes the method into a step 1026 which consists in triggering the activation of the on-board computer receiving the content, namely the gateway computer 21 since the target here is a computer of the second type 30, that is to say - say located in a secure area behind the gangway.
  • the client on-board computer 10 begins by defining the destination on-board computer 21 by reading the downloaded digital content characterized by its descriptive data which contains this indication, then sending an activation request to the recipient on-board computer, here gateway 21.
  • the target computer to be updated by this digital content is of the second type 30, located behind the gateway, the identified recipient of the digital content is therefore the gateway, the client computer 10 ignoring that the target is a computer of the second type, namely one of the computers 31, 32, 33 and in fact the recipient computer to which to send the activation request is identified as being the gateway computer 21.
  • a transition 2111 is validated when the gateway computer 21 receives the activation request sent by the client on-board computer 10 in step 1026 of activation trigger.
  • the client on-board computer 10 can use the CAN, FTP, Ethernet protocols to send this request to the destination computer 21 via the on-board bus 5, independently of the level of connectivity to a telecommunications network since these steps are executed disconnected from the world. outside.
  • a validation of the transition 2111 passes the method to a step 2112 which essentially consists in triggering the activation of the target on-board computer 30.
  • the gateway on-board computer 21 begins by defining the target on-board computer 30, in the species by reading the download list which for example takes the form of a table with the update status for each computer row, then by issuing an activation request to the target on-board computer 30.
  • the target computer to be updated that is to say whose digital content must be activated, is of the second type 30, namely one of the computers 31, 32, 33 indirectly connected to the customer computer 10 via the gateway computer 21.
  • a transition 3011 is validated when the gateway computer 30 receives the activation request sent by the gateway computer 21 at step 2112.
  • a validation of the transition 3011 passes the method to a step 3012 which consists in activating the digital content installed in step 3004 in the target computer 30, then in particular in notifying the gateway computer 21 of the completion of the activation, knowing that this notification can be a success notification or an activation failure notification.
  • Activation consists in the case of dual bank internal memory to be switched from the active (current) bank to the other (containing the new digital content) bank and in the case of an external memory to transfer the new digital content from external memory to internal memory.
  • a transition 1027 is validated when a notification of successful activation, notified by the gateway computer 21 at step 2112, is received by the customer calculator 10.
  • a validation of the transition 1027 passes the method into a step 1028 which consists in generating an internal activation report, which will be completed on each receipt of a notification relating to a new activated digital content, and in verifying whether or not it exists. other digital content to be installed in the digital system.
  • a transition 1029 is validated if there is other digital content to be installed in the digital system, that is to say on any on-board computer whatsoever. .
  • the transition 1029 is therefore validated when other digital content to be installed is detected in the list of downloaded digital content.
  • Validating transition 1029 returns the process to step 1026.
  • the transition 1030 is validated. and passes the method to a step 1031 which consists for the client computer 10 in sending an end of campaign notification of the current update to the gateway recipient computer 21. It is therefore after the successful activation of all the computers. targets 20, 30, 23 of the list, that this end of campaign notification is sent to each of the recipient computers 20, 21, 23. Each of the computers (in this case except the last) therefore waited on standby to receive this notification which confirms the success of all activations of the update campaign. In fact, this end-of-campaign notification cannot be sent before if one of the computers fails to activate it, as will be explained below.
  • a transition 2113 is validated when the end of campaign notification, sent by the client on-board computer 10 in step 1031, is received by the computer gateway 21.
  • a validation of the transition 2113 passes the method to a step 2114 which consists in sending an end of campaign notification to the target computer 30.
  • a transition 3013 is validated when the target computer 30 receives the end of campaign notification sent by the gateway computer 21 at step 2114.
  • a validation of the transition 3013 passes the method to a step 3014 which consists in erasing (whether in the bank of the internal inactive memory or in the external memory) the past digital content, now inactive at this step of the method, and a once this erasure has been completed, notify the gateway computer 21 of the “ready for a next campaign” status of the target computer 30.
  • Receipt of this notification of the “ready for a next campaign” status by the gateway computer 21 finalizes step 2114 with a return by the gateway computer 21 to the client computer 10 of the “ready for a next campaign” status, the gateway computer playing. here a role of mailbox. It should be remembered that in internal EEPROM memory, a non-emptied bank cannot be rewritable, hence the importance of erasing for a next update campaign.
  • a transition 1032 is validated when the client computer 10 receives the last notification of the status “ready for a next campaign” sent by the last one. calculator from the list in step 2114 or 2014.
  • a validation of the transition 1032 passes the method into a step 1033 which consists in generating an overall campaign success report, the generated report being updated by successive aggregations at each “ready” status of target computer 20 or recipient 21. Once all the notifications from each computer 20, 30, 23 in the list have been sent, the global report generated at this step 2014 will be complete, this report then being sent to the remote server 101 or 102 (not shown in FIG. 7 ).
  • step 2112 ends with a notification of failure of the activation by the gateway computer 21 to be sent back to the customer computer 10. and from step 1026 for triggering activation executed by the client computer 10, a transition 1034 is validated as soon as the notification of activation failure is received by the client computer 10
  • a validation of the transition 1034 passes the method into a step 1035 which consists in triggering a general rollback of all the computers of the digital system which is the subject of the update campaign.
  • general rollback is meant return to the initial state before the start of the campaign.
  • the customer on-board computer 10 begins by defining all the recipient on-board computers that are the subject of the update campaign, then in sending a backtracking request to each of these defined destination onboard computers 20, 21, 23.
  • the target computer is of the second type 30 but the client computer 10 only knows that the defined recipient is the gateway computer 21, the return request is therefore sent to the gateway computer 21 From step 2112 for triggering activation executed by the gateway computer 21, a transition 2115 is validated when the return request, sent by the client on-board computer 10 at step 1035, is received by the gateway computer 21 .
  • a validation of the transition 2115 passes the method into a step 2116 which consists first of all in triggering the return back of the target computer 30 by sending a request to go back to the target computer 30 (will therefore be sent sequentially following the method for each target computer 30 defined in step 1035).
  • the transition 3015 is validated when the target computer 30 receives the backtrack request sent by the gateway computer 21 in step 2116. In this case, this request is routed by means of the bus 6
  • a validation of the transition 3015 passes the method to a step 3016 which consists of performing the rollback, therefore rendering inactive the new digital content if it was not already, and once this rollback has been completed at notify the gateway computer 21 by sending a return to the initial state report.
  • This rollback is done by switching, which switches back to the other bank, in the case of dual bank internal memory and by restoring the digital content saved in the case of external memory.
  • the reception of this return to the initial state report by the gateway computer 21 finalizes step 2116 with a return by the gateway computer 21 to the customer computer 10 of the return to the initial state report, the gateway computer 21 playing here a mailbox role.
  • a transition 1036 is validated when the customer computer 10 receives the return to the initial state report sent by the gateway computer 21 in step 2116
  • a validation of the transition 1036 passes the method into a step 1037 which consists in generating a campaign failure report which will be completed by successive aggregations on each reception of a return to the initial state report (originating from each computer defined at step 1035), then once all the notifications from all the target computers defined in step 1035 have been received, the campaign failure report generated at this step 1037 will be complete, and the campaign end notification sent to each of the destination computers defined in step 1035.
  • this report is complete (that is to say once all the computers defined in step 1035 returned to the initial state) the destination gateway computer 21 is notified of the end of the campaign
  • the transition 2117 is then validated when the on-board gateway recipient computer 21 receives the notification of the end of campaign sent by the client on-board computer 10 in step 1037.
  • this notification is sent by means of the bus 5.
  • a validation of the transition 2117 passes the method into a step 2118 which consists first of sending a request to erase the new digital content of the update, now inactive at this step of the method, so as to keep only the past content reactivated (initial before update).
  • the transition 3017 is validated when the target computer 30 receives the backtrack request sent by the gateway computer 21 in step 2118. In this case, this request is routed by means of the bus 6
  • a validation of the transition 3017 passes the method into a step 3018 which consists in erasing the new digital content of the update if it was not already, and once this erasure has been completed, notifying the gateway computer thereof. 21 by sending a status "ready for a next campaign". The reception of this “ready” status by the gateway computer 21 finalizes step 2118 with a sending by the gateway computer 21 to the customer computer 10 of the “ready for a next campaign” status of the target computer 30, the gateway computer 21 acting here. a mailbox role.
  • a transition 1038 is validated when the client computer 10 receives the "ready for a next campaign" status notification sent by the gateway computer 21 in step 2118.
  • a validation of the transition 1038 passes the method into a step 1039 which consists in generating an overall campaign failure report, this report once complete, then being transmitted to the remote server 101 or 102 (not shown in FIG. 7) and releasing the restart ban.
  • the overall campaign failure report generated in step 1039 is updated by successive aggregations of the notifications received from each computer defined in step 1035.
  • step 1035 Once all the notifications from each computer 20, 21 (for the gateway 21, several notifications are possible since the update could include content intended for the gateway as such (for itself as a gateway) and contents having a target 30 or 23), 23 defined in step 1035 will have been sent, the global report generated in this step 1039 will then be complete.
  • the past digital content has been erased in order to be ready for a next campaign and to prevent, for security reasons, any reversion to the previous version.
  • a step of the method when a step of the method does not end as expected, the method remains blocked in this step and a timeout can be provided, for example in the client computer 10 or gateway 21, at the end of which a failure is detected. to then initiate a reset of the entire digital system, as defined above, with notification of the failure to the server.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Power Engineering (AREA)
  • Computing Systems (AREA)
  • Mechanical Engineering (AREA)
  • Transportation (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Sustainable Energy (AREA)
  • Sustainable Development (AREA)
  • Information Transfer Between Computers (AREA)
  • Stored Programmes (AREA)
  • Remote Monitoring And Control Of Power-Distribution Networks (AREA)

Abstract

Dans un véhicule (4) comprenant un système numérique qui comporte un calculateur client (10) embarqué apte à communiquer avec un serveur distant (101, 102), une unité de contrôle-commande embarquée (20, 11, 21, 22, 30, 31, 32, 33, 23) connectée, directement ou indirectement, au calculateur client (10) par un réseau embarqué de communication (5, 6, 7, 8), et comprenant un dispositif d'accumulation d'énergie électrique pour alimenter le calculateur embarqué et ladite unité de contrôle-commande embarquée (20, 11, 21, 22, 30, 31, 32, 33, 23), le procédé de mise à jour du système numérique comprend des étapes de: - téléchargement dans laquelle le calculateur client (10) télécharge un fichier à partir du serveur distant à condition que le dispositif d'accumulation d'énergie électrique est en état de pouvoir être rechargé; - distribution dans laquelle le calculateur client (10) distribue au moins une partie du fichier téléchargé à destination de l'unité de contrôle-commande embarquée (20, 11, 21, 22, 30, 31, 32, 33, 23); - installation dans laquelle toute partie distribuée du fichier téléchargé est installée dans l'unité de contrôle-commande embarquée (20, 11, 21, 22, 30, 31, 32, 33, 23).

Description

DESCRIPTION
TITRE : Procédé de mise à jour de système numérique.
L’invention concerne un procédé de mise à jour de système numérique dans un véhicule, notamment dans un véhicule automobile.
De manière connue en soi, un système numérique dans un véhicule comprend un ou plusieurs calculateurs embarqués communiquant entre eux par un ou plusieurs bus embarqués.
On rappelle qu'un calculateur embarqué comprend généralement une mémoire permanente pour stocker au moins des données numériques permanentes, un micrologiciel et/ou un programme informatique. Le calculateur embarqué comprend généralement aussi une mémoire vive pour mémoriser des données numériques variables, et au moins un processeur pour écrire et/ou lire les données numériques variables en mémoire vive en exécutant le programme informatique à partir de tout ou partie des données numériques permanentes et des données numériques variables. Une mise à jour du système numérique consiste à modifier un contenu numérique de la mémoire permanente d’au moins un calculateur embarqué.
Le document FR2775363 divulgue un calculateur de véhicule adapté pour être raccordé à un outil de mise à jour de données stockées mais il est préférable d’arrêter le véhicule pour raccorder l’outil de mise à jour.
Le document FR3011651 divulgue un procédé de mise à jour d’un calculateur de véhicule utilisant un boîtier d'interface, cependant la mise en oeuvre du procédé nécessite un arrêt du véhicule pour brancher le boîtier.
Le document FR2775371 divulgue un procédé pour télécharger un fichier de mise à jour en mémoire réinscriptible d’un calculateur de véhicule. Aujourd’hui, un large éventail de possibilités de télétransmissions sans fil, offre des opportunités pour télécharger des fichiers de mise à jour dans des unités de contrôle-commande embarqués de véhicule sans avoir à brancher un connecteur physique sur le véhicule. Cependant les procédés et dispositifs connus, nécessitent encore une durée plus ou moins prolongée du véhicule pour mettre à jour un fichier de données ou de programme dans une unité de contrôle-commande embarquée. L’écriture à partir d’un serveur distant dans une mémoire réinscriptible d’unité de contrôle-commande embarquée nécessite plus de temps que dans une mémoire conventionnelle d'ordinateur ou de téléphone mobile. Un arrêt du véhicule reste préconisé pour éviter un changement impromptu de comportement du véhicule en roulage, lié à la mise à jour. Un besoin se fait sentir pour réduire au minimum une durée de mise à jour d’unité de contrôle-commande, notamment pour réduire au minimum une durée d’indisponibilité du véhicule, pour passer d’une configuration antérieure d’unité de contrôle-commande embarquée à une nouvelle configuration par mise à jour de programme ou de données.
Le document EP2249251A1 divulgue un dispositif de mise à jour comprenant un serveur, une unité de contrôle-commande embarquée dans un véhicule, des moyens de communication pour connecter le serveur et l’unité de contrôle-commande embarquée, dans lequel lorsque le serveur exécute un processus de réécriture d’un programme de l’unité de contrôle-commande embarquée via les moyens de communication, le serveur détermine s’il doit exécuter ou non la réécriture du programme en se référant à un contenu mémoire de l’unité de contrôle-commande embarquée. Si une anomalie ou une rupture de communication se produit au cours de la tâche de réécriture, le processus de réécriture n’est pas mené à terme, une remise à zéro est exécutée, le programme antérieur est démarré.
Le dispositif divulgué par le document ci-dessus cité présente de nombreux inconvénients dont notamment celui de différer à une date intolérablement éloignée la mise à jour de l’unité de contrôle-commande embarquée en cas d’anomalies et/ou de ruptures de communications répétées. De tels cas peuvent se produire dans un véhicule, par exemple lorsqu’il est sous un tunnel ou dans un parking sous-terrain, par exemple aussi en cas de baisse de tension sur le réseau électrique embarqué du véhicule à laquelle sont sensibles les télécommunications et l’écriture en mémoire réinscriptible, par ailleurs fortement consommatrice d’électricité. Chaque tentative de réécriture d’un programme nécessaire au fonctionnement du véhicule, rend le véhicule indisponible jusqu’à démarrer le programme réécrit ou le programme antérieur selon que la réécriture s’est exécutée correctement ou non.
Pour remédier aux inconvénients présentés par l’état antérieur de la technique, l’invention a pour objet un procédé de de mise à jour de système numérique dans un véhicule comprenant un calculateur client embarqué, notamment de type multimédia, apte à communiquer avec un serveur distant, une unité de contrôle-commande embarquée connectée, directement ou indirectement, au calculateur client par un réseau embarqué de communication, et un dispositif d’accumulation d’énergie électrique pour alimenter le calculateur embarqué et l’unité de contrôle-commande embarquée
Le procédé est remarquable en ce qu’il comprend :
- une étape de téléchargement dans laquelle le calculateur client télécharge un fichier à partir du serveur distant lorsque le dispositif d’accumulation d’énergie électrique est en état de pouvoir être rechargé ;
- une étape de distribution dans laquelle le calculateur client distribue, directement ou indirectement, au moins une partie du fichier téléchargé à destination de l’unité de contrôle- commande embarquée ;
- une étape d’installation dans laquelle toute ou portion de ladite au moins une partie distribuée du fichier téléchargé est installée dans l’unité de contrôle-commande embarquée ;
- une étape d’activation dans laquelle l’unité de contrôle-commande embarquée active la ou les portions de fichier installées après mise à l’arrêt du véhicule.
Le calculateur est dit client en ce qu’il se distingue de l’unité de contrôle-commande par sa capacité à traiter d’autres média ou support que des contrôle-commandes d'actionneurs et de capteurs du véhicule, comme par exemple à traiter un téléchargement au protocole FTP. En utilisant les ressources de traitement du calculateur client pour télécharger un fichier de mise à jour, on allège les ressources nécessaires à la mise à jour dans l’unité de contrôle-commande, et par là même son coût, effet d’autant plus intéressant qu’un système numérique embarqué comprend généralement de nombreuses unités de contrôle-commande. La durée de téléchargement est totalement transparente pour l’unité de contrôle-commande car cette dernière n’est pas impactée par le téléchargement. Le dispositif d’accumulation d’énergie électrique en état de pouvoir être rechargé pendant le téléchargement assure de ne pas perturber non seulement le téléchargement, mais aussi d’autres consommateurs électriques du véhicule par la consommation électrique du téléchargement. Les étapes de distribution et d’installation effectuées après le téléchargement, décorrélées de l’étape de téléchargement, ne nécessitent pas de connexion au serveur distant pour être exécutées. Un calculateur multimédia est un exemple de calculateur client. L’unité de contrôle-commande embarquée est connectée, directement ou indirectement, au calculateur client, il s’agit donc de tout type d’unité de contrôle commande quelle que soit la manière dont elle est reliée au calculateur client, que ce soit par exemple directement par une liaison de communication, ou encore via un calculateur passerelle et des liaisons de communications, ou encore par les deux manières. De par ses ressources, le calculateur client est mis en interface avec un serveur distant et pilote directement ou indirectement les différentes étapes du procédé selon l’invention, par exemple il distribue indirectement une partie du fichier téléchargé à destination de certaines unités de contrôle-commande embarquées pour lesquelles la distribution est pilotée par le calculateur client puis gérée par le calculateur passerelle. Avantageusement dans l’étape de téléchargement, le calculateur client mémorise constamment un point de progression du téléchargement de manière à arrêter le téléchargement lorsqu’une dégradation effective ou risquée de communication avec le serveur distant est détectée, et reprend le téléchargement à partir du point de progression mémorisé lorsqu’il détecte une disparition de dégradation effective ou risquée de communication avec le serveur distant.
Il est ainsi possible d’interrompre le téléchargement autant de fois que nécessaire en cas de dégradation de communication effective ou risquée puis de le reprendre lorsque de bonnes conditions sont retrouvées, sans nuire aux étapes suivantes qui peuvent ensuite se faire hors connexion.
Les causes de dégradations effectives de communication sont multiples, passage du véhicule dans un tunnel ou dans un parking souterrain, interruption par un autre processus prioritaire sur le téléchargement, panne du serveur distant ou autres
Particulièrement, le dispositif d’accumulation d’énergie électrique hors d’état de pouvoir être rechargé est considéré par le procédé constituer une condition de détection de dégradation risquée de communication avec le serveur distant.
Plus particulièrement, lorsque le véhicule comprend un moteur thermique, le dispositif d’accumulation d’énergie électrique est considéré en état de pouvoir être rechargé si le moteur thermique est en rotation.
Le moteur thermique en rotation, permet par exemple de recharger dispositif d’accumulation d’énergie électrique au moyen d’un alternateur ou d’un alternodémarreur.
Plus particulièrement aussi, lorsque le véhicule comprend une batterie de traction électrique, le dispositif d’accumulation d’énergie électrique est considéré en état de pouvoir être rechargé si la batterie de traction électrique est branchée sur un réseau électrique de rechargement externe. Ce cas peut se produire non seulement pour un véhicule à traction purement électrique, mais aussi pour un véhicule hybride rechargeable sur réseau électrique externe ou au moyen du moteur thermique.
Avantageusement, le réseau embarqué de communication comporte une première liaison embarquée reliée au calculateur client, une deuxième liaison embarquée reliée à l’unité de contrôle-commande embarquée et un calculateur passerelle relié au calculateur client et à l’unité de contrôle-commande embarquée, une exécution de l’étape d’installation de tout ou partie distribuée du fichier téléchargé dans l’unité de contrôle-commande embarquée par le calculateur passerelle, permet de décharger l’unité de contrôle-commande embarquée, des tâches d’installation, gardant ainsi l’unité de contrôle-commande embarquée intégralement disponible pour ses tâches de contrôle commande, pour toute unité de contrôle-commande dont au moins un processeur est relié indirectement au calculateur client via la passerelle.
Avantageusement, en équipant le réseau embarqué de communication avec un premier bus embarqué relié au calculateur client, un deuxième bus embarqué relié à l’unité de contrôle- commande embarquée, et un calculateur passerelle relié aux deux dits bus embarqués, une exécution de l’étape d’installation de tout ou partie distribuée du fichier téléchargé dans l’unité de contrôle-commande embarquée, par le calculateur passerelle permet de décharger l’unité de contrôle-commande embarquée, des tâches d’installation, gardant ainsi l’unité de contrôle- commande embarquée intégralement disponible pour ses tâches de contrôle commande, notamment pour toute unité de contrôle-commande reliée indirectement au calculateur client via la passerelle.
Particulièrement, en équipant l’unité de contrôle-commande embarquée avec deux banques de mémoire réinscriptible exécutable, le procédé consiste à faire fonctionner l’unité de contrôle-commande embarquée sur une première banque de mémoire réinscriptible pendant que l’étape d’installation est appliquée sur une deuxième banque de mémoire réinscriptible.
Ainsi il suffit de faire commuter l’unité de contrôle commande de la première banque de mémoire réinscriptible exécutable sur la deuxième banque pour activer la mise à jour, la première banque jouant alors le rôle de la deuxième banque en vue d’une mise à jour ultérieure
Un arrêt bref du véhicule peut suffire car la disponibilité de l’unité de contrôle commande pendant les étapes de téléchargement, de distribution et d’installation qui précèdent, permet de laisser fonctionner le véhicule jusqu’à l’arrêt, alors exécuté simplement pour éviter à l’utilisateur du véhicule d’être surpris par un changement de comportement en cours de fonctionnement du véhicule.
Avantageusement, le procédé comporte une étape de pré téléchargement de données descriptives, qui permettront de caractériser les contenus numériques des fichiers téléchargés et de configurer dynamiquement l’expérience utilisateur lors de chaque mise à jour.
Particulièrement, le fichier téléchargé obtenu à l’issue de l’étape de téléchargement comporte d’autres données descriptives, qui permettront notamment de sécuriser les contenus numériques des fichiers téléchargés pour les unités de contrôle commande directement reliés au calculateur client.
Avantageusement, au moins une partie des données descriptives pré téléchargées comporte des métadonnées de configuration.
Plus particulièrement le procédé comporte au moins une étape de vérification d’au moins une condition d’activation, ladite au moins une condition d’activation étant fonction d’au moins une partie des données descriptives ce qui permet la configuration dynamique c’est à dire une gestion diversifiée et dynamique des campagnes de mises à jour, qui peut ainsi être définie en amont de manière débarquée.
De manière avantageuse, au moins une desdites étapes du procédé de mise à jour de système numérique comporte une sous-étape d’interaction entre l’appareil d’interface homme- machine et l’utilisateur via l’appareil d’interface homme-machine selon un mode d’interaction spécifique, notamment fonction de ladite étape en cours. Par exemple, le confort de l’utilisateur est encore amélioré lorsque l’étape d’activation nécessite un accord d’un utilisateur du véhicule pour être exécutée.
L’invention a aussi pour objet un système numérique embarqué dans un véhicule comprenant un calculateur client embarqué apte à communiquer avec un serveur distant, une unité de contrôle-commande embarquée connectée au calculateur client par un réseau embarqué de communication, alimentés chacun par un dispositif d’accumulation d’énergie électrique, caractérisé en ce que le calculateur client embarqué et l’unité de contrôle-commande embarquée sont programmés pour exécuter le procédé selon l’invention.
Avantageusement dans le système numérique embarqué, le réseau embarqué de communication comporte un premier bus embarqué relié au calculateur client, un deuxième bus embarqué relié à l’unité de contrôle-commande embarquée, et un calculateur passerelle relié aux deux dits bus embarqués, de sorte que le calculateur passerelle est programmé pour exécuter l’étape d’installation conforme au procédé.
L’invention a aussi pour objet un véhicule automobile comprenant un système numérique embarqué selon l’invention.
D’autres avantages et caractéristiques de l’invention apparaîtront à la lecture de la description détaillée de modes de mise en œuvre et de réalisation, à titre d’exemples illustratifs et non limitatif, en référence aux dessins annexés dans lesquels : [Fig. 1 ] montre schématiquement un véhicule comprenant un système numérique sur lequel est mise en œuvre l’invention ;
[Fig. 2] montre des étapes de séquence de pré téléchargement et de séquence de téléchargement au sein du procédé conforme à l’invention ; [Fig. 3] montre des étapes de distribution et d’installation pour un premier type de calculateur embarqué ;
[Fig. 4] montre des étapes de distribution et d’installation pour un deuxième type de calculateur embarqué;
[Fig. 5] montre le schéma de distribution et d’installation pour un troisième type de calculateur embarqué ;
[Fig. 6] montre des étapes d’activation pour un premier type de calculateur embarqué mis à jour ; [Fig. 7] montre des étapes d’activation pour un deuxième type de calculateur embarqué mis à jour .
Pour plus de clarté, les étapes identiques ou similaires sont repérées par des signes de référence identiques sur l’ensemble des figures.
[Fig. 1 ] montre un véhicule 4 comprenant un système numérique dans lequel est mise en oeuvre l’invention. Le système numérique comprend au moins deux calculateurs embarqués 10,
11 , 21 , 22, 23 agencés pour communiquer entre eux sur un premier bus de communication embarqué 5. Un appareil d’interface homme-machine 12 équipé d’un ou plusieurs écrans, peut comprendre un coupleur de communication sur le bus embarqué 5.
Le calculateur embarqué client 10 calculateur embarqué client 10 comprend un ou plusieurs processeurs et une capacité mémoire dimensionnée pour lui donner des ressources de calcul adaptées au traitement d’information numérique volumineuse, comme celle nécessaire à l’affichage pictographique et à la perception de commandes humaines par le bus embarqué 5 ou par liaison directe sur l’appareil d’interface homme-machine 12, aux échanges avec d’autres calculateurs embarqués du système numérique, à une communication extérieure au véhicule, et à l’exécution de programmes informatiques de niveau opérationnel et/ou applicatif. Le calculateur embarqué client 10 calculateur embarqué client 10 est par exemple souvent désigné par l’acronyme IVI (In-Vehicle Infotainment en anglais pour Info-divertissement Dans le Véhicule). Pour la communication extérieure, on peut équiper le calculateur embarqué client 10 calculateur embarqué client 10 avec une ou plusieurs prises 3 de type USB, OBD ou autre. Une prise 3 de type USB permet par exemple des transferts de fichiers stockés ou à stocker en mémoire d’une clé USB. On peut aussi équiper le calculateur embarqué client 10 avec des moyens de communication par voie aérienne OTA (Over The Air en anglais), pour établir des communications 1 , par exemple à un standard de type 802.11 avec un serveur distant 101 .
En dehors du calculateur client 10, les autres calculateurs sont des unités de contrôle- commande embarquée, qui peuvent être de trois types différents. Le premier type désignant les unités de contrôle-commande directement reliées au calculateur client 10 par le bus 5, ils sont intelligents et dotés de capacités de dé-encapsulation car ils se trouvent dans une zone non sécuritaire car située avant le calculateur passerelle 21 et reçoivent donc des contenus sécurisés par encapsulation(s), leurs mémoires sont préférentiellement de nature interne double banque , c’est-à-dire deux banques de mémoire réinscriptible exécutable (par exemple Flash, EEPROM) ou de nature mémoire tampon interne. Le second type désignant les unités de contrôle -commande indirectement reliées au calculateur client 10 via le calculateur passerelle 21 , ils sont donc en zone sécuritaire et de nature plus basique, leurs mémoires sont préférentiellement de nature interne double banque (deux banques de mémoire réinscriptible exécutable, par exemple Flash, EEPROM) ou de nature mémoire externe. Le troisième type désigne les calculateurs hybrides qui ont deux processeurs, l’un étant donc en liaison avec le calculateur client 10 et l’autre en liaison avec le calculateur passerelle 21 .
Le calculateur embarqué 21 est de type passerelle (GW pour Gâte Way en anglais). Le calculateur embarqué 21 permet d’échanger de l’ information numérique entre le prem ier bus em barqué 5 et un deuxième bus embarqué 6 du système numérique.
Le système numérique comprend un ou plusieurs calculateurs embarqués 31, 32, 33 agencés pour communiquer entre eux et avec le calculateur embarqué 21 , sur le deuxième bus embarqué 6. Le ou les calculateurs embarqués 31, 32, 33 sont de type UCE (acronyme de Unité de Commande Electronique). De manière connue en soi par ailleurs, une unité de commande électronique comprend une ou plusieurs sorties reliées chacune à un actionneur du véhicule, un coupleur de communication sur le bus embarqué 6, et un circuit électronique de traitement numérique pour commander, de manière connue en soi par ailleurs au moyen d’un micrologiciel, le ou les actionneurs en fonction de données numériques circulant sur le bus embarqué de communication 6. Chaque calculateur embarqué 31 , 32, 33 constituant une unité de commande électronique, peut aussi comprendre une ou plusieurs entrées reliées à des capteurs et/ou à des organes de commande du véhicule, pour exécuter le micrologiciel. Le bus embarqué 6 est représenté de manière simplifiée en figure 1 , il peut comprendre plusieurs ramifications reliées les unes aux autres par des passerelles secondaires non représentées et sans impact particulier sur le fonctionnement de l’invention. Selon différentes réalisations possibles, le système numérique du véhicule 4 peut aussi comprendre un calculateur embarqué 11 qui comprend des moyens de communication par voie aérienne à plus longue distance que par exemple celle au standard 802.11 . Les moyens de communication par voie aérienne (OTA) du calculateur embarqué 11 , permettent par exemple de manière connue en soi par ailleurs, d’établir une communication 2 par réseau de téléphonie cellulaire de version 4G ou supérieure avec un serveur distant 102, identique, distinct et ou connecté au serveur distant 101. D’autres type de communication peuvent être envisagés pour le calculateur embarqué 11 , comme par exemple à titre purement illustratif et non exhaustif, un mode de communication satellitaire ou un mode mixte de communication hertzienne descendante et de communication GSM montante. Le calculateur embarqué 11 n’est pas nécessairement distinct du calculateur embarqué 10. En d’autres termes, on peut envisager des versions de système numérique dans lesquelles le calculateur embarqué client 10 calculateur embarqué client
10 intègre les fonctionnalités du calculateur embarqué 11. Lorsqu’il est distinct du calculateur embarqué 10, le calculateur embarqué 11 tel qu’il est illustré sur la figure 1 , est relié au calculateur embarqué client 10 calculateur embarqué client 10 par le bus 5 ou par une liaison directe, pour faire bénéficier le calculateur embarqué client 10 calculateur embarqué client 10 de ses possibilités de communication à longue distance. Le calculateur embarqué 11 est alors par exemple du type souvent désigné par l’acronyme IVC (In-Vehicle Communication en anglais pour Communication Dans le Véhicule).
Selon différentes réalisations possibles, le système numérique du véhicule 4 peut aussi comprendre un calculateur embarqué 22 sans incidence directe sur le fonctionnement du véhicule, et relié pour cette raison au bus embarqué 5.
Selon différentes réalisations possibles, le système numérique du véhicule 4 peut aussi comprendre un calculateur embarqué 23 de type unité de commande électronique à haute capacité de traitement numérique, par exemple pour superviser et/ou gérer plusieurs fonctions du véhicule 4. Le calculateur embarqué 23 est alors relié au bus embarqué 5 pour traiter des données sans incidence directe sur le fonctionnement du véhicule ou des données sur lesquelles
11 peut exercer un contrôle de sécurité. Le calculateur 23 est relié au bus embarqué 5 pour traiter des données avec incidence sur le fonctionnement du véhicule. Le calculateur 23 peut aussi être relié au calculateur 10 par une liaison directe 7 (par exemple via protocole CAN, FTP, Ethernet) et au calculateur passerelle par un bus embarqué de communication 8
Le calculateur embarqué client 10 calculateur embarqué client 10 et au moins l’un des calculateurs embarqués 21 , 22, 23 relié au bus embarqué 5, notamment le calculateur embarqué 21 , hébergent un programme informatique réparti, comprenant des instructions informatiques pour mettre en œuvre le procédé de mise à jour expliqué ci-après, lorsque le programme informatique réparti est exécuté par les calculateurs sur lesquels il est hébergé.
Les étapes du procédé décrites dans les figures suivantes se divisent en trois phases, à savoir la première phase d’échanges entre un serveur distant 101 et le calculateur embarqué client 10 , contenant des étapes de pré téléchargement de données descriptives et de téléchargement des contenus numériques en fonction des données descriptives , illustrée notamment par la figure 2, la deuxième phase d’échanges entre le calculateur embarqué client 10 et un type de calculateur embarqué 20,30, 23, (indirectement via le calculateur passerelle 21 pour les calculateurs de deuxième ou troisième type) contenant des étapes de distribution et d’installation des contenus numériques, illustrée notamment par les figures 3 et 4 et 5 en fonction du type de calculateur, la troisième phase d’échanges entre le calculateur embarqué client 10 et un type de calculateur embarqué 20,30, 23, (indirectement via le calculateur passerelle 21 pour les calculateurs de deuxième ou troisième type) contenant des étapes d’activation d’un ou plusieurs calculateurs embarqués 20, 30, 23 mis à jour, illustrée notamment par les figures 6 et 7 en fonction du type de calculateur. Seule la première phase du procédé nécessite d’être connecté au monde extérieur via un réseau de télécommunication, les autres phases étant exécutables déconnectées du monde extérieur.
[Fig. 2] montre des étapes de procédé conforme à l’invention pour effectuer un pré téléchargement et un téléchargement de contenu numérique à partir d’un serveur de téléchargement distant 101
A partir d’une première étape de veille du procédé exécuté dans le calculateur embarqué 10, une transition 1001 est validée lorsque l’existence d’une mise à jour à réaliser, est signalée, notamment via un logiciel d’interface avec le monde extérieur, en mémoire du calculateur embarqué client 10 par le serveur distant 101 et que le véhicule 4 est en conditions satisfaisantes pour effectuer un pré téléchargement. Le calculateur embarqué client 10 constitue un calculateur embarqué client de téléchargement au regard du procédé de mise à jour de système numérique exposé. L’existence d’une mise à jour à réaliser, résulte d’un processus amont connu en soi par ailleurs. Le fait pour le véhicule 4 de disposer d’un niveau suffisant de connectivité à un réseau de télécommunication, génère une condition satisfaisante pour effectuer un pré téléchargement Un état du véhicule 4 lorsqu’il est à propulsion électrique ou à propulsion hybride rechargeable, dans lequel il est branché sur un réseau électrique de rechargement de batterie, ou s’il est en mouvement, dans lequel il est en phase de décélération, génère une condition satisfaisante pour effectuer un pré téléchargement. Un état du véhicule 4 lorsqu’il est à propulsion thermique ou à propulsion hybride, dans lequel son moteur à combustion interne tourne, génère une condition satisfaisante pour effectuer un pré téléchargement, que le véhicule soit en roulage ou à l’arrêt.
Une validation de la transition 1001 fait passer le procédé dans une étape 1002 qui consiste à pré télécharger des données descriptives de contenu à télécharger. Ces données descriptives, notamment sous forme de métadata en fichier .xml, comportent par exemple le numéro VIN (Vehicle Identification Number en anglais), l’adresse des contenus numériques à télécharger (par exemple URL), la liste d’ordonnancement des contenus à télécharger, des métadonnées de configuration spécifiant notamment le mode d’interaction sans demande utilisateur (background) ou avec demande utilisateur (foreground). En étape 1002, le calculateur embarqué client 10 commence par envoyer une requête de pré téléchargement au serveur 101 puis stocke en mémoire tampon les données descriptives de contenu au fur et à mesure de leur arrivée. La requête de pré téléchargement contient notamment un numéro VIN du véhicule 4 auquel appartient le calculateur embarqué 10. Le calculateur embarqué client 10 vérifie notamment que les données descriptives reçues correspondent bien aux spécifications du véhicule identifié par le numéro VIN.
A partir d’une deuxième étape de veille du procédé exécuté dans le serveur 101 , une transition 10101 est validée lorsque le serveur reçoit la requête de pré téléchargement émise par le calculateur embarqué client 10 à l’étape 1002 de pré téléchargement.
Une validation de la transition 10101 fait passer le procédé dans une étape 10102 qui consiste à émettre les données descriptives de contenu à télécharger vers le calculateur embarqué 10. A titre illustratif, le serveur distant 101 peut utiliser le protocole FTP pour transférer les données descriptives sous forme de fichier ou UDP sur une voie de télécommunication disponible par ondes électromagnétiques, 802.11 , téléphonie cellulaire, réseau ad hoc (WANET, MANET, VANET... ) ou autre, la mieux appropriée selon que le véhicule est à l’arrêt ou en mouvement, et/ou selon l’environnement du véhicule 4, c’est à dire des moyens de télécommunication disponible en sa localisation. Une voie de télécommunication filaire (802.3 sur câble Ethernet ou par Courant Porteur en Ligne) peut aussi être utilisée par exemple sur un véhicule électrique lorsqu’il est branché sur une station de rechargement de batterie.
Parallèlement à l’étape 10102 d’émission de données descriptives exécutée dans le serveur 101 , l’étape 1002 exécutée dans le calculateur embarqué 10, consiste à stocker en mémoire interne les fichiers ou trames reçues du serveur 101 directement par voie de communications 1 sur un coupleur de télécommunications propre au calculateur embarqué 10, ou indirectement via un autre serveur 102 de cœur de réseau de téléphonie cellulaire, un autre calculateur embarqué 11 (IVC) dédié aux télécommunications et un bus embarqué 5.
A partir de l’étape 1002 de pré téléchargement, une transition 1003 est validée en cas de perte par le véhicule 4 d’une condition satisfaisante pour effectuer un pré téléchargement. La perte de condition satisfaisante peut résulter d’une perte de connectivité au réseau de télécommunication, par exemple lorsque le véhicule passe dans un tunnel ou entre dans une zone à faible couverture réseau. La perte de condition satisfaisante peut résulter d’un arrêt du moteur à combustion interne lorsque le véhicule 4 est à propulsion thermique ou à propulsion hybride non rechargeable, par exemple lorsque le conducteur quitte le véhicule pour aller acheter une baguette de pain. Une coupure d'alimentation batterie peut aussi constituer une perte de condition satisfaisante.
Une validation de la transition 1003 fait passer le procédé dans une étape 1004 qui consiste à mettre le calculateur embarqué en attente de conditions satisfaisantes pour effectuer un pré téléchargement. En cas de coupure d’alimentation batterie, le calculateur embarqué client 10 peut utiliser une méthode de type STR (acronyme de l’expression anglaise Suspend To RAM) relative à la gestion de l'énergie permettant de suspendre l’exécution des processus et de mémoriser leur état afin de les restaurer à l’identique après extinction du calculateur embarqué.
A partir de l’étape 1004, une transition 1005 est validée lorsque toutes les conditions satisfaisantes au pré téléchargement sont retrouvées, reconnexion à un réseau de télécommunication par exemple en sortie de tunnel, redémarrage du moteur thermique, par exemple au retour du conducteur avec sa baguette de pain.
Une validation de la transition 1005 fait repasser le procédé dans l’étape 1002 qui consiste à informer le serveur 101 de sa disponibilité et à poursuivre le stockage des données descriptives envoyées par le serveur 101. Pendant l’interruption de réception par le calculateur embarqué en étape 1004, le serveur 101 reste simplement en attente en étape 10102 de manière habituellement prévue dans les protocoles FTP et UDP pour reprendre l’émission là où elle s’était interrompue.
A partir de l’étape 1002 de pré téléchargement, une transition 1007 est validée lorsque toutes les données descriptives ont été stockées en mémoire tampon du calculateur embarqué 10 Une validation de la transition 1007 fait passer le procédé dans une étape 1008 qui consiste à télécharger des contenus numériques comportant des données descriptives les caractérisant (notamment des données de sécurisation liées notamment aux contenus sécurisés destinés à des calculateurs du premier type (en zone non sécurisée) ou à un calculateur destinataire passerelle 21 en vue de la mise à jour d’un calculateur de deuxième type ou hybride (dans ce cas ces données contiennent par exemple des informations du destinataire de la mise à jour, de la cible de la mise à jour, de taille,... ), et par exemple à envoyer les données descriptives de configuration pré téléchargées au module de gestion des configurations dynamiques HMI-proxy (dans ce cas ces données contiennent, comme mentionné précédemment des métadonnées de configuration déterminant notamment le mode d’interaction sans demande utilisateur (background) ou avec demande utilisateur (foreground)). En étape 1008, le calculateur embarqué client 10 commence par envoyer une requête de téléchargement au serveur 101 par exemple sur le port FTP du calculateur embarqué 10 lorsque le protocole FTP est utilisé, ou via un autre port en fonction du type de communication (Wifi, Ethernet...).
A partir de l’étape 10102 du procédé exécuté dans le serveur 101 , une transition 10103 est validée lorsque le serveur reçoit la requête de téléchargement émise par le calculateur embarqué client 10 à l’étape 1008.
Une validation de la transition 10103 fait passer le procédé dans une étape 10104 qui consiste à émettre les contenus requis vers le calculateur embarqué 10. A titre illustratif, le serveur distant utilise de préférence un protocole de type FTP pour transférer les contenus sous forme d’un ou plusieurs fichiers sur une voie de télécommunication disponible de manière semblable au mode opératoire de l’étape 10102.
Parallèlement à l’étape 10104 exécutée dans le serveur 101 , l’étape 1008 est exécutée dans le calculateur embarqué 10, de manière comparable à l’étape 1002 de pré téléchargement avec stockage en mémoire tampon interne. L’utilisation notamment du protocole FTP sur un port de l’IVI, permet une exécution en parallèle sans interruption avec des étapes d’autres procédés de télécommunication sur d’autres ports ou utilisant d’autres protocoles. Par exemple, si le calculateur embarqué client 10 reçoit sur le bus embarqué 5 en provenance du calculateur embarqué 11 ou d'une prise de diagnostic OBD, des trames liées à un procédé de diagnostic à distance ou local, exécuté en parallèle, les trames sont simplement aiguillées, notamment en interne du calculateur embarqué client 10, sans besoin d’interrompre l’étape 1008 à aucun moment. Pendant le téléchargement, le calculateur 10 fait différents contrôles sur les fichiers téléchargés, comme par exemple des vérifications de conformité des fichiers aux données descriptives de contenu précédemment reçues en étape 1002 de pré téléchargement, et/ou des contrôles connus de parité sur des trames reçues pour véhiculer les fichiers téléchargés.
A partir de l’étape 1008, une transition 1009 est validée en cas de perte par le véhicule 4 d’une condition satisfaisante pour effectuer un téléchargement. La perte de condition satisfaisante peut ici encore résulter d’une perte de connectivité au réseau de télécommunication, d’un arrêt du moteur à combustion interne lorsque le véhicule 4 est à propulsion thermique ou à propulsion hybride non rechargeable, ou d’un débranchement de station de chargement batterie lorsque le véhicule 4 est à propulsion électrique. La transition 1009 peut aussi être validée en cas de contrôle négatif sur un fichier téléchargé.
Une validation de la transition 1009 fait passer le procédé dans une étape 1010 qui consiste à mettre le calculateur embarqué en attente de conditions satisfaisantes pour continuer à effectuer le téléchargement En étape 1010, le calculateur 10 conserve un pointeur sur le dernier fichier correctement téléchargé.
A partir de l’étape 1010, une transition 1011 est validée lorsque toutes les conditions satisfaisantes au téléchargement sont retrouvées, par exemple : reconnexion à un réseau de télécommunication, redémarrage du moteur à combustion interne pour un véhicule thermique, rebranchement à une station de charge de batterie pour un véhicule électrique, comme à l’étape 1005.
Une validation de la transition 1011 fait repasser le procédé dans l’étape 1008 qui consiste à informer le serveur 101 de sa disponibilité et à poursuivre le stockage des fichiers envoyés par le serveur 101. A son retour en étape 1008 par validation de la transition 1011 , le calculateur embarqué client 10 envoie au serveur 101 , une référence de dernier fichier correctement téléchargé, que ce soit suite à une interruption de conditions satisfaisantes du véhicule ou suite à un contrôle négatif sur un fichier en cours de téléchargement. Pendant l’interruption de réception par le calculateur embarqué en étape 1010, le serveur 101 reste simplement en attente en étape 10104 de manière habituellement prévue dans les protocoles de type FTP pour reprendre l’émission là où elle s’était interrompue dès la disponibilité du calculateur embarqué 10, pour envoyer le fichier à télécharger à la suite du dernier fichier correctement téléchargé.
A partir de l’étape 1008, une transition 1013 est validée lorsque le téléchargement terminé est signalé au calculateur embarqué client 10 par le serveur distant 101 , les fichiers téléchargés comprennent donc tout le nouveau contenu numérique de la mise à jour, ce contenu est donc complet. Une validation de la transition 1013 fait passer le procédé dans une étape 1014 qui consiste à envoyer au serveur 101 un accusé de bonne réception accompagné préférentiellement d'un rapport de téléchargement effectué. Après envoi de l’accusé de bonne réception, accompagné selon le cas de mise en œuvre, du rapport de téléchargement effectué, le calculateur 10 retourne en étape de veille du procédé, c’est-à-dire en attente de la transition suivante du procédé.
On notera que les étapes exécutées par le calculateur embarqué client 10 de la transition 1001 à la transition 1013, peuvent être interrompues de nombreuses fois par les transitions 1003 et/ou 1009, sans interférer avec le fonctionnement du véhicule 4. En effet les deux phases de pré téléchargement et de téléchargement se limitent à un stockage dans le véhicule, par exemple ici dans le calculateur embarqué 10, du contenu utile pour la mise à jour du système numérique. Peu importe que le déroulement des étapes 1002 à 1014 dure quelques minutes ou plusieurs jours, car les étapes 1002 à 1014 sont exécutées en temps masqué par rapport au fonctionnement du véhicule. Les deux phases du procédé qui viennent d’être exposées ci-dessus, sont ainsi mises en œuvre en mode connecté au monde extérieur sans mettre en danger l’état de charge de la ou des batteries électriques du véhicule, rechargées par le moteur à combustion interne tournant pour un véhicule thermique ou hybride, ou rechargées par la station de rechargement sur laquelle est branché le véhicule électrique ou hybride rechargeable.
A partir de l’étape 10104, une transition 10105 est validée lorsque le serveur 101 reçoit l’accusé de bonne réception, accompagné selon le cas de mise en œuvre, du rapport de téléchargement effectué.
Une validation de la transition 10105 fait passer le procédé dans une étape 10106 qui consiste à consigner l’accusé de bonne réception, accompagné selon le cas de mise en œuvre, du rapport de téléchargement effectué, dans une base de consignation d’états de téléchargements pour un ensemble de véhicules gérés par le serveur 101 en matière de mises à jour de systèmes numériques dans lesdits véhicules. Le serveur 101 retourne ensuite en étape de veille pour les étapes du procédé ci-dessus exposées, de manière connue ensoi par ailleurs pour les serveurs habituellement aptes à traiter plusieurs procédés en parallèle.
En outre, au moins une desdites étapes du procédé de mise à jour de système numérique peut comporter une sous-étape d’interaction entre l’appareil d’interface homme-machine 12 et l’utilisateur via l’appareil d’interface homme-machine 12 selon un mode d’interaction spécifique, notamment fonction de ladite étape en cours. Pour ce faire, comme mentionné précédemment, les données descriptives pré téléchargées peuvent comporter des métadonnées (de type xml par exemple) de configuration de l’appareil d’interface homme-machine 12. Ces métadonnées de configuration sont transmises par le calculateur embarqué client 10 à l’appareil d’interface homme-machine 12 par liaison directe interne (représentée, mais non référencée) et stockées dans un module de gestion des configurations dynamiques, aussi appelé HMI proxy, en fin d’étape 1008. En outre, de manière préférentielle, l’appareil d’interface homme-machine 12 est hébergé par le calculateur embarqué client 10. Les métadonnées de configuration caractérisent le contenu numérique pour mettre à jour un calculateur embarqué du fait qu’elles définissent le mode d’interaction entre l’appareil d’interface homme-machine 12 et l’utilisateur lors des étapes de distribution, d’installation et d’activation du contenu numérique associé. En effet, pour chaque étape de la mise à jour et en fonction du contenu numérique, une politique de gestion diversifiée des campagnes de mises à jour peut ainsi être définie en amont de manière débarquée et proposer ainsi des modes d’interaction entre l’appareil d’interface homme-machine 12 et l’utilisateur via l’appareil d’interface homme-machine 12 qui soient différents en fonction de la mise à jour concernée et de l’étape en cours de mise à jour du système numérique. En effet, le calculateur embarqué client 10 intervenant tout au long du procédé de distribution, installation et activation des contenus, il a connaissance de l’étape de la mise à jour en cours. Ainsi, en fonction de la mise à jour et de l’étape d’installation en cours, les différents modes d’interaction avec l’utilisateur, notamment au moyen d’un écran de l’appareil d’interface homme-machine 12, prennent par exemple la forme d’un accord qui peut être demandé à l’utilisateur au moyen d’un bouton virtuel affiché sur IΊHM sur lequel l’utilisateur devra appuyer, ou d’une information à l’utilisateur sous forme de texte, ou encore être invisible à l’utilisateur, par exemple s'il s’agit d’une campagne critique. De plus, les métadonnées de configuration caractérisant le contenu numérique pour mettre à jour un calculateur embarqué peuvent aussi définir les conditions véhicule requises pour déclencher l’interaction entre l’appareil d’interface homme-machine 12 et l’utilisateur. Par exemple, si la phase d’installation se termine en cours de mission, ce qui est très probable, la condition imposera par exemple que le moteur soit éteint et le mode d'interaction par demande de consentement ne sera donc proposé à l’utilisateur en phase d’activation qu’en fin de mission, c’est-à-dire en fin de trajet, une fois le moteur éteint.
[Fig. 3] montre des étapes de procédé conforme à l’invention pour effectuer une distribution et une installation de contenu numérique à l’intérieur du système numérique (on board en anglais) à partir du calculateur embarqué client 10. Les étapes à présent décrites sont exécutées déconnectées du monde extérieur (off board en anglais). Plus précisément, la phase de distribution et d’installation illustrées par la figure 3 sont effectuées en vue de mettre à jour un premier type de calculateur embarqué 20 correspondant à l’un des calculateurs embarqués 11 , 21 , 22 directement connecté sur le bus embarqué 5 sur lequel est connecté le calculateur embarqué client 10. Ces derniers 11 , 21 , 22 sont équipés chacun de ressources informatiques suffisantes pour traiter le contenu téléchargé qui lui est destiné.
Consécutivement à l’étape 1014 d’envoi d’accusé de bonne réception du procédé exécuté dans le calculateur embarqué 10, une transition 1015 est validée lorsque l’existence d’un contenu numérique complet pour mettre à jour un calculateur embarqué, est signalée en mémoire du calculateur embarqué client 10 par notification interne et que le véhicule 4 est en conditions satisfaisantes pour effectuer une distribution et une installation des contenus numériques à l’intérieur du système numérique. Ce contenu numérique complet prend notamment la forme d’une liste des contenus numériques téléchargés, sachant que l’enchaînement des contenus dans la liste n’a pas d’ordre nécessairement lié aux types de calculateurs, par exemple deux contenus qui se suivent peuvent être destinés à des calculateurs de type différent (à l’image de l’enchaînement suivant premier type puis deuxième type puis premier type puis deuxième type puis troisième type puis deuxième type, par exemple). Les deux phases du procédé relatives à la distribution et à l’installation des contenus dans un ou plusieurs calculateurs embarqués, ne nécessitant pas de connexion avec l’extérieur, le véhicule 4 est en conditions satisfaisantes lorsque le véhicule 4 est à même d’alimenter les calculateurs du système numérique concernés par la distribution et l’installation de contenu, c'est-à-dire par exemple de maintenir un niveau suffisant de charge des batteries, moteur à combustion interne tournant pour un véhicule thermique, batteries branchées sur une station de charge pour un véhicule électrique.
Une validation de la transition 1015 fait passer le procédé dans une étape 1016 dans laquelle le calculateur embarqué client 10 distribue un premier contenu numérique téléchargé en mémoire tampon interne vers la mémoire tampon interne du calculateur embarqué 20. En étape 1016, le calculateur embarqué client 10 commence par définir le calculateur embarqué destinataire du contenu numérique par lecture des données descriptives du contenu qui caractérisent ledit contenu, puis envoie une requête de distribution au calculateur embarqué destinataire puis commence à distribuer le contenu numérique vers ce calculateur. En effet, ici le calculateur cible devant être mis à jour par ce contenu numérique est du premier type 20, à savoir l’un des calculateurs 11 , 21 , 22 relié au calculateur client 10 directement via le bus embarqué 5 et de fait le calculateur destinataire du contenu numérique est identifié comme étant le calculateur cible en question 11 , 21 , 22.
Parallèlement, dans le calculateur destinataire 20, une transition 2001 est validée lorsqu’il 20 reçoit la requête de distribution émise par le calculateur embarqué client 10 à l’étape 1016 de distribution A titre illustratif, le calculateur embarqué client 10 peut utiliser les protocoles CAN ou FTP pour distribuer le contenu numérique, en l’espèce ce contenu est ici sécurisé (encapsulation(s)) puisque ce calculateur n’est pas en zone sécurisée et comporte des données descriptives téléchargées de sécurisation, au calculateur destinataire 20, en l’espèce via le bus 5 embarqué, indépendamment du niveau de connectivité à un réseau de télécommunication puisque ces étapes sont exécutées déconnectées du monde extérieur. Une validation de la transition 2001 fait passer le procédé dans une étape 2002 qui consiste à stocker le contenu numérique dans le calculateur destinataire 20.
Parallèlement à l’étape 1016 de distribution du contenu numérique exécutée par le calculateur client 10, l’étape 2002 de stockage du contenu numérique est exécutée dans le calculateur destinataire 20, il s’agit de désencapsuler le contenu sécurisé puis vérifier que le contenu est bien destiné à audit calculateur 20 (sinon, comme pour tout cas d’échec lors d’une étape, il y a rejet et effacement mémoire, comme explicité pour la phase d’activation dans la suite du texte, en l’espèce mémoire tampon) puis à stocker en mémoire tampon interne du calculateur destinataire 20 les fichiers ou trames reçues du calculateur client 10 via le bus embarqué 5.
A partir de l’étape 1016 de distribution, une transition 1017 est validée lorsque la distribution du contenu numérique terminée est signalée au calculateur client 10 par le calculateur embarqué destinataire 20, en l’espèce via le bus 5. En effet, quand bien même le calculateur client 10 sait quand il a fini de distribuer, le signal du calculateur destinataire 20 lui confirme que tout a bien été reçu.
Une validation de la transition 1017 fait passer le procédé dans une étape 1018 qui consiste à envoyer une requête d’installation au calculateur destinataire 20. En étape 1018, le calculateur embarqué client 10 envoie une requête de d’installation au calculateur destinataire 20 via le bus embarqué 5.
A partir de l’étape 2002 de stockage exécuté dans le calculateur destinataire 20, une transition 2003 est validée lorsque le calculateur destinataire 20 reçoit la requête d’installation émise par le calculateur embarqué client 10 à l’étape 1018.
Une validation de la transition 2003 fait passer le procédé dans une étape 2004 qui consiste pour le calculateur destinataire 20 à installer directement pour lui-même le contenu numérique préalablement stocké dans sa mémoire tampon interne, puis notamment à notifier au calculateur client 10 l’achèvement de l’installation. Par installer on entend préparer à l’activation future, c’est- à-dire en l’espèce si le calculateur destinataire 20 est double banque on y copie le contenu numérique nouveau dans la banque inactive, et si le calculateur ne dispose que de mémoire tampon il n’y a rien de plus à faire.
A partir de l’étape 1018 de requête d’installation exécutée dans le calculateur client 10, une transition 1019 est validée lorsque l’installation terminée est signalée au calculateur client 10 par le calculateur embarqué destinataire 20 via le bus 5, notamment au moyen de la réception de la notification d’achèvement d’installation émise par le calculateur destinataire 20. L’installation du contenu numérique dans le calculateur destinataire 20 est donc achevée.
La validation de la transition 1019 fait passer le procédé dans une étape 1020 qui consiste à vérifier s’il existe ou non un autre contenu numérique à installer dans le système numérique.
S’il existe un autre contenu numérique à installer dans le système numérique, c’est-à-dire sur un calculateur embarqué 11 , 21 , 22, la transition 1021 est validée lorsqu’un autre contenu numérique à installer est détecté dans la liste des contenus numériques téléchargés. La validation de la transition 1021 fait reboucler le procédé à l’étape 1016.
S’il n’existe pas d’autre contenu numérique à installer dans le système numérique, c’est-à- dire qu’on vient d’installer le dernier contenu numérique de la liste des contenus numériques téléchargés, la transition 1023 est validée et fait passer le procédé dans une étape 1024 qui consiste à passer en phase de vérification des conditions d’activation des contenus numériques de la campagne de mise à jour en cours envoi d'une notification de fin d’installation au module de gestion des configurations dynamiques HMI-proxy. Cette requête au HMI-proxy déterminera les conditions d’activation requises en fonction des contenus numériques et/ou des calculateurs, c’est-à-dire par exemple le besoin ou non d’accord utilisateur, conditions dynamiques prédéfinies en amont, notamment à la création de la campagne.
Après cette phase de distribution et d’installation pour un premier type de calculateur, le calculateur 10 retourne en étape de veille du procédé, il peut s’agir d’une attente de fin de mission ou par exemple d’une attente de fin de mission combinée à un accord utilisateur notamment, mais on ne pourra pas retourner en phase de distribution tant que le procédé n’est pas achevé, c’est-à- dire tant que la campagne de mise à jour ne sera pas terminée.
[Fig. 4] montre des étapes de procédé conforme à l’invention pour effectuer une distribution et une installation de contenu numérique à l’intérieur du système numérique (on board en anglais) à partir du calculateur embarqué client 10. Les étapes à présent décrites sont également exécutées déconnectées du monde extérieur (off board en anglais) Plus précisément, la phase de distribution et d’installation illustrée par la figure 4 sont effectuées en vue de mettre à jour un deuxième type de calculateur embarqué 30 correspondant à un calculateur indirectement connecté au calculateur embarqué client 10 au travers du calculateur passerelle 21 et équipé de ressources informatiques suffisantes pour traiter le contenu téléchargé qui lui est destiné, en l’espèce l’un des calculateurs embarqués 31 , 32, 33 connectés au deuxième bus embarqué 6.
Consécutivement à l’étape 1014 d’envoi d’accusé de bonne réception du procédé exécuté dans le calculateur embarqué 10, une transition 1015 est validée lorsque l’existence d’un contenu numérique complet pour mettre à jour un calculateur embarqué, est signalée en mémoire du calculateur embarqué client 10 et que le véhicule 4 est en conditions satisfaisantes pour effectuer une distribution et une installation de contenu numérique à l’intérieur du système numérique.
Comme déjà mentionné, ce contenu numérique complet prend notamment la forme d’une liste des contenus numériques téléchargés, sachant que l’enchaînement des contenus dans la liste n’a pas d’ordre nécessairement lié aux types de calculateurs. Les deux phases du procédé relatives à la distribution et à l’installation de contenus numériques dans un ou plusieurs calculateurs embarqués, ne nécessitant pas de connexion avec l’extérieur, le véhicule 4 est en conditions satisfaisantes lorsque le véhicule 4 est à même d’alimenter les calculateurs du système numérique concernés par la distribution et l’installation de contenu, c’est-à-dire par exemple de maintenir un niveau suffisant de charge des batteries, moteur à combustion interne tournant pour un véhicule thermique, batteries branchées sur une station de charge pour un véhicule électrique.
Une validation de la transition 1015 fait passer le procédé dans une étape 1016 dans laquelle le calculateur embarqué client 10 distribue un premier contenu numérique téléchargé en mémoire tampon interne vers le calculateur embarqué 21. En étape 1016, le calculateur embarqué client 10 commence par définir le calculateur embarqué destinataire du contenu numérique par lecture des données descriptives du contenu, puis envoie une requête de distribution au calculateur embarqué destinataire 21 puis commence à lui distribuer le contenu numérique. En effet, ici le calculateur cible devant être mis à jour par ce contenu numérique est du deuxième type 30, à savoir l’un des calculateurs 31 , 32, 33 sur le bus embarqué 6 et relié au calculateur client 10 via le calculateur passerelle 21 et de fait le calculateur destinataire du contenu numérique est identifié comme étant le calculateur passerelle 21 .
Parallèlement, dans le calculateur passerelle 21 , une transition 2101 est validée lorsqu’il 21 reçoit la requête de distribution émise par le calculateur embarqué client 10 à l’étape 1016 de distribution A titre illustratif, le calculateur embarqué client 10 peut par exemple utiliser les protocoles CAN, FTP, Ethernet, pour distribuer le contenu numérique au calculateur passerelle 21 , en l’espèce via le bus 5 embarqué, indépendamment du niveau de connectivité à un réseau de télécommunication puisque ces étapes sont exécutées déconnectées du monde extérieur. Une validation de la transition 2101 fait passer le procédé dans une étape 2102 qui consiste à stocker le contenu numérique dans le calculateur passerelle 21 .
Parallèlement à l’étape 1016 de distribution du contenu numérique exécutée par le calculateur client 10, l’étape 2102 de stockage du contenu numérique est exécutée dans le calculateur passerelle 21 , il s’agit de stocker en mémoire tampon interne du calculateur passerelle 21 les fichiers ou trames reçues du calculateur client 10 via le bus embarqué 5.
Parallèlement, à partir de l’étape 1016 de distribution du procédé exécuté dans le calculateur client 10, une transition 1017 est validée lorsque l’achèvement de la distribution du contenu numérique au calculateur destinataire passerelle 21 est signalé au calculateur client 10 par le calculateur passerelle 21 , en l’espèce via le bus 5.
Une validation de la transition 1017 fait passer le procédé dans une étape 1018 qui consiste à envoyer une requête d’installation au calculateur cible 30. En étape 1018, le calculateur embarqué client 10 envoie une requête de d’installation au calculateur destinataire passerelle 21 , en l’espèce via le bus embarqué 5. En effet ce contenu numérique apparaît d’après ses données descriptives comme un contenu destiné au calculateur passerelle 21, le calculateur client 10 n’est donc pas en liaison directe avec le calculateur cible, mais avec le calculateur passerelle 21 et ce dernier activera les calculateurs 30 comme expliqué par la suite.
A partir de l’étape 2102 de stockage exécuté dans le calculateur passerelle 21 , une transition 2103 est validée lorsque le calculateur passerelle 21 a reçu la requête d’installation envoyée à l’étape 1018.
La validation de la transition 2103 fait donc passer le procédé dans une étape 2104 dans laquelle le calculateur embarqué passerelle 21 définit le calculateur cible 30 du contenu (en fonction des données descriptives du contenu sécurisé) et lui 30 distribue le contenu numérique qu’il 21 avait stocké en mémoire tampon interne En étape 2104, le calculateur embarqué destinataire passerelle 21 commence par envoyer une requête de distribution au calculateur cible 30 défini, en l’espèce via le bus embarqué 6, puis commence à distribuer le contenu numérique vers ce calculateur cible 30. En effet, ici le calculateur cible devant être mis à jour par ce contenu numérique est du premier type 30, à savoir l’un des calculateurs 31, 32, 33 relié au calculateur passerelle 21, notamment via le bus embarqué 6. Parallèlement, à partir d’une étape de veille du procédé exécuté dans le calculateur embarqué cible 30, une transition 3001 est validée lorsque le calculateur passerelle 30 reçoit la requête de distribution émise par le calculateur passerelle 21 à l’étape 2104 de distribution. A titre illustratif, le calculateur embarqué passerelle 21 peut utiliser les protocoles CAN, FTP, Ethernet pour distribuer le contenu numérique au calculateur cible 30 via le bus 6 embarqué, indépendamment du niveau de connectivité à un réseau de télécommunication puisque ces étapes sont exécutées déconnectées du monde extérieur. Une validation de la transition 3001 fait passer le procédé dans une étape 3002 qui consiste à stocker le contenu numérique dans le calculateur cible 30.
Parallèlement à l’étape 2104 de distribution du contenu numérique exécutée par le calculateur passerelle 21 , l’étape 3002 de stockage du contenu numérique est exécutée dans le calculateur cible 30, il s’agit de stocker en mémoire interne inactive en cas de calculateur cible 30 double banque et sinon en mémoire externe du calculateur cible 30 les fichiers ou trames reçues du calculateur passerelle 21 , en l’espèce via le bus embarqué 6. Il convient de noter que le stockage en mémoire externe n’occupe pas toute la mémoire externe, mais qu’une partie de la mémoire externe, ce qui permet d’avoir à la fois en mémoire externe du calculateur destinataire le contenu numérique courant, c’est-à-dire d'une version passée (mais toujours actif à cette étape du procédé), celui-ci n’étant pas effacé, et ce nouveau contenu numérique de la mise à jour. Ce stockage en mémoire externe du contenu passé permettra dans la suite du procédé, lors de la phase d’activation, une sauvegarde pour un éventuel retour en arrière si nécessaire.
A partir de l’étape 2104 de distribution du procédé exécuté dans le calculateur passerelle 21 , une transition 2105 est validée lorsque la distribution du contenu numérique terminée est signalée au calculateur passerelle 21 par le calculateur embarqué cible 30, en l’espèce via le bus 6.
Une validation de la transition 2105 fait passer le procédé dans une étape 2106 qui consiste pour le calculateur passerelle 21 à envoyer une requête d'installation du calculateur cible vers le calculateur cible 30. En étape 2106, le calculateur embarqué passerelle 21 envoie une requête d’installation du calculateur cible au calculateur cible 30 en l’espèce via le bus embarqué 6.
A partir de l’étape 3002 de stockage exécuté dans le calculateur cible 30, une transition 3003 est validée lorsque le calculateur cible 30 reçoit la requête d’installation du calculateur cible émise par le calculateur passerelle 21 à l’étape 2106. Une validation de la transition 3003 fait passer le procédé dans une étape 3004 d’installation qui consiste pour le calculateur cible 30 à se constituer une sauvegarde du contenu courant en copiant, soit, en fonction de la nature de la mémoire du calculateur 30, les éléments manquants, à savoir ceux du contenu courant qui ne changent pas avec la mise à jour, dans la banque inactive dans le cas d’une mémoire interne double banque, soit, en cas de mémoire externe, en copiant l’intégralité du contenu numérique courant en mémoire externe du calculateur cible 30, puis notamment à notifier au calculateur passerelle 21 l’achèvement de l’installation. Par installer on entend préparer à l’activation future, et notamment pour un calculateur de deuxième type 30 à mémoire externe, il s'agit d’y sauvegarder le contenu courant pour permettre un éventuel retour en arrière. En effet, en cas de double banque une simple commutation suffit et permet de ne pas avoir à sauvegarder par copie tierce. De fait, si le calculateur cible 30 est double banque on copie dans la banque inactive les éléments du contenu courant du calculateur 30 présents dans la banque active qui n’ont pas fait l’objet de la mise à jour et ne figuraient donc pas dans les nouveaux contenus numériques, et si le calculateur cible 30 ne dispose que de mémoire externe on y copie l’ensemble des éléments du contenu courant du calculateur 30 (présents dans la mémoire active courante).
A partir de l’étape 2106 d’installation exécutée par le calculateur passerelle 21 , une transition 2107 est validée lorsque l’installation terminée est signalée au calculateur passerelle 21 par le calculateur embarqué cible 30, en l’espèce via le bus 6, notamment au moyen de la réception de la notification d’achèvement d’installation émise par le calculateur cible 30. L’installation du contenu numérique dans le calculateur cible 30 est donc achevée sans erreur.
Une validation de la transition 2107 fait passer le procédé dans une étape 2108 qui consiste à envoyer, en fonction de la notification d’achèvement d’installation, au calculateur client 10 le statut (correct ou incorrect) de l’installation de du calculateur cible 30. Après envoi du statut le calculateur passerelle 21 retourne en étape de veille du procédé.
A partir de l’étape 1018 d’installation exécutée par le calculateur client 10, une transition 1019 est validée à la réception du statut correct d’installation émis par le calculateur passerelle 21.
La validation de la transition 1019 fait passer le procédé dans une étape 1020 qui consiste à vérifier s’il existe ou non un autre contenu numérique à installer dans le système numérique.
S’il existe un autre contenu numérique à installer dans le système numérique, c’est-à-dire sur un calculateur embarqué quel qu’il soit 20, 30, 23, la transition 1021 est validée lorsqu’un autre contenu numérique à installer est détecté dans la liste des contenus numériques téléchargés. La validation de la transition 1021 fait reboucler le procédé à l’étape 1016.
S’il n’existe pas d’autre contenu numérique à installer dans le système numérique, c’est-à- dire qu’on vient d’installer le dernier contenu numérique de la liste des contenus numériques téléchargés, la transition 1023 est validée et fait passer le procédé dans une étape 1024 qui consiste à passer en phase de vérification des conditions d’activation des contenus numériques de la campagne de mise à jour en cours par envoi d’une notification de fin d’installation au module de gestion des configurations dynamiques HMI-proxy. Comme précédemment décrit en figure 3, cette requête au HMI-proxy déterminera les conditions d’activation requises en fonction des contenus numériques et/ou des calculateurs, c’est-à-dire par exemple le besoin ou non d’accord utilisateur.
Après cette phase de distribution et d’installation pour un deuxième type de calculateur, le calculateur 10 retourne en étape de veille du procédé, il s’agit donc d’une attente des conditions d’activation, mais on ne pourra pas retourner en phase de distribution tant que le procédé n’est pas achevé, c’est-à-dire tant que la campagne de mise à jour ne sera pas terminée.
[Fig. 5] illustre schématiquement le procédé conforme à l’invention pour effectuer une distribution et une installation de contenu numérique à l’intérieur du système numérique (on board en anglais) à partir du calculateur embarqué client 10. Comme précédemment, les étapes à présent décrites sont exécutées déconnectées du monde extérieur (off board en anglais). Plus précisément, la phase de distribution et d’installation objet de la figure 5 est effectuée en vue de mettre à jour un troisième type de calculateur embarqué 23 de type hybride correspondant au calculateur embarqué 23, qui en l’espèce est un afficheur. Ce troisième type de calculateur se dénomme hybride car il comporte deux processeurs et que chaque processeur est considéré comme un calculateur de type différent, tel que représenté sur la figure. Ainsi un premier processeur est un calculateur du premier type et est connecté au calculateur embarqué client 10 en l’espèce via la liaison sécurisée 7 (le bus embarqué 5 reliant le calculateur hybride 23 au calculateur client 10, n’est pas utilisé ici, mais pourrait représenter une variante) dont le port côté premier processeur est sécurisé, et le deuxième processeur est un calculateur du deuxième type et est connecté au calculateur embarqué passerelle 21 via le bus 8. Il convient de noter que préférentiellement, pour des raisons de sécurité, et tel que présenté ici la liaison directe 7 n’est pas toujours ouverte, c’est-à-dire qu’avantageusement le port de communication sécurisé situé sur le premier processeur est par défaut fermé, empêchant toute communication de données par cette liaison. En outre, ce calculateur hybride 23 pourrait comporter d’autres parties. Ce calculateur hybride 23 est équipé de ressources informatiques suffisantes pour traiter le contenu téléchargé qui lui est destiné. De par sa structure la phase de distribution et d’installation de contenu dans un calculateur hybride 23 met en œuvre les étapes afférentes telles que décrites précédemment pour un calculateur de premier type, en figure 3, et un calculateur de deuxième, en figure 4, la mise à jour comporte donc deux contenus numériques téléchargés distincts caractérisés chacun par ses données descriptives distinctes. Ainsi, le premier contenu, sécurisé, désignera un calculateur destinataire 23, comme s’il était de premier type, et le second contenu un calculateur destinataire passerelle pour une mise à jour du calculateur cible 23, comme s’il était de deuxième type.
Il est commencé par le second contenu, la flèche en trait plein entre le calculateur client 10 et le calculateur passerelle 21 représente les échanges entre ces deux calculateurs lors de la phase de distribution et d’installation du second contenu pour laquelle le calculateur passerelle 21 est destinataire alors que le calculateur hybride 23 est cible. De même, la flèche en trait plein entre le calculateur passerelle 21 et le calculateur hybride 23 représente les échanges entre ces deux calculateurs lors de la phase de distribution et d’installation du second contenu pour laquelle le calculateur passerelle 21 est destinataire alors que le calculateur hybride 23 est cible. Les étapes de procédé dont il est question sont donc à l’image de celles mises en œuvre pour un calculateur de deuxième type telles que décrites en figure 4.
Ce calculateur étant de troisième type, à l’issue de l’installation de ce second contenu, il est procédé à une étape intermédiaire dans laquelle le second processeur envoie une requête d’ouverture du port sécurisé au premier processeur, en interne du calculateur hybride 23 Cet envoi de requête d’ouverture est illustré par la flèche en trait pointillé entre le calculateur passerelle 21 et le calculateur hybride 23. Une fois le port ouvert, la suite des étapes de la phase de distribution et d’installation du premier contenu peuvent alors se dérouler comme précédemment décrites en figure 3, en l’espèce via la liaison 7.
La flèche en trait plein entre le calculateur client 10 et le premier processeur du calculateur hybride 23 représente la phase de distribution et d’installation du premier contenu dans la première partie de la mémoire externe du calculateur hybride 23 en tant que calculateur destinataire et cible. Les étapes de procédé dont il est question sont donc à l’image de celles mises en œuvre pour un calculateur de premier type telles que décrites en figure 3
A l’issue de la phase de distribution et d’installation, chaque calculateur cible est à jour, ce qui signifie donc pour un calculateur du premier type qu’il comporte le nouveau contenu numérique dans sa banque inactive interne ou dans sa mémoire tampon et pour un calculateur du deuxième type qu’il comporte le nouveau contenu numérique dans sa mémoire externe ou dans sa banque inactive interne, et donc les deux à la fois dans le cas d’un calculateur du troisième type.
[Fig. 6] montre des étapes de procédé conforme à l'invention pour effectuer l’activation d’un calculateur embarqué cible du premier type après installation. Les étapes à présent décrites sont également exécutées déconnectées du monde extérieur (off board en anglais). Plus précisément, la phase d’activation illustrée par la figure 6 est effectuée en vue de mettre à jour un premier type de calculateur embarqué 20 correspondant à l’un des calculateurs embarqués 11 , 21 , 22 directement connecté sur le bus embarqué 5 sur lequel est connecté le calculateur embarqué client 10, et équipés chacun de ressources informatiques suffisantes pour traiter le contenu téléchargé qui lui est destiné.
Consécutivement à l’étape 1024 d’envoi d’une notification de fin d’installation des contenus numériques de la campagne de mise à jour du procédé exécuté dans le calculateur embarqué 10, une transition 1025 est validée lorsque le véhicule 4 est dans les conditions d’activation requises par la campagne de mise à jour. Ces conditions sont déterminées par le module de gestion des configurations dynamiques HMI-proxy, sur la base des données descriptives (métadonnées) envoyées au module de gestion des configurations dynamiques HMI-proxy. Par exemple, chaque calculateur a ses propres conditions d’activations, parmi lesquelles certaines sont communes (fin de mission) et certaines plus précises (accord utilisateur : foreground) notamment dans le cas des calculateurs du deuxième type 30 Une condition satisfaisante pour effectuer l’activation de la mise à jour du calculateur du premier type 20 peut être générée par le fait pour le véhicule 4 d’être en fin de mission, c’est-à-dire que le moteur vient d’être arrêté.
Une validation de la transition 1025 fait passer le procédé dans une étape 1026 qui consiste à déclencher l’activation du calculateur embarqué cible (et destinataire à la fois, puisque ce calculateur est du premier type) 20. En étape 1026, le calculateur embarqué client 10 commence par définir le calculateur embarqué cible 20 par lecture du contenu numérique caractérisé par ses données descriptives qui contiennent cette indication, puis à émettre une requête d’activation au calculateur embarqué cible 20. En effet, ici le calculateur cible devant être mis à jour par ce contenu numérique est du premier type 20, à savoir l’un des calculateurs 11, 21 , 22 relié au calculateur client 10 directement via le sur le bus embarqué 5 et de fait le calculateur cible du contenu numérique, donc à activer, est identifié comme étant le calculateur cible en question 11 , 21 , 22. Parallèlement, dans le calculateur destinataire 20, postérieurement à l’étape 2004 d’installation directement pour lui-même du calculateur embarqué cible 20, une transition 2011 est validée lorsque le calculateur embarqué cible 20 reçoit la requête d’activation émise par le calculateur embarqué client 10 à l’étape 1026 de déclenchement d’activation. A titre illustratif, le calculateur embarqué client 10 peut utiliser les protocoles CAN, FTP, Ethernet pour émettre la requête d’activation au calculateur destinataire 20 via le bus 5 embarqué, indépendamment du niveau de connectivité à un réseau de télécommunication puisque ces étapes sont exécutées déconnectées du monde extérieur. Une validation de la transition 2011 fait passer le procédé dans une étape 2012 qui consiste à activer le contenu numérique installé à l’étape 3004 dans le calculateur destinataire 20, puis notamment à notifier au calculateur client 10 l’achèvement de l’activation, sachant que cette notification peut être une notification de réussite ou une notification d’échec de l’activation. Par activer, il est entendu, pour un calculateur du premier type, passer du contenu courant au nouveau contenu par commutation en cas de double banque et sinon par mise à jour de la mémoire courante interne en cas de mémoire tampon interne. En l’espèce cette notification est acheminée au moyen du bus 5.
A partir de l’étape 1026 de déclenchement d’activation exécutée par le calculateur client 10, une transition 1027 est validée lorsque le rapport d’activation réussie du contenu numérique, émise par le calculateur embarqué cible 20 à l’étape 2012, est reçue par le calculateur client 10.
Une validation de la transition 1027 fait passer le procédé dans une étape 1028 qui consiste à générer un rapport interne d’activation afférent au contenu numérique activé en question et à vérifier s’il existe ou non un autre contenu numérique à installer dans le système numérique
A partir de l’étape 1028 exécutée dans le calculateur client 10, une transition 1029 est validée s’il existe un autre contenu numérique à installer dans le système numérique, c’est-à-dire sur un calculateur embarqué 11 , 21 , 22, 30, 31 , 32, 33 quel qu’il soit. La transition 1029 est donc validée lorsqu’un tel autre contenu numérique à installer est détecté dans la liste des contenus numériques téléchargés. La validation de la transition 1029 fait reboucler le procédé à l’étape 1026.
S’il n’existe pas d’autre contenu numérique à installer dans le système numérique, c’est-à- dire qu’on vient d’installer le dernier contenu numérique de la liste des contenus numériques téléchargés, la transition 1030 est validée et fait passer le procédé dans une étape 1031 qui consiste pour le calculateur client 10 à envoyer une notification de fin de campagne de la mise à jour en cours au calculateur cible 20. C’est donc après l’activation réussie de tous les calculateurs cibles 20, 30, 23 de la liste, qu’est envoyée cette notification de fin de campagne à chacun des calculateurs cibles 20, 30, 23. Chacun des calculateurs (sauf le dernier) a donc attendu en veille de recevoir cette notification qui confirme la réussite de toutes les activations de la campagne de mise à jour. En effet, cette notification ne peut pas être émise avant au cas où un des calculateurs ne réussirait pas son activation, comme cela sera expliqué par la suite.
A partir de l’étape 2012 d’activation exécutée et réussie par le calculateur cible 20, une transition 2013 est validée lorsque le calculateur cible 20 reçoit la notification de fin de campagne envoyée par le calculateur client 10 à l’étape 1031.
Une validation de la transition 2013 fait passer le procédé dans une étape 2014 qui consiste à effacer le contenu numérique passé, désormais inactif à cette étape du procédé, et une fois cet effacement achevé à notifier le calculateur client 10 du statut « prêt pour une nouvelle mise à jour » du calculateur cible 20
A partir de l’étape 1031 d’envoi de notification de fin de campagne exécutée dans le calculateur client 10, une transition 1032 est validée lorsque le calculateur client 10 a reçu toutes les notifications de statut « prêt » envoyées par chaque calculateur cible 20 ou destinataire 30 à l’étape 2014 ou 2114.
Une validation de la transition 1032 fait passer le procédé dans une étape 1033 qui consiste à générer un rapport global de réussite de campagne, le rapport généré étant mis à jour par agrégations successives à chaque statut « prêt » de calculateur cible 20 ou destinataire 21 . Une fois que toutes les notifications de chaque calculateur 20, 30, 23 de la liste auront été envoyées, le rapport global généré à cette étape 2014 sera complet, ce rapport étant ensuite transmis au serveur distant 101 ou 102 (non représenté sur la figure 6).
En revanche dès qu’une activation se solde par un échec à l’étape 2012 pour un calculateur cible 20, à la suite de l’étape 1026 de déclenchement d’activation exécutée par le calculateur client 10, une transition 1034 est validée lorsque la notification d’échec d’activation du contenu numérique, émise par le calculateur embarqué cible 20 à l’étape 2012, est reçue par le calculateur client 10.
Une validation de la transition 1034 fait passer le procédé dans une étape 1035 qui consiste à déclencher un retour en arrière général de tous les calculateurs du système numérique faisant l’objet de la campagne de mise à jour. Par retour en arrière général, on entend retour à l’état initial avant le début de la campagne En étape 1035, le calculateur embarqué client 10 commence par définir tous les calculateurs embarqués destinataires faisant l’objet de la campagne de mise à jour, puis à émettre une requête de retour en arrière à chacun de ces calculateurs embarqués destinataires 20, 21, 23 définis. En l’espèce, le calculateur cible défini et devant donc effectuer le retour en arrière est du premier type 20, à savoir l’un des calculateurs 11 , 21 , 22 relié au calculateur client 10 directement via le sur le bus embarqué 5.
Parallèlement, dans le calculateur destinataire 20, la transition 2015 est validée lorsque le calculateur embarqué cible 20 reçoit la requête de retour en arrière émise par le calculateur embarqué client 10 à l’étape 1035. En l’espèce cette notification est acheminée au moyen du bus 5. Il convient de rappeler qu’à cette étape du procédé est encore présent en mémoire externe du calculateur cible 20 le contenu numérique passé (qui est désormais inactif si l’activation du nouveau contenu, de remplacement, a réussi, et toujours actif sinon), celui-ci n’étant pas effacé, et le nouveau contenu numérique de la mise à jour, désormais activé si son activation a réussi.
Une validation de la transition 2015 fait passer le procédé dans une étape 2016 qui consiste à effectuer le retour en arrière, c’est-à-dire à réactiver le contenu numérique passé, rendant donc inactif le contenu numérique nouveau s’il ne l’était pas déjà, et une fois ce retour en arrière achevé à le notifier au calculateur client 10.
A partir de l’étape 1035 de déclenchement de retour en arrière exécutée dans le calculateur client 10, une transition 1036 est validée lorsque le calculateur client 10 reçoit la notification d’achèvement de retour en arrière envoyée par le calculateur cible 20 à l’étape 2016.
Une validation de la transition 1036 fait passer le procédé dans une étape 1037 qui consiste à générer un rapport d’échec de campagne puis une fois ce rapport complet à notifier au calculateur cible 20 la fin de campagne, le rapport généré étant mis à jour par agrégations successives à chaque calculateur cible 20 ayant effectué son retour en arrière. Une fois que toutes les notifications de tous les calculateurs cibles définis à l’étape 1035 auront été reçues, le rapport d’échec de campagne généré à cette étape 1037 sera complet, et ta notification de fin de campagne envoyée à chacun des calculateurs cibles définis à l’étape 1035.
Parallèlement, dans le calculateur destinataire 20, la transition 2017 est alors validée lorsque le calculateur embarqué cible 20 reçoit la notification de fin de campagne émise par le calculateur embarqué client 10 à l’étape 1037. En l’espèce cette notification est acheminée au moyen du bus 5. Il convient de rappeler qu’à cette étape du procédé sont encore présents en mémoire externe du calculateur cible 20, le contenu numérique passé réactivé et le nouveau contenu numérique inactif. Une validation de la transition 2017 fait passer le procédé dans une étape 2018 qui consiste à effacer le contenu numérique nouveau de la mise à jour, désormais inactif à cette étape du procédé, pour ne garder donc que le contenu passé réactivé, et une fois cet effacement achevé à notifier le calculateur client 10 du statut « prêt pour une prochaine campagne » du calculateur cible 20.
A partir de l’étape 1037 exécutée dans le calculateur client 10, une transition 1038 est validée lorsque le calculateur client 10 reçoit la notification de statut « prêt pour une prochaine campagne » envoyée par le calculateur cible 20 à l’étape 2018.
Une validation de la transition 1038 fait passer le procédé dans une étape 1039 qui consiste à générer un rapport global d’échec de campagne, ce rapport une fois complet, étant alors transmis au serveur distant 101 ou 102 (non représenté sur la figure 6). Le rapport global d’échec de campagne généré à l’étape 1039 est mis à jour par agrégations successives des notifications reçues de chaque calculateur définis à l’étape 1035. Une fois que toutes les notifications de chaque calculateur 20, 21 (pour la passerelle 21 plusieurs notifications sont possibles puisque la mise à jour pouvait comprendre des contenus destinés à la passerelle en tant que telle (pour elle- même en tant que passerelle) et des contenus ayant une cible 30 ou 23), 23 définis à l’étape 1035 auront été envoyées, le rapport global généré à cette étape 1039 sera alors complet.
Après cette phase d’activation, réussie ou non, pour un premier type de calculateur, le calculateur client 10 retourne en étape de veille du procédé, de même pour le calculateur cible 20, puis s’éteindront.
[Fig. 7] montre des étapes de procédé conforme à l’invention pour effectuer l’activation d’un calculateur embarqué cible du deuxième type après installation. Les étapes à présent décrites sont également exécutées déconnectées du monde extérieur (off board en anglais). Plus précisément, la phase d’activation illustrée par la figure 7 est effectuée en vue de mettre à jour un deuxième type de calculateur embarqué 30 correspondant à l'un des calculateurs embarqués 31 , 32, 33 connecté au calculateur embarqué passerelle 21 , en l’espèce via le bus 6, et équipés chacun de ressources informatiques suffisantes pour traiter le contenu téléchargé qui lui est destiné.
Consécutivement à l’étape 1024 d’envoi d’une notification de fin d’installation des contenus numériques de la campagne de mise à jour du procédé par le calculateur embarqué 10 au module de gestion des configurations dynamiques, aussi appelé HMI proxy, localisé dans l’interface homme machine 12, qui peut elle-même être une partie du calculateur client 10, une transition 1025 est validée lorsque le véhicule 4 est dans les conditions d’activation requises par la campagne de mise à jour tel que défini pour ce contenu numérique dans le module de gestion.
Ces conditions sont issues des données descriptives pré téléchargées caractérisant chaque contenu numérique, tel que décrit précédemment. Par exemple, une condition satisfaisante pour effectuer l’activation de la mise à jour du calculateur du deuxième type 30 peut, comme précédemment décrit en figure 6, être générée par le fait pour le véhicule 4 d’être en fin de mission et une fois en fin de mission d’avoir demandé puis obtenu l'accord de l’utilisateur au moyen d’un bouton virtuel affiché sur IΊHM 12. En effet, cette demande utilisateur est préférée pour ce deuxième type de calculateur 30 car leur mise à jour est moins instantanée et nécessite de bloquer le redémarrage du moteur, ce qui nécessite d’alerter l’utilisateur. Ainsi, une fois l’accord utilisateur obtenu, on interdit le redémarrage moteur.
Une validation de la transition 1025 fait passer le procédé dans une étape 1026 qui consiste à déclencher l’activation du calculateur embarqué destinataire du contenu, à savoir le calculateur passerelle 21 puisque la cible est ici un calculateur de deuxième type 30 c’est-à-dire situé en zone sécurisée derrière la passerelle. En étape 1026, le calculateur embarqué client 10 commence par définir le calculateur embarqué destinataire 21 par lecture du contenu numérique téléchargé caractérisé par ses données descriptives qui contiennent cette indication, puis à émettre une requête d’activation au calculateur embarqué destinataire, ici passerelle 21. En effet, ici le calculateur cible devant être mis à jour par ce contenu numérique est du deuxième type 30, situé derrière la passerelle, le destinataire identifié du contenu numérique est donc la passerelle, le calculateur client 10 ignorant que la cible est un calculateur du deuxième type, à savoir l’un des calculateurs 31 , 32, 33 et de fait le calculateur destinataire à qui envoyer la requête d’activation est identifié comme étant le calculateur passerelle 21.
Parallèlement, dans le calculateur destinataire passerelle 21 , postérieurement à l’étape 2108 d’envoi du rapport, une transition 2111 est validée lorsque le calculateur passerelle 21 reçoit la requête d'activation émise par le calculateur embarqué client 10 à l’étape 1026 de déclenchement d’activation. A titre illustratif, le calculateur embarqué client 10 peut utiliser les protocoles CAN, FTP, Ethernet pour envoyer cette requête au calculateur destinataire 21 via le bus 5 embarqué, indépendamment du niveau de connectivité à un réseau de télécommunication puisque ces étapes sont exécutées déconnectées du monde extérieur.
Une validation de la transition 2111 fait passer le procédé dans une étape 2112 qui consiste essentiellement à déclencher l’activation du calculateur embarqué cible 30. En étape 2112, le calculateur embarqué passerelle 21 commence par définir le calculateur embarqué cible 30, en l’espèce par lecture de la liste de téléchargement qui prend par exemple la forme d’une table avec pour chaque ligne de calculateur le statut de la mise à jour, puis à émettre une requête d’activation au calculateur embarqué cible 30. En effet, ici le calculateur cible devant être mis à jour, c’est-à-dire dont le contenu numérique doit être activé, est du deuxième type 30, à savoir l’un des calculateurs 31 , 32, 33 relié indirectement au calculateur client 10 via le calculateur passerelle 21.
Parallèlement, à partir d’une étape de veille du procédé exécuté dans le calculateur embarqué cible 30 postérieure à l’étape 3004 d'installation, une transition 3011 est validée lorsque le calculateur passerelle 30 reçoit la requête d’activation émise par le calculateur passerelle 21 à l’étape 2112.
Une validation de la transition 3011 fait passer le procédé dans une étape 3012 qui consiste à activer le contenu numérique installé à l’étape 3004 dans le calculateur cible 30, puis notamment à notifier au calculateur passerelle 21 l’achèvement de l’activation, sachant que cette notification peut être une notification de réussite ou une notification d’échec de l’activation. L’activation consiste dans le cas de mémoire interne double banques à switcher de la banque active (courante) à la l’autre (contenant le nouveau contenu numérique) banque et dans le cas d’une mémoire externe à transférer le nouveau contenu numérique depuis la mémoire externe vers la mémoire interne. Il convient de rappeler que si c’est une mémoire externe dont dispose le calculateur 30, à cette étape du procédé le contenu numérique passé est toujours présent en mémoire externe (que l’activation du nouveau contenu, de remplacement, ait réussi ou non), celui- ci n’étant pas effacé, et si l’activation a réussi, ce nouveau contenu numérique, est aussi en mémoire active interne. Si le calculateur cible 30 dispose d’une mémoire interne double banque, par exemple EEPROM réinscriptible, cette mémoire contient dans la partie active le nouveau contenu ainsi que tout ce qui lui a été ajouté à l’étape 3004 et dans la partie inactive le contenu passé. En l’espèce, cette notification est acheminée au moyen du bus 6, par exemple par protocole FTP, CAN, Ethernet. La réception de cette notification par le calculateur passerelle 21 finalise l’étape 2112 avec un renvoi par le calculateur passerelle 21 au calculateur client 10 de la notification de réussite ou une notification d’échec de l’activation, le calculateur passerelle jouant ici un rôle de boîte aux lettres.
A partir de l’étape 1026 de déclenchement d’activation exécutée par le calculateur client 10, une transition 1027 est validée lorsqu’une notification de réussite de l’activation notifiée par le calculateur passerelle 21 à l’étape 2112, est reçue par le calculateur client 10. Une validation de la transition 1027 fait passer le procédé dans une étape 1028 qui consiste à générer un rapport interne d'activation, qui sera complété à chaque réception de notification afférente à un nouveau contenu numérique activé, et à vérifier s’il existe ou non un autre contenu numérique à installer dans le système numérique.
A partir de l’étape 1028 exécutée dans le calculateur client 10, une transition 1029 est validée s’il existe un autre contenu numérique à installer dans le système numérique, c’est-à-dire sur un calculateur embarqué quel qu’il soit. La transition 1029 est donc validée lorsqu’un autre contenu numérique à installer est détecté dans la liste des contenus numériques téléchargés. La validation de la transition 1029 fait reboucler le procédé à l’étape 1026.
S’il n’existe pas d’autre contenu numérique à installer dans le système numérique, c’est-à- dire qu’on vient d’installer le dernier contenu numérique de la liste des contenus numériques téléchargés, la transition 1030 est validée et fait passer le procédé dans une étape 1031 qui consiste pour le calculateur client 10 à envoyer une notification de fin de campagne de la mise à jour en cours au calculateur destinataire passerelle 21. C’est donc après l’activation réussie de tous les calculateurs cibles 20, 30, 23 de la liste, qu’est envoyée cette notification de fin de campagne à chacun des calculateurs destinataires 20, 21 , 23. Chacun des calculateurs (en l’espèce sauf le dernier) a donc attendu en veille de recevoir cette notification qui confirme la réussite de toutes les activations de la campagne de mise à jour. En effet, cette notification de fin de campagne ne peut pas être émise avant au cas où un des calculateurs ne réussirait pas son activation, comme cela sera expliqué par la suite.
A partir de l’étape 2112 de déclenchement d’activation exécutée par le calculateur passerelle 21 , une transition 2113 est validée lorsque la notification de fin de campagne, émise par le calculateur embarqué client 10 à l’étape 1031 , est reçue par le calculateur passerelle 21.
Une validation de la transition 2113 fait passer le procédé dans une étape 2114 qui consiste à émettre une notification de fin de campagne vers le calculateur cible 30.
Parallèlement, A partir de l’étape 3012 d’activation exécutée et réussie par le calculateur cible 30, une transition 3013 est validée lorsque le calculateur cible 30 reçoit la notification de fin de campagne envoyée par le calculateur passerelle 21 à l’étape 2114. Une validation de la transition 3013 fait passer le procédé dans une étape 3014 qui consiste à effacer (que ce soit dans la banque de la mémoire inactive interne ou en mémoire externe) le contenu numérique passé, désormais inactif à cette étape du procédé, et une fois cet effacement achevé à notifier le calculateur passerelle 21 du statut « prêt pour une prochaine campagne » du calculateur cible 30. La réception de cette notification du statut « prêt pour une prochaine campagne » par le calculateur passerelle 21 finalise l’étape 2114 avec un renvoi par le calculateur passerelle 21 au calculateur client 10 du statut « prêt pour une prochaine campagne », le calculateur passerelle jouant ici un rôle de boîte aux lettres. Il convient de rappeler qu’en mémoire interne EEPROM, une banque non vidée n’est pas réinscriptible, d’où l’importance de l’effacement pour une prochaine campagne de mise à jour.
A partir de l’étape 1031 d’envoi de notification de fin de campagne exécutée dans le calculateur client 10, une transition 1032 est validée lorsque le calculateur client 10 reçoit la dernière notification du statut « prêt pour une prochaine campagne » envoyée par le dernier calculateur de la liste à l’étape 2114 ou 2014.
Une validation de la transition 1032 fait passer le procédé dans une étape 1033 qui consiste à générer un rapport global de réussite de campagne, le rapport généré étant mis à jour par agrégations successives à chaque statut « prêt » de calculateur cible 20 ou destinataire 21 . Une fois que toutes les notifications de chaque calculateur 20, 30, 23 de la liste auront été envoyées, le rapport global généré à cette étape 2014 sera complet, ce rapport étant ensuite transmis au serveur distant 101 ou 102 (non représenté sur la figure 7).
En revanche dès qu’une activation se solde par un échec à l’étape 3012 pour un calculateur cible 30, l’étape 2112 se finalise par un renvoi de notification d’échec de l’activation par le calculateur passerelle 21 au calculateur client 10 et à partir de l’étape 1026 de déclenchement d’activation exécutée par le calculateur client 10, une transition 1034 est validée dès que la notification d’échec de l’activation est reçue par le calculateur client 10
Une validation de la transition 1034 fait passer le procédé dans une étape 1035 qui consiste à déclencher un retour en arrière général de tous les calculateurs du système numérique faisant l’objet de la campagne de mise à jour. Par retour en arrière général, on entend retour à l’état initial avant le début de la campagne En étape 1035, le calculateur embarqué client 10 commence par définir tous les calculateurs embarqués destinataires faisant l’objet de la campagne de mise à jour, puis à émettre une requête de retour en arrière à chacun de ces calculateurs embarqués destinataires 20, 21, 23 définis. En l’espèce, le calculateur cible est du second type 30 mais le calculateur client 10 sait seulement que le destinataire défini est le calculateur passerelle 21, la requête de retour est donc envoyée au calculateur passerelle 21 A partir de l’étape 2112 de déclenchement d’activation exécutée par le calculateur passerelle 21 , une transition 2115 est validée lorsque la requête de retour, émise par le calculateur embarqué client 10 à l’étape 1035, est reçue par le calculateur passerelle 21 .
Une validation de la transition 2115 fait passer le procédé dans une étape 2116 qui consiste d’abord à déclencher le retour en arrière du calculateur cible 30 par émission d’une requête de retour en arrière au calculateur cible 30 (sera donc émise séquentiellement en suivant le procédé à chaque calculateur cible 30 défini à l’étape 1035). Parallèlement, dans le calculateur cible 30, la transition 3015 est validée lorsque le calculateur cible 30 reçoit la requête de retour en arrière émise par le calculateur passerelle 21 à l’étape 2116. En l’espèce cette requête est acheminée au moyen du bus 6. Une validation de la transition 3015 fait passer le procédé dans une étape 3016 qui consiste à effectuer le retour en arrière, rendant donc inactif le contenu numérique nouveau s’il ne l’était pas déjà, et une fois ce retour en arrière achevé à le notifier au calculateur passerelle 21 par envoi d’un rapport de retour à l’état initial. Ce retour en arrière se fait par commutation, ce qui rebascule sur l’autre banque, en cas de mémoire interne double banque et par restauration du contenu numérique sauvegardé en cas de mémoire externe. La réception de ce rapport de retour à l’état initial par le calculateur passerelle 21 finalise l’étape 2116 avec un renvoi par le calculateur passerelle 21 au calculateur client 10 du rapport de retour à l'état initial, le calculateur passerelle 21 jouant ici un rôle de boîte aux lettres.
A partir de l’étape 1035 de déclenchement de retour en arrière exécutée dans le calculateur client 10, une transition 1036 est validée lorsque le calculateur client 10 reçoit le rapport de retour à l’état initial envoyé par le calculateur passerelle 21 à l’étape 2116
Une validation de la transition 1036 fait passer le procédé dans une étape 1037 qui consiste à générer un rapport d’échec de campagne qui sera complété par agrégations successives à chaque réception de rapport de retour à l’état initial (provenant de chaque calculateur défini à l’étape 1035), puis une fois que toutes les notifications de tous les calculateurs cibles définis à l’étape 1035 auront été reçues, le rapport d’échec de campagne généré à cette étape 1037 sera complet, et la notification de fin de campagne envoyée à chacun des calculateurs destinataires définis à l’étape 1035. En l’espèce, pour un calculateur de deuxième type, une fois ce rapport complet (c’est-à-dire une fois que tous les calculateurs définis à l’étape 1035 sont revenus à l’état initial) on notifie au calculateur destinataire passerelle 21 la fin de campagne
Parallèlement, dans le calculateur destinataire 21 , la transition 2117 est alors validée lorsque le calculateur embarqué destinataire passerelle 21 reçoit la notification de fin de campagne émise par le calculateur embarqué client 10 à l’étape 1037. En l’espèce cette notification est acheminée au moyen du bus 5.
Une validation de la transition 2117 fait passer le procédé dans une étape 2118 qui consiste d’abord à envoyer une requête d’effacement du contenu numérique nouveau de la mise à jour, désormais inactif à cette étape du procédé, pour ne garder donc que le contenu passé réactivé (initial avant la mise à jour). Parallèlement, dans le calculateur cible 30, la transition 3017 est validée lorsque le calculateur cible 30 reçoit la requête de retour en arrière émise par le calculateur passerelle 21 à l’étape 2118. En l’espèce cette requête est acheminée au moyen du bus 6. Une validation de la transition 3017 fait passer le procédé dans une étape 3018 qui consiste à effacer le nouveau contenu numérique de la mise à jour s’il ne l’était pas déjà, et une fois cet effacement achevé à le notifier au calculateur passerelle 21 par envoi d’un statut « prêt pour une prochaine campagne ». La réception de ce statut « prêt » par le calculateur passerelle 21 finalise l’étape 2118 avec un envoi par le calculateur passerelle 21 au calculateur client 10 du statut « prêt pour une prochaine campagne » du calculateur cible 30, le calculateur passerelle 21 jouant ici un rôle de boîte aux lettres.
A partir de l’étape 1037 exécutée dans le calculateur client 10, une transition 1038 est validée lorsque le calculateur client 10 reçoit la notification de statut « prêt pour une prochaine campagne » envoyée par le calculateur passerelle 21 à l’étape 2118.
Une validation de la transition 1038 fait passer le procédé dans une étape 1039 qui consiste à générer un rapport global d’échec de campagne, ce rapport une fois complet, étant alors transmis au serveur distant 101 ou 102 (non représenté sur la figure 7) et à relâcher l’interdiction de redémarrage. Le rapport global d’échec de campagne généré à l’étape 1039 est mis à jour par agrégations successives des notifications reçues de chaque calculateur définis à l’étape 1035.
Une fois que toutes les notifications de chaque calculateur 20, 21 (pour la passerelle 21 plusieurs notifications sont possibles puisque la mise à jour pouvait comprendre des contenus destinés à la passerelle en tant que telle (pour elle-même en tant que passerelle) et des contenus ayant une cible 30 ou 23), 23 définis à l’étape 1035 auront été envoyées, le rapport global généré à cette étape 1039 sera alors complet.
Après cette phase d’activation, réussie ou non, pour un deuxième type de calculateur, le calculateur client 10 retourne en étape de veille du procédé, de même pour le calculateur passerelle 21 et cible 30, puis s’éteindront. Dans le cas de la phase d’activation d’un calculateur du troisième type, c’est-à-dire hybride, la logique telle que présentée en figure 5 s’applique.
Quel que soit le type de calculateur, en fin de phase d’activation réussie, le contenu numérique passé a été effacé de manière à être prêt pour une prochaine campagne et pour empêcher pour des raisons de sécurité tout retour à la version précédente.
De manière générale, quand une étape du procédé ne se termine pas comme attendu, le procédé reste bloqué dans cette étape et une temporisation peut être prévue, par exemple dans le calculateur client 10 ou passerelle 21 , à l’issue duquel un échec est détecté pour alors initier une remise à l’état initial de tout le système numérique, tel que défini précédemment, avec notification de l’échec au serveur.

Claims

REVENDICATIONS
1 . Procédé de mise à jour de système numérique dans un véhicule (4) comprenant un calculateur client embarqué (10) , notamment de type multimédia, apte à communiquer avec un serveur distant (101 , 102), une unité de contrôle-commande embarquée ( 20, 11 , 21 , 22, 30, 31 , 32, 33, 23) connectée, directement ou indirectement, au calculateur client (10) par un réseau embarqué de communication (5, 6, 7, 8), et un dispositif d’accumulation d’énergie électrique pour alimenter le calculateur embarqué (10) et ladite unité de contrôle-commande embarquée (20, 11 , 21 , 22, 30, 31 , 32, 33, 23), caractérisé en ce qu’il comprend des étapes de :
- téléchargement (1008) dans laquelle le calculateur client (10) télécharge un fichier à partir du serveur distant à condition que le dispositif d’accumulation d'énergie électrique est en état de pouvoir être rechargé ;
- distribution (1016) dans laquelle le calculateur client (10) distribue, directement ou indirectement, au moins une partie du fichier téléchargé à destination de l’unité de contrôle-commande embarquée ( 20, 11 , 21 , 22, 30, 31 , 32, 33, 23) ;
- installation (2004, 3004) dans laquelle tout ou portion de ladite au moins une partie distribuée du fichier téléchargé est installée dans l’unité de contrôle-commande embarquée (20, 11 , 21 , 22, 30, 31 , 32, 33, 23) ;
- activation (2012, 3012) dans laquelle l’unité de contrôle-commande embarquée (20, 11 , 21 , 22, 30, 31 , 32, 33, 23) active la ou les portions de fichier installées après mise à l’arrêt du véhicule.
2. Procédé selon la revendication 1 , caractérisé en ce que dans l’étape de téléchargement (1008), le calculateur client (10) mémorise constamment un point de progression du téléchargement de manière à arrêter (1010) le téléchargement lorsqu’une dégradation effective ou risquée de communication avec le serveur distant (101 , 102) est détectée (1009), et reprend (1008) le téléchargement à partir du point de progression mémorisé lorsqu’il détecte (1011) une disparition de dégradation effective ou risquée de communication avec le serveur distant (101 , 102).
3. Procédé selon la revendication 2, caractérisé en ce que le dispositif d’accumulation d’énergie électrique hors d’état de pouvoir être rechargé constitue une condition de détection de dégradation risquée de communication avec le serveur distant (101 , 102).
4. Procédé selon l’une des revendications 1 à 3, caractérisé en ce que, lorsque le véhicule (4) comprend un moteur thermique, le dispositif d’accumulation d’énergie électrique est considéré en état de pouvoir être rechargé si le moteur thermique est en rotation.
5. Procédé selon l’une des revendications 1 à 4, caractérisé en ce que, lorsque le véhicule comprend une batterie de traction électrique, le dispositif d'accumulation d’énergie électrique est considéré en état de pouvoir être rechargé si la batterie de traction électrique batterie de traction électrique est branchée sur un réseau électrique de rechargement externe.
6. Procédé selon l’une des revendications 1 à 5, dans lequel le réseau embarqué de communication (5, 6, 7, 8) comporte une première liaison embarquée (5, 7) reliée au calculateur client (10), une deuxième liaison embarquée (6,8) reliée à l’unité de contrôle- commande embarquée (30, 31 , 32, 33, 23), et un calculateur passerelle (21) relié au calculateur client (10) et à l’unité de contrôle-commande embarquée (30, 31 , 32, 33, 23)), caractérisé en ce que l’étape d’installation (3004) de tout ou partie distribuée du fichier téléchargé dans l’unité de contrôle-commande embarquée (21), est exécutée par le calculateur passerelle (21 ).
7. Procédé selon l’une des revendications 1 à 6, dans lequel l’unité de contrôle-commande embarquée comprend deux banques de mémoire réinscriptible exécutable, caractérisé en ce que l’unité de contrôle-commande embarquée fonctionne sur une première banque de mémoire réinscriptible pendant que l’étape d’installation est appliquée sur une deuxième banque de mémoire réinscriptible.
8. Procédé selon au moins l’une des revendications 1 à 7, caractérisé en ce qu’il comporte une étape de pré téléchargement (1002) de données descriptives.
9. Procédé selon la revendication précédente caractérisé en ce qu’au moins une partie des données descriptives comporte des métadonnées de configuration.
10. Procédé selon la revendication précédente, caractérisé en ce qu’il comporte au moins une étape (1024) de vérification d’au moins une condition d’activation, ladite au moins une condition d’activation étant fonction d’au moins une partie des métadonnées de configuration.
11. Procédé selon l’une quelconque des revendications précédentes, caractérisé en ce que l’étape d’activation (2012, 3012) nécessite un accord d’un utilisateur du véhicule pour être exécutée.
PCT/EP2020/083141 2019-11-29 2020-11-24 Procédé de mise à jour de système numérique WO2021105089A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN202080084016.9A CN114746838A (zh) 2019-11-29 2020-11-24 用于更新数字系统的方法
US17/776,630 US11928458B2 (en) 2019-11-29 2020-11-24 Method for updating a digital system
KR1020227022355A KR20220108129A (ko) 2019-11-29 2020-11-24 디지털 시스템을 업데이트하는 방법
EP20808154.7A EP4066103A1 (fr) 2019-11-29 2020-11-24 Procédé de mise à jour de système numérique
JP2022529428A JP2023503288A (ja) 2019-11-29 2020-11-24 デジタルシステムを更新するための方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1913530A FR3103926B1 (fr) 2019-11-29 2019-11-29 Procédé de mise à jour de système numérique.
FRFR1913530 2019-11-29

Publications (1)

Publication Number Publication Date
WO2021105089A1 true WO2021105089A1 (fr) 2021-06-03

Family

ID=69811119

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/083141 WO2021105089A1 (fr) 2019-11-29 2020-11-24 Procédé de mise à jour de système numérique

Country Status (7)

Country Link
US (1) US11928458B2 (fr)
EP (1) EP4066103A1 (fr)
JP (1) JP2023503288A (fr)
KR (1) KR20220108129A (fr)
CN (1) CN114746838A (fr)
FR (1) FR3103926B1 (fr)
WO (1) WO2021105089A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115136122A (zh) * 2020-02-19 2022-09-30 株式会社电装 主装置、数据分发系统以及更新控制程序
JP7463870B2 (ja) * 2020-06-12 2024-04-09 株式会社オートネットワーク技術研究所 車載装置、車載通信システムおよび通信制御方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2775371A1 (fr) 1998-02-26 1999-08-27 Peugeot Procede de deverrouillage de l'acces d'un outil de telechargement d'un fichier, a un calculateur
FR2775363A1 (fr) 1998-02-26 1999-08-27 Peugeot Calculateur de pilotage du fonctionnement d'un organe fonctionnel de vehicule automobile
EP2249251A1 (fr) 2002-12-19 2010-11-10 Komatsu Ltd. Dispositif de contrôle de réécriture pour un programme embarqué
FR3011651A1 (fr) 2013-10-04 2015-04-10 Renault Sa Procede de mise a jour d'un calculateur de vehicule utilisant un boitier d'interface et boitier d'interface correspondant
DE102017217807A1 (de) * 2017-10-06 2019-04-11 Bayerische Motoren Werke Aktiengesellschaft Verfahren und vorrichtung zum verarbeiten einer software-aktualisierung

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2874765B1 (fr) * 2004-08-31 2007-02-09 Valeo Equip Electr Moteur Module de commande et de puissance pour une machine electrique tournante
JP6155888B2 (ja) * 2013-06-19 2017-07-05 株式会社リコー 通信装置、通信システム、通信方法及び通信プログラム
WO2016196106A1 (fr) * 2015-05-29 2016-12-08 Nike, Inc. Mise à jour de micrologiciel de dispositif de données d'activité sportive
JP6197000B2 (ja) * 2015-07-03 2017-09-13 Kddi株式会社 システム、車両及びソフトウェア配布処理方法
JP7013918B2 (ja) * 2018-02-16 2022-02-01 トヨタ自動車株式会社 車両制御装置、プログラム更新方法およびプログラム
US11561789B2 (en) * 2019-02-22 2023-01-24 Honda Motor Co., Ltd. Software update device, vehicle, and software update method
US11230187B2 (en) * 2019-10-28 2022-01-25 GM Global Technology Operations LLC Close-out assembly and a method of manufacturing the close-out assembly
KR20220001924A (ko) * 2020-06-30 2022-01-06 현대자동차주식회사 차량의 ecu 업데이트 제어 장치 및 그 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2775371A1 (fr) 1998-02-26 1999-08-27 Peugeot Procede de deverrouillage de l'acces d'un outil de telechargement d'un fichier, a un calculateur
FR2775363A1 (fr) 1998-02-26 1999-08-27 Peugeot Calculateur de pilotage du fonctionnement d'un organe fonctionnel de vehicule automobile
EP2249251A1 (fr) 2002-12-19 2010-11-10 Komatsu Ltd. Dispositif de contrôle de réécriture pour un programme embarqué
FR3011651A1 (fr) 2013-10-04 2015-04-10 Renault Sa Procede de mise a jour d'un calculateur de vehicule utilisant un boitier d'interface et boitier d'interface correspondant
DE102017217807A1 (de) * 2017-10-06 2019-04-11 Bayerische Motoren Werke Aktiengesellschaft Verfahren und vorrichtung zum verarbeiten einer software-aktualisierung

Also Published As

Publication number Publication date
US11928458B2 (en) 2024-03-12
JP2023503288A (ja) 2023-01-27
US20220405085A1 (en) 2022-12-22
FR3103926A1 (fr) 2021-06-04
KR20220108129A (ko) 2022-08-02
FR3103926B1 (fr) 2021-11-05
CN114746838A (zh) 2022-07-12
EP4066103A1 (fr) 2022-10-05

Similar Documents

Publication Publication Date Title
WO2021105089A1 (fr) Procédé de mise à jour de système numérique
EP2786247A1 (fr) Système de fourniture de services télématiques et procédé correspondant
WO2001099448A1 (fr) Procede pour le traitement et la transmission de donnees sur un reseau de telephonie mobile et systeme embarque a puce electronique
WO2015121418A2 (fr) Procédé de déploiement d'un ensemble d'application(s) logicielle(s)
FR2998689A1 (fr) Ensemble electronique comprenant un module de desactivation
WO2005008509A2 (fr) Procede de gestion des composants logiciels integres dans un systeme embarque
FR3096153A1 (fr) Procédé et dispositif de retour à un état précédent une mise à jour logicielle d’un calculateur d’un véhicule à distance
WO2006072747A1 (fr) Dispositif de connexion automatique au reseau internet
WO2021014064A1 (fr) Procédé et dispositif de mise à jour d'un logiciel d'un calculateur embarqué d'un véhicule, comportant une mémoire d'exécution, une mémoire de sauvegarde et une mémoire de contrôle
EP4036717A1 (fr) Démarrage d'une application
WO2022180323A1 (fr) Procédé de contrôle d'une grappe de noeuds esclave par une grappe de noeuds maître, dispositifs et programmes d'ordinateurs correspondants
WO2022064118A1 (fr) Procédé et dispositif de mise à jour d'un logiciel d'un calculateur embarqué d'un véhicule, comportant une mémoire d'exécution, une mémoire de sauvegarde et une mémoire de contrôle
EP3991029A1 (fr) Procédé de dialogue avec un calculateur sur bus embarqué de véhicule
FR3108191A1 (fr) Procédé et dispositif de mise à jour d’un logiciel comportant des adresses physiques vers la mémoire d’un calculateur embarqué d’un véhicule
FR3041782A1 (fr) Procede de reveil d'un calculateur, notamment pour un systeme de charge de batterie de vehicule hybride
FR3114415A1 (fr) Procédé et dispositif de mise à jour d’un logiciel d’un calculateur embarqué d’un véhicule, comportant une mémoire d’exécution et une mémoire de sauvegarde
FR3144331A1 (fr) Gestion de service d’exécution de logiciels utilisant des véhicules automobiles
FR3099265A1 (fr) Procédé et dispositif de mise à jour d’un logiciel d’un calculateur embarqué d’un véhicule, comportant une mémoire d’exécution, une mémoire de sauvegarde et une mémoire de contrôle
FR3099264A1 (fr) Procédé et dispositif de mise à jour d’un logiciel d’un calculateur embarqué d’un véhicule, comportant une mémoire d’exécution et une mémoire de sauvegarde
EP1825441B1 (fr) Unite de tachygraphe electronique pour vehicule automobile
FR2966263A1 (fr) Procede de controle d'un circuit integre, circuit integre et calculateur comportant un circuit integre
FR3103073A1 (fr) Serveur multimedia destine a etre embarque a bord d'un aeronef, systeme electronique de divertissement comprenant un tel serveur, procede de configuration logicielle d'un tel serveur et programme d'ordinateur associe
FR3100638A1 (fr) Procédé et dispositif de mise à jour d’un calculateur cible à partir d’un script interprété
EP4018347A1 (fr) Procédé et dispositif de mise à jour d'un logiciel d'un calculateur embarqué d'un véhicule, comportant une mémoire d'exécution et une mémoire de sauvegarde
WO2024105327A1 (fr) Procede et dispositif de controle d'au moins un dispositif embarque dans un aeronef

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20808154

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022529428

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 20227022355

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020808154

Country of ref document: EP

Effective date: 20220629