Vehicle software update system

Abstract

A server of this vehicle software update system that manages the software updates of a plurality of function-specific ECUs in a vehicle after a transfer comprises: an acquisition unit A that acquires installed function information on the vehicle before the transfer; an acquisition unit B that acquires installed function information on the vehicle after the transfer; an acquisition unit C that acquires user selection function information from a user terminal; a differential extraction unit that extracts differences between the installed function information on the vehicle before the transfer, the installed function information on the vehicle after the transfer, and user selection function information; and an update process determination unit that selects a necessary software update process and generates update function information according to the contents of the differences. A vehicle control device of the vehicle after the transfer includes a software update determination unit that controls the software update and the priority in the plurality of function-specific EUs according to the update function information delivered from the server. Each of the plurality of function-specific ECUs of the vehicle after the transfer has a software update processing unit that executes a software update method delivered by the vehicle control device of the vehicle after the transfer.

Description

Technical Field

[0006] , ,

[0005] , , , ,

[0001] The present disclosure relates to a vehicle software update system.

Background Art

[0002] With the multi-functionality and high functionality of features such as autonomous driving or advanced driving assistance functions, when driving a vehicle for the first time, such as a newly purchased vehicle or a rental car, or when driving a vehicle after someone else has driven it, there is a desire to continue using the functions and settings that the user values. Also, driving a new vehicle without being used to it may lead to accidents. To solve this problem, vehicle personalization (customization for an individual) is effective.

[0003] A technique of transmitting user-preferred settings customized by a user to an in-vehicle electronic control device to be rewritten and operating it with the user-preferred settings is known, for example, from Patent Document 1.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

[0007] When personalizing a system, if many features are pre-installed and then user-selectable features are added, challenges arise such as memory exhaustion due to increased memory capacity and increased update times. Furthermore, frequent memory updates can shorten memory lifespan (leading to failure). [Means for solving the problem]

[0008] This disclosure includes a vehicle control device mounted on a vehicle and a server that communicates via a network, The aforementioned vehicles include the vehicle before the transfer and the vehicle after the transfer. A vehicle software update system that manages software updates for multiple functional electronic control devices within the vehicle after the transfer, The aforementioned server, The acquisition unit A acquires information on the functions installed in the vehicle before the transfer, The acquisition unit B acquires information on the functions installed in the vehicle after the transfer, An acquisition unit C that acquires user selection function information from the user terminal, A difference extraction unit extracts the difference between the installed function information of the vehicle before the transfer, the installed function information of the vehicle after the transfer, and the user-selected function information. An update process determination unit selects the necessary software update process according to the content of the difference and generates update function information based on the necessary software update process, It has, In the vehicle after the transfer, The vehicle control device has a software update determination unit that controls software updates and prioritization within the plurality of function-specific electronic control devices in accordance with the update function information distributed from the server. Each of the aforementioned plurality of function-specific electronic control devices has a software update processing unit that executes a software update method notified by the vehicle control device of the vehicle after the transfer.

[0009] The functions that the user considers important can be obtained by acquisition unit C. Differential information can be obtained by acquisition units A and B. By comparing this differential information with the information on the functions that the user considers important obtained by acquisition unit C (by comparing the two sets of information), the software update decision unit determines which software should be updated. [Effects of the Invention]

[0010] According to this disclosure, since software updates will only include the necessary functions and differential parts required by the user, it will be possible to personalize the vehicle after the switch, and this will have the effect of shortening the software update time, reducing the capacity of the non-volatile memory of the function-specific electronic control unit, and extending the memory life of the non-volatile memory of the function-specific electronic control unit. [Brief explanation of the drawing]

[0011] [Figure 1] A block diagram showing the overall configuration of a vehicle software update system according to the first embodiment. [Figure 2] Sequence diagram of a vehicle software update system according to the first embodiment. [Figure 3] A data flow diagram illustrating a software update method for a vehicle software update system according to the first embodiment. [Figure 4] A flowchart illustrating the difference extraction process according to the first embodiment. [Figure 5] A flowchart illustrating the update process determination according to the first embodiment. [Figure 6] An example of setting the priority of each function-specific ECU according to the second embodiment. [Figure 7] A flowchart illustrating the priority setting process according to the second embodiment. [Figure 8] A flowchart illustrating the ECU update process according to the second embodiment. [Figure 9] This diagram shows a typical configuration example of a control device included in a function-specific ECU. [Modes for carrying out the invention]

