How to update vehicle software, update programs, and update systems.

Abstract

This prevents update failures caused by memory write limits and ensures the integrity of related functions. [Solution] A method for updating vehicle software includes: (1) receiving a software update request stored in the ECU's memory M; (2) identifying the software group to be updated based on the software group's compatibility information; and (3) determining that a software update can be performed if the number of writes in all of the memories where the software group is stored is below a certain threshold, while determining not to perform a software update if the number of writes in any of the memories where the software group is stored has reached a certain threshold.

Description

Technical Field

[0001] The technology disclosed herein belongs to the technical field related to a method for updating software for vehicles, an update program for software for vehicles, or an update system for software for vehicles.

Background Art

[0002] In the IoT field, software updates via OTA (Over The Air) are common and have also been introduced in in-vehicle ECUs (Electronic Control Units).

[0003] For example, Patent Document 1 discloses a software update system for managing software updates of in-vehicle devices via OTA. In Patent Document 1, a server distributes update software for a control device to a software update device based on the priority for software updates of the control device. The software update device updates the software of the control device using the update software distributed from the server.

[0004] Also, Patent Document 2 discloses a software management device that manages the version of software for in-vehicle devices by a version management unit, and an update confirmation processing unit determines whether there is updatable software using communication with a server, vehicle-to-vehicle communication, roadside-to-vehicle communication, etc. In Patent Document 2, when the software is updatable, the timing of notification and / or processing regarding software updates is selected based on the importance in vehicle driving during the update.

Prior Art Documents

Patent Documents

[0005]

Patent Document 1

Patent Document 2

Summary of the Invention

[0006] Incidentally, in vehicle ECUs, software is stored in rewritable non-volatile memory. Generally, non-volatile memory (e.g., flash memory) has a set limit on the number of write cycles, and exceeding this limit increases the likelihood of write errors. In such cases, an OTA update of the vehicle may reach the limit of the number of write cycles of the non-volatile memory, potentially causing the update to fail. In particular, there are many vehicle ECUs, and ensuring consistency and proper functioning between each ECU presents challenges.

[0007] The technology disclosed herein was developed in view of these points, and its purpose is to prevent update failures caused by memory rewrite limits and to ensure the integrity of related functions. [Means for solving the problem]

[0008] To solve the aforementioned problems, the technology disclosed herein relates to a method for updating software for a vehicle equipped with multiple ECUs (Electronic Control Units), and includes: receiving a software update request stored in the memory of the ECUs; identifying a group of software to be updated in response to the update request based on compatibility information of a group of software used to realize a predetermined function; and determining that a software update based on the update request can be performed if the number of writes in all of the memories where the group of software is stored among the multiple ECUs is below a predetermined threshold value, while determining not to perform a software update based on the update request if the number of writes in any of the memories where the group of software is stored has reached a predetermined threshold value. [Effects of the Invention]

[0009] The technology disclosed herein makes it possible to prevent update failures caused by memory rewrite limits and to ensure the integrity of related functions. [Brief explanation of the drawing]

[0010] [Figure 1] Block diagram showing the functional configuration of the software update process for a vehicle according to the embodiment. [Figure 2] A flowchart illustrating the overall process of updating vehicle software. [Figure 3] A flowchart illustrating an example of a vehicle software update process. [Figure 4] A flowchart illustrating an example of the process for updating package data information. [Figure 5] A diagram showing an example of package data. [Figure 6] This diagram illustrates an example of how to determine whether an update can be performed based on priority and the number of memory write cycles. [Figure 7] A flowchart illustrating an example of the operation of the count calculation module. [Figure 8] Block diagram showing an example hardware configuration for a software update system. [Figure 9] Block diagram showing other hardware configuration examples for a software update system. [Figure 10] Block diagram showing another example of the functional configuration for vehicle software update processing. [Modes for carrying out the invention]

[0011] The following describes exemplary embodiments in detail with reference to the drawings.

[0012] The following embodiments are illustrative, and there is no intention to limit the content of this disclosure by the presence or absence of descriptions or by the numerical values ​​provided as examples. Furthermore, the components constituting the systems, servers, etc., described herein, and the functions realized by the components such as functional blocks and modules described herein, may be implemented in circuitry or processing circuitry, including general-purpose processors such as CPUs (Central Processing Units) and GPUs (Graphics Processing Units), application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), conventional circuits, and / or combinations thereof, programmed to realize the described functions. A processor includes transistors and other circuits and is considered circuitry or processing circuitry. A processor may be configured to execute a program stored in memory. Memory includes, for example, volatile memory such as RAM, and non-volatile semiconductor memory such as ROM and flash memory.

[0013] 1. Overview of how to update the software Figure 1 is a block diagram illustrating an overview of a vehicle software update method according to this embodiment. Figure 1 primarily illustrates the functional configuration showing the software update method, and generally omits the hardware configuration. For example, as shown in Figure 6 later, the vehicle V is equipped with multiple ECUs (Electronic Control Units). Each of the multiple ECUs has a memory M that allows for software rewriting.

