In-vehicle device and program update system

Abstract

To prevent a vehicle from becoming inoperative as much as possible even when a program update fails.SOLUTION: An in-vehicle device 6 includes: a program storage unit 64 for storing a program; an activation processing unit 65 for activating the program; and an update processing unit 63 for receiving an update program 21 and an update reason 22 for the program and updating the program by the update program 21. If update of the program fails, the activation processing unit 65 activates the program in an activation mode according to the update reason 22.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to an in-vehicle device on which a program is implemented, and a program update system for updating the program.

Background Art

[0002] In in-vehicle devices on which programs are implemented, such as ECUs (Electronic Control Units) for controlling vehicles and gateway ECUs, it is known to update the programs by OTA (Over The Air) or the like. In this type of in-vehicle device, if an event such as power supply to the in-vehicle device being interrupted (hereinafter also referred to as "power-off") occurs during program update, the program update may fail. In this case, it is common for the in-vehicle device to start the program in a degraded mode that only performs program update, and in the worst case, the vehicle may enter a state where it cannot operate normally (hereinafter also referred to as "inoperable state"). Patent Document 1 discloses a technique for starting a simple program and performing vehicle evacuation driving even when program update fails.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the technique disclosed in Patent Document 1, when program update fails, it is expected to reduce the vehicle from entering an inoperable state by starting a simple program and performing vehicle evacuation driving. However, in the technique disclosed in Patent Document 1, if the simple program has a functional defect or the like, there is a risk that the vehicle may enter an inoperable state, and there is room for improvement.

[0005] The present invention has been made in view of the above, and an object thereof is to minimize the situation where the vehicle becomes inoperable even when a program update fails.

Means for Solving the Problems

[0006] In order to solve the above problems, an in-vehicle device of the present invention includes a program storage unit that stores a program, a startup processing unit that starts the program, and an update processing unit that receives an update program for the program and a reason for update, and updates the program with the update program. The startup processing unit is characterized in that when the update of the program fails, the program is started in a startup mode according to the reason for update.

Effects of the Invention

[0007] According to the present invention, it is possible to minimize the situation where the vehicle becomes inoperable even when a program update fails. Problems, configurations, and effects other than the above will be clarified by the description of the following embodiments.

Brief Description of the Drawings

[0008]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Modes for Carrying Out the Invention

[0009] Hereinafter, embodiments of the present invention will be described with reference to the drawings. For components denoted by the same reference numerals in each embodiment, unless otherwise specified, they have the same functions in each embodiment, and the description thereof will be omitted.

[0010] [Embodiment 1] The program update system 1 of Embodiment 1 will be described with reference to FIGS. 1 to 4. FIG. 1 is a diagram showing the configuration of the program update system 1 of Embodiment 1. FIG. 2 is a diagram showing the update reason table 8 referred to by the startup mode determination unit 652 shown in FIG. 1.

[0011] When the update of the program installed in the in-vehicle device 6 fails due to some factor and it becomes impossible to determine the storage surface (hereinafter also referred to as the "startup surface") of the program storage unit 64 in which the startable program is stored, an example of determining the program startup mode in the in-vehicle device 6 using the update data 20 acquired from the server device 2 will be described. However, the technical idea of the present invention is not limited to this example. For example, the program update system 1 may acquire the update data 20 by other methods instead of acquiring it from the server device 2.

[0012] The program update system 1 includes a vehicle 3 equipped with an in-vehicle device 6 and a server device 2.

[0013] The server device 2 is connected to the vehicle 3 via a wireless communication network 11. The communication method of the wireless communication network 11 is typically a communication method used for OTA, but other communication methods may also be used. The server device 2 always stores the latest update data 20. The server device 2 transmits the update data 20 to the vehicle 3. At this time, the server device 2 issues an update notification (hereinafter also referred to as the "program update notification") notifying that the program stored in the program storage unit 64 is to be updated with the update data 20 and transmits it to the vehicle 3.

[0014] The update data 20 includes an update program 21 for updating the program stored in the program storage unit 64 and an update reason 22 which is the reason for updating the program with the update program 21.

[0015] The vehicle 3 includes a communication device 4, a gateway device 5, and an in-vehicle device 6. The communication device 4 and the gateway device 5 are connected by a communication bus 31, and the gateway device 5 and the in-vehicle device 6 are connected by the communication bus 31. Physically, the communication bus 31 is composed of a plurality of communication buses 31. The standards of the plurality of communication buses 31 may be the same as or different from each other. The standard of the communication bus 31 is, for example, CAN (registered trademark), LIN (registered trademark), FlexRay (registered trademark), or Ethernet (registered trademark), etc.