[0012] Hereinafter, this embodiment will be described with reference to the accompanying drawings. In the accompanying drawings, functionally identical elements may sometimes be denoted by the same reference numerals. Although the accompanying drawings show embodiments and implementation examples in accordance with the principles of the present disclosure, these are for the purpose of understanding the present disclosure and are not used to limit the interpretation of the present disclosure in any way. The description in this specification is merely a typical example and does not limit the scope of the claims or application examples of the present disclosure in any sense.

[0013] In this embodiment, although the description is made in sufficient detail for those skilled in the art to implement the present disclosure, other implementations and forms are also possible, and it is necessary to understand that changes in configuration and structure and replacement of various elements can be made without departing from the scope and spirit of the technical idea of the present disclosure. Therefore, the following description should not be construed as being limited thereto.

[0014] Hereinafter, embodiments of the present disclosure will be described with reference to FIGS. 1 - 9.

[0015] (First Embodiment) FIG. 1 is a block diagram showing the overall configuration of a vehicle software update system according to the first embodiment. The vehicle software update system 10 shown in FIG. 1 includes a center 100 which is an OTA (Over The Air) server, a vehicle after replacement (Vehicle B, the second vehicle) 200, a vehicle before replacement (Vehicle A, the first vehicle) 300, and a user terminal 400, and these are connected to each other via a network 20. The network 20 may be constituted by, for example, a mobile phone network, the Internet, etc. The vehicle software update system 10 is a system for managing software updates of a plurality of function-specific electronic control units (ECUs: Electronic Control Unit) 206, 208, 210 in the vehicle 200 after replacement.

[0016] The server, Center 100, can communicate with the vehicle control devices 301 and 201 installed in the vehicles 300 and 200 via the network 20. The Center 100 receives information on installed functions from the vehicle after transfer 200, the vehicle before transfer 300, and the user terminal 400 via the network 20, and transmits (distributes) update function information for updating the software of each function-specific ECU 206, 208, and 210 in the vehicle after transfer 200. The Center 100 includes a vehicle / user authentication processing unit 101, a vehicle installed function information receiving unit 102, a user selection function receiving unit 103, a difference extraction unit 104, an update processing determination unit 105, and an update function information transmission unit 106.

[0017] The replacement vehicle 200 consists of a vehicle control device 201 that performs software update control and multiple function-specific ECUs 206, 208, and 210. In this example, the multiple function-specific ECUs 206, 208, and 210 are the autonomous driving ECU 206, the brake ECU 208, and the engine ECU 210. Each of the function-specific ECUs 206, 208, and 210 includes an update processing unit (also called a software update processing unit) 207, 209, and 211, respectively. Note that the ECUs installed in the replacement vehicle 200 are not limited to those shown in Figure 1, and other ECUs may be installed. Figure 9 shows a typical configuration example of a control device included in a function-specific ECU. In this example, the processor PRO, which is a control device included in the function-specific ECUs such as the autonomous driving ECU 206, the brake ECU 208, and the engine ECU 210, is formed on a single semiconductor substrate SUB made of, for example, a single crystal such as silicon, as shown in Figure 9. The processor PRO includes a central processing unit CPU capable of executing software, a random access memory RAM composed of volatile memory that serves as a temporary workspace for the central processing unit CPU, a flash-type read-only memory FROM composed of non-volatile memory that stores the software PROG executed by the central processing unit CPU as data, a peripheral function circuit PRI, and a bus BUS. The flash-type read-only memory FROM is a semiconductor memory that allows data, which is the software PROG, to be rewritten. In this embodiment, the flash-type read-only memory FROM is the memory where the updated software is stored. The bus BUS interconnects the central processing unit CPU, the random access memory RAM, the flash-type read-only memory FROM, and the peripheral function circuit PRI.

[0018] The vehicle control device 201 includes a vehicle authentication processing unit 202, an onboard function information transmission unit 203, an update function information reception unit 204, and a software update determination unit 205.