[0014] The memory M is, for example, a non-volatile memory. The non-volatile memory is, for example, a flash memory. The flash memory has an upper limit value for the number of rewrite times. Note that the memory M is not limited to the flash memory and may be other memories with an upper limit on the number of rewrite times. In the example of FIG. 1, the illustration of the ECU is omitted, and only the memory M is illustrated. Specifically, in the example of FIG. 1, as the memory M that can be a target of software update, memories M1 to M4 are exemplified. The memories M1 to M4 are implemented in, for example, different ECUs 1 to 4 as illustrated in FIG. 8 or FIG. 9.

[0015] The software update method is, for example, executed by the update execution determination module 1. As described above, each function realized by the update execution determination module 1 is realized by a general-purpose processor such as a CPU or a GPU or a specific-purpose processor programmed to realize those functions. Although a hardware configuration example will be described in detail later, the update execution determination module 1 may be provided inside the vehicle, or some of its functions may be realized by an external computer or an external server provided outside the vehicle.

[0016] Hereinafter, a specific example of the software update method for a vehicle executed by the update execution determination module 1 will be described. FIG. 3 is a flowchart showing the software update process (software update method).

[0017] 1-1. Update request In step S21, in the update execution determination module 1, a process is performed in which an update request RQ of software stored in the memory of the ECU is received. Specifically, an update request RQ is issued to the update execution determination module 1. When the update execution determination module 1 receives the update request RQ, it starts the software update process. In step S21, when the update execution determination module 1 receives a software update request, that is, when there is a reception of a software update request, the flow proceeds to the next step S22.

[0018] The update request RQ may include update data. The update data is specifically data for the update corresponding to the update request RQ. The update data may be in a form received after it is determined that the update described later is to be performed.

[0019] An update request (RQ) may include information on the update priority. The update priority may include multiple levels. Furthermore, the update priority may be managed in a score format based on predetermined criteria. In the example shown in Figure 6 below, the update priority has three levels: "high," "medium," and "low." A "high" priority includes, for example, "updates that, without which the normal operation of the vehicle would be impaired." More specifically, this includes, for example, bug fixes for software. A "medium" priority includes, for example, updates to functions related to driving. Specifically, this includes updates to memory related to the control of driving, steering, and braking. More specifically, a "medium" priority includes updates to driving control, steering control, or braking control aimed at "improving fuel efficiency," "improving driving performance," and "achieving driving, steering, or braking that improves occupant comfort." A "low" priority is an update that is unlikely to directly affect the vehicle's operation itself. For example, this includes updates to vehicle body-related functions, sound, lighting, etc. More specifically, examples of low-priority features include "power window raising and lowering function" and "turn signal flashing control."

[0020] An update request (RQ) may include software version information. An update request (RQ) may also include compatibility information between different software versions. Compatibility information includes information indicating the compatibility between software used to implement a given function. In other words, software components that are deemed compatible by compatibility information must be updated together, or it is recommended that they be updated together. The software components associated by compatibility information may all be stored in the memory of a single ECU, or they may be distributed across the memories of multiple ECUs.

[0021] In the example diagram, firmwares that are considered compatible according to compatibility information are given a common hatching. Firmware is an example of software. Specifically, firmware FW11 stored in memory M1 and firmware FW23 stored in memory M2 are associated with each other by compatibility information. Firmware FW21 stored in memory M2 and firmware FW33 stored in memory M3 are associated with each other by compatibility information. Firmware FW22 stored in memory M2, firmware FW32 stored in memory M3, and firmware FW42 stored in memory M4 are associated with each other by compatibility information. Firmware FW31 stored in memory M3 and firmware FW41 stored in memory M4 are associated with each other by compatibility information. In other words, firmware FW11 and firmware FW23 constitute a firmware group (equivalent to a software group). Similarly, firmware FW21 and firmware FW33 constitute a firmware group, firmware FW22, firmware FW32, and firmware FW42 constitute a firmware group, and firmware FW31 and firmware FW41 constitute a firmware group. The data format for compatibility information can be any format, as long as it allows for understanding compatibility. For example, software version information may be used to manage the compatibility between different software programs.

[0022] Compatibility information may be managed as package data. Package data may be linked to the version information of each software. Package data may associate software with related functions. Package data may associate software with related functions using the version information of each software. Package data may be pre-registered, or package data may be input or updated from an external source. Package data may also be generated by the update execution decision module 1. Specifically, as shown in Figure 2, the operation of the entire software update system may involve updating the package information and then making a decision to execute the software update as described using the flow in Figure 3. Note that the package information update (step S1) in Figure 2 is not an essential component of this disclosure.

[0023] Figure 4 shows an example of the package data information update process described in step S1 of Figure 2. When a request is made to refer to package data or software version information, the version information is retrieved from the data storage unit 13 and issued (steps S11, S12). When new package data is received, that information is stored in the data storage unit 13 (steps S13, S14). When a package update is performed, i.e., an OTA update is performed, the applied package data is stored in the data storage unit 13 (steps S15, S16). Note that the data storage unit 13 can be any storage area (e.g., memory) that the update execution decision module 1 can refer to, and the specific hardware configuration is not particularly limited. The same applies to the data storage unit 14, which will be described later.

[0024] 1-2. Memory write count information Returning to Figure 3, in step S22, the update execution decision module 1 refers to the registered memory rewrite count information. The update execution decision module 1 includes a calculation module 12 that calculates the memory rewrite count.

