Method for upgrading software of vehicle, upgrading program product, and upgrading system

Abstract

[Topic] To provide a method, program, and system for upgrading vehicle software that prevents upgrade failures caused by memory rewrite limits and ensures the coordination of related functions. [Solution] The method for upgrading vehicle software includes: (1) accepting upgrade requests for software stored in the memory (M) of the ECU; (2) determining the software group to be upgraded based on software group compatibility information; (3) determining that the software upgrade can be performed if the number of rewrites in all memories storing the software group is less than a baseline value, and on the other hand, determining that the software upgrade will not be performed if the number of rewrites in any memory storing the software group reaches the baseline value.

Description

Technical Field

[0001] The technology disclosed herein belongs to the technical field related to methods, procedures, or systems for upgrading software for vehicles. Background Technology

[0002] In the IoT field, software upgrades are typically done via OTA (Over The Air), and this practice has also been introduced in automotive ECUs (Electronic Control Units).

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

[0004] Furthermore, Patent Document 2 discloses a software management device that utilizes a version management unit to manage the software versions of an in-vehicle device, and an update confirmation processing unit uses communication with a server, inter-vehicle communication, and inter-vehicle communication to determine whether there is updatable software. In Patent Document 2, when the software is updatable, the timing of notifications and / or processing related to the software update is selected based on the importance of the update during vehicle operation.

[0005] Existing technical documents Patent documents Patent Document 1: Japanese Patent Application Publication No. 2018-132979 Patent Document 2: Japanese Patent Application Publication No. 2005-349878 Summary of the Invention

[0006] The problem that the invention aims to solve Furthermore, in vehicle ECUs, software is stored in rewritable non-volatile memory. Generally, non-volatile memory (such as flash memory) has an upper limit on the number of times it can be rewritten; exceeding this limit increases the likelihood of write errors. Therefore, it's possible that an over-the-air (OTA) update could reach the upper limit of the non-volatile memory's rewrite count, leading to update failure. In particular, the large number of vehicle ECUs presents challenges in ensuring coordination and proper functioning between them.

[0007] The technology disclosed herein was developed in view of the aforementioned problems, and its purpose is to prevent upgrade failures caused by the rewrite limits of memory and to ensure the coordination of associated functions.

[0008] Methods for solving problems To address the aforementioned problem, the technology disclosed herein targets a method for upgrading software used in a vehicle equipped with multiple ECUs (Electronic Control Units). This method includes: accepting an upgrade request for software stored in the memory of the ECUs; determining, based on compatibility information of the software group used to implement a specified function, a software group to be upgraded according to the upgrade request; and determining that a software upgrade can be performed based on the upgrade request if the number of rewrites in all the memories storing the software group in the multiple ECUs is less than a predetermined benchmark value, and conversely, determining that a software upgrade will not be performed based on the upgrade request if the number of rewrites in any memory storing the software group reaches the predetermined benchmark value.

[0009] Invention Effects The technology disclosed here can prevent upgrade failures caused by the rewrite limits of memory and ensure the coordination of related functions. Attached Figure Description

[0010] Figure 1 This is a block diagram illustrating the functional configuration of the software update process for a vehicle in an embodiment.

[0011] Figure 2 This is a flowchart illustrating the overall processing of the vehicle's software upgrade system.

[0012] Figure 3 This is a flowchart illustrating an example of software upgrade processing for vehicles.

[0013] Figure 4 This is a flowchart illustrating an example of information update processing for packet data.

[0014] Figure 5 This is a diagram representing an example of packet data.

[0015] Figure 6 This is a diagram illustrating an example of determining whether an upgrade can be implemented based on priority and the number of times the memory has been overwritten.

[0016] Figure 7 This is a flowchart illustrating an example of the actions of the count calculation module.

[0017] Figure 8 This is a block diagram illustrating an example of the hardware configuration of a software upgrade system.

[0018] Figure 9 This is a block diagram representing other hardware components of a software upgrade system.

[0019] Figure 10 This is another example of a block diagram illustrating the functionality of software update processing for vehicles.

[0020] Explanation of reference numerals in the attached figures V vehicle M, M1, M2, M3, M4 memory ECU1, ECU2, ECU3, ECUG (First ECU, Second ECU) 11 Management Module 15 Judgment Module 18. Communication Interface (Interface) 200 server devices 211 Management Module 215 Judgment Module Detailed Implementation

[0021] Hereinafter, exemplary embodiments will be described in detail with reference to the accompanying drawings.

[0022] Furthermore, the following embodiments are illustrative and are not intended to limit the content of this disclosure by the presence or absence of descriptions or illustrative values. Additionally, the functions implemented by the constituent elements of the system, server, etc., described in this specification, as well as the functional blocks, modules, etc., described in this specification, can be installed in a circuit system or processing circuitry that is programmed to implement the described functions and includes general-purpose processors such as CPUs (Central Processing Units) and GPUs (Graphics Processing Units), special-purpose processors, integrated circuits, ASICs (Application Specific Integrated Circuits), existing types of circuits, and / or combinations thereof. A processor includes transistors and other circuits and is considered a circuit system or processing circuitry. A processor can be configured to execute programs stored in memory. Memory includes, for example, volatile memory such as RAM, and non-volatile semiconductor memory such as ROM and flash memory.