[0019] The vehicle before replacement 300 is equipped with a vehicle authentication processing unit 301 and an onboard function information transmission unit 302. The vehicle before replacement 300 is also equipped with one or more ECUs, but since they are not relevant to the present invention, their description is omitted in Figure 1.

[0020] The user terminal 400 consists of a user authentication processing unit 401, a user selection function information input unit 402, and a user setting data area 403. The user terminal 400 is either a dedicated terminal or a portable terminal carried by the user (such as a tablet PC or smartphone). After user authentication, the user terminal 400 connects to the center 100 and becomes available for use. The user setting data area 403 stores information such as seat and mirror position information, brake and steering sensitivity information, and function priority setting data (see Figure 6), and transmits this information to the center 100 as user selection function information.

[0021] Figure 2 is a sequence diagram of a vehicle software update system according to the first embodiment. The vehicle before replacement 300 sends an authentication request from the vehicle authentication processing unit 301 to the center 100 (P1). The center 100 performs authentication in the vehicle / user authentication processing unit 101 and sends a completion notification back after authentication is complete (P2). The vehicle after replacement 200 sends an authentication request from the vehicle authentication processing unit 202 to the center 100 (P3). The vehicle / user authentication processing unit 101 performs authentication and sends a completion notification back after authentication is complete (P4). Subsequently, the vehicle before replacement 300 and the vehicle after replacement 200 transmit the installed function information to the vehicle installed function information receiving unit 102 of the center 100 (P5, P6). In other words, the vehicle-mounted function information receiving unit 102 has a first acquisition unit (acquisition unit A) that acquires the mounted function information of the vehicle 300 before the transfer from the mounted function information transmitting unit 302, and a second acquisition unit (acquisition unit B) that acquires the mounted function information of the vehicle 200 after the transfer from the mounted function information transmitting unit 203.

[0022] The user terminal 400 sends a user authentication request to the center 100 from the user authentication processing unit 401 (P7). The center 100 performs user authentication in the vehicle / user authentication processing unit 101 and sends a completion notification after authentication is complete (P8). After authentication is complete, the user inputs the user selection function on the user selection function information input unit 402 of the user terminal 400 (P9). After this input, the user terminal 400 transmits the user selection function information to the user selection function receiving unit 103 of the center 100 (P10). In other words, the user selection function receiving unit 103 has a third acquisition unit (acquisition unit C) that acquires the user selection function information (information on the installed functions selected by the user) from the user selection function information input unit 402. Note that the order of authentication of the pre-transfer vehicle 300, the post-transfer vehicle 200, and the user terminal 400 is not limited to the above example, and the order can be changed. Furthermore, the certification of each vehicle (300,200) can be carried out continuously or periodically.

[0023] Center 100 receives function information (function information of the pre-transfer vehicle 300, function information of the post-transfer vehicle 200, and user-selected function information) transmitted from the pre-transfer vehicle 300, the post-transfer vehicle 200, and the user terminal 400 using the vehicle-mounted function information receiving unit 102 and the user-selected function receiving unit 103, and then performs difference extraction using the difference extraction unit 104 (P11). Subsequently, the update processing determination unit 105 performs an update processing determination (P12), and the update function information transmission unit 106 transmits (distributes) the update function information to the post-transfer vehicle 200 (P13). The update processing determination unit 105 performs an update processing determination according to the content of the difference, selects the necessary software update processing, and generates update function information based on the necessary software update processing. The update function information transmission unit 106 transmits the update function information from the update processing determination unit 105 to the update function information receiving unit 204 of the post-transfer vehicle 200.

[0024] After the vehicle change, the vehicle 200 receives update function information at the update function information receiving unit 204, and the software update determination unit 205 determines the software update content based on the update function information (P14). After determining the software update method, the software update determination unit 205 sends an update instruction to each function-specific ECU (in the example of Figure 2, the software update processing unit 207 of the automatic driving ECU 206) (P15). The software update determination unit 205 can be configured to control software updates and priorities within multiple function-specific electronic control devices 206, 208, and 210, as will be explained in Embodiment 2 below. For information on priorities, please refer to the explanation in Embodiment 2. Software update methods include new addition (Install), deletion (Remove), update (Update), and no processing (Skip). For information on software update methods, please refer to the explanation in Figure 3 below.