[0025] The flowchart in Figure 7 shows an example of the operation of the computing module 12. In step S221, the computing module 12 receives information about the memory subject to the update request (hereinafter referred to as "update target memory") and the capacity information required for the update. Once the update target memory information and the capacity information required for the update are received, the flow proceeds to the next step S222. In step S222, the computing module 12 calculates the number of memory rewrites from the capacity information required for the update. The computing module 12 refers to the number of rewrites to date stored in the storage unit and adds the calculated rewrite count to obtain the new number of memory rewrites. In the next step S223, the computing module 12 stores the new number of memory rewrites calculated in step S222 in the data storage unit 14. The number of write cycles for the memory targeted for the update is added to the number of write cycles already held (to date).

[0026] 1-3. Decision on implementing the update In step S23 of Figure 3, the update execution decision module 1 determines whether the memory M is capable of performing the update. Specifically, first, the update execution decision module 1 identifies the software group to be updated in response to the update request based on compatibility information. If package data is stored in the memory unit, the software group to be updated may be identified based on the package data.

[0027] Next, the update execution decision module 1 determines that it will perform a software update based on the update request RQ if the number of write cycles of all memories where the software group is stored is below a predetermined threshold. On the other hand, if the number of write cycles of any memory M where the software group is stored has reached a predetermined threshold, it determines that it will not perform a software update based on the update request RQ.

[0028] The predetermined reference value is set with a predetermined margin relative to the upper limit of the number of write cycles for each memory. The size of the predetermined margin is not particularly limited and can be set arbitrarily. Furthermore, the size of the predetermined margin may be set to a fixed value or may be configured to be updatable. For example, if update requests are assigned priorities, the predetermined reference value may be set so that the higher the priority, the higher the upper limit of the number of write cycles allowed for the memory. Figure 6 shows an example of determining whether or not to perform an update based on priority and the number of write cycles for the memory.

[0029] In Figure 6, when the update priority is set to "low," and the number of memory writes is small, the update execution decision module 1 decides to perform the software update based on the update request. On the other hand, when the update priority is set to "low," and the number of memory writes is moderate or large, the update execution decision module 1 decides not to perform the software update based on the update request. In other words, the predetermined threshold value that serves as the basis for deciding whether to perform the update is set relatively low. To put it another way, the predetermined margin is relatively large relative to the upper limit of the number of memory writes.

[0030] When the update priority is set to "medium," the update execution decision module 1 decides to perform the software update based on the update request when the number of memory writes is low or moderate. On the other hand, when the update priority is set to "medium," the update execution decision module 1 decides not to perform the software update based on the update request when the number of memory writes is high. In other words, a predetermined threshold value that serves as the basis for deciding whether to perform an update is set to an intermediate value between the "low" and "high" priority levels. To put it another way, a predetermined margin is set to a moderate level relative to the upper limit of the number of memory writes.

[0031] When the update priority is set to "high," the update execution decision module 1 will decide to perform the software update based on the update request, even if the memory has been rewritten many times. In other words, the predetermined threshold value that serves as the basis for deciding whether to perform the update is set higher than when the priority is set to "low" or "medium." To put it another way, the predetermined margin relative to the upper limit of the number of memory rewrites is smaller than when the priority is set to "low" or "medium."

[0032] 1-4. Collecting version control information In step S24 of Figure 3, the update execution decision module 1 refers to the version information of the software targeted by the update request. If the requested update version matches the current version, it is deemed not to be subject to update. In other words, the update execution decision module 1 terminates the update process without performing the software update based on the update request. If there are other update requests, it performs the process in step S21. If there are no other update requests, the update execution decision module 1 remains in a waiting state until the next update request arrives. Note that "1-4. Collection of version management information" is not an essential element in the vehicle software update method. If the processes after "1-4. Collection of version management information" are not performed, the update execution decision module 1 sends update data (hereinafter also referred to as "effective update data") and update target information, including update capacity information, corresponding to each memory M, to the update target memory that is the target of the update request, based on the decision result in "1-3. Decision to perform the update". Memory M that receives the effective update data performs the update using that effective update data.

[0033] 1-5. Determining the suitability of the package In step S25 of Figure 3, the update execution decision module 1 determines whether there is a package suitable for the update based on the update request. For example, in "1-3. Decision to execute update", the update execution decision module 1 may determine whether there is a package suitable for the update based on the information of memory M that can be updated and the version information referenced in "1-4. Collection of version control information". If a suitable package exists, the flow proceeds to the next step S26. On the other hand, if no suitable package exists, it is determined that the software update related to the update request cannot be performed, and the process ends.