[0023] 1. Overview of software upgrade methods Figure 1 This is a block diagram illustrating an outline of a method for upgrading software for a vehicle according to an implementation embodiment. Figure 1 The diagram focuses on the functional components representing the software upgrade method, largely omitting the hardware components. For example, as described later... Figure 6 As shown, vehicle V is equipped with multiple ECUs (Electronic Control Units). Each ECU has a memory M whose software can be rewritten.

[0024] Memory M is, for example, non-volatile memory. Non-volatile memory is, for example, flash memory. Flash memory has an upper limit on the number of rewrite cycles. Furthermore, memory M is not limited to flash memory; it can also be other types of memory with an upper limit on the number of rewrite cycles. Figure 1 In the example, the illustration of the ECU is omitted; only the memory M is shown. Specifically, in Figure 1 In the example, memory M, which may become a target for software upgrades, is exemplified by memories M1 to M4. Figure 8 or Figure 9 As illustrated, the memories M1 to M4 are installed, for example, in different ECUs 1 to ECU 4.

[0025] The software upgrade method is executed, for example, by the upgrade implementation judgment module 1. As mentioned earlier, the functions implemented by the upgrade implementation judgment module 1 are implemented by general-purpose processors such as CPUs and GPUs, as well as dedicated processors, which are programmed to implement these functions. The upgrade implementation judgment module 1 can be installed inside the vehicle, or some of its functions can be implemented by an external computer or external server located outside the vehicle. Details will be explained later in the hardware configuration examples.

[0026] The following describes a specific example of the method for upgrading the vehicle software executed by the upgrade implementation judgment module 1. Figure 3 This is a flowchart illustrating the software upgrade process (software upgrade method).

[0027] 1-1. Upgrade Request In step S21, the upgrade implementation judgment module 1 processes the acceptance of the software upgrade request RQ stored in the ECU's memory. Specifically, an upgrade request RQ is sent to the upgrade implementation judgment module 1. Upon receiving the upgrade request RQ, the upgrade implementation judgment module 1 begins the software upgrade process. If the upgrade implementation judgment module 1 accepts the software upgrade request in step S21, i.e., receives the software upgrade request, the process proceeds to the next step, S22.

[0028] An upgrade request (RQ) may contain upgrade data. Upgrade data is the data used for the specific upgrade corresponding to the upgrade request (RQ). Upgrade data can also be received only after it has been determined that an upgrade, as described later, is being implemented.

[0029] Upgrade Requests (RQs) can include upgrade priority information. Upgrade priorities can have multiple levels. Alternatively, upgrade priorities can be managed using a scoring system based on defined criteria. This will be discussed later. Figure 6 In the example, the upgrade priority is divided into three levels: "high," "medium," and "low." "High" priority includes upgrades such as those that would hinder normal vehicle operation without them. More specifically, this includes fixing software bugs. "Medium" priority includes upgrades related to driving functions. Specifically, this includes upgrades to memory associated with the control of driving, steering, and braking actions. More specifically, "medium" priority includes upgrades to driving control, steering control, or braking control aimed at improving fuel efficiency, driving performance, or passenger comfort. "Low" priority refers to upgrades with a low probability of directly affecting the vehicle's driving. Examples include upgrades to vehicle body-related functions, audio systems, and lighting. More specifically, examples of "low" priority include "power window operation" and "direction indicator flashing control."

[0030] Upgrade Requests (RQs) can contain software version information. They can also contain compatibility information between different software versions. This compatibility information indicates the compatibility between the software versions used to achieve the specified functionality. In other words, software components that are considered compatible based on compatibility information need to be upgraded together, or are recommended to be upgraded together. Sometimes, the software components associated through compatibility information are all stored in the memory of a single ECU; other times, they are distributed across the memories of multiple ECUs.

[0031] In the example diagram, firmware units deemed compatible based on compatibility information are marked with the same shaded area. 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 through compatibility information. Firmware FW21 stored in memory M2 and firmware FW33 stored in memory M3 are associated with each other through 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 through compatibility information. Firmware FW31 stored in memory M3 and firmware FW41 stored in memory M4 are associated with each other through 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. Furthermore, compatibility information can be in any format, as long as compatibility can be assessed. For example, software version information can be used as compatibility information to manage the compatibility of different software.

[0032] Compatibility information can be managed as package data. Package data can be associated with the version information of various software. Package data can link functionally related software together. Package data can use the version information of various software to establish associations between functionally related software. Package data can be pre-registered, imported from external sources, or upgraded. Additionally, package data can be generated by the upgrade implementation judgment module 1. Specifically, such as... Figure 2 As shown, the overall operation of the software upgrade system can be performed after the package information has been updated. Figure 3 The process for determining whether to implement a software upgrade was explained. Furthermore, Figure 2 The update of package information (step S1) is not a necessary component of this disclosure.

[0033] Figure 4 express Figure 2This is an example of the packet data information update processing described in step S1. When a reference request for packet data and software version information exists, the version information is retrieved from the data storage unit 13 and sent out (steps S11, S12). When new packet data is received, this information is stored in the data storage unit 13 (steps S13, S14). When updating the data packet, i.e., when performing an OTA upgrade, the applied packet data is stored in the data storage unit 13 (steps S15, S16). Furthermore, the data storage unit 13 can be any storage area (e.g., a memory) that can be referenced by the upgrade implementation determination module 1, and there are no particular limitations on the specific hardware configuration. The same applies to the data storage unit 14, which will be described later.