[0016] The communication device 4 includes a communication processing unit 41. The communication processing unit 41 has a communication interface function for the server device 2 and the gateway device 5. The communication processing unit 41 receives the update data 20 transmitted from the server device 2 and transmits it to the gateway device 5.

[0017] The gateway device 5 includes an OTA processing unit 51, a storage unit 52, and a communication processing unit 53. The gateway device 5 is composed of a CPU, a ROM, a RAM, etc. The gateway device 5 realizes the functions of the OTA processing unit 51 and the communication processing unit 53 by the CPU expanding and executing each program describing the OTA processing unit 51 and the communication processing unit 53 stored in the ROM in the RAM.

[0018] When the OTA processing unit 51 receives a program update notification transmitted from the server device 2 via the communication device 4, it issues a transmission request for the update data 20 and transmits it to the server device 2 via the communication device 4. When the OTA processing unit 51 receives the update data 20 transmitted from the server device 2 via the communication device 4, it stores the received update data 20 in the storage unit 52. The storage unit 52 is composed of a non-volatile storage device and stores the update data 20. The communication processing unit 53 has a communication interface function for the in-vehicle device 6. The OTA processing unit 51 transmits the update data 20 stored in the storage unit 52 to the in-vehicle device 6 via the communication processing unit 53. At this time, the OTA processing unit 51 issues an update request (hereinafter also referred to as "program update request") to request the update of the program stored in the program storage unit 64 by the update data 20, adds the update data 20, and transmits it to the in-vehicle device 6. The method of transmitting the program update request and the update data 20 to the in-vehicle device 6 is not particularly limited. Note that the OTA processing unit 51 may transmit the received update data 20 directly to the in-vehicle device 6 via the communication processing unit 53 without storing it in the storage unit 52.

[0019] The in-vehicle device 6 includes a communication processing unit 61, an update data storage unit 62, an update processing unit 63, a program storage unit 64, and a startup processing unit 65. The in-vehicle device 6 is composed of a CPU, a ROM, a RAM, and the like. The in-vehicle device 6 realizes the functions of the communication processing unit 61, the update processing unit 63, the program A, the program B, the function determination unit 66, and the startup processing unit 65 by the CPU expanding and executing each program describing the communication processing unit 61, the update processing unit 63, the program A, the program B, the function determination unit 66, and the startup processing unit 65 stored in the ROM in the RAM. The in-vehicle device 6 may be an ECU that controls the vehicle 3.

[0020] The update processing unit 63 receives, via the communication processing unit 61, a program update request transmitted from the gateway device 5 and update data 20 added to the update request. The communication processing unit 61 has a communication interface function for the gateway device 5. The update processing unit 63 stores the received update data 20 in the update data storage unit 62. The update data storage unit 62 is configured by a non-volatile storage device and stores the update data 20.

[0021] The update processing unit 63 updates (rewrites) the program stored in the program storage unit 64 with the update data 20 stored in the update data storage unit 62. For example, when the program update request transmitted from the gateway device 5 is a request to update Program A, the update processing unit 63 acquires the update program 21 included in the update data 20 stored in the update data storage unit 62. The update processing unit 63 updates Program A stored in the program storage unit 64 with the acquired update program 21. The update processing unit 63 checks the update status of the program stored in the program storage unit 64, and if an event such as a battery power failure occurs before the update of the program is completed, it can be determined that the update of the program has failed. Note that the update processing unit 63 may use the received update data 20 directly for updating the program stored in the program storage unit 64 without storing it in the update data storage unit 62. The program update method is not limited to this example.

[0022] The program storage unit 64 is configured by a non-volatile storage device and stores programs. The program storage unit 64 has a plurality of storage surfaces (ROMs) that store Program A and Program B, respectively. Program A and Program B may each include a control program for controlling the vehicle and a boot program.

[0023] The startup processing unit 65 starts the program (Program A or Program B) stored in the program storage unit 64. Thereby, the startup processing unit 65 starts the in-vehicle device 6. The startup processing unit 65 includes a startup surface determination unit 651, a startup mode determination unit 652, and a startup execution unit 653.