[0025] The autonomous driving ECU 206 executes the update process using the update processing unit 207 of the autonomous driving ECU 206 in accordance with instructions notified by the software update determination unit 205 in the vehicle control device 201 of the vehicle 200 after the transfer (P16). In other words, each of the multiple function-specific electronic control devices 206, 208, and 210 has a software update processing unit 207, 209, and 211 that executes the software update method notified by the software update determination unit 205 in the vehicle control device 201 of the vehicle 200 after the transfer.

[0026] After the update is complete, a notification of update completion is sent to the vehicle control unit 201 (P17). The vehicle control unit 201 then notifies the center 100 of the update completion (P18), and the center 100 then sequentially notifies the user terminals 400 of the update completion (P19).

[0027] Figure 3 is a data flow diagram illustrating the software update method for a vehicle software update system according to the first embodiment. Figure 3 illustrates the user's selected function information and the update method.

[0028] For example, let's assume that the autonomous driving ECU 206 has four functions as autonomous driving support functions: function A (FA), function B (FB), function C (FC), and function D (FD). The vehicle before replacement 300 is equipped with function A (FA), function B (FB), and function D (new version) (FDNE). The vehicle after replacement 200 is equipped with function A (FA), function C (FC), and function D (old version) (FDOL). If the user selects function A (FA), function B (FB), and function D (new version) (FDNE) as the functions they need, the center 100, using the difference extraction unit 104 and the update processing determination unit 105, determines the functions required for the vehicle after replacement 200 and the update method.

[0029] After the vehicle change, vehicle 200 updates the software in the autonomous driving ECU 206 according to instructions from center 100 (ECU update process: P16). In the example in Figure 3, since there are no changes to function A (FA), no processing is performed (Skip), function B (FB) is newly added (Install), function C (FC) is deleted (Remove), and function D (FD) is updated from the old version (FDOL) to the new version (FDNE) (Update). By utilizing differential information as described above, the rewrite time and storage capacity (capacity of the software PROG) of the flash-type read-on rememory FROM can be suppressed. Therefore, according to this embodiment, effects such as a reduction in the storage capacity of the flash-type read-on rememory FROM, a reduction in update time, and an extension of the memory life of the flash-type read-on rememory FROM can be obtained. Flash-type read-on-re-memory (FROM) has the characteristic that its lifespan is shortened if its stored contents are frequently rewritten. Therefore, reducing the number of rewrites (updates) can extend the lifespan of flash-type read-on-re-memory (FROM).

[0030] Referring to the flowcharts in Figures 4 and 5, the operation of the difference extraction unit 104 (steps S401-S409 in Figure 4) and the operation of the update processing determination unit 105 (steps S501-S511 in Figure 5) will be explained.

[0031] First, in Figure 4, the difference extraction unit 104 starts the difference extraction process (S401).

[0032] Next, the difference extraction unit 104 acquires vehicle-mounted function information (S402). Examples of vehicle-mounted function information include the type of ECU by function, ECU function information, dependencies between ECUs, manufacturer name, vehicle model name, and platform generation. In this embodiment, the use of SOTA (Software Over the Air) Adaptive Platform (AP), which is standardized by the standardization organization AUTOSAR, is recommended, and the compatible version of the Adaptive Platform is included as a determination item.

[0033] In S403, the difference extraction unit 104 determines the manufacturer, vehicle model, and platform generation. If it is compatible (OK), the processing of the difference extraction unit 104 moves to S404. If it is not compatible (NG), the processing of the difference extraction unit 104 moves to S408.

[0034] In S404, the difference extraction unit 104 performs a comparison and extraction of the installed functions and user-selected functions. The specific extraction method is as explained in Figure 3.

[0035] In S405, the difference extraction unit 104 selects the function-specific ECU and software related to the extraction function.

[0036] Next, in S406, the update processing determination unit 105 performs resource determination. Resources include, for example, hardware resources required to execute the extraction function, such as sensor configuration, software resources, such as software version, and required memory size. The information used for these resource determinations is assumed to be included as part of the vehicle function installation information. If the resource determination is OK (YES), the processing of the difference extraction unit 104 moves to S407. If the resource determination is NG (No), the processing of the difference extraction unit 104 moves to S408.