[0034] Figure 5 shows an example of package data. The package data includes the package version number and the version information of each associated firmware. In addition to firmware FW22, FW32, and FW42 shown in Figure 1, firmware Fwa and FWb, which are not shown in Figure 1, are also registered as package data. The version information of each firmware FW22, FW32, FW42, Fwa, and FWb is stored linked to the package version information. In Figure 5, in the initial package (Ver1.00), all firmware versions FW22, FW32, FW42, Fwa, and FWb are Ver1.00. In the currently applied Ver1.10, FW32, Fwa, and FWb are Ver1.10. In other words, this example shows that when updating a package from Ver1.00 to Ver1.10, FW32, Fwa, and FWb must also be updated to Ver1.10 simultaneously. By managing in this way as a package, it is possible to prevent software updates from occurring without ensuring compatibility of related functions. Note that "1-5. Compatibility Package Determination" is not a mandatory element in the vehicle software update method. If the processing after "1-5. Compatibility Package Determination" is not performed, the update execution determination module 1 will send update target information, including valid update data and update capacity information corresponding to each memory M, to the update target memory that is the target of the update request, without referring to the memory version information in "1-4. Collection of Version Management Information". Memory M that receives the valid update data will perform the update using that valid update data.

[0035] 1-6. Issuance of valid update data and information on items to be updated. In step S26 of Figure 3, the update execution decision module 1 sends update target information, including valid update data and update capacity information corresponding to each memory, to the memory to be updated, based on the compatible package information determined in "1-5. Compatibility Package Determination".

[0036] 1-7. Examples The following provides a specific example. In this example, we assume that a priority "medium" update request has been received to update only firmware FW32 to ver2.00, as shown in the table in Figure 5. As shown in Figure 5, the package version at the time the update request is received is assumed to be ver1.10. Whether or not the updater can be performed will be determined based on the table in Figure 6. Furthermore, it is assumed that no valid update data for versions later than ver1.10 has been released.

[0037] In step S21 of Figure 3, the update execution decision module 1 receives an update request RQ with a "medium" priority to update only firmware FW32 to ver2.00, as described above.

[0038] In step S22, the update execution decision module 1 refers to the rewrite count information of memory M3 of the ECU (ECU3 in the example of Figure 7 described later) where the firmware FW32 is stored. Here, it is assumed that the rewrite count corresponds to "few" in Figure 6.

[0039] In step S23, the update execution decision module 1 determines whether the memory M is capable of performing the update. Since the number of times the memory has been rewritten is "low", the update execution decision module 1 determines that the software update based on the update request can be performed in memory M3.

[0040] In step S24, the update execution determination module 1 refers to the firmware FW32 version information. Since the firmware FW32 version is ver1.10, it is determined that the device is eligible for an update.

[0041] In step S25, the availability of a suitable package is determined. The suitable package for updating firmware FW32 to ver2.00 is ver1.20. As mentioned above, ver1.20 (FW22:ver1.00, FW32:ver1.10, FW42:ver1.00, FWa:ver1.10, FWb:ver2.00) has not been released, so the firmware update based on the update request will not be performed, and package ver1.10 will be maintained.

[0042] 2. Hardware Configuration The following describes an example of hardware configuration. In the following description, only parts relevant to the subject matter of the disclosed technology will be briefly explained, and configurations with little relevance to the subject matter of the disclosed technology will be omitted. Furthermore, for the sake of facilitating understanding of the technology, the same reference numerals are used for configurations corresponding to the configuration in Figure 1 above, but this is not intended to limit the scope of the technology of this disclosure.

[0043] 2-1. Example Hardware Configuration (1) This configuration example represents a computer that executes a software update method, where the computing unit, including a gateway ECU or other ECUs, is equivalent to a computer.

[0044] Figure 8 is a block diagram showing an example of the hardware configuration of a software update system. In the example in Figure 8, the update execution decision module 1 is located in vehicle V. The software update system includes vehicle V. Vehicle V is equipped with multiple ECUs. In the example in Figure 8, the multiple ECUs include a gateway ECU (hereinafter sometimes referred to as "ECUG"), ECU1, ECU2, and ECU3. In other words, ECU1, ECU2, ECU3, and ECUG are examples of a first or second ECU.

[0045] The gateway ECU includes a communication interface 18. The communication interface 18 is connected to the Internet N and includes a circuit for communicating with computers, server devices, information terminals, etc., located outside the vehicle. In this example, the communication interface 18 communicates with a server device 200 located outside the vehicle via the Internet N. Software update requests stored in the ECU's memory are input to the communication interface 18. Update requests received via the communication interface 18 are sent to the processor 16. Update requests are output, for example, from the communication interface 210 of the server device 200 and sent to the communication interface 18 via the Internet.

[0046] The gateway ECU includes a processor 16. The processor 16 is configured to implement the functions of the aforementioned update implementation decision module 1 by executing a program stored in memory M4. In the following description, a functional module implemented by the processor is referred to as having (having or including) that functional module.

[0047] The processor 16 includes an update execution decision module 1. The update execution decision module 1 includes a management module 11. The management module 11 may manage the number of rewrites of memory M included in each of the multiple ECUs. The management module 11 may manage the version information of the software stored in each ECU. The management module 11 may manage compatibility information between software versions included in a group of software used to implement a predetermined function. As mentioned above, compatibility information may be managed as package data. The number of rewrites of memory M, software version information, and compatibility information between software group versions may be stored in memory M4. Memory M4 is, for example, a memory that includes the functions of data storage unit 13, data storage unit 14 and memory M4 in Figure 1.

[0048] The update execution decision module 1 includes a calculation module 12. The calculation module 12 includes a function to calculate the number of memory writes. An example of the operation of the calculation module 12 has already been explained with reference to Figure 7, so the explanation will be omitted here.