[0024] The startup surface determination unit 651 determines whether it is possible to determine the startup surface from among a plurality of storage surfaces of the program storage unit 64. That is, the startup surface determination unit 651 determines whether it is possible to normally start the program stored in any one of the plurality of storage surfaces of the program storage unit 64. In the in-vehicle device 6, when the update of the program stored in the program storage unit 64 fails due to an event such as a battery power cut-off, the startup surface determination information preset in the program storage unit 64 or the startup processing unit 65 may be lost. The startup surface determination unit 651 can determine whether it is possible to determine the startup surface by determining whether the startup surface determination information is lost. When the startup surface determination unit 651 can determine the startup surface, it notifies the startup execution unit 653 of the information on the determinable startup surface in order to start the program stored on the determinable startup surface. When the startup surface determination unit 651 cannot determine the startup surface, it can determine that the update of the program stored in the program storage unit 64 has failed. When the startup surface determination unit 651 cannot determine the startup surface, it notifies the startup mode determination unit 652 that the startup surface cannot be determined in order to determine the startup mode of the program.

[0025] The startup mode determination unit 652 determines the startup mode of the program stored in the program storage unit 64. The startup mode is the method of starting the program stored in the program storage unit 64. When the update of the program stored in the program storage unit 64 fails, the startup mode determination unit 652 determines the startup mode of the program according to the update reason 22. Specifically, when the update of the program fails and the startup surface determination unit 651 cannot determine the startup surface, the startup mode determination unit 652 reads the update reason 22 from the update data 20 stored in the update data storage unit 62. At this time, the startup mode determination unit 652 may read the update reason 22 via the update processing unit 63, or may read the update reason 22 without passing through the update processing unit 63.

[0026] The startup mode determination unit 652 refers to a predetermined update reason table 8, identifies the startup mode corresponding to the read update reason 22, and notifies the startup execution unit 653. As shown in FIG. 2, the update reason table 8 associates the update reason ID 81, which is the identification information of the update reason 22, the content 82 of the update reason 22, and the startup mode 83 corresponding to the update reason 22. The startup mode 83 defines how to start the program and includes the setting content of the startup mode.

[0027] The update reason table 8 can be arbitrarily created according to the configuration of the program update system 1. The update reason table 8 may be preset in the in-vehicle device 6 including the startup mode determination unit 652, or may be included in the update data 20. Also, when the update reason 22 is destroyed for some reason and cannot be read, the startup mode determination unit 652 may determine to start the program stored in the program storage unit 64 in the degraded mode and notify the startup execution unit 653.

[0028] Even if the update of the program stored in the program storage unit 64 fails, when the startup surface determination unit 651 can determine the startup surface, the startup execution unit 653 starts the program stored on the determinable startup surface. The startup mode at this time is the normal startup mode adopted during normal startup before the update of the program. On the other hand, when the update of the program fails and the startup surface determination unit 651 cannot determine the startup surface, the startup execution unit 653 starts the program according to the startup mode notified by the startup mode determination unit 652.

[0029] In this way, when the update of the program stored in the program storage unit 64 fails, the startup processing unit 65 starts the program in the startup mode according to the update reason 22 included in the received update data 20. Thereby, the in-vehicle device 6 can avoid a situation where the program is always started in the degraded mode even though the update reason 22 is not a reason with relatively high risk. For example, when the update reason 22 is to address a defect in a partial function of the program, as shown in FIG. 2, the program can be started in the function restriction mode. Therefore, the in-vehicle device 6 can minimize the situation where the vehicle 3 becomes inoperable even when the program update fails.

[0030] FIG. 3 is a sequence diagram showing the processing of the program update system 1 shown in FIG. 1.

[0031] In S101, when there is an update to the program stored in the program storage unit 64, the server device 2 issues a program update notification and transmits it to the gateway device 5 via the communication device 4.

[0032] In S102, when the gateway device 5 receives the program update notification, it issues a transmission request for the update data 20 and transmits it to the server device 2 via the communication device 4.

[0033] In S103, when the server device 2 receives a transmission request for the update data 20, the server device 2 transmits the update data 20 to the gateway device 5 via the communication device 4.

[0034] In S104, the gateway device 5 receives the update data 20 via the communication device 4.

[0035] In S105, the gateway device 5 issues a program update request, adds the update data 20, and transmits the data to the in-vehicle device 6.

[0036] In S106, the in-vehicle device 6 receives the program update request and the update data 20.

[0037] In S107, the in-vehicle device 6 performs an update process of updating the program stored in the program storage unit 64 with the update program 21 included in the update data 20.

[0038] In S108, it is assumed that a battery power-off occurs during the update process of the in-vehicle device 6 and the update of the program stored in the program storage unit 64 fails. When a battery power-off occurs, there is a possibility that any of the startup surface determination information is lost.

[0039] In S109, it is assumed that the power of the battery of the vehicle 3 is restored.