[0034] 1-2. Memory overwrite count information Back Figure 3 In step S22, the upgrade implementation judgment module 1 refers to the registered memory rewrite count information. The upgrade implementation judgment module 1 includes a calculation module 12 for calculating the memory rewrite count.

[0035] Figure 7 The flowchart illustrates an example of the operation of the calculation module 12. In step S221, the calculation module 12 receives information about the memory that is the target of the upgrade request (hereinafter referred to as the "upgrade target memory") and the capacity information required for its upgrade. When the upgrade target memory information and the capacity information required for the upgrade are received, the process proceeds to the next step S222. In step S222, the calculation module 12 calculates the number of times the memory needs to be overwritten based on the capacity information required for the upgrade. The calculation module 12 refers to the number of overwrites stored in the storage unit up to the present, and adds the number of overwrites obtained through calculation to obtain the new number of overwrites for the memory. In the next step S223, the calculation module 12 stores the new number of overwrites for the memory obtained through calculation in step S222 in the data storage unit 14.

[0036] For the overwrite count information of the upgraded object storage, add it to the already stored (to date) overwrite count.

[0037] 1-3. Implementation Judgment for Upgrade exist Figure 3 In step S23, the upgrade implementation determination module 1 determines the memory M that can be upgraded. Specifically, firstly, based on compatibility information and the upgrade request, the upgrade implementation determination module 1 determines the software group that is the target of the upgrade. Furthermore, if the storage unit stores packet data, the software group that is the target of the upgrade can be determined based on the packet data.

[0038] Next, if the number of rewrites of all memories storing the software group is less than a predetermined baseline value, the upgrade implementation determination module 1 determines that the software upgrade should be performed based on the upgrade request RQ. On the other hand, if the number of rewrites of any memory M storing the software group reaches the predetermined baseline value, it is determined that the software upgrade should not be performed based on the upgrade request RQ.

[0039] The specified baseline value is set to have a specified margin relative to the upper limit of the number of times each memory can be overwritten. The size of this margin is not specifically limited and can be set arbitrarily. Furthermore, the specified margin can be set to a fixed value or configured to be updated midway. For example, when an upgrade request is prioritized, the specified baseline value could be such that the higher the priority, the higher the upper limit allowed for the number of times the memory can be overwritten. Figure 6 An example of determining whether an upgrade can be implemented is shown, based on priority and the number of times the memory has been overwritten.

[0040] exist Figure 6 In this scenario, when the upgrade priority is set to "low," and the number of memory overwrites is low, the upgrade implementation judgment module 1 determines to perform a software upgrade based on the upgrade request. Conversely, when the upgrade priority is set to "low," and the number of memory overwrites is moderate or high, the upgrade implementation judgment module 1 determines not to perform a software upgrade based on the upgrade request. That is, the predetermined benchmark value used as the basis for upgrade implementation judgment is set relatively low. In other words, the predetermined margin is relatively large relative to the upper limit of the number of memory overwrites.

[0041] When the upgrade priority is set to "medium," the upgrade implementation judgment module 1 determines to perform a software upgrade based on the upgrade request when the number of memory overwrites is low or moderate. Conversely, when the upgrade priority is set to "medium," the upgrade implementation judgment module 1 determines not to perform a software upgrade based on the upgrade request when the number of memory overwrites is high. That is, the predetermined benchmark value used as the basis for upgrade implementation judgment is set to an intermediate value between "low" and "high" priority. In other words, a predetermined margin is set to moderate relative to the upper limit of the number of memory overwrites.

[0042] When the upgrade priority is set to "high," even if the memory is overwritten many times, the upgrade implementation judgment module 1 will still determine to upgrade the software based on the upgrade request. That is, the predetermined benchmark value that serves as the basis for upgrade implementation judgment is set to a priority higher than "low" and "medium." In other words, the predetermined margin relative to the upper limit of the number of memory overwrites is smaller than in the cases of "low" and "medium" priorities.

[0043] 1-4. Collection of Version Management Information exist Figure 3 In step S24, the upgrade implementation judgment module 1 refers to the version information of the software that is the target of the upgrade request. If the upgrade request version is the same as the current version, it is excluded from the upgrade list. That is, the upgrade implementation judgment module 1 does not upgrade the software based on the upgrade request and ends the upgrade process. If other upgrade requests exist, the process in step S21 is performed. If there are no other upgrade requests, the upgrade implementation judgment module 1 enters a standby state until the next upgrade request arrives. Furthermore, "1-4. Collection of Version Management Information" is not a necessary element in the software upgrade method for vehicles. Without performing the processing after "1-4. Collection of Version Management Information," the upgrade implementation judgment module 1, based on the judgment result in "1-3. Upgrade Implementation Judgment," sends upgrade object information to the upgrade object memory that is the target of the upgrade request. This upgrade object information includes upgrade data (hereinafter also referred to as "valid upgrade data") corresponding to each memory M and upgrade capacity information. The memory M that receives the valid upgrade data uses the valid upgrade data to perform the upgrade.