[0049] The update execution decision module 1 includes a decision module 15. The decision module 15 has the function of performing various decision processing in the update execution decision module 1. For example, as shown in "1-3. Decision on execution of update" above, the decision module 15 determines that a software update based on an update request can be performed if the number of rewrites in all of the memories where the firmware group among ECU1 to 4 is stored is below a predetermined threshold value. For example, if the firmware group consists of firmware FW11 and firmware FW23, the decision module 15 determines that a software update based on an update request can be performed if the number of rewrites in both memory M1 where firmware FW11 is stored and memory M2 where firmware FW23 is stored is below a predetermined threshold value. On the other hand, if the number of rewrites in any of the memories where the firmware group is stored reaches a predetermined threshold value, the decision module 15 determines not to perform a software update based on an update request. In the above example, if the number of rewrites in either memory M1 where firmware FW11 is stored or memory M2 where firmware FW23 is stored reaches a predetermined threshold value, the decision module 15 determines not to perform a software update based on an update request.

[0050] The gateway ECU includes memory M14. Memory M14 is, for example, non-volatile memory. Memory M14 may also be, for example, flash memory. Firmware FW41 and FW42 are stored in memory M14. Memory M14 may also store the rewrite count, compatibility information, version information, or package data of memory M. Note that the rewrite count, compatibility information, version information, or package data of memory M may be stored in a storage medium other than memory M14. The configuration of the storage medium here is not particularly limited. For example, it may be non-volatile memory such as ROM or flash memory, or it may be a semiconductor recording medium such as an SDD (Solid State Drive).

[0051] The gateway ECU is connected to multiple ECUs (e.g., ECU1, ECU2, ECU3) via the in-vehicle network.

[0052] ECU1 includes a processor P1 and a memory M1. The processor P1 communicates with other ECUs and controls actuator A1 by executing a program stored in memory M1. ECU1 controls actuator A1 based on, for example, the measurement results of sensor D1. ECU1 may also control actuator A1 regardless of, for example, the measurement results of sensor D1. As memory M1 has already been explained, its explanation will be omitted here.

[0053] ECU2 includes a processor P2 and memory M2. The processor P2 communicates with other ECUs and controls actuator A2 by executing programs stored in memory M2. ECU2 may, for example, control actuator A2 based on the measurement results of sensor D2. ECU2 may also control actuator A2 independently of the measurement results of sensor D2. Memory M2 has already been explained, so its explanation is omitted here.

[0054] ECU3 includes a processor P3 and memory M3. The processor P3 communicates with other ECUs and controls actuator A3 by executing a program stored in memory M3. ECU3 controls actuator A3 based on, for example, the measurement results of sensor D3. ECU3 may also control actuator A3 independently of, for example, the measurement results of sensor D3. In the following description, sensors D1, D2, and D3 are collectively referred to as sensor D. Similarly, actuators A1, A2, and A3 are collectively referred to as actuator A.

[0055] Sensor D may be configured to measure the driving state, driving environment, and driving conditions of vehicle 1. Sensor D may be configured to acquire driver information of vehicle V. Sensor D may be configured to measure the state of the occupants of vehicle V. Sensor D may include, for example, one or more sensors selected from the group (1)-(9), which consists of: (1) multiple cameras mounted on the body of the vehicle 1 to capture images of the external environment; (2) multiple radars mounted on the body of the vehicle 1 to detect external targets; (3) a vehicle speed sensor to detect the absolute speed of the vehicle 1; (4) an accelerator pedal position sensor to detect the amount the accelerator pedal of the vehicle 1 is pressed; (5) a steering angle sensor to detect the rotation angle (steering angle) of the steering wheel of the vehicle 1; (6) a brake sensor to detect the amount the brake pedal of the vehicle 1 is pressed; (7) a position sensor that uses the Global Positioning System (GPS) to detect the position of the vehicle 1 (vehicle position information); (8) an in-car camera mounted on the interior mirror or dashboard of the vehicle 1 to capture images of the driver's facial expression and posture, the interior environment, etc.; and (9) an in-car sensor to acquire the driver's biometric information (body temperature, heart rate, respiration, etc.).

[0056] Actuator A is configured to operate under control from an ECU. Actuator A may include actuators that perform, or are associated with, one or more actions selected from, for example, the engine, drive motor, brakes, steering, or transmission. Actuator A may also include so-called body system actuators, such as airbags or power windows. Each actuator may include an ECU, or may be configured to operate under control from a higher-level ECU without including its own.

[0057] The server device 200 includes a communication interface 210. The communication interface 210 is connected to the Internet N and includes circuits for communicating with other servers, computers, vehicles V, etc. In this example, the communication interface 210 communicates with the vehicle V's communication interface 18 via the Internet N.

[0058] The gateway ECU includes a processor 220 and a memory unit 230. The processor 220 is configured to perform predetermined functions by executing programs stored in the memory unit 230. For example, when update information for vehicle V is released, the processor 220 creates an update request RQ. The processor 220 then transmits the update request RQ to the vehicle to be updated via the communication interface 210.