[0040] In S110, the in-vehicle device 6 determines whether it is possible to determine the startup surface of the program storage unit 64. When the in-vehicle device 6 can determine the startup surface of the program storage unit 64, the process proceeds to S111. When the in-vehicle device 6 cannot determine the startup surface of the program storage unit 64, the process proceeds to S112.

[0041] In S111, the in-vehicle device 6 starts the program stored in the program storage unit 64 in the normal startup mode.

[0042] In S112, the in-vehicle device 6 reads the update reason 22 included in the update data 20.

[0043] In S113, in-vehicle device 6 determines the startup mode based on the read update reason 22 and the update reason table 8 shown in FIG. 2. When the update reason ID 81 of the read update reason 22 is "0x01", in-vehicle device 6 proceeds to S114. When the update reason ID 81 of the read update reason 22 is "0x02", in-vehicle device 6 proceeds to S115. When the update reason ID 81 of the read update reason 22 is "0x03", in-vehicle device 6 proceeds to S116. Note that when the update reason ID 81 of the read update reason 22 is at least "0x02", in-vehicle device 6 may notify the user that the program update has failed. The method of notifying the user is not particularly limited.

[0044] In S114, in-vehicle device 6 starts the program stored in program storage unit 64 in the degraded mode. When the update reason 22 read in S112 is to address the security vulnerability of the program stored in program storage unit 64, when starting the program, the risk of being attacked using, for example, a security hole increases. Therefore, in this case, in-vehicle device 6 (startup processing unit 65) starts the program in the degraded mode where only the update of the program is performed. Thereby, in-vehicle device 6 can reduce the risk of being attacked using the security vulnerability.

[0045] In S115, the in-vehicle device 6 activates an executable program stored in any one of the plurality of storage surfaces of the program storage unit 64. When the update reason 22 read in S112 is to improve the function of the program stored in the program storage unit 64, even if the program update fails, the program stored in any one of the plurality of storage surfaces of the program storage unit 64 can be normally activated. Therefore, in this case, the in-vehicle device 6 (activation processing unit 65) activates an executable program stored in any one of the plurality of storage surfaces of the program storage unit 64. Thereby, even if the program update fails, the in-vehicle device 6 can avoid the degradation mode in which the vehicle 3 is likely to enter an inoperable state, and can control the vehicle 3 so that, for example, the vehicle evacuation driving is performed. Therefore, the in-vehicle device 6 can minimize the possibility that the vehicle 3 becomes inoperable even when the program update fails.

[0046] In S116, the in-vehicle device 6 activates in the function restriction mode. When the update reason 22 read in S112 is to address a defect in a partial function of the program stored in the program storage unit 64, if the defective partial function is not executed, it is highly likely that the vehicle 3 will not enter an inoperable state. Therefore, in this case, the in-vehicle device 6 (activation processing unit 65) activates the program in the function restriction mode that restricts the execution of the defective partial function. Thereby, even if the program update fails, the in-vehicle device 6 can avoid the degradation mode in which the vehicle 3 is likely to enter an inoperable state, and can control the vehicle 3 so that, for example, the vehicle evacuation driving is performed. Therefore, the in-vehicle device 6 can minimize the possibility that the vehicle 3 becomes inoperable even when the program update fails.

[0047] When the in-vehicle device 6 starts the program stored in the program storage unit 64 in the function restriction mode, it restricts the defective functions by performing a function determination process for determining whether each function of the program can be executed. The in-vehicle device 6 includes a function determination unit 66 that performs the function determination process. The function determination unit 66 determines whether each function of the program can be executed for each component that defines each function of the program. The conditions for the function determination unit 66 to determine whether it can be executed may be determined in advance for each component. As shown in FIG. 1, the function determination unit 66 may be incorporated into each program stored in the program storage unit 64. Alternatively, the function determination unit 66 may be incorporated into the startup execution unit 653 or the startup processing unit 65.

[0048] FIG. 4 is a flowchart of the function determination process performed in S116 shown in FIG. 3.

[0049] In S201, the in-vehicle device 6 determines whether a function to be determined whether it can be executed (hereinafter also referred to as "target function") among a plurality of functions constituting the program stored in the program storage unit 64 is a defective function. If the in-vehicle device 6 determines that the target function is a defective function, it proceeds to S202. If the in-vehicle device 6 determines that the target function is not a defective function, it proceeds to S203.

[0050] In S202, the in-vehicle device 6 sets the target function as non-executable and proceeds to S204.

[0051] In S203, the in-vehicle device 6 sets the target function as executable and proceeds to S204.