[0044] 1-5. Appropriate Data Packet Judgment exist Figure 3 In step S25, the upgrade implementation judgment module 1 determines whether there is a data packet suitable for the upgrade based on the upgrade request. For example, the upgrade implementation judgment module 1 can determine whether there is a data packet suitable for the upgrade based on the information of the memory M that can be upgraded in "1-3. Upgrade Implementation Judgment" and the version information referenced in "1-4. Collection of Version Management Information". If a suitable data packet exists, the process proceeds to the next step S26. On the other hand, if no suitable data packet exists, it is determined that the upgrade of the software involved in the upgrade request cannot be implemented, and the process ends.

[0045] Figure 5 An example of packet data is shown. Packet data includes the packet version number and the version information of the associated firmware. Besides... Figure 1 In addition to the firmware FW22, firmware FW32 and firmware FW42 shown, there will also be Figure 1 Firmware Fwa and FWb (not shown in the diagram) are registered as packet data. Furthermore, the version information for each firmware FW22, FW32, FW42, Fwa, and FWb is stored in a manner associated with the version information of the data packets. Figure 5In the initial data packet (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 illustrates an example where, when upgrading from Ver1.00 to Ver1.10 as a data packet, FW32, Fwa, and FWb need to be upgraded to Ver1.10 simultaneously. This management as a data packet prevents software upgrades from occurring without ensuring compatibility of related functions. Furthermore, "1-5. Compatibility Data Packet Judgment" is not a necessary element in the vehicle software upgrade method. Without performing the processing after "1-5. Compatibility Data Packet Judgment," the upgrade implementation judgment module 1 does not refer to the memory version information in "1-4. Collection of Version Management Information" and sends upgrade object information containing valid upgrade data corresponding to each memory M and upgrade capacity information to the upgrade object memory that is the target of the upgrade request. The valid upgrade data is used to perform the upgrade in the memory M that has received the upgrade data.

[0046] 1-6. Issuance of effective upgrade data and upgrade target information exist Figure 3 In step S26, the upgrade implementation judgment module 1 sends upgrade object information containing valid upgrade data corresponding to each memory and upgrade capacity information to the upgrade object memory based on the appropriate packet information judged in "1-5. Appropriate data packet judgment".

[0047] 1-7. Examples The following are specific embodiments. In this example, it is assumed that in Figure 5 The table received an upgrade request with a priority of "medium" that only upgrades firmware FW32 to ver2.00. For example... Figure 5 As shown, assume the data packet ver (data packet version number) at the time the upgrade request is received is ver1.10. Assume it is based on... Figure 6 The table is used to determine whether an upgrade can be implemented. Additionally, it is assumed that valid upgrade data for versions after ver1.10 has not been released.

[0048] exist Figure 3 In step S21, as described above, the upgrade implementation judgment module 1 receives an upgrade request RQ with a priority of "medium" that only upgrades firmware FW32 to ver2.00.

[0049] In step S22, the upgrade implementation judgment module 1 refers to the ECU storing firmware FW32 (described later). Figure 7 In the example, this refers to the rewrite count information of memory M3 in ECU3. Here, it is assumed to be related to... Figure 6 The word "few" in the text refers to a number of rewrites.

[0050] In step S23, the upgrade implementation judgment module 1 determines the memory M that can be upgraded. Since the memory has been overwritten a few times, the upgrade implementation judgment module 1 determines that the software can be upgraded based on the upgrade request in the memory M3.

[0051] In step S24, the upgrade implementation judgment module 1 refers to the version information of firmware FW32. Since the version of firmware FW32 is ver1.10, it is determined to be the target of the upgrade.

[0052] In step S25, it is determined whether a suitable data packet exists. The suitable data packet for firmware FW32 being ver2.00 is ver1.20. As mentioned earlier, since ver1.20 (FW22: ver1.00, FW32: ver2.00, FW42: ver1.00, FWa: ver2.00, FWb: ver2.00) has not been released, the firmware is not upgraded based on the upgrade request, and data packet ver1.10 is maintained.

[0053] 2. Hardware Configuration The following describes an example of hardware configuration. Furthermore, in the following description, only the parts related to the disclosed technical subject matter are briefly explained; configurations with low relevance to the disclosed technical subject matter are omitted. Additionally, regarding the aforementioned… Figure 1 The components corresponding to each other are labeled with the same reference numerals in the accompanying drawings for ease of understanding of the technology, but this is not intended to limit the scope of the technology disclosed herein.

[0054] 2-1. Example of hardware configuration (1) This example is a computer that includes a gateway ECU or other ECU and is equivalent to a method for performing software upgrades.

[0055] Figure 8 This is a block diagram illustrating an example of the hardware configuration of a software upgrade system. Figure 8 In this example, the upgrade implementation judgment module 1 is configured in vehicle V. The software upgrade system includes vehicle V. Vehicle V contains multiple ECUs. Figure 8 In this example, 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 either the first or second ECU.

[0056] The gateway ECU includes a communication interface 18. The communication interface 18 is connected to the Internet N and includes circuitry 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. An upgrade request for software stored in the ECU's memory is input to the communication interface 18. The upgrade request received via the communication interface 18 is sent to the processor 16. For example, the upgrade request may be output from the communication interface 210 of the server device 200 and sent to the communication interface 18 via the Internet.

[0057] The gateway ECU includes a processor 16. The processor 16 is configured to implement the functions of the aforementioned upgrade implementation determination module 1 by executing a program stored in the memory M4. In the following description, a functional module implemented by the processor means that the processor has (has or includes) that functional module.

[0058] The processor 16 includes an upgrade implementation judgment module 1. The upgrade implementation judgment module 1 includes a management module 11. The management module 11 can manage the number of times the memory M contained in each of the multiple ECUs is overwritten. The management module 11 can manage the version information of the software stored in each ECU. The management module 11 can manage the compatibility information between the software versions contained in the software group used to implement the specified function. As mentioned above, the compatibility information can be managed as package data. The number of times the memory M is overwritten, the software version information, or the compatibility information between the versions of the software group can be stored in a memory M4. The memory M4, for example, contains... Figure 1 The data storage unit 13, the data storage unit 14, and the memory M4 are memory units that perform functions.

[0059] The upgrade implementation judgment module 1 includes a calculation module 12. Calculation module 12 contains the function of calculating the number of times the memory has been overwritten. Regarding the action example of calculation module 12, since it has already been referenced... Figure 7 The explanation has already been provided, so it will be omitted here.

[0060] The upgrade implementation judgment module 1 includes a judgment module 15. The judgment module 15 has the function of performing various judgment processes as described in the upgrade implementation judgment module 1. For example, as shown in "1-3. Upgrade Implementation Judgment" above, if the number of rewrites in all the memories storing the firmware group in ECU1 to ECU4 is less than a predetermined benchmark value, the judgment module 15 determines that a software upgrade can be performed based on the upgrade request. For example, if firmware FW11 and firmware FW23 constitute a firmware group, and the number of rewrites in both memory M1 storing firmware FW11 and memory M2 storing firmware FW23 is less than a predetermined benchmark value, it is determined that a software upgrade can be performed based on the upgrade request. On the other hand, if the number of rewrites in any memory storing the firmware group reaches the predetermined benchmark value, it is determined that a software upgrade will not be performed based on the upgrade request. Taking the above example, if the number of rewrites in either memory M1 storing firmware FW11 or memory M2 storing firmware FW23 reaches the predetermined benchmark value, it is determined that a software upgrade will not be performed based on the upgrade request.

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

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

[0063] ECU1 includes a processor P1 and a memory M1. The processor P1 communicates with other ECUs or controls actuator A1 by executing programs stored in the memory M1. ECU1 controls actuator A1, for example, based on measurements from sensor D1. ECU1 can also control actuator A1 independently of measurements from sensor D1. Regarding the memory M1, since it has already been described, a description is omitted here.

[0064] ECU2 includes a processor P2 and a memory M2. The processor P2 communicates with other ECUs or controls actuator A2 by executing programs stored in the memory M2. ECU2 controls actuator A2, for example, based on measurements from sensor D2. ECU2 can also control actuator A2 independently of the measurements from sensor D2. Regarding the memory M2, since it has already been described, a description is omitted here.

[0065] ECU3 includes a processor P3 and a memory M3. The processor P3 communicates with other ECUs or controls actuator A3 by executing programs stored in the memory M3. ECU3 controls actuator A3, for example, based on measurements from sensor D3. ECU3 can also control actuator A3 independently of the measurements from 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.

[0066] Sensor D can be configured to measure the driving state, driving environment, and operating status of vehicle 1. Sensor D can also be configured to acquire the driver's operational information from vehicle V. Sensor D can also 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 of (1) to (9) below: (1) multiple cameras installed on the body of the car 1 and photographing the external environment; (2) multiple radars installed on the body of the car 1 and sensing external reflectors, etc.; (3) a vehicle speed sensor that detects the absolute speed of the car 1; (4) an accelerator opening sensor that detects the amount of pressure applied to the accelerator pedal of the car 1; (5) a steering angle sensor that detects the rotation angle (steering angle) of the steering wheel of the car 1; (6) a brake sensor that detects the amount of pressure applied to the brake pedal of the car 1; (7) a position sensor that detects the position (vehicle position information) of the car 1 using a Global Positioning System (GPS); (8) an in-vehicle camera installed on the rearview mirror, dashboard, etc. of the car 1 and photographing the driver's expression, posture, in-vehicle environment, etc.; (9) an in-vehicle sensor that acquires the driver's biological information (body temperature, heart rate, respiration, etc.).

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

[0068] Server device 200 includes a communication interface 210. Communication interface 210 is connected to the Internet N and includes circuitry for communicating with other servers, computers, vehicles V, etc. In this example, communication interface 210 communicates with communication interface 18 of vehicle V via the Internet N.

[0069] Server device 200 includes processor 220 and storage unit 230. Processor 220 is configured to perform a specified function by executing a program stored in storage unit 230. For example, when upgrade information for vehicle V is released, processor 220 generates an upgrade request RQ. Then, processor 220 sends the upgrade request RQ to the vehicle to be upgraded via communication interface 210.

[0070] 2-2. Hardware Configuration Example (2) This example is an example of a server device 200 configured to communicate with a vehicle V, which is equivalent to a computer executing a software upgrade method.

[0071] Figure 9 This is a block diagram representing other hardware components of a software upgrade system. In Figure 9 In the example, a portion of the functionality of the upgrade implementation judgment module 1 is configured in the server device 200, which is consistent with... Figure 8 The composition is different. Accompanying this is the indication that... Figure 1 The functional block diagram is as follows: Figure 10 That change. Furthermore, in Figure 9 In the middle, to and Figure 8 The corresponding constituent elements are labeled with the same reference numerals. Similarly, in Figure 10 In the middle, to and Figure 1 The corresponding constituent elements are labeled with the same reference numerals. In the following description, the focus is on the differences from the aforementioned "1. Overview of the software upgrade method" and "2-1. Hardware configuration example (1)".

[0072] exist Figure 9 In its composition, with Figure 8 Similarly, the vehicle V is equipped with multiple ECUs. The 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 these ECUs, are the same as in the aforementioned “2-1. Hardware Configuration Example (1)”, and their specific descriptions are omitted here.

[0073] The gateway ECU includes a processor 16. The processor 16 is configured to perform the functions of the aforementioned upgrade implementation judgment module 1 by executing a program stored in the memory M4. Figure 9 In the example, processor 16 only contains Figure 8The calculation module 12 in the upgrade implementation judgment module 1 is described in the record. The processing performed by the calculation module 12 will be explained later.

[0074] The gateway ECU includes a memory M4. Memory M4 is, for example, non-volatile memory. Memory M4 can be, for example, flash memory. Firmware FW41 and FW42 are stored in memory M4. In memory M4, [the following text appears to be incomplete and requires further context: "and..."] Figure 8 Similarly, the memory M stores the number of times it has been rewritten. On the other hand, with Figure 8 Depending on the circumstances, compatibility information, version information, and package data may not need to be stored.

[0075] Moreover, the gateway ECU contains and Figure 8 The same communication interface 18.

[0076] exist Figure 9 In its configuration, the server device 200 includes a communication interface 210. The configuration of the communication interface 210 is similar to... Figure 8 same.

[0077] Server device 200 includes a processor 220 and a storage unit 230. The processor 220 is configured to perform a predetermined function by executing a program stored in the storage unit 230. The processor 220 has equivalent to... Figure 8 The upgrade implementation judgment module 201 is an upgrade implementation judgment module 1. The upgrade implementation judgment module 201 includes a management module 211, which corresponds to the management module 11, and a judgment module 215, which corresponds to the judgment module 15. The storage unit 230 stores upgrade information (hereinafter referred to as "upgrade information") obtained from each vehicle V and used for upgrading the software of the vehicle. The upgrade information is stored in association with identification information used to identify the destination vehicle V. The upgrade 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 aforementioned embodiment, and their description is omitted here. Furthermore, the storage unit 230 records rewrite information of the memory M obtained from each vehicle V.

[0078] Next, refer to Figure 3 and Figure 10 The following description will explain the operation of the upgrade system when a portion of the function of the upgrade implementation determination module 1 is configured in the server device 200. This description will be based on the aforementioned implementation method (…). Figure 1 The explanation will focus on the differences between the two.

[0079] exist Figure 3In step S21, the upgrade implementation judgment module 201 of the server device 200 accepts the firmware upgrade request RQ for the ECU1-ECU3 and the gateway ECU of the vehicle V. Similar to the implementation method, when the upgrade implementation judgment module 201 accepts the software upgrade request, that is, receives the software upgrade request, the process proceeds to the next step S22. The specific content of the upgrade request RQ is the same as... Figure 3 same.

[0080] In step S22, the upgrade implementation determination module 201 refers to the memory rewrite count information registered for the vehicle V (hereinafter referred to as "target vehicle V") that is the object of the upgrade request RQ. The memory rewrite count information can be obtained, for example, by requesting the target vehicle V for the memory rewrite count information after receiving the upgrade request RQ. The method for obtaining the memory rewrite count information in the target vehicle V is the same as in the aforementioned embodiment. For example, the calculation module 12 of the target vehicle V accesses the memory M (e.g., memory M1 to M4) and obtains the memory consumption information. Furthermore, the calculation module 12 of the target vehicle V calculates the memory rewrite count based on the obtained memory consumption information. The memory rewrite count is summarized and sent to the server device 200 via the communication interface 18.

[0081] In step S23, the upgrade implementation determination module 201 determines which memory M is capable of being upgraded. The specific determination process is the same as in the aforementioned implementation method. Specifically, based on compatibility information and the upgrade request, the upgrade implementation determination module 201 determines the software group to be upgraded. Then, if the number of rewrites of all memory groups storing the firmware is less than a predetermined baseline value, the upgrade implementation determination module 201 determines that a software upgrade will be performed based on the upgrade request RQ. On the other hand, if the number of rewrites of any memory M storing the software group reaches the predetermined baseline value, it is determined that a software upgrade will not be performed based on the upgrade request RQ.

[0082] In step S24, the upgrade implementation judgment module 201 refers to the version information of the software that is the upgrade request object.

[0083] In step S25, it is determined whether a suitable data packet exists. If a suitable data packet exists, the process proceeds to the next step, S26. On the other hand, if no suitable data packet exists, it is determined that the software upgrade involved in the upgrade request cannot be implemented, and the process ends.

[0084] In step S26, the upgrade implementation judgment module 201, based on the appropriate packet information determined in "1-5. Appropriate Data Packet Judgment", sends the upgrade request and upgrade object information containing upgrade data and upgrade capacity information to the gateway ECU of vehicle V (see reference). Figure 9 In the gateway ECU (reference) Figure 9 In this process, based on the received upgrade object information, valid upgrade data is sent to the upgrade object storage.

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

[0086] The upgrade method for this software includes having the computer perform the following steps (1) to (3).

[0087] The software upgrade method includes: (1) accepting an upgrade request RQ for the software stored in the memory of the ECU. The upgrade request RQ is received, for example, by the ECUG via the communication interface 18.

[0088] The upgrade method for this software includes: (2) determining the firmware group to be upgraded based on the upgrade request, according to the compatibility information of the firmware group (equivalent to software) used in implementing the specified function. As mentioned above, the compatibility information includes information indicating the compatibility between the firmware used in implementing the specified function. Software version information can be used as compatibility information to manage the compatibility between different software.

[0089] The software upgrade method includes: (3) determining that a software upgrade can be performed based on the upgrade request RQ if the number of rewrites in all memories storing the firmware group in multiple ECUs is less than a specified baseline value. For example, if a firmware group consisting of firmware FW11 and firmware FW23 is the target of an upgrade request RQ, and the number of rewrites in memories M1 and M2 is less than a specified baseline value, it is determined that a software upgrade can be performed based on the upgrade request RQ. On the other hand, it includes: determining that a software upgrade will not be performed based on the upgrade request if the number of rewrites in any memory storing the firmware group reaches a specified baseline value. For example, in the above example, if a firmware group consisting of firmware FW11 and firmware FW23 is the target of an upgrade request RQ, and the number of rewrites in memory M1 or memory M2 reaches a specified baseline value, it is determined that a software upgrade will not be performed based on the upgrade request RQ.

[0090] Based on the above method, OTA failures caused by memory rewrite limits can be prevented. Furthermore, for upgrade requests (RQs), compatibility information of the software group (e.g., firmware group) used to implement the specified function is used to determine whether the functions implementing the specified function can be treated as a single unit for upgrade, thus ensuring the coordination of related functions.

[0091] The second method disclosed herein is as follows: Based on the first method described above, the upgrade request may include an upgrade priority. Furthermore, it can be determined whether to upgrade the software based on the upgrade request by comparing the number of times the memory M has been overwritten with a baseline value and the upgrade priority. As a third method, based on the second method described above, the higher the upgrade priority, the higher the specified baseline value.

[0092] In this way, by using priority to determine performance, the criteria for upgrading high-priority functions, such as those with high importance, can be relaxed, allowing for upgrades based on upgrade requests (RQs). This ensures that memory overwrite limits are not reached, while also enabling more reliable upgrades for critical functions.

[0093] The fourth approach disclosed herein is as follows: Based on any of the first to third approaches described above, the compatibility information may be included in the package data that associates the functions of the software with each other using the version information of each software.

[0094] The fifth method disclosed herein is as follows: Based on any of the first to third methods described above, the upgrade request may include version information of the software to be upgraded. The upgrade data used for the upgrade may be provided in the form of package data as a software group. The software upgrade method of the fifth method may determine whether it is compatible with the package data based on the version information of the software involved in the upgrade request. Furthermore, it may include: if compatible with the package data, determining that the software upgrade can be performed based on the upgrade request; conversely, if incompatible with the package data, determining that the software upgrade will not be performed based on the upgrade request.

[0095] By managing this as package data, the following effects can be achieved: For example, it is easy to determine whether an upgrade can be implemented based on the upgrade request (RQ). For example, it can prevent the software upgrade from resulting in a combination of software versions that the developer did not intend. For example, it facilitates so-called regression, where the software reverts to a previous version combination due to certain reasons (such as upgrade failure). For example, it simplifies the management of software version combinations in vehicles.

[0096] The sixth aspect of this disclosure relates to an upgrade procedure for software used in vehicles equipped with multiple ECUs (Electronic Control Units). This procedure includes causing a computer to perform the following steps (1) to (3).

[0097] Specifically, it includes: (1) accepting upgrade requests for software stored in the memory of the ECU; (2) determining the software group to be upgraded based on the compatibility information of the software group (e.g., firmware group) used in implementing the specified function, according to the upgrade request; and (3) determining that the software can be upgraded based on the upgrade request if the number of rewrites in all the memories storing the software group in multiple ECUs is less than a specified benchmark value, and on the other hand, determining that the software will not be upgraded based on the upgrade request if the number of rewrites in any memory storing the software group reaches the specified benchmark value.

[0098] According to the sixth method described above, similar to the first method, OTA failures caused by memory rewrite limits can be prevented. Furthermore, for upgrade requests (RQs), compatibility information of the software group (e.g., firmware group) used to implement the specified function is used to determine whether the functions implementing the specified function can be treated as a single unit for upgrade, thus ensuring the coordination of related functions.

[0099] The seventh aspect of this disclosure relates to a software upgrade system for a vehicle equipped with multiple ECUs (Electronic Control Units), including a first ECU and a second ECU. Each of the multiple ECUs has a memory whose software can be rewritten. In the example of the above embodiment, ECU1, ECU2, ECU3, and ECUG are examples of multiple ECUs. ECU1 has a memory M1. Similarly, ECU2 has a memory M2, ECU3 has a memory M3, and ECUG has a memory M4. Furthermore, the software upgrade system includes a communication interface 18 for accepting software upgrade requests (RQs). Additionally, the upgrade system has a management module 11 that manages the number of times the memory M of the multiple ECUs is rewritten, the version information of the software stored in each ECU, and the compatibility information between the versions of the software group used to implement the specified functions. In the example of the embodiment, the number of times the memory M is rewritten, the software version information, and the compatibility information are stored in memory M4 and managed by the management module 11. Furthermore, the upgrade system includes a judgment module that, when the communication interface 18 receives an upgrade request for the first software stored in the memory of the first ECU, determines other second software that is to be upgraded along with the first software based on version information and compatibility information, and determines whether to perform a software update 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 storing the second software has been rewritten.

[0100] According to the seventh method described above, similar to the first method, OTA failures caused by memory rewrite limits can be prevented. Furthermore, for upgrade requests (RQs), compatibility information of the software group (e.g., firmware group) used to implement the specified function is used to determine whether the functions implementing the specified function can be treated as a single unit for upgrade, thus ensuring the coordination of related functions.

[0101] As an eighth method, based on the seventh method mentioned above, the management module 11 and the judgment module 15 are set in any one of the multiple ECUs.

[0102] Therefore, the upgrade decision-making process can be completed in vehicle V, thus reducing the load on management devices (e.g., server devices) that manage upgrades to vehicle software.

[0103] As a ninth method, the seventh method described above may further include a server device 200 configured to communicate with the vehicle V. Furthermore, the server device may include a management module 211 and a judgment module 215.

[0104] Therefore, in vehicle V, an upgrade request is sent after determining whether an upgrade is possible, thus reducing the processing load in vehicle V.

[0105] (Other implementation methods) Furthermore, the disclosed technology is not limited to the above-described embodiments, and alternatives may be made without departing from the spirit of the claims.

[0106] Industrial applicability The technology disclosed herein is useful as a method, system, and procedure for upgrading software for vehicles.

Claims

1. A method for upgrading vehicle software, wherein the software upgrade method for a vehicle equipped with multiple ECUs (Electronic Control Units) is executed by a computer, characterized in that... Include: Accept upgrade requests for software stored in the memory of the ECU; Based on the compatibility information of the software group used to implement the specified functions, the software group that is to be upgraded is determined according to the upgrade request. as well as If the number of rewrites in all the memories storing the software group in the plurality of ECUs is less than a predetermined benchmark value, it is determined that the software can be upgraded based on the upgrade request. On the other hand, if the number of rewrites in any memory storing the software group reaches the predetermined benchmark value, it is determined that the software will not be upgraded based on the upgrade request.

2. The method for upgrading vehicle software according to claim 1, characterized in that, The upgrade request includes the upgrade priority. The decision to upgrade the software based on the upgrade request is made by comparing the number of times the memory has been overwritten with a baseline value and by considering the upgrade priority.

3. The method for upgrading vehicle software according to claim 2, characterized in that, The higher the priority of the upgrade, the higher the specified benchmark value.

4. The method for upgrading vehicle software according to claim 1, characterized in that, The compatibility information is contained in package data that associates the functions of software with each other using the version information of each software.

5. The method for upgrading vehicle software according to claim 1, characterized in that, The upgrade request includes version information of the software to be upgraded. The upgrade data used for the upgrade is provided in the form of package data for the software group. The method for upgrading the software used in the vehicle includes: The version information of the software involved in the upgrade request is used to determine whether it is compatible with the package data; as well as If the data is compatible with the package data, it is determined that the software can be upgraded based on the upgrade request; otherwise, if the data is not compatible with the package data, it is determined that the software cannot be upgraded based on the upgrade request.

6. A software upgrade program product for vehicles, specifically for vehicles equipped with multiple ECUs (Electronic Control Units), characterized in that... Have the computer perform the following steps: Accept upgrade requests for software stored in the memory of the ECU; Based on the compatibility information of the software group used to implement the specified functions, the software group that is to be upgraded is determined according to the upgrade request. as well as If the number of rewrites in all the memories storing the software group in the plurality of ECUs is less than a predetermined benchmark value, it is determined that the software can be upgraded based on the upgrade request. On the other hand, if the number of rewrites in any memory storing the software group reaches the predetermined benchmark value, it is determined that the software will not be upgraded based on the upgrade request.

7. A software upgrade system for vehicles, characterized in that, Each of the multiple ECUs has a memory whose software can be rewritten. The software upgrade system for the vehicle includes: The interface handles software upgrade requests; The management module manages the number of times the memory of the multiple ECUs is overwritten, the version information of the software stored in each of the ECUs, and the compatibility information between the versions of the software group used to implement the specified functions. as well as The judgment module, when the interface accepts an upgrade request for the first software stored in the memory of the first ECU, determines other second software that is also an upgrade target along with the first software based on the version information and the compatibility information, and determines whether to perform a software update 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 storing the second software has been rewritten.

8. The vehicle software upgrade system according to claim 7, characterized in that, Each of the plurality of ECUs has the management module and the judgment module.

9. The vehicle software upgrade system according to claim 7, characterized in that, The software upgrade system for the vehicle also includes a server device configured to communicate with the vehicle. The server device includes the management module and the judgment module.

Images