[0059] 2-2. Hardware Configuration Examples (2) In this configuration example, the server device 200, which is configured to communicate with the vehicle V, corresponds to a computer that performs software update procedures.

[0060] Figure 9 is a block diagram showing another example of the hardware configuration of the software update system. In the example in Figure 9, some of the functions of the update execution decision module 1 are located on the server device 200, which differs from the configuration in Figure 8. Accordingly, the block diagram showing the functional configuration in Figure 1 is changed as shown in Figure 10. Note that in Figure 9, components corresponding to those in Figure 8 are given the same reference numerals. Similarly, in Figure 10, components corresponding to those in Figure 1 are given the same reference numerals. The following explanation will focus on the differences from the previously mentioned "1. Overview of the software update method" and "2-1. Hardware configuration example (1)".

[0061] In the configuration shown in Figure 9, similar to Figure 8, vehicle V is equipped with multiple ECUs. These multiple ECUs include a gateway ECU (ECUG), ECU1, ECU2, and ECU3. ECU1, ECU2, and ECU3, as well as the sensors D and actuators connected to them, are the same as those described in "2-1. Hardware Configuration Example (1)" above, and their specific explanation is omitted here.

[0062] The gateway ECU includes a processor 16. The processor 16 is configured to implement the functions of the update execution decision module 1 described above by executing a program stored in memory M4. In the example in Figure 9, the processor 16 includes only the calculation module 12 of the update execution decision module 1 described in Figure 8. The processing performed by the calculation module 12 will be explained later.

[0063] The gateway ECU includes memory M14. Memory M14 is, for example, non-volatile memory. Memory M14 may also be, for example, flash memory. Firmware FW41 and FW42 are stored in memory M14. Memory M14 also stores the number of write cycles of memory M, as in Figure 8. However, unlike in Figure 8, compatibility information, version information, and package data do not necessarily need to be stored.

[0064] Furthermore, the gateway ECU includes a communication interface 18 similar to that shown in Figure 8.

[0065] In the configuration shown in Figure 9, the server device 200 includes a communication interface 210. The configuration of the communication interface 210 is the same as in Figure 8.

[0066] The server device 200 comprises a processor 220 and a storage unit 230. The processor 220 is configured to perform predetermined functions by executing programs stored in the storage unit 230. The processor 220 includes an update execution decision module 201, which corresponds to the update execution decision module 1 in Figure 8. The update execution decision module 201 includes a management module 211, which corresponds to the management module 11, and a decision module 215, which corresponds to the decision module 15. The storage unit 230 stores update information (hereinafter simply referred to as "update information") acquired from each vehicle V and used for updating the vehicle software. The update information is stored linked to identification information for identifying the vehicle V from which it was acquired. The update information includes the aforementioned compatibility information, version information, and package data. The compatibility information, version information, and package data are the same as in the embodiment described above, and their explanation is omitted here. Furthermore, the storage unit 230 records rewrite information of memory M acquired from each vehicle V.

[0067] Next, referring to Figures 3 and 10, we will describe the operation of the update system when some of the functions of the update execution decision module 1 are located on the server device 200. This explanation will focus on the differences from the previously described embodiment (Figure 1).

[0068] In step S21 of Figure 3, the update execution decision module 201 of the server device 200 receives update request RQs for the firmware of the vehicle V's ECUs 1-3 and gateway ECU. As in the embodiment, once the update execution decision module 201 receives a software update request, that is, once a software update request is received, the flow proceeds to the next step S2. The specific content of the update request RQ is the same as in Figure 1.

[0069] In step S22, the update execution decision module 201 refers to the registered memory rewrite count information for the vehicle V that is the target of the update request RQ (hereinafter referred to as "target vehicle V"). The memory M rewrite count information may be obtained, for example, by requesting the memory M rewrite count information from the target vehicle V after receiving the update request RQ. The method for obtaining the memory M rewrite count information in the target vehicle V is the same as in the embodiment described above. For example, the calculation module 12 of the target vehicle V accesses memory M (for example, memory M1 to M4) and obtains memory M depletion information. Then, the calculation module 12 of the target vehicle V calculates the memory M rewrite count based on the acquired memory M depletion information. The memory M rewrite counts are aggregated and transmitted to the server device 200 via the communication interface 18.

[0070] In step S23, the update execution decision module 201 determines which memory M can be updated. The specific details of the decision process are the same as in the embodiment described above. Specifically, the update execution decision module 201 identifies the software group to be updated in response to the update request based on compatibility information. Next, the update execution decision module 201 determines that it will perform a software update based on the update request RQ if the number of write cycles of all memories where the firmware group is stored is below a predetermined threshold value. On the other hand, if the number of write cycles of any memory M where the software group is stored has reached a predetermined threshold value, it determines that it will not perform a software update based on the update request RQ.

[0071] In step S24, the update execution decision module 201 refers to the version information of the software to which the update request is being made.

[0072] In step S25, it is determined whether a suitable package exists. If a suitable package exists, the flow proceeds to the next step, S26. On the other hand, if no suitable package exists, it is determined that the software update related to the update request cannot be performed, and the process ends.