[0052] In S204, the in-vehicle device 6 determines whether the determination of whether each target function can be executed has been made for all target functions. If the in-vehicle device 6 has not made the determination of whether each target function can be executed, it proceeds to S201. If the in-vehicle device 6 has made the determination of whether each target function can be executed, this process shown in FIG. 4 ends.

[0053] As a result, the in-vehicle device 6 can execute functions without defects as normal while restricting the execution of some defective functions by a relatively simple method. Therefore, the in-vehicle device 6 can easily avoid the degraded mode, and thus can easily reduce the possibility that the vehicle 3 becomes inoperable even when a program update fails.

[0054] Note that the update reason table 8 shown in FIG. 2 groups the update reasons 22 for countermeasures against defects in some functions of the program under one update reason ID 81 "0x03", but is not limited thereto. The update reason table 8 may be created by subdividing the update reasons 22 for countermeasures against defects in some functions of the program for each function of the program and associating each with an update reason ID 81 and a startup mode 83.

[0055] [Embodiment 2] The program update system 1 according to Embodiment 2 will be described with reference to FIG. 5. In the program update system 1 according to Embodiment 2, the description of the same configuration and operation as in Embodiment 1 will be omitted. FIG. 5 is a diagram showing the configuration of the program update system 1 according to Embodiment 2.

[0056] In the program update system 1 according to Embodiment 2, the vehicle 3 is not connected to the server device 2 via the wireless communication network 11, but is connected to the diagnostic device 7 by the cable 12. The diagnostic device 7 stores the update data 20. The diagnostic device 7 transmits the update data 20 to the vehicle 3 via the cable 12.

[0057] Similar to the in-vehicle device 6 of Embodiment 1, when the update of the program stored in the program storage unit 64 fails, the in-vehicle device 6 of Embodiment 2 starts the program in a startup mode according to the update reason 22 included in the received update data 20. Thereby, similar to the in-vehicle device 6 of Embodiment 1, the in-vehicle device 6 of Embodiment 2 can avoid a situation where the program is always started in the degraded mode even though the update reason 22 is not a reason with relatively high risk. Therefore, similar to the in-vehicle device 6 of Embodiment 1, the in-vehicle device 6 of Embodiment 2 can minimize the situation where the vehicle 3 becomes inoperable even when the program update fails.

[0058] [Others] Note that the present invention is not limited to the above-described embodiments, and includes various modifications. For example, the above embodiments have been described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described. Also, a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. Further, for a part of the configuration of each embodiment, addition, deletion, or replacement with other configurations is possible.

[0059] In addition, the above-described respective configurations, functions, processing units, processing means, etc. may be realized by hardware by designing a part or all of them, for example, by an integrated circuit. Also, the above-described respective configurations, functions, etc. may be realized by software by a processor interpreting and executing a program for realizing each function. Information such as a program, tape, file, etc. for realizing each function can be placed in a memory, a recording device such as a hard disk, SSD (solid state drive), or a recording medium such as an IC card, SD card, DVD.

[0060] Also, the control lines and information lines show those considered necessary for explanation, and not necessarily all the control lines and information lines are shown on the product. In fact, it may be considered that almost all the configurations are interconnected.

Explanation of Reference Numerals

[0061] 1... Program update system, 11... Wireless communication network, 2... Server device, 21... Update program, 22... Reason for update, 3... Vehicle, 6... In-vehicle device, 63... Update processing unit, 64... Program storage unit, 65... Startup processing unit

Claims

1. A program storage unit that stores a program; A startup processing unit that starts up the program; An update processing unit that receives an update program for the program and a reason for the update, and updates the program with the update program, wherein when the update of the program fails, the startup processing unit starts up the program in a startup mode according to the reason for the update. An in-vehicle device characterized by the above.

2. When the reason for the update is to address a security vulnerability in the program, the startup processing unit starts up the program in a degraded mode that only updates the program. The in-vehicle device according to Claim 1, characterized by the above.

3. When the reason for the update is to address a defect in a partial function of the program, the startup processing unit starts up the program in a function restriction mode that restricts the defective partial function from being executed. The in-vehicle device according to Claim 1, characterized by the above.

4. The program storage unit has a plurality of storage surfaces for storing the program. When the reason for the update is to improve the function of the program, the startup processing unit starts up the executable program stored in any one of the plurality of storage surfaces. The in-vehicle device according to Claim 1, characterized by the above.

5. A vehicle equipped with the in-vehicle device according to Claim 1; A server device connected to the vehicle via a wireless communication network, and transmitting the update program and the reason for the update to the vehicle. A program update system characterized by including the above.

Images