[0037] In S407, the difference extraction unit 104 determines the target ECU and the update software.

[0038] In S408, the difference extraction unit 104 determines that the judgment conditions are not met and issues an unprocessed notification. In other words, in S408, the update process is canceled. The user is then notified of the cancellation of the update process as an unprocessed notification.

[0039] As a result, the difference extraction process is completed by the difference extraction unit 104 (S409).

[0040] Next, the update process determination shown in Figure 5 will be explained. In Figure 5, the update process determination unit 105 starts the update process determination (S501).

[0041] The update processing determination unit 105 obtains the target ECU and function information from the results of the difference extraction process described in Figure 4 (S502) and obtains the function information of the vehicle after replacement (S503). In S504, the update processing determination unit 105 checks whether the function is not installed in the vehicle after replacement 200. If it is not installed (YES), the update processing determination unit 105 proceeds to S507. If it is NO (installed) in S504, the update processing determination unit 105 proceeds to S505. In S505, the update processing determination unit 105 checks whether the function is unnecessary in the vehicle after replacement 200. If it is an unnecessary function (YES), the update processing determination unit 105 proceeds to S508. If it is NO (necessary function) in S505, the update processing determination unit 105 proceeds to S506. In S506, the update processing determination unit 105 checks whether an update such as a version upgrade is necessary. If an update is necessary (YES), the processing of the update processing determination unit 105 moves to S509. If an update is not necessary in S506 (NO), the processing of the update processing determination unit 105 moves to S510.

[0042] The update processing determination unit 105 selects "Add New (Install)" in S507 and "Remove" in S508. The update processing determination unit 105 selects "Update" in S509 and "Skip" in S510. After that, the update processing determination by the update processing determination unit 105 is completed (S511). In other words, the update processing determination unit 105 is configured to select the type of software update processing from "Add (Install)", "Update", "Remove", and "Skip".

[0043] Therefore, each function-specific ECU (for example, the autonomous driving ECU 206, the brake ECU 208, and the engine ECU 210) installed in the vehicle 200 after the change will execute the software update process using each update processing unit (207, 209, 211) according to the instructions from the software update determination unit 205. In other words, each update processing unit (207, 209, 211) can perform new addition (Install), deletion (Remove), update (Update), or no processing (Skip). Each update processing unit (207, 209, 211) will perform one of the instructed actions from new addition (Install), deletion (Remove), update (Update), and no processing (Skip) according to the instructions from the software update determination unit 205.

[0044] (Second Embodiment) The vehicle software update system of the second embodiment will be described with reference to Figures 6 to 8.

[0045] While the first embodiment described the case where only the autonomous driving ECU 206 was to be updated, the second embodiment shows an example of updating multiple ECUs. The vehicle software update system in the second embodiment can utilize the vehicle software update system of the first embodiment described in Figures 1 to 5. Furthermore, since the vehicle software update system in the second embodiment operates similarly to the vehicle software update system of the first embodiment described in Figures 1 to 5, redundant explanations will be omitted.

[0046] Figure 6 shows an example of priority settings for each function-specific ECU according to the second embodiment. Figure 6 shows an example of priority settings for function-specific ECUs installed in the replacement vehicle 200, and describes examples of ECU type 600, setting function 610, update target 620, and various priority levels 630. In this example, the ECU type 600 includes the engine ECU 60A (corresponding to 210 in Figure 1), brake ECU 60B (corresponding to 208 in Figure 1), steering ECU 60C ​​(corresponding to 206 in Figure 1), autonomous driving ECU 60D, mechanical system control ECU 60E, and information system ECU 60F. In this example, the setting function 610 includes engine control 61A, brake sensitivity 61B, steering sensitivity 61C, driver assistance / autonomous driving 61D, seat position and mirror position 61E, and car navigation / air conditioning (car navigation system / air conditioner) 61F. In this example, the item to be updated, 620, contains data and programs 62A, 62B, and data 62C.