[0073] In step S26, the update execution decision module 201 sends an update request and update target information, including update data and update capacity information, to the vehicle V's gateway ECU (see Figure 9) based on the compatible package information determined in "1-5. Compatibility Package Determination". The gateway ECU (see Figure 9) then sends valid update data to the update target memory based on the received update target information.

[0074] 3. Summary As described above, the first aspect of this disclosure relates to a method for updating software for a vehicle equipped with multiple ECUs (e.g., ECU1, ECU2, ECU3, ECUG).

[0075] The software update procedure involves the computer performing the following steps (1) through (3).

[0076] The method for updating this software includes (1) receiving an update request RQ for the software stored in the ECU's memory. The update request RQ is received by the ECU, for example, via the communication interface 18.

[0077] The method for updating this software includes (2) identifying the firmware group to be updated in response to an update request, based on compatibility information of the firmware group (equivalent to software) used to implement a predetermined function. As mentioned above, compatibility information includes information indicating the compatibility between firmwares used to implement a predetermined function. Compatibility between software may be managed using software version information as compatibility information.

[0078] The software update method includes (3) determining that a software update based on an update request RQ can be performed if the number of writes in all of the memories where the firmware group of one of the multiple ECUs is stored is below a predetermined threshold. For example, if the firmware group consists of firmware FW11 and firmware FW23, and this firmware group is the target of an update related to an update request RQ, then if the number of writes in memory M1 and memory M2 is below a predetermined threshold, then it is determined that a software update based on the update request RQ can be performed. On the other hand, if the number of writes in any of the memories where the firmware group is stored has reached a predetermined threshold, then it is determined that a software update based on the update request will not be performed. For example, in the above example, if the firmware group consists of firmware FW11 and firmware FW23, and this firmware group is the target of an update related to an update request RQ, then if the number of writes in memory M1 or memory M2 has reached a predetermined threshold, then it is determined that a software update based on the update request RQ will not be performed.

[0079] According to the above configuration, OTA failures due to memory rewrite limits can be prevented. Furthermore, in response to an update request (RQ), compatibility information of the software group (e.g., firmware group) used to implement a predetermined function is used to determine whether the function implementing the predetermined function can be treated as a single unit and whether an update can be performed, thereby ensuring the consistency of related functions.

[0080] A second aspect of this disclosure is that, in the first embodiment described above, the update request may include an update priority. The decision to perform a software update based on the update request may be made based on a comparison with a reference value for the number of write cycles of memory M and the update priority. In a third aspect, in the second embodiment described above, the higher the update priority, the higher the predetermined reference value may be.

[0081] By using priority-based decision-making in this way, the criteria for deciding whether to update high-priority functions, such as those with high criticality, can be relaxed, allowing updates to be performed based on update requests (RQs). This ensures that updates to critical functions are executed more reliably while avoiding reaching the memory write limit.

[0082] A fourth aspect of this disclosure is that, in any one of the first to third aspects described above, the compatibility information may be included in package data that associates software for related functions using the version information of each software.

[0083] A fifth aspect of this disclosure is that, in any one aspect of the first to third aspects described above, the update request may include version information of the software to be updated. The update data used for the update may be provided as package data as a group of software. The software update method according to the fifth aspect may determine whether the software is compatible with the package data based on the software version information related to the software request. If it is compatible with the package data, the method may determine that the software update based on the update request can be performed, while if it is not compatible with the package data, the method may also include determining not to perform the software update based on the update request.

[0084] Managing this as package data offers the following advantages: For example, it becomes easier to determine whether or not to perform an update based on an update request (RQ). For example, it prevents the software update from resulting in a combination of software versions that the developer did not anticipate. For example, it becomes easier to revert to a previous version combination, known as regression, due to some reason (e.g., update failure). For example, it becomes easier to manage the combination of software versions for vehicles.

[0085] A sixth aspect of this disclosure relates to a software update program for a vehicle equipped with multiple ECUs (Electronic Control Units). The program includes having a computer perform the following steps (1) to (3).

[0086] Specifically, this includes (1) receiving update requests for software stored in the ECU's memory, (2) identifying the software group to be updated in response to the update request based on compatibility information of the software group (e.g., firmware group) used to implement a predetermined function, and (3) determining that a software update can be performed based on the update request if the number of write cycles in all of the memories where the software groups of the multiple ECUs are stored is below a predetermined threshold, while determining not to perform a software update based on the update request if the number of write cycles in any of the memories where the software groups are stored has reached a predetermined threshold.

[0087] According to the sixth embodiment described above, as with the first embodiment, it is possible to prevent OTA failures caused by memory rewrite limits. Furthermore, in response to an update request RQ, compatibility information of the software group (e.g., firmware group) used to implement a predetermined function is used to determine whether an update can be performed by treating the functions that implement the predetermined function as a single unit, thereby ensuring the consistency of related functions.