[0047] The various priority levels 630 can be classified according to the factors they prioritize, such as vehicle function priority 63A, safety priority 63B, update size priority 63C, and user setting priority 63D. The numbers (1-6) listed for each priority level 630 indicate that the priority level increases from smallest to largest (priority: 1>2>3>4>5>6). As shown in Figure 6, the appropriate priority level changes depending on the factors prioritized (63A, 63B, 63C, 63D). Note that the priority numbers (1-6) listed in Figure 6 are provided as representative examples to illustrate this embodiment and are not limiting.

[0048] In the second embodiment, as shown in Figure 6, the priority setting method 640 can be selected from initial setting (1) 641, initial setting (2) 642, automatic determination 643, and user setting 644.

[0049] Referring to the flowchart in Figure 7, the priority setting process (steps S701-S710 in Figure 7) will be explained. Priority setting is performed by the software update determination unit 205 of the vehicle 200 after the transfer.

[0050] The software update determination unit 205 starts the priority setting process (S701). Next, the software update determination unit 205 acquires the ECU information to be updated (S702). In S703, the software update determination unit 205 checks whether there are multiple ECUs to be updated. If there are multiple (YES) in S703, the software update determination unit 205 proceeds to S704. If there are not multiple (NO) in S703, the software update determination unit 205 terminates its processing because priority determination is not required (S710). In S704, the software update determination unit 205 checks whether the user setting data area 403 contains priority settings. If there are user settings (YES) in S704, the software update determination unit 205 proceeds to S707. If there are no user settings (NO) in S704, the software update determination unit 205 proceeds to S705.

[0051] In S705, the software update determination unit 205 calculates the update size for each ECU to be updated. If the difference in update size is small, there is little benefit in prioritizing update size, so the software update determination unit 205 checks whether it is above a preset threshold (for example, 1 Mbyte or more) (S706). If the difference in update size is above the threshold (YES), the software update determination unit 205 proceeds to S708. If the difference in update size is within the threshold (NO), the software update determination unit 205 proceeds to S709.

[0052] In S707, the software update determination unit 205 sets the priority setting method 640 to user setting 644.

[0053] In S708, the software update determination unit 205 sets the priority setting method 640 to automatic determination 643. Automatic determination 643 sets the update priority in descending order of update size. The reason for setting priority based on update size is to reduce the probability of update failure.

[0054] In S709, the software update determination unit 205 sets the priority setting method 640 to the initial value (2) 642 (safety-first 63B). Note that the initial value (2) 642 can also be changed to the initial value (1) 641 or another initial value setting. In this embodiment, in order to ensure the safety of the vehicle's functions in the event that the update fails midway, the initial value of the priority setting method 640 is set to the initial value (2) 642 of safety-first 63B.

[0055] After each setting is complete, the priority setting process by the software update determination unit 205 ends (S710).

[0056] Therefore, the software update determination unit 205 is configured to control software updates and priorities within multiple function-specific electronic control units 206, 208, and 210, as explained in P15 of Figure 2.

[0057] Figure 8 is a flowchart illustrating the ECU update process according to the second embodiment. The ECU update process (steps S801-S812) will be described with reference to Figure 8. The ECU update process is performed by the software update determination unit 205 of the vehicle 200 after replacement.

[0058] The software update determination unit 205 starts the ECU update process (S801). First, the software update determination unit 205 acquires information on the ECUs to be updated (S802). The update order of each ECU follows the priority setting determined in the flowchart in Figure 7. For example, if the ECUs to be updated are the three shown in Figure 1: the automatic driving ECU 206, the brake ECU 208, and the engine ECU 210, and the priority setting method 640 in Figure 6 is automatic determination 643 (update size priority 63C), then the automatic driving ECU 206 will be updated first, followed by the engine ECU 210, and finally the brake ECU 208.

[0059] In S803, the software update determination unit 205 checks for ECUs to be updated. If there are any ECUs that have not been updated in S803 (YES), the software update determination unit 205 proceeds to S804. If there are no ECUs that have not been updated in S803 (NO), the software update determination unit 205 proceeds to S811.

[0060] In S804, each function-specific ECU (autonomous driving ECU 206, brake ECU 208, engine ECU 210) executes the update process using its respective update processing unit (207, 209, 211) according to instructions from the software update determination unit 205. In S805, the software update determination unit 205 checks whether the update process was successful or not. If the update process is successful (YES) in S805, the software update determination unit 205 returns to S803. If the update process fails (NO) in S805, the software update determination unit 205 moves to S806. Normally, when updating multiple ECUs, the probability of update failure increases.

[0061] In S806, the software update determination unit 205 updates the retry counter in order to execute a retry process (another update process) for the function-specific ECU whose update process failed. In other words, the retry counter is used to count the number of retries. Then, the processing of the software update determination unit 205 moves to S807. In S807, the software update determination unit 205 checks the counter value of the retry counter. If the counter value of the retry counter exceeds a preset counter value (for example, 2) (YES), the processing of the software update determination unit 205 moves to S808. If the counter value of the retry counter does not exceed a preset counter value (for example, 2) (NO), the processing of the software update determination unit 205 returns to S803. As a result, the retry process is executed for the function-specific ECU whose update process failed.

[0062] In S808, if the retry process exceeds a predetermined number of retries (in this example, if the retry counter value exceeds 2), the software update determination unit 205 checks for inconsistencies between multiple functional ECUs. Specifically, checking for inconsistencies between multiple functional ECUs involves confirming whether the updates of all dependent functional ECUs have been completed. In other words, when an update fails in any of the multiple functional ECUs, the software update determination unit 205 can determine whether the updates of all dependent functional ECUs have been completed, thereby determining whether the updates of all dependent functional ECUs are updated or not (update failure). If there is an inconsistency in S808 (YES), the software update determination unit 205 proceeds to S810. If there is no inconsistency in S808 (NO), the software update determination unit 205 proceeds to S809. The dependencies between functional ECUs can be obtained from the installed function information. For example, if the ECUs to be updated are the autonomous driving ECU 206, the brake ECU 208, and the engine ECU 210, then the autonomous driving ECU 206 and the brake ECU 208 are dependent on each other, while the engine ECU 210 is not dependent on the other ECUs (206, 208). In this case, an inconsistency would occur if either the autonomous driving ECU 206 or the brake ECU 208 failed to update.

[0063] In S809, the software update determination unit 205 sends an update failure notification. In this case, the update of some ECUs will not be completed.

[0064] In the S810, the software update determination unit 205 executes a Rollback process to revert all dependent ECUs to their original software state (the software state before the update). By executing the Rollback process, inconsistencies between all dependent ECUs can be avoided.

[0065] In S811, the software update determination unit 205 sends an update completion notification. This occurs when the update of all ECUs has been successful.

[0066] The ECU update process is now complete (S812).

[0067] (Third embodiment) A third embodiment of a vehicle software update system will be described.

[0068] The user terminal 400 can utilize an in-vehicle terminal or navigation terminal with a panel installed inside the vehicle after the change 200 or the vehicle before the change 300, rather than a dedicated terminal or a mobile terminal. The panel of the in-vehicle terminal or navigation terminal can be used as an input unit. By using these, it is possible to input user-selected function information inside the vehicle after the change 200 or the vehicle before the change 300. For example, the input / output device as the panel of a navigation terminal installed in a vehicle can be used as the user-selected function information input unit 402 as described in Figure 1. Since in-vehicle terminals or navigation terminals provided in the vehicles (300, 200) can be used, there is no need to purchase a dedicated terminal or mobile terminal separately, so a vehicle software update system can be built at a relatively low cost.

[0069] In the software update system of this disclosure, the functions of server 100 (101-106), vehicle 200 (202-205, 207, 209, 211), vehicle 300 (301, 302), and user terminal 400 (401-403) may be configured as hardware circuits formed on a semiconductor substrate. They may also be configured as software executed by a CPU. Alternatively, they may be configured using both hardware circuits and software.

[0070] (modified version) This disclosure is not limited to the embodiments described above, and includes various modifications. For example, the embodiments described above are described in detail for the purpose of explaining this disclosure clearly, and are not necessarily limited to having all the configurations described. Furthermore, it is possible to replace parts of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add configurations from other embodiments to the configuration of one embodiment. In addition, it is possible to add, delete, or replace parts of the configuration of each embodiment with other configurations. [Explanation of Symbols]