[0088] A seventh aspect of this disclosure relates to a software update system for a vehicle equipped with a plurality of ECUs (Electronic Control Units), including a first ECU and a second ECU. Each of the plurality of ECUs has a memory that can be rewritten with software. In the example of the above embodiment, ECU1, ECU2, ECU3, and ECUG are examples of the plurality of ECUs. ECU1 has memory M1. Similarly, ECU2 has memory M2, ECU3 has memory M3, and ECUG has memory M4. Furthermore, the software update system includes a communication interface 18 that receives software update requests RQ. The update system also has a management module 11 that manages the number of rewrites of the memory M of the plurality of ECUs, the version information of the software stored in each ECU, and compatibility information between versions of software groups used to realize predetermined functions. In the example of the embodiment, the number of rewrites of memory M, the software version information, and the compatibility information are stored in memory M4 and managed by the management module 11. Furthermore, the update system includes a determination module that, when an update request for the first software stored in the memory of the first ECU is received by the communication interface 18, identifies other second software to be updated along with the first software from version information and compatibility information, and determines whether or not to perform a software update based on the update request, based on the number of times the memory of the first ECU has been rewritten and the number of times the memory of the second ECU in which the second software is stored has been rewritten.

[0089] According to the seventh embodiment described above, as with the first embodiment, it is possible to prevent OTA failures caused by memory rewrite limits. Furthermore, in response to an update request RQ, compatibility information of the software group (e.g., firmware group) used to implement a predetermined function is used to determine whether an update can be performed by treating the functions that implement the predetermined function as a single unit, thereby ensuring the consistency of related functions.

[0090] In the eighth aspect, in the seventh aspect described above, the management module 11 and the decision module 15 are provided in one of the multiple ECUs.

[0091] This allows the update decision process to be completed within the vehicle V, thereby reducing the load on the management device (e.g., a server) that manages updates for the vehicle's software.

[0092] In the ninth embodiment, the seventh embodiment described above may further include a server device 200 configured to communicate with the vehicle V. The server device may also include a management module 211 and a decision module 215.

[0093] This means that in vehicle V, the update request is sent only after the feasibility of the update has been determined, thus reducing the processing load on vehicle V.

[0094] (Other embodiments) Furthermore, the technologies disclosed above are not limited to the embodiments described above, and can be substituted insofar as they do not depart from the spirit of the claims. [Industrial applicability]

[0095] The technologies disclosed herein are useful as methods, systems, and programs for updating vehicle software. [Explanation of Symbols]

[0096] V Vehicle M, M1, M2, M3, M4 memory ECU1,ECU2,ECU3,ECUG 1st ECU, 2nd ECU 11 Management Modules 15 Decision Module 18. Communication Interface (Interface) 200 Server Devices 211 Management Module 215 Decision Module

Claims

1. A method for updating software for a vehicle equipped with multiple ECUs (Electronic Control Units) that is executed by a computer, The ECU accepts update requests for the software stored in its memory, Based on compatibility information of the software suite used to implement a predetermined function, the software suite to be updated in response to the update request is identified. A software update method that includes determining that a software update based on the update request can be performed if the number of write cycles in all of the memories where the software group is stored among the plurality of ECUs is below a predetermined threshold, while determining not to perform a software update based on the update request if the number of write cycles in any of the memories where the software group is stored has reached a predetermined threshold.

2. In the software update method described in claim 1, The aforementioned update request includes the update priority, A software update method that determines whether to perform a software update based on an update request, based on a comparison with a reference value for the number of memory write cycles and the priority of the update.

3. In the software update method described in claim 2, A software update method in which the higher the priority of the update, the higher the predetermined reference value.

4. In the software update method described in claim 1, The aforementioned compatibility information is a software update method included in package data that associates software with related functions using the version information of each software.

5. In the software update method described in claim 1, The aforementioned update request includes version information of the software to be updated, The update data used for the update is provided as package data for the aforementioned software group. The aforementioned update method is: Based on the software version information related to the update request, it is determined whether it is compatible with the package data. A software update method that includes determining that a software update can be performed based on the update request if the package data is compatible, and determining not to perform a software update based on the update request if the package data is not compatible.

6. A software update program for vehicles equipped with multiple ECUs (Electronic Control Units), On the computer, The ECU accepts software update requests stored in its memory, Based on compatibility information of the software suite used to implement a predetermined function, the software suite to be updated in response to the update request is identified. An update program that determines that a software update based on the update request can be performed if the number of write cycles in all of the memories where the software group is stored among the plurality of ECUs is below a predetermined threshold value, while determining not to perform a software update based on the update request if the number of write cycles in any of the memories where the software group is stored has reached a predetermined threshold value.

7. A software update system for a vehicle equipped with multiple ECUs (Electronic Control Units), including a first ECU and a second ECU, Each of the aforementioned multiple ECUs has a memory that can be rewritten with software, An interface for receiving software update requests, A management module that manages the number of times the memory of the multiple ECUs has been rewritten, the version information of the software stored in each of the ECUs, and the compatibility information between the versions of the software groups used to implement a predetermined function, A software update system comprising: when an update request for first software stored in the memory of the first ECU is received by the interface, the system identifies other second software to be updated together with the first software from the version information and the compatibility information, and determines whether or not to perform a software update based on the update request based on the number of times the memory of the first ECU has been rewritten and the number of times the memory of the second ECU in which the second software is stored has been rewritten.

8. In the software update system described in claim 7, One of the plurality of ECUs is equipped with the management module and the decision module. A software update system.

9. In the software update system described in claim 7, The vehicle further comprises a server device configured to communicate with the aforementioned vehicle, The server device includes the management module and the decision module. A software update system.

Images