[0071] 10: Vehicle software update system, 20: Network, 100: Center (OTA server), 101: Vehicle / user authentication processing unit, 102: Vehicle mounted function information receiving unit, 103: User selection function receiving unit, 104: Difference extraction unit, 105: Update processing determination unit, 106: Update function information transmission unit, 200: Vehicle after replacement, 201: Vehicle control device (software update control device), 202: Vehicle authentication processing unit, 203: Mounted function information transmission unit, 204: Update function information receiving unit, 205: Software update determination unit, 206: Autonomous driving ECU, 207: Autonomous driving ECU update processing Sections: 208: Brake ECU, 209: Brake ECU update processing unit, 210: Engine ECU, 211: Engine ECU update processing unit, 300: Previous vehicle, 301: Vehicle authentication processing unit, 302: Mounted function information transmission unit, 400: User terminal, 401: User authentication processing unit, 402: User selected function information input unit, 403: User setting data area, 600: ECU type, 610: Setting function, 620: Update target, 630: Various priorities, 640: Priority setting method, 641: Initial setting (1), 642: Initial setting (2), 643: Automatic judgment, 644: User setting

Claims

1. It comprises a vehicle control system mounted on the vehicle and a server that communicates via a network. The aforementioned vehicles include the vehicle before the transfer and the vehicle after the transfer. A vehicle software update system that manages software updates for multiple functional electronic control devices within the vehicle after the transfer, The aforementioned server, The acquisition unit A acquires information on the functions installed in the vehicle before the transfer, The acquisition unit B acquires information on the functions installed in the vehicle after the transfer, Acquisition unit C that acquires user selection function information from the user terminal and A difference extraction unit extracts the difference between the installed function information of the vehicle before the transfer, the installed function information of the vehicle after the transfer, and the user-selected function information. An update process determination unit selects the necessary software update process according to the content of the difference and generates update function information based on the necessary software update process, It has, In the vehicle after the transfer, The vehicle control device has a software update determination unit that controls software updates and prioritization within the plurality of function-specific electronic control devices in accordance with the update function information distributed from the server. Each of the aforementioned plurality of function-specific electronic control devices has a software update processing unit that executes a software update method notified by the vehicle control device of the vehicle after the transfer. Vehicle software update system.

2. In the vehicle software update system according to claim 1, The aforementioned difference extraction unit determines the platform, and if the determination conditions are not met, it cancels the update process and notifies the user; this is a vehicle software update system.

3. In the vehicle software update system according to claim 1, The aforementioned difference extraction unit performs a resource determination of the ECU, and if the determination conditions are not met, the system cancels the update process and notifies the user, in a vehicle software update system.

4. In the vehicle software update system according to claim 1, The update processing determination unit selects the type of software update processing from add, update, delete, or skip, in this vehicle software update system.

5. In the vehicle software update system according to claim 1, The user terminal is a mobile device carried by the user, and is a vehicle software update system.

6. In the vehicle software update system according to claim 1, The user terminal is a vehicle software update system that allows input operations to be performed inside the vehicle before or after the transfer.

7. In the vehicle software update system according to claim 1, The vehicle control device of the vehicle after replacement is a vehicle software update system that, when there are multiple targets for update within the multiple function-specific electronic control devices, allows the software update determination unit to select user setting, automatic determination, and safety-first initial setting when setting the priority.

8. In the vehicle software update system according to claim 7, The aforementioned automatic determination sets the update priority from the target electronic control devices in order of decreasing update size. A vehicle software update system that allows the selection of the initial setting prioritizing safety if the difference in the update size is within a pre-set threshold.

9. In the vehicle software update system according to claim 1, A vehicle software update system in which each of the plurality of functional electronic control devices has a software update processing unit that can perform addition, update, deletion, and skip as part of the software update process.

10. In the vehicle software update system according to claim 1, The software update determination unit of the vehicle control device of the vehicle after the transfer, When an update fails in any of the aforementioned multi-function electronic control units, it is checked whether the updates of all dependent functional electronic control units have been completed, and any inconsistencies in updates and non-updates among all dependent functional electronic control units are determined. A retry process is executed to attempt to update the function-specific electronic control unit that failed to update. A vehicle software update system that, if the aforementioned retry process exceeds a predetermined number of retries, executes a Rollback process to restore all dependent function-specific electronic control units to their original software state.

Images